Pagination SEO in 2026: Numbered Pages, Load More, or Infinite Scroll?

Administrator in Search Engine Optimization Jul 26 / 4 weeks ago

In February 2026, a Berlin furniture retailer with 38,000 products shipped a category-page redesign. The design team swapped numbered page links for infinite scroll because it tested better with users. Nobody looped in the SEO lead. Within six weeks, organic visits to products beyond the first screen of each category fell by a third. The finance team traced about 70,000 euros of lost quarterly revenue to items Google could no longer reach. The products were still live. The prices were still competitive. Google simply stopped seeing anything that loaded after a scroll event, because Googlebot does not scroll. That failure is not rare, and it is not new. It keeps happening because pagination sits in a blind spot between design, engineering, and marketing. Each team assumes another team owns it. This guide exists so that blind spot does not cost you a quarter of revenue before anyone notices what changed.

Here is what you will get from the next few minutes of reading. First, a clear picture of how Google treats paginated content in 2026, years after it retired rel=prev/next. Second, the canonical-tag mistake that still ships as a default in popular platforms and quietly removes deep pages from the index. Third, an honest comparison of numbered pages, load more buttons, and infinite scroll, and when each one is the right call. Fourth, a pagination SEO audit you can run this week with tools you already pay for. Along the way I will argue a few things that cut against common practice. Noindexing page two is usually self-harm. View All pages are underrated on small catalogs. And infinite scroll is a design pattern that teams treat as neutral when it truly changes how your site is crawled. The goal is simple. Every item you sell or publish should be easy to reach, crawl, and index without anyone having to click or scroll.

What is pagination SEO and why does it still decide revenue in 2026?

Pagination SEO is the work of structuring page sequences, such as shop categories, blog archives, and forums, so search engines can find, crawl, and index everything behind page one. It matters because most of your inventory lives on deep pages. If Googlebot cannot reach page seven of a category, the products on page seven effectively do not exist in search.

The money at stake is easy to miss. On a typical retail catalog, the first page of a category holds 24 to 48 items, so a 4,000-item category hides more than 98 percent of its products behind the pager. Those deep items rarely rank for head terms. Together, though, they win thousands of long-tail queries with clear buying intent. Knowing which queries those are is a search intent job as much as a technical one. Pagination SEO is the plumbing that lets that long tail earn anything at all.

What actually replaced rel=prev/next after Google retired it?

Nothing replaced it directly. Google confirmed in March 2019 that rel=prev/next had not been an indexing signal for years. In 2026, Google treats each paginated URL as a normal standalone page. The work moved from markup hints to basics: unique crawlable URLs, plain anchor links between pages, self-referencing canonicals, and internal links that keep deep pages within a few hops of the homepage.

Google's current pagination and incremental page loading guidance is refreshingly plain. Give every page in the sequence its own URL, such as a page query parameter. Link the pages to each other with normal anchor links. Do not use URL fragments for page state, because Google ignores everything after the hash. I still see teams adding rel=prev/next markup in 2026 out of nostalgia. It does no harm, but every hour spent on it is an hour not spent on link paths and XML sitemaps, which actually move discovery.

Should page 2 canonicalize to page 1?

No. Each paginated page should carry a self-referencing canonical. Pointing the canonical of page two at page one tells Google the pages are duplicates when they are not. Google then folds the sequence into one URL, stops crawling the deeper pages, and the items linked only from those pages can drop out of the crawl path entirely.

This is the most common pagination SEO mistake I see, and it ships as a default in more than one commerce platform. Google's own docs recommend giving each page in the sequence its own canonical URL. Page two holds different products than page one, so it is not a duplicate. Declaring it one is a lie the algorithm eventually believes. Run your category templates through a meta tag analyzer and read what page two actually declares. Sorted and filtered category variants are a different problem with different rules. Mixing filters up with page sequences is how teams end up noindexing the wrong thing.

Should you noindex paginated category pages?

Usually no. A noindex on page two and beyond feels tidy. But over time Google crawls noindexed pages less, and the links on them lose their power to lead crawlers anywhere. If deep items depend on paginated pages for discovery, noindexing those pages starves the very products you want indexed.

