Resubmitting Sitemaps After a Domain Change

Problem Statement

The new domain is live, the redirects are in place, and the obvious next move is to submit a sitemap of the new URLs and delete the old one. Deleting the old one is the mistake. A sitemap of legacy URLs is the fastest way to get a crawler to re-request every old path and discover its 301 — remove it and you are waiting for organic re-crawl of URLs that may not be revisited for weeks. This page sits under Sitemap Re-submission Strategies.

Two sitemaps running in parallel after a domain change The legacy sitemap continues to advertise old URLs so their redirects are discovered, while the new sitemap advertises the destination URLs; both are submitted until legacy discovery completes. Both Sitemaps Stay Live Legacy sitemap old URLs, still listed New sitemap destination URLs Crawler re-requests sees 301, follows it Index moves over old drops, new appears Deleting the legacy sitemap removes the fastest route a crawler has to your redirects.
The legacy sitemap is a discovery mechanism for redirects, not a claim that the old URLs should still rank.

When to Use This Approach

  • You have completed a domain change and the redirect map is live and verified.
  • Legacy URLs number in the thousands and organic re-crawl alone would take months.
  • Search Console shows the new property with few indexed URLs while the legacy property still holds most impressions.
  • You need a defensible timeline for when legacy URLs should stop appearing in reports.

What a Sitemap Actually Does After a Move

A sitemap is a discovery hint, not an instruction. It tells a crawler which URLs exist and roughly when they changed; it does not force indexing, does not confer ranking, and does not override a canonical tag or a noindex directive. Understanding that narrow role is what makes the legacy-sitemap decision obvious rather than counter-intuitive.

The bottleneck after a domain change is not indexing the new URLs — those are discovered quickly through internal links, the new sitemap, and the redirects themselves. The bottleneck is getting the crawler to re-request the old URLs, because that is the only way it learns each one now returns a 301. Old URLs are, by definition, not linked from the new site. Nothing points at them any more. Their re-crawl frequency was already set by how often they used to change, which for an archive page might be once a quarter.

That is the gap the legacy sitemap fills. It is a list of URLs whose only purpose is to be requested so that the response can be observed. Every entry that gets fetched teaches the index one more mapping, and the process finishes weeks earlier than it would if you waited for organic re-crawl.

# The legacy sitemap's job in one line: make these URLs get requested again
curl -s https://legacy.example/sitemap.xml | grep -c '<loc>'   # how many mappings you are advertising

The corollary is that a legacy sitemap is temporary by design. Once its URLs have been fetched and their redirects observed, it has done its work and keeping it published serves no further purpose — which is why the retirement decision is made on evidence rather than left indefinitely.

Step-by-Step Instructions

1. Regenerate the New Sitemap From the Live Site

Generate from what the site actually serves, not from the CMS’s idea of it. Every entry must be a canonical, 200-returning URL on the new domain — no redirect targets that themselves redirect, no noindex pages, no parameters.

# Fetch the generated sitemap and assert every entry is on the new host
curl -s https://example.com/sitemap.xml | grep -o '<loc>[^<]*' | sed 's/<loc>//' \
  | grep -v '^https://example\.com/' | head
# any output here is an entry pointing somewhere it should not

2. Keep the Legacy Sitemap Reachable

The legacy sitemap must return 200 on the legacy domain while the redirects are in force. That means excluding its path from the blanket redirect rule, the same carve-out used for verification files and .well-known paths.

# Serve the legacy sitemap itself; redirect everything else
location = /sitemap.xml {
    try_files /sitemap-legacy.xml =404;   # 200, never 301
}
location / {
    return 301 https://example.com$request_uri;
}

3. Submit Both, on Their Own Properties

Submit the new sitemap on the new property, and re-submit the legacy sitemap on the legacy property. Cross-submitting only works where both hosts are verified in the same account, and it is clearer to keep each on its own property while both are being monitored.

4. Advertise the Sitemap in robots.txt on Both Hosts

# Absolute URL, one Sitemap line per file, at the end of robots.txt
Sitemap: https://example.com/sitemap.xml
Reading the sitemap processing report A matrix of four sitemap report states — discovered, couldn't fetch, has errors, and submitted versus indexed gap — with the cause and the action for each. What the Sitemap Report Is Telling You REPORT STATE USUAL CAUSE ACTION Couldn't fetch sitemap itself 301s exclude from rule Has errors entries on wrong host regenerate from live Success, 0 discovered empty or gzip mismatch check content-type Discovered > indexed normal early, not late wait, then investigate Only the last row is expected to be true for a while after a move.
Three of these four states are configuration faults you can fix the same day; the fourth is the one that needs patience.

5. Retire the Legacy Sitemap Only on Evidence

Retire it when legacy impressions have fallen close to zero and the new property’s indexed count has stabilised — typically six to twelve weeks. Retiring on a calendar date rather than on evidence is how sites lose the tail of their archive, the failure mode covered in Log-Based 404 Triage After a Cutover.

Worked Example

