The number-one fear at any redesign kickoff is "will we lose our Google rankings?". The honest answer: only if the redesign is sloppy. A well-executed migration usually preserves or improves rankings because the new build is faster on Core Web Vitals than the old. A sloppy migration loses 30-60% of organic traffic inside a fortnight and the recovery takes months. This page is the full playbook we run on 50+ same-day rebuilds per year with zero net traffic loss.
Why most redesigns lose traffic
The pattern is almost always the same. A new agency takes a brief, designs a beautiful site, ships it on a Friday afternoon, and the URLs change because the new CMS uses a different slug structure. Old URL /services/emergency-plumber becomes /services/plumbing/emergency. No redirect map. Google's crawler returns to /services/emergency-plumber, gets a soft-404 because the CMS serves a generic "not found" page on a 200 status code, and inside three weeks the ranking is gone. The redesign was technically excellent. The transition was unprotected.
Step 1 — full URL crawl before you touch anything
Screaming Frog, full crawl of the existing site, export every URL, every status code, every canonical, every title, every H1, every meta description. Save the CSV. This is your baseline contract: any URL in this export must resolve to a meaningful destination after the launch. For a 400-page site this is a 30-minute crawl on the desktop licence; for a 4,000-page site allow 4-6 hours and a Memory mode database. The columns to capture: URL, status code, content-type, response time, word count, H1, meta title, meta description, canonical, robots meta, internal links inbound and outbound, image alt text count, structured data validator output.
Step 2 — Search Console export
Inside Google Search Console, navigate to Performance > Search results, set the date range to "last 16 months", filter to top 1,000 by clicks, export. Repeat for Pages. Build a third sheet that joins them: for each top query, the landing page Google currently serves. This is your protection checklist — every mapping must survive the launch. If query "[trade] [city] emergency" currently sends users to /trade/city-emergency, the redesign needs an equivalent landing page targeting the same intent. We have seen redesigns "consolidate" four city pages into one regional page and lose 40% of traffic overnight because the new page ranks for nothing the old four ranked for.
Step 3 — the 1:1 redirect map
Every old URL maps to exactly one new URL. No "let it 404 and Google will figure it out" — Google does not. 301 redirects (not 302), written into the host's redirects.json or .htaccess or Vercel rewrites file, tested with curl before launch. Building the map: open the URL CSV from step 1, add a "new URL" column, sort by inbound link count descending, map the top 100 by hand, map the next 900 using a SUBSTITUTE or REGEX rule, map the long tail using a default catch-all rule scoped to the directory. Test the whole map with a Bash script that curls every old URL and asserts the response is 301 with the expected Location header. We run that test in CI before any go-live; if a single redirect 404s, the deploy is blocked.
Step 4 — preserve schema entities
If the old site emitted Article, FAQPage, LocalBusiness, Product or any other schema entity with a stable @id, the new site must emit the same entity with the same @id at the same canonical URL. Google treats matching @id as continuity — the reviews, the aggregateRating, the awards, the brand mentions attached to the old entity transfer cleanly to the new. Change the @id and you start a new entity from scratch; the rich-results take 8-14 weeks to rebuild. The most common failure: the new site's schema uses a different sub-type (Restaurant vs FoodEstablishment, Electrician vs ProfessionalService). Even with matching @id, the sub-type change forces Google to re-evaluate the entity. Match the sub-type unless you have a clear reason to change.
Step 5 — keep the H1 and the first paragraph stable for week one
Even if the design is changing, the words have to stay close to the old version on day one. Google's crawler treats meaningful changes to H1 + first paragraph as a signal that the page topic has shifted. If you also redirect the URL and re-skin the design in the same week, you have given the crawler three simultaneous reasons to re-evaluate the page from scratch. Ship the new design with the old copy intact for week one. Let the crawler revisit. Confirm rankings are stable. Refresh the copy in week three (small edits) and week six (deeper rewrites). The traffic line stays flat instead of dipping and recovering.
Step 6 — launch on a Tuesday morning
Never on a Friday. If something breaks, you want a full week of working hours to fix it. The Tuesday morning launch runbook: T-7 days send the confirmation email with the runbook attached; T-1 day final reminder, request to pause email and ad pushes for 48 hours; T+0 deploy, DNS swap with low TTL pre-set, cache purge across CDN; T+5 minutes smoke test of the top 30 URLs; T+10 minutes submit fresh sitemap.xml; T+15 minutes URL-inspect 10 random old URLs in Search Console to confirm Google sees the 301; T+30 minutes monitor real-user errors via Sentry; T+60 minutes first PageSpeed run on three random URLs; T+90 minutes sign-off email to client. If anything is amber at T+30, hold and remediate before sign-off.
Step 7 — monitor for 30 days
Search Console "Pages" report, every day for two weeks, then twice a week for two more. Watch for "Discovered – currently not indexed" or "Crawled – currently not indexed" creeping up — both are early warning signs that the crawler is finding pages but choosing not to index them, which usually means a quality drop the new build has introduced. Beyond the Pages report, watch four lines: daily organic clicks, daily impressions split by branded vs non-branded, daily 404 count from the host log, and daily Core Web Vitals field data from CrUX. Healthy launch: clicks within 5% of baseline within 14 days, impressions matching within 7 days, 404 count near-zero, CWV improving.
What "no SEO loss" actually means
Specific success criteria. Within 14 days: organic clicks within 5% of pre-launch baseline. Within 30 days: within 2%. If you are still down 10% at day 30, something in the redirect map or schema is broken — investigate immediately. Branded queries (your business name) should recover within 7 days. Non-branded long-tail queries can take 30-60 days to fully stabilise but should not drop more than 10% at the trough.
The five highest-stakes mistakes we see in rescues
Pattern of failure we keep finding when called in to rescue a sloppy migration. (1) 302 redirects instead of 301s — temporary signal, no link-equity transfer. (2) Redirect chains: /old → /interim → /new — each hop discards authority. (3) Catch-all redirects pointing every old URL at the new homepage — soft-404 signal, rank vanishes. (4) Schema sub-type changes that should have been preserved. (5) Copy rewritten on launch day instead of held stable for week one. Each is individually recoverable; in combination they produce the 60% traffic drop we see most often.
When to engage professional migration help
Two scenarios where DIY migration risks more than the cost of a professional handover. First: you have more than 200 URLs, more than 50 of which receive monthly organic traffic. The redirect-map complexity scales nonlinearly past that volume and the cost of getting it wrong is materially larger than the cost of getting it right. Second: your site has industry-specific schema (legal, medical, financial, real-estate) that the migration needs to preserve precisely. Off-the-shelf migration tools handle BlogPosting and Organization well; they handle LegalService, Dentist, RealEstateListing and FinancialProduct poorly.