Wrong image links, buttons returning to staging and widgets pointing at an old domain usually mean URL replacement was incomplete or unsafe. WordPress stores URLs across posts, metadata, options and plugin-specific structures. The repair must respect that structure rather than running a blind database replacement.
Identify every old URL form
List the exact source and destination variants: HTTP and HTTPS, www and root, temporary hostnames, ports, escaped URLs and paths. Search a database export read-only to learn where each appears.
Do not assume every mention of the old domain should change. Author biographies, external references, email addresses, licences and multisite records may be intentional.
Establish the canonical destination
Confirm the final DNS, certificate and redirect policy first. Decide whether WordPress home and siteurl use root or www, and ensure HTTPS works at the origin. Replacing content before the destination is stable can create a second cleanup.
wp option get home
wp option get siteurlConstants in wp-config.php can override database values, so compare both sources.
Take a restorable database backup
Export the database immediately before changing it and record table prefix, row counts and time. Store the copy outside the public web directory. A backup is useful only if credentials and a tested import route are available.
Pause editorial changes during replacement, or arrange a final delta. Otherwise a rollback may discard posts, comments, users or orders added during the repair.
Use a serialization-aware replacement
PHP serialized strings record character lengths. A raw SQL REPLACE() can leave those lengths invalid when the new URL differs, breaking widgets and plugin settings.
WP-CLI understands serialized values. Preview scope before writing:
wp search-replace 'https://staging.example.net' 'https://example.com'
--all-tables-with-prefix --precise --dry-runReview counts, then remove --dry-run only when they make sense. Avoid --all-tables unless unrelated application tables are truly in scope.
Inspect content, widgets and builders separately
Classic widgets may live in sidebars_widgets and widget_* options. Block widgets, reusable blocks and navigation can be posts. Page builders often store JSON or encoded metadata and may provide their own replacement tool.
Do not edit opaque builder blobs manually. Use the supported tool, then regenerate its CSS/assets and clear only relevant cache layers.
Correct attachment and generated references
Verify attachment URLs, featured images, srcset, galleries, downloadable files, CSS background images and Open Graph images. The media files must exist in matching uploads paths.
Old URLs may remain in generated CSS, minified files, CDN settings or full-page cache. Regenerate disposable assets after database correction rather than treating cached output as the source.
Check redirects and mixed content
Request representative old URLs and ensure they reach the single intended new URL without loops. Internal links should use the canonical address directly; relying on redirects wastes requests and masks errors.
Use the browser console and source to locate remaining HTTP resources. Do not install a permanent mixed-content rewrite plugin instead of correcting stored URLs.
Validate functionality and SEO signals
Crawl a sample covering pages, posts, categories, media, widgets and landing pages. Check canonical tags, hreflang if used, sitemap entries, structured data and share images. Submit forms and test logged-in editing.
Compare the count of old-domain matches after repair, but manually classify survivors. Zero matches is not automatically correct.
Prevent the next URL repair
Build migrations around the real hostname via hosts-file testing where possible. Keep a written canonical-domain policy and a scoped search-replace procedure. Recurring care should flag staging domains in public HTML and verify new media links, so a hidden widget does not remain wrong for months.