WordPress Search and Replace on a Live Site in 2026

Why this matters on a live WordPress site

WordPress search and replace looks straightforward until a live site starts showing broken images, stale domain names, or links that still point to staging. On production, you need a method that updates URLs without damaging serialized data, theme settings, or plugin metadata.

This tutorial walks through a safe way to run WordPress search and replace on a fresh VPS with WP-CLI, plus backups, a dry run, and post-change verification. If you are moving a site from staging to production or switching domains after a migration, this sequence avoids most support headaches. If you need the server side first, a Hostperl VPS gives you the control you need for this kind of maintenance.

For readers still planning the move, Hostperl also has practical guides on WordPress staging for safer launches and setting up WordPress staging on a Hostperl VPS.

Before you touch production

Use a maintenance window if the site handles active orders, forms, or member logins. WordPress search and replace can be quick, but you should still back up the database and confirm the exact strings you plan to change.

• Know the old value and the new value exactly, including https, www, and trailing slashes.
• Check whether the site uses a page builder, commerce plugin, or multilingual plugin.
• Confirm that WP-CLI is installed and that you can access the site files.

If you are replacing a full domain after a migration, review your DNS and SSL plan first. A domain change without matching certificate and DNS updates creates avoidable support tickets.

Connect to the server and identify the OS

On your local computer, connect as root first. The IP below is a documentation example only.

ssh root@203.0.113.10

Replace 203.0.113.10 with the real public IP of your VPS. If your provider gives you a default non-root account, you can also use the same example IP with that username after you confirm the login method.

On the VPS as root, check the operating system before you install anything:

cat /etc/os-release

You should see whether the server is Ubuntu, Debian, AlmaLinux, or Rocky Linux. The package commands below are split accordingly.

Update packages and install WP-CLI

On the VPS as root, update the package index first. Then install the tools you need for WordPress search and replace.

Ubuntu and Debian

apt update
apt -y upgrade
apt -y install wp-cli mariadb-client unzip curl

This updates the server and installs WP-CLI plus a database client. If your repository does not offer wp-cli directly, install the packaged version from your distribution or follow the official WP-CLI release method, then confirm the binary works.

wp --info

Successful output should show the WP-CLI version and the PHP runtime it uses.

AlmaLinux and Rocky Linux

dnf -y update
dnf -y install wp-cli mariadb unzip curl

Then check the tool:

wp --info

If WP-CLI is not available from your enabled repositories, install it from the official Phar release and place it in /usr/local/bin/wp with executable permissions.

Find the WordPress path and make a backup

On the VPS as root, go to the site directory. This tutorial uses a common web root layout, but your actual path may differ.

cd /var/www/example.com/public_html
pwd

Before any WordPress search and replace, export the database. Use your real database name, username, and password file if you keep secrets outside the shell history.

wp db export /root/example-com-pre-replace.sql --path=/var/www/example.com/public_html

If you prefer MySQL tools, you can also take a classic dump. That gives you a second restore path if something unexpected appears later.

mysqldump -u wordpress_user -p wordpress_db > /root/example-com-pre-replace-mysql.sql

After the backup, confirm the file exists and is non-empty:

ls -lh /root/example-com-pre-replace.sql /root/example-com-pre-replace-mysql.sql

Run a dry run first

Use a dry run before you write any changes. This shows what WP-CLI will change without modifying the database.

wp search-replace 'https://staging.example.com' 'https://example.com' --dry-run --all-tables --path=/var/www/example.com/public_html

Replace the example values with your real old and new URLs. The dry run should list matching tables and a count of rows that would change. If it touches fewer rows than expected, your content may contain another variant such as http:// or a bare domain without protocol.

For sites with images or hardcoded theme paths, test those values separately. It is better to run two precise replacements than one broad guess.

Run the live WordPress search and replace

Once the dry run looks right, repeat the command without --dry-run. This writes the new value into the database.

wp search-replace 'https://staging.example.com' 'https://example.com' --all-tables --path=/var/www/example.com/public_html

