Website migration checklist for speed and search

How to use this list

Every step links to the guide that explains it. Skip the items that do not apply, such as language links on a one-language site. The order matters: the staging block must come off at launch, and the redirects must exist before the old address stops answering.

Before: decide and record

• Name what is changing. A new host, a new domain, a new platform or theme, new page addresses, or a new design. Each adds its own risks. A move that keeps every address the same is far simpler than one that changes them.
• List every address on the old site. Use your content system's page list, your sitemap if you have one, and the crawl script from internal linking to find what links reach. Add the pages that get the most visits and the pages that get links from other sites.
• Record the baseline. Save a speed report for the key pages, with the date: Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift, page weight, requests and server response. Save the traffic and conversion numbers for the same weeks. See how to read a speed report.
• Save what search engines see. For the main pages, the title, meta description, headings, canonical link, language links and structured data. The new site must carry these over. See titles and headings and structured data basics.
• Take a complete backup, of the files and the database, and keep a copy off the server. The WordPress Handbook begins a server move the same way, by backing up the directory, images, plugins and other files and the database.
• Check the accounts. Domain registrar, DNS, host, CDN, email, analytics and payment accounts should all be in your name, with logins you can reach.
• Lower the DNS time to live ahead of a host change. Changes spread over the record's time to live, so a short one makes the switch quicker and an emergency undo possible. Raise it again afterwards. See DNS performance.
• Get the certificate ready on the new host, so that HTTPS works the moment the address points to it. See TLS and HTTPS speed.

Staging: build and test

• Work on a copy, not on the live site. A staging environment lets you test a change before visitors see it. See how to test speed changes safely.
• Keep search engines out of the copy. Use a password where you can, plus the setting that discourages indexing. Write "remove at launch" on the list, because a block left in place after launch is one of the costliest mistakes. See robots.txt and noindex.
• Write the redirect map. One row for each old address that changes: the old path and the new path, pointing to the closest matching page. Send the retired pages that have no match to the nearest useful page, not all of them to the home page. See redirects and status codes.
• Make each redirect one hop and permanent. A 301 straight to the final address, with no chain through other redirects and no 302 for a move that is permanent.
• Update internal links to the new addresses, so visitors do not pass through redirects. Fix image, script and style paths too. See internal linking.
• Compare the tags on old and new for the key pages. The title, description, canonical link, robots rules, language links, headings and structured data should be there, in the raw HTML. See canonical tags, hreflang and JavaScript and SEO.
• Make sure canonical links use the final address, with https and the host you chose.
• Set the real 404 page to return a 404 status, and not a 200.
• Test the journeys that make money: forms, search, login, cart and checkout, booking and payment, with test entries. Check that emails from the site arrive.
• Check the tracking: analytics, ad tags and conversion events fire once on the new site.
• Measure speed on the copy with the same pages and the same method as the baseline, and fix the differences before launch. A new theme or host can be slower. See optimize or redesign.
• Test on real phones. See testing on real phones.

You can check the redirect map with this script, which reads a file of old,new pairs and reports every row that is not a single permanent redirect to a page that answers. It needs Node 18 or later:

// check-redirects.mjs: node check-redirects.mjs redirects.csv https://www.example.com
// redirects.csv holds one "old-path,new-path" pair per line, for example: /old-page/,/new-page/
import { readFileSync } from 'node:fs';

const [file, origin] = process.argv.slice(2);
const rows = readFileSync(file, 'utf8').trim().split('\n').map((line) => line.split(',').map((s) => s.trim()));

for (const [from, to] of rows) {
  const first = await fetch(origin + from, { redirect: 'manual' });
  const location = first.headers.get('location');
  const target = location ? new URL(location, origin).href : null;
  const second = target ? await fetch(target, { redirect: 'manual' }) : null;
  const ok = first.status === 301 && target === new URL(to, origin).href && second && second.status === 200;
  console.log(ok ? 'ok     ' : 'PROBLEM', from, '->', first.status, location || '-', second ? '->' : '', second ? second.status : '');
}

I tested it against a small test server with five rows. It passed the one correct redirect and flagged a 302, a chain of two redirects, a redirect to a page that returned 404, and an old address that did not redirect at all.

Launch: switch and check

• Take the staging block off. Remove the password, the discourage-indexing setting and any noindex tag or header, and check robots.txt does not disallow the whole site. This is the item to double-check.
• Point the address to the new site, and wait for the DNS change to spread.
• Turn on the redirects from your map, and the redirect from http to https and from the other host name to the chosen one, each in one hop.
• Add HSTS carefully, with a short time at first. See HTTPS and security headers.
• Check the headers of the home page and two deep pages with curl -sIL: status codes, redirects, Content-Type, caching and compression. See HTTP caching headers and text compression.
• Purge caches: the page cache, the CDN and the browser cache rules, so that visitors see the new files. See caching explained.
• Run the redirect checker on the full map, and the crawl script on the new home page to find broken internal links and redirects.
• Run Lighthouse on the key pages and compare with the baseline.
• Walk the money journeys again on the live site, with a real device.
• Confirm the tracking is recording visits and conversions.

After: watch and finish

• Watch for errors in the first hours and days: forms, orders, error pages, server load.
• Rerun the crawl and redirect checks after a week, and fix what appears.
• Keep the old site's files and database for a while. The WordPress Handbook's steps for managing the old site say to keep the old database just in case, and to be sure you have a backup of it before going further.
• Keep the old addresses redirecting for as long as people link to them. The Handbook suggests adding redirection instructions to guide visitors to the new address.
• Raise the DNS time to live back to a normal value.
• Compare field data after 28 days, since the Chrome UX Report covers a rolling 28-day window. See the Chrome UX Report and how long speed work takes.
• Compare traffic and conversions with the baseline weeks, allowing for season and campaigns.
• Set a routine: a budget, monitoring and a quarterly review. See automated testing and budgets.

Mistakes to avoid

• The staging block left on.
• All old addresses sent to the home page.
• A 302 where a 301 was meant, or a chain of redirects.
• A canonical link that still names the old host or an `http` address.
• Tags that exist only on the old site, such as structured data.
• Skipping the checkout test.
• A new theme or host that is slower, found after launch.
• Switching off the old site at once.
• Doing everything on the same day with nobody watching.

Check your own page

Run the free audit on your most important page now, before any move, and save the report. After the move, run it again on the same page and compare, and check that the new address still answers with a 200 and the old one with a 301.

Sources

• Moving WordPress in the WordPress Advanced Administration Handbook: backups before a move, keeping or changing the domain, redirects in .htaccess, and managing the old site.
• Redirections in HTTP on MDN: permanent and temporary redirects and why to fix internal links.
• Chrome UX Report methodology: the 28-day window of field data.