Website Migration SEO Checklist: How to Rebuild Without Losing Your Rankings

Rankings drop after a website rebuild when nobody wrote down everything the old site was silently doing: which pages earned links, which ones brought in enquiries, which old URL a trade directory still points to. The new site launches, those jobs vanish, and the owner finds out six weeks later when the phone goes silent. The fix is dull and completely learnable. Treat the redirect map as the product, and the design as the wrapper.

This playbook is the process we use when we rebuild a site for a client who already has something worth protecting. Copy the templates, tick the boxes, and you can run it without us.

Quick answer

To migrate a website without losing rankings: crawl and export every old URL, decide what happens to each one (keep, improve, merge or retire), map every old URL to its single best new URL with a 301 redirect, build and test on a password-protected staging site, launch in a low-traffic window, then check Search Console, analytics and enquiries on days 1, 3, 7, 14 and 30. Keep the redirects for at least a year, as Google advises. Expect a wobble for a few weeks. Agree your rollback triggers before you launch.

The whole migration on one page. Most of the work happens before launch day.

What can a migration actually break?

A migration can break six things: your URLs, your content, your links, your tracking, your crawl settings and your trust signals. Each one fails in its own way, and each one needs an owner before you start.

What	How it breaks	Who notices
URLs	Old addresses return 404, or redirect to the home page	Google, and every visitor with a bookmark
Content	The rebuild silently drops the page that ranked, or cuts its text in half	Google, a few weeks later
Links	Other sites still link to dead addresses, so their authority goes nowhere	Nobody, until traffic dips
Tracking	Analytics, call tracking or form events missing on the new site	You, when you cannot prove anything
Crawl settings	A staging noindex or a Disallow: / goes live	Everyone, loudly
Trust signals	Reviews, credentials, schema, author names and dates vanish in the redesign	Google and AI tools

Google’s own guidance on site moves says to expect ranking fluctuations and to change only one thing at a time. That second rule is the one most agencies break, because a rebuild is the moment everyone wants to change the domain, the URLs, the copy and the platform together. Resist it.

How should you split the project: the one-change rule

Split the project into two phases. In phase one you change the platform and the design, and keep the URLs and the core copy of every page that ranks. In phase two, a month or two after launch, you improve the content and the structure with the new site stable underneath you.

Why it works: if traffic dips after phase one, you know it was the move. If it dips after phase two, you know it was the content. Do both at once and you will never know which one hurt you.

The common mistake is “while we are in there”. While we are in there, let us rename the services, rewrite the headings, shorten the URLs and merge the blog categories. Each of those is reasonable alone. Together, they are a lottery ticket.

Rule of thumb we use: any page that gets organic traffic or has links pointing at it keeps its URL, its main heading and the substance of its copy in phase one. You can restyle it. You can fix typos. You do not rewrite it.

Step 1: Build the inventory (weeks 8 to 6 before launch)

The inventory is one spreadsheet that lists every URL on the old site with its traffic, links and job. If a page is not in the sheet, it will not get a redirect, and it will break.

What to do, in order:

1. Crawl the old site. Use Screaming Frog (the free version crawls up to 500 URLs; a paid licence removes that cap). Export all URLs with status codes, titles, H1s, canonical tags and word counts. Crawl images, PDFs and scripts too, because Google’s guidance says to include them in the mapping.
2. Pull the sitemap. Your XML sitemap lists what you think exists. The crawl lists what actually does. The difference is interesting.
3. Export Search Console performance. Go to Performance, Pages, set the date range to the last 16 months (the longest it keeps), and export clicks, impressions and position per URL. Also export the top 100 queries.
4. Export analytics. In GA4, take landing pages with sessions and key events (form submits, calls, purchases) for the same period. A page that gets 40 visits and 6 enquiries matters more than one that gets 400 visits and none.
5. Pull your backlinks. Search Console’s Links report shows the top linked pages for free. Ahrefs Webmaster Tools (free for sites you own) and Semrush show more. Export every URL that has at least one external link.
6. Check server logs if you can. Logs show URLs that Googlebot and AI crawlers actually request, including old ones that your crawl never finds. Ask your host for the last 30 days.
7. Merge everything into one sheet with the old URL as the key.

Columns for the inventory:

