Sitemap Re-submission Strategies

Context

Sitemaps are how you tell Google the new URL set exists all at once, instead of waiting for it to rediscover the site link by link. After a domain change the sitemap step is deceptively easy to get wrong: teams delete the legacy sitemap immediately (starving redirect discovery), submit a sitemap full of old URLs under the new property, or forget the sitemap index file that ties large sites together. This page sits in the discovery half of the Search Console Handover and defines a clean re-submission workflow. SEO engineers run it right after the new property is verified and the Change of Address is filed.

Done correctly, the new sitemap accelerates the indexing curve you monitor in Index Coverage Handoff; done wrong, it injects redirect and canonical errors that take weeks to drain.

Submit the sitemap index; Google fetches each per-section child sitemap beneath it.

A sitemap is a discovery aid, not an instruction. It tells a crawler which URLs you consider canonical and worth visiting; it does not compel indexing, override a robots.txt directive, or rescue a page the crawler has judged low quality. Getting that distinction right shapes everything below, because most sitemap disappointment comes from expecting it to do work that belongs to redirects, canonicals, or content.

What it does do, and does uniquely well during a migration, is accelerate discovery of an estate the crawler has never seen. That is worth a great deal in week one, when several thousand new URLs exist and nothing links to most of them from outside your own domain. It is also why the legacy sitemap matters just as much: it keeps the crawler returning to old URLs so it finds their redirects, which is the mechanism by which those URLs eventually leave the index.

The two sitemaps therefore serve opposite purposes at the same time — one accelerating entry, one accelerating exit — and both need to be live and submitted for the duration of the crossover. Retiring the legacy sitemap early is a common instinct and it slows the migration measurably, because the old URLs then get re-crawled only when the crawler happens to reach them.

Pre-flight Checks

Confirm each of these before submitting anything, since a sitemap submitted with errors records those errors against the file and colours how promptly the rest of it is read.

New property verified per Property Verification Methods
Sitemaps regenerated to contain only new-domain canonical URLs (no legacy hostnames)
All sitemap URLs return 200 on the new domain, not 301 or 404
A sitemap index file in place if the site exceeds 50,000 URLs or 50 MB per file
The legacy sitemap confirmed still reachable and returning 200

Execution Steps

1. Regenerate Sitemaps for the New Domain

Build the file from the new site’s own routing rather than transforming the old one, so its contents describe what exists rather than what used to. The diff against the value-tiered inventory afterwards is the check that matters — it is the only thing that catches a whole section missing, which no validator will flag because a sitemap with a section absent is perfectly well-formed. Rebuild the XML so every <loc> is a new-domain canonical URL — a sitemap listing redirecting or legacy URLs sends mixed signals. Validate the file against the sitemap schema and confirm lastmod reflects the migration date. Keep entries to canonical, indexable, 200-responding URLs only.

Regenerate from the new estate rather than rewriting the old file. A find-and-replace across the legacy XML preserves every URL that should no longer exist — including everything you deliberately retired — and submitting that invites the crawler to spend budget confirming a few thousand 410s while your new pages wait. Generate afresh, then diff the result against the value-tiered inventory to confirm the top tiers are all present; a sitemap silently missing your highest-value section is common and produces no error anywhere.

Include only canonical, indexable, 200-returning URLs. Every entry that redirects, 404s, or carries a canonical pointing elsewhere is a small deduction from how much the crawler trusts the file, and at scale that trust is the thing determining how promptly the rest of it gets read. Run the batch status check before submitting rather than after.

2. Structure a Sitemap Index for Large Sites

An index file is required past the format limits and useful well before them, because it is what lets the coverage report attribute problems to a part of the estate you recognise. If the site exceeds the 50,000-URL or 50 MB per-file limit, split into multiple sitemaps referenced by a single sitemap index, and submit the index. Segmenting by section (products, articles, categories) also makes the per-segment indexing rate visible in the Pages report, which sharpens the monitoring in Index Coverage Handoff.

Split by section rather than by arbitrary shards. The format limits — fifty thousand URLs or fifty megabytes uncompressed per file — mean large estates need an index either way, and the choice of how to divide them determines how useful the coverage report will be. Per-section files let Search Console attribute problems to something you recognise: “the products sitemap is 12% unindexed” is actionable in a way that “sitemap-7 is 12% unindexed” is not.

