Pagination, infinite scroll and load more buttons: how to keep long lists crawlable

Why does pagination matter for SEO, and what can go wrong?

Pagination divides long lists, such as products, articles or search results, into smaller pages. It speeds up page loads, reduces server work and keeps lists usable, but it also hides items from crawlers if the structure is wrong. Items that Google cannot reach cannot rank.

What does Google say about showing a subset of results?

Google's guidance on pagination and incremental page loading, last updated December 10, 2025, explains that showing a subset of results improves page speed, reduces network and backend load and avoids errors from overly long lists. It also stresses that site owners must still make sure crawlers can reach all the content.

Which sites are most affected?

Online stores with large categories, blogs and news archives, directories, job boards, property portals and any site that lists more items than fit on one screen.

What typically goes wrong?

Items beyond the first page are linked only through buttons or scripts, page two is canonicalized to page one so it drops out, page numbers use hash fragments, parameters generate endless variants and slow list pages hold back the whole category. Each failure leaves products or posts effectively invisible, as the diagnosis of Page indexing statuses often reveals.

How do you know whether your pagination is broken?

Crawl the site without running JavaScript, then count how many product or article URLs appear. If the count is far lower than your catalog size, the deeper pages are not linked in a crawlable way.

Does pagination hurt rankings by itself?

No. Paginated series are normal. The problems come from implementation: blocked discovery, wrong canonicals and thin or duplicated pages. Done properly, pagination gives each item a stable address and keeps pages fast.

Should you show everything on one page instead?

Only for short lists. A single page with hundreds of items becomes slow and heavy, which hurts users and metrics such as Largest Contentful Paint.

Which pagination patterns exist, and how do they compare?

Three patterns dominate: numbered pagination, a load more button and infinite scroll. Each has different usability trade-offs, and each needs a crawlable foundation.

How do the patterns compare?

Pattern	How it works	Strengths	SEO risk
Numbered pagination	Separate pages with page links	Shows result size and position, naturally crawlable	Low, if links are real anchors
Load more button	A button appends items to one page	Simple, keeps the user in context	High, unless paginated URLs sit behind it
Infinite scroll	Items load as the user scrolls	Effortless browsing	High, and long lists cause scrolling fatigue

Which pattern should you choose?

For SEO-critical lists, numbered pagination is the safest. If product teams prefer load more or infinite scroll, build them as an enhancement on top of crawlable paginated URLs, as described below.

What do usability studies imply?

Google's guidance notes that pagination shows result size and position but adds navigation steps, that load more can show total size but cannot handle very large sets, and that infinite scroll is intuitive but can cause fatigue. None is universally best. Pick the one that suits the content, then make it crawlable.

Does the pattern affect conversion?

It can. For shopping, shoppers often want to jump to a page or return to a position. Test the pattern with real users, and keep a URL for each position.

What about "view all" pages?

A view-all page can work for small sets, but large ones become slow. If you offer one, keep it fast and make sure it does not duplicate the paginated pages in confusing ways, with canonical choices explained in the guide to canonical URLs.

Should the view-all be the canonical?

Only if it loads quickly and contains the full set. Otherwise let each paginated page canonicalize to itself.

How do you make paginated pages crawlable?

Link each page to the next with an anchor element that has a real href, give each page a unique URL and avoid fragments. Google's guidance says it generally crawls URLs found in the href of anchor elements, and that crawlers do not click buttons or run scripts that need user action.

What does crawlable pagination markup look like?

<nav aria-label="Pagination">
  <a href="/category/boots/?page=1">1</a>
  <a href="/category/boots/?page=2" aria-current="page">2</a>
  <a href="/category/boots/?page=3">3</a>
  <a href="/category/boots/?page=3" rel="next">Next</a>
</nav>

The URLs are illustrative. Use whatever pattern your platform supports, such as a page parameter or a path segment, and keep it consistent.

Why not use buttons with click handlers?

Because a button with a script is not a link. Crawlers will not trigger it, so the next page is never found. The same principle runs through the guide to internal linking and crawlable links.

What are the URL rules?

• Give each page a unique URL, such as ?page=2 or /page/2/, since Google treats each as a separate page.
• Do not use fragment identifiers, such as #page=2, because Google ignores them.
• Link sequentially from each page to the next, and consider linking back to the first page.
• Keep the URL pattern stable so that links and bookmarks keep working.

Can paginated pages share titles?

Google says pages in a sequence can share titles and descriptions, and it tries to recognise the sequence. You can add the page number to the title for users, but it is not required.

