Redesigning your website is one of the highest-risk events in your SEO timeline. Done carelessly, it can erase months or years of ranking progress within days of launch — and traffic losses of 30–60% are not unusual when proper SEO migration protocols aren't followed. Done correctly, a redesign is an opportunity to significantly improve your position. The difference comes down to process.
Step One: Audit What You Have Before Touching Anything
Before a single design file is opened, you need a complete record of your current SEO state. This is your baseline — the thing you'll measure against to determine whether the redesign helped or hurt.
Run a full crawl of your existing site. Document every URL, its title tag, meta description, H1, canonical, and current Google ranking for its primary keyword. Export this to a spreadsheet. This list becomes your redirect map and your recovery reference if something goes wrong.
Pull your top 20 pages by organic traffic from Google Search Console. These pages are your priorities. Any URL in this list must either be preserved exactly or receive a permanent 301 redirect to its new equivalent — no exceptions.
Also document any pages that have earned backlinks. Use Google Search Console's "Links" report to find which URLs have the most external sites pointing to them. These URLs carry accumulated ranking authority that redirects partially preserve — losing them without redirects loses that authority permanently.
URL Structure: Change as Little as Possible
The single most common cause of redesign-related ranking drops is unnecessary URL changes. Developers and designers have a habit of "cleaning up" URL structures during a rebuild — consolidating folders, removing dates from blog slugs, changing /services/web-design/ to /web-design/. Each of these changes destroys the ranking equity accumulated at the old URL, even with a 301 redirect in place.
301 redirects preserve approximately 90% of ranking authority — but that 10% loss is real and compounds across many URLs. More importantly, redirects introduce a processing delay in Google's re-crawl and re-indexing cycle, during which your pages may temporarily disappear from results.
The rule: keep URLs identical unless there is a specific SEO reason to change them. If a URL currently ranks and the page is being rebuilt, that URL should remain exactly the same on the new site.
Building the Redirect Map — And Testing It Properly
Any URL that must change requires a 301 redirect from old to new. Redirect maps should be built before the new site goes live — not as an afterthought post-launch.
Format is simple: a spreadsheet with two columns, old URL and new URL. Every old URL that is being removed, renamed, or merged needs an entry. Don't forget:
- Blog posts that are being consolidated
- Category or tag pages being removed
- Old landing pages that were created for campaigns
- Any pages accessible at multiple URLs (www vs non-www, trailing slash vs no trailing slash)
Once the new site is on a staging environment, test every redirect before launch. An incorrectly configured redirect to a 404 page passes zero ranking authority. Tools like Screaming Frog can crawl a redirect map and verify each one resolves correctly.
Maintaining Technical SEO Through the Build
A rebuild is the easiest time to introduce technical SEO errors — and the hardest time to catch them, because everything is being changed simultaneously.
Check these explicitly before launch:
Canonical tags. Every page should have a self-referencing canonical. If the new CMS or framework generates canonicals dynamically, verify the output on staging is correct — especially for paginated pages, filtered views, and any URL that is accessible with and without a trailing slash.
Robots.txt. Staging environments are typically configured with Disallow: / to prevent Google from indexing work in progress. This configuration must not be deployed to production. It happens more often than developers admit.
XML sitemap. Regenerate the sitemap for the new site and verify it contains only indexable pages — no 301s, no 404s, no noindex pages. Submit the new sitemap to Google Search Console immediately after launch.
Page speed. The new design should not be slower than the old one. Run PageSpeed Insights on both environments before committing to launch. Our guide on Core Web Vitals in Next.js explains what to optimise if scores drop.
Post-Launch: The First 30 Days
The period immediately after launch is critical. Traffic fluctuations are normal — Google re-crawls and reindexes the new site over days to weeks. But certain signals tell you whether the migration is on track or whether action is needed.
Monitor Search Console daily for the first two weeks. You're watching for a spike in crawl errors (404s that shouldn't exist), a drop in indexed pages, or manual actions. Address 404 errors immediately — they indicate redirect gaps.
Track your top 20 organic pages weekly. Some ranking movement is expected. If a previously top-10 page drops to page three or beyond, check whether the page's URL, title, H1, and canonical are identical to the pre-launch version. An unintended change is usually the cause.
Don't make other changes simultaneously. The two to four weeks after launch are not the time to also restructure your information architecture, consolidate content, or test new title tag formulas. Isolate the migration so that any ranking changes can be attributed to the redesign specifically.
If you're planning a rebuild and want to make sure SEO is treated as a first-class concern from the start — not bolted on after the fact — see how we approach it at dricomm.com/our-services. You can also get a free audit of your current site before any work begins, to understand exactly what you'd be protecting.
Ready to grow your business online? Get your free audit →