If the site used the old domain in both secure and non-secure forms, run a second pass for the HTTP version:

wp search-replace 'http://staging.example.com' 'https://example.com' --all-tables --path=/var/www/example.com/public_html

That second pass helps when old internal links, embedded media, or plugin settings still point at plain HTTP.

Check for serialization problems and clear caches

WP-CLI handles serialized data correctly, which is why it is safer than a plain database search. Still, you should check that the site opens and that cache layers do not hold old values.

wp cache flush --path=/var/www/example.com/public_html

If the site uses a page cache plugin, clear that plugin too from its dashboard or command line. For object cache-backed sites, restart Redis only if you know the cache is dedicated to this WordPress instance.

If you use a stack from Hostperl, the underlying VPS resources are usually enough for this type of maintenance, and you can keep the workflow simple. For larger stores, consider a stronger plan from dedicated server hosting so the replacement and verification steps do not compete with live traffic.

Verify the database and site response

On the VPS as root or the non-root sudo user, confirm the new URL is present in the database. This is a quick spot check rather than a full audit.

wp db query "SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%example.com%' LIMIT 10;" --path=/var/www/example.com/public_html

You should see rows that contain the new domain. Then test the front end from the server itself.

curl -I https://example.com

Expect a 200 or a 301 to the final canonical URL. If you get a certificate error or a redirect loop, fix DNS, TLS, or the virtual host before you proceed.

From your local computer, load the site and click a few internal links. Images should load from the new domain, and the browser console should stay clear of mixed-content warnings.

When the site is behind Nginx or Apache

WordPress search and replace often exposes old asset URLs in reverse proxy setups. If your site sits behind Nginx, confirm the upstream and server name still match the live domain. If you are using Apache, check that the virtual host document root and ServerName point at the current site.

For customers who want the web layer documented cleanly, the Hostperl knowledge base also covers PHP-FPM behind Nginx and Nginx vs Apache for VPS hosting. Those choices affect how quickly you can test and roll back changes.

Troubleshooting the most common failures

If the site shows old links after the replacement, start with a quick diagnostic. The problem is usually a missed table, a cache layer, or a second domain variant that was not included in the first pass.

wp search-replace 'staging.example.com' 'example.com' --dry-run --all-tables --path=/var/www/example.com/public_html

If you see matching rows in tables you skipped before, rerun the live command with the same table scope.

If WP-CLI reports permission errors, check the site files and ownership:

ls -ld /var/www/example.com/public_html
whoami

On a managed VPS, the web files should usually belong to the site user, not root. Fix ownership only if you know the correct account:

chown -R deploy:deploy /var/www/example.com/public_html

If the restore is needed, stop here and put the database backup back in place:

wp db import /root/example-com-pre-replace.sql --path=/var/www/example.com/public_html

Run that only after you confirm the database file is the correct one. A rollback is safer than trying to guess your way through a broken content swap.

Finish with a small post-migration checklist

• Open the homepage and one blog post from a private browser window.
• Check media uploads for broken image paths.
• Search the site for the old domain name in visible content.
• Confirm the SSL certificate matches the new domain.
• Test forms, checkout, and login flows if the site is an ecommerce or membership build.

Those checks usually take less than ten minutes and catch the issues that matter most to customers. If you are preparing a larger migration, this staging checklist is a useful companion.

FAQ

Does WordPress search and replace break serialized data?

Not if you use WP-CLI. WP-CLI updates serialized values safely, which is why it is preferred over raw SQL string replacement.

Should I replace both http and https?

Yes, if the old site used both forms. Check the dry run first, then run separate replacements for each variant.

Can I do this from the WordPress admin?

You can use plugins, but for a live site WP-CLI is more reliable and easier to audit. It also gives you a dry run and a clean rollback path.

What if the site still shows old URLs after replacement?

Clear caches, check for a second domain variant, and scan theme or plugin settings that store external URLs outside standard post content.

Is a backup really necessary for a small site?

Yes. Even a small site can have serialized settings, plugin metadata, and commerce records that need a clean restore if the replacement goes wrong.