Official statement
Other statements from this video 43 ▾
- 2:22 What should you do if your site lost traffic after a Core Update without making any mistakes?
- 2:22 Are Core Web Vitals Really Going to Transform Your SEO Strategy?
- 3:50 Does a ranking drop after a Core Update really indicate an issue with your site?
- 3:50 Should You Really Wait Before Optimizing Core Web Vitals?
- 3:50 Why is Google delaying the complete transition to the Mobile-First Index?
- 7:07 Can Google really delay Mobile-First Indexing indefinitely?
- 11:00 Why doesn't Google canonicalize URLs with fragments in sitelinks and rich results?
- 11:00 Do URLs with fragments (#) in Search Console mean you need to rethink your tracking and analysis strategy?
- 14:34 Why do the numbers from Analytics, Search Console, and My Business never match?
- 14:35 Why do your Google metrics never align between Search Console, Analytics, and Business Profile?
- 16:37 How are FAQ clicks really counted in Search Console?
- 18:44 Are mobile and desktop accordions really neutral for SEO?
- 18:44 Is it true that mobile accordion hidden content is indexed as visible content?
- 29:45 Does the rel=canonical via HTTP header really still work?
- 30:09 Does the HTTP header rel=canonical really work to manage duplicate content?
- 31:00 Why does Search Console still show 'PC Googlebot' on recent sites when Mobile-First Index is supposed to be the standard?
- 31:02 Is it true that all sites indexed after July 2019 default to Mobile-First Indexing?
- 33:28 Why does Google emphasize textual context in Search Console feedback?
- 33:31 Are Search Console tools really enough to solve your indexing problems?
- 33:59 Why are your pages still not indexed after 60 days in Search Console?
- 37:24 What happens when Google occasionally indexes HTTP instead of HTTPS even after an SSL migration?
- 37:53 Is it really necessary to combine both 301 redirections AND canonical tags for an HTTPS migration?
- 39:16 What really causes your sitemap to fail in Search Console and how can you effectively resolve the issue?
- 41:29 Is your brand disappearing from the SERPs for no apparent reason: can Google feedback really fix it?
- 44:07 Should you choose a subdomain or a new domain for launching a service?
- 44:34 Subdomain or New Domain: What Does Google Really Think for SEO?
- 44:34 Do Google penalties really transfer between domains and subdomains?
- 45:27 Do Google penalties really spread between domains and subdomains?
- 48:24 Should you really overlook PageRank when deciding between a domain and a subdomain?
- 48:33 Do links between root domains and subdomains really pass PageRank?
- 49:58 Should you really be worried about duplicate content from scraping?
- 50:14 Can you relaunch an old domain without being penalized for duplicate content by spammers?
- 50:14 Should you really report every scraping URL via the Spam Report to prompt action from Google?
- 57:15 Is it really necessary to report spam URL by URL to assist Google?
- 58:57 Why does Google refuse to show your FAQs in rich results despite perfect markup?
- 59:54 Why doesn't Google display your FAQ rich results even with perfect markup?
- 65:15 Is it possible to add FAQs to your pages just to secure rich results in SEO?
- 65:45 Can you really add a FAQ just to get the rich result without risking penalties?
- 67:27 Should you still optimize rel=next/prev tags for pagination?
- 70:10 Should you really index all category pages to optimize your crawl budget?
- 70:18 Should you really stop placing category pages in noindex?
- 72:04 Does the number of JavaScript files really slow down Google indexing?
- 72:24 Does Googlebot really render all JavaScript in a single pass?
Google states that it's not necessary to submit the entirety of paginated pages (page 2, 3, 100…) in the XML sitemap for large sites. With the rel=next/prev attribute being abandoned, Google can handle pagination on its own without a specific signal. In practice, a streamlined sitemap focused on strategic pages is sufficient — but be careful about crawl budget and the actual indexing of deep pages.
What you need to understand
Why does Google believe that not all paginated pages deserve a spot in the sitemap?
Pagination often generates hundreds or even thousands of URLs on large e-commerce sites or directories. Submitting page=1 to page=547 in the XML sitemap creates a massive, complex file that can be difficult to maintain and potentially counterproductive.
Google assumes that if page 1 is discovered, the bot will follow the internal links to page 2, 3, etc. Therefore, the sitemap does not need to serve as an exhaustive list — it should highlight the strategic URLs you want to index first.
What has changed with the end of rel=next/prev?
Until March 2019, Google recommended the rel=next/prev attribute to explicitly signal paginated series. This signal has been abandoned as Google claimed to detect it automatically in 99% of cases.
Since then, no specific markup is required. Each paginated page is processed individually by the algorithm, without automatic grouping under a common canonical URL. It is up to you to decide whether page=2 deserves indexing or not.
Which pages are considered important?
Google does not provide an exhaustive list, but the idea is clear: prioritize unique and high-value content. Product pages, blog articles, strategic landing pages — anything that drives organic traffic or conversions.
Intermediate paginated pages (page 12 of 87) rarely bring unique SEO value. They often duplicate the same filters, the same template, with just a different list of items. Unless for specific cases (e.g., page 2 ranking on a specific long tail), their indexing is not a priority.
- Only submit strategic pages: flagship products, main categories, editorial content
- Let the bot discover pagination through typical internal linking
- Monitor actual indexing with Google Search Console to ensure important pages are indeed crawled
- Avoid giant XML sitemaps that dilute the signal and complicate maintenance
- No worries if page=2 isn’t in the sitemap — Google will find it if it's linked from page=1
SEO Expert opinion
Is this statement consistent with observed practices in the field?
Yes and no. On well-linked sites with a correct crawl budget, Google indeed discovers paginated pages without issue. Server logs show that Googlebot naturally follows links from page=1 → page=2 → page=3.
However, on sites with a constrained crawl budget (millions of pages, complex architecture, slow response times), deep paginated pages are never visited if they do not appear in the sitemap. [To Verify] if your site exceeds 100k indexable pages — the absence of a sitemap can drastically slow down discovery.
In what cases does this rule not apply?
If your paginated pages have unique and rankable content, excluding them from the sitemap is a mistake. A classic example: a forum with specific discussions per page, or a classifieds site where each page=X targets a different search intent.
Similarly, if your pagination uses client-side JavaScript without HTML fallback, Google may struggle to discover subsequent pages. In this case, the sitemap becomes essential to guarantee indexing — even if Google claims to manage without it.
What nuances should be added to this recommendation?
Google says "important pages," but does not define the criteria. An e-commerce site with 10,000 products spread across 500 category pages: should you submit only page=1, or page=1 to page=10? No official answer.
My field opinion: if a paginated page generates documented organic traffic (via Search Console), it deserves to be in the sitemap. Otherwise, focus on content hubs (page=1 of categories, product sheets) and leave the rest to natural crawling.
Practical impact and recommendations
What concrete steps should you take to optimize your XML sitemap?
Audit your current sitemap: how many paginated pages are submitted, and how many are truly indexed? If you have 5,000 URLs page=X in the sitemap but only 200 are indexed, that’s unnecessary noise.
Reduce the sitemap to strategic pages: main categories, flagship products, editorial content. For pagination, keep page=1 consistently — and possibly page=2 to page=5 if they generate identifiable traffic in Search Console.
How do you verify that important pages are crawled without the sitemap?
Cross-reference data from Google Search Console (coverage report, indexed pages) with your server logs. If a strategic page never appears in Googlebot logs, it is not being discovered — add it to the sitemap.
Use the URL Inspection tool in Search Console to force a one-time crawl of a critical paginated page. If Google rejects it or marks it as "Detected, currently not indexed," dig into the reasons: duplicated content, incorrect canonical, blocking robots.txt.
What mistakes should you absolutely avoid?
Do not abruptly remove all paginated pages from the sitemap without analyzing their real SEO contribution. Some pages=X rank on specific long tails — removing them could drastically reduce traffic.
Avoid submitting URLs with multiple parameters (page=2&sort=price&filter=brand): Google often sees them as duplicate content. Prefer canonical pagination URLs, without unnecessary filters.
- Audit the current sitemap: ratio of submitted URLs / indexed URLs
- Identify paginated pages generating organic traffic via Search Console
- Keep page=1 of each paginated series in the sitemap
- Exclude deeper paginated pages without unique SEO value
- Monitor server logs to verify the real crawl of important pages
- Test indexing via URL Inspection on a sample of excluded pages
❓ Frequently Asked Questions
Dois-je supprimer toutes les pages paginées de mon sitemap XML ?
Google crawle-t-il automatiquement les pages 2, 3, 4… si elles ne sont pas dans le sitemap ?
L'attribut rel=next/prev est-il encore utile en SEO ?
Comment savoir si une page paginée mérite d'être dans le sitemap ?
Peut-on utiliser une balise canonical sur les pages paginées pour les regrouper ?
🎥 From the same video 43
Other SEO insights extracted from this same Google Search Central video · duration 1h14 · published on 04/06/2020
🎥 Watch the full video on YouTube →
💬 Comments (0)
Be the first to comment.