What about rel next and rel prev?

Google no longer uses them, though other search engines may. Keeping them does no harm, but do not rely on them. Plain anchor links and unique URLs do the job.

Should you remove existing rel next and prev tags?

It is optional. If your platform adds them, leave them, and focus on crawlable links and correct canonicals.

How should canonical tags and indexing work on paginated pages?

Each page in a sequence should have its own canonical URL. Google's guidance says not to point the whole sequence at the first page, because the items on pages two and beyond would then be treated as duplicates of page one and may disappear from the index.

Why is page-one canonicalization harmful?

A canonical to page one tells Google that pages two to ten are the same as page one. Products or posts that appear only on later pages lose their path into the index. It is among the most common and costly pagination mistakes on large stores.

When is a canonical to a view-all page acceptable?

When the view-all page is fast, complete and carries all items. Even then, test carefully, and keep the paginated pages crawlable.

Should paginated pages be indexable?

Usually yes, because they are the route to deeper items. Their purpose is discovery, not ranking, so they rarely rank on their own, and noindexing them can reduce how often Google follows links to items that appear only there. If items are also reachable through other crawlable routes, such as category links and sitemaps, noindexing deep pages is less risky, but test before applying it.

How do you avoid thin paginated pages?

Keep a sensible number of items per page, enough to be useful, and put introductory copy on page one only. Do not repeat long descriptions on every page.

How do sitemaps and feeds help?

Google notes that sitemaps or a Merchant Center feed can help it find all products. List item URLs in the sitemap, so that discovery does not depend on deep pagination alone, and keep the product feed aligned with canonical URLs. The guide to XML sitemap best practices explains how to list URLs correctly.

Should paginated URLs be in the sitemap?

Generally list the items and primary category pages. Paginated list pages add little unless they are your only route to items.

How do you build load more and infinite scroll so that Google can crawl them?

Build the paginated version first, then enhance it with scripts. Each chunk of items should live at its own URL, the script should update the address bar as chunks load and the fallback links should work without JavaScript.

What is the progressive enhancement approach?

1. Render page one with normal pagination links and server-rendered items.
2. Give every subsequent page its own URL that returns the full list segment.
3. Add JavaScript that intercepts the Next link and appends the next segment into the current page.
4. Update the URL with the History API as the user scrolls or loads more, so each position is shareable.
5. Keep the real anchor links in the HTML so that crawlers and users without scripts can navigate.

Why does this satisfy Google and users?

Crawlers follow the plain links and index each page, and users enjoy the smooth experience. Both read the same underlying paginated structure.

What should you avoid with infinite scroll?

Do not load later items only on scroll events with no URL behind them, do not use hash fragments for positions and do not hide the footer and key links forever beneath endless content. Googlebot does not scroll like a user, so items that appear only after scroll triggers may never be found. The rendering considerations in the guide to Googlebot and the DOM apply here.

How do you test it?

Disable JavaScript, load the list and click through the pagination links. Then use the URL Inspection tool on a deep page to confirm that the items appear in the rendered HTML.

What about performance with long lists?

Appending hundreds of items can bloat the DOM and slow interactions. Cap the number of items per segment, consider virtualization for very long lists and watch interaction metrics, as described in the guide to Interaction to Next Paint.

Can you preload the next page?

Google notes that preload, preconnect or prefetch can speed up movement to the next page. Use them for the likely next page only, not for every link.

How do filters and sort orders interact with pagination?

Filters and sorts multiply paginated lists into thousands of near-duplicate URLs. Control which combinations Google crawls and indexes, keep the indexable ones high quality and block or noindex the rest.

What does Google recommend for duplicate list variations?

Google's guidance says to use a noindex robots meta tag or robots.txt rules to block unwanted URL patterns when filters and sort orders create duplicates. Choose carefully: noindex needs crawling to be seen, while robots.txt prevents crawling and is better for pure crawl traps. The comparison of noindex versus disallow explains the difference.

Which parameters usually deserve control?

Sort order, view mode, page size, price sliders and combinations of many filters. Single, high-demand filters may deserve their own landing pages.

How do you decide which filtered pages to index?

Index combinations that match real search demand and have enough items to be useful, with unique titles, headings and introductory text. Everything else should canonicalize to the base list or be excluded. The approach is set out in strategic indexing of filtered attributes, and the trap patterns in crawl traps and infinite filters.

How do pagination and filters combine?

A filtered list has its own pagination. Apply the same rules: unique URLs, crawlable links and self-canonicals for indexable filtered lists, and exclusion for the rest.

