A migration is not finished when only home and siteurl point to the new domain. The old host can survive in redirects, page-builder data, menus, canonical tags, cached HTML, webhooks and CDN rules. The first job is to identify which layer is actually producing it.
Classify the old-domain occurrence first
Capture one exact example and determine whether it appears in an HTTP Location header, rendered HTML, an asset URL, a canonical tag or an API response. Each points to a different source and therefore a different repair.
Check the authoritative configuration before searching the database
- WordPress
homeandsiteurl; - multisite or multilingual domain settings;
- Nginx, Apache, hosting-panel and CDN redirects;
- object/page cache and generated sitemaps;
- webhooks, email templates and external callbacks.
Use serialized-data-aware replacement
If the old domain is stored in builders, widgets or options, use a WordPress-aware search-replace with a dry run and a verified backup. A plain SQL replacement can corrupt serialized values. For migration routing problems, compare the separate guide to permalinks returning 404 after migration.
Separate stale cache from wrong source data
A correct database value with old HTML usually means a cache or another application node is stale. If media URLs fail as well, follow the checks in WordPress images broken after migration before changing more database values.
Do not rewrite identifiers indiscriminately
Avoid blanket replacements in GUIDs, historical records or third-party identifiers unless you know they are operational URLs that must change.
Verification
Test representative pages, redirects, canonicals, assets, forms, webhooks and the sitemap. The migration is complete only when the old domain appears solely in intentionally preserved historical data or explicit redirects.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Browser location, response headers and page source distinguish an HTTP redirect from a stored link or SEO metadata issue.
- 1
Capture the exact old-domain occurrence: Location header, HTML, asset URL or API response.
- 2
Check home, siteurl, network options and multilingual domain settings.
- 3
Search the database with a serialized-data-aware dry run.
- 4
Inspect server/CDN redirects, object cache and generated sitemaps.
What must be verified
- The old domain redirects only where intentionally mapped.
- Canonical, sitemap, assets and internal links use the new domain.
- Forms, webhooks and scheduled jobs call the correct host.
Official technical sources
Continue the diagnosis
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
If home and siteurl are already updated to the new domain, why do old links still appear?+
Because home and siteurl only control core WordPress URL generation. Menus, widgets, page-builder data, canonical tags, cron jobs and CDN configuration are stored or cached separately and can still reference the old host even after those two settings are corrected.
Is it safe to replace every occurrence of the old domain in the database?+
No. Some identifiers, such as GUID values and certain historical data, should not be changed, so a blind replace-all can damage records that were intentionally left referencing the original value.
How can I tell if I'm dealing with a server redirect versus a stored link in the database?+
Check the browser's response headers and Location header against the page's HTML source. A redirect happening at the server or CDN level shows up in the response headers before any content loads, while a stored link appears directly in the page HTML or an API response.
Does flushing the cache fix old-domain references if the underlying data hasn't been corrected yet?+
No, and doing it too early can be misleading. Each cache layer should only be flushed after its source — database, server rule, or CDN config — has actually been corrected, otherwise the cache will simply repopulate with the same stale references.