We Don't Need Page Numbers: Google and Infinite Scrolling

Look at almost any product built in the last few years and the numbered page links at the bottom, 1 2 3 … 47 Next, are gone. Feeds scroll forever, search results sprout a "Load more" button, dashboards stream rows as you reach the bottom. For users, that is mostly an upgrade: nobody enjoys hunting for the right page number. But "we don't need page numbers" quietly splits into two very different questions, one about humans, one about Googlebot, and teams that answer only the first one routinely hide half their catalogue from search. This is the detailed 2026 guide to pagination vs infinite scroll: what each pattern does to UX, what Google actually crawls, the trap that silently de-indexes content, and how to get both right. Since 2016, Make An App Like has shipped 500+ apps for founders in 40+ countries; these are the same rules we apply on every build.

Quick Answer: Do You Still Need Page Numbers?

For users? Usually not. Numbered pagination is rarely the best experience, load-more or infinite scroll feels faster and lighter for most browsing.

For Google? You don't need visible page numbers, but you absolutely still need crawlable paginated URLs. Googlebot doesn't scroll and doesn't click "Load more," so any content that only appears on scroll, with no real URL behind it, is invisible to search.

The rule: hide the page numbers from people if you like, but keep a unique, linked URL (e.g. /blog?page=2) under every chunk of content so crawlers can still reach all of it.

Key Takeaways

• Two audiences, two questions. "Do humans need page numbers?" (usually no) is not the same as "Does Google need pages?" (yes, as crawlable URLs).
• Googlebot doesn't scroll or click. Scroll-loaded content with no URL behind it is never seen.
• rel="next"/rel="prev" is dead for Google, confirmed unused since 2019. Use plain <a> links instead.
• Never canonicalize page 2..N to page 1. Each paginated page is self-canonical and indexable.
• Progressive enhancement wins: server-render page 1, expose a crawlable "load more" link, then enhance with JS.
• Load-more is the safest default, keeps the footer reachable, the back button working, and accessibility intact.
• Infinite scroll has real costs: Core Web Vitals (INP/CLS), lost scroll position, unreachable footer.
• Match the pattern to intent: numbered for goal-oriented search/e-commerce, infinite for exploratory feeds.

Quick Facts

Why This Matters

Pagination is where UX and SEO collide most expensively. Get it wrong and the damage is invisible until traffic quietly stalls: the items on "page 2 and beyond", half your products, most of your archive, never get indexed because nothing links to them in a way a crawler can follow. The fix is not to bring back ugly page numbers; it's to understand that the URL layer and the interaction layer are separate concerns. Decouple them and you can give users a modern, number-free experience while giving Google every URL it needs.

The Real Question: Humans vs Googlebot

"We don't need page numbers" is true for the person scrolling. It is false for the crawler, unless you do extra work. These are two independent layers:

• The interaction layer (what humans touch): numbered links, a load-more button, or auto-loading on scroll. Pure UX. Optimise it for your users' intent.
• The URL layer (what crawlers follow): the set of addressable, linked pages that together expose every item. This must exist regardless of which interaction you pick.

The entire art of modern pagination is keeping these two layers in sync, a slick scroll on top, a clean trail of crawlable URLs underneath.

What Google Actually Does With Pagination in 2026

Two facts drive every decision here:

1. rel="next" and rel="prev" are not a Google signal. Google announced in 2019 that it hadn't used these link annotations for indexing "for many years" and treats each page in a series as a standalone page. They're not harmful (Bing and assistive tech may still read them), but they do nothing for Google ranking or discovery. Don't build your strategy on them.

2. Googlebot renders, but it does not interact. Modern Googlebot runs an evergreen Chromium and executes JavaScript, but it loads the page in a very tall viewport and does not fire scroll events, hover, or click buttons. So "load more" content and infinite-scroll batches that depend on a user action simply never load for the crawler. What Googlebot indexes is the rendered HTML of the initial state, plus anything reachable by following <a href> links.

