How to Search and Replace in the WordPress Database Safely

Moving a site to a new domain, switching from http:// to https://, or renaming something that appears in hundreds of posts: all of these need a search and replace across the database. Done wrong, it breaks widgets, settings and page-builder layouts. Done right, it takes a minute.

Why a plain SQL replace breaks things

WordPress and many plugins store settings as serialized PHP data, which records the length of every string:

s:19:"http://old-site.com";

If you replace http://old-site.com with https://new-site.com directly in SQL, the text is 20 characters long but the data still says s:19. PHP can no longer read it, and the setting silently resets. Page builders and widgets are common victims. A proper search-replace tool unserializes, replaces and re-serializes the data so the lengths stay correct.

Before you start

1. Take a full database backup. Search-replace can’t be undone.
2. Test on staging if the site matters.
3. Be specific. Replace https://old-site.com rather than old-site, so you don’t change unrelated text.
4. Do a dry run first and look at how many replacements it would make.

Option 1: WP-CLI (the most reliable)

If you have SSH access, WP-CLI handles serialized data correctly:

# See what would change, without changing anything
wp search-replace 'https://old-site.com' 'https://new-site.com' --dry-run

# Run it, skipping the GUID column
wp search-replace 'https://old-site.com' 'https://new-site.com' --skip-columns=guid

# Clear caches afterwards
wp cache flush

Skip the guid column: WordPress uses it as a permanent ID for feeds, and it shouldn’t change.

Option 2: a plugin in wp-admin

Without SSH, use a search-replace plugin that handles serialized data and offers a dry run, then check the result. Some page builders keep their own caches or encoded data; after replacing, regenerate their CSS or caches from the builder’s settings if they offer that.

After the replace

• Log in again if you changed the site URL (cookies belong to the old domain).
• Clear every cache: page cache, object cache, CDN.
• Check pages built with page builders, menus, widgets and forms.
• Look for mixed-content warnings in the browser console if you switched to https.

DevKit

DevKit bundles developer tools inside wp-admin, including a Search & Replace screen. Its documentation notes it isn’t yet fully compatible with page-builder data, so for sites built with a builder, prefer WP-CLI for now. DevKit’s other tools help around a migration: regenerating salts, reading the error log without FTP, and switching on maintenance mode while you work.