A website audit should be allowed to reach a conclusion the auditor would rather not sell: leave this site alone.

Maybe it needs a sharper service page, a repaired form, cleaner navigation, or measurement that actually works. Maybe the platform has become an operational problem and moving is justified. Maybe the business has changed so much that the old structure can't carry the new job. Those are four different diagnoses, and they should not all end in the same invoice.

Before anyone recommends a redesign, an audit should gather evidence across nine areas — business fit, content and search, conversion paths, lead handoff, measurement, usability and accessibility, performance, technical and maintenance context, and ownership — and its conclusion should be one of five verbs: keep, repair, restructure, migrate, or rebuild. If the verb was chosen before the evidence was collected, what you have is a sales presentation with screenshots.

The question an audit answers is not "is this a good website." It is narrower and more useful: what is stopping this specific site from doing its current business job, and what is the smallest responsible change that fixes it? Answering that means learning what the business sells, who it serves, where inquiries come from, what action matters, and what the site already does well — before deciding what to break.

The nine areas, and what counts as evidence in each

An audit legitimately touches all nine. It should not re-teach each one — several have a dedicated article in this library that goes deeper — so what follows is the evidence to demand in each area and the one trap that hides there.

1. Business fit. A technically clean site can still explain the wrong company. The evidence is a page-level gap list, not "the messaging feels weak": the service that now earns most of the revenue gets one sentence; an abandoned service still owns the navigation; the site never states its service area; every visitor is funneled into one generic form. The trap: a visual redesign cannot correct an undecided offer. It can only make the confusion better-looking.

2. Content and search. Inventory the actual URLs and attach the search evidence to them. Google Search Console's Performance report can show which queries and pages already draw impressions and clicks, split by page, query, device, and date — which is exactly how you avoid deleting a plain-looking page that quietly earns qualified visits. Google is clear about the limits: data can be aggregated differently by property, recent data can be preliminary, and isolating the effect of one change is hard because other things happen at the same time. Use it as evidence, not prophecy. The trap: "the old site looks dated" is not evidence that its pages have no value. The inventory is also the start of a migration map if a rebuild is later justified. (Preserving that visibility through a redesign is its own subject — see "How to Redesign a Website Without Losing the Search Visibility You Already Have.")

3. Conversion paths. Test the route from a visitor's question to a meaningful action, not just the presence of a button. Can a visitor tell whether the service fits? Is the next action visible when they are ready? Do phone and email links work on a phone? Do the error, empty, and confirmation states make sense? "There is a contact button" is inventory; "a person can actually reach and complete the right contact path on mobile and desktop" is evidence.

4. Forms and lead handoff. This gets its own area because the front end can look successful while the business never receives the inquiry. The audit should confirm, with an authorized test on a property the business controls, that a submission is saved to a real record, that the notification reaches the intended person, and that a test record can be identified and removed — and it should write down what each system can actually prove. A success animation proves the interface displayed a success animation; it does not prove an email arrived or that anyone will respond. The trap: do not let captured inquiries be reported as qualified leads or revenue — those are later business outcomes. (The full test procedure lives in "How to Test Whether Your Contact Form Is Actually Losing Leads.")

5. Measurement. Start from business questions, not a traffic screenshot: which actions indicate intent, which system proves a form was captured, which system proves a call connected, and can test and spam traffic be separated from real inquiries. The receipt is a short measurement map — question, metric, source system, owner, limitation. The trap: an event named generate_lead is just an event someone configured; the name does not certify qualification, and a dashboard that reports a phone-link click cannot prove a call connected unless a call-tracking or phone system supplies that. (Why the analytics number and the lead count disagree is covered in "Why Google Analytics and Your Lead Count Don't Match.")

6. Usability and accessibility. Run the automated checks, then don't confuse them with a conclusion. W3C's Web Accessibility Initiative says no tool alone can determine whether a site meets accessibility standards — knowledgeable human evaluation is required — and that WCAG conformance applies to full pages and, where a task spans several pages, the complete process. So a homepage score cannot speak for a booking flow it never exercised. Automated findings should name the element and rule; manual findings should state the task, the expected behavior, the observed behavior, and the severity. The trap: "Accessibility score: 92" is neither a remediation plan nor a conformance claim, and this is an evaluation framework, not legal advice — obligations depend on the organization, jurisdiction, and facts, and those questions need counsel. (What a checker can and cannot prove is its own article: "What a Website Accessibility Checker Can—and Cannot—Prove.")

7. Performance. Read the tools correctly instead of chasing a green number. PageSpeed Insights reports both field data (historical, anonymized real-user data from the Chrome User Experience Report, generally a trailing 28-day window) and lab data (a simulated run useful for debugging), and Google notes the two can differ and that lab data may miss real-world bottlenecks. The audit records which URL and device were tested, whether field data existed for the URL or only the broader origin, and uses the diagnostics to locate a mechanism — a hero image blocking render, a consent tool delaying interaction, an embedded scheduler dominating JavaScript, a slow server. The trap: averaging a few Lighthouse scores into a verdict. The real question is what experience is failing, for whom, and whether the fix is proportionate. (Depth in "What a High PageSpeed Score Really Tells You About a New Website.")

