Moving a WordPress Site: Data and Redirects

Moving a WordPress site means finishing two jobs that are easy to confuse: carrying files and database across intact, and telling search engines that addresses changed. Short answer: back up first, classify the move, replace old addresses in the database with a tool that respects serialized data, leave the guid column alone, rebuild .htaccess and permalinks, test every redirect, and then watch both sites in Search Console. If you run a blog, a shop or a company site and are about to change host or domain, this order protects your data and gives search engines a clear signal. DNS cutover and TTL belong to a different problem, covered in changing web hosts without losing rankings.

Choosing your route first

Three questions before you start.

1. Do the addresses change? If not, skip search-replace and redirects.
2. Does the data contain serialized values? If so, do not run a plain find-and-replace; use one of the three routes the guide names.
3. Is every old URL mapped to a new one? With no mapping list, do not begin.

Name the type of move

The WordPress guide to moving a site (Opens in a new tab) opens with a fork. If the URLs stay the same, you copy the files and the database, and you update wp-config.php on the new server if the database name or user changed. If the domain or URL path changes, the guide lays out a nine-step sequence. Which fork you are on decides whether search-replace and redirects enter the plan at all.

If you use a translated admin interface, screen and plugin names may differ from the English labels used here.

Splitting a move into two halves

Google's site move with URL changes (Opens in a new tab) documentation starts with general advice: expect ranking fluctuation, change one thing at a time, think about splitting the move, and time it for low traffic. Practical suggestion: do not change host and domain on the same day. Move the host first, watch the site for a few days, then change the domain. If something breaks, you will know which change caused it.

Changes to postpone until after the move

Changing the design, rebuilding the URL structure and rewriting content in bulk, all on the same day as the move, runs against the "change one thing at a time" advice in Google's documentation. Leave those jobs until the move is finished and monitoring has settled. Do not put old addresses into the new sitemap, do not leave internal links pointing at old addresses on the new site, and do not forget to remove noindex tags that were set during development.

Freeze edits and list what exists

Before you begin, write down what the site contains: plugins, themes, custom post types, forms, booking or payment flows, scheduled tasks and outside service connections. That list is also the skeleton of your post-move test plan. Practical suggestion: pause content entry from the moment you export the database until the new site is live. A post, comment or order created in between will not reach the new server and has to be merged by hand later.

Parts of the site that produce data, such as memberships, comments, form entries and orders, deserve extra care in the window. The easiest way to confirm nothing was lost is to note one sample record of each kind before the move and look for the same record afterwards. The documentation has no statement on this; it is a practical suggestion, and you have to build the test for your own site.

Signals that mislead after a move

The first misreading is that keeping the domain makes a move complicated. According to the guide, when addresses and domain stay the same the move is very simple and can be done by moving the files. The second is that copying the database updates every link by itself; if the address changes, the guide asks for sequenced steps. The third is that a redirect can be written anywhere. Google's redirect page recommends a permanent server-side redirect wherever possible and mentions JavaScript redirects only when the other methods are not available.

Taking copies and carrying the database

The WordPress guide treats a backup as a requirement, not a tip: files, images, plugins and the database. Its sequence for a domain change runs like this: download the site files, export the database, store both in a separate folder as a site backup, change the URLs on the old site in Settings, General and expect a 404 page afterwards, download the files again, export the database again, put the new server's database details in wp-config.php, upload the files, and import the database on the new server.

Why two backups

The first download is a clean backup taken before anything changes. The second is taken after the address change and travels to the new host. Keeping the two apart gives you a way back if a replacement goes wrong. The guide says that if one does, you should restore the database from your backup and repeat the steps carefully.

A staging address for rehearsal

The guide notes that you can change siteurl and home in the wp_options table temporarily to test the new server before switching over. A test copy must not be open to search engines; the details are in fixing a staging site indexed by Google.

Rewriting addresses while keeping serialized values intact

Replacing the old address inside the database is the riskiest step. The guide warns that a plain find-and-replace can cause issues with data serialization, because some themes and widgets store string lengths, and those lengths change when the address does. It names three routes: a plugin such as Velvet Blues Update URLs or Better Search Replace if you can reach the dashboard, the WP-CLI search-replace command, or a third-party search-and-replace script for people comfortable with database administration.

