How To Follow Website Migration SEO Best Practices

Website migration SEO is the discipline of moving a site, whether you are changing domain, CMS, URL structure, or protocol, without handing your organic traffic to a competitor. Done right, rankings hold and sometimes improve. Done carelessly, you can erase years of authority in a single launch. This is the sequence Victoria Olsina follows, and it is the same one she hands to founders after a strategy call. Outcome: a controlled move with parity on day one. Time budget: two to six weeks. Skill level: intermediate.

What You’ll Need Before You Start

A migration lives or dies on what you record before you touch anything. Skip this section and you are flying blind for the next eight weeks.

Tools and access required

You need admin access to Google Search Console, Google Analytics, your CMS, DNS, and hosting. No exceptions. Losing access on launch day is a common way to turn a two-hour job into a two-day outage, and it is the kind of avoidable mistake Victoria Olsina lists in her technical SEO notes.

You also need a crawler. Screaming Frog or Sitebulb will produce the URL inventory that becomes your migration map: every URL, its status code, its metadata, its internal links, and its canonical tag. Without this file you cannot build a redirect map you trust, and without a trustworthy redirect map you cannot prevent the 404 errors that leak link equity after launch.

Benchmarks to record now

Export current organic traffic, top-ranking keywords, indexed page counts, and crawl errors from Search Console before any change is made. Freeze a baseline of your top 100 keyword positions in a spreadsheet. Post-launch fluctuations get measured against that fixed reference, not against memory, and this is where a disciplined on-page SEO baseline pays off.

Identify your highest-value pages by organic traffic and backlink count. These pages carry the most risk and the most upside. They are also the ones where a lazy redirect will hurt you the most.

Then assemble stakeholders: engineering, SEO, content, and analytics. Aligning after scope is locked is not alignment, it is damage control. Get everyone in one room while decisions are still cheap, and if you need a second opinion before locking scope, book a call.

Takeaway: if you cannot show the pre-migration baseline in a spreadsheet, you are not ready to migrate.

Before You Start: What Can Break and What to Back Up

Setup is a five-minute job. Getting it right is a lifetime job. Know the failure modes before you touch production.

The failure modes that kill rankings

Missing or incorrect 301 redirects are the single biggest cause of ranking drops. Search engines cannot pass authority from old URLs to new ones without them, and every unredirected URL is a page of link equity thrown away. Read the sitemap XML playbook before you assume your CMS will regenerate the map for you.

Accidental noindex tags or a robots.txt that blocks crawlers on the live site have wiped entire domains off Google in hours. It happens when a staging config ships to production. Check both files with a crawler in the first thirty minutes after launch, or you will not notice until traffic collapses on day three. This is the same discipline Victoria Olsina writes about in her Web3 SEO notes, because on-chain projects fail here constantly.

Duplicate content arises when both old and new environments get indexed at once. Canonical tags plus HTTP authentication on the staging environment prevent it. Broken internal links after a URL restructure fragment crawl paths and starve priority pages of equity, which is why featured snippet-worthy pages tend to lose their spots first.

What a safe staging environment looks like

Full database and file backup before you touch anything. That is your rollback point. Staging behind HTTP auth or IP allowlist so Google cannot index it. Every canonical tag on staging points at itself, not at production, because you do not want Google confused about which URL to serve. When agents start crawling both environments, the confusion compounds fast, which is one reason she keeps pushing founders to make sure the site is discoverable by agents only after launch, not during staging tests.

Takeaway: if there is no rollback plan, there is no migration plan.

Step-by-Step: Pre-Migration SEO Checklist

Step 1: Audit and map every URL

Crawl the live site with Screaming Frog. Export the full URL inventory. For every URL with inbound links or organic traffic, assign a best-match destination on the new site. This spreadsheet is the single most important artefact of the whole project, and the same audit discipline underpins the full-funnel content system Victoria Olsina built with Bando.

Verification: every source URL has exactly one target URL, and no target URL is the homepage unless the old URL was also the homepage. Redirecting a high-traffic product page to the root passes zero topical authority and Google will treat it as a soft 404.

Step 2: Build and validate your redirect map

Turn the spreadsheet into a redirect file, whether that is nginx config, an .htaccess block, a WordPress plugin, or a CDN rule. Every redirect is a 301, not a 302, and there are no chains. Chains dilute authority and slow the crawl, and the same principle applies whether you are moving a marketing site or a stablecoin project.

Verification: crawl your old URL list against the new environment and confirm every response is a single-hop 301 to the correct target.

Step 3: Test on staging before touching production

Replicate metadata, structured data, and canonical tags on the new environment. Migrating content without migrating signals is a classic reason rankings drop the week after launch. Check Core Web Vitals on staging: a CMS switch that halves your LCP score will cost you, according to Google’s page experience documentation.

Verification: staging crawl matches production crawl for title tags, meta descriptions, canonicals, structured data, and internal link counts. Any drift gets fixed before launch. This is also the moment to sanity-check that your new stack can be automated by the AI marketing agent workflows you rely on for content ops.

Takeaway: the redirect map is not done until a crawler confirms every old URL returns a single 301 to a topically relevant destination.

Step-by-Step: Launch Day Protocol

Step 4: Execute the migration in a controlled window

Pick a mid-week, low-traffic window outside peak trading. Tuesday or Wednesday morning is usually safest. Have engineering, SEO, and analytics on the same call, and keep the rollback command copy-pasted in a document. This is the same operational rhythm described in the scaling with AI framework.

Do not stack a domain change, a CMS switch, and a URL restructure into a single launch. Phase them. When something breaks, and something will break, you want to isolate the cause in minutes, not days. According to Google Search Central guidance, staged moves are easier for Googlebot to reprocess as well.

