Home / Guides / Website migration
Guide · SEOWebsite migration checklist: how to move to a new site without losing search traffic or leads
A website migration keeps its rankings and leads when you protect four things: every URL that earns traffic gets a 301 redirect to its closest new match, content and metadata carry over, the new site is crawlable and fast, and you monitor for at least 90 days after launch.
Take the checklist to your team.
A printable checklist covering every phase of a migration, from the baseline crawl to the 90-day review, with a tick box for each item.
- Phase-by-phase tasks with owners
- The redirect and QA tests to run before launch
- Launch-day and 90-day monitoring lists
Not every migration carries the same risk.
A migration is any change that alters how search engines find and understand your pages: a new design, a new content management system, a new domain, a new URL structure or a move to HTTPS. The more a migration changes URLs and content, the more rankings are at risk.
| Type | What changes | Risk |
|---|---|---|
| Visual redesign | Look and layout. URLs and content stay. | Low, if headings, copy and internal links are kept |
| Replatform (new CMS or hosting) | Technology. URLs may change by accident. | Medium. URL patterns, redirects and speed often shift. |
| URL restructure | Page addresses and site architecture. | High. Every changed URL needs a redirect. |
| Domain change or rebrand | The whole address. | High. All pages redirect, and reputation must transfer. |
| Merge or split sites | Content moves between sites. | High. Check duplication and ownership of each page. |
| HTTP to HTTPS | The protocol. | Low to medium. Redirects and canonical tags must be right. |
Decide why you are migrating, and what success looks like.
Write down the reason: a faster site, a platform you can maintain, a rebrand, a clearer structure. Then agree the measures that decide whether it worked: organic traffic, rankings for the pages that matter, leads from organic search, and the lead-to-SAL ratio for that source. Fix a window, for example no worse than the baseline after 90 days, and have SEO involved from the first planning meeting rather than the week before launch.
Set the project team and roles early. Marketing owns the outcomes and the content. Development owns the build and the redirects. SEO owns the URL map and the checks. Sales hears about launch dates so that lead handling does not break.
Record what you have before you touch anything.
You cannot prove a migration worked, or find what broke, without a record of the old site. Collect it while the old site is still live.
- Crawl the old site. Export every URL with its status code, title, meta description, headings, canonical, word count and internal links.
- Pull performance data. From Search Console, export 16 months of clicks, impressions and positions by page and by query. From GA4, export organic landing pages and key events.
- List the pages that matter. Rank them by traffic, leads and links. These are the pages you must not lose.
- Export backlinks. Which pages earn links from other sites. Those URLs need the most care.
- Record rankings for your 30 to 50 most important keywords.
- Save the technical set-up. robots.txt, XML sitemaps, redirects already in place, structured data, tracking tags and form settings.
- Take speed and Core Web Vitals readings. So you can compare.
The redirect map is the most important document in the project.
For every old URL that has traffic, links or leads, decide which new URL replaces it, and redirect it with a permanent 301. Build this as a spreadsheet with four columns: old URL, new URL, status, and notes.
| Old URL | New URL | Rule |
|---|---|---|
| /seo-services/ | /seo-geo | 301 to the closest equivalent page |
| /blog/migration-tips/ | /guides/migration | 301 to the new version of the article |
| /team/ | /about | 301 to the page that now holds the content |
| /old-offer/ | 410 Gone | No equivalent. Say so, rather than redirecting to the home page |
- One hop. Redirect straight to the final address. Chains slow crawling and lose signals.
- Closest match, not the home page. Mass redirects to the home page are treated as soft errors and waste the page's links.
- Both slash forms. Some hosts match trailing slashes exactly, so list /page and /page/ separately.
- Keep URLs where you can. The best redirect is the one you do not need. If a URL is good, keep it.
- Check new URLs are not shadowed. Make sure no old rule redirects away from an address you now use for a new page.
- Cover parameters, old files and images where they earn traffic or links.
A real example: when we moved search-value.com from WordPress to a new site, we mapped the old WordPress addresses to the new pages with 301s, and listed both slash forms because the host matches them exactly. An old rule for /faq also sent that address to our services page, hiding the new FAQ page until we caught it. Test every redirect against the live pages, not only the list.
Carry over everything search engines use.
The new site is a chance to improve, but change content deliberately, not by accident. Pages that rank today rank because of their text, titles, headings and links. Keep them close to the original unless you have a reason to change them.
- Content parity. Every page you are keeping has equal or better content. Do not cut the copy that ranks to fit a design.
- Titles, meta descriptions and headings carried across, or improved on purpose.
- Internal links preserved, with descriptive anchor text.
- Canonical tags point each page to its own preferred URL.
- Structured data recreated: Organisation, Article, FAQ and breadcrumbs.
- Images with alt text, and sensible file names, compressed.
- International sites: hreflang tags if you serve more than one language or region.
- A useful 404 page, with links to the main sections.
- Analytics and conversion tracking installed, with forms and events tested.
- Speed and mobile checked against your baseline.
Build on a staging site that search engines cannot index: protect it with a password, and add a noindex tag as a second safeguard. Do not rely on robots.txt alone, because blocked pages can still appear in results if linked.
Test the redirects and the site before launch.
Crawl the staging site with the same tool you used on the old one, and compare the two. Then work through these tests.
| Test | How | Pass when |
|---|---|---|
| Redirects | Run the full old URL list against the redirect rules in bulk | Every URL returns a single 301 to the right page, with a 200 at the end |
| Indexability | Crawl for noindex tags, robots blocks and canonical errors | Only the pages you intend are indexable |
| Content comparison | Compare titles, headings and word counts old versus new | No unplanned losses on important pages |
| Internal links | Crawl for broken links and orphan pages | No broken links, and no important page without links |
| Tracking | Test GA4, tag manager and conversion events | Events fire once, on the right action |
| Forms | Submit every form and check the email, CRM and thank-you page | Leads arrive with source data |
| Speed and mobile | Run Lighthouse or PageSpeed Insights | Equal to or better than baseline |
| Sitemap and robots | Check the new XML sitemap and robots.txt | Sitemap lists final URLs only; robots.txt allows crawling |
Launch day, in order.
Choose a quiet day and time, not a Friday, a holiday or a peak campaign. Have developers, SEO and marketing available, and agree a rollback plan before you start.
Prepare
Lower DNS time-to-live a day or two ahead if the address or host changes. Freeze content on the old site. Back it up.
Switch and open up
Deploy the new site and redirects. Remove the staging noindex tag and any robots block. Check that robots.txt allows crawling.
Verify
Test a sample of redirects, the home page, the key service pages, forms and tracking. Confirm HTTPS and the canonical tags.
Tell search engines
Submit the new XML sitemap in Search Console. Request indexing for the key pages. For a domain change, use the Change of Address tool.
The most common launch mistake is leaving the staging noindex tag or a blocking robots.txt in place. Check both within minutes of going live.
Watch closely for 90 days.
| When | Check | Why |
|---|---|---|
| Day 1 to 7 | Search Console coverage and crawl stats, 404s and server errors, redirect samples, forms, analytics | Catch breakage before it compounds |
| Week 2 to 4 | Indexed pages versus expected, rankings for priority keywords, organic traffic versus baseline, leads | Spot pages that lost visibility |
| Month 2 to 3 | Backlinks pointing to old URLs, redirect chains, speed, lead-to-SAL by source | Confirm recovery and fix the long tail |
| Month 3 and 6 | Full review against the goals you set | Decide what to improve next |
A temporary dip in traffic after launch is common while search engines reprocess the site, and recovery usually takes weeks, sometimes a few months. A sharp drop on pages you meant to keep is a signal to investigate quickly. Ask the sites that link to you most to update their links to the new addresses, and keep your redirects in place for at least a year; for a domain change, keep the old domain for as long as you can.
What goes wrong, and how to fix it.
| Symptom | Likely cause | Fix |
|---|---|---|
| Traffic collapses at launch | Noindex or robots block left on | Remove it, resubmit the sitemap, request indexing |
| Key pages lose rankings | Content, titles or headings changed, or redirects missing | Compare with the baseline, restore the content, correct the redirect |
| Spike in 404 errors | URLs missing from the map | Find them in Search Console, add 301s |
| Duplicate content | Both old and new versions indexed, or no canonical | Fix canonicals and redirects |
| Leads stop | Forms or tracking broken | Test every form and the CRM link |
| Slow pages | Heavy scripts or unoptimised images | Optimise, defer scripts, compress images |
Take the checklist to your team.
A printable checklist covering every phase of a migration, from the baseline crawl to the 90-day review, with a tick box for each item.
- Phase-by-phase tasks with owners
- The redirect and QA tests to run before launch
- Launch-day and 90-day monitoring lists
Algoworks
Want a second pair of eyes on this?
Book a pipeline review. We will look at how your funnel works today and show you what we would change first.
- A 30-minute callYou describe your funnel and where it leaks.
- A look at your funnel dataRead-only access to analytics and your nurture platform.
- First findingsWhat we would change first, and what it should move.