Splitting a sitemap only changes what Search Console reports

A WordPress team planning to move a set of high-value landing pages out of the site root into a /products/ custom post type asked r/TechSEO whether a dedicated product-sitemap.xml would get the moved pages re-indexed faster. The poster put that file first on the list of objectives. The question was whether anyone who had split core pages out of one monolithic page-sitemap.xml saw clearer diagnostics or faster re-indexation in Search Console.

Splitting the file changes what Search Console reports back, and that is all it changes. The indexing report can be filtered by submitted sitemap, so the moved pages get their own coverage numbers instead of being averaged in with every other page on the site. That is worth having during a migration. The split is not a crawl lever: the same URLs are being declared, with the same timestamps, to the same crawler, and a second XML file does not tell Google that this group matters more. Google’s own John Mueller would not confirm that splitting sitemaps changes crawling when asked about splits by page age. Budgeting recovery time against sitemap structure sets the wrong expectation.

The levers are already in the team’s own plan. A 301 from every old root URL to its new path is what carries the ranking signals across. Internal links rewritten to the new paths, which the poster plans to find with Screaming Frog, tell Google which URL is now the real one and stop the site from spending crawls on hops. External links on domains the team controls, repointed to the new URLs, remove one more hop each. How fast the pages come back follows from how completely those three are done and how quickly Google recrawls, and Google’s published timing ranges for site moves are a better input to a recovery estimate than anything in the sitemap plan.

The thread drew one reply. A commenter, u/BusyBusinessPromos, wrote that none of it makes sense if the pages are already indexed, and that there are many ways to organize files in the root using links. That is too blunt as a rule, because a hierarchy that matches how a site is actually built pays off over years of adding pages to it. It does land on the gap in the plan. The plan names two other things the restructure is meant to deliver: a /products/ archive page that WordPress generates when has_archive is on, and Product or Service JSON-LD. The markup does not need the URLs to move. It can go on the pages where they sit today. Taken together, the decision worth making before running the Post Type Switcher plugin is narrower than the plan implies: whether a /products/ hub and a cleaner path are worth putting established, indexed pages through a redirect, given that the reporting and the schema are both available without moving anything.

What to do

• Write each 301 to the exact URL WordPress will serve, trailing slash included. A redirect that lands on a URL WordPress then canonicalizes gives every crawler two hops instead of one, which is the loop risk the poster asked about.
• Confirm the old root URLs stop returning 200 once the post type switches. A conversion that leaves the old path resolving alongside the new one creates duplicates rather than redirects.
• Crawl the new structure on staging before it goes live, and validate the staging site in Search Console, so the redirect map and the link rewrites are checked against a real crawl instead of a spreadsheet.
• Keep the separate sitemap. Watch the indexing report through it after the switch, and read a slow curve as a reason to re-audit redirects and internal links, not as a reason to resubmit the file.