A WordPress admin plugin to Customize and secure your WordPress dashboard
Migration:sfe search and replace. Change domain without breaking your widgets
A serialization-aware search and replace: it rewrites the old site address everywhere in the database without corrupting serialized options — which a hand-written SQL query almost always destroys.The preview isn't optional: without one, execution refuses to run.
How WordPress search and replace works
WordPress stores many settings in serialized form, and every serialized string carries its own length. Replacing oldsite.com with newsite.example through a direct query changes the text but not the number — from that moment the value can no longer be read, and widgets, theme settings and plugin configurations come back empty.
This tool decodes the value, replaces inside the structure — including nested arrays and array keys — and re-encodes it with the correct lengths.
guid column on posts: that's a historical identifier, not an address, and changing it makes feed readers re-announce every old post as new.Take a backup first. There is no undo — the replacement rewrites data in place. The backup module is part of the same suite and takes a minute.
Frequently asked
Five answers on serialization, the mandatory preview, skipped columns and what to do if it goes wrong.
Because WordPress stores many settings in serialized form, and every serialized string carries its own declared length. A direct query replaces the text but leaves that number untouched: from then on the value can no longer be decoded, and widgets, theme settings and plugin configurations come back empty.
A serialization-aware WordPress search and replace decodes the value, replaces inside the structure — including nested arrays and array keys — and re-encodes it with correct lengths. It is the only safe way to change WordPress site URL across an existing database.
No, and that’s deliberate. First you see how many rows match, table by table, with the total. Only then does the execute button appear, and it stays tied to the preview you just saw: change the values in the fields and the preview has to be run again.
So you cannot execute a replacement other than the one you checked. The final confirmation sits on a separate screen, reminding you that this rewrites data across the whole database and cannot be undone.
Every table carrying the site prefix is searched, limited to text columns and to tables with a single primary key. The guid column on posts is always skipped: it is a historical identifier rather than an address, and changing it makes feed readers re-announce every old post as new.
If a serialized value can’t be decoded it is left untouched rather than gambled with. And if it contains an object of a class that no longer exists — typical of uninstalled plugins — the tool stops on that value and doesn’t rewrite it.
Yes. The tool takes two pairs: old and new address, and optionally old and new filesystem path. You need both when a migration changes the domain and the directory at once, which is the usual case when moving from a local development environment to hosting.
When it finishes you get a count of tables, rows and cells changed, so you can check the run touched what you expected.
No, and no tool of this kind can genuinely offer one: the replacement rewrites data in place, so the previous state no longer exists. That is exactly why the preview is mandatory and the confirmation sits on its own screen.
Take a backup before you run it: the module is part of the same suite and takes a minute. If something goes wrong, restoring that archive is the only undo there is.