Put those together and the conclusion is blunt: if content isn't in the first render and isn't behind a real link, Google can't see it.

The Three Patterns, Compared

Notice the SEO column: all three can be excellent. The difference is how much engineering it takes to keep the URL layer intact, trivial for numbered and load-more, deliberate work for infinite scroll.

The Infinite-Scroll SEO Trap

Here's the failure mode we see most often. A team replaces pagination with infinite scroll. The first ~10 items render server-side; the rest are fetched by an API call fired on scroll and appended to the DOM. Humans see everything. Googlebot sees the first 10, never scrolls, and indexes a page that links to nothing deeper. Result: items 11 to 10,000 are orphaned, not in the index, not in search, not earning traffic. No error appears anywhere. The page looks perfect to the team because they're humans who scroll.

The same trap catches "load more" buttons wired as pure onClick handlers with no href: a button is not a link, so the crawler has nothing to follow.

The Fix: Crawlable URLs Behind the Scroll

Google's own long-standing recommendation for infinite scroll is progressive enhancement: build a paginated, crawlable structure first, then layer the fancy scrolling on top. Concretely:

1. Server-render the first page so its content and links exist in the initial HTML.
2. Give every batch a real URL, /feed?page=2, /feed?page=3, that returns that batch on its own.
3. Link to the next page with an actual anchor. A "Load more" rendered as <a href="?page=2"> is both the no-JS fallback and the crawler's trail.
4. Enhance with JavaScript: intercept the link / observe a sentinel, fetch the next page, append it, and use the History API to update the address bar so the URL always reflects what's on screen.

Here is the pattern in a Next.js (App Router) listing. The server component renders page 1 plus a crawlable "Load more" link:

// app/feed/page.tsx (Server Component)
export default async function Feed({ searchParams }: { searchParams: { page?: string } }) {
 const page = Math.max(1, Number(searchParams.page ?? 1));
 const { items, hasNext } = await getItems(page); // SSR, in the initial HTML

 return (
 <main>
 <ul id="feed-list">
 {items.map((it) => (
 <li key={it.id}><a href={"/item/" + it.slug}>{it.title}</a></li>
 ))}
 </ul>

 {/* Real, crawlable link, works with JS OFF and gives Googlebot a trail */}
 {hasNext && (
 <a id="load-more" rel="next" href={"/feed?page=" + (page + 1)}>
 Load more
 </a>
 )}
 </main>
 );
}

Then a small client enhancer turns that link into infinite scroll without removing the crawlable fallback:

"use client";
import { useEffect, useRef } from "react";

export function InfiniteEnhancer() {
 const loading = useRef(false);

 useEffect(() => {
 const link = document.getElementById("load-more") as HTMLAnchorElement | null;
 const list = document.getElementById("feed-list");
 if (!link || !list) return;

 const io = new IntersectionObserver(async (entries) => {
 if (!entries[0].isIntersecting || loading.current) return;
 loading.current = true;

 const nextUrl = link.getAttribute("href")!; // "/feed?page=2"
 const res = await fetch(nextUrl, { headers: { "X-Partial": "1" } });
 const { html, nextHref } = await res.json();

 list.insertAdjacentHTML("beforeend", html); // append new items
 if (nextHref) {
 link.setAttribute("href", nextHref); // advance the fallback
 history.pushState({}, "", nextUrl); // keep the URL shareable
 } else {
 link.remove(); // no more pages
 io.disconnect();
 }
 loading.current = false;
 }, { rootMargin: "600px" });

 io.observe(link);
 return () => io.disconnect();
 }, []);

 return null;
}

The crucial detail: the <a href> is never removed for non-JS clients, so Googlebot follows it page by page and discovers every item, while humans get a seamless scroll and a URL that updates as they go. Modern build tools and AI coding assistants make this scaffolding fast to produce; for a sense of how teams ship UIs like this today, see our take on vibe coding vs agentic engineering and the top vibe-coded websites.

Pagination SEO Rules That Still Apply

