Auditing a website redesign

Old templates accumulated fixes nobody documented: a canonical tag added after an incident, alternative text written for a campaign, a structured data block a plugin injected.

A new theme or component library starts from zero on all of them, and the loss is invisible in a visual review.

Redesigns also change performance profiles — heavier hero images, new fonts, a script framework — which the old site's measurements no longer describe.

When URLs change too, the redirect work is a separate job with its own question page; this page covers what changes even when they do not.

Scan the current site first. The baseline does not have to be clean; it has to exist, because every later comparison needs it.

If the old site is already gone, public web archives hold captures of most pages, which is enough to recover titles, canonicals and structured data at a point in time.

Check each new template on a staging URL before launch. Staging behind a password can be analysed page by page from a signed-in browser.

Pay particular attention to the templates that carry the most pages — article, product, category — since one template fault multiplies across all of them.

Confirm the staging directives that keep the new site out of search are the kind that will be removed at launch, and plan their removal explicitly.

Metadata: titles, meta descriptions, canonical URLs, language declarations and Open Graph properties, template by template.

Structure: one H1 per page, heading order, navigation and footer links, internal links that still resolve.

Structured data: blocks that existed before and are still present and valid.

Images and accessibility: dimensions, alternative text, responsive candidates, contrast, form labels, focus visibility.

Loading: page weight, render-blocking resources, layout shift and the largest element, which a new hero design changes more than anything else.

The comparison between the baseline and the post-launch scan classifies each finding: new, regression, resolved, persisting, and several states for what could not be observed.

Regressions and new findings on high-traffic templates are the redesign's defects; persisting ones are the old backlog that simply moved over.

Resolved findings are the redesign's wins, and worth confirming rather than assuming.

Compare scans with similar coverage. A new navigation that exposes more or fewer pages changes what a crawl reaches, and a finding on a page no longer reached is not a fix.

Rescan after the first round of fixes to confirm them, then keep a recurring scan for the weeks when content editors meet the new templates.

Watch for pages that fell out of the navigation and now have no internal links — redesigns orphan pages quietly.

Field performance data takes weeks to reflect a change; laboratory measurements are the early signal.

Keep the baseline report: it is the reference when someone asks later what the redesign changed.

Each crawled page is classified by type — home, product, category, article, contact, pricing, legal and the rest — with a confidence and the signals that produced it.

Grouping findings by page type turns a long list into a list per template, which is how redesign work is actually assigned.

A finding present on every page of one type and on no other is a template defect, fixed once in the template rather than page by page.

The comparison also reports, per category, the share of verifiable checks passing before and after, which shows whether the redesign improved accessibility or loading overall even when individual findings move both ways.

Check at least one page of each type the site uses; types with a single page — the home page, the contact page — are the ones a sampled review forgets.