Google’s documentation on pagination sets three rules for URLs. Each page in a series needs its own URL and its own canonical. Page one must not be the canonical for the whole series. Page numbers must not live in URL fragments, because Google ignores fragment identifiers. None of that requires a site to serve every archive page back to page 900, so a large WordPress site can cap its pagination. That cap can take part of the XML sitemap down with it, because WordPress core sitemaps use the same paged query variable as archive pages.
Google wants one URL and one canonical per page
The three rules sit under one heading, “Use URLs correctly”, in Google’s documentation on pagination and incremental page loading. A ?page=n parameter is the example given, and Google treats such URLs as separate pages. If the link to the next page differs only after the #, Googlebot may not follow it, on the assumption that it has already fetched that page.
The same page tells sites to link each page to the next with ordinary <a href> tags, and suggests linking every page back to the first. Titles and descriptions may repeat across the series. The rel="next" and rel="prev" link elements get one sentence: Google used them in the past and no longer does, although other search engines may still read them.
Deep pagination costs server time and crawl requests, and it is one of the usual causes of wasted crawl budget on large sites. A common answer is a rule that returns 404 for any archive page beyond page N, or redirects it to page one.
WordPress sends sitemap pages through the same paged variable as archives
An archive URL such as /category/news/page/7/ reaches WordPress as a query with paged=7. The rewrite rule that builds it in WP_Rewrite appends &paged= to every page/n/ pattern.
The XML sitemaps built into WordPress core use the same variable. In WP_Sitemaps::register_rewrites(), a URL matching ^wp-sitemap-([a-z]+?)-([a-z\d_-]+?)-(\d+?)\.xml$ is rewritten to index.php?sitemap=$matches[1]&sitemap-subtype=$matches[2]&paged=$matches[3]. The address /wp-sitemap-posts-post-7.xml therefore arrives as sitemap=posts, sitemap-subtype=post and paged=7, exactly the page number an archive would carry. A second rule, ^wp-sitemap-([a-z]+?)-(\d+?)\.xml$, does the same for sitemaps without a subtype, such as the user sitemap.
WordPress sets is_paged() to true whenever paged is greater than one. To get_query_var( 'paged' ) and is_paged(), page seven of the post sitemap looks just like page seven of the news archive.
How a pagination cap makes WordPress sitemap files return 404
Each sitemap file holds at most 2,000 URLs by default. The figure comes from wp_sitemaps_get_max_urls(), which passes 2,000 through the wp_sitemaps_max_urls filter. A post type with 30,000 published posts is split across 15 files.
Now add a cap that sends a 404 for anything with paged above 5. Archive pages 6 and up disappear, as intended. Sitemap files 6 to 15 disappear too, and with them 20,000 post URLs. Posts in core sitemaps are sorted by ID in ascending order, so the files that vanish are the ones holding the highest post IDs, usually the most recently created posts.
The site itself gives no sign of the problem. Every post still loads, the archives behave as designed, and the sitemap index at /wp-sitemap.xml still lists all 15 files, because the index is built from the number of posts rather than from fetching the files. The failure is visible only when someone requests one of the higher-numbered files or reads the sitemap report in Search Console.
Whether the cap reaches the sitemap depends on when it runs. Core renders sitemaps in WP_Sitemaps::render_sitemaps(), hooked to template_redirect at the default priority of 10 and registered during init. Plugins and the theme’s functions.php load before init. A cap hooked to template_redirect at priority 10 or lower is therefore called before the sitemap renderer, and so is a cap on an earlier hook such as wp. If that cap sends a 404 or a redirect and ends the request, the sitemap never gets rendered.
WordPress core already exempts its own sitemaps
redirect_canonical(), which rewrites paginated URLs into their canonical form, tests get_query_var( 'sitemap' ) first and builds a sitemap URL in that case, before its general paged logic runs. render_sitemaps() does nothing unless the sitemap query variable is set or, in released versions of WordPress, the stylesheet query variable.
The sitemap rewrite rules set sitemap on the index and on every XML sitemap file, and an ordinary archive request never sets it. A cap that returns early on that variable leaves sitemaps alone:
add_action( 'template_redirect', function () {
// Core sitemaps reuse 'paged'. Leave them alone.
if ( get_query_var( 'sitemap' ) ) {
return;
}
$max_page = 50;
if ( is_paged() && (int) get_query_var( 'paged' ) > $max_page ) {
global $wp_query;
$wp_query->set_404();
status_header( 404 );
nocache_headers();
}
}, 9 );The variable exists on every WordPress version that ships core sitemaps, which arrived in 5.5. The same guard belongs in any pre_get_posts callback that changes paged on the main query, since render_sitemaps() reads the page number from that query.
Moving the cap to a priority above 10 also protects sitemaps, because render_sitemaps() exits after a successful render. That protection depends on hook order rather than on the request itself, and it disappears if someone later moves the cap to priority 10 or lower. The explicit check works at any priority.
How to test whether a pagination cap breaks the WordPress sitemap
Open /wp-sitemap.xml and note the highest-numbered file for the largest post type. Then request that file directly. A 200 response with a list of URLs means the cap leaves sitemaps alone. A 404, or a redirect to an archive, means the cap has caught the sitemap.
Raising wp_sitemaps_max_urls reduces the number of sitemap files and can push the problem past the cap for a while. It does not remove the overlap, which returns once a post type has more posts than the cap times the new limit per file: 50,000 posts with a cap at page 5 and 10,000 URLs per file.
Older posts need another route in once pagination is capped
Capping pagination is a reasonable choice once deep archive pages stop earning their crawl requests. The cap also cuts the internal links that lead to older posts, so those posts need another route in: hub pages and related links built into the information architecture of a large site and its site structure, and a working sitemap. On WordPress, the sitemap keeps working when the cap returns early for requests that set the sitemap query variable.
Last fact-checked: 24 October 2026