Website migration SEO checklist: every step before, during and after launch

This checklist follows the order of a real project, from the first week to two months after launch. It draws on Google's published guidance for site moves with URL changes, translated into steps a non-technical owner can ask for and check. Print it, give it to whoever builds the site, and ask for each section to be signed off before the next one begins.

Before you start: what do you need to record?

Everything here describes the old site as it is today. Once the new site launches, much of this information becomes hard or impossible to recover.

1. Verify the site in Google Search Console and Bing Webmaster Tools if it is not already. These are the free tools from Google and Microsoft that report how each search engine sees your site. Google's guidance is to verify every variant: with and without www, and http as well as https.
2. Export 16 months of Search Console performance data, which is all Google keeps: clicks and impressions by page and by search query.
3. Build a complete URL inventory. Combine a crawl of the site, the XML sitemap (the file listing your pages for search engines), Search Console's indexed pages, analytics landing pages and any old campaign or PDF links you know about.
4. Record which pages have links from other websites, using Search Console's Links report.
5. Save the content of your top pages: page title, description, main heading, body text and any structured data (code that labels facts like your address and services for machines).
6. Record current rankings for the ten to twenty searches that bring you business, with the date.
7. Note who holds every login: domain registrar, DNS (the settings that point your domain at a server), hosting, Search Console, analytics and email. Launches stall on missing passwords more often than on code.

Planning: how should the new structure be decided?

1. Give every old URL a decision: keep at the same address, move to a new address, merge into another page, or drop.
2. Keep addresses unchanged wherever the new platform allows. An unchanged URL needs no redirect and carries the least risk.
3. Write new addresses in plain words, short and readable, such as /kitchens/shaker rather than /page?id=482.
4. Protect content that ranks. For each page with real search traffic, agree in writing that its substance carries over: topics, depth and the phrases people search with.
5. Change as little at once as you can. Google advises planning changes "one after the other, not everything at the same time." If a new domain name can wait, let it wait.
6. Choose the launch date with your calendar in mind. Google suggests moving during a seasonal or weekly dip in traffic, and avoiding the weeks your enquiries usually peak.

The redirect map: what must it contain?

The redirect map is a spreadsheet: old URL in one column, new URL in the next. It is the most important deliverable in the project.

1. One row for every old URL that is moved or merged, including PDFs and images that other sites link to.
2. Each old URL points at its closest equivalent, never a blanket redirect to the homepage. Google warns that mass redirects to an irrelevant page can be treated as soft 404s, meaning Google treats the old page as gone.
3. Permanent 301 redirects, set up on the server or platform, not JavaScript or timed page refreshes. Google treats 301 and 308 redirects as a strong signal that the new address replaces the old.
4. No chains. Each old URL goes to its final address in one step, including any redirects left over from previous redesigns.
5. Dropped pages return a 404 or 410 code, which Google's guidance says is correct for content you are not moving.
6. Variants covered: http to https, www to non-www (or the reverse), and trailing slash versions should all resolve to one address.

The detail on each of these is in the guide to 301 redirects when changing website.

Pre-launch: what should be tested on the staging site?

Staging is the private copy of the new site used for building and testing. It should be password protected, because a robots.txt block alone does not reliably keep pages out of Google.

1. Every page has a unique title and description written for the search it should rank for.
2. One main heading per page, and the important text present in the page rather than in images.
3. Text is visible without JavaScript tricks. If the site is built with a JavaScript framework, check the delivered page contains the content, not an empty shell.
4. Canonical tags point at each page's own new address. A canonical tag is a line of code telling Google which address is the preferred version of a page.
5. Structured data is present and valid, tested with Google's Rich Results Test. Schema markup for AI search explains what to include.
6. The site is fast on a phone, measured against the old site. Core Web Vitals explained covers the measures.
7. Internal links point at new URLs directly, not at old ones that redirect.
8. A new XML sitemap lists only new, indexable URLs.
9. A production robots.txt file is ready that allows crawling and lists the sitemap.
10. Forms, phone links, booking tools and analytics work, with test enquiries sent and received.
11. The redirect map is tested by running every old URL through a redirect checker against staging, where the setup allows it.

The two launch-day disasters, a leftover noindex tag and a robots.txt file that blocks everything, both come from the staging site. Make removing them a named, ticked item on the day, not an assumption.

Launch day: what happens, in what order?

1. Point the domain at the new site, or switch the platform live.
2. Remove the staging password and every noindex instruction. Confirm the live robots.txt is the production version.
3. Run the full redirect list against the live site. Every row should return a single 301 to the right page.
4. Spot-check the ten most important pages in a browser and on a phone.
5. Submit the new sitemap in Search Console and Bing Webmaster Tools.
6. Use Search Console's URL Inspection tool on the homepage and main service pages, with a live test.
7. If the domain changed, use the Change of Address tool in Search Console and the Site Move tool in Bing Webmaster Tools. Google's tool only applies to moves between domains or subdomains, not to path changes or a switch to https.
8. Send a test enquiry through every form and confirm it arrives.

After launch: what should you watch, and for how long?

Week one

• Check Search Console's Pages report every couple of days for new "Not found (404)" errors, and redirect any that should exist.
• Update the links you control: Google Business Profile, Bing Places, social profiles, directories, email signatures and ad campaigns.
• Contact the most valuable sites that link to you and ask them to update to the new address, as Google's guidance suggests.

Weeks two to eight

• Compare clicks and impressions weekly against the same weeks before launch, by page and by query.
• Watch the old sitemap's indexed count fall and the new one's rise. Google's guidance is to remove the old sitemap once the move is complete.
• Recheck rankings for your key searches every two weeks.

Months three to twelve

• Keep every redirect live. Google advises keeping them "generally at least 1 year"; there is rarely any reason to remove them at all.
• If you changed domain, keep renewing the old one. Google recommends holding it for at least a year so nobody else can buy it and reuse it.

Some ranking movement in the first weeks is normal; Google says so in its guidance. A clear and continuing fall after a month is not, and lost rankings after a website redesign covers how to find the cause. For how these stages fit into a realistic schedule, see how long a website redesign takes, and for the reasoning behind each step, the main guide on redesigning your website without losing Google rankings.

Which items do agencies most often leave out?

When you review a proposal, look for these by name. If they are not written down, assume they are not included.

• A URL inventory and redirect map that you receive and keep.
• Carrying over page titles, descriptions and structured data, rather than letting the new template generate defaults.
• Search Console verification and sitemap submission for the new site.
• A named person checking Search Console after launch, with a stated number of weeks.
• Fixing post-launch problems at no extra charge for a defined period.

The M/AFZAL Rebuild, for example, writes redirects from old pages, Search Console setup and 14 days of post-launch fixes into its published scope. Whoever you hire, ask to see these items in the contract before you sign.