Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Recovery & Prevention

WordPress Still Redirects or Links to the Old Domain After Migration

Old-domain references can live in options, serialized content, cache, redirects or external configuration. Map where each one originates.

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 home and siteurl;
  • 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.

WP RepairDiagnostic model
1Symptom2Evidence3Controlled change4Verification
Follow the chain until you find the first point that stops behaving as expected.
  1. 1

    Capture the exact old-domain occurrence: Location header, HTML, asset URL or API response.

  2. 2

    Check home, siteurl, network options and multilingual domain settings.

  3. 3

    Search the database with a serialized-data-aware dry run.

  4. 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.

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.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident