How to implement pagination that search engines can crawl

What pagination is and how it works

Pagination means dividing a set of items into pages of a fixed size and giving the visitor controls to move between them: previous, next and numbered page links. In web development, each page is normally a separate request. The server works out which slice of items to show from a page number in the address, such as /blog/page/3/ or /shoes?page=3, and returns just those items with links to the other pages.

The arithmetic is simple. With 24 items per page, page 3 shows items 49 to 72:

per_page = 24
offset   = (page - 1) * per_page      # page 3 -> skip 48 items
pages    = ceil(total_items / per_page)  # 500 items -> 21 pages

For search engines, each page in the series is just another URL. Google crawls page 1, follows the link to page 2, and so on, discovering the posts or products linked from each one. That is why pagination is a crawling question, not only a design one: an item that is only linked from page 14 is found only if the crawler can reach page 14.

Pagination problems that hide pages from search

The last two rows overlap with wider crawl issues. See crawler traps and faceted navigation for those.

How to add pagination in HTML

Whatever builds the page, the HTML a crawler receives for page 3 should look like this:

<head>
  <title>Sourdough Recipes, Page 3 | Example Bakery</title>
  <link rel="canonical" href="https://example.com/recipes/?page=3">
</head>
...
<nav aria-label="Pagination">
  <a href="/recipes/?page=2" rel="prev">Previous</a>
  <a href="/recipes/">1</a>
  <a href="/recipes/?page=2">2</a>
  <a href="/recipes/?page=3" aria-current="page">3</a>
  <a href="/recipes/?page=4">4</a>
  <a href="/recipes/?page=21">21</a>
  <a href="/recipes/?page=4" rel="next">Next</a>
</nav>

• Every page link is a plain anchor with a real href. You can still enhance it with JavaScript, but the link must work without it.
• The canonical points at the page itself, including its page number. It does not point at page 1.
• Page 1 lives at the clean address, /recipes/. Redirect /recipes/?page=1 to it with a 301 so there are not two versions.
• aria-current="page" tells screen readers which page is current, and the nav label makes the control easy to find.
• Linking to the last page and a few around the current one keeps every page within a few clicks of page 1.

Use a self-referencing canonical on each page as described in how to fix canonicals, and make sure pages beyond the last return a real 404 status.

Implementing it on the server, and does pagination improve performance?

Yes, pagination improves performance for both the visitor and the server. A page of 24 products sends a fraction of the HTML and images of a page with 500, and the database returns a small slice. The usual query uses LIMIT and OFFSET:

SELECT id, title, slug, published_at
FROM posts
WHERE status = 'published'
ORDER BY published_at DESC, id DESC
LIMIT 24 OFFSET 48;   -- page 3

Offsets are fine for a few hundred pages. On very large tables they slow down as the page number rises, because the database still reads and discards every skipped row. For deep lists and APIs, keyset pagination, also called cursor pagination, starts from the last item seen instead:

SELECT id, title, slug, published_at
FROM posts
WHERE status = 'published'
  AND (published_at, id) < ('2026-03-14 09:00:00', 4812)
ORDER BY published_at DESC, id DESC
LIMIT 24;

Keep an index on the sort columns, here published_at and id. Always include a unique column in the sort order so items with the same date do not jump between pages. For public, crawlable listings, keep numbered page URLs even if you use keyset queries behind them; cursor tokens in URLs make poor, unstable addresses.

Return the right status codes

curl -sI "https://example.com/recipes/?page=3"   | head -n 1   # expect 200
curl -sI "https://example.com/recipes/?page=999" | head -n 1   # expect 404
curl -sI "https://example.com/recipes/?page=1"   | grep -i '^location'   # expect /recipes/

Pagination in WordPress, Shopify and Next.js

• WordPress. Archives paginate at /page/2/ by default, with the number of posts per page set under Settings, Reading. Themes output the links with the_posts_pagination() or paginate_links(), which produce real anchors. Check that your SEO plugin gives each page a self-referencing canonical, and avoid load more buttons that replace those links. The WooCommerce crawl guide covers shop archives.
• Shopify. Collections paginate with the Liquid paginate tag and the ?page= parameter. Use default_pagination or build links from the paginate object, and check the theme's canonical includes the page number. See the Shopify crawl guide.
• Next.js. Read the page number from searchParams in a Server Component, fetch that slice on the server, render next/link anchors to the other pages, and call notFound() when the page is out of range. Set the canonical in generateMetadata to include the page parameter.
• Category pages generally. Put a short introduction on page 1 only, so the later pages do not repeat it. The category pages guide covers the rest.

Infinite scroll and load more buttons

Infinite scroll is fine for visitors if it sits on top of normal pagination. Each batch should correspond to a real URL such as ?page=4, the page should update the address with history.pushState as the visitor scrolls into a new batch, and the paginated links should remain in the HTML, even if visually tucked below the list. A crawler then sees normal paged URLs while visitors scroll.

A worked example: a recipe archive

Example Bakery's recipe section had 500 recipes, 24 per page, across 21 pages. A crawl found only 62 recipes reachable from internal links, and Search Console listed most of the rest as Discovered, currently not indexed or did not know about them at all.

The page links were <button> elements that loaded the next batch with JavaScript, every page had a canonical pointing to /recipes/, and pages 2 onwards carried noindex, follow. Requesting ?page=999 returned an empty page with status 200.

The fix replaced the buttons with anchors to ?page=N, kept the JavaScript as an enhancement, changed each canonical to the page's own address, removed the noindex, and returned 404 for out-of-range pages. A recrawl reached all 500 recipes within three clicks of the recipe index, and over the following weeks the number of indexed recipes rose steadily.

The fix, step by step

Edge cases worth knowing

• View all pages. A single page listing every item can work for a few dozen items, and you can point paginated pages' canonicals at it if it loads quickly. For hundreds of items it becomes slow, so stay with pagination.
• Changing items per page. Moving from 24 to 48 per page shifts every item to a new page number. That is harmless for items, which keep their own URLs, but out-of-range pages should then return 404 rather than errors.
• Duplicate titles. Paginated pages sharing one title are normal and rarely a problem, but adding the page number keeps crawl reports and tabs readable.
• Sorted views. If ?sort=price creates a second full set of pages, canonicalise sorted views to the default order and keep sort links out of the main crawl path. See crawl budget.
• Items reachable only by pagination. Deep pages are crawled less often. Link important items from category hubs, related item blocks and the sitemap too, as covered in orphan pages.

Keeping pagination crawlable

Pagination tends to break during redesigns, when a new theme or front-end component swaps links for a load more button. Protect it with a few checks:

1. After any template change, fetch page 2 of a listing with curl and confirm the pagination links are anchors with href values and the canonical points at page 2.
2. Test a page number past the end and confirm it returns 404.
3. Crawl the site every few months and compare the number of items found with the number published. A gap usually means a break in pagination or in internal links.
4. Keep every item in the XML sitemap, so discovery never depends on pagination alone.