The advice to remove the script is a practical suggestion; the documentation says nothing about cleaning up scripts afterwards.

Do not touch guid

The guide is at its most forceful here: never change the contents of the guid column, under any circumstances. The guid is the post identifier that feed readers use to track items, so you skip that column in every search-replace. The guide's WP-CLI example does exactly this with an option that skips the guid column. If you use a plugin, confirm that it leaves guid out.

Which tables to cover, and where the guide disagrees with itself

The guide says the old address can survive in image links, plugin options, upload paths and widgets, and it advises a full database search. Yet the same page also says to perform a search and replace only on the wp_posts table. Those two statements pull in different directions. Practical suggestion: decide the scope yourself before replacing, and know what each table change will do. Transients can be deleted safely because WordPress recreates them.

Post-import commands and stray values

The guide's WP-CLI examples show the shape of the commands: a search-replace from the old address to the new one with the guid column skipped, and two option updates that set home and siteurl. Both settings need the full https:// prefix and no trailing slash. Other places may still hold the old address: image links, plugin options, upload paths and widgets, and some of these are fixed in the admin, for example under Appearance, Widgets. Plugin-specific option values may also need manual updates, and a migration plugin such as Duplicator can move a site between locations if you prefer that route.

Old addresses inside plugin settings

Practical suggestion: after the import, open the settings screens of your form, booking, search and cache plugins one by one and look at any field that holds an address. Even when search-replace updated serialized values correctly, a plugin may keep its own cached copy of the old address. Start with three cheap checks: clear the cache plugin, read the front-end source in a logged-out browser, and open the sitemap address.

Client handover for agencies

When you move a client's site, attach this checklist to the handover and date each step. Tell the client before the move, in writing, that traffic may fluctuate for a while; the Google documentation expects it. For the backlink side of a move, see preserving backlink value during a site migration. Steps and thresholds in the documentation can change; check the current pages before relying on them.

Empty or partial export files

The migration guide also covers moving through export files. It says it is wise to disable all plugins before exporting, because some plugins can conflict with the export and produce an empty file. The same guide notes that the PHP upload limit can be too small for the export file. Practical suggestion: write down the plugin state before you export, and check the file size afterwards.

Multisite and table prefix warnings

For multisite the guide has a clear warning: do not attempt a blanket search-replace without the dedicated search-and-replace script. If you change the table prefix, the guide says the prefixed keys inside the usermeta table must be updated as well. Follow the step-by-step instructions in those sections for a multisite move.

Rewrite rules, permalinks and proving the redirects

The guide calls a backup of .htaccess not a recommendation but a requirement. The order is: back it up, copy any custom rewrite or redirect rules somewhere safe, re-save the Permalinks settings to regenerate the file, re-add your custom rules updated for the new address, and test all redirects.

Server-side permanent redirects

Google's redirects page (Opens in a new tab) says permanent redirects (301 and 308) show the new target in search results, while temporary ones (302, 303 and 307) keep the source page in results. It prefers server-side redirects and gives Apache .htaccess rules among its examples. An instant meta refresh counts as permanent, and a JavaScript location change is a last resort because rendering can fail. For a WordPress move, the server-side rules go in the old domain's .htaccess or in the old host's configuration.

Old-to-new URL map and canonical tags

Google's move documentation asks for a list that maps each old URL to its new one, and for canonical tags, hreflang annotations and internal links to be updated on the new site. In WordPress, internal links are handled by the search-replace, and canonicals by the address setting in your search plugin. A canonical that still points at the old address sends a contradictory signal.

Sitemaps and crawl rules

The documentation says to submit the new sitemap in Search Console and then remove the old one, and to take out any noindex or robots.txt blocks that were only needed during development. For auditing the sitemap, see XML sitemap audit and error fixes.

Testing redirects

Setting up a redirect is half the job. The other half is testing it on purpose. Practical suggestion: pick examples of different types from the mapping list, not random ones, and write down the response code and the target for each.

If you see a chain or a loop, look at the clash between the server rule and the WordPress address setting. On chains, Google's move documentation advises avoiding them where possible.

How long to keep redirects

