In February the managing partner of a mid-size Prague law firm called us in a panic. Two weeks earlier, his agency had launched a long-overdue redesign of their website. The new design was crisp, the brand refresh looked sharp, and the partners had finally signed off on the homepage copy after six months of revisions. The launch went out on a Friday afternoon. By Monday morning, organic traffic had dropped 60%, the contact form was broken, and three of their highest-converting service pages returned 404 errors.
The agency had done what a surprising number of agencies still do in 2026: they built a beautiful new site, flipped the DNS, and crossed their fingers. There was no redirect map. The new URL structure was different from the old one, but no one had bothered to wire the old URLs to their new equivalents. Pages that had taken years to earn rankings on Google were simply gone, replaced by 404s that Googlebot would soon stop visiting.
Migrating a website is one of the highest-risk things a business will ever do online. Done well, it is invisible to your customers and your search rankings. Done badly, it can erase years of SEO equity overnight. This guide is the playbook we follow when we run a migration, whether the project is a full redesign, a replatform off a legacy CMS, a domain change after a rebrand, or a rescue of a site whose previous team disappeared. If you are about to move your site, read this first.
What "website migration" actually means in 2026
The word "migration" gets used loosely. In practice, it covers at least five distinct types of project, and each carries a different risk profile. Knowing which one you are doing changes the playbook.
Visual redesign on the same platform. Same URLs, same CMS, same backend, new design. This is the lowest-risk migration. As long as your URL structure does not change, search rankings rarely move. The risk is mostly in performance regression if the new design loads more assets than the old one. Detailed in our post on when your site actually needs a redesign.
Replatform to a different CMS. Moving from WordPress to a custom Nuxt or Next.js stack, from Wix to a headless CMS, from a hand-coded site to Shopify. This is medium-to-high risk because URL structures usually change and the new platform may render content differently. We covered the why behind these moves in our deep dive on when a traditional CMS becomes a bottleneck and the trade-offs in WordPress vs custom.
Domain change. Often after a rebrand, an acquisition, or moving from a country-specific domain to a global one. Search engines treat the new domain as a separate property until you prove the old one moved, so this is among the highest-risk migrations.
Information architecture overhaul. Same domain, same platform, but the structure of the site changes: categories are merged, URLs are restructured, navigation is rebuilt. From a search perspective this can be as disruptive as a domain change, because the URLs Google has indexed for years are no longer where you said they were.
Hosting or infrastructure migration. Same domain, same code, new servers or new CDN. Usually low risk if executed carefully, but TLS misconfigurations, IP geolocation changes, or robots.txt drift during the move can cause real problems.
Before you do anything else, name what kind of migration you are doing. The mitigations below differ depending on which of these you are running.
The pre-migration audit: what you must inventory before you touch anything
Most migration disasters trace back to the same root cause: the team did not actually know what they had before they replaced it. The audit phase is where you establish the baseline that everything else gets measured against.
Start by exporting a full crawl of the existing site. Screaming Frog or Sitebulb will do, as will most agency-grade SEO platforms. You want every URL the spider can reach, every redirect already in place, every meta title and description, every canonical tag, every H1, and every internal link. Save this crawl somewhere durable. It is the single most useful artifact in the entire migration.
Pull the top 200 organic landing pages from the last 12 months in Google Analytics and Search Console. These are your high-value URLs. Every one of them needs an explicit destination on the new site. If a page in your top 200 is not in your redirect map at launch time, you are choosing to lose that traffic.
Inventory the backlink profile. Use Ahrefs, Semrush, or Search Console's link report to identify the URLs other sites have linked to. Backlinks are the asset that takes the longest to rebuild, and they point at specific URLs. If a high-authority backlink is pointing at a URL that 404s after launch, you are not just losing that traffic, you are losing the link equity that page used to pass to the rest of your site.
Capture a baseline of Core Web Vitals for the top templates. PageSpeed Insights, Chrome User Experience Report, and your real-user monitoring data should all agree on what "normal" looks like for the current site. After launch, you will compare against this baseline to detect regressions before customers do.
If you want a deeper framework for what to inspect, our SEO audit page lists the diagnostic questions we run through, and the security audit service catches the configuration issues that always seem to surface during a cutover.
301 redirects: the single most common reason migrations fail
If you only do one thing right during a migration, get the redirects right. Every URL on the old site that has any value, organic traffic, indexed status, internal or external link pointing at it, needs a 301 redirect to its closest equivalent on the new site. Not a 302. Not a soft 404 that returns a 200 status with a "page not found" message. A clean 301.
Build the redirect map as a spreadsheet with three columns: old URL, new URL, status. The map is generated during the architecture phase, not at the end. Every page you decide not to recreate on the new site needs a deliberate decision: redirect to the closest parent category, redirect to the homepage as a last resort, or accept the loss of that page if it had no traffic and no links.
Edge cases that bite teams every time: query strings (does /products?id=42 need to redirect somewhere?), trailing slashes (does /about and /about/ resolve to the same place?), case sensitivity (does /Services redirect to /services?), and locale paths (do /en/about, /about, and /ru/about all have correct cross-locale redirects?). Test each of these explicitly before launch.
For sites with more than a few hundred URLs, do not test redirects manually. Run the old site's full URL list through a tool like httpstatus.io or write a small script. Every URL should return a single 301 to the correct destination, with no chains and no loops. A redirect chain (URL A → URL B → URL C) loses link equity at each hop and slows down crawlers. A redirect loop is a guaranteed indexation problem.
If you are using Cloudflare or another modern edge platform, redirects can be handled at the CDN layer with sub-millisecond latency. We do this on most projects because it keeps the application code clean and makes redirect changes deployable without a full release.
Preserving on-page SEO: titles, meta descriptions, headings, schema, alt text
The redirect map gets the right URL to load. The on-page audit makes sure that, when it loads, Google still sees a page that deserves the ranking it had.
For every URL in your top 200, copy the existing title tag, meta description, H1, and main body content into the new site verbatim, unless you have a specific reason to change them. "Improving" the title tag of a page that ranks #2 for a high-value keyword is one of the most expensive optimization mistakes you can make. If a page is already performing, the goal of migration is to preserve its performance, not to reinvent it.
Schema markup is the second biggest on-page liability. If your old site had Article schema, FAQPage schema, BreadcrumbList, Organization, or LocalBusiness markup, the new site must implement the same types on the same URLs. Validate every template with Google's Rich Results Test before launch. A missing schema graph will not 404 you, but it will quietly remove your rich snippets from search results, and that drop in click-through rate looks identical to a ranking drop in your reports.
Alt text on images is the easiest thing to forget. When the design team rebuilds image components, the alt attribute is often dropped or replaced with placeholder text. Crawl the new staging site and confirm every image that had alt text on the old site has alt text on the new one. We have written more about this in our technical SEO checklist for new website launches, which covers the full pre-flight inventory.
Technical SEO during the cutover: robots.txt, sitemaps, hreflang, canonical tags
The 24-hour window around launch is when configuration mistakes do the most damage. A few specific things to triple-check.
Robots.txt. The single most common launch-day catastrophe is shipping a robots.txt file that still says Disallow: / from the staging environment. Every staging site should be blocked from crawlers. Every production site needs that block lifted. Audit the production robots.txt before you flip DNS, and again after the new site is live.
XML sitemap. Submit a fresh sitemap to Google Search Console immediately after launch. The sitemap should reflect the new URL structure with accurate lastmod dates. If the old sitemap is still referenced from robots.txt, update that reference to the new sitemap URL.
Hreflang. For multi-locale sites like ours, hreflang tags tell search engines which version of a page to show to which users. The new site must implement hreflang on every translated page, with correct language and region codes, and with reciprocal entries between locales. A broken hreflang setup splits ranking signals across language versions and is invisible to anyone not specifically looking for it.
Canonical tags. Every URL on the new site should declare a self-referencing canonical, except where you deliberately want to consolidate (for example, paginated archives canonicalizing to the unparameterized version). A missing canonical on a templated page can cause Google to pick a different URL as the "correct" one, and that URL is often not the one you wanted to rank.
Performance and Core Web Vitals: do not migrate to a slower site
One of the most depressing patterns we see is a beautiful new design that ranks worse than the old one because it is slower. Modern design trends, custom fonts, animations, video backgrounds, and large hero images all carry performance cost. If the new site has worse Core Web Vitals than the old one, the migration is a downgrade no matter how it looks.
Run Lighthouse and PageSpeed Insights against the new staging site before launch and compare the numbers to your pre-migration baseline. The metrics that matter most: Largest Contentful Paint (LCP) under 2.5 seconds, Interaction to Next Paint (INP) under 200 milliseconds, and Cumulative Layout Shift (CLS) under 0.1. If any of these regressed against the old site, fix it before you launch, not after.
Common culprits we see in 2026: hero videos that autoplay before the page is interactive, web fonts loading without font-display: swap, third-party tags that block the main thread, and image components that ship the same JPEG to every device instead of serving responsive WebP variants. Our website speed optimization page goes deeper on the diagnostic flow, and the performance service is what we offer when a site has shipped slow and needs to be fast.
The launch-day checklist: a sequenced playbook
Launch day is not a single event. It is a sequence of steps with a specific order. Doing them out of order is how teams ship a site that returns 503 errors for the first hour, or worse, that gets indexed in its broken pre-launch state.
Below is the runbook we follow on the day of cutover. Do not launch on a Friday and do not launch in the evening. Tuesday or Wednesday morning gives you the rest of the workday plus the next two days to respond to anything that goes wrong.
| Step | Action | Why it matters |
|---|---|---|
| 1 | Final staging review against the redirect map | Catch missing or wrong redirects before they hit production |
| 2 | Confirm production robots.txt allows crawling | Single most common launch-day disaster |
| 3 | Verify SSL certificate covers the new site and any subdomains | Browser warnings tank conversion within minutes |
| 4 | Lower DNS TTL to 300 seconds 24 hours before cutover | Lets you roll back fast if something breaks |
| 5 | Flip DNS to the new origin or CDN | The actual cutover |
| 6 | Smoke-test top 20 URLs from a clean network | Don't trust your own cache; verify from outside |
| 7 | Submit new sitemap in Search Console | Tells Google to start re-crawling immediately |
| 8 | Use the Change of Address tool if the domain changed | Explicit signal to Google that the site moved |
| 9 | Confirm analytics is firing on the new site | Without GA you are flying blind for the next 30 days |
| 10 | Monitor server errors and Core Web Vitals for 4 hours | The window where edge issues surface |
If you do not have an in-house team that can run this checklist, our project support team handles cutovers as a fixed-fee engagement. We have run this playbook on more than fifty migrations and the steps are deliberately boring on purpose.
The first 30 days: what to monitor and when to panic (or not)
Even a perfectly executed migration produces ranking volatility for the first one to four weeks. Google needs time to recrawl the redirect map, follow the internal links on the new site, and consolidate signals on the new URLs. Knowing what is normal, and what is not, prevents teams from making panicked changes that actually hurt recovery.
Day 1 to 7. Expect a small dip in organic traffic, typically 5-15%. Search Console will start reporting crawl activity on the new URLs within hours and the redirect coverage report will populate within a few days. If you see a 50%+ drop on day one, something is wrong, almost always with redirects or robots.txt.
Day 7 to 21. The new URLs should be appearing in search results in place of the old ones. Click-through rate per query is the metric to watch most closely; if it drops sharply on a high-value query, the meta description for the new URL probably differs from the old one. The most common pattern: traffic dips, then partially recovers as Google catches up.
Day 21 to 30. By the end of the first month, organic traffic should be within 5% of pre-migration levels. If it is not, the migration left something on the table, usually a category of pages that was redirected incorrectly, or a piece of schema that did not survive the move.
If the numbers do not recover, do not start "optimizing" by changing on-page elements. That makes diagnosis harder. Investigate the migration itself first: re-check the redirect map, validate schema on the top 50 pages, audit hreflang. The fix is almost always to repair the migration, not to layer new SEO work on top of an unrepaired one. If you suspect something deeper is broken and the original team is gone, our project takeover service exists for exactly this scenario.
Frequently asked questions
How long does a website migration take, end to end?
A redesign on the same platform: 4-8 weeks. A replatform with URL changes: 6-12 weeks. A domain change: add 1-2 weeks for the redirect mapping and Search Console setup. The time-consuming part is rarely the build itself; it is the audit, the redirect mapping, and the QA. Teams that try to compress those phases pay for it after launch. Our website cost breakdown covers what these projects typically cost in 2026.
Will I lose rankings, even if the migration is done well?
Short-term, almost always yes, by a small margin. The first one to four weeks see normal volatility as Google reprocesses the site. A well-executed migration recovers fully, and in many cases ends up ranking better than before because the technical foundation is stronger. A poorly executed migration loses rankings and never fully recovers; we have audited sites that were still down 30%+ a year after a botched move.
Should I freeze new content during the migration?
Mostly yes. From the start of the development phase until two weeks after launch, avoid publishing new pages or restructuring existing ones. Every change you ship during the cutover window adds noise to your post-launch diagnostics. Time-sensitive content like blog posts can usually continue, but new templates, new sections, and major copy rewrites should wait.
What happens to my backlinks?
301 redirects pass the vast majority of link equity from the old URL to the new one. Modern Google does not penalize you for the redirect itself. The risk is when a backlink is pointing at a URL you forgot to redirect, in which case the link is wasted. This is why the audit phase looks at backlinks specifically, not just URLs with traffic.
Can I migrate the site myself?
If you have an in-house team that has done it before, yes. If you are running the redirect map manually in a spreadsheet for the first time, the cost of a mistake is almost always higher than the cost of hiring help. The agencies that get migration right are the ones that have run the same playbook twenty times. If you want a second opinion before committing, our post on 12 questions to ask a web agency includes the migration-specific ones to ask.
The bottom line
A website migration is the rare project where the goal is for nothing to change from your customers' perspective and for nothing to change from Google's perspective, even though almost everything has changed under the hood. The discipline that gets you there is unglamorous: audit thoroughly, map every URL, preserve on-page elements, validate schema, monitor relentlessly. None of it is exciting. All of it is the difference between a launch that lifts your business and a launch that costs you a quarter of organic revenue.
If you are planning a redesign, a replatform, or a domain change in 2026 and want a partner who has run this playbook before, get in touch. We will tell you up front whether the migration risk in your project is being underestimated, and what it takes to bring it down. If you are already mid-migration and the numbers look wrong, the same applies. Pricing for migration-focused engagements is on our pricing page, and the underlying capabilities are documented under web development, redesign, and design.