What about JavaScript-driven filters?

If filters change the list without changing the URL, crawlers see only the default view. That is fine for non-indexable filters, but not for those you want in search. The patterns in JavaScript-based filters and content visibility explain how to give valuable filters real URLs.

Should filter links use nofollow?

Not as a rule. Use proper canonical, noindex or robots controls rather than relying on link attributes, which are hints.

How should you design the content and user experience of paginated pages?

Paginated pages should be useful to people first: clear position, fast loading, consistent sorting and helpful navigation. That same design also helps crawlers understand the sequence.

What should every paginated page include?

A clear heading that names the list, a visible "Page 2 of 10" indicator, links to first, previous, next and last pages, a stable sort order and the items themselves rendered in HTML. Avoid replacing page content with a generic message, and keep key navigation visible so users can leave the list.

Should introductory text repeat on every page?

No. Place the long introduction on page one only. Repeating it on every page adds duplicate text and pushes items down the screen.

How do titles, headings and breadcrumbs work across a series?

Use the same core title and add the page number from page two onward, for example "Waterproof Hiking Boots, Page 2". Keep one H1 that names the list, and keep breadcrumbs pointing up to the category, not to previous pages. Descriptive anchors in navigation support understanding, as the guide to title links and rewrites explains for titles.

Should page numbers appear in the meta description?

It is optional. A shared description is acceptable, since Google says pages in a sequence can share titles and descriptions.

What stable sorting should you provide?

Default to a sort that gives each item a predictable position, such as relevance or newest first, and avoid random ordering. If items shuffle between visits, users lose their place and crawlers see unstable pages. Offer user-selected sorts through parameters you control, and canonicalize the non-default sorts to the default list.

How many items per page should you show?

Enough to be useful without slowing the page. Test page weight and interaction speed, and keep images lazy-loaded below the fold, following the practices in image SEO and Google Images.

What developer specification and QA checklist makes pagination repeatable?

A written specification prevents each redesign from reinventing pagination. It states the URL pattern, link markup, canonical rule and test cases, so that developers and QA know what "correct" means.

What belongs in the specification?

• URL pattern: for example /category/boots/ for page one and /category/boots/?page=2 for later pages, with no fragments.
• Markup: a pagination nav using anchor elements with href attributes, including first, previous, next and last links.
• Canonical rule: each page's canonical is its own absolute URL; page one's canonical omits the page parameter.
• Enhancement rule: load more and infinite scroll must update the URL and keep fallback links.
• Filter and sort rule: which parameters are indexable, which canonicalize to the base list and which are excluded.
• Performance budget: maximum items and image weight per page.

Who signs off on the specification?

The SEO lead and the front-end lead together, so that SEO rules and technical constraints are settled before work begins.

What does the QA checklist cover?

Test	How to run it	Pass condition
Links work without JavaScript	Disable scripts and click Next to the last page	Last page reachable through links alone
Self-canonicals	View source on pages 1, 2 and 5	Each canonical equals its own URL
No fragments	Search page URLs for the hash sign	None used for page numbers
Items in rendered HTML	URL Inspection live test on page 3	Page 3 items appear in rendered HTML
Filter control	Crawl with filters on	Non-indexable filters excluded or canonicalized
Speed	Measure Largest Contentful Paint on page 1 and 5	Both within budget

When should QA run?

Before each release that touches list templates, and again after launch on production URLs, since staging can differ from live.

What does the post-launch review include?

Check Search Console for new exclusions on item URLs, compare crawl counts of items before and after, and review the Crawl stats report for changes in requests to list pages. Record the findings with dates, so that you can tie any change in indexing to a specific release.

How do you handle a failed test?

Treat it as a defect with an owner and a date. Pagination defects hide revenue pages, so they deserve the same priority as a broken checkout step.

How does pagination differ for stores, blogs and local sites?

The principles are identical, but the stakes and typical mistakes differ by site type.

What matters for ecommerce category pages?

Products on deep pages are only found if pagination is crawlable, and the first page usually carries the ranking weight. Put helpful category text on page one, keep paginated pages fast, include product URLs in the sitemap and feed and keep product pages linked from other routes, such as best-seller blocks. The notes on category page content placement show where text belongs without cluttering list pages.

How many products per page is right?

There is no standard. Balance usability and speed, commonly 24 to 60 items on mobile-friendly grids, and test with real users.

What matters for blogs and news archives?

