# Infinite Scroll on PrestaShop: How to Preserve SEO Pagination and URLs

> On three thousand references, a poorly implemented infinite scroll can leave two thousand five hundred products without a link from their own category. The principle that solves the problem, the four mistakes to avoid and the checks to run.

- Page: <https://www.datafirefly.com/en/2026/10/06/infinite-scroll-prestashop-seo-pagination/>
- Language: en
- Published: 2026-10-06
- Last updated: 2026-10-06
- Other languages: [fr](https://www.datafirefly.com/2026/10/06/scroll-infini-prestashop-pagination-seo/index.md), [es](https://www.datafirefly.com/es/2026/10/06/scroll-infinito-prestashop-paginacion-seo/index.md), [de](https://www.datafirefly.com/de/2026/10/06/infinite-scroll-prestashop-seo-paginierung/index.md), [it](https://www.datafirefly.com/it/2026/10/06/scroll-infinito-prestashop-paginazione-seo/index.md), [pl](https://www.datafirefly.com/pl/2026/10/06/infinite-scroll-prestashop-paginacja-seo/index.md), [nl](https://www.datafirefly.com/nl/2026/10/06/oneindig-scrollen-prestashop-paginering-seo/index.md), [pt](https://www.datafirefly.com/pt/2026/10/06/scroll-infinito-prestashop-paginacao-seo/index.md)
- Index: <https://www.datafirefly.com/en/2026/llms.txt>

Infinite scroll improves the browsing experience and creates an indexing problem: if the products of subsequent batches only exist in the browser, search engines only see the first twenty of each category.

On a catalogue of three thousand references spread across fifteen categories, that can leave two thousand five hundred products without an inbound link from their own category.

The scroll-position restore behaviour, a neighbouring topic, is covered separately.

## Why the subsequent pages disappear

Three mechanisms add up.

**No link to follow.** If loading the next batches is triggered by scrolling, no address exists in the page. The crawler has nothing to explore.

**Scrolling is not simulated.** An engine that renders a page's code does not scroll the screen like a visitor. What loads on scroll therefore never loads.

**No shareable address.** Without a URL matching each state, no external link can point to a page 3, and nothing gets passed along.

Consequence: your products remain discoverable via the sitemap and internal links, but they lose the link from their category, which is the most natural and the most qualifying one.

## The solution: keep both structures

The principle that solves the problem fits in one sentence: **infinite scroll is an enhancement layered on top of pagination that genuinely exists**.

Concretely, that means three things.

**The paginated pages exist** and are reachable at their own address. Opening page 3 directly in a browser must display products 41 to 60, served by the server.

**The pagination links are present** in the page's code, even if they are visually hidden in favour of scrolling.

**Scrolling updates the address** with each loaded batch, replacing the current history entry rather than creating a new one.

A visitor only sees smooth scrolling. A crawler sees classic pagination. Both are served without compromise, and it is not different content but the same content reachable through two paths.

## Hidden pagination links

A point that sometimes raises concerns: is it legitimate to visually hide links that are present in the code?

Yes, in this precise case, for two reasons. The links lead to the **same content** as the one reached by scrolling, so there is no divergence between what the visitor sees and what the crawler sees. And they remain **keyboard accessible**, which makes them usable by a real share of visitors.

Best practice is in fact not to hide them entirely: a "see next page" button below the loaded products, alongside automatic loading, serves search engines, keyboard users and those who prefer pagination all at once.

## Handling the addresses

Four rules.

**Page 1 exists without a parameter.** It must not be reachable both with and without a page indication, otherwise you create a duplicate.

**Each page carries a canonical to itself.** Pointing pages 2 and beyond to the first amounts to requesting the exclusion of products that only appear on them.

**Product order is stable.** If your default sort changes between two visits, the same product can move from page 2 to page 3, which makes indexing unstable. Add a deterministic tie-breaker, the ID for instance, after your main sort criterion.

**Sort and filter parameters** combine with pagination in a normalised order, otherwise you multiply variants of the same page.

## The number of products per page

A decision with a direct effect on indexing.

Too few products per page produces many pages, which spreads crawling thin. Too many products makes the page heavy and degrades performance.

A benchmark: twenty-four to forty-eight products per page covers most situations well. On a category of two hundred products, that gives four to eight pages, which remains crawlable.

The "view all" page deserves a note. It is sometimes recommended as the canonical target of the paginated series. That is defensible below one hundred products, unmanageable beyond: the page becomes too heavy and the experience degrades for everyone.

## What not to do

Four mistakes, in order of severity.

**Scrolling alone, without underlying pagination.** That is the starting case, and the most damaging.

**A canonical from subsequent pages to page 1.** A very widespread mistake, which produces exactly the result you were trying to avoid.

**Noindex on pages 2 and beyond.** Some apply it to avoid duplication, which is unfounded: these pages have different content. Noindex excludes them from the index and prevents the discovery of their products.

**Creating one history entry per loaded batch.** The visitor who scrolled through ten batches must press back ten times to leave the category.

## Checking it works

Four quick checks.

**Open page 3 directly** in a browser, by pasting its address. The matching products must display without any prior scrolling.

**View the source code** of page 1, without script execution. Links to the following pages must appear in it.

**Use URL inspection** in Search Console on a page 3, and look at the rendered result. It is the closest test to what the engine actually sees.

**Count the indexed pages** of your categories in the indexing report. If only pages 1 appear, your pagination is not being seen.

## The effect on the sitemap

A complementary question, to settle.

The sitemap must contain your product pages, which guarantees their discovery independently of pagination. Should paginated category pages be added to it?

No, in general. The sitemap flags important pages, and a category's page 7 is not one. The pagination links are enough to make them crawlable.

On the other hand, if your sitemap does not contain all your product pages, fix that first: it is the safety net that compensates for navigation flaws.

## Measuring

Three indicators, recorded before and then at two months.

The **number of indexed category pages**, which must rise if your subsequent pages were invisible.

The **number of indexed product pages**, against the total catalogue. That is the figure that counts.

The **discovery delay** of a new product added in a deep category, which measures the efficiency of the whole chain.

The  sets up this dual structure on PrestaShop 8 and 9: real server-side pagination with links present in the code, progressive loading on top with address updates that don't multiply history entries, a self-referencing canonical per page and a pagination button kept for keyboard access.