How to run a safe search and replace across your whole WordPress site

When do you need a site-wide search and replace?

You need one whenever the same piece of text sits in more places than you would ever edit by hand. The usual reasons are:

• A new domain or HTTPS. Every internal link and image address still points at http://oldsite.com.
• A rebrand. The business name, a product name or a slogan is in hundreds of posts, menus and SEO titles.
• New contact details. A phone number or email address in the header, the footer, a dozen pages and the contact form notices.
• Moved files. Images now load from a CDN or a different folder, so their addresses have to change.
• A tool you dropped. An old plugin left shortcodes or tracking codes behind that now print as plain text.

On a site that is a few months old, editing each page is not realistic, and it is the easiest way to miss the one copy a customer sees. A proper search and replace changes every copy in one run.

Where does WordPress keep the text you want to change?

Not just in your posts. A WordPress site keeps text in several database tables, and a search that only looks at page content will miss most of them:

The table names use your own prefix, so wp_ may be something else on your site. Some tools search only the tables WordPress itself registers unless you ask for all of them, which is why plugin tables are so often missed.

Why a plain SQL replace breaks WordPress

WordPress stores many settings as PHP serialized data, and serialized data records the length of every piece of text. Change the text without changing that number and WordPress can no longer read the setting. This is the one mistake that turns a simple change into a broken site.

Here is a widget setting holding a 22-character address:

a:1:{s:3:"url";s:22:"https://oldsite.com/me";}

Replace oldsite.com with new-business-site.com using SQL and you get this:

a:1:{s:3:"url";s:22:"https://new-business-site.com/me";}

The text is now 32 characters long, but the setting still says s:22. PHP refuses to read it, and the widget, theme option or plugin setting quietly goes back to its default or disappears. Nothing warns you; you find out when a client asks where their footer went.

A proper search and replace tool unpacks the serialized value, changes the text, and packs it again with the right lengths. That is the main reason to use a tool built for the job instead of a query in phpMyAdmin. The WordPress migration guide warns about exactly this.

Why page builders need extra care

Serialized data is the problem everyone writes about. Page builders are the one that catches people now. Elementor, Divi, Beaver Builder, Bricks and others keep their own copy of your content, usually as JSON in post meta, beside the HTML that WordPress shows. Two things go wrong:

• The text is stored differently. JSON escapes slashes and quotes, so https://oldsite.com can be saved as https:\/\/oldsite.com. A search for the plain address finds the HTML copy and misses the builder copy.
• One copy changes and the other does not. The page looks right until someone opens it in the builder and saves it, and the old text comes back.

Before any site-wide change on a site built with a page builder, check that your tool searches the builder data and changes every copy of the sentence together. After the change, regenerate the builder's CSS (Elementor has a Regenerate files button under Tools) and empty the caches.

Five ways to search and replace in WordPress, compared

Every serious option handles serialized data. Where they differ is how you see the changes first, whether you can undo, and whether they cope with page builders and many sites:

A sixth option, the standalone Search Replace DB script from interconnect/it, is aimed at developers moving a site by hand. It is a PHP file you upload to the server, so it should be deleted as soon as you have finished.

How to run a search and replace safely, step by step

Whatever tool you choose, the safe order is the same:

1. Back up the database. Take a fresh database backup, or make sure the tool you use can undo the change, before anything is written.
2. Write the exact text to find. Search for the most specific version of the text, such as https://oldsite.com with the protocol, so nothing else that happens to contain the words is caught.
3. Run a dry run first. Run the search with a dry run or preview, so you see how many fields and which pages would change before anything is saved.
4. Read the matches, not just the count. Open a few of the matches, leave out any that should stay, and keep the GUID column out of a domain change.
5. Run the replace. Run the change for real on the tables or pages you checked, with a tool that handles serialized data.
6. Empty every cache and check the site. Clear the page cache, the object cache and any CDN, then open the changed pages in a private window on a computer and a phone.

A dry run that reports thousands of changes when you expected a few dozen is the most useful warning you will get. Stop and make the search text more specific.

How to search and replace with the Better Search Replace plugin

Better Search Replace, now by WP Engine, is the most used plugin for this, with over a million active installations. It handles serialized data in every table and has a dry run.

1. Install and activate Better Search Replace from Plugins, then Add New.
2. Go to Tools, then Better Search Replace.
3. Enter the exact text in Search for and the new text in Replace with.
4. Select the tables. For a domain or address change, select them all, so plugin tables are included.
5. Leave Run as dry run? ticked and run it. Check the number of changes against what you expected.
6. Untick the dry run, run it again, then empty your caches.

The free version tells you how many fields would change, not which ones. If you need to see the actual changes before you commit, the Pro version adds that, or use a tool with a full preview. Deactivate the plugin when you have finished.

