The short answer
Migrations lose rankings when URLs change without redirects, when content silently doesn't carry over, or when technical signals like schema and robots rules get dropped in the rebuild. Build a complete redirect map from a crawl of the old site before launch, carry the content and markup across intact, and expect a short dip that recovers rather than a permanent loss.
Deciding whether to rebuild is one question. Moving your site without losing the rankings you already have is a different one, and it's the one that goes wrong most often. A redesign or platform move is the most common way a firm accidentally deletes its own search visibility, not because the new site is worse, but because the old URLs vanished and nobody told search engines where they went. The design is fine. The mechanics were skipped.
This is the mechanics side: why migrations lose rankings, how to build the redirect map that prevents it, what to check before launch, and how to read the dip afterward without panicking or overreacting.
Why do migrations lose rankings in the first place?
Because search rankings attach to specific URLs, not to your brand in the abstract. Every page that ranks, every practice-area page, every blog post, every attorney bio, earns that position at a particular address. When you migrate and that address changes without a redirect, the ranking has nowhere to go. The engine had authority pointed at /dui-defense/; the new site calls it /practice-areas/criminal/dui/ and never says the two are the same page. To the engine, the old page is gone and the new one is a stranger starting from zero.
Three things cause almost all of the damage. URLs change and nobody maps the old ones to the new ones. Redirects get missed, so old links, including the ones AI engines and directories already know, land on 404s. And pages quietly get dropped in the redesign, a thin practice-area page or an old but still-ranking post, so the content that earned the ranking no longer exists anywhere. Each of these is preventable. None of them prevents itself.
How do you build the redirect map?
Start by inventorying every URL the old site currently has, before you touch anything. Crawl the live site and export the full list. Pull the pages Search Console shows as getting impressions and clicks, so you know which URLs actually carry ranking weight. Add anything that shows up in your analytics as a landing page. The goal is one complete list of every address that exists and matters, because you can't redirect what you didn't know was there.
Then map old to new, one row per URL: the old address, and the single most relevant page on the new site. A blog post maps to the same post at its new address. A DUI page maps to the new DUI page, not to a generic "practice areas" index, because a redirect to a vaguely related page tells the engine the specific content is gone. Where a page truly has no successor, that's a decision to make deliberately, not a gap to leave blank. Every old URL that carried value needs a deliberate destination.
Use 301 redirects, not 302. A 301 is permanent and tells engines to move the ranking signals to the new URL; a 302 is temporary and signals that the old URL is coming back, so the authority tends to stay stranded on a page that no longer exists. This one setting, permanent versus temporary, is a common quiet cause of a migration that "did everything right" and still sank. If the move is permanent, say so with a 301.
Can you keep the old URLs instead of remapping them?
Where you can, yes, and it's the safest option. The redirect that never has to fire is the one where the URL didn't change. If your practice-area pages already live at clean, sensible addresses, keep those exact paths on the new site. Preserving /car-accidents/ as /car-accidents/ means that page keeps its authority with nothing to break. Reserve URL changes for pages whose current addresses are genuinely bad, and change them on purpose, with a redirect, not as an accident of a new template's default structure.
The trap is a platform or theme that imposes its own URL pattern and silently rewrites every address in the process. That's exactly the kind of default that turns a clean redesign into a ranking wipe. Decide your URL structure first, keep the good addresses stable, and make the new platform match your plan rather than the other way around.
What else has to carry over besides the URLs?
The on-page signals that made each page rank. The redirect gets a visitor to the right address; it doesn't guarantee the new page is as strong as the old one. Carry over the real content, not a trimmed marketing rewrite that drops half the text a page ranked for. Keep the title tags and headings that were working. Move the schema, and confirm it's valid on the new page, because schema is hygiene and rich-result eligibility, not a magic switch, and a redesign is a common place for it to get dropped or broken. Same page, same address, same signals is the goal.
Internal links need updating too. When your own navigation, footer, and body links still point at old URLs, every internal click becomes a redirect hop, and any link you missed in the redirect map surfaces as an internal 404. Update internal links to point directly at the new addresses so the site links to itself cleanly and doesn't lean on redirects to hold together.
What about Google Business Profile and citations?
Point them at the right place, because they're outside your site and won't update themselves. Your Google Business Profile website link, your directory and citation listings, and anything else pointing at a specific old URL will keep sending people and engines to that address after launch. If those URLs 301-redirect, the traffic still lands, which is one more reason the redirect map has to be complete. But update the important ones directly anyway, starting with the GBP website field, so your most valuable references point straight at the live page instead of relying on a redirect chain.
This matters more for local visibility than firms expect. The map pack and local results lean on consistent signals, and a GBP link pointing at a dead or redirected URL is a signal worth fixing on day one. Don't let the profile that drives your local calls quietly point at a page that moved.
What's the pre-launch checklist?
Run through this before the new site goes live, not after:
- Crawl the old site. Export the complete URL list and confirm every ranking page from Search Console is on it.
- Stage the redirects. Have the full old-to-new 301 map built and ready to deploy the moment the new site launches, so there's no window where old URLs 404.
- Check canonicals. Each new page should canonical to itself, not to a staging domain or an old URL left in by the template.
- Kill the staging noindex. Staging sites are usually set to noindex or blocked in robots.txt. Confirm that block is removed on the live site, because a noindex left on at launch is one of the fastest ways to disappear from search entirely.
- Robots.txt allows the right pages. Make sure it isn't blocking pages you need indexed or the crawlers you want reading the site.
- Update the XML sitemap. Generate a fresh sitemap of the new URLs and remove the old ones.
- Resubmit in Search Console. Submit the new sitemap so engines discover the new structure quickly instead of waiting to stumble on it.
The noindex line deserves its own emphasis. More clean migrations have been sunk by a staging noindex left switched on than by any redirect mistake, because everything looks perfect and the site simply drops out of the index a few days later. Check it, then check it again after launch.
How do you read the dip after launch?
Expect some volatility and don't overreact to it. Even a well-executed migration can see rankings wobble while engines recrawl the new structure, re-process the redirects, and re-associate authority with the new URLs. Some movement in either direction in the days after launch is normal and doesn't mean something broke. The mistake is treating ordinary settling as an emergency and making rushed changes that create new problems on top of the migration.
Watch the right signals instead of refreshing rankings hourly. In Search Console, check the coverage and indexing report for a spike in errors or a wave of pages dropping out, and check that your top pages are still indexed at their new addresses. Watch for 404s climbing, which points at a redirect you missed, and for pages you expected to move showing up as excluded. Those are real signals worth acting on. General rank jitter usually isn't. As a caution, no honest process guarantees a specific outcome or timeline, so anyone promising an exact recovery window is selling certainty that doesn't exist.
If the dip is genuine, it almost always traces back to something on the checklist: a missed redirect, a noindex left on, a page that got dropped, schema that broke, or a 302 where a 301 belonged. Work the list, not your nerves. A migration that inventoried its URLs, mapped every one to a real destination, kept the good addresses stable, and cleared the checklist before launch is the kind that settles rather than sinks. This is also why the decision to move at all is worth thinking through first, covered in redesign or patch, and why owning your site and being able to export it, covered in who owns your law firm website, makes a clean migration possible in the first place. The build itself, done with the redirects and signals handled, is our web design service. Before you move anything, run the free audit so you know exactly where your current visibility lives and what to protect.
Questions we get about this
-
Why do website migrations lose rankings?
Because the new site breaks the connection between a URL and the history attached to it. Changed URLs without redirects orphan every link and signal that page had accumulated; content that doesn't carry over fully means the page no longer earns its position; and dropped schema, robots rules, or canonical tags remove things engines were relying on. None of these announce themselves. The loss is almost always self-inflicted and almost always preventable with a checklist.
-
How do you build a redirect map for a site migration?
Crawl the old site first so you have every live URL, not just the ones in the menu, then map each to its closest equivalent on the new site. Redirect one-to-one wherever a real equivalent exists, and only send a page to a category or the homepage when nothing better exists — bulk redirects to the homepage are treated as soft 404s and lose the value anyway. Include old URLs that already redirect, so chains resolve. Test the whole map before launch rather than after.
-
What else has to carry over besides the URLs?
The content in full, the page titles and meta descriptions, the structured data, the canonical tags, the image alt text, the internal links, and the robots and sitemap configuration. Analytics and Search Console properties need updating too, or you'll be blind exactly when you need to watch. The most commonly dropped item is schema, because it's invisible in a page comparison. Check the rendered new pages rather than assuming the build carried everything.
-
How long should a post-migration dip last?
A few weeks is normal as engines recrawl and reassign signals; a decline still deepening after a month or two is a problem rather than a settling period. Watch indexing coverage and the ranking of your most valuable pages specifically, not just total traffic, since an average can hide one important page falling out. If the dip isn't recovering, start with redirects and indexing rather than with content. Resist making large changes during the dip — you'll lose the ability to tell what caused what.
