The 2026 Website Redesign Checklist: Ship Without Losing Traffic
A website redesign checklist is the QA framework that prevents a relaunch from undoing the SEO equity, conversion paths, and integrations the old site quietly carried. The dominant risk is not the new design — it is the silent regression of everything that worked before. Search Engine Journal's analysis of 892 site migrations found that 17% never recovered their pre-migration traffic even after 1,000 days, and the average recovery took 523 days. The teams who avoid that outcome do not test harder. They test the right things before, during, and after launch — URL preservation, redirect QA, content and schema carryover, before/after Lighthouse comparisons, sitemap diffs, 404 handling, image-alt audits, mobile-responsive parity, and the rollback plan.
TL;DR — the redesign QA killers, in priority order:
- Broken URL mapping. Mass-redirects to the homepage create soft 404s. Google may pass no link equity.
- Lost schema and canonicals. Article, FAQ, breadcrumb, and product schema dropped during a CMS migration costs rich-result placements.
- Performance regression on real-user data. A Lighthouse score that looks fine in lab tests but breaks the 75th-percentile INP threshold of 200ms on production.
- Sitemap pointing at dead URLs. New sitemap.xml referencing old slugs is one of the fastest ways to confuse Googlebot during reindexation.
- No rollback rehearsal. Knowing the runbook exists is not the same as having executed it.
Phase 1: Pre-redesign baseline — document what "working" looks like
The redesign starts before any staging environment is built. You cannot verify nothing broke if you do not know what working looked like. This is the phase teams skip when timelines compress, and the phase whose absence causes the worst post-launch arguments — the ones where nobody can prove whether the form was already broken before launch.
Traffic, conversion, and performance baseline
- Export 90-day organic traffic by URL from Google Search Console — these are your high-value redirect targets
- Export top pages by sessions, pageviews, and conversion rate from GA4
- Document current Core Web Vitals (LCP, INP, CLS) at the 75th percentile from CrUX — that is the threshold Google uses for ranking
- Screenshot your GA4 event configuration — conversion events lost in migration are extraordinarily hard to backfill
URL and backlink inventory
- Crawl the live site with Screaming Frog SEO Spider (now at v23.x) — export Internal HTML and All Outlinks
- Cross-reference with Search Console's Pages report to catch URLs receiving impressions that the crawl missed
- Export existing 301 and 302 redirects from your .htaccess, Nginx config, Cloudflare rules, or CDN
- Pull a backlinks export from Ahrefs, Semrush, or Search Console — every page with a meaningful external link is a mandatory redirect target
- List URLs referenced in email campaigns, paid ads, link-in-bio tools, QR codes, or printed material
Functionality and visual baseline
- Catalogue every form, third-party integration, authenticated flow, and custom-JavaScript widget — with their endpoints
- Document which pages use which templates — template-level changes cascade
- Full-page screenshots of the top 30 pages at 1440px, 768px, and 375px viewports
- Save the current sitemap.xml for direct diffing against the post-launch version
Phase 2: URL preservation and the redirect map
URL preservation is the most consequential redesign decision and the most commonly mishandled one. Google's own documentation is explicit: redirects should be 1:1 replacements, and if the new page differs meaningfully from the original Google may treat it as a soft 404 and pass no PageRank. Mass-redirecting everything to the homepage — a common shortcut under deadline — is the single fastest way to lose traffic.
The redirect map
- Every pre-redesign URL maps to one post-redesign URL with comparable content and intent
- Pages with strong backlinks or organic traffic get priority — they concentrate the equity that must survive
- No mass-redirects to the homepage for any page that previously ranked
- No redirect chains — Google explicitly recommends updating internal links to point at final URLs rather than relying on redirect chains
- All redirects use 301, not 302, unless a 302 is intentionally appropriate (geo, A/B, seasonal)
- www/non-www and HTTP/HTTPS both resolve to the canonical version; trailing-slash behaviour is consistent
Verification before launch
- A scripted check (a
curl -Iloop or Screaming Frog list mode) confirms every old URL returns 301 and the target returns 200 - No redirect target itself returns
noindex, 404, or 410 - Edge cases tested: query strings, fragments, trailing slashes, internationalised URLs, uppercase/lowercase variants
A subtle 2026 nuance — if you are changing a page's URL and its content, Google's guidance is to update the content first, let it reindex, then redirect the URL. That way Google sees a redirect between two equivalent pages and passes link equity cleanly.
Phase 3: Content audit and metadata carryover
Content that existed before the redesign must exist after it, in the right place, with the right structure, and without losing any of the metadata that Google reads. CMS migrations are where most metadata silently disappears — Yoast or RankMath fields that lived in WordPress custom fields do not automatically map to whatever the new CMS uses.
Content presence
- Every URL from the pre-redesign crawl exists at the same URL on the new site or has a 1:1 301
- No previously indexed pages return 404, 403, or are newly blocked by robots.txt
- Body copy matches the approved source — no truncation, Lorem Ipsum, or draft revisions accidentally published
- Headings reflect the intended hierarchy — exactly one H1 per page
- Author bylines, dates, and category metadata on articles are accurate
- In-page links point at new internal URLs directly, not through redirects — matters for crawl efficiency and link equity
Image-alt audit
Most redesigns rebuild image assets and either lose or auto-generate alt attributes. WCAG 2.2 1.1.1 (Non-text Content) requires meaningful alternatives, and accessibility enforcement has tightened since the European Accessibility Act took effect on June 28, 2025.
- Informational images have descriptive alt text — not the filename
- Decorative images have
alt=""so screen readers skip them - Image-links have alt text describing the link destination, not the image
- No images carry the previous CMS's auto-generated alt (filename or title field)
For deeper accessibility coverage during a redesign, the best accessibility testing tools for WCAG compendium covers axe DevTools, WAVE, and Pa11y in detail.
Schema preservation
- Article schema present on every page that had it pre-redesign, with
author,datePublished,dateModified,headline,image - FAQ schema preserved with question/answer pairs matching visible content
- Breadcrumb schema reflects the new URL hierarchy
- Product schema retains price, availability, SKU, rating, and review count on commerce pages
- Every page with schema validates in Google's Rich Results Test
- No leftover schema references URLs or images that no longer exist
Open Graph and social previews
The first post-launch user touchpoint is often a shared link on LinkedIn, X, or Slack. Broken OG previews are immediately public.
-
og:title,og:description,og:image,og:url,og:typepresent on every page - OG images are 1200×630px and load over HTTPS — not pointing at staging or a wiped CDN bucket
- Twitter Card meta present where you target X distribution
- Test a sample in Facebook's Sharing Debugger and LinkedIn's Post Inspector — clear cache so new previews fetch
Phase 4: Technical SEO and the sitemap diff
A new site usually means a new sitemap. The sitemap diff — comparing pre and post — is the single most efficient way to spot URLs that fell out unintentionally and URLs that appeared by accident (filter pages, tag archives, dev pages).
Sitemap diff
- sitemap.xml regenerated post-launch and accessible at the canonical location
- No references to pre-redesign URLs that no longer return 200
- Entries match the canonical URL — same protocol, host, trailing-slash behaviour
- Diff pre vs post —
sort pre-sitemap.xml > pre.txt && sort post-sitemap.xml > post.txt && diff pre.txt post.txt— every removed entry intentional and either redirected or genuinely retired - Submitted to Google Search Console and Bing Webmaster Tools
robots.txt, canonicals, hreflang
- robots.txt diffed line-by-line against pre-redesign — no staging "Disallow: /" shipped to production
- No pages that should be indexed are
noindex; no pages that should not be indexed are missingnoindex(search, filters, cart, account) - Canonical tags resolve to the correct URL — trailing-slash mismatch is the classic self-canonicalising bug
- Hreflang pairs are reciprocal and the URLs return 200, not 301 or 404
Title tags and meta descriptions
- Every page has a unique title tag (50–60 chars) and unique meta description (140–160 chars)
- Templated titles (e.g.
{Product} | Buy Online) not producing duplicates across hundreds of pages
Phase 5: Functionality parity — what worked before still works
This is the section teams most often abbreviate under deadline pressure, and the section that produces the most painful post-launch incidents. The redesign is judged not on what is newly possible but on whether the day-one tasks users came for still complete.
Forms and authentication
- Every form submits and produces the correct confirmation; validation rules identical to pre-redesign
- Submissions reach their destination (CRM, email, database, API) with the original field mapping intact
- Hidden fields and UTM capture survive; multi-step forms have no state loss
- Anti-spam (reCAPTCHA, hCaptcha, honeypot) in place and not blocking legitimate submissions
- Login, registration, password reset, OAuth, and account-management flows all complete end-to-end
E-commerce (if applicable)
- Product pages show correct price, SKU, availability, variants, rating
- Cart actions, guest and authenticated checkout, and payment complete with test cards
- Order-confirmation emails send correctly; discount codes apply
Analytics carryover
- GA4 pageviews, custom events, and conversion events fire on production — verified in DebugView, not assumed from staging
- Server-side tracking continues to fire — cookie-blocked client-side analytics undercount, and 2026 GA4 deployments increasingly rely on GTM Server-Side
- Meta Pixel, Google Ads, LinkedIn Insight, and retargeting pixels present on correct pages
- UTM parameters survive redirects; marketing automation (HubSpot, Marketo) receives form events with correct mapping
- Heat-mapping or session-replay (Hotjar, FullStory, Microsoft Clarity) installed and capturing
Cross-browser and mobile-responsive parity
- Primary flows tested in Chrome, Firefox, Safari, Edge — and on real iOS Safari and Android Chrome devices
- Breakpoints visually diffed at 375px, 768px, and 1024px against baseline screenshots
- No new console errors; no CLS spike on mobile that did not exist before
Phase 6: Before/after Lighthouse and performance comparison
Performance regression is the most easily measured redesign failure mode — and the most easily missed when teams compare lab scores in isolation rather than against the documented baseline. The question is not whether Lighthouse gives you a green score. It is whether the redesigned site is faster or slower than the one it replaced, on the 75th-percentile real-user data Google actually uses for ranking.
Lighthouse 12 weights performance as: TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. Time to Interactive was removed in Lighthouse 10. INP is reported but not yet part of the Lighthouse score — Google measures INP through CrUX field data instead.
Lab tests on staging before launch
- Lighthouse run on homepage, top landing pages, and primary conversion pages — mobile profile, simulated 4G throttling
- Each metric compared against the Phase 1 baseline — flag pages where LCP increased by 500ms+ or TBT by 100ms+
- WebPageTest or PageSpeed Insights side-by-side for before/after
- Total page weight has not ballooned (compare gzipped transfer, not uncompressed)
- Images served in WebP/AVIF with responsive
srcsetand explicit width/height to prevent CLS - JavaScript bundle has not grown without justification — check the new framework wasn't shipped alongside the old one mid-transition
- Third-party scripts load asynchronously and do not block the main thread — the most common post-redesign TBT culprit
- Cache headers set correctly on static assets
Field data after launch
Lab tests miss what real users experience. Set up monitoring before launch so field data has a clean starting point.
- Core Web Vitals report in Search Console configured and the property verified
- Proactive alerts at 80% of Google's thresholds — INP > 160ms, LCP > 2.0s, CLS > 0.08 — to catch regressions before they hit the 28-day CrUX window
- A RUM tool collecting field data from day one (Cloudflare Web Analytics, SpeedCurve, DebugBear, or Vercel Analytics)
For deeper field-vs-lab analysis, the Chrome DevTools performance auditing guide covers reading flame charts for redesign-induced bottlenecks.
Phase 7: 404 handling, soft 404s, and the post-launch crawl
Even a perfect redirect map produces 404s. External sites link to URLs no one remembered; old PDFs surface in search. How the new site handles those 404s — and how Google interprets them — matters for both UX and crawl budget.
404 page hygiene
- The 404 page returns an HTTP 404 status, not a 200 with "page not found" text (the classic soft-404 trap)
- The 404 page is informative — search box, links to top categories, contact options
- Custom 404s log every miss with the referrer — surfaces broken external links worth requesting a fix on
Soft 404 audit
Soft 404s are the most common cause of "redirects working but traffic still dropping" mysteries. Google flags a redirect as a soft 404 when the destination is too different from the origin.
- Two weeks post-launch, check Search Console > Pages > "Not indexed" for the Soft 404 and Page with redirect categories
- For each soft 404, verify the redirect target is the most relevant equivalent — not a thin category page
- For Crawled — currently not indexed, give Google 4–8 weeks to consolidate signals before assuming the page is lost
Re-crawl after launch
- Full Screaming Frog crawl of production 24–48 hours after launch
- Cross-reference with the pre-redesign inventory — every URL that returned 200 should now return 200 or be a 301
- All Redirects report shows no chains, no loops, no 4xx/5xx destinations
- New sitemap submitted in Search Console; URL Inspection used to request indexing on top 10–20 priority pages
Phase 8: Rollback plan and post-launch monitoring
No QA process eliminates all risk. The teams that struggle most with launch incidents are the ones who assumed they would not need a rollback plan. Rehearse it, document it, and have it ready to execute by a single named person on launch day.
Before launch day
- Previous version still accessible in staging or archive, with a known DNS/hostname switch to restore it
- DNS TTL lowered to 300 seconds 48 hours before launch so a rollback propagates quickly
- Database migrations reversible, or a snapshot exists from immediately before launch
- Rollback triggers defined: error-rate thresholds, traffic-drop thresholds, severity levels
- One named person has authority to call rollback and is reachable on launch day
On launch day
- Smoke test immediately: homepage, top three landing pages, primary conversion flow, login
- Server error rates monitored in real time for the first two hours
- Sample of high-traffic redirects tested directly in production
- Analytics events confirmed firing in production via DebugView
- Team on standby for four hours post-launch before declaring stable
The first 30 days
- Daily Core Web Vitals field data check in Search Console
- Weekly organic CTR and impressions check for top 50 pages
- Weekly soft-404 audit until the indexing graph stabilises
- Two-week and four-week conversion-rate reviews against pre-launch baseline
Capturing bugs during redesign QA without losing context
Working through a checklist of this scope across a full website produces a volume of bugs that is hard to manage with ad-hoc screenshots and Slack threads. Reproduction steps get lost. Console errors go undocumented. Network failures that would explain a bug are visible for thirty seconds in DevTools before someone closes the tab.
Crosscheck is a free Chrome extension that captures a screenshot or screen recording, the full console log, every network request, and browser/environment details from a single click — then sends a complete bug report straight to Jira, Linear, ClickUp, GitHub, or Slack. A redirect loop in Phase 2 captured with the full network trace shows the chain a developer needs to see. A form silently failing in Phase 5 captured with the console error and the failing POST request collapses the usual back-and-forth. The best bug reporting tools for 2026 roundup walks through how Crosscheck stacks up against alternatives.
FAQ
How long should a website redesign QA cycle take?
For a site of 50–500 pages with meaningful organic traffic, plan for two to four weeks of dedicated QA between feature-complete staging and launch. Smaller sites compress to one week; enterprise sites with thousands of URLs or multi-region hreflang can run six to eight. The common mistake is treating QA as a final-week sprint rather than a parallel workstream.
What's a normal traffic drop after a redesign?
A short-term dip of under 10% that recovers within two to four weeks is normal — that is Google reindexing. A drop of 30% or more that persists past 30 days indicates a structural problem — usually missing or chained redirects, lost schema, or soft 404s on the redirect targets. Search Engine Journal's 892-migration dataset puts the average recovery at 523 days, so distinguishing transient from structural within the first month matters.
Should we use 301 or 302 redirects during a redesign?
Use 301 for every permanent URL change — which is the entire point of a redesign. Reserve 302s for temporary states (A/B, geo, seasonal). A 302 used by accident tells Google the change is temporary and slows the transfer of ranking signals to the new URL.
Do we still need a sitemap diff if Google can crawl the new site?
Yes. The diff catches what a crawl misses: URLs that fell out unintentionally (a category template that broke), URLs that appeared by accident (faceted filters, dev pages), and inconsistencies between what you submit and what Google discovers. Twenty minutes on the diff saves twenty hours debugging indexation six weeks later.
How do we verify schema survived the migration?
Run Google's Rich Results Test on a sample of each schema type — Article, FAQ, Product, Breadcrumb, Organisation — on staging and on production. Compare the parsed JSON-LD. The common loss patterns: dateModified resetting to the redesign date on every article (which can suppress freshness signals), Author objects collapsing to plain strings, and FAQ schema dropping when the FAQ accordion is replaced.
What's the difference between a redesign and a site migration for QA?
A redesign changes visual design, UX, and possibly information architecture on the same domain. A site migration changes domain, platform, or URL structure. They overlap when a redesign includes a URL restructure or CMS swap. A pure domain migration also needs Search Console's Change of Address tool, which a redesign on the same domain does not.
Start your redesign QA the right way
A redesign should make your site better. The checklist above exists to make sure it does not make it worse. Baseline documentation ensures you know what working looked like. URL preservation and redirect QA protect the equity the old site earned. Schema and OG carryover keep the new site looking the same to Google and to social platforms. Lighthouse comparison and field-data monitoring catch performance regressions before they affect ranking. The rollback plan ensures that if something does break, you can fix it before it costs you.
If you want bug reports from your QA team to arrive with screenshots, console logs, network captures, and environment data already attached, the Crosscheck Chrome extension is free with no usage limits.
