A visitor browses a category, scrolls down to the fortieth product, opens a product page, goes back and lands at the top of page 1. They have to start over. It is one of the most reported frictions on large catalogues, and also one of the cheapest to fix.
Why going back does not work
Three distinct causes, with different solutions.
The page is reloaded from the server. On a back navigation, the browser may serve the page from its cache or request it again. In the second case all the visual state is lost, including the scroll position.
The content is loaded after the initial render. On a category with infinite scroll or asynchronous filters, the page returns to its starting state: the products loaded by scrolling no longer exist on the way back.
The navigation state is not in the URL. If pagination, filters and sort order are not reflected in the address, the browser has no way of restoring them.
That last cause is the structural one: with no state in the URL, no reliable restoration is possible.
What needs to be remembered
Four elements, only two of which are obvious.
The scroll position. The most visible, and paradoxically the least important: if the right products are displayed, a visitor quickly finds their bearings again.
The current page or the number of batches loaded. This is the decisive point. A visitor who reached the sixtieth product must find those sixty products again, not the first twenty.
The active filters and sort order. They belong in the URL, which settles the problem independently of any memorisation mechanism.
The product viewed. Restoring the position is good; bringing the visitor back exactly to the thumbnail of the product they have just seen, with a light highlight, is markedly better. They pick up their thread immediately.
Infinite Scroll PrestaShop — SEO-Safe Pagination & Position RestoreInfinite scroll on category pages with SEO-preserved pagination and exact position restore after visiting a product page.€69.00
The two technical approaches
State in the URL. Each change of filter, sort order or page updates the address without a reload. Going back naturally restores the state because the address describes it.
This is the more robust approach: it also works for link sharing, opening in a new tab and indexing. It does require clean handling of the navigation history, with a distinction between changes that create a history entry and those that replace the current one.
The useful rule: a filter change creates an entry, a simple scroll replaces the current entry. Without that distinction, the back button forces the visitor through ten intermediate states before leaving the category.
Session storage. The state is saved on the browser side when leaving the page and restored on return. Simpler to implement, and limited: it does not work on a shared link or in a new tab.
The combination that works: the URL carries the filters, the sort order and the pagination; session storage carries the scroll position and the identifier of the last product viewed.
The new tab case
A very widespread behaviour and one rarely handled: the visitor opens product pages in new tabs, keeps five of them open, and comes back to the category tab.
Good news: in that case the category tab has not been reloaded and its state is intact. No mechanism is needed.
Two things to watch nonetheless. If your page automatically reloads its content when focus returns, to refresh stock levels for example, you destroy that state. And highlighting the last product viewed does not work in this scenario, since several products have been opened.
Good practice is to visually mark every product already viewed in the grid, not just the last one. It helps in both scenarios and it helps the visitor navigate a long list.
Infinite scroll or pagination
Returning to a position is harder with infinite scroll, and that weighs in the choice between the two.
With classic pagination, the URL contains the page number, going back works naturally, and indexing is simple. The drawback is the extra click on each page.
With infinite scroll, the browsing experience is smoother but three problems appear: returning to the position, access to a footer that has become unreachable, and indexing of the dynamically loaded products.
The intermediate solution resolves most of those points: a scroll that automatically loads two or three batches, then an explicit “show more” button, with the URL updated at each batch. You keep the fluidity of the early browsing, the address stays shareable, and the footer becomes reachable again.
What breaks the restoration
Four situations to check after implementation.
Server cache. A cached page may be served in a state different from the one expected. Check the behaviour in real conditions, not only in a development environment.
Stock changes. If a product becomes unavailable between leaving and returning, the grid changes and the stored position no longer matches. Restore on the product identifier rather than on a position in pixels.
Responsive display. A pixel position calculated on desktop means nothing if the visitor has rotated their phone in the meantime. One more reason to think in products rather than distance.
Blocks of variable height. A promotional banner or a block loaded late shifts the grid. Wait for the elements above the grid to finish loading before restoring.
Measuring
Two indicators are enough, and the second is the one that counts.
The number of products viewed per session on the categories concerned. A visitor who no longer loses their position mechanically views more of them.
The return rate to the category from product pages. If it rises after implementation, your comparison journey works. If it stays low, the problem is elsewhere, probably in the product page itself.
The Infinite Scroll module for PrestaShop handles this behaviour on PrestaShop 8 and 9: progressive loading with the address updated at each batch, restoration of the page and the position when returning from a product page, marking of products already viewed, and an explicit button after the first batches to keep the footer reachable.