Google's move documentation tells you to keep redirects for as long as possible and, as a rule, at least one year. The Change of Address tool is for moves between domains or subdomains only; the page says it is not needed for http to https, a www change on the same domain, or path changes. It advises server-side permanent redirects where possible and avoiding chains. The documentation has no statement on TTL.

The redirects page adds that you should use a permanent redirect only when you are sure the change will not be reversed. For a short outage, a temporary redirect sends users elsewhere without changing the place of the original URL in search results.

Monitoring after launch

The documentation asks you to verify both the old and the new site in Search Console and to look at server logs. Expect traffic on the old site to fall as traffic on the new one rises. It says to expect temporary fluctuation in rankings, and that for medium-sized sites it can take a few weeks or more for new URLs to replace the old ones. That duration comes from the page; it is not a forecast for your site.

Planning the way back

A move plan should include the way back. Do not switch off the old server the moment the move ends. Keep the old copy and the database backup for a while, so you can return if the new site shows a serious fault. Practical suggestion: keep the old hosting account open until you have confirmed the redirects and seen the new site start to enter the index in Search Console. Write the rollback trigger in advance: which symptom, at what level, sends you back? If most of the new addresses return 404, or the checkout does not work, returning to the old site is reasonable.

Roles on move day

Write down who does what: who takes the backup, who runs the search-replace, who tests the redirects. Even on a one-person site the list makes tired skipping visible. When the move is over, record each action with its date. If a problem appears months later, that record explains which step produced which result.

Walkthrough: a violin maker's workshop site

Example scenario: a violin maker wants to rename the business, move to a new domain and renew the hosting. The site holds a gallery, a commission form and a handful of long articles about the craft. She splits the work in two phases.

She keeps the redirects in place for at least a year and notes the date in her calendar.

Example scenario: a community choir's site

A choir moves to a new domain and a new host. The first attempt uses an export file made while plugins were active, and the file is empty. The fix runs in this order: disable plugins and export again, ask the new host about the upload limit, run search-replace with the guid column skipped, re-save permalinks, and write a server-side redirect from the old address to the new one. After each step, test the home page and one inner page. This scenario is fictional.

Move-night checklist

Before the move:

• Files and database backed up
• A copy of .htaccess saved
• Mapping list of old to new URLs ready
• The search-replace tool confirmed to skip guid
• Staging closed to search engines

After the move:

• Permalinks re-saved
• Redirects tested
• New sitemap submitted, noindex and robots blocks removed
• Old and new site watched in Search Console
• A calendar note for at least a year of redirects

Short list for move night

• Is the plugin state recorded and the export file not empty?
• Is the guid column left out of search-replace?
• Were permalinks re-saved, and does the rule file keep any custom rules?
• Do server-side permanent redirects from old addresses to new ones work?
• Is a backup of the old site stored off-site?

Frequently Asked Questions

Do I need search-replace when only the host changes?

If addresses stay the same, the WordPress guide describes copying files and database and updating wp-config.php if the database details change. Search-replace comes in when the domain or the URL path changes.

Why does serialized data cause trouble?

According to the guide, some themes and widgets store string lengths. When the address changes, the length changes, so a plain find-and-replace can corrupt the data.

Why must I leave the guid column alone?

The guide says never to change the contents of the guid column under any circumstances. Feed readers use the guid as an identifier to track posts.

How long should I keep redirects?

Google's move documentation says to keep redirects as long as possible and, as a rule, at least one year.

Is the Change of Address tool needed for every move?

No. The documentation says it applies to moves between domains or subdomains, not to http to https, a www change on the same domain, or path changes.

What if traffic drops after the move?

The documentation says to expect temporary fluctuation in rankings. Check redirects, canonicals and the sitemap, and look at the index coverage report in Search Console.

Conclusion

A WordPress move combines moving files and data with telling search engines about new addresses. Classify the move, take two separate backups, run search-replace with a tool that respects serialized data, leave guid alone, rebuild .htaccess, test server-side permanent redirects and keep them in place for as long as possible, as a rule at least a year. Then watch both sites in Search Console.

Once the move is complete, what remains is feeding the site with fresh content.

For a steady flow of carefully made articles, take a look at our content writing service.