WordPress Search Replace: Safe Database Guide

Running a search-and-replace directly on your WordPress database is the fastest way to update URLs, change a domain name, or fix hardcoded links after moving a site. But a careless find-and-replace can corrupt serialized data, break your site, or leave it unreachable. This guide walks you through a safe, step-by-step process using phpMyAdmin and a dedicated search-replace tool, so you can make changes without losing sleep.

What You’ll Need

• Access to your hosting control panel (cPanel, Plesk, or similar).
• phpMyAdmin or another database management tool.
• A full database backup (created right before you start).
• Your site’s current URL and the new URL you want to use.
• An FTP client or file manager in your hosting panel (for the backup and optional plugin method).

Step-by-Step

1. Back up your database. In phpMyAdmin, select your WordPress database from the left sidebar. Click the “Export” tab, choose “Quick” or “Custom” (keep the default SQL format), and click “Go.” Save the file to your computer. This is your safety net.
2. Back up your files (optional but recommended). Use FTP or your file manager to download your entire wp-content folder and wp-config.php. If something goes wrong, you can restore both files and database.
3. Identify the exact strings to replace. For a domain change, you typically replace http://old-domain.com with https://new-domain.com. Be precise: include the protocol (http/https) and the full domain. Avoid replacing just a partial word like “old” because it could appear in other contexts.
4. Choose your tool. The safest approach is to use a dedicated search-replace script like WP-CLI (if you have command-line access) or a plugin like “Better Search Replace” (which handles serialized data correctly). If you must use phpMyAdmin’s SQL query, you risk breaking serialized arrays—use it only for simple, non-serialized data and with extreme caution.
5. If using WP-CLI: Run wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables --precise --recurse-objects --dry-run first to see what will change. Then run the command without --dry-run to execute it. This method is fast and safe because WP-CLI understands serialized data.
6. If using a plugin: Install and activate “Better Search Replace” (or a similar reputable plugin). Go to Tools → Better Search Replace. Enter the search string and replace string. Select all tables (or only the ones you need). Check “Dry Run” first to preview the number of changes. Then run the real operation. After it finishes, deactivate and delete the plugin.
7. If using phpMyAdmin (last resort): Click on your database name, then the “SQL” tab. Enter a query like:
   UPDATE wp_options SET option_value = REPLACE(option_value, 'http://old.com', 'https://new.com');
   Repeat for each table that contains URLs (e.g., wp_posts, wp_postmeta, wp_comments). This method does NOT handle serialized data correctly and can corrupt your site. Only use it if you have no other option and you are certain your data is not serialized.
8. Clear any caching. After the replace, clear your WordPress cache (if you use a caching plugin) and your browser cache. If you changed your domain, you may also need to update the siteurl and home options in the wp_options table (though most tools do this automatically).
9. Test your site thoroughly. Visit the front page, a few posts, the admin dashboard, and check for broken links or missing images. If you changed the domain, log in via the new URL.

Common Mistakes

• Using phpMyAdmin’s SQL REPLACE on all tables blindly. This breaks serialized data (arrays and objects) because it changes the string length without updating the stored length values. This can make your site throw errors or show blank pages.
• Forgetting to include the protocol. If you replace old-domain.com without http://, you might also replace it in places like https://old-domain.com or old-domain.com/path, which can cause partial replacements.
• Not doing a dry run first. Always preview what will be replaced. A dry run shows you the number of occurrences and lets you catch mistakes before they become permanent.
• Skipping the backup. Even a simple replace can have unexpected side effects. A backup is your only way to revert if something goes wrong.
• Replacing too broadly. For example, replacing “http” with “https” everywhere will break links that are already https or that point to external http sites. Be specific.

Tips

• Use a dedicated tool. WP-CLI and Better Search Replace are built to handle serialized data. They are the safest options.
• Test on a staging site first. If possible, copy your site to a staging environment and run the search-replace there. This lets you see the result without risking your live site.
• Keep a log of what you replaced. Write down the exact search and replace strings, the date, and the tables affected. This helps if you need to troubleshoot later.
• Update your wp-config.php if needed. If you changed your domain, you may need to update the WP_HOME and WP_SITEURL constants to the new URL.
• Check for hardcoded URLs in your theme files. A database search-replace won’t fix URLs that are hardcoded in PHP files. Use a code editor to find and replace those separately.

Troubleshooting

If your site shows a “database connection error” after the replace: This usually means the database credentials in wp-config.php are wrong or the database was corrupted. Restore your backup immediately.

If your site loads but looks broken (no styles, images missing): The URLs in the database are probably not fully replaced. Check that you replaced both the siteurl and home options, and that you included the correct protocol. You may need to run the replace again with a more specific string.

If you see PHP errors about serialized data: Your replace corrupted serialized arrays. Restore your backup and use a proper tool like WP-CLI or Better Search Replace.

If you cannot log into the admin dashboard: This can happen if the replace changed the admin_url or the user meta. Try accessing wp-admin via the new URL. If that fails, restore the backup and redo the replace with the correct strings.

If the replace worked but some pages still show old URLs: Clear all caches (WordPress, browser, CDN). Also check for any hardcoded URLs in your theme or plugins.

Frequently Asked Questions

Q: Can I use phpMyAdmin to do a search-replace safely?
A: It’s risky because it doesn’t handle serialized data. If you must, use a plugin or WP-CLI. If you have no other choice, test on a staging site first and always have a backup.

Q: What is serialized data and why does it break?
A: Serialized data is a way WordPress stores arrays and objects in the database. It includes a character count. A simple SQL REPLACE changes the string length but not the stored count, making the data unreadable.

Q: How do I change my WordPress site URL after moving to a new domain?
A: Use the same search-replace process, replacing the old domain with the new one. Also update the siteurl and home options in wp_options. WP-CLI and Better Search Replace do this automatically.

Q: Is it safe to use a plugin like Better Search Replace?
A: Yes, it’s designed for this purpose and handles serialized data correctly. Always do a dry run first and back up your database.

Q: What if I only need to replace a word in my posts, not a URL?
A: You can use the same process. Just enter the word you want to replace and the new word. Be careful to avoid replacing it in URLs or other unintended places.

Q: Can I undo a search-replace if I don’t have a backup?
A: No, there is no undo. That’s why a backup is essential. If you don’t have one, you may need to manually revert the changes, which is nearly impossible for large databases.

Related

• Mail Problems in Catalina & Fixes
• MW4 Campaign Branches vs Black Ops 6 Choices
• HP’s History of Innovation: 10 Products That Changed Everything