Column	Example
Old URL	/services/commercial-cleaning
Status code	200
Title and H1	“Commercial Cleaning in Leeds”
Clicks, last 16 months	412
Best query and position	“office cleaners leeds”, 6
Sessions and enquiries	1,150 and 14
Referring domains	7
Decision	Keep
New URL	/services/commercial-cleaning
Owner	Sam

Common mistake: relying on the sitemap alone. Old landing pages, campaign pages and PDFs often earn links and never appear in the sitemap. The crawl plus Search Console union catches them.

Check:

• Every URL from crawl, sitemap, Search Console, analytics and backlinks is in the sheet
• Images, PDFs and downloads are included
• Each row has a clicks number, an enquiries number and a link count
• One named person owns the sheet

Take a baseline snapshot before anything changes

You cannot judge a migration without a before picture. Save these into a folder called baseline-YYYY-MM-DD:

• The full crawl export
• Search Console performance by page and by query (16 months)
• Analytics: sessions, enquiries and conversion rate for the last 90 days
• Your top 30 queries and where you rank for each
• Core Web Vitals from Search Console (Google’s “good” targets, at the 75th percentile: Largest Contentful Paint 2.5 seconds or less, Interaction to Next Paint 200 milliseconds or less, Cumulative Layout Shift 0.1 or less)
• An AI visibility baseline: 20 prompts a buyer would ask, run in ChatGPT, Gemini, Perplexity and Google AI Mode, with a note of who got named and which URLs got cited (template further down)
• Screenshots of the top 20 pages on desktop and mobile

Step 2: Decide what happens to every page

Every URL gets one of four fates: keep, improve, merge or retire. Make the decision with the numbers, not with taste.

Sort every page by what it earns and how good it is. The top row has the most to lose.

The decision rules:

• Keep as is: earns traffic, links or enquiries, and the page is good. Same URL, same heading, same substance. Restyle only.
• Improve (phase two): earns traffic or links but is thin or dated. Keep it live and the URL unchanged now. Rewrite it after the dust settles.
• Merge: two or more weak pages cover the same topic. Pick the strongest URL, fold the best content into it, and 301 the others to it.
• Retire: no traffic, no links, no enquiries, no reason to exist. Return 404 or, if you want to be explicit that it is gone for good, 410. Google’s guidance says deleted content that is not moving should return a 404 or 410.

Worked example (illustrative numbers, not a client). Picture a 30-page services business that ran the numbers and found: 9 pages carried 85% of organic clicks, 11 pages had never had a click in 16 months, and 3 old blog posts were linked to by an industry body. Result: 9 keep, 4 improve, 6 merge into 3, 8 retire (with the 3 linked blog posts kept, because those links were worth more than the posts looked). Without the backlink column, those 3 posts would have been retired and the industry-body link would have pointed at a 404.

Common mistake: retiring pages because they “look old”. Age is irrelevant. Links and clicks are the test.

Step 3: Build the URL map and the redirects

The URL map is a two-column promise: this old address now goes to that new address. Every old URL that has traffic, links or a purpose needs a row.

What Google says (Search Central, site moves with URL changes):

• Use server-side permanent redirects, preferably 301 or 308.
• Avoid redirect chains. Aim for no more than 3 hops, and keep it under 5. We aim for one hop, always.
• Do not redirect lots of pages to an unrelated URL, such as the home page.
• Keep the redirects for generally at least one year.

A good map sends each page to its closest match. A bad map dumps everything on the home page.

The four numbers that matter most when you plan redirects and crawl rules.

The redirect map template (copy this into a sheet and export as CSV):

old_url	new_url	type	match_quality	reason	tested	notes
/services/commercial-cleaning	/services/commercial-cleaning/	301	exact	same page, trailing slash added	yes
/blog/2019/05/office-cleaning-tips	/blog/office-cleaning-tips/	301	exact	date folders removed	yes	5 referring domains
/our-team	/about/	301	close	team page merged into About	yes
/services/window-cleaning-old	/services/window-cleaning/	301	exact	duplicate merged	yes
/spring-offer-2021	/services/	301	broad	expired offer, nearest parent	yes	no traffic, fine
/downloads/brochure.pdf	/downloads/brochure.pdf	301	exact	file moved folder	yes	11 links
/old-page-no-value	(none)	410	n/a	retired	yes

