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.

Sitemap index structure A single sitemap index references per-section child sitemaps; both old and new sitemaps stay submitted during the move. Sitemap Index Structure sitemap-index.xml submit THIS file sitemap-products.xml sitemap-articles.xml sitemap-categories.xml ≤ 50,000 URLs ≤ 50,000 URLs ≤ 50,000 URLs
Submit the sitemap index; Google fetches each per-section child sitemap beneath it.

Pre-flight Checks

  • 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

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.

2. Structure a Sitemap Index for Large Sites

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.

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.

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.

5. Retire the Legacy Sitemap on Confirmation

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.

Configs / Commands

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

Validation

  • 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

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

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.

Related

← Back to Search Console Handover