Website Audit Checklist Before A Redesign

A useful audit decides what to protect first

A redesign should not start by deleting pages, rewriting navigation, or replacing the homepage without knowing what already works. The audit should identify which assets need protection before the new design plan is approved.

That means looking beyond visual taste. A useful audit connects search visibility, page structure, buyer objections, proof, forms, performance, and maintenance risk into one action list.

• Current URL inventory and sitemap comparison
• Pages with traffic, links, enquiries, or sales value
• Messages, proof, FAQs, and pricing cues that buyers need
• Technical SEO, metadata, schema, sitemap, and robots signals
• Forms, analytics, accessibility, speed, and mobile layout risks

What the audit should include

The strongest audit separates evidence from opinion. It records what the site currently says, what users can do, what search engines can crawl, and which changes would create launch risk.

The output should be specific enough to guide scope. A redesign team should know which pages to keep, improve, merge, redirect, remove, rewrite, or rebuild.

• UX review: navigation, first viewport, CTAs, mobile layout, and form routes
• Content review: page jobs, headings, service hierarchy, proof, FAQs, and buyer fit
• SEO review: titles, descriptions, canonicals, internal links, schema, sitemap, and robots
• Performance review: hero media, images, fonts, scripts, layout stability, and third-party code
• Launch review: redirects, noindex rules, analytics, form delivery, browser QA, and handover

How to turn findings into redesign scope

An audit is only valuable when it changes the plan. Findings should be grouped into blocking issues, redesign requirements, content inputs, proof gaps, and post-launch improvements.

This prevents the redesign from becoming a visual refresh that ignores search risk, broken enquiry paths, weak content, or missing evidence.

• Must fix before launch
• Should fix during the redesign
• Can improve after launch
• Needs client evidence or approval
• Should not be claimed until proof exists

Weak audit warning signs

A weak audit produces a generic score and a list of disconnected tips. A useful audit explains what matters for the business, which routes carry risk, and how the next website should be scoped.

Be cautious when an audit ignores the current URL set, skips forms and mobile checks, recommends new pages without proof, or promises rankings from template-level fixes.

Website audit scope map

• Inventory: current URLs, sitemap entries, noindex pages, redirects, and pages with visible commercial value.
• Buyer journey: homepage first viewport, service paths, proof placement, pricing cues, contact routes, and form states.
• Search: metadata, canonicals, schema, internal links, crawlable content, robots, and sitemap alignment.
• Technical quality: mobile layout, accessibility basics, image handling, scripts, fonts, Core Web Vitals risk, and browser QA.
• Scope output: keep, improve, merge, redirect, remove, rewrite, or rebuild decisions with owners.

Common mistakes to avoid

• Using an automated score as the whole audit instead of connecting findings to redesign decisions.
• Changing URLs or deleting pages before checking traffic, links, enquiries, and content value.
• Publishing audit recommendations that require proof, testimonials, offices, or outcomes the business cannot support.

What 760 Studios would review first

• Current URL and sitemap risk
• First buyer-journey gap to fix
• Which audit findings should become redesign scope

Studio note

760 Studios connects brand, content, UX, frontend quality, and search foundations so the recommendation is tied to the commercial job of the site, not a generic checklist.

Implementation notes for this guide

A useful implementation turns website audit checklist into a route-level decision. The content owner should know which page answers the query, which buyer stage it supports, what proof is visible, which service or pricing page it links to, and how the next action is measured. Without that connection, even a good article can become isolated content that does not help a buyer or strengthen the wider site.

Before publication, check the rendered page rather than only the draft copy. The title, meta description, H1, intro, article sections, schema, internal links, sitemap entry, and CTA should all describe the same purpose. If the article supports a commercial service, the service route should link naturally from the guide and the guide should link back to the relevant service, pricing, work, or project-start path.

Evidence and launch checks to connect

• Confirm the article has one clear buyer question and one clear route owner.
• Connect the guide to at least one current service page and one next-step route.
• Use method proof, checklists, screenshots, or work records only where they are visible and supportable.
• Check metadata, canonical URL, structured data, sitemap inclusion, and mobile layout after build.
• Review the page after launch against search queries, internal-link paths, and enquiry quality.

This is how 760 Studios treats guide content as part of a larger decision system: each article should help someone compare options, reduce risk, and move into a practical next step without depending on exaggerated proof or search promises.