Website Migration SEO Checklist
Most traffic lost in a redesign is lost through missing redirects. This checklist is how to avoid being one of those sites.

Short answer
To keep rankings through a website migration, crawl and benchmark the old site, map every valuable old URL to its closest new equivalent, set up permanent 301 redirects, carry over titles, content and structured data, test everything on staging, then monitor Search Console closely after launch. Keep redirects in place for at least a year, and ideally permanently.
A website migration is any change that alters where your pages live or how they are built: a redesign that changes URLs, a move from Wix or Squarespace to WordPress, a switch of CMS, a new domain, or merging two sites. Each one can wipe out years of search visibility if it is handled carelessly, and each one can be done with little or no lasting loss if it is planned.
This website migration SEO checklist covers what to do before, during and after launch. Most of it is unglamorous: inventories, spreadsheets and redirect testing. That is exactly why it gets skipped, and why so many redesigns lose traffic. It fits within the wider plan in SEO for small businesses.
Types of website migration
| Migration | URLs change? | Main risk |
|---|---|---|
| Redesign on the same platform | Sometimes | Removed content, changed page focus |
| Platform change (e.g. Wix to WordPress) | Usually | Every URL pattern changes |
| HTTP to HTTPS | Protocol only | Mixed content, incomplete redirects |
| Domain change | All | Signals must transfer to a new domain |
| Site merge | Many | Duplicate and overlapping pages |
| URL restructure only | Yes | Redirect gaps |
The more that changes at once, the harder it is to diagnose problems afterwards. If you can, avoid changing domain, platform and content in a single launch.
Google's own guidance is in site moves with URL changes. The checklist below follows it, with the practical detail added.
Before: benchmark and inventory
- Record a baseline. Export the last 16 months of Search Console Performance data by page and by query. Note organic sessions and conversions from analytics. You cannot judge the migration without a before picture. Google Search Console for business owners explains where to find these.
- Crawl the current site. Use a crawler such as Screaming Frog to list every URL, its title, meta description, H1, canonical, status code and word count.
- Combine URL sources. Add URLs from the sitemap, Search Console, analytics landing pages and your backlink data. Pages that get traffic or links but are not linked internally are easy to miss.
- Identify valuable pages. Mark pages with clicks, impressions, backlinks or conversions. These must keep an equivalent.
- Save the old site. Keep a full copy of the old content and a crawl export. You will need it when something is missing.
Before: map and redirect
- Build a redirect map. In a spreadsheet: every old URL in one column, its new destination in the next. Each old URL should go to the closest equivalent new page, not to the homepage.
- Decide what happens to removed pages. If there is a genuine equivalent, redirect. If the content is gone with no replacement, a 404 or 410 is more honest than redirecting everything to the homepage, which Google tends to treat as a soft 404 anyway.
- Use permanent redirects. Server-side 301 (or 308) redirects. Not JavaScript or meta refresh redirects.
- Avoid chains. If old URLs already redirect, update the map so each goes straight to its final destination in one hop.
- Plan for URL variants. Trailing slashes, uppercase, query strings and old http or www versions should all resolve correctly.
Before: carry over what ranks
- Keep content on valuable pages. If a page ranks well, keep its substance. Shortening a strong page to fit a new design is one of the most common causes of lost rankings.
- Carry over titles and meta descriptions for ranking pages, or improve them deliberately rather than accidentally.
- Keep heading structure and internal links that support important pages.
- Rebuild structured data on the new templates, and test it. See schema markup for business websites.
- Plan the new structure properly. If URLs are changing anyway, this is the moment to get them right. How to create an SEO-friendly website structure covers what good looks like.
Before launch: test on staging
- Block staging from indexing with password protection, not just a noindex tag that might be copied to live.
- Test the redirect map. Run every old URL through a crawler pointed at staging or the redirect rules and confirm each returns one 301 to the right destination.
- Crawl the new site. Check for broken links, missing titles, duplicate pages and incorrect canonicals.
- Check performance. A new design that is much slower can undo the benefit. Core Web Vitals explained covers the thresholds.
- Check tracking. Analytics, conversion events and any call tracking must be working on day one.
Launch day
- Remove staging protection and any noindex on the live site. Check the robots.txt file and, on WordPress, the "discourage search engines" setting.
- Put redirects live at the same moment as the new site.
- Spot-check redirects for your top 20 pages by hand.
- Submit the new XML sitemap in Search Console.
- Domain change only: verify the new domain in Search Console and use the Change of Address tool. Google says this tool is only needed when moving between domains or subdomains.
- Update your Google Business Profile website link and the most important citations if the domain changed.
- Add an annotation in Search Console for the launch date.
After launch: monitor
- Daily for the first two weeks: Search Console Pages report and crawl stats, 404 errors in analytics or server logs, and enquiries.
- Fix 404s quickly. Any old URL with traffic or links that now returns 404 needs adding to the redirect map.
- Request indexing for the most important new pages.
- Update internal links so they point straight to new URLs rather than through redirects.
- Ask key linking sites to update their links, starting with the most valuable.
- Compare performance with the baseline weekly for the first two to three months.
- Keep redirects for at least a year, which is Google's minimum recommendation, and ideally permanently.
A worked example: building a redirect map
Say a 40-page building firm site is moving from a website builder to WordPress. The crawl, sitemap and Search Console exports together list 58 old URLs, more than the 40 pages anyone remembered, because old blog posts, a gallery and some forgotten landing pages are still live.
Part of the resulting map might look like this:
| Old URL | New URL | Action | Reason |
|---|---|---|---|
| /services-1 | /services/extensions | 301 | Same content, new structure |
| /loft-conversions-kent | /services/loft-conversions | 301 | Ranking page, content kept |
| /blog/post/planning-tips | /blog/planning-permission-extensions | 301 | Rewritten and expanded |
| /gallery | /projects | 301 | Same purpose |
| /summer-offer-2023 | none | 410 | Expired, no equivalent, no links |
| /contact-us | /contact | 301 | Same page |
| /blog/post/company-news | /about | 301 | Thin post with two backlinks; closest relevant page |
Three things this shows. First, old URL patterns from builders rarely match anything sensible, so almost every URL changes. Second, some decisions need judgement: the thin news post has backlinks, so it redirects rather than disappearing. Third, a 410 is fine for a page with no value and no replacement.
The map is also a useful moment to fix what was wrong before. Two old pages that targeted the same service can be merged into one new page, with both redirecting to it.
Common migration mistakes
| Mistake | What happens | How to avoid it |
|---|---|---|
| No redirect map at all | Old URLs return 404; rankings and links are lost | Map every valuable URL before launch |
| Redirecting everything to the homepage | Treated like soft 404s; relevance is lost | Redirect to the closest equivalent |
| Staging noindex copied to live | The new site drops out of the index | Check robots meta and robots.txt on launch day |
| Strong content cut for the new design | Pages lose the queries they ranked for | Keep the substance of ranking pages |
| Launching just before a busy season | Any dip hits when it hurts most | Launch in a quieter period where possible |
| Removing redirects after a few months | Signals and old links break | Keep them for at least a year, ideally permanently |
| Analytics not installed on the new site | No way to measure the impact | Test tracking on staging |
A realistic timeline for a small site
| When | What happens |
|---|---|
| 4 to 6 weeks before launch | Baseline exported, old site crawled, URL inventory built |
| 2 to 4 weeks before | Redirect map completed and reviewed; content carried over |
| 1 to 2 weeks before | Staging crawled, redirects tested, tracking tested |
| Launch day | Redirects live, noindex removed, sitemap submitted, spot checks |
| Weeks 1 to 2 after | Daily checks of indexing, 404s and enquiries |
| Months 1 to 3 after | Weekly comparison with the baseline; fixes as needed |
Squeezing the first three rows into the last few days before launch is how most redirect gaps happen.
Who should own the migration
On small projects, the developer builds the site, and nobody owns the SEO side. That gap is where traffic is lost. Whoever builds the site, agree in writing who is responsible for the URL inventory, the redirect map, the launch checks and the monitoring afterwards. If it is you, this checklist is the job. If it is someone else, ask to see the redirect map before launch day.
What normal looks like after a migration
Some fluctuation in the first few weeks is expected while Google recrawls and processes the change. Google's guidance is that a small to medium site can take a few weeks for most pages to move. A sharp, sustained drop is not normal. If clicks are still well below the baseline after a month or two, check in this order:
- Are the important old URLs redirecting correctly?
- Are the new pages indexed?
- Did content or page targeting change on the pages that dropped?
- Is anything blocked: noindex, robots.txt, canonical tags pointing at staging?
Most post-migration problems are found in the first two.
Migrating from a website builder
Moving from Wix, Squarespace or similar to WordPress or a custom build is one of the most common migrations for small businesses, and the URL patterns almost always change. The platform side is covered in moving from Wix or Squarespace to WordPress. The SEO side is everything above.
If you are deciding whether to redesign at all, when to redesign or rebuild a WordPress website covers the decision.
Next step
A migration is the one SEO job where a mistake can undo years of work in a single afternoon. If you are planning one, the SEO service can own the redirect map and launch checks, alongside a build through the website development service. The website migration SEO preservation showcase walks through the method in more detail.
Worked examples
Related services
Related reading
SEO
SEO for Small Businesses: A Practical Guide
What to do first, what to ignore, and why most small-business SEO advice is written for companies a hundred times your size.
SEO
Google Search Console: A Guide for Business Owners
The free tool that tells you what Google actually thinks of your site. Twenty minutes a month is enough, if you know where to look.
SEO
SEO Website Audit Checklist
What to check, in the order that matters, with the reason each item is on the list.
SEO
How to Create an SEO-Friendly Website Structure
Structure is decided early and expensive to change. Here is how to get it right the first time.
