Run this review when a redesign, template swap, redirect map, lead form, navigation change, tracking change, or major content edit has enough blast radius to make memory unreliable. The question is not whether the new version looks better. The question is whether the changed pages stayed findable, trackable, fast enough, accessible enough, and useful enough to buy from.
A before-and-after website change audit answers that decision with evidence instead of memory. New copy, menus, CMS templates, commerce pages, redirects, lead forms, images, analytics tags, and page structure can improve a site, but they can also create traffic drops, broken tracking, slower pages, accessibility regressions, or weaker lead quality.
Last reviewed: April 23, 2026. The search, page-experience, Core Web Vitals, structured-data, and accessibility standards below are summarized from Google Search Central, web.dev, and W3C WCAG. Verify those sources before making high-stakes decisions because thresholds, reports, and search features can change.[1][3][4][5][6]
Short version: run the review before launch, on launch day, after early behavior appears, and again after enough users and field data have accumulated. Compare the same URLs before and after: search visibility, conversion events, crawlability, redirects, Core Web Vitals, accessibility, and lead quality. Keep the edit when business outcomes and technical health hold or improve; fix it when friction appears but the sales path still works; roll back when the change breaks indexing, tracking, checkout, forms, or another path to revenue.
This is also the right frame for AI search. Google’s current guidance for AI features points back to the same foundational SEO and helpful-content practices, not a separate checklist of AI-only tricks.[1][2]
The review should be saved like a change log. Record what changed, when it changed, which URLs were affected, which metrics moved, and whether the result calls for a rollback, a fix, or more observation.
Capture The Baseline Before Editing
Start with the URLs that can hurt the business if they break: the homepage, the top organic landing pages in Google Search Console, the pages that receive paid traffic, the contact or quote page, the main service pages, and any template that will be reused across many URLs. If a template changes 40 location pages, do not test only the page that looks best in the browser.
For search visibility, save Search Console clicks, impressions, average position, top queries, indexed status, and any Page Indexing issues for the affected URLs. For conversion, save analytics sessions, form starts, purchases, booked calls, qualified leads, or other key events if that is the account standard.[7] For tracking QA, use the site’s tag preview, event debugger, or server-side logs before the edit ships, so you know which events fired before the site changed.
For speed, save mobile and desktop results from PageSpeed Insights or a comparable Lighthouse run, including field data when it exists and lab data when field data is not available.[8] PageSpeed Insights reports real-user Core Web Vitals over the previous 28-day collection period, so a same-day test is useful for debugging but not enough for a final verdict.
The Core Web Vitals baseline should use Google’s current good thresholds: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1 at the 75th percentile.[4] INP replaced First Input Delay as a Core Web Vital on March 12, 2024, so old FID screenshots are not enough for a current review.[9]
Use crawl data as well as dashboards. A crawler, a CMS export, or a site-audit snapshot can show title tags, status codes, canonicals, internal links, image alt text, and missing headings before edits begin. In practice, the useful baseline is boring evidence: screenshots, CSVs, and notes that a second person can compare without guessing what the original page looked like.
If there is no saved audit for the current site, capture one repeatable snapshot before the edit starts. The Website Advisor home page is one option when you need a quick record of the live URL; a crawl export, analytics screenshot, or staging checklist can serve the same purpose if it records the same fields you will compare later.
| Review point | What to save or test | Decision rule |
|---|---|---|
| Before launch baseline | Affected URLs, Search Console data, analytics events, crawl data, screenshots, speed tests, and accessibility checks | Do not launch without the same comparison set for the pages that sell or rank |
| Launch-day technical health | HTTP status, redirects, canonical tags, robots rules, noindex rules, sitemap entries, forms, events, and mobile layout | Hotfix or roll back if sales paths, indexing, or tracking are broken |
| Early behavior after 7 days | Sessions, form starts, submissions, checkout starts, crawl signals, indexing signals, and support complaints | Fix friction if users reach the page but stop before the next action |
| Full readout after 28 to 35 days | Core Web Vitals field data, query mix, landing-page conversion, revenue actions, and lead quality | Keep, iterate, or revert based on page-level business outcomes and technical health |
Give images and JavaScript extra attention. The 2024 HTTP Archive Web Almanac page-weight chapter reported a median page weight of 2,652 KB on desktop and 2,311 KB on mobile in October 2024, with JavaScript and images making up large portions of that weight.[10] If a redesign adds a hero video, a carousel, three chat widgets, and uncompressed team photos, the baseline should make that cost visible.
Check Technical Health After Launch
Launch-day checks should start with Google’s minimum technical requirements. Google says a page needs to be accessible to Googlebot, return an HTTP 200 success status, and contain indexable content to be eligible for indexing.[11] If a new template accidentally adds noindex, blocks CSS in robots.txt, or returns a soft 404, the copy quality no longer matters.
Redirects need a separate pass because they affect both users and canonical signals. Google treats HTTP 301 and 308 as permanent redirects and HTTP 302, 303, and 307 as temporary redirects. Lighthouse also flags multiple page redirects when a page has two or more redirects.[12][13] A practical launch rule is simple: important landing pages should resolve to the final 200 URL with zero or one redirect whenever possible.
Canonical tags, sitemaps, and structured data should match the new URL set. Use fully qualified final URLs in XML sitemaps, update canonicals, and keep structured data synchronized with visible content. Google Search supports Schema.org vocabulary and generally recommends JSON-LD when the site can support it.[6]
Accessibility checks should be part of launch health, not a cosmetic afterthought. Test keyboard focus, labels, color contrast, sticky headers, and form errors against WCAG 2.2; many business sites use AA as the working target.[5]
In one redesign audit, the page looked cleaner and speed was roughly unchanged, but the mobile quote form stopped passing submissions into the CRM after a script order change. That was not a wait-and-see issue. The rollback trigger was simple: the page could still get visits, but it could no longer preserve leads.
If the site uses a CDN, edge redirects, app-level routing, or cache rules, check those settings directly instead of assuming the CMS tells the whole story. A redirect chain can live outside the page editor, and a stale cache can make one tester see the fixed page while another still sees the broken version.
Compare Behavior, Not Just Traffic
Traffic can move for reasons unrelated to the edit: seasonality, paid budget, email campaigns, algorithm updates, offline sales activity, or a competitor launch. Compare behavior by page and intent. A service page that loses low-intent visits but gains quote requests may be healthier than a page that gains traffic and sends fewer people to the form.
Use one comparison table per important URL. Keep the math visible so the team can argue about the decision, not the spreadsheet. The sample below is illustrative, not a benchmark; replace the numbers with your own analytics and Search Console data.
| Metric for one service page | Before edit | After 28 days | Readout |
|---|---|---|---|
| Organic sessions | 1,000 | 900 | Traffic fell 10% |
| Form submissions marked as key events | 24 | 30 | Lead volume rose 25% |
| Submission rate | 2.4% | 3.3% | Conversion efficiency improved |
| LCP on mobile field data | 3.2 seconds | 2.4 seconds | Moved from needs improvement to good under the web.dev threshold |
| Top non-brand queries | 12 queries in top 10 | 11 queries in top 10 | Search visibility needs monitoring, not an immediate rollback |
That example points to a measured decision: keep the page live, investigate the lost organic sessions, and protect the speed gain. It does not support a panic rollback because the business outcome improved and the Core Web Vitals result moved in the right direction.
I have seen this pattern after a service-page rewrite: non-brand impressions softened, but form submissions and booked calls improved because the new copy filtered out research traffic. The right decision was to keep the page live, monitor query mix, and protect the speed gain, not roll back a page that was producing better work for sales.
Segment the comparison when the page serves more than one job. For a local service business, compare branded queries, non-brand service queries, map-pack landing pages, and paid landing pages separately. For an ecommerce site, compare product detail pages, collection pages, cart starts, checkout starts, and purchases. For a lead-generation site, compare form views, form starts, submissions, qualified leads, and booked calls.
Watch query mix closely after copy changes. If Search Console shows fewer impressions for the old head term but more clicks from specific buying-intent queries, the edit may be doing its job. If impressions rise but the key event rate falls, the new content may be attracting the wrong audience or hiding the next step.
Set A Review Window
Use different review windows for different risks. Broken forms, missing tags, wrong redirects, and blocked pages should be caught on launch day. Search and Core Web Vitals need longer windows because Google, CrUX, and users need time to collect enough post-launch data.
The master checklist above is the operating rhythm, but severity matters more than the calendar. Do not wait 28 days for a broken checkout, missing lead form, noindex tag on a service page, or analytics outage. Conversely, do not roll back a search-facing copy change after two noisy days if leads, indexing, and technical health are intact.
The final decision should be written in plain language. Keep the edit if the affected pages stay indexable, Core Web Vitals are good or improving, key events hold or rise, and lead quality does not decline. Fix the edit if users still want the offer but the page got slower, the form got harder to complete, or tracking no longer proves what happened. Roll back when a launch breaks the path to revenue or makes important pages unavailable to search engines.
FAQ
Do small copy edits need this review?
No. A paragraph rewrite on a low-traffic page may only need a quick Search Console and analytics note. Use the full review when the edit touches titles, headings, navigation, templates, internal links, redirects, forms, tracking, structured data, or pages that already produce leads or sales.
Can staging data replace live-site data?
No. Staging is useful for layout, accessibility, forms, tags, redirects, and crawl tests, but it usually does not have real Search Console queries, analytics behavior, CrUX field data, or production cache behavior. Use staging to prevent obvious mistakes, then use live data to judge the result.
Should this FAQ get FAQ schema?
Usually no. Google now limits FAQ rich results largely to authoritative government and health sites, so adding FAQ schema just for visibility is unlikely to help and can distract from the real audit.[14]
Sources
- Google Search Central helpful content guidance: https://developers.google.com/search/docs/fundamentals/creating-helpful-content
- Google Search Central AI features guidance: https://developers.google.com/search/docs/appearance/ai-features
- Google Search Central page experience guidance: https://developers.google.com/search/docs/appearance/page-experience
- web.dev Core Web Vitals thresholds: https://web.dev/vitals/
- W3C WCAG 2.2 recommendation: https://www.w3.org/TR/WCAG22/
- Google Search Central structured data introduction: https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
- Google Analytics key events help: https://support.google.com/analytics/answer/9267568
- PageSpeed Insights documentation: https://developers.google.com/speed/docs/insights/v5/about
- web.dev INP Core Web Vital announcement: https://web.dev/blog/inp-cwv-march-12
- HTTP Archive 2024 Web Almanac page-weight chapter: https://almanac.httparchive.org/en/2024/page-weight
- Google Search technical requirements: https://developers.google.com/search/docs/essentials/technical
- Google Search redirect documentation: https://developers.google.com/search/docs/crawling-indexing/301-redirects
- Chrome Lighthouse multiple redirects audit: https://developer.chrome.com/docs/lighthouse/performance/redirects/
- Google Search FAQPage structured data guidance: https://developers.google.com/search/docs/appearance/structured-data/faqpage