• Self-canonical every page. /blog?page=3 canonicals to itself, not to /blog.
• Keep deeper pages indexable. No blanket noindex on page 2..N, those items need discovery.
• Use real <a href> links between pages (buttons and onClick are invisible to crawlers).
• Give each page a distinct title/description hint, e.g. append ", Page 2", to avoid duplicate-title warnings.
• Don't block paginated URLs in robots.txt. Blocking discovery is the opposite of what you want.
• Consider a "View all" page when the full set is small enough to load fast; otherwise stick with pagination.
• Stable, clean parameters. Prefer ?page=N consistently; don't mix infinite-scroll offsets that change between loads.

The UX Problems Infinite Scroll Creates

Infinite scroll isn't a free upgrade. Its real-world costs:

• The footer becomes unreachable. Every time the user nears the bottom, more content pushes the footer (contact, links, legal) out of reach. Brutal for sites whose footer carries navigation.
• The back button breaks. Click an item, hit back, and you're dumped at the top instead of where you were, unless you save and restore scroll position.
• No deep linking without the History API, users can't share "the thing I was looking at."
• No sense of progress. "How much is left?" is unanswerable, which is fine for feeds and frustrating for tasks.

Mitigations: prefer load-more when a footer matters; persist and restore scroll position on back-navigation; update the URL via history.pushState; and show a clear end-state when the list is exhausted. These same trade-offs are part of broader interface decisions we cover in factors affecting product design.

Performance and Core Web Vitals

Endlessly appending DOM nodes is a performance tax that shows up directly in Core Web Vitals:

• INP (Interaction to Next Paint): thousands of accumulated nodes bloat memory and lengthen main-thread work, so taps and clicks feel laggy. Fix with list virtualization, render only the rows in view (e.g. a windowing library) and recycle the rest.
• CLS (Cumulative Layout Shift): inserting items without reserved space shoves content around. Reserve height with skeleton placeholders sized to the real content.
• LCP (Largest Contentful Paint): a giant first batch delays the main render. Keep the initial page small and let enhancement do the rest.

Accessibility

A load-more button (or link) is far kinder to assistive tech than auto-loading scroll: it's a real, focusable control the user triggers intentionally. If you ship infinite scroll, you owe these: manage focus so it isn't lost when content appends, announce newly loaded items through an aria-live="polite" region, ensure everything is keyboard-reachable, and provide a path to the footer (a skip link or a load-more fallback). Auto-loading content with no announcement leaves screen-reader users stranded.

Which Pattern Should You Use?

Common Mistakes

• Infinite scroll with no paginated URLs. The classic content-orphaning bug, most of your catalogue never gets indexed.
• "Load more" as a button, not a link. Crawlers can't click; expose an <a href>.
• Canonicalizing page 2..N to page 1. Tells Google the deep pages are duplicates and drops them.
• noindex on paginated pages. Hides the very items you want found.
• Relying on rel=next/prev. Dead for Google since 2019.
• Forgetting the History API. Breaks deep links, sharing, and the back button.
• No virtualization on long lists. Memory and INP degrade as the DOM grows without bound.
• Killing footer access. Infinite scroll on a footer-navigation site frustrates users and hides links.

Why Founders Build With Make An App Like

Founded in 2016, Make An App Like has shipped 500+ apps for founders in 40+ countries, reaches a 50,000+ founder audience through our publishing platform, and has been featured by TechCrunch as a leading partner for non-technical founders. We build SEO-first front-ends where the UX layer and the crawlable URL layer are designed together, so a modern, number-free interface never costs you search traffic.

Estimate Your Build Cost

Planning a listing-heavy site, feed, or marketplace and want a fast, line-item budget? Use our free calculator: https://makeanapplike.com/tools/app-cost-calculator

Launch Faster With a Ready-Made Foundation

Skip months of build time with a white-label app, marketplace, or SaaS foundation that ships SEO-friendly listings out of the box: https://makeanapplike.com/buy-white-label-apps

Conclusion

