Website Redesign SEO Checklist

Your dev team just sent a Figma link. The new design looks sharp. Everyone's excited. And nobody in the room is thinking about the 47 pages that currently drive 80% of your organic traffic.

I've managed 44 websites across Astro, Next.js, WordPress, and static HTML. I've migrated sites between stacks, rebuilt them from scratch, and watched what happens when redesigns go wrong. The redesign itself is never the problem. It's what changes underneath that destroys rankings.

This is the exact checklist I use before, during, and after every redesign to protect organic traffic.

Why Redesigns Destroy Rankings

Google doesn't rank websites. It ranks individual pages based on specific signals: the URL, the content, the internal links pointing to it, the structured data, the page speed. A redesign can change every one of those signals simultaneously.

Here's what actually breaks:

• URLs change without redirects. /blog/post-name/ becomes /articles/post-name. Google treats these as completely different pages. Every old URL that returns a 404 loses all its accumulated ranking signals overnight.
• Content gets removed or rewritten. Designers want cleaner pages. They remove paragraphs, rewrite headlines, strip out "unnecessary" text. That text is exactly what Google matched to search queries.
• Structured data gets stripped. Schema markup doesn't survive CMS changes unless someone deliberately migrates it. Most dev teams don't even check. Rebuild missing markup fast with the free schema markup generator.
• Page speed regresses. The new design loads a 3MB hero image, two custom fonts, and a JavaScript animation library. Core Web Vitals go from green to red.
• Internal linking architecture changes. Navigation restructuring breaks the link equity flow that told Google which pages matter most.

I've seen all five happen in a single redesign. The site lost 62% of its organic traffic in 3 weeks. It took 5 months to recover to 80% of the original level. For more on timelines, see how long SEO takes under normal conditions; post-redesign recovery adds 2-4 months on top.

Phase 1: Before the Redesign (Your Baseline)

Everything that follows depends on having a clean snapshot of where you are right now. Skip this step and you won't know what broke.

Export Your Traffic Data

Pull every URL and its traffic from Google Search Console. Filter to the last 90 days. Export clicks, impressions, CTR, and average position for every page. Sort by clicks descending. The top 50 pages are the ones you absolutely cannot afford to break.

Crawl the Full Site

Use Screaming Frog or Sitebulb to crawl every URL. Document:

• Every URL and its HTTP status code
• All existing redirects (you'll need to preserve these)
• Pages with structured data (FAQ, HowTo, Product schema)
• Internal link counts per page
• Canonical tag configuration
• Core Web Vitals scores from PageSpeed Insights

This crawl is your insurance policy. Every post-launch issue gets diagnosed by comparing against it.

Screenshot the Current Sitemap

Download your XML sitemap. Count the URLs. This number should stay roughly the same after launch. If your current sitemap has 340 URLs and the new site generates 280, that's a flag to check, not proof of anything on its own. A sitemap is a crawl hint, not an indexing record: dropping a URL from it doesn't deindex the page, and a page can lose its index status for reasons that have nothing to do with the sitemap. Confirm what actually happened in Google Search Console's Pages report, with a site: search, or with the URL Inspection tool before you treat any URL as gone.

Phase 2: URL Mapping (The Most Critical Step)

This is where most redesigns fail. Every URL that changes needs a 301 or 308 permanent redirect to its new location. Not a 302. Not a JavaScript redirect. A server-level permanent redirect. (A 308 carries the same SEO weight as a 301, the only difference is that it preserves the HTTP method, Google treats both as permanent.) A URL that isn't changing doesn't need a redirect at all. See Google's migration guidance for the full picture.

Build the Redirect Map

Create a spreadsheet with two columns: old URL and new URL. Every single page from your crawl needs a row. If the URL structure changes from /blog/post-name/ to /articles/post-name/, every path needs a redirect.

Missing even one high-traffic URL can cost thousands in lost organic visits. 2026 CTR benchmarks put position 3 at roughly 5-10% of searches, so a page ranking position 3 for a keyword with 8,000 monthly searches drives somewhere around 400-800 clicks per month. One missing redirect wipes that out.

Here's a worked example from a real URL restructure, a site moving from date-based blog URLs, a flat services folder with legacy file extensions, and an inconsistent category folder to a single, clean URL pattern:

Two things go wrong most often in this table. First, two old URLs collapsing onto the same new URL, like the first and third rows above; decide which one is canonical and 301 the other into it, don't leave both live. Second, rows left blank because nobody could work out where a page went; a blank row means a 404 on launch day, not a redirect.

The Trailing Slash Case

Trailing slashes are a small config decision with a large blast radius, because they define whether /about and /about/ are the same URL or two competing ones. Left unmanaged, a stack that serves both forms with a 200 status lets Google crawl and index them as separate pages, splitting any links or authority pointing at the page between the two versions instead of consolidating on one.

This site shows the fix rather than the problem: trailingSlash: true in next.config.ts doesn't just pick a preferred form, it makes Next.js issue a 308 redirect from the non-slash URL to the slash URL automatically, so /about lands on /about/ server-side instead of both being independently crawlable. That's the correct outcome, one canonical URL, one redirect hop, no duplicate.

The fix is the same in principle regardless of framework: pick one form, set it once in the framework config so it actually redirects the other form rather than just rendering it, trailingSlash: 'always' in Astro or trailingSlash: true in Next.js, and make sure the redirect map, the internal links, and the XML sitemap all agree with that setting before launch. On a stack with no such config, or where it's set inconsistently, checking this after launch means finding out from a GSC "duplicate, Google chose different canonical" report weeks later, when the damage is already done.

Preserve Existing Redirects

Your current site probably has redirects already in place from previous URL changes, old campaigns, or merged pages. These need to carry forward. If your old site redirected /services/consulting/ to /services/seo-consulting/, that redirect must still work after the redesign. Otherwise, any backlinks to the original URL break.

Pre-Launch Redirect Verification Checklist

Run through this before DNS cuts over to the new site, not after:

1. Crawl the old site's XML sitemap and server logs together. The sitemap shows what you meant to have indexed; the logs show what's actually getting hit, including old URLs that fell out of the sitemap years ago but still carry backlinks.
2. Map every URL from that combined list, plus your existing redirects, to an outcome on the new site. No blank rows. If a genuinely relevant destination exists, redirect to it, not the homepage and not a loosely related category page. If nothing on the new site actually answers that URL any more, a 404 or, better, a 410 is the honest outcome, a forced redirect to an irrelevant page is worse for users and for Google than an accurate error. Google's own migration guidance makes the same point: don't funnel many old URLs into one unrelated destination.
3. Test the redirects on staging before DNS cutover. Request each old URL against the staging environment (with a hosts file edit or a staging domain) and confirm a single-hop 301 or 308 to the correct final URL, not a 302, not a redirect chain through two or three hops.
4. Check the trailing slash and protocol on every redirect target. A redirect that lands on the wrong slash or http instead of https just creates a second redirect hop Google has to follow.
5. Monitor GSC Coverage and server 404 logs daily for the first two weeks post-launch. Check each new 404 against the redirect map: if it's a URL that should have a relevant destination, it's a missing row, fix it. If it's a URL you deliberately retired with nothing to replace it, the 404 (or 410) is doing its job. Either way it's far cheaper to confirm in week one than to notice in month three.

Phase 3: Content Preservation

Don't let designers remove text to "clean up" the page. If a page ranks for 40 keywords, those keywords are in the content. Removing paragraphs to make the design cleaner removes the content Google is ranking.

Protect Your Headlines

Rewriting H1 tags changes the primary signal Google uses to match queries. If your H1 is "Best Running Shoes for Flat Feet 2026" and the designer changes it to "Find Your Perfect Fit", you've removed every keyword Google was using to rank that page.

Keep Body Content Intact

I audit sites where the redesign removed 60% of the page content to fit a "modern minimal" layout. Every removed paragraph contained long-tail keywords the page ranked for. The page went from ranking for 40 queries to ranking for 8. That's a common SEO mistake I find during technical audits.

Migrate Meta Data

Meta titles, meta descriptions, and image alt text must transfer to the new site. Meta titles and alt text carry real ranking weight; meta descriptions don't, Google has said directly that they're not a ranking signal, their job is the snippet Google shows in results, which is what drives click-through once you're already ranking. Losing any of the three during migration costs you something, just not the same thing. If your CMS migration doesn't carry them over automatically, export them and reimport them manually.

Phase 4: Technical Checklist During Build

Run through this list before the site goes live. Every item is a binary check: it works or it doesn't.

• Canonical tags on every page, pointing to the correct URL (watch for trailing slash mismatches)
• XML sitemap generating correctly with all new URLs, no old URLs, no 404s
• robots.txt not blocking anything that wasn't blocked before (staging robots.txt rules are the number one cause of post-launch indexing failures)
• Structured data carried over: check with Google's Rich Results Test
• Meta titles and descriptions preserved from the old site
• Internal links updated to new URLs (not relying on redirects for internal navigation)
• Image alt text preserved across the migration
• hreflang tags if the site serves international audiences
• Open Graph and Twitter Card tags for social sharing
• 404 page returning a proper 404 status code (not a soft 404 that returns 200)

If you're switching CMS platforms, this list doubles in importance. A WordPress-to-Next.js migration changes how every one of these elements gets generated. For context on how acquisitions compound these risks, see SEO after acquisition.

Phase 5: Launch Day Protocol

Launch day starts the monitoring sprint, not the celebration.

Immediate Actions (First Hour)

1. Submit the new XML sitemap to Google Search Console
2. Check robots.txt isn't blocking the site (open yourdomain.com/robots.txt in a browser)
3. Test 20 random old URLs against your redirect map: a URL that changed should 301 or 308 to the right destination (not 302), a URL that stayed the same should load directly, and a URL you deliberately retired should return 404 or 410, not a redirect to somewhere irrelevant
4. Run a PageSpeed Insights test on 5 key pages and check the lab data: that's synthetic and available immediately, so it's the only Core Web Vitals read you can trust in hour one. The field data (Chrome UX Report) tab is a rolling 28-day aggregate, on a URL that just launched it's either blank or still showing the old site's history, and it won't reflect the new pages until roughly 28 days of real traffic has accumulated against them
5. Check mobile rendering on 3 different screen sizes

First 24 Hours

6. Run a full Screaming Frog crawl of the new site
7. Compare URL count against your pre-launch crawl
8. Check the GSC Coverage report for any new errors
9. Verify all structured data with the Rich Results Test
10. Test every form, CTA, and conversion point (these aren't SEO items, but broken conversions make the traffic worthless)

Phase 6: Post-Launch Monitoring

Post-launch monitoring continues until your traffic stabilises, well past the launch date itself.

Week 1-2: Daily Checks

Monitor these in Google Search Console every day:

• Indexed pages count. This should roughly track your redirect map: a drop that matches pages you deliberately retired is expected, not a fault. If it drops by more than 5% beyond what your map accounts for, something is blocking crawling or returning errors.
• Crawl errors. No unintended new 404s is the target. A 404 or 410 on a page you deliberately retired with no replacement is fine; a 404 on a URL that should have redirected somewhere relevant is a missed row in the map.
• Impressions trend. A 10-20% dip in the first week is normal as Google recrawls. A 40%+ drop means something structural broke.

Week 2-4: Ranking Recovery

• Track positions for your top 20 queries. Minor fluctuations (1-3 positions) are normal. Drops of 10+ positions indicate a page-level problem: check the specific URL for content changes, missing schema, or redirect issues.
• Compare click-through rates against your baseline. If impressions recovered but clicks didn't, your new meta titles or page titles may be underperforming.
• Check for new crawl anomalies in GSC's Pages report. Watch for "Crawled, currently not indexed" increases.

When to Escalate vs When to Wait

Wait if: traffic dipped 10-20%, impressions are recovering, no new crawl errors, redirects are working. This is normal. Give it 3-4 weeks.

Escalate if: traffic dropped 40%+, indexed page count is falling beyond what your retired-page count explains, unintended new 404 errors are appearing daily, or Core Web Vitals scores regressed significantly. These need immediate fixes, not patience.

The Real Cost of Getting This Wrong

A B2B SaaS company I audited redesigned their marketing site without URL mapping. They changed 180 URLs. Only 40 got redirects. The other 140, including 12 pages that drove 65% of their organic demo requests, returned 404s for 6 weeks before anyone noticed.

Organic demo requests dropped 73%. Recovery took 4 months after implementing redirects. The redesign that was supposed to "modernise the brand" cost them an estimated £180,000 in pipeline.

The checklist above takes 2-3 days of preparation. Skipping it risks months of lost revenue. That's the trade-off.

If you want a second pair of eyes before your redesign launches, I work as an SEO migration consultant for pre-launch reviews. I'll crawl both versions, map every redirect, and flag every risk before you push to production.