SEO Migration Plan: Redesign Without Losing Your Google Rankings

A business redesigned their website. New platform, new design system, responsive templates, faster load times — everything the brief asked for. Within two weeks of launch, their top ten commercial queries dropped off page one. Organic traffic fell by more than half. Leads from search dried up. The redesign that was supposed to modernise the brand had, in practical terms, made the business invisible on Google.

The cause wasn't the redesign itself. The site was technically superior to what it replaced. The cause was 200-plus URLs that changed when the new site went live — and not a single redirect mapping the old addresses to the new ones. Every backlink pointing to the old site now hit a 404. Every indexed page Google knew about returned a dead end. Eight months of recovery work followed: building redirect maps after the fact, resubmitting sitemaps, waiting for Google to recrawl and re-evaluate pages it had already trusted.

That outcome was entirely avoidable. An SEO migration plan — built before the first wireframe is approved — ensures that every URL, every backlink, every piece of ranking equity transfers cleanly from old site to new. At EB Pearls™, we treat migration planning as a non-negotiable phase in every redesign project, because rankings lost through negligence take months to recover, while rankings preserved through planning are never lost in the first place.

Why Redesigns Kill Rankings

A website redesign changes things Google cares about. URLs change. Page titles change. Internal link structures change. Content gets consolidated, split, or rewritten. Heading hierarchies shift. Canonical tags may point to new locations — or may be missing entirely.

Google doesn't know you've redesigned. It knows that the URLs it indexed now return errors, that the pages it ranked have different content, and that the link signals it trusted point to addresses that no longer exist. From Google's perspective, the old site has been deleted and a new, unproven site has appeared in its place.

The ranking signals your old site accumulated — backlinks, crawl history, user engagement data, topical authority — are tied to specific URLs. When those URLs disappear without redirects, the signals disappear with them. Google must then discover your new URLs, crawl them, evaluate them against competitors, and decide whether they deserve the positions your old pages held. That process takes months, not days.

This is why a website design project that ignores migration planning is fundamentally incomplete. The design can be excellent, the code can be clean, the performance can be superior — and none of it matters if Google can't find the pages or connect them to the authority the old site earned.

The most dangerous misconception is that Google will "figure it out." It won't. Without explicit 301 redirects telling Google that old-url-A is now new-url-B, the search engine treats them as entirely separate pages. Your old page loses its rankings. Your new page starts from zero.

The Anatomy of an SEO Migration Plan

An SEO migration plan is a structured document that maps every element of your current site's search equity to its equivalent on the new site. It's created before development begins, executed during launch, and monitored for at least 90 days after go-live. The plan covers five core components.

The Complete URL Audit

Every indexed URL on your current site must be catalogued. Not just the pages in your navigation — every URL that Google has indexed, including blog posts, resource pages, PDF links, image URLs, and parameter-based variations. Use Google Search Console's index coverage report and a full site crawl to build this inventory. If Google knows about it, it needs to be in your audit.

For each URL, record the current ranking positions, organic traffic volume, and inbound backlink count. This data determines priority. A URL that ranks on page one for a commercial query and has 40 referring domains needs a perfect redirect. A URL that receives no traffic and has no backlinks may not need one at all.

The 301 Redirect Map

This is the centrepiece of the migration plan. The 301 redirect map is a one-to-one mapping of every old URL to its new equivalent. Where the new site has an equivalent page, the mapping is straightforward. Where pages have been consolidated, the redirect points to the most relevant new page. Where pages have been removed entirely, the redirect points to the closest topical match — never to the homepage as a catch-all.

The redirect map should be built as a spreadsheet with columns for: old URL, new URL, HTTP status code (301 for permanent redirects), current ranking keywords, monthly organic traffic, and inbound backlink count. This format makes it auditable and testable before launch.

Redirect chains — where URL A redirects to URL B, which redirects to URL C — must be avoided. Each hop dilutes link equity and slows crawling. Every old URL should resolve to its final destination in a single redirect. Google's own documentation on site moves confirms that clean 301 redirects are the primary mechanism for transferring ranking signals.

Metadata Transfer

Page titles, meta descriptions, heading structures, and structured data markup carry SEO value. When new pages are built, they should inherit the metadata from the pages they replace — not start fresh with new copy that hasn't been tested in search results.

This doesn't mean copying metadata verbatim. If the redesign includes a rebrand or messaging shift, titles and descriptions should reflect that. But the primary keyword targeting should carry over. A page that ranked for "custom ecommerce development" shouldn't launch with a title that no longer includes that phrase.

Open Graph tags, Twitter cards, and schema markup also need migration. If your old pages had FAQ schema, product schema, or article structured data, the new pages should have equivalent or improved markup.

Internal Link Architecture

Your old site's internal linking structure distributed authority across pages. The new site's structure will do the same — but differently. Every internal link on the old site that pointed to a now-changed URL needs to be updated to point to the new URL directly, not rely on the redirect.

This is the step most migration plans skip. Redirects handle external links and bookmarks, but internal links should point to final URLs from day one. Relying on redirects for internal navigation wastes crawl budget and creates unnecessary server load.

Map your old site's internal link structure before the redesign. Identify which pages received the most internal links (these are your highest-authority pages in Google's eyes) and ensure the new architecture maintains or improves their internal link equity. The concept-to-launch process should account for this mapping as part of information architecture planning.