That attribution is the main practical benefit and it compounds during a migration, when the question is constantly which part of the estate is lagging. Keep the section boundaries aligned with your value tiers where you can, so the report answers the prioritisation question directly.

3. Submit the New Sitemap and Keep the Legacy One Live

Submit the new domain’s sitemap (or index) under the new property. Critically, leave the legacy sitemap reachable and submitted under the legacy property so Google re-crawls old URLs and discovers their 301s, driving deindexing. Removing it early slows the deindex side of the migration tracked in your URL Mapping & Redirect Architecture checks.

Submit the new sitemap on launch day, not before. Submitting while the new URLs still return 404 or redirect to the legacy site tells the crawler your canonical list is wrong, and those errors are recorded against the file — so the first impression it forms of your new estate is of an inventory that does not resolve. Wait until the cutover is complete and the batch audit returns clean, then submit once.

Keep the legacy sitemap submitted in the legacy property at the same time. This is the step people skip because it feels contradictory, and it is doing genuine work: the crawler uses that file to return to old URLs, encounters the 301, and processes the deindexing. Nothing else drives that as reliably, and on a deep archive nothing else drives it at all within a useful timeframe.

4. Run the Ping / Resubmit Workflow

After submission, confirm the report shows “Success” with the expected discovered-URL count. If you ship sitemap changes during the migration, re-submit through the same flow rather than creating duplicate entries. Reference the sitemap in robots.txt so crawlers outside Search Console find it too.

Reference the sitemap from robots.txt as well as submitting it, using an absolute URL. Submission covers the search engines whose consoles you use; the robots.txt reference covers everything else that crawls the site, which during a migration includes several tools you may want to find the new URLs promptly. It costs one line and it is the only discovery mechanism available to crawlers you have no account with.

Resist re-submitting repeatedly as a way to hurry things along. Re-submission re-queues the file for processing; it does not raise the priority of the URLs inside it, and doing it daily achieves nothing beyond adding noise to the report’s history. Submit once, confirm the file was read successfully, and then leave it alone unless the contents genuinely change.

5. Retire the Legacy Sitemap on Confirmation

This is the last step of the handover and the one most often taken early. Wait for the evidence described below rather than for the technical work to feel finished — the two are separated by several weeks on most estates, and there is no cost to waiting. Only once the legacy URLs have largely deindexed and the new URLs are indexed do you remove the old sitemap. Premature removal is a common cause of stalled deindexing; align the timing with the coverage thresholds before retiring it.

The two sitemaps do opposite jobs during the crossover, which is why the instinct to retire the legacy one early is so costly.

The right-hand box is the counter-intuitive one — a sitemap full of URLs you want removed from the index is exactly what speeds their removal.

Configs / Commands

The fragments below cover the index structure, the discovery reference, and the pre-submission audit. Run the audit before every submission rather than only the first: a sitemap that was clean at launch drifts as the site changes, and each redirecting or missing URL inside it is a small deduction from how promptly the rest of the file gets read.

Minimal sitemap index referencing per-section sitemaps:

<!-- Submit THIS index file; each child holds up to 50,000 URLs -->
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap><loc>https://newdomain.example/sitemap-products.xml</loc></sitemap>
  <sitemap><loc>https://newdomain.example/sitemap-articles.xml</loc></sitemap>
</sitemapindex>

Reference the sitemap in robots.txt for crawler discovery:

# Absolute URL required; place at the end of robots.txt
Sitemap: https://newdomain.example/sitemap-index.xml

Audit every sitemap URL returns 200, not a redirect (batch check):

# Extract <loc> values and flag any non-200 response before submitting
curl -s https://newdomain.example/sitemap-articles.xml \
  | grep -oP '(?<=<loc>)[^<]+' \
  | while read -r u; do echo "$(curl -s -o /dev/null -w '%{http_code}' "$u") $u"; done

How you split a large estate determines how useful the coverage report will be for the rest of the migration.

Both files are valid and contain identical URLs. Only one of them makes the coverage report worth reading during a migration.

The submission mechanics after a host change are set out step by step in Resubmitting Sitemaps After a Domain Change; if the estate is large enough that one indexed count tells you nothing, split it first using Splitting Large Sitemaps for Faster Recrawl.

Validation

