Better Search Replace plugin review and common issues

A successful replacement may still leave content if: (1) some tables were not selected for the search — run again with all tables selected to catch missed locations; (2) the old URL appears in different formats (with/without www, http/https, trailing slash variations) — run separate searches for each URL format variation; (3) content is in theme options, customizer settings, or plugin-specific options tables that may use different serialization formats; (4) JavaScript files or CSS files reference old URLs (not in database); (5) Elementor or other page builders store data in JSON format in their own tables — check elementor_data in the postmeta table separately.

For large databases: (1) select specific tables rather than all tables — prioritize wp_posts, wp_postmeta, wp_options, and wp_usermeta for most URL migration needs; (2) increase PHP max_execution_time in wp-config.php or php.ini (set_time_limit(600) for 10 minutes); (3) for very large databases, use WP-CLI instead: wp search-replace “old.url” “new.url” –all-tables — WP-CLI runs without browser timeout constraints; (4) WP Migrate (paid, by same developer) handles large-scale replacements more robustly with progress tracking.

If a replacement broke serialized data: restore from a database backup immediately. If no backup exists: (1) use phpMyAdmin to manually check recently modified tables (look at wp_options first — serialized data corruption there is common); (2) try running Better Search Replace with the reverse replacement to undo changes (search for new value, replace with old value — though this may not perfectly restore broken serialization); (3) Better Search Replace is designed to handle serialized data correctly, but incorrect source/destination values (replacing partial strings inside serialized keys) can break serialization. Always backup before running.

For an HTTP → HTTPS migration: (1) create a full database backup; (2) in Better Search Replace, enter “http://yourdomain.com” in the search field and “https://yourdomain.com” in the replace field; (3) run Dry Run first to see how many replacements will occur; (4) select all tables (or at minimum: wp_posts, wp_postmeta, wp_options, wp_usermeta) and execute; (5) also update WordPress siteurl and home in Settings → General if not done already. Run a second search for http://www.yourdomain.com → https://www.yourdomain.com to catch www-prefixed variations.

After a domain change, WooCommerce product images may break if image URLs are stored with the old domain. After running the standard domain replacement (which updates most URLs), also check: (1) wp_postmeta where meta_key is _product_image_gallery — these store comma-separated image IDs which should not need replacement; (2) wp_postmeta where meta_key is _thumbnail_id — these store IDs, not URLs; (3) run Better Search Replace on the domain portion of any stored absolute image URLs that appear in product descriptions. Also run WooCommerce → System Status → Tools → Regenerate Thumbnails after domain migration to rebuild image size cache.

No — always create a full database backup before running any search and replace operation. Better Search Replace does not create automatic backups in the free version. Use the Dry Run option first to preview the number of replacements. Even with correct values, an unexpected edge case (unusual data format, serialization complexity) could cause issues that require restoration from backup. Use UpdraftPlus, Duplicator, or your hosting’s backup tool to create a backup before running.

Yes — leave the “Replace With” field empty to replace the search term with an empty string (effectively deleting all instances). This is useful for cleaning up shortcode remnants, removing plugin-specific markup after deactivation, or removing test content. Use Dry Run first to verify the scope of the deletion before executing. Empty string replacement on serialized data requires careful validation — removing a key from within a serialized string without adjusting the array count will corrupt the data.

Yes, that can happen, especially on older sites with many plugins. This usually happens when the plugin, theme, and add-ons are updated out of sequence. In most cases, testing on staging catches the issue before it reaches the live site. From experience, backups and changelog reviews save a lot of cleanup time.

Start by checking whether another plugin already does the same job. In most cases, overlap is what creates avoidable conflicts and performance issues. A common issue is installing a plugin because it looks convenient without checking the stack first. From experience, a short compatibility review avoids most of the pain later.