Introduction

If a WordPress site breaks after migration and someone ran a raw search-replace directly against the database, the real problem is often corrupted serialized data. This is not the same as a simple home URL mismatch. WordPress may still connect to the database, but arrays and objects stored in options, widget settings, builder metadata, and plugin configuration no longer match their recorded string lengths. Once that happens, WordPress and plugins start reading partial or invalid values.

Treat this as a data integrity problem. Do not keep running more direct replacements to see if the site improves. The safe path is to preserve the current state, restore clean data if possible, and rerun the domain replacement with a WordPress-aware method.

Symptoms

  • Widgets disappear or move into inactive widgets after migration
  • Theme settings, menus, or Customizer values reset unexpectedly
  • Page builder layouts break or show only part of their content
  • Plugin settings screens behave inconsistently even though the database import completed
  • The site is not simply redirecting wrong; structured settings across the site are broken
  • PHP warnings or notices appear around malformed serialized data or failed unserialize() calls

Common Causes

  • A raw SQL REPLACE() query was run against WordPress tables
  • The SQL dump was edited with a text editor before import
  • phpMyAdmin or another generic database tool was used for a global string replacement
  • The migration changed protocol or domain length inside serialized option values
  • The site relies heavily on plugins, builders, or theme settings stored in serialized arrays
  • Multiple unsafe replacement passes were run while trying to fix earlier migration issues

Step-by-Step Fix

  1. Stop running direct database replacements immediately, because each unsafe pass can corrupt more serialized rows and make recovery harder.
  2. Confirm that the break affects structured settings such as widgets, builder content, theme mods, or plugin options, because this separates serialized-data corruption from simpler URL or redirect problems.
  3. Take a full backup of the current broken database and site files before changing anything else, because you may need to compare rows or recover specific settings later.
  4. Restore the last clean database copy from before the unsafe search-replace if you have one, because that is the fastest way back to valid serialized values.
  5. Rerun the domain or protocol replacement only with a serialization-aware WordPress tool, because WordPress-safe replacement methods recalculate string lengths correctly.
  6. Limit the replacement scope to the exact old and new values you actually need, because broad or careless replacements create fresh corruption even with better tools.
  7. Recheck high-impact data areas such as wp_options, wp_postmeta, widget settings, theme mods, and builder metadata, because those are where serialized corruption usually hurts first.
  8. Clear caches and regenerate derived assets after the safe replacement, because cached output can make a repaired site still look broken.
  9. Test the site methodically and repair any remaining damaged settings from exports, known-good rows, or manual reconfiguration instead of applying more raw replacements, because targeted recovery is safer than another global edit.