Run these against the live files rather than against the generator’s output; the failure modes worth catching — a stale cached copy, a compression setting the crawler cannot read, a path that 404s in production — all occur between generation and delivery.

New sitemap shows “Success”, with discovered URLs matching the expected count
Every <loc> returns HTTP 200 on the new domain (no 301/404 in the batch check)
curl -s https://newdomain.example/robots.txt | grep Sitemap returns the absolute sitemap URL
The legacy sitemap still returns 200 and remains submitted under the legacy property
Sitemap index resolves and each child sitemap is reachable

Retire the legacy sitemap on evidence rather than on a date. The signal to watch is the legacy property’s coverage report showing its URLs have moved into the “Page with redirect” state at scale — that is confirmation the file has done its job. Removing it earlier strands whatever remains; leaving it longer costs nothing beyond an entry in a report you are already reading, which is why erring towards later is the right instinct here.

When you do retire it, remove the submission and let the file 404 rather than redirecting it to the new sitemap. A redirected sitemap is ambiguous — it suggests the legacy inventory has moved wholesale to the new location, which is not what happened — while a clean 404 on a file you have deliberately withdrawn is unambiguous and produces no lingering coverage entries.

Rollback Triggers

Sitemap status “Couldn’t fetch” persists beyond 48 hours → check origin/CDN and robots.txt
More than 5% of <loc> URLs return non-200 → regenerate before re-submitting
Discovered URL count is far below expected → the sitemap is truncated or malformed; rebuild
Legacy deindexing stalls after the old sitemap was removed → re-submit the legacy sitemap

One broader point about expectations. None of the work on this page makes indexing happen; all of it makes discovery faster and the resulting coverage data more legible. A migration with excellent sitemaps and broken canonicals will not index well, and a migration with sound redirects and canonicals will eventually index acceptably even with a mediocre sitemap. The reason to do this properly is that it compresses weeks into days at the point where compression is most valuable, and it gives you a per-section view of what is lagging — not because the file itself carries any authority.

FAQ

Should I delete the old sitemap right after the move? No. Keep it reachable and submitted under the legacy property so Google re-crawls the old URLs and finds their 301s, which is what drives deindexing. Remove it only after legacy URLs have largely left the index.

Do I submit individual sitemaps or the sitemap index? Submit the sitemap index when the site exceeds the 50,000-URL or 50 MB per-file limit — Google reads the index and fetches each child. For small sites a single sitemap is enough.

How often should I re-submit during a migration? Submit once after launch, then re-submit only when the sitemap content materially changes. Re-submitting an unchanged sitemap repeatedly does not speed up crawling and can muddy the report.

Can the new sitemap include redirecting URLs? No. Every <loc> must be a final, 200-responding canonical URL on the new domain. Listing redirecting or legacy URLs injects “Page with redirect” errors into the coverage report.

How often should the sitemap be regenerated after launch? On whatever cadence the estate actually changes — nightly for an active catalogue or publisher, weekly for a slower site — and automatically rather than by hand. The value is in the file staying true: a sitemap that still lists URLs retired a month ago, or omits a section added last week, gradually stops being a reliable signal and starts being a source of coverage errors attributed to you. Automate generation as part of the build so it cannot drift, and treat a sitemap that has not changed since launch on a site that has as a defect.

What should the lastmod value contain, and does it matter? It should reflect a genuine content change, and it matters more than most people expect. A lastmod that updates on every build regardless of whether the page changed teaches the crawler that the field carries no information, after which it is ignored entirely — including on the occasions when something really did change. Set it from the content’s own modification timestamp, leave it alone when only the template changed, and it remains a useful hint for prioritising re-crawls.

Should retired URLs appear in a sitemap at all? Not in the new site’s sitemap, and only in the legacy one for as long as that file is doing its deindexing job. Once the legacy tail has drained, both the file and the URLs go. What should never happen is retired URLs appearing in the new estate’s sitemap — that is an explicit statement that you consider them canonical and worth crawling, which contradicts the 410 or redirect you are simultaneously serving, and mixed signals of that kind slow everything down.

Does splitting into more files make the crawler read them faster? No. The number of files affects organisation and diagnosis, not crawl rate — a hundred small sitemaps are read no faster than four large ones, and the extra fragmentation makes the coverage report harder to interpret rather than easier. Split when the format limits require it or when a section boundary would make the report more useful, and not otherwise.

← Back to Search Console Handover