How to redesign a UK website without losing Google rankings
A redirect mapping checklist, schema-preservation techniques, and the 30-day metric we watch to confirm zero loss.
The number-one fear at a redesign kickoff: "will we lose our Google rankings?" The honest answer is "only if the redesign is sloppy." Here's the protocol we use to ship 50+ same-day redesigns a year with zero 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. We have rescued sites from this position; rescue takes longer than building it properly the first time.
Step 1: full URL crawl, before you touch anything
Screaming Frog, full crawl, export every URL, every status code, every canonical, every title. Save the CSV. This is your baseline.
What to capture in the crawl
Beyond the obvious URL list: HTTP status code for every page, content-type, response time (so you can spot orphaned bloat), word count, H1, meta title, meta description, canonical tag value, robots meta value, all internal links inbound and outbound, all images and their alt text, and the structured data validator output for each page. Twelve CSV columns, one row per URL. For a 400-page site this is a 30-minute crawl on a desktop license; for a 4,000-page site allow 4-6 hours and a Memory mode database. The file is your contract: any URL in the export must resolve to a meaningful destination after the launch.
Step 2: Search Console export
Top 1,000 queries, top 1,000 pages, last 16 months. Save the CSV. These are the URLs and queries you must protect.
The query-to-URL mapping
Inside Search Console go to Performance > Queries, set the date range to the last 16 months, filter to the top 1,000 by clicks, export. Repeat for Pages. Then build a third sheet that joins them — for each top query, the landing page Google currently serves. This becomes your protection checklist: every one of those mappings has to survive the launch. If query "plumber stockport emergency" currently sends users to /plumbing/stockport-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: 1:1 redirect map
Every old URL maps to one new URL. No "let it 404 and Google will figure it out" — Google doesn't. 301 redirects, written into the host's redirects.json or .htaccess, tested with curl before launch.
Building the map without losing your mind
Open the URL CSV, add a column "new URL". Sort by inbound link count descending. Map the top 100 by hand — these are the URLs with most authority and deserve careful attention. Map the next 900 using a SUBSTITUTE or REGEX rule (a common pattern: /services/old-slug/ → /services/category/old-slug/). 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 had Article, FAQPage or LocalBusiness schema, the new site must too. Same @id, same canonical URL — Google treats it as continuity.
Entity continuity in detail
Google's knowledge graph caches the entity profile keyed off the @id you set in JSON-LD. If the old site emitted {"@type": "LocalBusiness", "@id": "https://oldsite.co.uk/#organization"} and the new site emits {"@type": "LocalBusiness", "@id": "https://oldsite.co.uk/#organization"} (note: same @id, same canonical, even if the design and tech stack are now different), Google treats it as the same entity and the reviews, aggregateRating, awards and brand mentions carry over. Change the @id and you start a new entity from scratch — the old reviews are still attached to the URL but the connection between the entity in the Knowledge Graph and the new entity on the new page is broken, and the rich results take 8-14 weeks to rebuild.
Step 5: keep the H1 and the first paragraph
Even if the design changes, the words have to stay close to the old version on day one. Refresh the copy in week three after Google has re-crawled.
Why the copy lag matters
Google's crawler treats meaningful changes to the 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. We ship the new design with the old copy intact for week one, let the crawler revisit, confirm rankings are stable, then refresh the copy in week three (small edits) and again in week six (deeper rewrites). The traffic line stays flat instead of dipping and recovering.
Step 6: launch on a Tuesday
Never on a Friday. If something breaks, you want a full week of working hours to fix it.
The launch-day runbook
A typical launch runs across 90 minutes on a Tuesday morning: T-30 final crawl of staging to confirm zero broken internal links; T-20 DNS TTL reduced to 300 seconds 24 hours earlier so this step actually propagates; T-15 deploy to production; T-10 cache purge across CDN; T-5 first manual smoke test of the top 30 URLs; T+0 swap DNS; T+5 second smoke test of the top 30; T+10 submit fresh sitemap.xml via Search Console; T+15 inspect 10 random old URLs in URL Inspection to confirm Google sees the 301; T+30 monitor real-user errors via Sentry or equivalent; T+60 first PageSpeed Insights run on three random URLs; T+90 sign-off email to the client. If anything is amber at T+30 we hold and remediate before the 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.
The early-warning dashboard
Beyond the Pages report, we watch four lines: daily organic clicks (Search Console > Performance), daily impressions split by branded vs non-branded, daily 404 count from the host log, and daily Core Web Vitals field data from CrUX. A healthy launch shows clicks within 5% of baseline within 14 days, impressions matching within 7 days, 404 count flat at near-zero (any 404s are investigated within 24 hours), and CWV improving — because if the redesign is doing its job the new build should be faster than the old. Where any of those lines diverges, we have a documented playbook for the failure mode (redirect drift, schema fault, copy change too aggressive, sitemap incomplete, CDN miscached).
The redirect map maintenance window
A 1:1 map at launch is necessary; it is not sufficient forever. New content created on the new site will mint URLs that did not exist on the old. Old URLs that did not get traffic but had a few inbound links will gradually accumulate them again. We schedule a redirect audit at day 60 and day 180 — for each, we re-run the inbound link export from Search Console, find any URL that has received external links since launch and is not in the redirect map, and add the appropriate destination. Without this, your redirect file slowly rots.
What "no SEO loss" actually means
Within 14 days, organic clicks should be within 5% of the pre-launch baseline. Within 30 days, within 2%. If you're still down 10% at day 30, something in the redirect map or schema is broken.
The three highest-stakes redirect mistakes we see
In rescues from other agencies we keep finding the same three patterns. (1) 302 redirects instead of 301s. A 302 tells Google the change is temporary; the link equity does not transfer, the canonical signal stays on the old URL, and the rankings drift. Always 301 on a permanent move. (2) Redirect chains: /old → /interim → /new. Each hop discards a small amount of authority and adds latency; chains of three or more cause Google to give up following partway. Audit the live redirects with a tool that follows the chain (Screaming Frog with the redirect-chain report) and collapse every chain to a single 301. (3) Redirects pointing to the new homepage as a catch-all instead of the relevant new page. Google treats a homepage redirect from a deep page as a soft-404 signal — the page is effectively gone, the rank goes with it. Map every meaningful URL individually; only the genuine long-tail orphans should fall through to the catch-all.
Schema-level traps that ruin a clean URL migration
A redirect map can be perfect and the rankings still drop if the schema layer regresses. Three recurring traps: (1) The new site emits a different LocalBusiness subtype than the old (Restaurant vs FoodEstablishment, Electrician vs ProfessionalService). Even when the @id is preserved, Google's Knowledge Graph treats the subtype change as significant and re-evaluates the entity. Match the old subtype unless there is a clear reason to change. (2) Article schema with a different author entity. If the old posts had a Person author with a stable @id and the new posts switch to Organization, the author-rank signal that boosted those URLs in 2024-2025 vanishes. Preserve the Person entity. (3) FAQPage schema split or merged across pages. Google's 2024 update reduced FAQ rich-result visibility but it has not gone to zero; rearranging the FAQ entities between pages forces a fresh classification on each. Where possible, keep the FAQ blocks attached to the same URL they lived on before.
The communication script for clients during a launch week
Beyond the technical playbook, the political work of a redesign matters more than people realise. Here is the email cadence we send through launch week, copy-paste-able. T-7 days: confirmation that the launch is on, runbook attached, contact info for the on-call developer, expected downtime window stated as "zero" with a contingency window of 30 minutes. T-1 day: final reminder, request to pause any scheduled email or paid-ads pushes for 48 hours to avoid muddying the traffic data. T+0 hour: launch confirmation, the live URL, a smoke-test checklist (test the contact form, test mobile, test checkout if e-commerce), the support contact. T+7 days: first health report, traffic delta, any flags, any small content tweaks landing. T+30 days: full health report, the redesign considered complete and successful or not, transition to ongoing care plan. The cadence keeps the client calm during the 14-day uncertainty window when Google is still re-crawling and the rank lines look noisier than they will at month two.