Step 5: Verify redirects and indexation immediately

The moment DNS switches, crawl the live site. Confirm redirects fire. Confirm no page returns a 404 or a 500. Confirm robots.txt is not the staging version. Confirm noindex tags are absent from anything you want indexed. The whole check should take under an hour with a crawler running in the background, and it is the same verification pass Victoria Olsina runs before shipping custom GPTs that scrape client sites.

Step 6: Update Search Console and sitemaps

Submit the new XML sitemap to Search Console. If you changed domain, use the Change of Address tool to formally notify Google. Verify analytics tracking codes fired on launch, because a gap in analytics data on day one makes the whole post-migration analysis unreliable. The same principle carries into how LLM SEO monitoring works: without clean logs, you cannot debug what the models are seeing.

Takeaway: launch is not complete until a crawler confirms parity and Search Console has the new sitemap.

Post-Migration Monitoring: How to Confirm Nothing Broke

What to watch in the first 30 days

Check Search Console daily for the first two weeks. Watch for crawl error spikes, drops in indexed pages, and manual actions. These are your early warning signals, and the same monitoring cadence applies whether you are running a marketing site or an AI agents product.

Compare organic traffic week-over-week against the pre-migration baseline. A dip of 15 to 20 percent in the first few weeks is common while Google reprocesses. A sustained drop of more than 30 percent by week four is a signal that something in the redirect map or indexation setup is wrong, and it is worth reviewing the crawl logs the way outlined in the ChatGPT monitoring workflow.

Track keyword rankings for your top 100 terms daily during month one. Rank movement points you at which specific pages need redirect corrections or content review.

When fluctuations are normal and when to act

Reach out to domains linking to old URLs not covered by redirects and ask them to update the link. A direct backlink recovers equity that a redirect chain cannot fully preserve, and this outreach layer becomes even more important as the agentic web makes crawler behaviour less predictable.

After eight weeks, run a full site crawl. Look for residual redirect chains, broken internal links, and orphaned pages. Fix them. This is the audit the Web MCP protocol will eventually automate, but for now it is a manual pass.

Takeaway: if you are not monitoring daily for the first month, you are not migrating, you are gambling.

Troubleshooting

• Symptom: organic traffic drops more than 30 percent after two weeks. Cause: redirects are missing, chained, or pointing to irrelevant targets. Fix: crawl the old URL list, patch every non-200 or multi-hop response, and resubmit the sitemap. Cross-check with tool reviews if your current crawler is missing edge cases.
• Symptom: indexed pages collapse in Search Console. Cause: robots.txt is blocking or a global noindex shipped to production. Fix: replace robots.txt with the production version, remove the noindex, request indexing on priority URLs.
• Symptom: duplicate content warnings appear. Cause: staging is still crawlable, or HTTP and HTTPS are both serving. Fix: lock staging behind auth and force HTTPS at the server level.
• Symptom: Core Web Vitals scores drop. Cause: new stack is not configured for caching, image optimisation, or CDN. Fix: enable caching, ship images through a CDN, defer non-critical scripts.
• Symptom: analytics shows zero traffic on launch day. Cause: tracking snippet did not migrate. Fix: reinstall GA4 tag, verify with real-time reports.

Conclusion

A migration is a high-risk, high-reward event, and the difference between a win and a disaster is almost entirely in preparation and monitoring, not the launch itself. Handled well, it protects rankings. Handled poorly, it deletes them.

Follow the sequence: audit, map, stage, launch in a controlled window, monitor daily for a month. The biggest failures Victoria Olsina sees are skipped audits, lazy redirects to the homepage, and silence in Search Console after launch.

FAQ: Frequently Asked Questions

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

Most sites stabilise within four to eight weeks if redirects are clean. Complex domain moves can take three to six months for full recovery. Sustained losses past that point usually mean the redirect map or content parity is wrong.

Do I need 301 redirects if I’m keeping the same domain?

Yes, if any URL changes. Even a slug rewrite requires a 301 to preserve link equity and stop internal links from breaking. Only a CMS swap that preserves every URL exactly can skip redirects, and even then you verify with a crawl.

What is the biggest SEO risk during a website migration?

Broken or missing 301 redirects. Every unredirected URL is a page of accumulated authority thrown away, and search engines cannot reconnect old signals to new locations without an explicit map. Everything else is secondary to getting this right.

Should I migrate my website and redesign it at the same time?

No. Phase them. Migrate first with visual parity, verify rankings hold, then ship the redesign. Combining both makes it nearly impossible to isolate which change caused a ranking drop, and troubleshooting doubles in cost.

How do I tell Google about a domain change?

Use the Change of Address tool in Search Console after both domains are verified. Submit the new XML sitemap. Keep 301 redirects live for at least twelve months so Google has time to fully transfer signals to the new domain.

Does changing CMS always cause a rankings drop?

Not if URLs, metadata, structured data, and Core Web Vitals reach parity or better. Drops usually come from unnoticed regressions: slower page speed, missing canonicals, or a template that stops rendering key content server-side.

How do I check if my redirects are set up correctly?

Crawl your old URL list against the new environment with Screaming Frog or Sitebulb. Every URL should return a single-hop 301 to a topically relevant target. Chains, 302s, and redirects to the homepage all count as failures.

What should I monitor after a website migration is complete?

Search Console crawl errors and indexation daily for two weeks, organic traffic week-over-week against baseline, top 100 keyword rankings daily for month one, and a full site crawl at week eight to catch residual redirect chains and orphans.

Get a second pair of eyes on your migration

Victoria Olsina reviews redirect maps and launch plans for crypto and Web3 sites as part of her crypto SEO service. Book a free strategy session before you ship and she will walk through the plan with you.