Pagination SEO: A Practical Guide
How to handle paginated pages, rel=next/prev, indexing decisions and infinite scroll so a series of listing pages doesn't compete against itself.
Pagination SEO is how you let search engines crawl and index a series of listing pages — page 2, page 3, and beyond — without those pages competing against each other or getting missed entirely. The current approach is simple: each page self-canonicalizes, the series links with plain visible links, and every page has a real, crawlable URL.
Getting this wrong quietly removes catalog and article pages from search, which is why it belongs on the technical SEO checklist alongside redirects and canonicals, rather than being treated as a minor template detail nobody revisits.
في هذه الصفحة
Does Google still use rel=next/prev for pagination?
No. Google confirmed years ago it no longer uses those tags to understand a paginated series, and treats each page in a series as its own standalone URL to be crawled and indexed on its own merits. Adding the tags doesn't hurt, but relying on them to signal anything about pagination no longer works.
What actually matters now is more basic: each page needs a real, unique, crawlable URL, and the pages need to be linked to each other with plain HTML links a crawler can follow — not a page number that only appears after a script runs.
This is a smaller change than it sounds, but it trips up sites that built their pagination years ago around the old assumption. If your templates still emit rel=next and rel=prev, there's no need to rip them out; they're simply not doing any work anymore. The thing worth checking is what they were added instead of — teams that implemented rel=next/prev often skipped giving each page its own self-canonical, on the reasoning that the pagination tags handled the relationship. They don't, and haven't for years, which leaves exactly the duplicate-content risk pagination handling was meant to prevent.
| Then | Now |
|---|---|
| rel=next / rel=prev tags | Each page self-canonicalizes; the tags are optional and inert |
| Canonicalizing all pages to page 1 | Each page keeps its own canonical unless it's a true duplicate |
| Hiding pagination behind JavaScript | Real crawlable links to each page, independent of script execution |
Should paginated pages be indexed, noindexed, or canonicalized to page 1?
Indexed, in most cases. Page 2 of a product listing contains different products than page 1; canonicalizing it to page 1 tells search engines those different products don't exist as a separate, indexable unit, which is rarely what you want for a catalog you're trying to get found in search.
The instinct to canonicalize every page to page 1 usually comes from a reasonable worry about thin or repetitive content, and it is the wrong fix for that worry. A listing page that shows real, distinct items is not thin just because it shares a template and a sidebar with every other page in the series — the products, articles or listings on it are the content, and canonicalizing them away removes them from search entirely rather than fixing whatever made them feel thin.
A simpler heuristic than picking an exact cutoff page number: check whether the page still ranks or receives any clicks at all once it has been indexed for a few weeks. A deep page that never earns an impression is a reasonable noindex candidate regardless of its page number; a deep page that does get found is evidence the cutoff was set too aggressively.
How should paginated URLs appear in the XML sitemap?
Every genuinely indexable page in the series belongs in the XML sitemap the same as any other page — page 2, page 3 and beyond, using their real canonical URLs. Leaving paginated pages out of the sitemap doesn't stop them from being indexed, it just removes one of the signals that helps a crawler find and prioritize them.
A common mistake is generating the sitemap only from a CMS's "primary content" list, which frequently excludes anything with a ?page= parameter by default. Check the sitemap generation logic specifically for paginated URLs rather than assuming it covers them because it covers everything else.
There is a reasonable judgment call at the deep end of a series: once a listing runs past several dozen pages, including every single one in the sitemap adds volume without much benefit, since a crawler is unlikely to prioritize page 90 of a sort order nobody uses. Including the first several pages of any series and letting the rest be found through normal internal linking is a fair compromise, as long as the pages you do exclude are still reachable by a link somewhere, not orphaned entirely.
What about infinite scroll — does it need special handling?
Yes. Infinite scroll that only loads new items as JavaScript detects a scroll event, with no underlying page-number URL, is invisible to a crawler that doesn't simulate scrolling all the way down. The items past whatever loads on first paint may never be crawled at all.
This is worth taking seriously even for sites that render JavaScript-heavy pages successfully elsewhere. A crawler that can execute JavaScript is not the same as a crawler that will patiently scroll a page dozens of times to load everything — most crawls budget a fixed amount of time and interaction per page, and an infinite-scroll listing that needs fifteen scroll events to reveal its last item is likely to be abandoned well before then.
Give every batch of loaded items its own URL
As the visitor scrolls, update the URL to a real, addressable page — history.pushState with a real path, not just a hash fragment.
Make that URL work when requested directly
A crawler, or a visitor who bookmarks or shares the URL, should get the same content back on a direct request, not just via the scroll interaction.
Keep a traditional paginated fallback reachable
A 'load more' or numbered pagination link that works without JavaScript is the simplest way to guarantee every item is reachable by a crawler.
How do you fix pagination after a URL structure or redirect change?
Carefully, and all at once. If page 1 of a series moves and gets a 301 redirect to a new URL, every later page in that series usually needs the equivalent redirect too — ?page=2 under the old structure has to map to ?page=2 under the new one, not silently break because only page 1 was accounted for in the migration plan.
This gets missed constantly because migration checklists tend to test page 1 of every section and assume the pattern holds. Test at least one deep page per paginated section specifically, and check that its Core Web Vitals didn't regress either — the Core Web Vitals guide covers how a template change can quietly worsen loading performance across an entire paginated section at once, not just the page that was directly edited.
Once the pattern-based redirect is live, spot-check pages from several points in the series rather than only the ones nearest the front. A rule that works correctly for page 2 can still fail for page 200 if it makes an assumption — a maximum page count, a specific number format — that only breaks at the far end of a long series, and that kind of failure is exactly the one a quick front-of-series check will never catch.
أسئلة يطرحها الناس
Does Google still use rel=next and rel=prev?
No. Google stopped using those tags to understand paginated series years ago. They no longer hurt to include, but they no longer help either — treat each paginated page as it own self-canonicalizing URL instead.
Should page 2, 3 and beyond be indexed?
Usually yes, if they contain genuinely different items and could reasonably answer a search on their own. Noindexing every page past page one just removes those items from search entirely.
Does infinite scroll need pagination at all?
Yes, underneath it. Infinite scroll needs to load real, individually addressable URLs as the visitor scrolls, or a crawler that doesn't run the scroll interaction will only ever see the first batch of items.
Can I noindex pages past a certain page number?
You can, and it's reasonable past a point where pages are thin or rarely reached — page 40 of a listing, for example. There's no fixed cutoff; judge it by whether the page still contains anything worth ranking.
المصادر
- Consolidate duplicate URLs — Google Search Central (checked 22 September 2026)
- <link>: The External Resource Link element — MDN Web Docs (checked 22 September 2026)
Get your paginated pages checked before they quietly disappear from search
احجز استشارة مجانية مدتها 30 دقيقة مع إبراهيم وجيريمي. ننظر في موقعك أثناء الحديث، وتخرج بخطة مرتّبة حسب الأولوية.
من كتب هذا
Jeremy ZavaCo-founder
Leads growth and client partnerships.
يعمل على: CRO, SEO
راجعه قبل النشر Ibrahem Helal، Co-founder.
المزيد عن هذا
- Technical SEO: the complete checklist for 2026Technical SEO makes sure search engines and AI crawlers can reach, render and index your pages. This checklist covers every layer, in the order to fix it.
- XML Sitemaps: How to Get Them RightAn XML sitemap lists the URLs worth crawling. Get the format, the sitemap index and the submission step right, or search engines mostly ignore it.
- 301 Redirects for SEO: What to Get RightA 301 redirect passes most ranking signal to its target when the target is the closest live match. Chains and lazy homepage redirects throw that signal away.
- Core Web Vitals: how to fix LCP, INP and CLSPass Core Web Vitals by fixing field data, not lab scores: find the slow template, fix LCP, INP and CLS in that order, then wait 28 days to confirm.