A website-health review should not end with a score and a hundred equal-looking warnings. It should identify what prevents customers from completing an important task, what exposes the business to meaningful risk, and what improvement deserves capacity next.

Run this checklist on the pages that matter most: homepage, primary service or product pages, location pages, pricing, contact, signup handoff, and any page receiving significant paid or organic traffic.

Start with the customer job

For each page, write the visitor’s likely job and the business’s intended next action.

Examples:

  • understand whether a service fits;
  • compare plans;
  • find hours and location details;
  • request a quote;
  • create an account; or
  • verify a company’s credibility.

Then test the full path. A good-looking page is unhealthy if the form fails, the phone number is wrong, the signup link lands in an error, or the customer cannot tell what happens next.

1. Message and conversion

  • Does the first screen say what the business helps with and who it is for?
  • Is the primary action specific and visible?
  • Does the page provide the information needed to take that action?
  • Are important claims supported by proof, terms, or a clear explanation?
  • Are prices, commitments, and limitations stated honestly?
  • Does the call to action lead to the promised destination?
  • Can a customer understand the next step without decoding internal language?

Avoid stacking several equal-priority calls to action. Choose one primary path and make secondary paths visibly secondary.

2. Mobile and responsive behaviour

Test on a narrow phone, a larger phone, tablet width, laptop, and wide desktop.

  • No horizontal scrolling at normal zoom.
  • Text remains readable without pinching.
  • Buttons and links are easy to activate without hitting a neighbour.
  • Header and mobile navigation are fully keyboard operable.
  • Tables and comparisons remain understandable on small screens.
  • Forms use appropriate input types and autocomplete attributes.
  • Sticky elements do not cover content or controls.
  • Images reserve their space to avoid layout shifts.

Do not rely only on a simulator. Test at least one real mobile device when the journey is commercially important.

3. Accessibility

Use WCAG 2.2 Level AA as the target, then include people and assistive technologies in testing.

  • The page has one descriptive H1 and a logical heading hierarchy.
  • Navigation, main content, and footer use semantic landmarks.
  • Every interactive control works with a keyboard.
  • Focus is visible and not obscured by sticky content.
  • Link text describes the destination out of context.
  • Informative images have useful alt text; decorative images use empty alt text.
  • Forms have persistent labels, clear instructions, and programmatically associated errors.
  • Status changes are announced to assistive technology.
  • Text and controls meet contrast requirements.
  • Information is not conveyed by colour alone.
  • Motion respects prefers-reduced-motion and does not block use.
  • Content remains usable at text zoom and browser zoom.

Automated tests can find some failures, but keyboard, screen-reader, zoom, and cognitive clarity need manual review.

4. Performance and stability

Google’s Core Web Vitals currently focus on loading, responsiveness, and visual stability. At the 75th percentile of page loads, “good” thresholds are:

  • Largest Contentful Paint (LCP): 2.5 seconds or less;
  • Interaction to Next Paint (INP): 200 milliseconds or less; and
  • Cumulative Layout Shift (CLS): 0.1 or less.

Use field data where available and lab tests to diagnose. The Web Vitals documentation explains the metrics and thresholds.

Check:

  • the main content appears quickly on a typical mobile connection;
  • the hero asset is correctly sized and prioritized;
  • images use suitable dimensions and formats;
  • fonts are limited, self-hosted where practical, and use safe fallback behaviour;
  • non-essential scripts load late or only after consent;
  • interaction does not trigger long main-thread tasks; and
  • banners, embeds, and asynchronous content reserve space.

5. Search and crawl health

Google’s Search Essentials describe the technical and spam-related baseline for eligibility in Google Search. Review:

  • canonical pages return a 200 status;
  • retired pages return the intended redirect, 404, or 410 status;
  • redirects are direct rather than chained;
  • robots.txt is plain text and does not block important assets or pages;
  • the sitemap contains only canonical, indexable URLs;
  • each page has a unique, accurate title and description;
  • canonical links match the production URL convention;
  • noindex appears only where intended;
  • important pages are linked from relevant navigation or content;
  • structured data matches visible content and validates; and
  • images, headings, and links describe the content clearly.

Do not add unsupported ratings, FAQ markup for hidden questions, or location pages that exist only to swap a place name.

6. Forms and handoffs

Submit every form with valid, invalid, empty, and spam-like input.

  • Labels remain visible after typing.
  • Required fields are identified in text.
  • Validation explains how to fix the issue.
  • Errors receive focus or are announced appropriately.
  • The submit button prevents accidental duplicate submissions without trapping the user.
  • Success is shown only after the destination system confirms acceptance.
  • Missing production integrations fail visibly rather than pretending to succeed.
  • Honeypot and rate limiting do not block legitimate keyboard or assistive-technology use.
  • No personal information appears in analytics events, URLs, or logs.

Test external handoffs such as signup, sign-in, booking, and payment. The destination is part of the journey even when it runs on another origin.

  • The legal entity, contact details, pricing currency, and material terms are visible where needed.
  • Testimonials and customer logos are used with permission and correct context.
  • Claims distinguish estimates from measured outcomes.
  • Privacy disclosures name the actual website providers and purposes.
  • Optional analytics does not load before consent.
  • Visitors can choose essential-only use and reopen preferences later.
  • Newsletter consent is explicit and separate from other form purposes.
  • Sensitive information is not requested through a general contact form.

Privacy and consumer-protection requirements vary by jurisdiction. Have qualified counsel review material policies and claims.

8. Security basics

A public-site review is not a security assessment, but it can catch visible gaps:

  • HTTPS is enforced without mixed content.
  • Security headers fit the application.
  • dependencies and platform software are supported and updated;
  • secrets are not exposed in client code, repositories, or source maps;
  • admin and deployment accounts use strong MFA;
  • forms validate input on the server;
  • error messages do not expose internals;
  • backups and rollback are tested; and
  • unused APIs, integrations, storage bindings, and permissions are removed.

The OWASP Top 10 is a useful awareness reference, not a complete testing method. Use qualified security support for high-risk systems or sensitive data.

9. Content operations

  • Every factual owner, price, hour, feature, and legal statement has an internal source of truth.
  • Material pages have a named owner and review date.
  • Outdated content is updated, merged, redirected, or retired.
  • Images have documented rights and no unnecessary metadata.
  • Broken internal and external links are monitored.
  • The site has a rollback path for releases.

A healthy site is maintained, not merely launched.

Prioritize the findings

Put every finding into one of four lanes:

  1. Urgent: revenue interruption, security exposure, materially wrong information, inaccessible core journey, or legal/compliance risk.
  2. High value: clear customer friction or discoverability problem with strong evidence.
  3. Maintain: routine updates, content freshness, and preventive work.
  4. Scope: larger redesign, migration, specialist assessment, or custom project.

Attach the evidence, owner, required access, approval, and definition of done. The checklist becomes useful when it produces a ranked action backlog and verifiable completion—not when it produces the longest report.