WordPress Broke After a URL Change? Fix Serialized Data Safely

You changed your WordPress site's domain or switched it from http to https, and now half the site looks wrong. Widgets are empty. Theme options reset to defaults. Page builder content just vanished. You didn't touch a single setting on purpose — so what broke?

The Symptom: Things Go Missing, Not Just URLs

A simple domain change should be a find-and-replace job: swap oldsite.com for newsite.com in the database and you're done. Except after doing exactly that, you notice:

• Elementor, Divi, or WPBakery pages show a blank canvas instead of your layout
• Widgets in Appearance > Widgets are empty, or the widget area disappears entirely
• Theme customizer settings (logo, colors, menus) revert to defaults
• Some plugin settings pages throw a PHP notice like unserialize(): Error at offset...

None of this is a coincidence. It's almost always the same root cause: a plain text find-and-replace was run against serialized PHP data in the database.

The Cause: Serialized Strings Have a Length Prefix

WordPress stores a lot of structured data — widget settings, theme mods, page builder layouts, some plugin options — as PHP's serialize() output, saved as a plain text string inside a database column. A serialized string looks like this:

a:1:{s:4:"home";s:19:"http://oldsite.com";}

Notice the s:19 right before the URL — that's PHP telling itself "the next string is exactly 19 bytes long." If you run a database-level find-and-replace tool (phpMyAdmin's search, a generic SQL UPDATE ... REPLACE(), or a text editor on an exported .sql file) and swap http://oldsite.com for https://newsite.com, the string is now 20 characters instead of 19 — but the length prefix still says s:19.

PHP's unserialize() reads that prefix literally. When the byte count doesn't match the actual string, unserialize fails silently in most cases — WordPress just gets back false or a truncated array instead of throwing a visible fatal error. The setting effectively disappears. That's why widgets go empty and page builder content vanishes instead of the site erroring out loudly — the failure is quiet by design.

The Fix: Replace With a Tool That Understands Serialization

Option 1 — WP-CLI search-replace (recommended if you have SSH/terminal access)

This is the correct tool for the job. It walks every table, finds serialized values, recalculates the length prefixes, and re-serializes correctly. Always dry-run first:

wp search-replace 'http://oldsite.com' 'https://newsite.com' --all-tables --dry-run

# once the dry run output looks right:
wp search-replace 'http://oldsite.com' 'https://newsite.com' --all-tables --precise --report-changed-only

On Getwebup's cPanel hosting, you get WP-CLI through cPanel > Terminal, or over SSH if it's enabled on your plan. cd into the site's document root first so WP-CLI can find wp-config.php.

Option 2 — Better Search Replace plugin (no shell access)

If you're on shared hosting without terminal access, install the free "Better Search Replace" plugin. It runs the same serialization-safe logic as WP-CLI, from the WordPress admin. Tick "Save changes to database" only after you've reviewed the dry-run results it shows first.

Option 3 — Already broke it? Restore from backup, then redo it properly

If you already ran a raw phpMyAdmin find-and-replace and things are broken, don't try to hand-patch the length prefixes — it's tedious and easy to get wrong on nested arrays. Restore your last database backup (cPanel > Backup Wizard, or JetBackup if it's enabled on your account) and redo the URL change with WP-CLI or Better Search Replace instead.

Where to Check After the Swap

Prevention: Do It Right the First Time

• Back up the database before you touch it. A five-minute mysqldump saves hours of manual repair.
• Always dry-run first. Both WP-CLI and Better Search Replace support this — read the output before committing.
• Run all the URL variants, not just one. If you're not sure whether old links used http://, https://, with or without www, run separate passes for each combination rather than assuming one covers it.
• Update wp-config.php too. If WP_HOME and WP_SITEURL are defined there, a database-only replace won't touch them — you'll need to edit the file directly.
• Clear every cache layer after. Object cache, page cache, and CDN cache can all mask whether the fix actually worked.

Prevention on Getwebup

If you're moving a site to a new domain on Getwebup hosting, take a JetBackup snapshot first from cPanel — it takes seconds and gives you an instant rollback point if the search-replace doesn't go as planned. WP-CLI is available via Terminal in cPanel on plans where SSH is enabled; support can enable it if you don't see it.

If you've already lost content and don't have a recent backup, don't panic before trying a WP-CLI dry run against the reverse replacement (new URL back to old) — in some cases this reveals which specific rows still hold stale, correctly-serialized data you can target individually instead of a full restore.