Some widgets went blank right after a domain change? A sidebar shows nothing, a footer widget area looks empty, but the rest of the site works fine. Your content almost certainly isn't gone. WordPress stores widget data as PHP-serialized text. A domain swap that isn't serialization-safe can corrupt just enough of it that WordPress silently stops rendering the affected widgets — without deleting anything underneath. This applies whether the domain change went through a migration plugin, a manual database export/import, or a raw find-and-replace with no tool involved at all. Below: why this specific symptom happens, the safe fix for most readers, and what to do without command-line access.

Symptoms

  • One or more widgets show empty, or a whole sidebar/footer widget area has nothing in it
  • The rest of the site — posts, pages, main content — looks and works fine, which is what makes this confusing rather than an obvious "the site is broken"
  • Started right after a domain change: a new host, a staging-to-live cutover, or a URL/rebrand change
  • The site doesn't use Elementor for that area, or Elementor pages look fine and only native Appearance → Widgets content is affected — if it's Elementor styling that broke, see Elementor Styles Missing After Migration instead

Why this happens: how WordPress actually stores widgets

Widget data lives in two different places, which is exactly why the breakage looks scattered instead of all-or-nothing.

Which widget goes in which sidebar is stored in a single option, sidebars_widgets, in the wp_options table — an associative array mapping each widget area to the list of widget instance IDs placed in it.

Each widget's actual settings — a Text widget's content, a Custom HTML widget's code — live somewhere else entirely. Every widget type gets its own wp_options row, named widget_{type} (widget_text, widget_custom_html, widget_recent-posts, and so on). Each row holds a serialized, multi-dimensional array covering every instance of that widget type on the site, keyed by numeric instance ID. This is documented directly in WordPress's own WP_Widget class reference: saving a widget calls update_option("widget_" . $id_base, $settings), and loading it unserializes that same row back.

That split matters. A broken domain-change search-replace can corrupt several of these rows in one pass — sidebars_widgets plus one widget_* row per widget type actually in use — rather than a single row the way deactivating one plugin touches just active_plugins. Some widget types survive untouched while others go blank, which is why the damage looks partial and confusing instead of an obvious full-site failure.

The corruption mechanism itself is the same one behind most serialized-data breakage on WordPress: a PHP-serialized string encodes its own byte length as part of the format (s:LENGTH:"value"). A plain text find-and-replace that swaps olddomain.com for newdomain.com inside one of these values changes the string's length without updating that encoded length prefix. unserialize() then fails silently, and WordPress falls back to rendering nothing for that option rather than throwing a visible error. WP Engine's guide to serialized WordPress data covers this mechanic in more depth if you want the full picture.

If you're on the block-based Widgets Editor (WordPress 5.8 and later), this still applies the same way. Block widgets are stored inside an invisible widget_block widget instance. That instance is itself just another serialized wp_options row under the same mechanism described above — confirmed by the WordPress core team's own announcement post. You don't need to figure out which editor a site uses before applying the fix below.

Fix it: lowest-risk steps first

Step 1 — Confirm it's corruption, not something else

Open the relevant widget_* rows in phpMyAdmin (or your host's database tool) and look at option_value. A garbled or oddly truncated string — not a clean, readable serialized array — confirms corrupted data rather than, say, a theme conflict or caching issue hiding the widget area. If the values look intact, the cause is probably elsewhere; don't apply the fixes below to data that isn't actually broken.

Step 2 — Back up before touching anything

Export the affected wp_options rows, or take a full database backup, before making any change. This is what makes every step below reversible if the wrong row gets edited.

Step 3 — Re-run a serialization-safe search-replace (the fix for most readers)

If WP-CLI is available — via SSH, or your hosting panel's built-in terminal — this is the fastest, safest fix:

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --precise --dry-run

Review the dry-run output, then run it again without --dry-run to apply it for real. The --precise flag matters: it unserializes, replaces, and correctly re-serializes each affected value, instead of corrupting it further the way a raw SQL REPLACE() query would — see WP-CLI's own search-replace documentation for the full set of flags. This is the same command already covered step-by-step on All-in-One WP Migration Didn't Replace All Your URLs, including how to handle multiple URL formats — follow that article's Step 3 for the full walkthrough rather than repeating it here.

Step 4 — No WP-CLI or SSH access? Restore from a pre-migration backup

Paste the original values for the affected sidebars_widgets and widget_* rows back in from a backup taken before the domain change. Then redo the domain change using a serialization-safe method — a reputable migration plugin's own search-replace tool, or WP-CLI if it becomes available — rather than a plain text find-and-replace.

Step 5 — Narrower case: you know exactly which row broke and have no clean backup

Manually correcting a single corrupted serialized string is possible, but it's the same higher-risk, hand-edit-the-format mechanic already covered in depth in Step 4 of No FTP Access — Deactivate a Broken Plugin via phpMyAdmin: getting a string's length or the array's entry count even slightly wrong corrupts the row further. Read that walkthrough before attempting a manual edit here — the mechanics are identical, only the option name differs.

Verify the fix

Reload the front end and check the previously-empty widget areas specifically, not just that the homepage loads. Confirm the widget content is actually correct, too — a corrupted-then-restored row can look non-empty while still holding stale, pre-migration data if the wrong backup version was used to restore it.

If you need to roll back

Paste the original option values you saved in Step 2 back into their rows. This is why saving them first, before any search-replace or manual edit, isn't optional.

Related fixes

FAQ

Why did only some of my widgets disappear, not all of them?

Because widget data isn't stored in one place. Which widgets go where is one option (sidebars_widgets), but each widget type's actual settings live in their own separate option row. A broken search-replace can corrupt some of those rows and leave others untouched, which is why the damage looks partial instead of affecting every widget at once.

Do I need WP-CLI, or can I fix this entirely through phpMyAdmin?

WP-CLI's search-replace --precise is the fastest and safest option if you have SSH or panel terminal access, since it handles the re-serialization automatically. Without it, restoring the affected rows from a pre-migration backup through phpMyAdmin works too — it just requires having that backup available, and redoing the domain change with a serialization-safe method afterward.

I'm using the block-based Widgets Editor — does this fix still apply to me?

Yes. Block widgets are stored inside an invisible widget_block widget instance, which is itself a serialized wp_options row under the same storage mechanism as classic widgets. The cause and the fix are the same regardless of which widgets editor a site uses.