Migrating a WordPress site to a new domain or switching from HTTP to HTTPS always involves updating URLs stored in the database. WordPress distributes these references across multiple tables: post content and GUIDs live in wp_posts, widget settings and the site URL live in wp_options, and custom field values are stored in wp_postmeta. A simple SQL REPLACE statement handles non-serialized text columns perfectly well. However, WordPress also serializes PHP arrays and objects when writing many options and meta values to the database, and serialized strings embed the byte length of every value as part of their format. Running a plain text substitution on a serialized string changes the stored lengths without updating the byte-count markers, which breaks deserialization and causes WordPress to silently discard or corrupt the affected data. This is one of the most common causes of broken widget configurations and plugin settings after a domain migration. For full-site migrations the safest tool is WP-CLI’s wp search-replace command, which deserializes data, performs the substitution, and re-serializes it correctly. But for the most common scenarios — updating post content, post GUIDs, and the siteurl and home option values, none of which are serialized — direct SQL REPLACE queries are fast, reliable, and require no extra tools beyond phpMyAdmin or a MySQL terminal. Always run a SELECT preview with the same WHERE condition first to see exactly how many rows will be affected. And always take a full database backup before running any bulk UPDATE statement. MySQL’s REPLACE(column, old, new) function performs a case-sensitive, in-place substitution and returns the modified string — the WHERE clause pre-filters rows so only matching records are touched, keeping execution fast even on large tables. The queries below cover the four most common replacement targets in a standard WordPress installation.
Problem: You need to replace an old domain name or URL scheme across the WordPress database after migration.
Solution: Run the following queries in phpMyAdmin or a MySQL client (replace wp_ with your table prefix):
-- 1. Preview rows that will be affected
SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%http://old-domain.com%';
-- 2. Replace in post content
UPDATE wp_posts
SET post_content = REPLACE(post_content, 'http://old-domain.com', 'https://new-domain.com')
WHERE post_content LIKE '%http://old-domain.com%';
-- 3. Update post GUIDs
UPDATE wp_posts
SET guid = REPLACE(guid, 'http://old-domain.com', 'https://new-domain.com');
-- 4. Update site URL and home URL in options
UPDATE wp_options
SET option_value = REPLACE(option_value, 'http://old-domain.com', 'https://new-domain.com')
WHERE option_name IN ('siteurl', 'home');NOTE: Never run REPLACE on all rows of wp_options without the WHERE option_name IN (...) constraint — serialized plugin settings stored in that table will break silently. For a complete migration that also covers widget data, nav menu assignments, and plugin configuration stored as serialized meta, use WP-CLI: wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables. After the replacement, flush the WordPress object cache and regenerate permalinks by visiting Settings → Permalinks and clicking Save.