How to search and replace with WP-CLI

If you have SSH access, WP-CLI's search-replace command is the fastest option and the one most hosts use for migrations. It handles serialized data and skips tables without a primary key. Always start with a dry run:

wp search-replace 'https://oldsite.com' 'https://newsite.com' --skip-columns=guid --dry-run

When the report looks right, run the same command without --dry-run. The options worth knowing:

By default the command only looks at tables registered with WordPress, so add --all-tables-with-prefix when a plugin keeps your old text in a table of its own. The --regex option exists, but the documentation warns it is many times slower.

How to search and replace from your WPCentrify dashboard

If you look after several WordPress sites, the database tools above have two gaps: you see a count instead of the actual sentences, and the only undo is restoring a backup. WPCentrify Find & Replace was built for the everyday version of this job, changing words and links on live client sites, without signing in to each one.

1. Search. Open the website in WPCentrify and go to the Find & Replace tab. Type the words or paste a sentence straight off the live site; curly quotes, dashes and spacing still match.
2. Review. Every match is listed on its page, with the words around it, so you can see a phone number in a footer apart from the same digits in an order number.
3. Choose. Tick the matches to change, leave the rest. Filter by kind of page or field, match whole words or case, and export a report first if a client wants to approve it.
4. Replace. Check the preview and press Replace. Each change is checked before it is written, and every copy a page builder keeps of the same sentence changes together, so the layout stays as it was.

What makes it safer on a live site:

• It searches page and post content, titles, excerpts, headers, footers, reusable blocks, menus, link addresses, image alt text, custom fields and the SEO titles and descriptions from Yoast, Rank Math, SEOPress, The SEO Framework and Slim SEO.
• Changes can be made on Gutenberg, the Classic editor, Elementor, Divi 4 and 5, WPBakery, Avada, Beaver Builder, Bricks, SiteOrigin, SeedProd, Enfold and Themify.
• Every replacement can be undone from the history for 90 days, and every replace and undo is recorded in the Activity feed with who did it.
• Replacements are words only, so code or markup cannot be pasted into a site by accident, and code snippets, orders and form entries are never touched.
• People can be allowed to search without being allowed to change anything.

It is honest about its limits: it works one website at a time, widgets and the theme Customizer are not searched, eight builders (including Oxygen, Brizy and Breakdance) are find only for now, and a full domain migration that has to rewrite siteurl and every table is still a job for WP-CLI. It is included on every paid plan and needs the WPCentrify plugin 2.20.0 or newer.

How to change your domain with search and replace

A domain change is the biggest search and replace most sites ever run, and the database is only part of it:

1. Back up the files and the database on the old domain.
2. Point the new domain at the site and install its SSL certificate.
3. Run the replace with the full address and protocol, for example https://oldsite.com to https://newsite.com, on all tables, skipping the GUID column.
4. If the site also moved from http to https, run a second pass for the http:// version of the old address.
5. Check WP_HOME and WP_SITEURL in wp-config.php, and any address hard-coded in the theme.
6. Re-save the permalinks under Settings, then Permalinks.
7. Add 301 redirects from every old address to the new one, so links and search rankings follow.
8. Empty every cache, then tell Google about the move in Search Console.

The WordPress documentation is blunt about one point: never change the GUID column. Feed readers use it to know which posts they have already shown, so changing it makes old posts appear as new to every subscriber.

What to check after a search and replace

• Empty every cache. The page cache plugin, the server cache (LiteSpeed, Nginx or your host's), the object cache (Redis or Memcached) and any CDN such as Cloudflare. Until you do, visitors see the old text.
• Regenerate page builder files. Elementor and some others save generated CSS that can still hold an old address.
• Open the pages that matter. The homepage, the contact page, a post and a product page, in a private window, on a computer and a phone.
• Check the settings that were serialized. Widgets, the theme's options and one or two plugin settings pages, to be sure nothing went back to its default.
• Search again. Run the same search with the old text. Anything still found is a copy the tool could not reach, often in a widget, the Customizer or a hard-coded theme file.

A checklist for your next site-wide replace

• Fresh database backup, or a tool that can undo
• The exact search text, with the protocol for addresses
• All the tables that hold the text, plugin tables included
• A dry run or preview, and a look at the matches
• The GUID column left alone on a domain change
• Page builder copies changed together
• Page, object and CDN caches emptied
• The key pages checked in a private window, and the search run again

Sources

• wp search-replace, WP-CLI Commands, WordPress Developer Resources
• Migrating WordPress, WordPress Advanced Administration Handbook
• Better Search Replace, WordPress.org plugin directory
• Search Regex, WordPress.org plugin directory
• Search Replace DB, interconnect/it on GitHub
• serialize, PHP Manual

All sources checked on 7 November 2026.