A website audit is an investigation of whether a website works for its intended visitors and exposes its important information clearly. It connects observations to decisions: which page failed, what evidence explains the failure, who can change it and how the result will be verified. A useful audit is therefore more than a score or a long list of warnings. It is a prioritized maintenance plan grounded in the actual pages, responses and user journeys you inspected.
Start by defining the website's purpose. An appointment site needs reachable service information and a reliable booking route. A publication needs discoverable articles, understandable navigation and readable content. A shop needs working categories, product information and checkout. These purposes change the severity of a finding. A missing decorative image and an unavailable checkout cannot sensibly receive the same priority simply because both requests returned an error.
Define a sample before running checks
Write down the public origin, the important page types and the journeys visitors must complete. Include the homepage, a category or service page, a detailed page, a contact route and an intentionally missing URL. For a multilingual site, include examples from each language. Check both a normal desktop viewport and a narrow mobile viewport. This small inventory makes the audit reproducible and helps distinguish a whole-site defect from a problem on one template.
A single-page tool inspects the submitted page and whatever bounded resource samples it collects. It cannot establish that every URL on the domain works. Use the complete page audit for broad observations on a representative URL, then use the site crawler to discover and inspect multiple pages. Record the crawl starting point and any page limits alongside the findings. A URL outside that sample remains unverified, even if the report looks healthy.
Check whether pages can be reached
Begin with the connection and response. Does the hostname resolve? Does HTTPS connect successfully? Does the requested path serve the expected content? Note the initial URL, any redirect destinations and the final HTTP status. A page that looks normal in an already-open browser may still have a broken direct URL or depend on a cached application shell. Open important paths directly as well as through the website's own navigation.
Investigate failures before rewriting content. A DNS error concerns name resolution; a timeout may involve networking or server responsiveness; a not-found response concerns the requested resource. These are different observations with different owners. The HTTP status guide explains how to interpret the response category. Preserve the exact failing URL, including a relevant query string, while removing private tokens before sharing evidence with anyone else.
Inspect discovery and indexing separately
Once a page is reachable, ask how people and crawlers find it. Follow ordinary internal links from the homepage and relevant category pages. Review whether the sitemap lists intended public pages and whether robots directives permit the crawling you intend. These checks should agree with the page's canonical declaration and indexing policy. A reachable URL is not automatically a page that should appear in search results.
For example, a public article may need crawl access and an indexable response, while an internal search-results page may intentionally carry a noindex directive. Do not remove every restriction just to improve an audit score. The indexability checker brings several signals together, and the robots.txt explanation clarifies why blocking requests and controlling indexing are separate tasks. Search systems still decide what to index; technical eligibility is not a promise of inclusion.
Review the page as a document
Read the title, main heading, introductory explanation, section headings and image alternatives together. Can a visitor tell what the page offers and what action to take next? Is important information present in text, rather than available only in a promotional image? Does the page explain unfamiliar terms and answer the question implied by its title? Metadata cannot compensate for a page that fails its actual purpose.
Use the SEO audit to identify inspectable page signals, then read the content yourself. Compare sibling pages when checking duplicate titles or near-identical descriptions. Similar wording is sometimes appropriate, but repeated templates should not erase the distinction between genuinely different services or articles. The content-quality checklist offers an editorial review that complements mechanical HTML checks.
Examine performance and public security settings
Performance work should connect a measurement to a visitor problem. Record the device, network conditions, cache state and measurement source. A server-response time is not the same as complete loading speed or responsiveness after the page becomes interactive. Use the speed checker for its stated delivery observations, and a suitable browser or field-data tool when investigating rendering and real-user experience.
Public security-header observations also need context. Missing or unexpected policies deserve review, but they do not prove a website has been compromised. Before changing a policy, identify which application, hosting service or CDN produces the response. A restrictive change can break legitimate scripts, images or embeds. The security-headers overview describes the purpose of common controls and why configuration changes should be tested on representative pages.
Turn findings into work that can be verified
Keep one record per underlying problem. Include affected URLs, the observed condition, expected behavior, likely source, responsible person and a concrete verification step. Group repeated instances when they come from the same template, while retaining enough examples to check the scope. Prioritize broken essential journeys and unintended access or indexing problems before cosmetic improvements. Mark uncertain findings as needing investigation instead of presenting a guess as a diagnosis.
An illustrative record might say: the contact link on five service pages points to an old path; the destination returns 404; update the shared navigation component; then follow the link from those templates and confirm the intended contact page loads. This record is more actionable than “fix broken links.” After deployment, repeat the original request and test the visitor journey. Save the before-and-after evidence in a local report, and use the repeat-scan method for an organized comparison.
Decide what the audit does not establish
A public website audit does not replace a private application-security review, an accessibility assessment involving real users, analytics interpretation or an inventory of authenticated business workflows. It can reveal useful evidence and direct further investigation. It cannot prove that untested pages, private accounts or future deployments are safe. State those boundaries in the report so its readers understand both the findings and the limits of the sample.
Revisit the inventory after a redesign, migration, hosting change or substantial content release. Keep a short maintenance checklist for the most valuable journeys and use the same representative pages when comparing results. An audit becomes useful when it produces a tested improvement and an understandable record of what changed, rather than an impressive count of issues with no clear next action.
Compare an initial website review
| Approach | Evidence | Useful for |
|---|---|---|
| Quick page check | Reachability and core page observations | A first pass on a representative URL |
| Complete audit | All available page registry evidence | A broad diagnosis of that page |
| Browser walkthrough | The visitor journey and interactions | Confirming what a person can actually complete |
Using CrawlNFix for this task
CrawlNFix makes the initial public check available free, without requiring a website account or a paid plan. Use it whenever you need to review a real change, then keep the downloaded evidence with your work. The URL-based check needs a connection; for saved-content analysis, the separate keyword comparison can work locally after it has loaded. These workflows serve different questions and should not be presented as interchangeable scans.