This noindex habit is the second most common pagination SEO error. The fear behind it is thin content. Teams worry that page nine of a category looks low quality to an algorithm. In practice, paginated pages rarely rank and rarely need to. Their job is to pass crawlers and equity through to item pages. Judging them by the standards of an article, where word count and depth matter, misreads their job. Keep them indexable, keep them linked, and let Google decide what to surface. The exception is truly empty pages, such as a category with two items in a stale template. That is a pruning decision, not a pagination one.

Numbered pages, load more, or infinite scroll: which pattern wins where?

Numbered pagination is the safest pattern for search and the dullest for users. Infinite scroll wins engagement on feed-style content and carries the highest crawl risk. Load more sits between them and inherits the risks of whatever build hides behind it. Choose by content type and by how much of your revenue rides on deep items.

My honest take: teams pick infinite scroll because it looks modern in a design review, not because anyone measured what it does to crawling. It is a site structure change wearing a visual-refresh costume. If your revenue is concentrated in a small set of items that all sit on page one, take the engagement win. If your margin lives in the long tail, the boring numbered pattern is the profitable one.

How do you make infinite scroll crawlable?

Pair the scroll feed with real component pages. Each chunk of the feed maps to its own URL. The browser updates that URL with the History API as the user scrolls, and each URL returns its items as server-rendered HTML. Googlebot does not scroll and does not click, so content that appears only after a scroll event is invisible to it.

The build checklist looks like this.

1. Divide the feed into chunks that map one-to-one to paginated URLs, such as a page parameter. Plan for half a day of engineering discussion before anyone writes code.
2. Update the address bar with pushState as each chunk enters the viewport, so users share and bookmark the URL of what they are actually seeing.
3. Make every component URL return full server-rendered content on direct request. This is the step that fails most often, because it usually means real backend work, not a frontend patch. Google's JavaScript SEO docs explain how rendering gets deferred, and deferred rendering is exactly what you are guarding against.
4. Keep visible next and previous anchor links in the markup even if most users never touch them. They are for crawlers.
5. Verify with URL Inspection that a mid-sequence URL renders its items. Budget an afternoon for testing across templates.

Some teams add ItemList markup to listing pages while doing this work. Fine, but structured data describes content Google can already see. It does not rescue content Google cannot reach.

Why do load more buttons quietly hide your products?

A load more button without a real URL behind it is infinite scroll with extra steps. Googlebot does not click buttons, so every item behind the click stays out of the crawl unless it has another path in. Sites lose deep items this way while their category pages look perfectly healthy to a human.

The fix is progressive enhancement in its original sense. Render the button as a real anchor link to the next page URL. Then let JavaScript catch the click and append content for users. Crawlers follow the link, users get the smooth feel, and both see the same inventory. It is a one-sprint change on most stacks. While you are in the template, run the page against an on-page SEO checklist, because load more templates often also ship duplicate titles across the sequence.

How does pagination control crawl depth on large sites?

Every hop from the homepage lowers a URL's crawl priority. A 190-page category chain means an item on page 95 sits nearly a hundred hops deep, which is a polite way of saying it will not be crawled this quarter. Pagination SEO is crawl-depth design, and crawl depth decides how fresh Google's copy of your catalog is.

Three fixes do most of the work. First, add jump links in the pager to the first page, the last page, and a few midpoints. The deepest page then sits a handful of hops away instead of dozens. Second, split oversized categories into subcategories that act as hub pages, which shortens paths and matches how people actually browse. Third, measure instead of guessing. A desktop crawler like Screaming Frog, covered in our SEO tools roundup, charts crawl depth in minutes, and its crawl maps make a 90-hop chain painfully visible in a meeting. If Search Console shows deep items stuck in Discovered currently not crawled, depth is the first suspect to check.

Do View All pages still make sense?

On small catalogs, yes, and they are underrated. A single View All page pools every item, every internal link, and every ranking signal on one URL. That beats spreading them across a fragile sequence. The pattern dies on large catalogs, where a thousand-item page ruins load time and mobile use at once.

