Find Old Domain URLs Left Behind After Moving WordPress

Why Old Domain References Survive a Successful WordPress Migration

A domain migration can appear complete while older URLs still hide in the site’s content and configuration. The homepage loads at the new address, the dashboard works, and a redirect sends visitors from the old domain to the new one. Yet an image may still request a file from the former host, a navigation item may redirect twice, or a social-sharing image may reference a retired subdomain.

The reason is that WordPress stores URLs in several places. Some are generated dynamically from the current site settings. Others are absolute addresses saved in post HTML, serialized options, plugin fields, navigation blocks, CSS, or attachment-related data. Updating Settings > General does not automatically rewrite every saved string.

Know Which Old-Domain Matches Matter

Not every mention of the previous domain needs replacing. Use the following table to classify findings before editing your site. The sample addresses are illustrative, not results from a live WordPress installation.

Important: a legacy URL in the guid database column is not, by itself, a broken internal link. WordPress guidance explicitly warns against rewriting GUIDs during ordinary migrations because feed readers use them to identify existing content.

Step 1: Confirm the New WordPress Address and Domain Variants

Begin in Settings > General. Confirm that WordPress Address (URL) points to the installation location and Site Address (URL) points to the visitor-facing location. They are often identical but can differ when WordPress is installed in a subdirectory. If the fields cannot be edited, examine whether WP_HOME and WP_SITEURL are defined in wp-config.php.

Write down the complete group of addresses involved in the migration: HTTP and HTTPS versions, www and non-www hostnames, old staging hosts, and any retired CDN subdomains. Search for the actual hostnames, not just one full URL. Otherwise, you may miss references using a different protocol or hostname variant.

Check that the new domain serves the intended pages and media before planning replacements. Replacing a host without verifying its destination can turn working redirected links into direct 404 errors.

Step 2: Search Real Pages for Old URLs

Start with evidence from the public website. Open a representative older article on the new domain, then use View Page Source or your browser’s developer tools to search for the old hostname. Look for it in href, src, srcset, content, url(), and JSON-LD values. A browser’s visible page can look correct even when its HTML still contains an outdated address.

Inspect more than the homepage. Check a category archive, an old article, a page-builder landing page, a product or custom post type, and a page containing galleries or download buttons. For a broad site, use a crawler that can extract links and HTML references rather than opening hundreds of pages manually.

Distinguish page-source references from network requests. A browser may follow an old-domain link through a redirect, so the final asset appears on the new host. The source still deserves correction if you control it, because direct new-domain links avoid unnecessary hops and reduce reliance on the previous domain.

For links that seem suspicious, the Internal Links and Anchor Text Analyzer can be used as an additional review aid. Confirm which links the tool actually detects before treating its output as an exhaustive site audit.

Step 3: Inspect Posts, Menus, Widgets, and Builder Content

Next, search inside WordPress itself. A normal dashboard search is useful for finding posts by title or text, but it does not guarantee coverage of every custom field or database option. Use a structured checklist so an apparently clean post editor does not end the investigation prematurely.

• Posts and pages: inspect old articles, reusable patterns, custom HTML blocks, internal buttons, and embedded links.
• Navigation: check classic custom-link menu items and block-theme navigation content, depending on the theme.
• Widgets and theme settings: review footer links, logos, Customizer fields, and theme option panels.
• Page builders: inspect image widgets, button URLs, templates, global elements, and generated stylesheets.
• Custom fields: review SEO plugin metadata, ACF or other plugin fields, and custom post type data.
• Media: check gallery HTML, image captions with links, CSS backgrounds, and responsive image candidates.

Step 4: Audit the Database Without Changing It Yet

Take a restorable database backup before running a replacement. On important production sites, reproduce the migration on staging and verify that rollback is possible. Common database locations include post content, post metadata, options, and plugin-specific tables. Do not assume all installations use the default wp_ table prefix.

If WP-CLI is installed, a dry run provides a useful count of potential replacements without writing changes. This example searches for the retired hostname within the normal WordPress tables:

wp search-replace 'old.example' 'new.example' --dry-run --skip-columns=guid

Replace the example hostnames with your verified domains. Review the reported affected tables and counts. The command reports potential changes; it is not a complete page-by-page list of rendered URLs, and not every potential replacement will necessarily be appropriate.

For a read-only look at ordinary post bodies, an administrator with database access can run a scoped query like the following. Replace wp_posts with the actual table name if the prefix differs:

SELECT ID, post_type, post_title
FROM wp_posts
WHERE post_content LIKE '%old.example%';

This query is an illustration, not a universal audit. It does not inspect post metadata, options, or serialized values inside other tables. In addition, results may include intentional mentions of the former domain, not only links that require editing.

