Picture a site redesign that is already built, sitting on a staging server, ready to go live. Good work, genuinely. Cleaner layout, faster pages, better copy. But nobody has mapped the old URLs to the new ones. Nobody has checked which pages are actually bringing in traffic. Launched as it stands, it could quietly wipe out most of the site's organic visibility.
This happens more often than it should. A rebrand, a platform change, a new developer, a "let's just move to WordPress" decision made in a meeting where nobody thought about search rankings at all. The new site looks better. Three weeks later, the phone has stopped ringing and nobody can explain why.
Why Rankings Disappear During a Migration
Google doesn't rank a domain. It ranks specific pages, based on their content, their links, their history, and their URL. When you migrate a website, whether that means a new design, a new platform, or a new domain entirely, you're often changing the very things Google was using to identify and trust those pages.
Change a URL without redirecting it and the old page returns a 404. Any ranking, any backlink, any bit of accumulated trust tied to that page is gone. Do that across fifty or a hundred pages and you've effectively asked Google to start evaluating your site from zero.
Redesigns also tend to strip things out without anyone noticing. Alt text gets lost. Heading structure changes. Internal links that pointed to old URLs now go nowhere. Page speed sometimes gets worse, not better, because the new theme is heavier than the old one. None of this is dramatic on its own. Together, it adds up to a site that looks nicer and performs worse.
What Actually Needs to Happen Before Launch
The work that protects rankings happens before the new site goes live, not after.
Start with a full inventory of the existing site. Every indexed URL, along with whatever traffic and ranking data is available for it. This is the map you're working from. If you don't know what you have, you can't know what you're about to lose.
Every one of those URLs needs a destination on the new site, and a 301 redirect connecting the two. Not a redirect to the homepage as a catch-all, which is common and lazy, but a redirect to the actual equivalent page. If a service page moves from /services/plumbing to /plumbing-services, that specific redirect needs to exist. If a page is genuinely being retired because the content no longer applies, that's a decision to make deliberately, not a side effect of nobody checking.
Content should be reviewed for what made it useful in the first place. If a page was ranking because of a specific paragraph, a specific set of headings, or specific internal links pointing to it, a full rewrite that discards all of that is starting the ranking process over, whether anyone intended that or not.
Technical basics need checking too:
- Title tags and meta descriptions carried over or improved, not left blank on launch
- XML sitemap regenerated and submitted the day the new site goes live
- Robots.txt checked to make sure the new site isn't accidentally blocking search engines, which happens more than people admit
- Structured data (schema markup) rebuilt if the old site had it
The Part Everyone Forgets: After Launch
Migrating without loss isn't just a pre launch checklist. The days immediately after matter just as much.
Once the new site is live, submit the new sitemap in Google Search Console and keep an eye on the coverage reports. This tells you fairly quickly if pages are being dropped from the index or hitting errors. Rankings often dip briefly during a migration even when everything is done correctly. Google needs time to recrawl and re-evaluate the new URLs. What you're watching for is whether that dip recovers within a few weeks or turns into something permanent, which usually means a redirect or technical issue was missed.
Backlinks need attention as well. If other sites are linking to URLs that no longer exist, those links are only worth something if the redirect chain is solid. Reaching out to update a handful of high value backlinks directly, rather than relying entirely on redirects, is worth the effort for anything that's sending real referral traffic.
Platform Changes Add Another Layer
Moving from Wix to WordPress, or from a custom build to Shopify, or off a legacy CMS entirely, introduces problems beyond URL structure. Different platforms handle canonical tags, pagination, and even basic HTML output differently. A new platform can generate duplicate versions of every page, one with a trailing slash and one without, splitting ranking signals between two URLs that Google sees as separate pages. It's a small technical detail with a real cost, and it's the kind of thing that only surfaces if someone is actually checking the rendered HTML, not just the design.
Domain Changes Are Their Own Project
Changing domains entirely, say from a .ca to a .com, or rebranding the business name, is the highest risk version of this. Google treats a domain change as a significant event and it can take months to fully consolidate authority onto the new domain, even with a clean migration. This isn't something to do casually or as an afterthought to a rebrand. It needs its own timeline and its own monitoring plan, separate from the general redesign work.
We also resist the urge to change everything at once. A new domain, a new design and a new content strategy launched simultaneously makes it almost impossible to diagnose a problem if one shows up. Where a client's situation allows it, we prefer to separate structural changes from content changes, so that if rankings dip, we know which variable to look at first.
What This Actually Looks Like for Us
When we take on a migration at Redenn, the SEO mapping happens before a single line of new design gets approved for launch. We pull the existing site's full URL and traffic picture, build the redirect map alongside the new site structure, and treat launch day as the start of a monitoring period, not the end of the project. It's less exciting than the redesign itself, and it's the part that decides whether the redesign was worth doing at all.
If you're planning a redesign, a platform move, or a rebrand and you're not sure what the migration plan actually looks like, it's worth a conversation before anything gets built. Reach out through /contact or start the conversation at /start.
