Yes, but only if the products are reachable through crawlable links. Google can parse anchor elements with an href attribute, including links inserted into the page by JavaScript, but it cannot reliably extract URLs from buttons or script-only events. Load more, infinite scroll and classic pagination all work for discovery when each product and each page has a real, resolvable URL in the HTML.
What does Google actually say about pagination and incremental loading?
Google's guidance on pagination and incremental page loading treats pagination, Load more and infinite scroll as user-experience patterns, not as ranking features. The document explains that displaying a subset of results improves initial load speed, reduces network traffic and protects backend systems from very long lists. It also states that you may need to take action to ensure the Google crawler can find all your site content.
The important distinction is between what a shopper sees and what the crawler can parse. A Load more button that appends products to the same document can be perfectly usable for humans while leaving those products invisible to discovery if no crawlable URL points to them.
Google's link best practices are the mechanism behind discovery. Google generally crawls a link only when it is an anchor element with an href attribute. Links inserted dynamically by JavaScript are crawlable when they use that markup. Formats such as a span with an href, an anchor with only a click handler, or an anchor with a router directive instead of href are not reliably parsed.
Why do Load more and infinite scroll hide products?
Incremental loading often fetches the next set of products from an API and injects them into the existing page. The URL does not change. If the injected product cards contain proper anchor elements with href attributes, Google can follow them. If the cards are divs with click handlers, or if the product URLs only exist inside a JSON response, there is nothing reliable for the crawler to extract.
Classic pagination has the same failure mode in a different form. A page-number control built from buttons with no href gives the crawler no path to page two. A numbered link with a real URL does.
What is the safest structure for a category with many products?
The safest structure is one where every product and every paginated page has a stable, crawlable URL, and where the page itself declares its canonical version. A practical decision table:
| Pattern | Discovery risk | What to verify |
|---|---|---|
| Numbered links with href | Low | Each page returns 200 and contains product anchors |
| Load more appending cards | Medium to high | Injected cards use anchor elements with href |
| Infinite scroll only | High | A paginated fallback URL set exists |
| Button-only page numbers | High | Replace with anchor elements or add a sitemap path |
| Faceted filters | Variable | Do not rewrite the whole facet system; check which combinations are linked |
Self-referencing canonicals are the default expectation for paginated category pages. Each page in the sequence should point to itself, not to page one. Google no longer uses rel next and rel prev as indexing signals, so you should not rely on them to guarantee discovery. They are not harmful, but they are not a mechanism you can depend on.
How do you test whether Google can reach products behind Load more?
You do not need personal analytics to run this check. You need to compare the rendered page against the raw response.
- Fetch the category URL with JavaScript disabled and inspect the HTML. Look for anchor elements with href attributes pointing to products and to the next page.
- Fetch the same URL with rendering enabled and compare. If product links appear only after rendering, they may still be crawlable, but the dependency is worth documenting.
- Open the URL inspection tool for a sample product that sits behind Load more. Check whether Google has a crawled version and whether the canonical Google selected matches the URL you intended.
- Check the category page's own canonical tag. It should point to itself.
- Repeat for one large category, one small category and one filtered view.
A hypothetical example: a store sells 400 lamps across 20 pages. Pages one to five are linked with numbered anchors. Pages six to twenty are only reachable by clicking Load more four times. In that setup, the crawler can follow the first five pages directly; the remaining products depend entirely on whether the injected cards contain href links. If they do, discovery is plausible. If they do not, those products have no crawlable path from the category.
What should you not change?
Do not rewrite a working faceted navigation system just because pagination looks untidy. Facets often create thousands of near-duplicate URLs, and a broad rewrite can remove useful crawl paths or create new index bloat. Fix the specific discovery gap: add crawlable links, confirm self-canonicals, and leave the rest of the facet logic alone until you have evidence of a problem.
For a broader view of how category structure fits into store visibility, see Ecommerce SEO: build a store people can actually find. If you are prioritising fixes across a whole site, Ecommerce SEO audit: the checks that come first explains how to sequence them.
What remains uncertain?
Google's documentation describes what the crawler can parse, not how much crawl budget any specific store receives. A crawlable link is a necessary condition for discovery, not a guarantee that every product will be indexed. Rendering behaviour can also change, and a pattern that works today may need rechecking after a front-end refactor. Treat the checks above as a repeatable diagnostic rather than a one-time fix.
Follow-up questions
Does Load more hurt SEO compared with classic pagination?
Not by itself. The pattern matters less than whether the products and pages have crawlable URLs. A Load more implementation with proper anchor elements can be discovered; a classic pagination control built from buttons cannot.
Should paginated pages use rel next and rel prev?
No. Google no longer uses rel next and rel prev as indexing signals. Use self-referencing canonicals on each page and make sure the sequence is linked with crawlable anchors.