Staging Environment Validation

Before the new site goes live, every component of the migration plan must be tested in a staging environment. Crawl the staging site and verify that every redirect fires correctly, that no redirect chains exist, that canonical tags point to the right URLs, that the XML sitemap includes all new URLs and excludes old ones, and that robots.txt doesn't accidentally block critical pages.

This validation step catches errors that would otherwise go live. A single misconfigured redirect rule — say, a regex pattern that matches too broadly — can redirect hundreds of pages to the wrong destination. Finding that in staging costs minutes. Finding it in production, after Google has crawled the errors, costs months.

How a Staged Cutover Preserves Rankings

A staged cutover is the safest approach to launching a redesigned site. Instead of switching the entire site in one deployment, you migrate in phases — typically by section or subdomain — monitoring each phase before proceeding to the next.

Phase one: migrate low-risk sections first. Start with pages that have minimal organic traffic and few backlinks. This lets you validate that redirects, metadata, and canonical tags are working correctly in production without risking your highest-value pages.

Phase two: migrate high-value pages. Once the redirect infrastructure is validated, move your top-ranking pages. Monitor Search Console daily for crawl errors, indexing issues, and ranking changes. If problems appear, you can roll back a single section rather than the entire site.

Phase three: monitor and adjust for 90 days. After the full migration, keep the monitoring cadence high. Check Search Console for 404 errors, soft 404s, redirect errors, and indexing anomalies. Track rankings for your top commercial queries daily for the first two weeks, then weekly for the remaining period. Search Engine Journal's migration checklist provides a useful reference for the monitoring cadence and specific metrics to track.

The 90-day window matters because Google doesn't recrawl your entire site overnight. Some pages are crawled daily, others weekly, others monthly. It can take up to three months for Google to fully process a large site migration. Rankings may fluctuate during this period even with perfect redirects — that's normal. What you're watching for is sustained drops that indicate a redirect or canonical issue.

The Migration That Preserved Every Ranking

Contrast the opening scenario with how a properly planned migration works. A business with a mature website — strong rankings for commercial queries, an established backlink profile, and consistent organic traffic — needed a complete platform migration and redesign.

Before any design work started, the migration plan was built. A full URL audit identified every indexed page. The 301 redirect map was constructed, mapping each old URL to its new equivalent. Metadata was catalogued and carried forward. The internal link architecture was redesigned to match the new site structure while preserving authority distribution.

The staged cutover moved the site section by section over two weeks. Search Console was monitored daily. Crawl errors were caught and corrected within hours, not weeks. When the migration was complete, organic traffic held steady. Rankings for the top commercial queries showed no measurable decline. The backlink profile transferred cleanly — referring domains that pointed to old URLs now resolved to new pages without broken links.

No recovery period. No lost leads. No panicked calls to an SEO agency three months post-launch. The difference between this outcome and the opening scenario wasn't technical skill or budget — it was planning. The project delivery framework included migration as a defined phase, not an afterthought.

At EB Pearls, we've delivered over 900 projects across software development and web, and the pattern is consistent: migration plans built before development prevent the ranking drops that migration plans built after launch try to fix.

Common Migration Failures and How to Prevent Them

Redirecting everything to the homepage. When teams don't have time to build a proper redirect map, they default to redirecting all old URLs to the homepage. Google treats this as a soft 404 — the redirect fires, but the destination isn't relevant to the original page's content. Rankings are lost just as surely as if no redirect existed.

Forgetting non-HTML assets. PDFs, images, and downloadable files accumulate backlinks and search traffic. If these assets move to new URLs during the migration, they need redirects too. A PDF that ranks in Google's search results for a specific query will lose that position if its URL changes without a redirect.

Removing the redirect map too early. Redirects should remain in place permanently, or at minimum for 12 months. Removing them after a few weeks — on the assumption that Google has "caught up" — can cause previously recovered rankings to drop again as Google re-encounters the old URLs through backlinks and cached references.

Ignoring Search Console property verification. If your domain changes (e.g., from www to non-www, or from HTTP to HTTPS), you need to verify the new property in Google Search Console and use the Change of Address tool. Without this step, Google's migration processing is slower and less reliable.

Not testing redirects under load. A redirect map that works in a browser test may fail under production traffic if the server can't handle the volume of redirect processing. Test redirect performance in the staging environment with realistic traffic loads, especially for sites with thousands of redirected URLs. DevOps practices that include load testing as part of deployment validation catch these issues before they affect real users.

What to Do Next

If you're planning a website redesign, the SEO migration plan should be the first deliverable — before wireframes, before design, before development. Start by exporting your current URL inventory from Google Search Console and running a full site crawl with a tool like Screaming Frog. That inventory becomes the foundation of your redirect map.

If you've already launched a redesign without a migration plan and your rankings have dropped, the recovery path is the same work done in reverse: audit the damage, build the redirect map, implement the redirects, resubmit your sitemap, and wait. The work is identical — it just costs months of lost traffic that proper planning would have prevented.

When you're ready to redesign without risking your rankings, talk to our team about a website project that includes migration planning from day one. We'll audit your current search equity and build the migration plan before the first wireframe is approved.

Frequently Asked Questions