In short
Not by itself. Infinite scroll becomes a problem when the products loaded after the first batch exist only in response to a scroll or a click, because search engine crawlers render a page but do not interact with it. If every batch also lives at a real, linked URL that returns those products on request, the pattern is safe. The remaining questions are about shoppers rather than crawlers: losing your place on the back button, an unreachable footer and a page that keeps growing on a phone.
Crawlers render pages, they do not scroll them
Googlebot loads a page, executes its JavaScript and looks at the result, but it does not behave like a person. It does not scroll to the bottom, it does not click a load more button, and it does not wait around for content triggered by those actions. Whatever is in the rendered page without interaction is what gets seen.
So a category page that shows twenty-four products and fetches the rest as the visitor scrolls exposes twenty-four products to a crawler. On a category holding four hundred items, the other several hundred have no route in from that page. They may still be found through the sitemap, but a URL discovered only through a sitemap has no internal links pointing at it, which weakens it and slows how often it is revisited.
That is the whole mechanism. Nothing about the scrolling itself is penalised, and there is no rule against the pattern. The damage is structural: the internal link graph that should connect a category to its products has a hole in it.
The same reasoning applies to review lists, filtered results and any other component that reveals content on interaction. If it matters that something is found, it needs an address and a link.
The pattern that keeps both audiences happy
Build paginated URLs first, then layer the scrolling behaviour on top. Each batch of products should be reachable at its own address, and the load more control should be a real link to that address which JavaScript intercepts for visitors whose browsers support it. With scripting unavailable, the link still works and a crawler follows it.
Update the address as the shopper moves through the batches, so somebody who scrolls to the fourth screen and opens a product can return to where they were rather than to the top. That single change fixes the most common complaint about infinite scroll and costs very little to implement.
Each paginated URL should be canonical to itself, carry a title that reflects the page number where it is visible, and stay out of the sitemap if you prefer to list only the first page. What matters is that the links exist and resolve, not that every page is submitted.
Check the result the way a crawler sees it. Request the category with JavaScript disabled and confirm the link to the next batch is in the source, then run the live URL through Search Console's inspection tool and read the rendered HTML for the same link.
How to tell whether your store already has the problem
Three checks give a clear answer. First, view the page source of a deep category and search for the URL of the second batch. If it is absent from both the raw source and the rendered output, products beyond the first screen have no internal path.
Second, open the page indexing report in Search Console and look for products sitting in the discovered but not indexed state. A large group of them on a store with infinite scroll is the classic symptom: Google knows the URLs from your sitemap and has not been given enough reason to fetch them.
Third, take a sample of products from deep in a large category and inspect them individually. If the tool reports few or no referring internal links from your own site, the category is not passing anything down to them.
The fix order follows from what you find. Restore the paginated links first, since that is the structural repair. Then look at whether the categories themselves are too large, because a category needing twenty batches is usually a category that should have subcategories.
The shopper side, which is where the real cost usually sits
Infinite scroll suits feeds people browse without a destination. Product grids are not that. Shoppers on a category page are comparing and narrowing, and the behaviours they rely on are filtering, sorting, opening several items and coming back, and knowing roughly how far through the range they are.
Continuous loading interferes with all four. The footer, which usually holds shipping, returns and contact links, becomes hard to reach because new content keeps appearing above it. Progress is invisible, so there is no sense of having seen the range. On a phone, the page keeps getting heavier, which shows up in interaction responsiveness and in data use.
A load more button avoids most of that while keeping the convenience. It loads on demand, leaves the footer reachable, and gives an obvious place to stop. That is why it has become the common pattern on large retail sites.
Whatever you choose, test it rather than assuming. Add to cart rate and revenue per session on the category template, split by device, will tell you what the pattern is worth on your catalogue. On stores where products are compared side by side, pagination often holds up better than either alternative.
Related questions
Does Googlebot click a load more button?
No. It renders the page and reads what is there, but it does not perform clicks, scrolls or form submissions. That is why the control has to be a genuine link to a URL that returns the next batch, with the script enhancing it for visitors rather than being the only way the content is reachable.
Does infinite scroll affect Core Web Vitals?
It can affect responsiveness and layout stability rather than load time. Each batch adds elements and event listeners, so a long session on one page can make interactions slower, and content inserted without reserved space causes shifts. Measure the category template on a mid-range phone after several batches, not just on first load.
Can pagination and infinite scroll exist together without creating duplicates?
Yes, because they are two views of the same sequence rather than two sets of pages. The paginated addresses hold the batches, the scrolling behaviour reveals them in one continuous view, and each address canonicalises to itself. Duplication only appears if you also generate a separate view-all URL listing the same products.