October 31, 2026
Most stores should use their theme's built in recently viewed section if it has one, and add a lightweight app or a small code snippet if it does not. Put the rail on the product page below the main content and on the cart page, nowhere else. It must hide sold out items, cap itself at four to eight products, and load after the main content so it never slows the page a customer is actually reading.
Recently viewed exists because shoppers browse the way people browse a market stall: they circle back. A customer who looked at three jackets, left to check a size chart, and cannot find the second jacket again is a sale the store lost to its own navigation.
The feature is simple, which is why its failures are so consistent. Rails that show sold out items, rails that slow the product page, and rails on every page including checkout are the three ways stores turn a small convenience into a small tax.
Check your theme first. Many current paid themes and some free setups include a recently viewed section you can switch on, and a built in one inherits your theme's styling and updates. If yours lacks it, a small app is the honest choice for most stores: the feature touches storage, sessions, and product data, and an app keeps that maintained when Shopify changes something underneath.
The do it yourself route, a snippet storing viewed product handles in the browser and rendering them back, is well documented and fine for a store with a developer on call. Without one, it becomes the kind of quiet breakage nobody notices for a season: the rail showing blanks after a theme update. Choose the option someone will actually maintain.
Product pages and the cart. On a product page the rail answers the question the customer is already asking, what was that other one. On the cart page it recovers the item they compared and dropped. On the homepage it is noise, because a returning visitor has a purpose the rail rarely matches, and at checkout it is a distraction a store should never install.
Three rules keep it honest. Hide anything sold out, because showing a customer the unavailable jacket they wanted is pure frustration. Cap the count low, four on mobile, so the rail stays a memory and not a second catalog. And never let the rail block or delay the main product content: it loads last, or it does not load.
Recently viewed recovers comparison shoppers; it does not create demand. Expect it to show up as slightly better product page depth and fewer dead end sessions, not a conversion leap you can see in a week. Stores with tiny catalogs gain little, because the customer could find the jacket again anyway. Stores with deep, similar catalogs, apparel, parts, supplies, gain the most.
Watch what the rail shows your customers about your store. If it regularly surfaces sold out and seasonal leftovers, the problem is catalog housekeeping wearing a feature's clothes. Clean that up and the same rail starts looking like a service instead of an apology.
Related reading: Add a Backorder Notice on a Shopify Product Page That Buyers Actually Read, Add a Gift Card Balance Check on Shopify: Stop the Support Tickets, and Add Back in Stock Alerts on Shopify: Capture the Sale You Already Earned.
Dawn does not ship a full recently viewed section by default in the way many paid themes do. Stores on Dawn usually add it with an app or a documented code snippet. Before adding either, check your theme version and settings; features move between versions and a setting you already have beats an install.
Only if it is tied to a logged in account, which most implementations are not: browser based versions live on one device. That is acceptable for most stores, since comparison shopping usually happens in one session on one phone. Do not promise customers a cross device memory your setup does not have.
Four to eight, with the most recent first. Beyond eight the rail stops being a memory aid and becomes a catalog the customer did not ask for. On mobile, four is usually right, and the rail should be swipeable rather than a long vertical stack pushing the page apart.
A badly built one can, if it loads product data synchronously before the main content or pulls full product pages per item. A correct implementation loads after the main content and fetches light product data only. Test the product page speed with the rail on, on mobile, before you call it done.