A workable rule: if the full list stays under roughly 100 items, and the page keeps its largest contentful paint near two seconds on a mid-range phone, prefer View All and drop the paginated variant. Categories above that line should stay paginated. The mistake to avoid is running both patterns with clashing canonicals, where paginated pages point at View All while internal links point at the paginated pages. Pick one main version and make every signal agree with it.

How should blog archives and news feeds handle pagination?

Archives exist for discovery, not for ranking. Keep them crawlable and boring: numbered pages, self-referencing canonicals, and stable URLs. The real archive problem is usually cargo, not structure. Ten years of tag pages and near-empty date archives waste crawling long before the pager itself hurts anything.

For publishers, pagination SEO is usually the smaller half of the archive problem. I would rank the work in this order. Merge overlapping tags, empty categories, and orphaned date archives before touching the pager. Treat that as part of a broader content refresh and pruning program. Then make sure the newest content is never more than two hops from the homepage, because news-style content earns most of its search value in its first days. Feed-style infinite scroll is fine on a news homepage as long as the component-URL pattern from earlier in this guide backs it.

How do you audit pagination problems step by step?

A pagination SEO audit answers three questions. Can a crawler reach every item URL without a click or a scroll? How many hops does the deepest item sit from the homepage? And do the paginated URLs declare sane canonicals and robots rules? You can answer all three in about a day on most sites.

1. Crawl the site twice with a desktop crawler, once with JavaScript rendering off and once with it on. Expect 30 to 90 minutes per crawl on a mid-size site. The gap between the two item counts is your JavaScript dependency, and it should be near zero.
2. Export the item URLs from each crawl and diff them against your product database. Missing items are your discovery gap, and the gap usually clusters in a few categories.
3. Inspect page two of your five biggest categories by hand. Read the canonical, the robots meta, and the title. This takes twenty minutes and finds the default-setup bugs that crawlers smooth over. A site-wide SEO report tool helps you pick which templates deserve that manual read.
4. Run URL Inspection on a sample of deep paginated URLs and deep item URLs. Note which sit in Discovered currently not crawled versus Crawled currently not indexed, because the two states point at different fixes.
5. Confirm every item URL is listed in your sitemap files. A generator such as our XML sitemap generator is fine for small sites, while large catalogs need sitemaps built from the product database directly.
6. If the audit convinces you to change URLs, treat it as a migration with a full redirect map, following our redirects and site migrations guide. Pagination URL changes without redirects quietly reset whatever equity the sequence had.

Fold the findings into your standing technical SEO audit process so pagination gets rechecked after every major template release, not once per crisis.

How do you measure paginated pages in Search Console and GA4?

In Search Console, filter the performance report by your pagination parameter to see whether deep pages earn impressions at all, then use the indexing reports to count how many paginated URLs Google actually knows. In GA4, the default reports hide query parameters, so measuring pagination takes one deliberate setup step.

The Search Console side of pagination SEO measurement is quick. A page filter on something like page= splits the sequence out of the noise, and the trend of impressions on page-two-and-beyond URLs is a direct read on whether your deep content shows up in search at all. On the GA4 side, page paths strip query strings in most standard reports, so create a custom dimension on the full page location if pagination analysis matters to you. The mindset is the same one we describe for tracking AI referral traffic in GA4. Decide what question you are asking, then shape the data to answer it, because the defaults will not.

How does your pagination pattern move Core Web Vitals?

Infinite scroll is a layout-shift machine. Every appended batch can push content around, and scroll handlers plus huge DOM trees produce the long tasks that ruin input response. Numbered pages reset the viewport cleanly on each load, which is one reason the boring pattern keeps winning field-data comparisons.

If you keep scroll or load more patterns, three habits contain the damage. Reserve vertical space for incoming items so the layout does not jump, which is the core advice in the web.dev guidance on cumulative layout shift. Cap the DOM by recycling nodes that scroll far out of view, because a 5,000-product DOM tree makes every tap sluggish. And lazy-load images below the first viewport with explicit dimensions. Our Core Web Vitals guide covers the measurement side, but the summary is that pagination choices show up directly in CLS and INP field data, and field data is what Google scores.

Frequently Asked Questions

Does Google still use rel=prev/next in 2026?