"We don't need page numbers" is right about the interface and wrong about the plumbing. Hide the numbers, ship infinite scroll or a load-more button, give users the modern experience they expect, but never let the crawlable URL layer disappear underneath. Server-render the first page, link every batch with a real anchor, enhance with JavaScript and the History API, and reserve numbered pagination for the goal-oriented surfaces (search, e-commerce) where users genuinely want it. Do that and you get the best of both worlds: a number-free UI for humans and a complete, discoverable site for Google.

Frequently Asked Questions

1. Do you need pagination for SEO?

You need crawlable, unique URLs for your content, not necessarily visible numbered page links. If a listing has more items than one page can show, each subset must live at a URL Googlebot can reach via a real anchor link (for example /blog?page=2). You can hide the page numbers behind infinite scroll or a load-more button for users, as long as those crawlable URLs still exist underneath.

2. Is infinite scroll bad for SEO?

Infinite scroll is only bad for SEO when the additional content has no crawlable URL. Googlebot does not scroll or click, so anything loaded purely by a scroll event is invisible to it. Infinite scroll backed by paginated, linked URLs (progressive enhancement) is perfectly SEO-friendly; infinite scroll with no underlying pagination silently hides most of your content.

3. Does Google still use rel="next" and rel="prev"?

No. Google confirmed in 2019 that it had not used rel="next"/rel="prev" as an indexing signal for years and treats paginated pages as individual pages. The tags are harmless and other engines (and accessibility tools) may still use them, but you should not rely on them for Google. Focus instead on plain crawlable anchor links between pages.

4. Should page 2 of a list canonicalize to page 1?

No, this is one of the most common and damaging pagination mistakes. Each paginated page should be self-canonical (page 2 points its canonical at page 2). Canonicalizing every page to page 1 tells Google the deeper pages are duplicates, so it drops them from the index and never discovers the items only listed there.

5. Can Googlebot see infinite scroll content?

Only the content present in the initial render. Googlebot renders pages with an evergreen Chromium but uses a tall viewport and does not fire scroll events or click "load more". Content that only appears after a user scrolls is not seen unless you also expose it through paginated URLs or server-render it. Test with the URL Inspection tool's rendered HTML.

6. Infinite scroll vs pagination vs load more, which is best?

It depends on intent. Numbered pagination suits goal-oriented browsing where users compare and return to specific positions (search results, e-commerce category pages). Load-more is a strong default: it gives control and keeps the footer reachable. Infinite scroll fits exploratory, time-killing feeds (social, media). All three should sit on top of crawlable paginated URLs.

7. How do I make infinite scroll SEO-friendly?

Use progressive enhancement: server-render the first page, give every subsequent page a real URL (/feed?page=2) reachable through an anchor link (a "load more" anchor is ideal because it works without JavaScript), then enhance with an IntersectionObserver that fetches and appends the next page and updates the address bar with the History API so the URL is always shareable and the back button works.

8. Should I add noindex to paginated pages?

Generally no. Pages 2..N usually contain unique items you want discovered, so they should be indexable and self-canonical. Adding noindex (or robots disallow) to deeper pages is a frequent mistake that hides products and articles. The exception is genuinely low-value, near-duplicate filter combinations, which you may noindex deliberately.

9. Does infinite scroll hurt Core Web Vitals?

It can. Endlessly appending DOM nodes inflates memory and main-thread work, which degrades Interaction to Next Paint (INP); inserting content without reserved space causes layout shift (CLS); and a heavy first payload can delay Largest Contentful Paint (LCP). Mitigate with list virtualization (render only visible rows), reserved skeleton heights, and a sane initial page size.

10. Is infinite scroll bad for accessibility?

Poorly built infinite scroll is hostile to keyboard and screen-reader users: focus is lost when content appends, the footer becomes unreachable, and there is no clear "more content loaded" announcement. A load-more button is far more accessible, it is a real, focusable control. If you must use infinite scroll, manage focus, announce new content via an ARIA live region, and keep a keyboard-reachable path to the footer.