How to redesign a website without losing your SEO

The asset audit. Before a designer opens Figma, before a developer writes a line of code, before the wireframes get reviewed — pull the full Search Console export for the last 16 months. That is your asset list. Every URL that earned an impression is an asset Google has assigned authority to. Anything not on the list can be deprecated; anything on the list needs a destination on the new site.

What to export, specifically:

• Pages report — every URL with its impressions, clicks, average position, click-through rate for the full 16-month window
• Queries report — every query the site ranks for, mapped to its top-ranking URL
• Query-Page pairs — the cross-table that tells you which queries each URL captures
• Internal-link map — Screaming Frog or Sitebulb crawl, exporting the link graph of the existing site

16 months matters specifically because Google has been known to revisit URLs on a 12-15 month cycle. A 90-day baseline misses the long-tail. A 6-month baseline misses URLs that rank for seasonal queries. 16 months covers a full year plus margin.

This is the step that gets skipped most often. The agency that says "we'll redirect the old URLs as we find them" is the agency that's going to ship the new site, then realize 600 ranking URLs are 404ing. Don't accept that workflow. The baseline is non-negotiable.

Real number from our own rebrand: we found 922 URLs in our legacy Google Search Console that earned impressions but didn't exist on the live sitemap. Six hundred of those were "ghost rankings" — pages Google still held in its index because no redirects had been issued when the original Elementor site dropped them. We had to either redirect them or repopulate them, and the answer for each one was case-by-case.

This is the step nobody talks about. Most 5-year-old sites have multiple URLs competing for the same keyword cluster. Three blog posts about "SEO for small business," two service pages about "web design Boca Raton," a guide and a category page targeting the same head term. Google can't decide which to rank, so it ranks none of them well.

The audit is mechanical:

1. Group every URL in your Google Search Console baseline by the head term it ranks for.
2. Identify clusters where 2+ URLs share the same head term and overlapping query footprints.
3. Pick the strongest survivor per cluster (highest impression count + best position + most internal links).
4. 301-redirect the losers into the survivor. Don't merge content; consolidate authority into one URL.
5. Update internal links to point only at the survivor.

The accounting matters. When two URLs splitting 50K + 30K monthly impressions get consolidated into one URL, the survivor doesn't keep 80K — typically it ends up around 60-90K because Google's algorithm now trusts the single canonical answer more. We've measured this on multiple migrations.

Real number from our own rebrand: we deleted 66 cannibalizing posts during this audit, recovering roughly 200,000 monthly impressions worth of split authority that we redirected into the city and service pages. Every one of those deletes was deliberate, with the 301 target chosen specifically to consolidate equity where we wanted ranking depth, not where the content "fit best."

The agency that skips this is the agency leaving 200K impressions on the table because the audit work isn't billable-looking.

The next failure mode: the agency builds the new site with one URL convention, the client says "actually we want category names in the URLs," and the URLs change three times before launch. Each change orphans the redirects you've been writing.

The URL search markup for the entire new site should be a single document, locked before any page is built. The search markup specifies:

• Top-level structure — `/services/`, `/guides/`, `/blog/`, `/case-studies/`, `/{service}-{city}/` for city pages, etc.
• Permalink format for posts — `/blog/{slug}/`, NOT `/{category}/{postname}/` (category-based permalinks bake the URL into a fragile category taxonomy)
• Slug conventions — how compound terms get hyphenated, whether plurals or singulars are used, whether numbers appear in URLs
• The exact list of redirect rules from old URL pattern to new URL pattern
• The treatment for pagination, archives, tag pages, author pages, attachment pages

Once locked, every page built must conform. Changes to the URL search markup after build start should trigger an explicit re-audit of every redirect that depends on the changed pattern.