No. Google confirmed back in 2019 that it had already stopped using rel=prev/next as an indexing signal. Leaving the markup in place does not hurt, and a few other search engines have historically read it as a hint, but you should not spend build time on it. Plain anchor links, unique URLs, and correct canonicals are what Google's current pagination docs actually ask for.

Should page 2 have its own title and meta description?

Yes, vary them lightly. Appending a page number to the title, such as Running Shoes, Page 3, is enough to avoid a wall of identical titles in crawl reports and keeps each URL honestly described. Do not invest in unique descriptive copy for every paginated page. These pages exist to pass crawlers through to items, not to win their own rankings.

Is infinite scroll bad for SEO?

Infinite scroll is risky by default and fine when engineered properly. The risk is that crawlers never trigger scroll events, so items that load on scroll stay undiscovered. The fix is pairing the scroll feed with real component URLs that render their content server-side, updated through the History API. If your team cannot commit to that engineering work, numbered pagination is the safer choice.

How many items should one category page show?

Most retail sites land between 24 and 48 items per page, and that range holds up. Fewer items per page means longer chains and deeper crawl paths. More items per page means heavier pages and slower largest contentful paint on mobile. Pick a number near the top of that range, then check both crawl depth and field performance data before tuning further.

Should paginated URLs be in the XML sitemap?

Generally no. Sitemaps should list the URLs you want indexed and ranking, which means item pages, category first pages, and articles. Paginated URLs get discovered through the links between pages, which is exactly the job those links exist to do. The exception is a diagnostic one, where temporarily listing deep pages helps you test whether discovery or quality is blocking indexing.

Do paginated pages dilute link equity?

Equity flows through paginated pages rather than pooling on them, and that is the design. The genuine dilution problem is depth. When equity has to pass through ninety sequential hops, almost nothing arrives at the far end. Jump links, subcategory hubs, and featured-item modules on category first pages shorten those paths and deliver more value to deep items than any markup tweak.

What is the fastest fix when deep products are not indexed?

Work the discovery path first. Confirm page-two-and-beyond URLs are crawlable and self-canonical, confirm the sequence is linked with plain anchor links, and confirm every item URL sits in the sitemap. Then request indexing on a handful of sample items and watch their status for two to three weeks. If they move from discovered to indexed, keep going. If nothing moves, your constraint is quality or authority rather than pagination.

Does a load more button hurt Core Web Vitals?

It can, and the damage usually shows up in layout shift and input delay rather than load time. Each appended batch pushes the footer and everything below it downward, which counts toward CLS unless you reserve space first. Heavy click handlers that fetch, parse, and render large batches can also produce the long tasks that hurt INP. Keep batches small, reserve vertical room for incoming items, and give every image explicit dimensions. Field data, not lab tests, decides how Google scores it.

How should multilingual sites handle paginated pages?

Give every language its own complete pagination sequence and never mix them. The German page two should link to the German page three, not to an English URL. If you use hreflang annotations, connect matching page numbers across languages so the signals line up. Do not canonicalize translated paginated pages to their English versions, because that hides the translated items from crawlers. The same self-canonical rule applies in every language, where each paginated URL declares itself.

Does Google index page 2 of a category?

It can, and that is normal and harmless. In practice Google usually ranks the first page of a category because it carries the most internal links and the strongest signals. A deep page showing up for an occasional long-tail query is not duplicate content and needs no fix. Leave the deeper pages indexable and let them do their real job, which is passing crawlers and link equity through to the products and articles they list.

Where does pagination SEO go next?

The Berlin retailer from the opening recovered, by the way, in the least glamorous way possible. The team put component URLs behind the scroll, restored self-referencing canonicals, added jump links, and watched deep-item impressions climb back over eight weeks. No penalty, no mystery, just plumbing. That is the honest shape of pagination SEO in 2026. The markup era is over, and what remains is architecture: real URLs, short paths, and signals that agree with each other. My prediction for the next two years: this discipline gets more valuable, not less. AI crawlers and shopping agents are worse at running JavaScript than Googlebot ever was, and they will simply skip inventory they cannot reach in plain HTML. The sites that win agentic search will be the ones whose deepest products are one clean URL away. Audit your biggest category this week and count the hops to your last item. What did you find when you looked?