WordPress Still Showing Old URLs After Migration? Fix It

You moved the site, the files copied fine, the database imported without errors — and now half the pages load with broken CSS, images point at a server that doesn't exist anymore, and clicking any link bounces you back to the old host. This is almost never a broken migration. It's WordPress doing exactly what it's told: serving URLs that are still baked into the database.

Why This Happens

WordPress doesn't store your domain in one tidy place. It's scattered across the database in at least four spots, and a straight file-and-database copy moves all of them over unchanged — old domain included.

• wp_options table — the siteurl and home rows define what WordPress thinks its own address is. If these still say oldsite.com, every generated link, admin redirect, and asset path uses it.
• Serialized data — widget settings, page builder layouts (Elementor, Divi), and some plugin options store arrays as serialized strings with a byte-length count baked in. Edit the URL with a plain text find-and-replace and you corrupt the array; WordPress silently drops the setting instead of erroring.
• Post content — images inserted through the media library, internal links you typed by hand, and anything pasted from the old site's editor all contain the full old domain as plain text.
• wp-config.php — if it has hardcoded WP_SITEURL or WP_HOME constants, they override whatever the database says, which is a separate and very common cause of the exact same symptom.

Step 1 — Confirm It's a URL Problem, Not a DNS Problem

Before touching the database, rule out the simpler explanation. If you're testing through a temporary URL or a hosts-file entry while DNS is still pointed at the old server, you'll see this exact mess even on a perfectly migrated site — because you're hitting the new files through an address WordPress doesn't recognize as its own.

# Quick check: are you resolving to the new server?
nslookup yourdomain.com

# If it still returns the old IP, this isn't a URL bug —
# it's DNS/propagation. Fix that first, then re-test.

If DNS is already correct and the domain is resolving to Getwebup, move on — the problem is in the database.

Step 2 — Check wp-config.php First

Open wp-config.php in File Manager or over SFTP and look for these two lines near the top:

define('WP_SITEURL', 'https://oldsite.com');
define('WP_HOME', 'https://oldsite.com');

If they're there, either delete them (WordPress will fall back to the database values) or update them to the new domain. This alone fixes the problem in a surprising number of cases, and it's worth 30 seconds before you go anywhere near the database.

Step 3 — Fix the Database with WP-CLI (the reliable way)

If you have SSH access on your Getwebup VPS or cPanel Terminal, wp search-replace is the right tool. It's serialization-aware, meaning it recalculates those byte-length counts automatically instead of breaking them the way a manual SQL find-and-replace would.

# Always dry-run first — this shows what WOULD change, nothing is written yet
wp search-replace 'https://oldsite.com' 'https://newsite.com' --dry-run --all-tables

# Looks right? Run it for real
wp search-replace 'https://oldsite.com' 'https://newsite.com' --all-tables

# Multisite installs need this instead, run from the network root
wp search-replace 'https://oldsite.com' 'https://newsite.com' --network --all-tables

Two flags matter more than people expect:

• --all-tables — without it, WP-CLI skips custom tables that plugins like WooCommerce or form builders create outside the standard WordPress schema, and you'll still find stray old URLs later.
• Run it for both the http:// and https:// versions of the old domain if you're not sure which protocol the old content used. Mixed-protocol references are the most common cause of "some images are broken, others aren't."

No SSH? Use a Plugin Instead

If you're on a shared cPanel plan without terminal access, install Better Search Replace (free, in the plugin directory) from wp-admin, run it in dry-run mode first, then commit the change. It handles serialized data the same way WP-CLI does — just avoid any plugin or manual SQL approach that doesn't explicitly mention serialization safety.

Step 4 — Clear Every Layer of Cache

By this point the database is correct — but you'll still see the old domain if a cache is serving a stale copy. Clear these in order:

Step 5 — Check .htaccess for Leftover Redirects

If someone previously set up a redirect rule pointing this domain elsewhere — or the old host's migration tool wrote a default-page rule — it can override everything you just fixed. Open .htaccess in File Manager and look above the standard WordPress block for anything with Redirect or RewriteRule referencing the old domain, and remove it.

Prevention: Bake This Into Every Future Migration

1. Run wp search-replace as a standard step immediately after importing the database — don't wait for someone to report broken links.
2. Always dry-run first. It costs ten seconds and catches typos in the old/new domain before they get written.
3. Keep WP_SITEURL and WP_HOME out of wp-config.php unless you have a specific reason — hardcoded constants are the thing people forget about six months later.
4. Purge every cache layer as the last step, not the first — clearing cache before the database fix just means you get to see the same stale content twice.

If you migrated to Getwebup and are still seeing this after working through the steps above, open a support ticket with your domain and we'll check the database and cache layers directly — this is one of the fastest tickets for us to close.