A page may render on the new domain while its canonical, sitemap entry, image URL, or structured data still points to staging. Search engines then receive conflicting signals about which copy represents the content.
The reliable route is not the longest checklist; establish the failing boundary, keep one clean reproduction, and change one layer at a time until the evidence lets you align redirects, rel=canonical, sitemap URLs, internal links, Open Graph data, and WordPress settings around one production origin.
Read the failure at the right layer
- Serialized options and content retain the old domain.
- A proxy or environment constant overrides home/siteurl unexpectedly.
- Canonical and sitemap plugins use stale caches or separate configuration.
The branches are ordered to protect the strongest evidence around this possibility: serialized options and content retain the old domain. The observed scope and logs—not a familiar-looking error screen—decide which one applies.
Crawlability, indexability, and canonical selection are separate; a crawler may discover a URL it cannot fetch, fetch a URL marked noindex, or index a different canonical than the publisher prefers; test the live HTTP response and rendered document before interpreting a report label; in this guide, the practical goal is to align redirects, rel=canonical, sitemap URLs, internal links, Open Graph data, and WordPress settings around one production origin.
Build a clean diagnostic record
- Inspect source—not only the address bar—for canonical, hreflang, Open Graph, JSON-LD, feeds, and asset origins.
- Run a serialized-aware
wp search-replace OLD NEW --dry-runand review tables. - Map redirects for old HTTP/HTTPS and host variants.
- Compare the canonical URL reported by Search Console.
The sequence moves from observation toward intervention. Preserve the result of the final check—compare the canonical URL reported by Search Console—because it provides a useful comparison after the repair.
Audit old origins with a dry run
WP-CLI understands serialized data. First review exactly which tables and values still contain the verified old origin.
wp search-replace 'https://staging.example.net' 'https://example.com' \
--all-tables-with-prefix --precise --dry-run
curl -sS https://example.com/sample-page/ | \
rg -i 'canonical|og:url|staging\.example\.net'Interpretation and safety: Create a database backup before the real replacement. Search engines need consistent redirects, internal links, sitemaps, and canonicals; one tag alone is not enough.
Test one hypothesis without losing the baseline
Treat “Serialized options and content retain the old domain” as a working hypothesis, not a conclusion. Establish a baseline first: inspect source—not only the address bar—for canonical, hreflang, Open Graph, JSON-LD, feeds, and asset origins. Record both the result you expected and the result you actually saw.
A supporting result justifies a staging test of the narrowest repair: correct WordPress URL settings and environment constants. A result that contradicts “Serialized options and content retain the old domain” is useful too: it rules out one layer without disturbing production and gives the next operator a clean starting point.
Repair the cause—not the message
- Correct WordPress URL settings and environment constants.
- Run a backed-up, serialized-aware replacement for verified old internal origins.
- Regenerate sitemaps/caches and use page-to-page permanent redirects from old URLs.
Before applying “Correct WordPress URL settings and environment constants,” name its rollback point and the evidence that will count as success. Afterward, repeat the original request and specifically check whether you can crawl a sample from every content type and compare self-canonical, status, sitemap, and internal links; a changed symptom at that point is new evidence, not permission to make several more changes at once.
Verification checklist
- Crawl a sample from every content type and compare self-canonical, status, sitemap, and internal links.
- Check that old URLs make one clean redirect to their equivalent new pages.
- Use URL Inspection after deployment.
One successful refresh is not closure. Keep the incident open until you can also check that old URLs make one clean redirect to their equivalent new pages, adjacent paths have not regressed, temporary diagnostics are gone, and another operator can explain what changed.
Prepare a useful escalation if the boundary is outside your control
When escalating, include the exact canonical URL, response chain, robots rules result, meta and X-Robots-Tag values, canonical annotation, sitemap entry, and Search Console live-test date; search changes require recrawling; they are not instant configuration toggles; include the result of this first observation: inspect source—not only the address bar—for canonical, hreflang, Open Graph, JSON-LD, feeds, and asset origins.
State what was tested, including the result of “Inspect source—not only the address bar—for canonical, hreflang, Open Graph, JSON-LD, feeds, and asset origins,” and what changed between attempts; evidence tied to that observation is safer and more actionable than granting broad access or sending an unnecessary full database export.
Tempting moves to avoid
- Canonical is a signal, not a substitute for redirects and consistent links.
- Do not redirect every old URL to the home page.
Incident handoff
Primary references
- Google canonicalization — official reference consulted for this guide.
- WP-CLI search-replace — official reference consulted for this guide.
Editorial note: The scenario above illustrates how to approach “Correct WordPress URL settings and environment constants”; it is a documented example, not a claim about a reader’s server, so verify the cited documentation, take the appropriate backup, and follow the real environment’s access and change-control rules.