Real artifact from our own rebrand: the search markup lock document lives at /url-migration/URL-SCHEMA-LOCKED.md in our internal repo. It defines 998 URLs across 4 tiers (A: priority money pages, B: hubs, C: content, D: legacy). Every URL has a priority level. Every priority URL has a curl-verified redirect rule. The build phase couldn't begin until the search markup was Skyler-signed.

Now you map every URL from the Google Search Console baseline (Step 1) to a destination on the new search markup (Step 3). The output is a CSV with three columns at minimum: old_url, new_url, redirect_type. Nothing else.

Where each old URL goes:

• Direct 1:1 match — old URL maps to the equivalent page on the new search markup (most common)
• Many-to-one consolidation — old URLs that survived the cannibalization audit map into the chosen survivor
• Closest-hub fallback — old URLs with no clean equivalent get redirected to the closest topical hub (a deleted "SEO for plumbers" post → /services/seo/, not to /404)
• Preserve as-is — URLs that stay at the same path on the new site (no redirect needed)
• Excluded — URLs that should not be preserved (e.g., spam attempts in the Google Search Console log, accidentally-indexed admin pages). Document why each one is excluded.

The map is the source of truth. Every redirect rule on the production site comes from this CSV. Every QA check verifies against this CSV. The agency that "redirects URLs as they find them" without a master map is the agency that misses a big share of them.

Real numbers from our own rebrand: 998 unique URLs in the map, 840 needing redirect, 158 preserve-as-is, 0 excluded. The map lives in /url-migration/migration-map.csv. We added 275 supplemental redirects later (after auditing internally-linked URLs that never accumulated Google Search Console impressions). Total: 1,683 active redirect rules across 9 years of content.

The redirects must be implemented at the server level (Apache/Nginx config, WordPress `wp_redirect()`, or a dedicated plugin like Redirection that emits proper 301s). They must NOT be implemented in:

• JavaScript — Google's crawler often does not execute JS-based redirects, and even when it does the equity transfer is partial
• Meta-refresh tags — these are technically "soft" redirects; Google treats them as 200s with content, not 301s
• Plugins that just rewrite the URL in the address bar — these don't issue HTTP 301 status codes; from the crawler's view nothing happened
• Cloudflare Worker redirects on a different domain than your site — they work, but they break the predictable 301 flow if not configured correctly

Test every redirect with curl -I:

$ curl -I https://old-site.com/old-page/
HTTP/2 301
location: https://new-site.com/new-page/

If the response is anything other than `HTTP/2 301` with a `location` header pointing at the right destination, the redirect is broken. Don't accept "it works in the browser" as evidence; the crawler doesn't render the way the browser does.

Cache caveat: after deploying redirects, your content network (Cloudflare) and your host's page cache (Kinsta page cache, WP Rocket, etc.) may serve cached versions of the OLD page for hours or days. We hit this on our own rebrand — for ~12 hours the curl tests showed 404s coming back from a cached 404 response, while the WP redirect layer was actually issuing proper 301s. Flush all cache layers immediately after deploying redirects, then re-verify with curl + cache-bust query strings.

This is the step that distinguishes agencies who have done this before from agencies who haven't. A redirect chain is when an old URL redirects to an intermediate URL, which redirects to another intermediate, which finally redirects to the final destination. Each hop bleeds equity.

Google's tolerance: roughly 1-2 redirect hops are fine. 3+ hops start to lose ranking signal. 5+ hops are treated as broken.

How chains form:

• Existing legacy redirects on the old site (from a previous rebuild 5 years ago) still firing, sending old-URL-A → old-URL-B
• Then your new migration map redirects old-URL-B → new-URL-C
• Then your new site's URL canonicalization redirects new-URL-C (non-www) → new-URL-C (www) or HTTP → HTTPS or trailing-slash → no-slash
• Result: 4-hop chain from the URL Google has in its index to the final destination

The audit:

1. Take every entry in your migration map.
2. For each old URL, run curl -ILI (multiple `I` flags = follow redirects, show all headers).
3. Count the number of 301 hops in the response chain. If more than 1, you have a chain.
4. Add a direct 301 rule from the original URL to the final destination, bypassing the intermediate hops.
5. Re-test until every URL resolves in a single hop.

Real number from our own rebrand: our first deploy had 87 multi-hop chains, mostly from legacy 2018-era Elementor redirects compounding with our new search markup. We added 87 direct rules in the migration map to flatten them. Every URL in the migration map now resolves in 1 hop. The audit script lives at /url-migration/audit-redirects.py; it ran nightly during the migration window.

URL redirects are necessary but not sufficient. The new site has to inherit (or surpass) the technical signals the old site was ranking on. Easy ways to lose ranking even with perfect redirects:

• Search markup disappeared. Old site had LocalBusiness + Service + BreadcrumbList + FAQPage emitted via Yoast. New site ships with no search markup. The semantic signal Google used to rank the page is gone.
• Core Web Vitals collapsed. The old site loaded its main content in 2.1 seconds. The new one ships with hero animations and lazy-loaded fonts and now takes 4.8. Google demotes the page even though the URL is the same.
• Internal-link graph thinned. Old site had each service page linking to 4-5 sibling services + 6-8 supporting blog posts. New site has a sparse "modern minimal" nav and only the homepage links to each service. Topical authority signals collapse.
• Title + meta description rewritten without intent preservation. Old title was "Boca Raton Web Design Agency | 11 Years Building South Florida Sites." New title is "Web Design — Our Services." Same URL, different ranking footprint.
• Word count cut in half. The old service page was 1,800 words; the new one is 600. Google's content quality models notice.

The audit pre-launch is a per-page comparison. For every URL preserved or 301-redirected, ensure:

• Search markup at minimum as comprehensive as the old page (typically more)
• Title + meta-description retain the primary keyword(s) the old URL ranked for
• Word count at or above the old page (for content-driven pages)
• Internal links from at least as many pages as before, ideally more
• Mobile Core Web Vitals equal to or better than old page (don't let loading speed, tap response or layout stability get worse)

Real check from our own rebrand: we ran a pre-launch diff across all 26 launch-pace pages comparing old-site vs new-site for each of the 5 above signals. Every page passed before the domain switch.

Launch isn't the end; it's the start of the riskiest 60 days. The metrics that will tell you whether the migration worked, and what to fix if it didn't:

• Google Search Console — Index coverage report. Watch daily for the first week. Expect a temporary dip in indexed pages as Google re-crawls; expect it to recover within 7-14 days. If it doesn't recover, you have URLs that aren't being indexed and need investigation.
• Google Search Console — Pages report. Weekly delta against the pre-launch baseline. Identify URLs that lost impressions; check if their redirect is firing, if the new page has equivalent content, if the search markup is intact.
• Google Search Console — Performance report. Daily for week 1, weekly thereafter. Total impressions + clicks. Expect 10-20% temporary dip in week 1-2 as Google re-evaluates; expect recovery by week 4-6. If you're still 30% below baseline at week 8, something is wrong.
• A map-rank tracker (a geo-grid tool). Weekly rank tracking for the top 8-12 keywords from the geographic centroid of your service area. Local-pack rank moves on a different cycle than organic rank.
• Google Business Profile Insights. Daily for week 1, weekly thereafter. Calls, direction requests, website clicks. These correlate with revenue more tightly than rank does.
• Server logs (or Cloudflare Analytics). Watch for unexpected 404s. If old URLs are still being hit and you're 404ing on them, add to the migration map and redirect.

The 90-day rollup: by month 3, you should be at or above pre-launch baseline on every signal that matters. If you're not, the rebuild has cost rankings and you need to know what to fix.

The agencies that ship a new site and disappear are the agencies who don't want to be in the room when the 60-day metrics come in. The agencies who do this well have a 60-day post-launch monitoring program as part of the engagement scope — not as an upsell, but as the standard close-out.