How to Safely Search and Replace URLs in WordPress (With Undo)

You're mid-migration or mid-rebrand, you need to swap an old URL for a new one across the whole site, and you've just read enough horror stories to be nervous about clicking "Run." That nervousness is correct. A bad WordPress search and replace can quietly corrupt page-builder layouts, blank out widgets, and leave you guessing what broke and when.

This guide shows you how to do it safely — back up first, preview before you commit, apply only the rows you approve, and undo with one click if something looks off. The safety net is the whole point.

When you need a site-wide search and replace

A WordPress search and replace isn't an everyday task, but when you need it, you need it on every table at once. The common jobs:

Moving to a new domain. Every internal link, image src, and stored option still points at the old domain after you copy the files and database across.
Pushing staging to live. Your staging.example.com URLs need to become example.com the moment you go live, or half the site loads from the wrong place.
Fixing HTTP→HTTPS. After installing an SSL certificate, content still hard-codes http:// URLs, triggering mixed-content warnings and breaking the padlock.
Rebranding. A company name, product name, or path that appears in hundreds of posts needs to change everywhere consistently.
A repeated typo or wrong URL. One affiliate link, CDN path, or misspelled slug copy-pasted across the archive.
Swapping an image everywhere. A logo or banner referenced by URL across posts, options, and metadata.

In all of these, hand-editing posts isn't viable — the strings live in the database, across multiple tables, including serialized blobs you can't safely touch by hand.

Why you can't just run an SQL query — the serialized-data trap

The instinct is to open phpMyAdmin and run UPDATE wp_posts SET post_content = REPLACE(...). Don't. It works fine for plain post content, but it will silently corrupt the most important parts of your site.

WordPress stores a huge amount of configuration as serialized data — PHP arrays and objects flattened into a single text string. Page builders (Elementor, Divi, Beaver Builder), theme customizer settings, widget configurations, and most plugin options are all serialized. A serialized string records the exact byte length of every value it contains, like this:

s:24:"https://oldsite.com/image";

That s:24 says "the following string is 24 characters long." If a raw SQL REPLACE swaps oldsite.com (11 chars) for mynewbrand.io (13 chars), the text changes but the length counter doesn't. Now the string claims to be 24 characters when it's actually 26. PHP can no longer unserialize it, so WordPress reads it as empty — and your Elementor section, your widget, or your theme settings vanish.

This is the single biggest reason "I ran a quick SQL query" turns into "my homepage is blank." A proper search-and-replace tool unserializes each value, replaces inside it, and recounts the lengths before saving — so the data stays valid. Update URLs handles this automatically; if you want the mechanics, see how to update serialized data effectively. The deeper dive on doing it without corruption is in search and replace without breaking serialized data.

Step 1 — Always back up first

Every search-and-replace guide says "back up first," and almost nobody does it, because the real backup step is a chore: dump the database, store it somewhere, and figure out how to restore it under pressure if something goes wrong.

That friction is the actual problem. The fix is removing the excuse. Update URLs has a built-in one-click database backup — you snapshot the database from inside the same screen where you're about to make changes, and restore it with one click if you need to. No phpMyAdmin export, no SSH, no separate plugin. Walkthrough here: one-click database import and export.

Take the backup immediately before you run the replace, not yesterday. State changes between then and now, and you want your rollback point to be the exact moment before the operation. If you're on managed hosting with automatic backups, great — but those can take time to restore and may roll back unrelated changes too. A local, one-click snapshot is faster and surgical.

If you haven't installed the plugin yet, start with the installation guide.

Step 2 — Search and replace, step by step

Here's the full safe workflow. The order matters: preview before you apply, and never apply blind.

