I went looking for a specific window product earlier this week. It belongs to a national window brand most people in the home products space would recognize. The brand recently rolled out a beautiful new website under a new corporate identity. Looks great on the surface.
Here's what I actually found.
The first organic listing in Google for the product I searched is a PDF brochure from a few months ago, hosted on the brand's old WordPress upload directory. I clicked it. 404. The new site doesn't recognize that URL. Instead of redirecting me to the same brochure on the new site, or to the relevant product page, it dropped me on a "Page not found" screen with a homepage link.
That's the first impression a new visitor gets. A broken link, on what's supposed to be the brand's most authoritative result.
If I didn't already know the company had been rebranded, I'd assume the product was discontinued, the company went under, or I'd landed on the wrong site entirely. None of those is the answer the brand wants.
This is what site migrations cost when they're done badly. And it happens constantly, especially when a redesign and a rebrand land at the same time.
What does a site migration actually mean?
A site migration is any major change to a website that affects how search engines find, crawl, or trust your URLs.
That includes:
- Moving to a new domain
- Restructuring your URL paths (changing /services/seo/ to /what-we-do/seo/, for example)
- Switching content management systems
- Rebranding with a new domain or new URL structure
- Consolidating multiple sites into one
- Switching between HTTP and HTTPS, or www and non-www
- A "full redesign" that changes URLs even if the domain stays the same
The key word is URLs. If your URLs are changing, you're doing a migration, even if your team is calling it a redesign.
This is where most of the trouble starts. Teams plan for the design work, the content work, and the launch announcement. Nobody plans for the URL change itself.
Why most site migrations cost businesses search rankings
There's rarely a single reason migrations go wrong. It's usually four or five small failures that compound, and the brand doesn't notice for weeks until organic traffic is down.
When a brand calls me after a bad migration, the conversation almost always starts the same way: "Our organic traffic dropped and we don't know why." By the time we work through it, the answer is usually one or more of the failures below.
These are the ones I see most often, roughly in the order they show up.
1. No redirect map, or an incomplete one
Every old URL needs to redirect to the most relevant new URL. That sounds obvious. It almost never happens completely.
Teams will redirect the main pages (home, about, contact, top services) and miss everything else. Old blog posts. PDF downloads. Image files. Old landing pages from a campaign three years ago that still rank for valuable terms. Sub-pages of category pages.
If those URLs aren't mapped, anyone who clicks them, including Google, hits a 404. And 404s tell Google "this content is gone." Over time, the rankings those URLs earned go away too.
The window brand example earlier? That was a PDF on an old upload path. Nobody mapped the wp-content uploads folder. So every PDF ever indexed by Google now returns a 404.
I see three versions of this failure regularly. Sometimes there's no redirect map at all, which is at least obvious. More often, the map covers the top-level pages but leaves PDFs, blog posts, and old assets behind. The partial version does more damage because nobody notices it until rankings have already started slipping.
Then there's the laziest version, where every old URL redirects straight to the homepage. That isn't a redirect strategy. It tells Google those old pages don't exist anywhere specific, it dilutes the authority of the homepage, and it leaves the user staring at a generic page instead of the product or blog post they were trying to reach. A 410 "gone" status would be more honest. A blanket homepage redirect is just misleading.
2. The crawl baseline was never captured
Before the migration, someone should crawl the old site in full and save the result. Every URL, title tag, meta description, internal link, and existing redirect, captured in one place.
Without that snapshot, you have no way to know what was on the old site to begin with. Pages disappear and nobody notices, because nobody can prove they were ever there.
This is the failure that turns "our organic traffic dropped and we don't know why" into a multi-week investigation. With a baseline, the answer takes hours. Without one, it can take months, and the recovery starts from a much weaker position.
3. Internal links still point to old URLs
Even with redirects in place, internal links that still point to old URLs force an extra hop on every click. That dilutes link equity and tells Google you're not entirely sure which URL is the real one. The redirects are doing work they shouldn't have to.
The right move is to update the internal links to point directly to the new URLs. Most teams skip this step because the redirects "kind of work."
4. The XML sitemap still lists the old URLs
If the sitemap submitted to Google still references old URLs, Google keeps trying to crawl them, finds redirects or 404s, and slows down its discovery of the new site. The sitemap should reflect the new URL structure on day one of the migration, not weeks later.
5. The new site went live with staging settings still active
This one is more common than people want to admit. The staging environment had noindex tags or a robots.txt blocking crawlers, sometimes both. When the site went live, nobody removed them. The new site sits there for weeks, completely invisible to Google, while the team wonders why the migration "killed" their rankings.
The other version of this is when the staging URL itself ends up in production. The live site is now sitting at staging.companyname.com or companyname-staging.netlify.app instead of the actual domain. Google indexes the wrong URL, or it indexes both and you've created a duplicate-content problem on top of the migration.
Both versions are catchable in the first hour after launch if anyone is looking. Most teams aren't.
6. Search Console and Analytics weren't reconnected
When the domain or property changes, your existing Search Console and Analytics setups don't follow automatically. Someone has to verify the new property, set up the right tracking on the new site, and link the two so historical data is preserved.
If this gets skipped, you lose visibility into what's happening at exactly the moment you most need it. Rankings, clicks, impressions, and traffic data all go dark for the new site for weeks while you scramble to reconnect.
7. Schema markup didn't carry over
If the old site had structured data on key pages (FAQ, product, organization, breadcrumbs), and the new site doesn't, the rich results those pages earned in Google can disappear within a few weeks.
This one is a quiet loss. Nothing breaks. There's no bug report. You just notice fewer clicks in Search Console one month, then again the next month, because your listings stopped getting the visual treatment that used to set them apart.
For more on the schema side of this, see Why Adding Schema Shouldn't Be a Dev Project Every Time.
The cost goes beyond rankings
Most migration conversations stop at the rankings story. That's the obvious cost. It's also usually not the worst one.
The bigger cost is brand trust. The window brand example isn't really a ranking issue at all. It's a credibility one. A potential customer sees a 404 on what looks like the brand's official content and walks away with no idea what happened, just a vague sense that something about the brand isn't quite right.
For brands that work through dealers, partners, distributors, or referral networks, the cost compounds. Those partners have years of links pointing to the brand's old URLs. They use those links in their own marketing. When the links break, the partner's marketing breaks too. Now there's a downstream trust problem on top of the original migration problem.
I see this most often with B2B brands that have years of content built up (documentation, technical resources, case studies, white papers) and with manufacturers whose distributors and channel partners depend on stable URLs to do their own marketing. The migration team rarely thinks about anyone outside the parent company. The damage shows up everywhere else.
A migration touches three things at once: search rankings, brand trust, and the partner ecosystem that depends on your URLs. Treat it as a redesign and the cost will land in all three, just not until weeks after launch.
How to migrate a website without losing your search rankings
Google publishes official guidance for site moves with URL changes, and it's worth reading. What follows is the working version of that guidance, with the practical pieces that consistently catch teams out in real client work.
Plan and capture before anything moves
- Crawl the old site completely. Save the crawl. Every URL, title, meta description, and existing redirect.
- Build a redirect map. Every old URL needs a destination, including PDFs, image paths, and old landing pages.
- Decide what's intentionally not migrating, and document those decisions. Sometimes a 410 "gone" status is the right call.
- Confirm schema markup is carrying over to the new pages.
- Plan how Search Console and Analytics will be reconfigured on day one.
Land the move cleanly
- Push redirects live before the new site goes public, or at the same moment.
- Submit the new XML sitemap to Search Console.
- Verify the new property in Search Console.
- Confirm Analytics is collecting data on the new site.
Monitor and fix what only shows up after launch
- Crawl the new site and validate every redirect works (no 404s, no chains of redirects).
- Monitor Search Console for indexing errors, manual actions, and crawl anomalies.
- Watch for ranking drops on the highest-value pages. If a key page drops, find out why fast.
- Update internal links so they point to new URLs directly, not to redirects.
- Track 404s in your server logs and add redirects as new ones are discovered.
That's the simplified version. Larger or more complex sites need a longer list, but these steps catch most of what goes wrong.
What to ask your dev team or agency before a migration
If you're hiring someone to handle a redesign or rebrand, these are the questions worth asking early.
Someone owns this end-to-end, or it falls between roles and never gets done.
If the answer is anything other than "a complete crawl, saved as a working file," that's a gap.
Rich results and AI visibility both depend on this carrying over cleanly.
You need to know who is verifying the new property and on what date.
Most damage shows up in weeks two through six. The plan needs to cover that window.
If your dev team or agency can't answer these clearly, the migration is at risk. Not because they're bad at their job, but because they're probably scoped to deliver a website, not protect search rankings. Those aren't the same job.
This is one of the biggest gaps I see in agency work. Most web teams are excellent at design and build. Very few are scoped to think about what happens to search visibility when the new site replaces the old one. Search rankings rarely make it onto the project brief.
Frequently asked questions
It depends on how much was lost and how quickly it's caught. If the redirect mapping is fixed within a week or two of launch, recovery can be quick. If a brand discovers the problem six months later, recovery takes much longer because Google has had time to deindex pages and rebuild its understanding of the site.
Yes. Adding a 301 after launch is much better than leaving the 404 in place. Google will eventually pick up the redirect and pass most of the old URL's authority to the new page. The earlier you do this, the better the recovery.
No. A well-planned migration can hold rankings steady or even improve them. The risk comes from skipped steps, not from the migration itself.
Those URLs may not need a 1:1 redirect. The right move depends on the topic, the traffic volume, and whether there's a logical new home for that traffic. Sometimes a 410 "gone" status is the cleanest answer. Other times a redirect to a related category page works better. There's no single rule.
Not right away. Confirm where the redirects are actually being served from before you touch the old server. If the redirects live on the old server and you shut it down, every redirect breaks at the same moment. The minimum I recommend is keeping the redirect setup active for 12 months after launch. Longer is better, especially for URLs with backlinks, rankings, referral traffic, or campaign links that may surface in old emails or partner sites years later.
Yes. Use Search Console's Change of Address tool if you're moving to a new domain, and submit your new XML sitemap as soon as the new site is live.