Shopify collection pagination and SEO: how ?page= URLs should work

How does Shopify turn one collection into several URLs?

Shopify's paginate tag exists because a for loop is limited to 50 iterations per page. To list more products than that, a theme wraps the loop in paginate collection.products by N, where N is between 1 and 250. Inside the tag the theme gets a paginate object, and the default_pagination filter turns it into the page links. The documented output is ordinary anchors with a page query parameter, for example href="/services/liquid_rendering/resource?page=2", plus a "Next" link to the following page.

That is the whole mechanism, and it is a good one for search: every page of a collection has its own address, and the navigation between them is a real link. Shopify also documents a ceiling. The tag lets a shopper reach the 25,000th item in an array and no further, so a collection beyond that size has to be narrowed before it is paginated.

Two details are worth knowing before you read anything else. The first is that the page size is a theme decision. A theme that paginates by 12 turns a 120-product collection into ten URLs; one that paginates by 48 turns it into three. The second is that paginate also controls how much data the server fetches. Shopify's documentation notes that referencing collection.products fetches up to 50 products by default whatever the loop's limit says, and that pairing paginate with a matching page size reduces the data queried and speeds up the response.

What does Google ask of paginated pages?

Google's guide to pagination, incremental page loading and their impact on Search gives three practices. We quote them in our own words, with the reasoning attached.

Link pages sequentially. Each page should link to the next with an a href, so that Googlebot can find the later pages. Google also suggests linking from every page back to the first page of the collection, as a hint that the first page may be the better landing page. Shopify's default pagination output does the first part. Check that your theme keeps it.

Use URLs correctly. Give each page a unique URL, with a ?page=n parameter as the example. Do not use the first page as the canonical of the whole sequence; give each page its own canonical. Do not put page numbers in a URL fragment, because Google ignores everything after the # and may decide it has already fetched the page. Google's guide also states that it no longer uses rel="next" and rel="prev", though other search engines may. If your theme still prints them, they are harmless, and not worth adding if it does not.

Avoid indexing filtered or re-sorted lists. A ?sort_by=price-ascending or a filter parameter produces the same products in another order. Google's answer is to block those with noindex or discourage crawling with robots.txt. That is a different problem from pagination, and we cover it in the collection filter URLs guide.

One more line from the same page matters on Shopify: pages in a paginated sequence do not need distinct titles or descriptions. Google says you can use the same ones for every page and that it tries to recognise pages in a sequence and index them accordingly. You do not need to write "Page 2 of 7" into every title to be safe.

What should the canonical on page two say?

Page two should say ?page=2. Our canonical URL guide lists what Shopify's canonical_url object emits: page one canonical to the bare collection URL, page two canonical to itself with the parameter. That matches Google's instruction, and it is worth stating plainly because the opposite edit is common. An SEO app or a hand-edited theme.liquid points every page of the sequence at page one because it looks tidy. By Google's own guidance that is wrong: the products that appear only on pages two to seven are then attached to a canonical that does not list them.

You can check it in under a minute. Open /collections/<handle>?page=2 on your own store, view the source, and search for rel="canonical". The href should end in ?page=2. Then do the same on page one and confirm there is no ?page=1 in the canonical.

Why should deep pages stay indexable?

The tempting shortcut is to put noindex on every page after the first, on the reasoning that they are thin duplicates. They are not duplicates. Each page holds different products. If page three is the only place a product is linked from in the collection, then a noindex on page three removes the path Google uses to find that product.

Google's guide puts the weight on the other tools: sitemaps and Merchant Center feeds help it find products, but the pagination links are what let it crawl the collection itself. Our sitemap guide covers what Shopify lists. It lists product URLs, which is a useful second route to deep products, but it is a hint, not a replacement for a crawlable collection.

The honest trade-off is crawl effort. A store with 400 products and 24 per page has about seventeen pages per collection, which is not a problem. A store with tens of thousands of products and small page sizes has a much longer tail, and there it is reasonable to raise the page size so that fewer URLs exist, rather than to hide URLs that hold products. If a long tail is a real concern, the lever is the page size in paginate collection.products by N, not noindex.

Does infinite scroll or a "load more" button break this?

It can. Google's guide says it generally crawls URLs found in the href attribute of a elements, and that its crawlers do not click buttons or trigger JavaScript functions that need a user action to update the page. "Load more" and infinite scroll are generally built with JavaScript. A theme that replaces the page links with a button that fetches the next batch can leave Google with only the first page of products.

The guide's own table of trade-offs is useful here. Load more and infinite scroll keep everything on one page, which is pleasant to use, and neither suits very large result sets. Pagination shows where the shopper is, at the cost of a page load per step.

The pattern that works on Shopify is to keep the real paginated links in the HTML and let JavaScript enhance them. The server still renders ?page=2 as an anchor; the script intercepts the click or the scroll and appends the next page's products. Shopify's paginate documentation names the Section Rendering API as the way to paginate a list without refreshing the whole page, so fetching pages by script is a supported route. Test it by turning JavaScript off, or by viewing the page source rather than the rendered DOM, and looking for the ?page=2 link.

How do you test your own collections?

Four checks, none of which needs a paid tool.

1. View source on a large collection. Search for ?page=2. If it is not in the HTML as an href, the links are built by script and Google may not follow them.
2. Read the canonical on pages one, two and the last page. Page one: bare URL. Others: themselves.
3. Crawl with a crawler that does not run JavaScript. Any crawler set to fetch HTML without rendering JavaScript shows what a link-following bot sees. Count how many products it reaches through the collection. If it is fewer than the collection holds, something is blocking the path.
4. Check Search Console. In the Page indexing report, filter by URLs containing page=. "Crawled - currently not indexed" on deep pages is common and not by itself a fault. A large number of pages under "Alternate page with proper canonical tag" for ?page= URLs means the canonical is pointing at page one.

What should you fix first, and how long does it take?

1. Check the canonical on page two of your largest collection (two minutes). If it points at page one, remove the app or theme edit that does it.
2. View source and find the ?page=2 anchor (two minutes). If your theme uses infinite scroll and the anchor is missing, ask your developer to render the pagination links server-side and let the script enhance them rather than replace them (a few hours of theme work).
3. Remove any noindex from ?page= URLs (ten minutes), unless you can show the products on them are all reachable another way.
4. Decide the page size (an hour). A larger page means fewer URLs and a longer page to load; weigh it against the speed numbers in our page weight guide.

If you would rather have your collections crawled and the pagination checked against a full list of products, that is one of the things our Store Teardown covers.