Older posts depend on archive pagination and internal links to be discovered. Do not rely on page 15 of an archive to surface a cornerstone article. Link important posts from hubs and related content, and consider category archives for topical grouping. The linking logic appears in the guide to orphan page identification.

Should author and date archives be indexed?

Only if they add unique value. Thin date archives often add noise, and noindex or consolidation is reasonable.

What matters for local and service sites?

Most small local sites need little pagination. If you have many location pages, a directory with crawlable pagination or hub pages is useful, but each location page must have unique content. Avoid long paginated lists of thin pages, a pattern that the analysis of scaled content abuse warns about.

Do review lists need pagination?

If you display many reviews, paginate or load more, and keep the most useful reviews on the first view.

How do you test and monitor pagination over time?

Crawl with and without JavaScript, compare the number of discovered items with your catalog size, inspect deep pages in Search Console and track how many items are indexed. Pagination breaks quietly after redesigns and plugin changes.

Which checks belong in the routine?

• A no-JavaScript crawl to confirm that links reach the last page.
• A canonical check on pages two and beyond.
• A fragment check: no page URLs containing a hash sign.
• A URL Inspection test on a deep page to confirm the rendered HTML shows its items.
• A sitemap check to confirm that items are listed independently of list pages.
• A review of the Page indexing report for item URLs that are not indexed.

How often should you run them?

After every theme, platform or template change, and quarterly for stable sites. The checks fit in the technical SEO audit checklist.

Which numbers show success?

The share of catalog items discovered in a crawl, the indexed share of item URLs, crawl depth of the deepest items and organic landing pages by category. Improvement appears over weeks as Google recrawls, so record dates and watch trends rather than days.

What if items still do not index?

Check item quality, duplicate content and internal links. Pagination only provides the route, and weak pages can still be excluded.

What does a pagination fix look like in practice?

This is a fictional example that illustrates the method. The outcomes are invented.

What was the situation?

A fictional outdoor-gear store had a "Boots" category with 480 products. A redesign introduced a load more button, and within months many products dropped out of impressions in Search Console.

What did the test find?

A no-JavaScript crawl found only the first 24 boots. Page two onward existed only through the button, and a plugin had set every paginated page's canonical to the category root. The sitemap listed only category pages, not products.

What did AH SEO Agency recommend?

Running the Pagination Safety Check: restore anchor links with unique page URLs, convert the load more button into a progressive enhancement of the Next link, set each page's canonical to itself, remove the plugin rule, add all product URLs to the sitemap and keep helpful category copy on page one. The team deployed in two releases, monitored indexed products weekly and recorded that recovery took several weeks and could not be guaranteed.

What did they learn?

The button was never the problem. It was the lack of a link underneath it, combined with a canonical that erased the later pages.

Which pagination mistakes should you avoid?

Almost every pagination failure comes from a short list of avoidable mistakes.

What do sites get wrong most often?

Load more or infinite scroll with no URLs behind them, canonicals pointing to page one, hash fragments for page numbers, blocking paginated URLs in robots.txt while relying on them for discovery, noindexing deep pages when items have no other path, endless filter combinations, very slow list pages and relying on rel next and prev.

Which mistake is the most costly?

Items reachable only through script-driven loading. They look fine to users and are invisible to crawlers, which makes the problem easy to miss.

How do you prevent regressions?

Add the Pagination Safety Check to your release checklist and run it on your two or three largest lists. Automate what you can: a crawl comparing item counts before and after a release catches most breakages.

Who owns pagination?

Front-end developers implement it, and SEO defines the rules and runs the checks.

How does AH SEO Agency help with pagination and large lists?

AH SEO Agency tests your lists with the Pagination Safety Check, shows you exactly which items crawlers can and cannot reach and gives your developers precise rules for URLs, links, canonicals and filters. We then monitor indexing until the lost items return, and we report honestly on what changed.

Where do you start?

Start with technical SEO support, add an ecommerce SEO review or request a free SEO audit that includes a pagination check.

Summary: how do you keep long lists visible to Google?

Give every page its own URL, link pages with real anchors, canonicalize each page to itself, avoid fragments, build load more and infinite scroll on top of paginated URLs and control filters and sorts.

• Google crawls anchor hrefs and does not click buttons or trigger user-action scripts.
• Do not canonicalize every page to page one, and do not rely on rel next and prev.
• Progressive enhancement satisfies users and crawlers.
• Control filter and sort variants with noindex or robots.txt as appropriate.
• Run the AH SEO Agency Pagination Safety Check after each release.