Every time a client says “we’re launching a new website next month,” a small part of me braces for impact. Not because new websites are bad — they’re usually overdue. But the migration itself is where traffic goes to die, and the same mistakes keep showing up regardless of budget, agency, or platform.
I’ve been involved in enough migrations at this point — as advisor, as the person doing the technical audit, sometimes as the person called in after the damage is done — to see the pattern clearly. Five mistakes account for the vast majority of post-launch traffic loss. All of them are preventable. None of them are surprising. And yet they keep happening, because the people building the new site and the people responsible for organic performance are rarely in the same room at the same time.
1. Changing URLs without redirects
This is the single most damaging mistake and the most common. A site has built up authority on a set of URLs over years. The new site launches with a different URL structure — different slugs, different directory hierarchy, sometimes a completely different domain — and nobody maps the old URLs to the new ones.
The result is instant. Every inbound link, every indexed page, every bookmarked URL returns a 404. Google doesn’t know where the content went. The authority those pages accumulated doesn’t transfer. It just evaporates.
The fix is a redirect map: every old URL mapped to its equivalent new URL with a 301 redirect. Not a blanket redirect of everything to the homepage — that’s almost as bad as no redirects at all. A one-to-one map. It’s tedious work. On a site with thousands of pages, it takes days. But it’s the single highest-ROI task in the entire migration.
When I audit a migration plan and there’s no redirect map, I tell the client to delay the launch until one exists. That’s not a suggestion. Without it, you’re voluntarily giving up years of accumulated search equity.
2. Launching with noindex and forgetting to remove it
This one’s the avoidable catastrophe. During development, the staging site has a <meta name="robots" content="noindex"> tag or a Disallow: / in robots.txt to keep search engines from indexing unfinished pages. Perfectly reasonable during development. Then the site launches and nobody removes it.
I’ve seen this happen on sites with six-figure monthly organic traffic. The entire site silently drops out of Google’s index over the course of a few weeks. By the time someone notices — usually because a client asks why leads dried up — the damage is deep. Re-indexing takes time. Rankings don’t come back to where they were. Some never recover fully.
The fix is a launch checklist with exactly one item in bold at the top: verify that noindex/disallow directives are removed on the production domain. Check the HTML source. Check robots.txt. Check the HTTP headers. Check them on launch day and check them again a week later. It takes five minutes and prevents a disaster.
3. Site speed regression
New sites tend to be slower than old sites. This sounds counterintuitive — the new design is modern, the code is fresh, the hosting is better. But modern designs come with heavier assets. New frameworks ship more JavaScript. Custom fonts add render-blocking requests. Hero images at retina resolution weigh five times what the old JPEG did.
The old site loaded in 1.8 seconds. The new site loads in 4.5 seconds. Nobody noticed during development because the dev team’s on fast connections and the staging server had no real traffic.
Google has been explicit about speed as a ranking factor. But even setting aside rankings, users leave. A site that takes four seconds to load loses a measurable percentage of visitors on every page load. Multiply that across thousands of sessions and the revenue impact is real.
Test the new site’s performance against the old site’s benchmarks before launch. Use the same tools, the same test locations, the same connection profiles. If the new site’s slower, fix it before you go live. After launch, speed problems compete with every other post-launch priority and rarely win.
4. Internal link rot
Content migration is never as clean as it looks in the project plan. Pages get restructured, merged, split, or dropped. The body content moves across, but the internal links inside that content — the links from one blog post to another, from a service page to a case study, from a FAQ answer to a product feature — break silently.
Nobody audits the internal links because the content “migrated successfully.” The pages are there. The text is correct. But hundreds of internal links now point to URLs that don’t exist anymore or have changed structure. The site’s internal link graph, which Google uses to understand page importance and topical relationships, is shredded.
Crawl the new site before launch. Run a full crawl and check every internal link. Flag every 404 and every redirect chain. Fix them in the content, not just in the redirect map. Internal links should point directly to the canonical destination, not through a redirect.
5. Removing content that was driving long-tail traffic
This is the “nobody reads that” trap. During the redesign, someone reviews the old site’s content and decides that certain pages are outdated, off-brand, or irrelevant. Old blog posts, niche product pages, detailed FAQ entries — they get cut from the migration scope. The new site launches clean and focused.
What nobody checked is whether those pages were generating organic traffic. A blog post from 2014 about a niche technical topic might get thirty visits a month. That sounds like nothing. But when you cut fifty such pages, you’ve lost fifteen hundred monthly visits from highly specific, often high-intent search queries. Those visitors knew exactly what they were looking for and your site had the answer. Now it doesn’t.
Before removing any page from the migration, check its organic traffic. If it brings in any meaningful visits, migrate it. If you genuinely need to remove it, redirect it to the closest relevant alternative. Content pruning is fine. Blind pruning is expensive.
The pre-migration checklist
Every migration should have a technical SEO audit before the new site goes live. Not after. Not “we’ll fix it post-launch.” Before.
The audit covers: redirect map completeness, robots and indexing directives, page speed benchmarks versus the old site, internal link integrity, content parity for traffic-driving pages, structured data migration, XML sitemap accuracy, and canonical tag configuration.
None of this is complicated. All of it is tedious. And that’s exactly why it gets skipped — it isn’t exciting work and it doesn’t show up in the design mockups or the feature demos. It shows up six weeks later, when the traffic graph drops off a cliff and everyone starts asking what happened.
After the launch
Even with a perfect pre-migration audit, expect some turbulence. Rankings fluctuate during any migration. Google needs to recrawl and reprocess the entire site. Some pages will settle in different positions than they held before.
The difference between a migration that recovers in four weeks and one that never recovers is whether the fundamentals were handled. Redirects, indexability, speed, internal links, content preservation — get those right and the turbulence is temporary. Miss any of them and you’re rebuilding from a weaker position.
If you’re about to migrate a site and your technical team hasn’t mentioned any of the five items above — ask them. That conversation is worth having before launch day, not after.