For ecommerce and news sites, infinite scroll is everywhere on product lists and article feeds — users scroll to the bottom and the next page loads automatically, smooth as butter. But search engines don’t scroll. They only recognize URLs. Infinite scroll crams everything into one page, so crawlers only ever see the first screen, and the products and articles behind it never make it into the index.
This article explains where infinite scroll conflicts with SEO, and how to have both without ruining the user experience. If you’re planning to add infinite scroll, read this first — it’ll save you a ton of index recovery work later.
Here’s the bottom line up front: infinite scroll is great for user experience but unfriendly to crawlers — content without an independent URL can’t get indexed. The solution is infinite scroll for humans, paginated URLs for crawlers, both coexisting. Every page must have an independently crawlable URL (like ?p=2), and those URLs should be listed in the XML sitemap; don’t hide key content behind scroll — put the most important, most index-worthy content on the first screen.
Figure: Coexisting infinite scroll and pagination (compiled by 运营GO)
Where the conflict is
Infinite scroll is essentially “one request loads, frontend JS renders the rest.” Crawlers (especially at the crawling stage before JS execution) get the initial HTML, which only contains the first screen’s content and a “load more” trigger — no links to the subsequent products. The result: you think thousands of products are live on your site, but Google has only indexed the few dozen on the first screen.
A more hidden problem is diluted authority: all traffic and links point to that one list page URL, internal link authority can’t flow to individual products, and product pages never get a chance to appear directly in search. This is fatal for ecommerce — when users search for a specific model, your product page isn’t even in the running. I’ve seen a site where after adding infinite scroll, organic traffic to product pages dropped 60% in three months, and only slowly recovered after reverting to pagination.
How to verify if indexing is broken
After launching infinite scroll, don’t judge by gut feel. Go to GSC’s “URL Inspection” and spot-check a few product/article URLs that should be beyond the first screen — see whether “Google has selected this URL” says “Yes,” “Indexed but not in index,” or “Not found.” If you find a lot of paginated content isn’t indexed, it’s basically infinite scroll’s fault. Another quick check: search site:yourdomain.com + specific product name and see if the product page appears in results. I recommend doing this verification weekly after launch — catch it early, fix it early.
The both-worlds solution: scroll for humans, pagination for crawlers
Step 1: Keep paginated URLs. When infinite scroll loads the next page, the URL should change synchronously (like #page=2 or ?p=2), so every “screen” of content has its own address. That address must be directly accessible by crawlers to get the corresponding content — not dependent on a JS trigger. Technically this is called “addressable state,” and it’s the basic skill for doing SEO on SPAs and infinite feeds.
Step 2: Put core content on the first screen. The most important products, the newest articles — put them on the first few screens, so even if crawlers only grab the initial HTML, what gets indexed is the most valuable part. Don’t hide your bestsellers behind the third screen. A rule of thumb: assuming crawlers only grab the initial HTML, are the 10 URLs you most want indexed all in there? If not, rearrange the order.
Step 3: Sitemap as safety net. List all paginated URLs and individual product/article URLs in the XML sitemap, submit it to GSC. It doesn’t matter that crawlers don’t scroll — the sitemap points the way for them one by one. For technical details, see crawl budget optimization, which is about spending budget on high-value URLs instead of letting pagination waste crawl quota on low-quality pages.
A common wrong implementation
A lot of people think “using the history API to change the URL counts as pagination” — it doesn’t. If after changing the URL, directly visiting that URL returns the first screen’s content (relying on JS to re-fetch), crawlers can’t get the static content for that page, which means it’s effectively not paginated. The correct approach is server-side rendering (SSR) or pre-rendering each paginated URL, so crawlers directly get the complete HTML for that page. This is the most overlooked — and most fatal — step in doing SEO with infinite scroll.
On mobile there’s an extra layer to think about: infinite scroll on phones is most likely to make users “get lost” — they scroll to the bottom and can’t find a way back to the top, or pagination parameters don’t sync in mobile routing. I recommend keeping a persistent “back to top / page number” control on mobile, and making sure the ?p= parameter is also crawlable in mobile routing. Don’t skip it because “mobile users don’t care about pagination” — crawlers use the same indexing logic on mobile and desktop.
| Pagination method | Crawl friendliness | Best for |
|---|---|---|
| Traditional pagination ?page=2 | High | Multi-page content lists |
| Infinite scroll | Low (needs support) | Mobile content feeds |
| Load more (button) | Medium | Medium-short lists |
When to just abandon infinite scroll
Two types of sites should just skip infinite scroll entirely: first, depth-first content sites (blogs, documentation), where users want precise navigation and sharing of specific pages, and pagination gives a better experience; second, sites where SEO is the main traffic source, where the benefit of infinite scroll doesn’t outweigh the indexing loss. If a news feed absolutely must use it, at least keep a “view all / pagination” entry on category pages — don’t block the path entirely. To see how to let crawlers smoothly traverse the whole site from an architecture perspective, check the flat navigation architecture article, which is about flattening content hierarchy so crawlers have shorter paths to walk.
How to recover if you already launched infinite scroll
If your site already has infinite scroll and indexing has dropped, don’t panic and rewrite everything. Fix in this order: first, add independent URLs to each page and make sure direct visits return static content (slowest but most critical); then add all paginated and detail URLs to the sitemap and submit to GSC; then use GSC’s “URL Inspection” to request re-indexing of key paginated pages one by one; finally, watch for 4-6 weeks and see if product page traffic comes back. During recovery, don’t rush to refactor the frontend — first clear the “can be crawled” hurdle, and talk about experience optimization after indexing recovers. A site I worked with followed this order, and organic traffic to product pages recovered to 90% of pre-infinite-scroll levels by week eight.
Next action items
- Check whether your site’s URL changes when infinite scroll loads — if not, fix it (add a
?p=parameter). - Confirm each paginated URL returns corresponding static content when visited directly, not just via JS.
- Add all paginated and detail URLs to the XML sitemap and submit to GSC.
- Move bestselling content to the first screen, don’t hide it deep in the scroll.
- Pure content sites or SEO-first sites should switch to pagination entirely and abandon infinite scroll.
