Website Migration SEO Checklist: 4 Stages Before and After Launch
You launched the new site on a Thursday. By the following Monday, organic traffic was down more than half, three of your best-converting pages returned 404s, and nobody could tell you why.
This is the most common preventable disaster in small business marketing, and it is almost never caused by the thing people worry about. It is rarely the design. It is rarely the CMS. It is nearly always a set of small technical decisions that were made by whoever happened to be pushing the site live, at 11pm, with no checklist.
Here is the checklist. It runs in four stages, and it starts a step earlier than every other migration checklist you will find.
A website migration is any change to your domain, URL structure, protocol, CMS, or site architecture. Traffic drops when old URLs are not redirected to matching new ones, or when the new site blocks crawling. Before you audit URLs, confirm you control your domain registrar, hosting, Google Search Console, and analytics. Then benchmark, map redirects one to one, and monitor for 90 days.
What actually counts as a website migration?
A migration is any change that alters where your pages live or how search engines reach them. Design changes alone are not a migration. Address changes are.
There are five types, and most real projects are two or three of them at once:
- Domain change. oldbrand.com becomes newbrand.com. The highest-risk type, because every single URL changes.
- Protocol change. HTTP becomes HTTPS. Sounds trivial. Leaves hardcoded internal links pointing at the old protocol for years if the templates are not audited.
- URL structure change. /blog/post-name becomes /insights/2026/post-name. Common when switching CMS.
- Platform change. WordPress to Webflow, Shopify to WooCommerce. URL patterns almost always shift even when nobody intended them to.
- Site consolidation. Two domains merge into one, or a subdomain moves to a subfolder.
If your project is only a visual refresh and every URL stays identical, you do not need this checklist. You need a website redesign checklist, which covers the design, content, and conversion decisions instead. Use both if your redesign also changes URLs, which it usually does.
Why do websites lose traffic after a migration?
Because search engines treat a new URL as a new page with no history, unless you explicitly tell them otherwise.
Every ranking your old pages earned is attached to a specific URL. Google has spent months or years accumulating signals about that address: which sites link to it, how people behave when they land on it, what queries it answers. Change the address without forwarding it, and all of that evidence points at a page that no longer exists.
Google’s own site move documentation is direct about this. When you move URLs, you need to tell Google which old address maps to which new one, and you need to keep those instructions in place long enough for the index to catch up.
The four failure modes account for nearly every case:
- Missing redirects. Old URL returns a 404. The ranking dies with it.
- Lazy redirects. Every old URL redirects to the homepage. Technically not broken. Strategically identical to a 404, because the homepage does not answer the query the old page ranked for.
- Blocked crawling. The staging site’s robots.txt (with its Disallow: /) goes live with the new site. Google is politely locked out of your entire website.
- Lost internal links. The new templates hardcode the old domain or old protocol into the header logo, footer, or navigation. Hundreds of internal links now point somewhere they shouldn’t.
If you are already past launch and looking at a graph heading down, diagnose before you panic. Not every drop is a migration failure, and the reasons website traffic drops include several that have nothing to do with your new site.
Stage 0: What do you own?
Before you crawl a single URL, confirm you control the five accounts a migration depends on. This is the step every other checklist skips, and it is the one that most often stops a migration dead.
Here is why it matters. A migration requires access to systems that are frequently held by someone other than the business owner: the domain registrar, the DNS records, the hosting environment, the Google Search Console property, and the analytics account. If your previous agency or developer set those up under their own accounts, you will discover it on migration day. Not before.
At that point you have two options, neither good. Ask a departing agency for cooperation on a project that ends your relationship with them, or rebuild from zero and lose your historical data permanently.
We treat this as policy rather than advice. Every account we touch is created in the client’s name, under the client’s billing, with the client as owner and Tabula as a user that can be removed. That is what the marketing ownership framework means in practice, and a migration is the moment it either saves you or costs you.
Confirm before you plan anything:
- Domain registrar login. Is the domain registered to your business, with your email as the admin contact? Check the WHOIS record, not what you were told.
- DNS control. Can you edit A records and CNAMEs yourself, or do you have to submit a request to someone?
- Hosting access. Root or admin, on an account you pay for directly.
- Google Search Console. Are you a verified Owner, not a Delegated Owner or User? Owners can add and verify new properties. Users cannot.
- Analytics. Admin on the GA4 property, plus the ability to export historical data before anything changes.
If any of these is a no, resolve it before the migration is scheduled. If you are in the middle of changing agencies, the marketing handover process covers what to demand and in what order.
Stage 1: What do you record before launch?
Everything you will later need to prove the migration worked, or to find what broke.
You cannot diagnose a post-migration problem without a pre-migration baseline. Take these snapshots and store them somewhere outside the site you are about to replace.
Full URL inventory. Crawl the entire existing site and export every URL that returns a 200. Include images and PDFs. Cross-reference with a Search Console export of every page that received impressions in the last 12 months, because crawlers miss orphaned pages that still rank.
Performance baseline. Export 12 months of Search Console data: queries, pages, clicks, impressions, average position. Export GA4 sessions and conversions by landing page. Twelve months, not three, so you can separate migration damage from seasonality.
Backlink inventory. Export referring domains and the specific URLs they link to. These are the pages where a broken redirect costs you the most, and they are your redirect priority list.
Top pages by revenue and by ranking. Not the same list. Protect both.
Current technical state. Note existing canonicals, robots.txt contents, XML sitemap URLs, and any hreflang in place.
Stage 2: How do you map redirects without losing equity?
One old URL to one matching new URL, using a 301, with no chains.
This is the mechanical core of the migration and it is tedious. There is no shortcut that works.
Map one to one. Every old URL gets a new URL that serves the same intent. A product page redirects to that product’s new page, not the category. A blog post redirects to that post, not the blog index.
Use 301, not 302. A 301 says permanent and passes ranking signals. A 302 says temporary and Google may keep indexing the old URL. Server-side redirects, not JavaScript.
Kill redirect chains. If URL A redirects to B and B redirects to C, point A directly at C. Chains dilute signals and slow crawling.
Handle the genuine orphans deliberately. Some old pages have no equivalent. Redirect them to the closest relevant parent page, and let low-value pages with no links or traffic return a 410. Do not send them all to the homepage.
Fix internal links at the source. Do not rely on redirects to handle your own navigation. Search and replace every absolute internal URL in the new templates. Check the header logo anchor and footer specifically, because those are the two places where a hardcoded old domain or an http:// prefix survives a migration and then appears on every page of the site at once.
Then test in staging. Take a sample of at least 200 old URLs, weighted toward your highest-traffic and most-linked pages, and confirm each one lands where it should with a single 301 hop.
Redirect mapping is the point where most in-house migrations quietly go wrong, because it is slow work with no visible output until launch day. If you would rather not own this part, our SEO service handles migration mapping as part of technical setup, and you keep the map.
Stage 3: What do you check in the first 48 hours?
Whether Google can see the new site at all, and whether the redirects survived deployment.
Work through this in order, on launch day:
- robots.txt. Fetch yourdomain.com/robots.txt in a browser. If it contains Disallow: /, your staging file went live. Fix this first, before anything else on this list.
- Meta robots tags. Check the source of your homepage and three key pages for noindex. Staging environments often set this globally.
- Redirect spot-check. Run your 200-URL sample again against production. Every one should return a single 301 to a live 200.
- XML sitemap. New sitemap generated, containing only live 200 URLs, submitted in Search Console.
- Change of Address. If the domain changed, submit the Change of Address tool in Search Console from the old property. This requires Owner access on both properties, which is why Stage 0 comes first.
- Analytics tracking. Confirm GA4 is firing on the new site. Check real-time reports with your own visit.
- HTTPS and canonicals. Every page loads over HTTPS with a valid certificate, and self-canonicalises to the HTTPS version of itself.
- Live crawl. Crawl production and export every 404, every redirect chain, and every internal link pointing at the old domain.
- Google Business Profile. If you are a local business, the website URL in your profile still points at the old address. So do your citations, your social profiles, and your email signature. Update the profile the same day, because a mismatched URL there weakens the local signals covered in optimising your Google Business Profile.
If pages are still missing from search after a week, work through why a website doesn’t show up on Google before assuming the migration is the cause.
Stage 4: What happens at 30, 60, and 90 days?
You monitor, and you resist the urge to change anything for the first month.
Some ranking volatility after a migration is normal and self-correcting. Google needs to recrawl every redirected URL, and on a smaller site with modest crawl budget that takes weeks. Intervening in week two, based on incomplete data, is how a recoverable migration becomes a permanent loss.
Days 1 to 30. Watch Search Console Coverage daily for spikes in Not Found, Blocked, or Excluded. Watch Crawl Stats to confirm Google is fetching the new URLs. Compare clicks and impressions against your baseline weekly, not daily. Fix technical errors immediately. Change nothing about content, titles, or URLs.
Days 30 to 60. Impressions should be recovering toward baseline. Identify any specific URL still down more than 30% against its own pre-migration numbers and check its redirect individually. Confirm your important backlinks resolve to live pages with one hop.
Days 60 to 90. Compare against baseline properly. Pages still underperforming at this point have a content or intent problem, not a redirect problem, and that is when you start editing. Keep the redirects in place permanently, or at minimum for a year.
What breaks most often and never makes the checklist?
Four things, in our experience auditing sites after migration:
Hardcoded template links. The logo in the header and the links in the footer often carry an absolute URL written into the template by hand. When the domain or protocol changes, that one line generates a broken or redirected internal link on every page of the site simultaneously. It is invisible in the CMS and obvious in a crawl.
Directories accidentally disallowed. A folder blocked during development (case studies, resources, a client portal) stays blocked in the live robots.txt. The pages exist, they are linked, and they cannot be indexed.
Trailing slash inconsistency. The new platform serves /page and /page/ as separate URLs, and your redirects only cover one version. Half your redirect map silently fails.
Old domain still referenced in content. Blog posts, PDFs, and image paths that hard-reference the previous domain. These redirect, so nothing appears broken, and they keep sending signals to an address you no longer use.
None of these produce an error message. All of them show up in a crawl, which is why the crawl at step 8 is not optional.
When should you not migrate?
When the reason is aesthetic and the cost is your entire URL structure.
Changing your domain because the new name sounds better is a decision with a real SEO price. Sometimes that price is worth paying, for a genuine rebrand or a legal requirement. Often it is not, and the same commercial goal can be met by redesigning on the existing domain with the URLs untouched.
Three cases where the risk usually is worth it: consolidating multiple domains that are competing with each other, moving from HTTP to HTTPS, and a rebrand where the old name actively works against you.
One case where it usually is not: you are on oldname.com, you prefer newname.com, and nothing else about the business has changed.
Own the migration, then own what comes after
A migration is a one-week project with a twelve-month consequence. Get the redirects right and you keep everything you built. Get them wrong and you spend a year rebuilding rankings you already had.
The part worth internalising is Stage 0. Redirect mapping is a solved problem that any competent technical SEO can execute. Account ownership is not solvable on launch day. If someone else holds your registrar, your hosting, or your Search Console, your migration happens on their timeline and with their cooperation, and you find out on the worst possible day.
Check that first. Then work the list.
If you have a migration coming up and want a second pair of eyes on the redirect map before launch, or you are looking at a traffic drop after one and need it diagnosed, get in touch. Either way, the map is yours.
And once the new site is live, it needs maintaining, not just launching. What ongoing website maintenance actually involves covers what should happen in month two.
Frequently asked questions about website migrations
How long does it take to recover rankings after a website migration?
Most sites stabilise within 30 to 60 days if redirects are correct, though larger sites with slower crawl rates can take longer. Anything still down against its own baseline at 90 days is a content or intent problem, not a redirect problem. Resist making changes in the first month.
Do I need to keep 301 redirects in place forever?
Keep them permanently where possible, and for a minimum of one year. Google eventually treats a 301 as consolidated, but external links pointing at your old URLs never expire. Remove the redirect and those links start returning 404s, costing you referral traffic and the link equity itself.
Will changing my domain hurt SEO even if I do everything right?
Expect short-term volatility regardless. A correctly executed domain migration typically sees a temporary dip during recrawling, then recovery. The permanent losses come from missing or lazy redirects, not from the domain change itself. Submit the Change of Address tool in Search Console to speed up recognition.
What is the difference between a website redesign and a website migration?
A redesign changes how pages look. A migration changes where they live. If every URL stays identical, you have a redesign and no redirect work is needed. If your domain, protocol, URL structure, or platform changes, you have a migration, and most redesigns quietly include one.
Can I redirect all my old pages to the homepage?
No. It technically avoids 404s but throws away every ranking those pages held, because the homepage does not answer the queries they ranked for. Google increasingly treats mass homepage redirects as soft 404s. Map one old URL to one matching new URL that serves the same intent.
Do I need to resubmit my sitemap after a migration?
Yes. Generate a new XML sitemap containing only live 200 URLs on the new structure and submit it in Search Console. Keep the old sitemap accessible on the old domain for a short period so Google can discover the redirects it lists more quickly.
Author
Carlos Rios
Carlos Rios is the Founder of Tabula. Before starting the agency, he spent his career inside companies — reporting to leaders who had no patience for vanity metrics and wanted straight answers about what was working and why. He built Tabula around that same standard: a marketing system the client owns, powered by AI and led by experts who explain the plan in plain language. Carlos studied philosophy for six years at York University and holds a Master's in Marketing from the Schulich School of Business.