match_quality is the column that keeps you honest. Aim for every row that has traffic or links to be “exact” or “close”. If a high-value page is “broad”, stop and make a better page for it to land on.

Before you write a single rule, normalise the variants. One old page can exist at many addresses. Each needs to end up at the same single destination in one hop:

• http:// and https://
• www. and non-www
• With and without trailing slash
• Uppercase and lowercase
• index.html, index.php
• Tracking parameters such as ?utm_source=

Pick one canonical form for the new site (for example https://example.co.uk/path/), redirect every variant straight to it, and make sure each new page carries a self-referencing canonical tag with the full absolute URL. Google’s duplicate URL guidance recommends redirects as the strongest signal, then rel="canonical", then sitemap inclusion, and says all signals should point at the same URL.

Pattern rules for big sites. If 400 blog posts move from /blog/2019/05/slug to /blog/slug/, write one pattern rule instead of 400 lines, then spot-check ten. In Apache or most hosts it looks like this:

RewriteRule ^blog/[0-9]{4}/[0-9]{2}/(.+)$ /blog/$1/ [R=301,L]

Patterns are fast and dangerous. Test them against your full URL list before launch, not after.

Test the map with a script. Save your CSV as redirects.csv with two columns (old, new), then run this against staging or after launch. It prints every row where the final destination or the status is wrong:

while IFS=, read -r old new; do
  result=$(curl -s -o /dev/null -L -w "%{http_code} %{url_effective} %{num_redirects}" "https://www.example.co.uk$old")
  echo "$old -> $result (wanted $new)"
done < redirects.csv

Look for three things: a final status that is not 200, a final URL that differs from the one you wanted, and a redirect count above 1.

Check:

• Every URL with traffic, links or enquiries has a row
• Every “broad” match has been challenged
• No chains: old goes to final in one hop
• All variants (http, www, slash, case) land on one canonical form
• Retired pages return 404 or 410, never a soft redirect to the home page
• The script runs clean on a full test

Step 4: What to keep on the new site

Keep everything that tells Google and buyers who you are and what each page is for. A redesign changes the clothes. It should not change the DNA.

Carry these across, page by page:

• URL (best redirect is no redirect)
• Title tag and meta description for pages that rank. If you change a title, you are changing what that page ranks for.
• H1 and the main body copy of ranking pages
• Internal links, updated to point at new URLs directly, so users do not pass through a redirect on your own site
• Image alt text and file names where they describe the image (Google calls alt text the most important attribute for images)
• Structured data: organisation, local business, product, FAQ, article. Check it matches what is visible on the page.
• Canonical tags, hreflang if you have international pages
• Author names, bios, credentials, publish dates and reviewed-by lines. Redesigns love to delete these as “clutter”. They are trust signals (see our piece on E-E-A-T for professional services).
• Reviews and testimonials with their markup
• Your 404 page, which should be helpful and return a real 404 status
• Analytics, ad pixels, call tracking and form events

New things worth adding now: a fresh XML sitemap, Core Web Vitals in the green, a proper contact route above the fold (see website lead capture).

Common mistake: keeping the words but moving them into tabs, sliders, images or scripts that load late. If the text is not in the HTML a crawler receives, it may as well not exist. Google’s own advice on AI features says to keep important content available as text. Our piece on why beautiful sites do not rank covers how to check this in two minutes.

Step 5: Staging, noindex and the two classic disasters

The two most common migration disasters are mirror images: the test site gets indexed, or the live site launches with the test site’s blocking switched on.

Rules for staging:

1. Put staging behind a password (HTTP authentication from your host). This is the cleanest approach: nothing gets crawled, nothing gets indexed, nothing leaks.
2. If you cannot use a password, use a noindex meta tag or X-Robots-Tag: noindex header. Google says it will drop a page with noindex from results.
3. Do not also block staging in robots.txt if you rely on noindex. Google is explicit: if robots.txt blocks the page, the crawler never sees the noindex rule, and the URL can still appear in results through links. Pick one method.
4. Google’s site move guidance adds a launch rule: if you used noindex during development, write down in advance every place you will remove it, and prepare the live robots.txt ahead of time.

Disaster A: staging gets indexed. Search site:staging.yourdomain.co.uk in Google now. If pages appear, you have duplicate content and a leak. Fix with password protection, then request removal.

Disaster B: live launches with the block on. Before launch, write the live robots.txt and the live meta robots rules in the launch plan. Right after launch, check all of these in this order:

• yourdomain.co.uk/robots.txt shows what you intended (no Disallow: /)
• View source on the home page and three deep pages: no noindex in the robots meta tag
• Response headers: no X-Robots-Tag: noindex
• WordPress: Settings, Reading, “Discourage search engines from indexing this site” is unticked
• Webflow and Shopify: no password page or site-wide index setting left over from staging
• URL Inspection in Search Console on the home page reports “URL is on Google” or “can be indexed”

Also check that robots.txt returns a normal file. If a robots.txt does not exist it should return a proper 404, which Google’s guidance asks for.

Step 6: Launch day, hour by hour

Pick a low-traffic window (for most B2B sites, a Tuesday or Wednesday morning, never Friday afternoon and never the week of a big campaign or a holiday), and make sure the people who can fix things are at their desks.

Print this. Tick it. Launch days go wrong when someone relies on memory.

The day before

• Lower DNS TTL to 300 seconds (48 hours earlier is better, so old values expire before you switch). This also makes rollback quick.
• Take a full backup of the old site and database, and store it off the server.
• Freeze content on the old site. Anything published after the crawl needs a manual row in the map.
• Verify all variants of the old and new sites in Search Console (http, https, www, non-www, subdomains), as Google recommends.
• Confirm the new site’s server can handle more crawling. Googlebot visits more heavily after a move.

Go live

• Switch DNS or deploy the new build.
• Switch on the redirects.
• Remove staging passwords and noindex.
• Publish the live robots.txt.
• Purge CDN cache.

First hour

• Run the redirect script against the live site.
• Load 20 old URLs by hand on a phone, not on your office wifi.
• Test every form with a real submission, and confirm the notification email arrives and the confirmation email goes out.
• Click every phone link and email link on mobile.
• Confirm analytics is recording, with a test visit from your phone showing in real time.
• Submit the new XML sitemap in Search Console and remove the old one. The old one will show redirect warnings, which Google says you can ignore.
• If the domain or subdomain changed (and only then), submit Change of Address for every verified variant of the old domain. Do not use it for http to https, www to non-www, or moving paths within a domain.
• Inspect the home page and three key pages with URL Inspection, and request indexing.

AI crawlers. Check your robots.txt, your CDN and your security plugin for AI crawler rules. OpenAI documents three agents: OAI-SearchBot (shows your site in ChatGPT search), GPTBot (training) and ChatGPT-User (visits triggered by a user’s question). Each is controlled independently, and OpenAI says a robots.txt change can take about 24 hours to take effect. To be eligible for ChatGPT search results you need OAI-SearchBot allowed. Some CDNs and hosts, Cloudflare included, have been switching AI-crawler blocking on by default for new sites, so a fresh account on a new platform can silently undo your AI visibility. Check the setting yourself rather than assuming.

End of day

• Compare real-time analytics with a typical Tuesday. Traffic should look similar.
• Check your enquiry inbox and phone line. Ask the team to log every enquiry.
• Write the day-one note in a shared doc: what shipped, what broke, what is still open.

Step 7: The 30-day monitoring plan

Google says a small or medium site can take a few weeks for most pages to move, and that Googlebot has to visit every old and new URL at least once before the move counts as complete. So a wobble is normal. The job is to tell a normal wobble from a real problem.

Check the same things on the same days, and write the numbers down.

What to look at, and where:

• Search Console, Pages (indexing): are new URLs moving into “Indexed”? Are “Not found (404)” or “Page with redirect” counts climbing in a way you did not expect?
• Search Console, Sitemaps: discovered URLs vs indexed URLs for the new sitemap.
• Search Console, Performance: clicks and impressions for the top 30 queries and the top 20 pages, compared with your baseline.
• Search Console, Crawl stats (Settings): are crawl requests healthy and are server errors near zero?
• Analytics: organic sessions and, more important, enquiries.
• Your inbox and phone: the only number your bank account cares about.
• Server logs or 404 report: the most requested missing URLs. Each one is a redirect you forgot.

Our rules of thumb (these are our working thresholds from running migrations, not Google guidance, so treat them as triggers to investigate, not as laws):

When	Healthy	Investigate
Day 1	Redirect script clean, no noindex, sitemap accepted	Anything not 200 or 301
Day 3	Top pages inspected as indexable, 404 list short	Top-10 page returning 404 or “Excluded”
Day 7	Organic sessions within about 20% of baseline	More than 30% down and falling
Day 14	Most old URLs show as redirecting, new URLs indexed	A top page missing from the index
Day 30	Clicks recovering toward baseline, enquiries steady	Enquiries down more than a third with no seasonal reason

What to do on day 7 if things dip: do not rewrite the site. First check the boring causes in this order: robots and noindex, redirect chains and loops, canonical tags pointing at the wrong place, a missing sitemap, slow pages (Core Web Vitals), and tracking gaps that make a normal week look like a collapse. Most dips are one of those six.

Common mistake: making content changes in week two to “fix” a dip. That adds a second variable and ruins your diagnosis. Fix technical faults immediately. Leave content alone until week four.

Keep the redirects live. Google says to keep them at least one year. We suggest keeping them indefinitely unless there is a strong reason not to. Update your own internal links, ad destinations, social profiles, email signatures and the biggest external links so they point at the new URLs directly.

Step 8: Write the rollback plan before you need it

A rollback plan is a half page, agreed in advance, that says what counts as a disaster and exactly what you do about it.

Rollback triggers (agree these in writing):

1. The site is down or throwing errors for more than 30 minutes
2. Forms or checkout do not work and cannot be fixed within two hours
3. A sitewide noindex or robots block cannot be removed quickly
4. More than a third of your top-50 URLs do not resolve correctly after redirect testing

Rollback steps:

1. Named decision-maker says “roll back” (one person, not a committee)
2. Point DNS back to the old host (quick, because you lowered the TTL)
3. Restore the old site from the backup if anything changed
4. Remove the new site’s redirects if they are interfering
5. Post a status note to the team, then diagnose on staging

Be honest about the limits. Rolling back in the first hours is clean. After a few days, Google has started processing the move and browsers have cached 301 redirects (Shopify’s own help warns that removing a 301 may not take effect for some visitors until their cache expires). A late rollback is a second migration, so prefer fixing forward unless the trigger is severe.

Platform specifics: Shopify, WordPress, Webflow

Each platform has one trap that catches people who have not migrated onto it before.

Shopify

• Where: Content, Menus, URL redirects. Bulk upload with Import and a CSV, then review and click Import redirects.
• The trap: Shopify fixes the structure of /products/, /collections/ and /blogs/. If your old store used different folders (a WooCommerce /product-category/..., for instance), every product and category URL changes and needs a redirect. You cannot redirect away from /products or /collections/all themselves.
• Redirects only work from URLs that are currently broken. If the old URL still loads a valid page, the redirect will not fire. Hiding a collection or setting a product to Draft makes its URL a 404 and so eligible for a redirect; making it visible again deletes the redirect.
• Some prefixes cannot be redirected from at all: /apps, /cart, /orders, /services and /shop, among others. Redirects from URLs with query strings may not behave as expected, and tag-filtered collection URLs cannot be redirected.
• Standard stores can hold up to 100,000 redirects.
• Redirects start working immediately.
• Also check: product variants, handle changes, discontinued products (redirect to the closest category, never the home page), and your blog base URL.

WordPress

• Where: a redirect plugin (Redirection, Rank Math or Yoast Premium) for a few hundred rules, or server-level rules (.htaccess on Apache, nginx.conf) for large sets, which are faster.
• The trap: the “Discourage search engines from indexing this site” checkbox in Settings, Reading. It is ticked on many staging sites and often survives into launch. Also check that your SEO plugin has not set noindex on post types or taxonomies by accident.
• Changing permalink structure changes every URL. If you must, write one pattern redirect and test it.
• Page builders and plugins: old builder shortcodes, leftover plugin pages and ?p=123 URLs often get indexed. Include them in the inventory.
• AI crawler rules: SEO and security plugins sometimes write AI-bot blocks into robots.txt. Read the file after every plugin update.

Webflow

• Where: Site settings, in the 301 redirects section. CSV import is supported.
• The trap: CMS collection URLs. Changing a collection’s slug or a CMS item’s slug changes the URL, and in practice CMS redirects are often one manual rule per item, with no native wildcard. Webflow’s help pages suggest keeping total redirects to roughly a thousand, so keep the rules tight and avoid redundant ones.
• Turn off indexing of the free .webflow.io staging address, otherwise it can compete with your real domain.
• Also check: folder-level pages, 404 page, sitemap auto-generation setting, and custom code for tracking added in the old platform.

Protecting AI visibility during a move

AI tools such as ChatGPT, Gemini, Perplexity and Google AI Mode build their answers from what they can crawl and what other sites say about you. A migration can shift that overnight, and nobody sends you a warning.

Google states that appearing in its AI features needs no special optimisation: a page must be indexed and eligible to show with a snippet, and normal SEO practice applies. That means everything above (clean redirects, crawlable text, matching structured data) protects you in AI results too. It also means the other AI tools care about the same basics. And it matters, because Pew Research Center’s analysis of 900 US adults’ browsing in March 2025 found that people clicked a traditional result in 8% of visits when Google showed an AI summary, against 15% when it did not. When fewer people click, being the named source counts for more.

The AI-safe migration checklist:

• Run the 20-prompt baseline (template below) before launch and again at weeks 2, 4 and 8
• Keep every old URL redirecting. AI answers cite specific URLs. If an assistant has your old address in its index, the redirect keeps the citation alive while the new URL gets picked up.
• Allow the crawlers you want in robots.txt and at the CDN, and confirm OAI-SearchBot is not blocked
• Keep your facts consistent: company name, address, services, pricing guidance, credentials and team names should read the same on the new site, your Google Business Profile, LinkedIn and directories
• Do not rename during a move. In audits we often find an old rebranded site still live, so AI treats the old name as a separate competitor. A migration is the moment to retire the old domain properly, with redirects, not to run two versions.
• Keep original publish dates on articles. Resetting every date to launch day tells AI tools (which pay attention to dates) that your evidence is brand new. Show a real “updated” date when you genuinely update.
• Keep proof as text: credentials, case study numbers, review counts and author bios should sit in the page HTML, not just in images
• Keep answer blocks. If a page opens with a clear 40 to 60 word answer and a FAQ, keep them. Our AI search optimisation work leans on these.

20-prompt baseline template:

#	Prompt (what a buyer types)	Tool	Date	We named?	Competitors named	URL cited
1	“Best [service] in [city]”	ChatGPT
2	“Who should I hire for [problem]”	Perplexity
3	“[Service] cost UK”	Google AI Mode
…

Run each prompt with and without your brand name, and with and without a location. Log what you see. It will not be identical every time, so look for patterns across the 20, not one-off results. We do not promise a movement either way. What we can promise is that you will know.

Our MVPs case study shows what AI visibility work looks like when it compounds, and why you do not want to reset it by accident.

The migration timeline

When	What
8 to 6 weeks before	Crawl, export, merge into the inventory. Baseline snapshot. Decide each page’s fate.
6 to 4 weeks before	Build the redirect map. Stakeholder sign-off on keep/merge/retire. Staging build begins with same URLs.
4 to 2 weeks before	Staging review. Redirect script test on staging. Tracking, forms, schema and robots checked. Write the rollback plan.
2 weeks to 1 day before	Content freeze. Lower TTL. Backups. Verify Search Console properties. Launch rehearsal.
Launch day	Go live, redirects on, noindex off, sitemap in, tests run.
Day 1 to 30	Check on days 1, 3, 7, 14, 30. Fix technical faults at once. Leave content alone.
Day 30 to 90	Phase two: improve the thin pages, merge candidates, add the new content. Re-run the AI baseline.
Month 12	Review the redirects. Keep the ones with traffic or links.

Templates

Crawl comparison sheet (before and after)

Check	Before	After	Pass?
Total indexable URLs
URLs returning 200
URLs returning 404
Redirects (301)
Redirect chains
Pages missing a title
Pages missing an H1
Pages with noindex
Canonicals pointing elsewhere
Images missing alt text
Pages with structured data
Average word count (top 20 pages)

Crawl the old site before launch and the new site after launch with the same tool and the same settings. Differences you did not plan are your to-do list.

The one-page launch brief

Fill this in and put it where everyone can see it.

• Launch date and time:
• Decision-maker:
• Who is at their desk: (developer, SEO, content, owner)
• Rollback triggers agreed: yes/no
• Old host and backup location:
• DNS provider and TTL set to 300 on:
• Redirect map version:
• Tracking checked by:
• Enquiry log owner for 30 days:

What to do if you are already mid-disaster

If you launched last week and traffic has dropped, do these in order. Do not rewrite anything yet.

1. Check robots.txt, the meta robots tag and the X-Robots-Tag header for a block
2. Run your old URL list through the redirect script and fix any 404s or chains
3. Check canonicals on the new pages: do they point to themselves, or to the staging domain?
4. Submit the correct sitemap and inspect the home page
5. Compare 404s in Search Console and server logs with your map. Add the missing redirects.
6. Check Core Web Vitals. A heavier new design can wreck page speed.
7. Confirm analytics and forms are recording properly. Sometimes the traffic is fine and the measurement is broken.
8. Give it a few weeks before concluding anything else. Google’s own guidance expects a move to take that long.

Questions people ask

Does a website redesign hurt SEO?

It can, but it does not have to. Rankings fall when URLs break, content gets thinner, pages slow down or a crawl block goes live. A redesign that keeps the URLs and core copy, redirects whatever changes, and passes the launch checklist usually settles in a few weeks. Google itself says to expect fluctuations during a move.

How long does it take to recover rankings after a migration?

Google says a small or medium site can take a few weeks for most pages to move, and larger sites take longer. We watch for stabilisation over about four to eight weeks. If top pages are still missing from the index after that, look for a technical cause in redirects, canonicals or robots rules rather than waiting.

Do I need 301 redirects when I change my website design only?

If no URL changes, you do not need redirects for those pages. If the platform change alters any URL, even adding a trailing slash or changing /product/ to /products/, each changed address needs a 301 to its new equivalent.

How long should I keep 301 redirects?

Google says generally at least one year. We suggest keeping them for as long as they get traffic or have links pointing at them, which for most sites means indefinitely.

Should I use Google’s Change of Address tool?

Only when the domain or subdomain changes, for example from one domain name to another. Google says not to use it for http to https, www to non-www, or moving paths within a domain.

Will changing platforms (WordPress to Shopify, Wix to Webflow) affect my rankings?

The platform itself is not a ranking factor. What changes is your URL structure, page speed, how much control you have over robots, redirects and structured data, and what ends up in the HTML. Check each of those during the inventory and testing, using the platform notes above.

How do I stop my staging site being indexed?

Password protect it at the server. If you cannot, use noindex and make sure robots.txt does not block those pages, because Google can only see noindex if it is allowed to crawl the page.

Want us to do this for you?

If you would rather hand over the inventory, the redirect map and launch day to people who have done it before, we do that as part of our website and SEO work, and we start with a free call where we look at what your current site is earning. We will tell you honestly if a rebuild is the right move or if fixing the existing site would do the job.

Sources

• Google Search Central, “Site move with URL changes”, Search Central documentation, accessed November 2026
• Google Search Central, “How to specify a canonical URL with rel=canonical and other methods”, Search Central documentation, accessed November 2026
• Google Search Central, “Block Search indexing with noindex”, Search Central documentation, accessed November 2026
• Google Search Central, “Google Image SEO best practices”, Search Central documentation, accessed November 2026
• Google Search Central, “AI features and your website”, Search Central documentation, accessed November 2026
• Google web.dev, “Web Vitals”, Google, accessed November 2026
• OpenAI, “Overview of OpenAI Crawlers”, OpenAI developer documentation, accessed November 2026
• Shopify Help Center, “URL redirects”, Shopify, accessed November 2026
• Webflow Help Center, “301 redirects”, Webflow, accessed November 2026 (the redirect-count guidance of roughly 1,000 is Webflow’s recommendation, not a hard limit)
• Search Engine Land, “Cloudflare to block AI crawlers by default with new pay per crawl initiative”, Search Engine Land, July 2025
• Pew Research Center, “Google users are less likely to click on links when an AI summary appears in the results”, Pew Research Center, July 2025