How to Preserve SEO During a Website Rebuild

TL;DR #

Rebuilds don't lose rankings because of a new theme. They lose rankings because on launch day a batch of old URLs disappears or moves without a redirect, crawlers hit walls, and the backlinks pointing at those URLs stop doing any work for you. To keep traffic, four things have to happen. Two to three weeks before launch, crawl the old site and pull every URL that has traffic, backlinks, or conversions. Build a one-to-one old-to-new 301 map where every row has a destination. Run launch day from a runbook: verify on staging, cut over, then check redirects within minutes. For four weeks after launch, watch Search Console, indexing, rankings, and 404s, and patch the problems the same week you find them. This is the list we actually use, not theory.

We took over a building-materials exporter who'd been running the same WordPress site for five years. About 8,000 monthly organic visits, mostly to product pages and case studies that fed inquiries. Marketing wanted a "modern" rebuild on Next.js with a headless CMS. Three days after launch, organic dropped to 2,300 and the founder called at 11pm. The cause was embarrassing: the dev team had changed /products/xxx-tile/ to /en/products/xxx-tile, nobody wrote 301 rules, and five years of backlinks were now pointing at 404s.

The damage isn't complicated. But miss any single step in the list below and recovery takes two to three months instead of two to three weeks. Here's the process we now run on every rebuild.

1. Crawl #

Two to three weeks before launch, capture the old site as data, not as a memory. You need four datasets:

• Full URL inventory: run Screaming Frog or Sitebulb against the production site and export every reachable URL — including PDFs, image pages, tag archives, and pagination. Our worst miss was a client who forgot about 200+ /case/page/2/ URLs that the new build never generated, all 404 on launch day.
• Organic traffic pages: pull the last 12 months of the Pages report from Google Search Console, sort by clicks, export. The top 20% typically drives 80% of organic traffic — those pages must survive.
• Linked pages: from Ahrefs, Semrush, or Search Console's Links report, export every URL that has at least one external backlink. These are years of accumulated equity. Each broken redirect is a permanent loss.
• Converting pages: from GA4, list every landing page that has produced a form submission, WhatsApp click, or email click in the last six months. Traffic may be small. Inquiry impact is not.

Merge the four into one master sheet: old URL, last-12-month clicks, backlinks, conversions, content topic, decision (keep / merge / retire). This sheet is the spine of every later decision. For the per-field version of this audit, see the Complete Website Renovation Audit Checklist.

2. Mapping #

Walk the master sheet row by row. Every old URL gets one of three outcomes:

• One-to-one keep: the URL structure changes but the topic stays. /products/red-tile.html → /products/red-tile/. Direct 301.
• Merge: three near-duplicate product pages collapse into one canonical page, often with anchors. All three old URLs 301 to the new page, ideally to the right anchor. The catch: keywords and link anchor text from all three originals have to live on the new page, or the merge is really a deletion wearing a hat.
• Retire: outdated product, dead service, or a page with zero traffic and zero backlinks. 301 to the closest parent category, or return 410 Gone if there's no good destination. Use 410, not 404. 410 tells crawlers "intentionally removed" and is cleaner.

Every row needs a target. Our hard rule: if the mapping sheet still has "TBD" entries, the rebuild does not enter staging verification.

Encode the 301s the way the dev team will use them — nginx/Apache rewrite rules, a Next.js redirects config, or rows in WordPress's Redirection plugin. The thinking here overlaps with the SEO Migration Checklist for Old Domains, but for a same-domain rebuild you can skip the DNS and hreflang work.

3. Content #

Most teams treat rebuild SEO as a technical problem and then watch rankings drop anyway. The reason is usually content. The new design "needs breathing room," so a 1,500-word product description shrinks to 300 words. The page ranks for less because it says less.

Before launch, verify:

• Keywords still present: every keyword that ranked top-10 for a high-traffic page over the last 12 months should appear naturally in the new H1, H2s, opening paragraph, or body. Not stuffed. Present, because the new page is genuinely about the same thing.
• Word count floor: top-20% traffic pages cannot lose more than 30% of their word count. If the designer wants whitespace, give them whitespace in the visual frame, not in the prose.
• Image alt text: migrate the alt attributes from the old site. Don't let the new CMS auto-generate "image-1.jpg." Image search depends on it.
• Structured data: re-add FAQ schema, Product schema, BreadcrumbList, anything the old site had. Run Google's Rich Results Test on the templates before launch.
• Canonical logic: if the old site sent canonical signals (paginated archives pointing to a main archive, parameter URLs pointing to clean URLs), the new site needs the same logic, not a default canonical-self on every page.

Content migration breaks down further by field. The full list lives in the Website Content Migration Checklist.

4. Technical baseline #

In rebuild SEO, the technical items most likely to bite you, in priority order:

• robots.txt: the Disallow: / you set on staging is the single most common production accident in this category. One line removes the whole site from Google. Make curl https://yourdomain.com/robots.txt the last manual check before you tell anyone launch is done.
• sitemap.xml: generate a fresh sitemap with new URLs only, submit to Google Search Console and Bing Webmaster Tools. Don't proactively delete the old sitemap. Let it 404; crawlers will recrawl.
• Canonical tags: one per page, pointing to itself, on the production domain. Not the staging domain you forgot to swap.
• hreflang (if multilingual): when paths change, every hreflang target URL changes too. Update the full set, not just the language switch.
• 404 page: ship a useful custom 404 with site search, top services, and a contact link. Google doesn't penalize 404s, but a visitor arriving from an old backlink and bouncing on a generic error page is a lost lead anyway.
• Page speed: run Lighthouse. LCP under 2.5 seconds, CLS under 0.1. New builds often regress here because of hero animations and autoplay video the old static template never had.

For the broader checklist, see the Technical SEO Baseline for a New or Rebuilt Website. For terminology, the Overseas Website Glossary covers the acronyms. Google's SEO Starter Guide is also worth a re-read with the rebuild lens on.

5. Launch runbook #

Launch day is not "click deploy and announce on LinkedIn." Our runbook, working backwards:

T-minus one week

• Crawl staging end-to-end, diff against the master sheet, confirm every old URL has a working 301.
• Manually hit 30 high-priority redirects on staging and confirm the response codes.
• Stage the new sitemap so the new structure is at least readable.
• Take a full backup of the old site — database and files. Twice.

Launch day, in order

1. Cut DNS or web-server config. New site receives traffic.
2. curl robots.txt and sitemap.xml to confirm both are live and correct.
3. Hit the 30 priority redirects against production. Any miss = roll back or hotfix immediately.
4. Submit the new sitemap in Search Console. Request indexing on the homepage and the top five traffic pages.
5. Drop an annotation in GA4 and Search Console marking the launch. You'll thank yourself in a month.

Week 1 post-launch

• Daily check of the Search Console Coverage report. New 404s and soft 404s get same-day 301 patches.
• Daily Screaming Frog crawl from outside the network — anything that 404s without a redirect is a missed mapping row.
• Daily GA4 Pages report — confirm the pre-launch top 20 pages are still pulling traffic.

How this fits into a real sprint cadence is in How Our Small Team Runs a Four-Week Website Rebuild Sprint.

6. The first 4 weeks #

The month after launch is observation, not vacation. Four things to look at every week:

• Search Console, Coverage: new 404s, "Excluded," "Crawled, currently not indexed." 404s get 301s. Excluded is usually a stray noindex.
• Search Console, Performance: compare the four weeks pre-launch to the four weeks post-launch by clicks, impressions, and average position. The five worst-performing queries point you at the specific pages to check.
• Search Console, Links: are external backlinks reassociating with the new URLs? If a high-value linking page hasn't updated four weeks in, it's worth emailing the site owner to ask for a link update directly.
• GA4, conversions: form, WhatsApp, and email-click totals, broken down by page. Traffic flat but conversions down usually means a CTA position issue or a form field that the new template added without anyone thinking about it.

At the end of week four, build a comparison: 30 days before vs 30 days after, by page, by query, by country. The point isn't to show the boss. The point is to decide whether the next sprint is content, links, or conversion fixes.

Tradeoffs #

A complete pre-launch process takes 3-4 weeks, plus 4 weeks of post-launch monitoring. Small teams always ask which steps they can drop. Our take:

• Non-negotiable: crawl, mapping sheet, robots/sitemap/canonical check, week-one monitoring. Skip any of these and traffic loss is a guarantee, not a risk.
• Can be deferred: structured data backfill, a polished 404 page, Lighthouse performance tuning. These can land in the two weeks after launch without measurable SEO cost.
• Can be skipped: per-pagination 301s for /page/2/, /page/3/ archives. These pages usually have no traffic and no backlinks. 301 to the parent or 410 is fine.

If time is genuinely scarce, isolate the top 20% of traffic pages and protect those. One-to-one 301, keywords preserved, daily monitoring. Patch the rest if and when problems surface.

FAQ #

How long should we keep 301 redirects? #

Twelve months minimum, twenty-four recommended. Google's own site move guidance says to keep redirects in place for "at least one year," and external linking sites update far more slowly than crawlers. Keeping a 301 rule alive long-term costs almost nothing (one nginx line) and protects years of accumulated backlinks. Removing them early is throwing away the link equity you just paid to preserve.

How much short-term traffic dip is normal? #

The first one to two weeks usually see a 5-15% organic fluctuation while crawlers re-index. If, four weeks in, organic hasn't recovered to within 90% of pre-launch levels, treat it as an unfixed problem — recheck Search Console Coverage and the 301 hit rate before assuming it's seasonality.

Should we noindex during a soft launch? #

No. The new site should be crawlable from the moment it goes live on the production domain. The longer search engines see noindex, the longer the recovery takes. Use password protection or Disallow on the staging domain; flip to fully open the moment production is real.

Can we delete all the old blog posts? #

Not without checking. Pull the Search Console data first — anything with clicks or backlinks in the last 12 months gets 301'd to the closest topic page or kept. Posts with neither traffic nor links can return 410 Gone. Mass deletion without that filter throws away potential search assets you've already paid to build.

Get a diagnosis #

If you're planning a rebuild on an existing corporate website — or you've launched and traffic is already sliding — bring the old domain, Search Console access, and your launch timeline. We'll run this exact checklist with you in a free initial review under our website rebuild service and tell you which items are P0 fixes versus what can wait for the next iteration.