8. Technical and maintenance context. Inspect maintenance evidence without pretending to run a penetration test: platform/plugin/runtime versions and end-of-life components, HTTPS behavior, who owns the backups and whether a restore has ever actually been performed, account roles and stale users, the update process, and whether a staging or rollback path exists. The single most useful receipt here is a successful restore test — "backups are enabled" and "we restored the live site within the agreed process" are not the same statement. The trap: the OWASP Top 10 is an awareness document for common risks; a generic scanner passing it is not proof a site is secure, and deeper security testing should be scoped separately with qualified expertise and written authorization.

9. Ownership, access, and platform constraints. Determine what the business can actually control and move: the domain registrar and registrant, DNS, the hosting or platform account, billing owner, export rights, licenses, analytics and listing access, lead-data export, and administrative recovery. ICANN describes the registrant as the person or entity that registers the domain and manages its settings through the registrar — and a vendor can administer a domain without being the party that should hold the registration, so confirm the exact account rather than accepting "we handle the domain." The trap: if the platform genuinely cannot export important content, preserve URL behavior, or give the business proper access, that is a real reason to migrate; if the platform can do the job and the problem is a neglected page or a broken form, migrating adds risk without fixing the cause. (Ownership terms belong in the contract — see "What a Website Design Contract Should Say About Ownership, Access, and Exit.")

From evidence to a verb

The point of collecting all that is to justify one of five actions — and the honest version of an audit shows which evidence pattern points to which verb, so a buyer can check the reasoning instead of trusting the recommendation. This is also where you can see a sales pitch working: it collects the same observations and routes almost all of them to "rebuild."

Recommendation The evidence pattern that justifies it What a sales pitch does with the same site instead
Keep Site fits the current business job, important paths work, no material failure found. Calls it "dated" and recommends a rebuild anyway.
Repair Structure is sound; failures are bounded and nameable (a broken form handoff, an inaccessible control, a dead tracking event, an outdated claim, one performance bottleneck, a missing account). Bundles the small fixes into a full redesign so the fixes can't be bought on their own.
Restructure Platform is fine, but information architecture, service presentation, or conversion paths need real reorganization. Sells a new platform the business didn't need in order to justify the same content work.
Migrate A concrete platform limit — no export, no URL control, no required integration, no proper access, unsupportable code. Recommends migration on taste ("we prefer X") with no named limit on the current system.
Rebuild The business job, content structure, design, and technical base all need replacement, and a pile of repairs would preserve the wrong foundation. Reaches "rebuild" first and collects evidence to fit it.

The recommendation can combine verbs — keep the platform, restructure the services, repair the form, retire the dead pages. "Redesign" is not the only verb available, and an audit that only knows one is not really auditing.

What the owner should walk away with

An audit is only inspectable if the deliverable lets another competent person follow the reasoning. Before you accept any redesign recommendation, ask to receive:

  1. The question and scope — which properties, pages, systems, devices, and date range were examined.
  2. An evidence inventory — URLs, screenshots, test records, report exports, and account observations, with source dates, sanitized where needed.
  3. Findings tied to consequences — what failed, how it was tested, and why it matters to a customer or the business.
  4. Severity and confidence — which findings are verified, suspected, informational, or outside scope.
  5. The recommended verb — keep, repair, restructure, migrate, rebuild, or a stated combination, mapped to the evidence.
  6. A sequenced plan — what happens first, who owns it, what it depends on, and what proves it's done.
  7. Preservation requirements — the pages, data, accounts, integrations, and search signals that must survive any change.
  8. Open questions — what the auditor could not verify and what access or expertise would resolve it.

If you cannot get that package, you are being asked to authorize surgery from a photograph. The deliverable is the buyer's leverage: it is the difference between a recommendation you can question and one you can only obey.

"But the auditor wants the rebuild"

Worth saying plainly, because it is the real objection: the person auditing the site is often the person who would be paid to rebuild it. That is a genuine conflict, and no amount of tone fixes it. Two things do. The first is the evidence deliverable above — a conflicted recommendation you can inspect is safer than an independent one you can't. The second is whether "keep" and "repair" are actually on the table: a provider who can profitably recommend a small repair, and sometimes does, is showing you their incentives are survivable.

A free look at your site is fine — useful, even — as long as you keep the findings and the findings are specific. The thing to be wary of is a "free audit" whose conclusion is fixed before your URL is typed in, where every site somehow needs the largest package. Free is a price, not a diagnosis.

If someone tells you your site needs a redesign, ask for evidence across the nine areas and ask which verb the evidence supports. The answer may still be "rebuild." At least then you'll be buying a diagnosis instead of a reflex — and you'll have the receipts to prove it either way.

RP's current website offer starts with a free look at your current site — a plain read of where it's leaking, with the findings yours to keep whether or not you ever hire RP. That is the honest shape of the thing: inspect first, then say out loud whether a rebuild is worth it. It is not a substitute for a separately scoped legal, security, or formal accessibility audit, and it is not a promise about what the inspection will find.

Sources