Moving a WordPress site to a new domain, host, or from HTTP to HTTPS often leaves old URLs baked into the database, causing broken links, missing images, and 404 errors. This happens because WordPress stores full URLs — not just relative paths — throughout its database, including inside serialized data that a simple find-and-replace can corrupt if done carelessly. Fixing this requires updating both the core WordPress settings and every URL reference scattered across your posts, pages, and metadata.
Why URLs Break After Migration
A few common causes explain most post-migration URL problems:
- Mismatched Site Address and WordPress Address. These two settings, found in Settings > General, must reflect your new domain exactly, or the entire site can misbehave.
- Hardcoded URLs in content and media. Every image, internal link, and embedded file stores a full URL (like
https://oldsite.com/wp-content/uploads/...) rather than a relative path.
- Serialized data. WordPress stores some settings — especially widget and theme configuration — as PHP serialized arrays that include a character count alongside the text. A plain text replace that changes the URL’s length without updating that count will corrupt the data and can break your site.
- Incomplete database transfer. If tables were only partially migrated, some content may still reference the old environment entirely.
Step 1: Update the Core Site URLs
- Log into wp-admin on the new site.
- Go to Settings > General.
- Update both the WordPress Address (URL) and Site Address (URL) fields to your new domain.
- Save changes.
If you can’t log in because the mismatch is preventing access, you can set these directly in wp-config.php instead:
define('WP_HOME', 'https://newsite.com');
define('WP_SITEURL', 'https://newsite.com');
Step 2: Run a Safe Search-and-Replace Across the Database
Because of the serialized data issue, don’t use a plain SQL UPDATE ... REPLACE() across every table blindly — it’s fine for simple option fields but risky for postmeta and widget data. Instead:
- Install a search-and-replace plugin such as Better Search Replace or Search Replace DB — these are built specifically to handle WordPress’s serialized data correctly.
- Enter your old and new URLs, making sure to omit trailing slashes (e.g.,
https://oldsite.com, not https://oldsite.com/).
- Select the tables to search, typically all WordPress core tables plus any custom tables your theme or plugins use.
- Run a dry run first if the plugin offers one, to preview how many rows will be affected before committing.
- Execute the replacement and confirm the reported row count looks reasonable for your site’s size.
If you prefer working directly in phpMyAdmin, the manual SQL approach covers the most visible fields:
UPDATE wp_options SET option_value = replace(option_value, 'https://oldurl.com', 'https://newurl.com') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET guid = replace(guid, 'https://oldurl.com', 'https://newurl.com');
UPDATE wp_posts SET post_content = replace(post_content, 'https://oldurl.com', 'https://newurl.com');
UPDATE wp_postmeta SET meta_value = replace(meta_value, 'https://oldurl.com', 'https://newurl.com');
This handles posts, pages, and their metadata, but it will not safely fix serialized widget or theme option data — use a plugin for that instead of running this against wp_options broadly.
Step 3: Fix Image and Media URLs
Media file paths are a frequent casualty of migration, since the full URL to each image is stored at upload time:
- Confirm the search-and-replace step above included the
wp_postmeta table, where attachment metadata lives.
- If images still appear broken, install Regenerate Thumbnails to rebuild image size variants under the new URL structure.
- Check your theme’s customizer settings (logo, background images) separately, since these are sometimes stored outside standard post content.
Step 4: Force HTTPS If You Migrated from HTTP
If your migration included a move from HTTP to HTTPS, mixed-content warnings often appear even after the database is updated:
- Make sure your SSL certificate is properly installed and active on the new host.
- Re-run your search-and-replace tool specifically for
http://yoursite.com → https://yoursite.com, since this is a distinct change from a domain swap.
- Add a redirect rule in your
.htaccess file to force HTTPS for any request that still arrives over HTTP:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
Step 5: Set Up Redirects for External Traffic
Updating your own database fixes internal links, but visitors and search engines arriving via old bookmarks or search results will still hit the old domain:
- Set up 301 redirects at the server or DNS level from the old domain to the new one, if you still control the old domain.
- Use a plugin like All in One SEO’s Redirection Manager to catch and log 404 errors that slip through, so you can add specific redirects for any URLs still being requested.
Step 6: Verify Everything Is Working
- Clear any caching plugin and your CDN cache, since cached pages can still reference old URLs even after the database is fixed.
- Browse key pages, checking that images, internal links, and forms load correctly.
- Visit a handful of old URLs directly to confirm redirects are firing and landing on the correct new pages.
- Check Google Search Console (or your preferred crawler) for any lingering 404s in the days following migration.
Join The Discussion
URL cleanup is one of the most error-prone parts of a WordPress migration, especially when serialized data gets mangled by a careless find-and-replace. Have you run into broken links, missing images, or mixed-content warnings after moving a WordPress site? Share which tools worked well for you, any migration horror stories, or tips for catching issues before they affect visitors.
