Why your WordPress sitemap still names staging
You open the live sitemap after a WordPress migration and there it is: a staging hostname sitting inside URLs that ought to belong to the public site. The sitemap loads, the pages may even redirect, and somebody has probably suggested submitting it again. That does not answer the useful question: which configuration generated that entry in the first place?
For a Dubai, UAE, UK or Liverpool business launching a rebuilt site, this is worth sorting properly. A sitemap is one of the places you explicitly hand search crawlers a list of URLs to visit. Leaving an old staging domain in it makes the launch look less finished than it is.
Start with a sample, not the whole sitemap
Take three to five incorrect entries from the public sitemap. Record the exact URL listed, the sitemap file it appears in, the page it is meant to represent and where the URL ends up when opened in a private browser window.
Do not begin by changing random WordPress settings or running a broad database replacement. A sitemap can be generated by WordPress core, an SEO plugin, a multilingual plugin, a dedicated sitemap tool or a cached static file. Those are different repair routes.
WordPress sitemap staging URLs after migration usually mean that the live sitemap generator, or a layer in front of it, is still using an obsolete URL source. Check a sample of the listed URLs, identify the generator, compare its configured domain with the live site address, correct the source narrowly, regenerate the sitemap and confirm that the final page destinations and canonicals agree with the new entries.
Google’s sitemap guidance says sitemap URLs should be fully qualified absolute URLs, that Google attempts the URLs exactly as listed, and that the sitemap should contain URLs you want in search results. A redirect from staging to live is better than a dead end, but it is still the wrong list to publish.
Identify what is actually producing the file
First establish whether the affected URL is in a sitemap index, such as sitemap_index.xml, or in one of its child sitemaps. Then look for the fingerprint of the generator. The XML structure, sitemap naming and WordPress admin settings often make this reasonably clear.
Check the following in order:
- Open the sitemap URL in a private browser session and note any redirects.
- Inspect the page source or XML output for the generator name where it is exposed.
- Check WordPress Address and Site Address settings under Settings, General.
- Check the active SEO or sitemap plugin settings for a domain, canonical or sitemap base setting.
- Check whether the sitemap is a generated response or a physical file being served from old deployment or cache storage.
A mundane but common migration detail: the production site address has been corrected in WordPress, while an SEO plugin’s index was built when the staging domain was still configured. Another is a cache or CDN continuing to serve a generated sitemap response from before launch. Same visible problem, different source.
Run the URL-source comparison
| Audit point | What to compare | What a mismatch suggests |
|---|---|---|
| Listed sitemap URL | Hostname, protocol and path | The published output is carrying an obsolete base URL |
| WordPress site settings | Home and site address against the intended live domain | The core configuration may still point at staging |
| Sitemap generator | Its own URL, canonical or index settings | A plugin or extension may hold separate migration-era data |
| Public response | Generated XML versus a stored or cached file | The correction may not yet be reaching visitors or crawlers |
| Final page | Redirect destination and canonical URL | The sitemap and the page-level signals disagree |
Use one service page as the controlled example. If the sitemap lists staging.example.com/services/consulting, check whether it redirects to www.example.com/services/consulting, whether the live page declares the live canonical URL, and whether the sitemap should instead list that final live address directly. This is more useful than scanning 800 URLs and feeling vaguely alarmed.
Correct the generating source, not the symptom
The practical recommendation is simple: fix the source that creates the incorrect sitemap URLs before asking a crawler to use the sitemap again. Resubmitting a sitemap can prompt another fetch, but it does not rewrite the URLs inside it.
If WordPress Address or Site Address is wrong, correct that through the proper site configuration route and verify the public domain still behaves as expected. If the sitemap plugin is wrong, adjust its relevant setting or rebuild its index using its supported controls. If old domain references are genuinely embedded in migration data, handle them carefully. WordPress stores some values in serialised data, so a casual search-and-replace can damage settings or widgets. Use a controlled approach to replace WordPress URLs without breaking serialised data when that is the evidenced repair route.
Do not treat every old reference in the database as a reason to replace every string. Staging URLs can remain legitimately in internal notes, old attachments, test records or integration settings. The task is to repair the public URL source that is producing the sitemap, not to tidy history for sport.
Regenerate, then compare the public result
Once the source is corrected, regenerate the sitemap through the relevant tool and clear only the cache layers that can serve that sitemap. Fetch the public sitemap again in a private session and compare the original sample entries with the new output.
Check all of the following before considering the issue contained:
- The sitemap index and child sitemap URLs use the intended live hostname.
- The sampled entries are absolute URLs, not relative paths or redirected staging addresses.
- Each sampled sitemap URL resolves to the intended live page.
- The live page canonical points to that same intended URL.
- No separate cache, CDN rule or static file is restoring the old XML response.
If the settings and generator look correct but the public XML remains old, that is a distinct cache investigation. The issue may be a stale response rather than an incorrect URL source. Use the separate guide on WordPress sitemap updates blocked by a stale cache layer for that boundary, rather than assuming the migration change failed.
Keep sitemap repair within the wider launch check
A sitemap with staging URLs rarely deserves a full rebuild, but it does justify a focused website repair review when redirects, canonical URLs, migration settings and caching are disagreeing. Those signals should tell the same story. If they do not, the site has been launched with loose ends that can confuse crawlers and make future diagnosis harder.
For a broader review of migration faults, broken public routes and WordPress configuration issues, see the scope of website repair support in Dubai. The sensible aim is not an elaborate technical ceremony. It is one consistent live URL used by the sitemap, the page and the browser.
If you have a public sitemap listing a staging domain, request a sitemap source audit using a sample of the incorrect staging entries. A few representative URLs are normally enough to establish whether the fault sits in site configuration, the sitemap generator or the cache serving the result.