Install and open Update URLs. After installation, find it in your WordPress admin. (Free version covers the core search-and-replace; the free vs Pro breakdown shows what's included.)
Enter your old and new strings. Type the exact string you're searching for (e.g. http://staging.example.com) and the replacement (e.g. https://example.com). Be specific — http:// vs https://, trailing slashes, and www all matter. The step-by-step is in how to do search and replace text in WordPress.
Pick your tables. By default you can scan everything, but on a large site it's faster and safer to target only the tables that hold the string — usually wp_posts, wp_postmeta, and wp_options. The selected-tables guide explains the table picker.
Run a dry run. This is the step that separates safe operators from gamblers. A dry run scans the database and shows you exactly what would change — every matching row, in which table, with the old and new values side by side — without writing anything. Read it. See how to do a dry run before search and replace.
Review and selectively apply. Here's the edge most tools don't have: you don't have to accept all-or-nothing. With selective apply, you check the rows you approve and skip the ones you don't — so if the dry run surfaces a match inside a table you didn't expect, you simply leave it unchecked. Apply only the approved rows.
Verify. Load the site in an incognito window, click through a few key pages, and confirm images, links, and layouts resolve to the new URL. Check a page-builder page specifically, since that's where serialized data lives.

That's it. The combination of dry-run preview plus selective apply means you're never guessing what the tool did — you decided every change before it happened.

Step 3 — Made a mistake? How to undo it

Even with a dry run, you'll occasionally realize after the fact that you replaced the wrong string, or changed it everywhere when you meant to change it in one place. This is where most tools leave you stranded. Better Search Replace, for instance, has no undo — once it writes, your only recovery is restoring a database backup, assuming you took one.

Update URLs keeps a full history of every operation and lets you roll back any replace with one click. Open the history, find the operation, and click undo — it reverses exactly that change set and nothing else. No restoring a whole database, no losing the orders or comments that came in since. Details in how to view search and replace history and undo changes.

This is the feature that turns search-and-replace from a high-stakes, hold-your-breath operation into a routine one. If you want the focused walkthrough, see how to undo a search and replace. And if you're specifically weighing tools, here's the honest Better Search Replace alternative comparison.

Specific jobs

The workflow above is the same every time, but a few common jobs have their own gotchas worth calling out.

Moving WordPress to a new domain

A domain move is the classic case: copy files and database, then replace every instance of the old domain with the new one across wp_posts, wp_postmeta, and wp_options. The catch is the siteurl and home values in wp_options — get those wrong and you can lock yourself out of admin. Do the replace with a dry run first and verify those two rows specifically. The full procedure, including the order of operations, is in move WordPress to a new domain. If you only need to fix the core address, change the WordPress URL in the database covers the narrower job.

Fixing mixed-content HTTP→HTTPS warnings

After adding SSL, your pages still embed http:// resources — images, scripts, stylesheets — and browsers flag mixed content, breaking the padlock. The fix is a site-wide replace of http://yourdomain.com with https://yourdomain.com (scope it to your own domain so you don't rewrite external links). Because some of those URLs live in serialized page-builder data, do it with a serialization-aware tool, not raw SQL. Step-by-step: fix mixed content (HTTP→HTTPS).

Bulk-replacing image / attachment URLs

When you move media to a CDN, change your uploads path, or swap a logo that's referenced everywhere, the image URLs are scattered across post content, postmeta, and options — including the GUID field, which needs careful handling (see what GUID is and how to replace it). Update URLs can target attachment and image URLs directly. The dedicated guide is bulk-replace image & attachment URLs.

Save time on repeat jobs with profiles & history

If you do this once a year, the dry-run-and-verify flow is enough. If you're an agency or freelancer running staging→live promotions every week, the repetition adds up — and that's where two features earn their keep.

Save and load profiles lets you store a search-and-replace configuration — strings, table selection, options — and reload it for the next site or the next deploy. No re-typing the same staging. → live. swap a hundred times. See how to save and load search and replace profiles.

History keeps a record of every operation you've run, so you can audit what changed on a client site, re-run a known-good replace, or undo one weeks later. Combined with profiles, it turns a risky manual chore into a repeatable, documented process. Pro adds a few extras worth knowing about — see search & replace Pro and Pro settings.

Conclusion

A WordPress search and replace is only scary when you're flying blind. Make it safe and it becomes routine: take a one-click backup, preview every change with a dry run, apply only the rows you approve, verify in incognito, and keep a one-click undo in your back pocket for the times you get it wrong. That safety stack — backup, dry run, selective apply, undo — is exactly what Update URLs is built around, including the rollback that raw SQL and several popular tools simply can't offer. Install it on a staging copy first, run a dry run, and you'll never dread the "Run" button again. Grab it from the Update URLs product page.

FAQs

Will this break my serialized data?

Not if you use a serialization-aware tool. Update URLs unserializes each value, replaces inside it, and recounts the byte lengths before saving — so page-builder layouts, widgets, and theme settings stay intact. A raw SQL REPLACE does not do this and will corrupt serialized data. More on the mechanics: update serialized data effectively.

Do I need a backup before running it?

Yes — always. Update URLs includes a one-click database backup so there's no excuse to skip it. Take the snapshot immediately before the replace, not earlier, so your rollback point is the exact pre-operation state.

Can I undo a search and replace?

Yes. Update URLs keeps a full history with one-click undo, reversing exactly that change set without restoring an entire database. This is something Better Search Replace can't do — see the undo guide.

Does it work on large sites?

Yes. Scope the operation to the tables that actually hold the string — usually wp_posts, wp_postmeta, and wp_options — using the selected-tables option to keep it fast. The dry run reports matches before anything is written, so you size the job before committing.

Can I target specific tables?

Yes. The table picker lets you run the replace only on the tables you choose, instead of scanning the entire database — faster on big sites and safer when you want to limit the blast radius. If anything misbehaves, the troubleshooting guide covers the common cases.