A documentation site with 24,000 URLs moved from docs-legacy.example to example.com/docs/. The team submitted the new sitemap on day one and deleted the legacy sitemap the same afternoon, on the reasoning that the old URLs no longer existed.

Six weeks later the legacy property still showed 19,000 URLs indexed and the new property showed 4,100. Nothing was broken — the redirects were correct and returned single-hop 301s — but nothing was prompting a re-crawl of pages that had historically been fetched once a quarter.

The fix was to restore sitemap-legacy.xml on the legacy host with all 24,000 old URLs and re-submit it on the legacy property. Discovery of the redirects moved from a trickle to several thousand URLs a week, and the crossover — new property indexed count overtaking legacy — arrived four weeks later. The mapping that generated both files came straight from the CSV workflow described in Using Python to Generate CSV Redirect Maps.

Verification

# 1. The legacy sitemap must be 200, not 301 — this is the check people skip
curl -sI https://docs-legacy.example/sitemap.xml | head -1     # expect HTTP/2 200

# 2. Content type must be XML, not HTML from an error page
curl -sI https://example.com/sitemap.xml | grep -i content-type   # expect application/xml

# 3. Sample entries and confirm each returns 200 on the new host
curl -s https://example.com/sitemap.xml | grep -o '<loc>[^<]*' | sed 's/<loc>//' \
  | shuf -n 25 | xargs -I{} -P4 curl -s -o /dev/null -w '%{http_code} {}\n' {} | sort | uniq -c

Anything other than 200 in the third check is a sitemap entry that should not be there. A sitemap containing redirects tells a crawler that the redirect target is the canonical URL — which is true — but wastes the crawl budget you are trying to concentrate.

Retirement timeline for the legacy sitemap A timeline from cutover through weeks two, six and twelve, showing legacy impressions falling and new-property indexed count rising, with the retirement decision at the crossover. Retire on Evidence, Not on a Date Cutover submit both Week 2 discovery climbing Week 6 crossover expected Week 12 retire legacy file The retirement gate is legacy impressions near zero, not the number of weeks elapsed. A site with a deep archive can legitimately need twice this long.
Week twelve is a typical outcome, not a rule — read the impression curve rather than the calendar.

FAQ

Should the legacy sitemap list old URLs or new ones? Old ones. Its entire purpose is to get the crawler to re-request the legacy paths so it encounters the 301 responses. A legacy sitemap listing new URLs duplicates the new sitemap and prompts nothing.

How long should I keep the legacy sitemap live? Until legacy impressions have fallen close to zero — usually six to twelve weeks, longer for a deep archive. Retire it on the evidence in the reports, not on a date chosen in advance.

Does re-submitting the same sitemap speed anything up? Re-submitting an unchanged file achieves nothing; the crawler already has it and re-reads it on its own schedule. Re-submission matters when the file’s contents have genuinely changed — new sections, a corrected host, a repaired encoding.

Can I put both old and new URLs in one sitemap? You can, but it is harder to read. Two files on two properties let you watch the legacy count fall and the new count rise as independent numbers, which is exactly the signal you need to decide when the move is finished.

What content type should the sitemap return? application/xml or text/xml; a gzipped file additionally needs Content-Encoding: gzip. An error page served as text/html under a .xml path is a common cause of a sitemap that reports success but discovers zero URLs.

Should the sitemap include the lastmod date? Yes, and it should be truthful. After a migration the honest value for a page whose content did not change is its original modification date, not the migration date — marking every URL as modified on cutover day makes the field meaningless as a prioritisation signal.

Do priority and changefreq help after a move? No. Both are widely ignored, and neither compensates for a URL that is thin, duplicated or unlinked. Effort spent tuning them is better spent making sure every entry returns 200 and that the legacy sitemap is reachable, which are the two things that measurably change how fast the move completes.

Should the legacy sitemap be listed in the legacy robots.txt? Yes. It costs one line, it gives the crawler a second route to the file, and it survives the case where somebody removes the Search Console submission without telling anyone. Make sure the Sitemap: line carries an absolute URL — a relative path in robots.txt is ignored.

What if the legacy domain is being released and cannot serve a sitemap? Then the discovery route disappears with it, and the migration will complete on organic re-crawl alone. This is a strong argument for holding the legacy domain and a minimal redirect service for the duration; the hosting cost is trivial next to a re-crawl that takes months instead of weeks.

Can I submit a sitemap of legacy URLs on the new property instead? Cross-submission works only when both hosts are verified in the same account, and even then it muddles the reporting: you can no longer read the legacy count falling and the new count rising as independent numbers. Keep each sitemap on the property whose host it describes.

How do I know the legacy sitemap is actually doing anything? Watch the legacy property’s indexed count fall and the crawl-stats request count for the old host stay non-zero. If requests to the legacy host have dropped to nothing while thousands of old URLs are still indexed, the file is not being read — check that it returns 200 and XML rather than a redirect or an error page.

Related

← Back to Sitemap Re-submission Strategies