Infinite scroll is a way of showing a long list, such as products, articles or search results, where more items load automatically as the visitor nears the bottom of the screen, so there is no “page 2” to click. It feels smooth on a phone, but it can hide most of the list from search engines if it is built without them in mind.
How infinite scroll works
The first batch of items arrives with the page. When the visitor scrolls close to the end, a script asks the server for the next batch and adds it to the page. A variant replaces the automatic loading with a “Load more” button, which works the same way behind the scenes.
The search problem is that Googlebot does not behave like a person with a thumb. It loads the page, renders it, and reads what is there. It does not keep scrolling to trigger the next request, and it does not press “Load more”. If the only route to item 61 onwards is a scroll event, those items, and the links to their product or article pages, may never be found through that list.
The reliable pattern is to back the scrolling list with real, separately addressable pages. Batch one lives at /shoes/, batch two at /shoes/?page=2, and so on, each loadable on its own with plain links between them. As the visitor scrolls, the script updates the address bar to the matching URL using the browser’s History API. People get the smooth experience, and crawlers get a normal set of paginated pages they can follow.
Why it matters
For a UK online shop, the category listing is often the main path Google uses to reach individual products. A clothing retailer with 400 dresses in one category, showing 24 at a time, has 376 dresses reachable only through scrolling. If those products are not also linked from somewhere a crawler can follow, they may sit undiscovered or be crawled rarely, which slows how quickly new stock or price changes show in search.
It also affects visitors. A footer full of delivery, returns and contact links is unreachable when new items keep pushing it down. People who click a product and then press Back often lose their place and land at the top of the list again. And a page that grows indefinitely can become slow on older phones, because the browser holds every loaded image and element in memory.
Common mistakes
- No URLs behind the batches. Everything after the first load exists only in the browser, with no address a crawler or a shared link can reach.
- Using a # fragment for page numbers. Google generally ignores everything after the hash, so /shoes/#page=3 is treated as the same URL as /shoes/.
- A “Load more” button with no link. A <button> that fires a script gives crawlers nothing to follow. An <a href> pointing at the next page does.
- Canonicalising every page to page one. Pages 2, 3 and 4 hold different items. Each should carry its own self-referencing canonical, or the items on them lose their crawl path.
- Burying essential links in the footer. If delivery information or the contact page only appears in a footer that scrolling never reaches, move those links somewhere visible.
How to act on it
Start by checking what a crawler sees. Load a category or blog listing with JavaScript turned off, or run it through the URL Inspection tool in Search Console and view the rendered HTML. Count the items and links present. If the list stops at the first batch, the rest depends on scrolling.
Then confirm that each batch has a URL that loads on its own, returns a 200 status and links to the next. Combine this with sensible lazy loading for images, so the page stays light without hiding content. On shops with filters as well as scrolling, the two problems often overlap, and the fix usually sits within a wider review of crawl paths and site structure, which is the kind of work I cover in technical SEO.
If you are choosing a pattern for a new build, a “Load more” button backed by real paginated URLs is usually the safest middle ground. It keeps the footer reachable, lets people stop when they want to, and gives search engines a clean set of pages.