Step 5: Build an Old-to-New URL Map Before Replacement

A straightforward move may preserve paths, such as https://old.example/about/ becoming https://new.example/about/. But real migrations often change slugs, upload directories, category bases, or attachment locations. For those cases, a simple domain substitution is insufficient.

Create a mapping with at least four fields: old URL, intended new URL, content type, and verification result. Include pages, images, downloadable files, and any retired CDN paths. The Website Migration URL Mapper is a relevant way to organize or review examples before editing; verify actual behavior on the live tool page before relying on automated features.

For stored image paths, use the WordPress Media URL Mapper to help plan the relationship between old and new media addresses. A mapping must still be checked against the file that really exists on the destination server.

Step 6: Replace Approved URLs Safely

WordPress option values and plugin data may use PHP serialization, which records string lengths. Replacing text directly with a broad SQL REPLACE() query can damage these stored structures. Use a reputable serialization-aware search-and-replace process, such as the WP-CLI command documented by WordPress, and review the scope before making changes.

When an old hostname and a new hostname have matching URL paths, the following illustrates a controlled replacement after backup, dry-run review, and destination testing:

wp search-replace 'https://old.example' 'https://new.example' --skip-columns=guid

Do not run the example unchanged. Separate the old http:// variant and any www or subdomain variants where necessary. If slugs or file paths changed, use a verified URL-by-URL map rather than a blanket hostname substitution. On WordPress multisite, the command’s default table scope and any network-wide option require special review.

Step 7: Check SEO Metadata and Migration Signals

Even when the visible page has no old links, the HTML head may still publish the former address. Audit self-referencing canonical tags, Open Graph URLs and images, Twitter/X image metadata, hreflang references where applicable, structured data URLs, and XML sitemap entries. Correct these at the SEO plugin or template source rather than editing generated HTML output.

After a genuine domain move, each indexable page should ordinarily identify the correct new canonical URL. XML sitemaps should also list the preferred new addresses. A sitemap validator can support a format or URL review, while Search Console and a dedicated crawl provide separate evidence about indexed and discoverable pages.

Keep permanent redirects from old page URLs to their relevant new equivalents. They protect existing inbound links, bookmarks, and search discovery, but they should not be treated as a substitute for updating links that you control. Test representative rules with the Bulk HTTP Status and Redirect Checker and confirm that URLs do not lead to irrelevant homepages or long redirect chains.

Step 8: Verify Media Files and Clear Every Relevant Cache

Images deserve a separate pass because the WordPress Media Library can display valid attachment entries while old post HTML still points to a different hostname. Check src, srcset, video poster URLs, CSS background images, downloads, and external storage or CDN URLs. Open each proposed destination directly and confirm it serves the expected file, not merely a redirect or error page.

After corrections, clear the WordPress page cache, object cache where relevant, CDN cache, generated builder files, and browser cache. Reload sample pages in a fresh session with developer tools open. Check whether the old hostname remains in rendered HTML and whether any live requests still depend on it.

If a missing image remains broken, restore or remap the file. An old URL that redirects to a 404 cannot be repaired by cache clearing or by resizing the picture. If the file exists but needs a separate size or crop adjustment, the Image Resizer and Cropper addresses that different task.

Questions That Come Up During a WordPress Domain Cleanup

Why does my WordPress database still show the old domain after replacement?

It may appear in a GUID, an untouched plugin table, a staging record, a historical reference, or a hostname variant your search did not include. Identify the field and purpose of the entry before treating it as an error.

Does a 301 redirect mean I can leave all old internal links in place?

No. Redirects are important for old external links and bookmarks, but internal links should generally point directly to the correct new destination. This reduces unnecessary requests and dependence on the former domain.

Why do some images still use the old URL after I clear WordPress cache?

The value may be stored in post HTML, a builder widget, generated CSS, or a CDN configuration. Inspect the browser request’s initiator and correct the source producing that URL, then clear the relevant cache again.

Final Checklist Before Declaring the Move Clean

• Confirm the correct WordPress and Site Address settings, including legitimate subdirectory differences.
• Audit old hostnames in representative public HTML and network requests.
• Review posts, navigation, widgets, options, custom fields, and page-builder records.
• Back up the database and evaluate WP-CLI dry-run results before any replacement.
• Leave GUIDs intact and avoid changing historical text without a reason.
• Verify old-to-new mappings for pages, images, downloads, and renamed paths.
• Correct canonical, social, structured-data, and sitemap URLs where necessary.
• Test permanent redirects, purge caches, and repeat the audit on high-value templates.

Bottom line: finding old-domain URLs is a classification and verification task, not just a search-and-replace operation. Fix references that affect visitors or search engines, preserve identifiers that should remain stable, and confirm that every changed URL reaches the right destination.