slop auditA website audit report example is useful when it shows more than a score. A developer should be able to see the tested URL, the evidence behind each finding, the likely impact, the owner, and the smallest fix that can be verified before launch.
This guide uses an illustrative public marketing page to show that format. It is a sample, not a scan of the example page. For a live report, open the Slop Audit example report, then run an audit against a public URL you control.
What this website audit report example includes
A practical report answers five questions in order:
- What was tested? Record the submitted URL, final URL, response status, date, viewport, and release or commit.
- What was measured? Separate response, HTML, crawler, browser, accessibility, performance, and content observations.
- What is blocked? Call out broken routes, inaccessible actions, missing crawl signals, or mobile conditions that stop the main task.
- What should happen next? Give every warning an owner, priority, effort, and verification step.
- What could not be tested? Keep incomplete evidence visible instead of turning an unavailable measurement into a failure.
That structure makes the report useful to both a developer fixing a release and a reviewer deciding whether the remaining risk is acceptable. The guide to how Slop Audit audits a public website explains the four groups of checks and the evidence each group can produce.
Example scope and test conditions
The following sample describes a hypothetical page at https://example.com/. A real report should replace every value with an observed result.
Submitted URL: https://example.com/
Final URL: https://example.com/
Release: marketing-site 2026.09.18 / commit abc1234
Tested at: 2026-09-18T16:30:00Z
Response: 200 OK, text/html
Viewports: mobile 390px and desktop 1440px
Coverage: 92% of applicable checksThe scope is one public URL and the resources that the bounded audit can reach from it. It does not include authenticated screens, private APIs, every route on the domain, or a claim that the page is secure, legally compliant, accessible to every person, or guaranteed to rank. State those boundaries near the top so the reader does not mistake a focused pre-launch check for a complete engineering or compliance review.
Example executive summary
Decision: ship after the primary action and canonical URL are fixed. The page returns HTML and exposes the intended product explanation, but two findings can interrupt the release path. The mobile navigation covers the primary action at the narrow viewport, and the HTTP URL does not redirect directly to the HTTPS canonical URL. The title, description, robots policy, and sitemap entry are present. Browser evidence is complete for both requested viewports; payment processing and authenticated workflows were not tested.
The summary is short because the details belong in the findings. It names the decision, the blockers, the evidence boundary, and what remains outside scope. Avoid writing “SEO score: 82” without explaining which checks contributed to that number.
Example score and coverage summary
Slop Audit keeps readiness and visible-content risk separate:
- Production Readiness: how well the public page loads, works, explains itself, and exposes useful trust and machine-readable signals. Higher is better.
- Slop Risk: visible patterns such as generic claims, weak proof, placeholder content, template residue, or an unclear action. Lower is better. It is not an authorship detector.
- Coverage: the share of applicable checks that actually ran.
- Confidence: how strongly the completed evidence supports the result.
An illustrative summary might read:
Production Readiness: 78 / 100
Slop Risk: 24 / 100 (moderate)
Coverage: 92%
Confidence: medium
Strong signals: final HTML, title, metadata, robots policy, sitemap entry
Priority gaps: canonical redirect, mobile primary action, proof for pricing claim
Unavailable: authenticated checkout and server-side analytics validationThe numbers help sort work; they do not replace the findings. A high score with low coverage is not the same release decision as a high score backed by a complete run.
Example findings from highest priority to lowest
The findings below show a useful website audit report format. They are intentionally concrete and keep observed evidence separate from a recommended fix.
Priority 1: the public URL has a redirect-chain problem
Outcome: warning · Owner: platform or deployment · Effort: quick
Observed: http://example.com/ redirects to http://www.example.com/, which then redirects to https://example.com/.
Evidence: The response sequence contains two 3xx hops before the final 200 response. The page canonical points to the HTTPS apex, but the old host remains linked in one campaign email.
Impact: Every extra hop adds failure and latency risk. More importantly, the redirect target, canonical tag, sitemap, internal links, and shared URLs do not describe one unambiguous page version.
Fix and verification: Choose the HTTPS host, redirect every known variant directly to it with one permanent redirect, update internal links and campaign templates, then repeat the request with headers visible. Google's canonicalization guidance explains why redirects and canonical links should agree.
Priority 1: the primary action is covered on mobile
Outcome: fail · Owner: frontend · Effort: moderate
Observed: At a 390px viewport, the fixed navigation overlaps the “Start free” action after the menu opens.
Evidence: The browser observation records the viewport, the overlapping element, and a screenshot region. Keyboard focus can move to the control, but the control is not visually usable until the menu is dismissed.
Impact: The page's first task is blocked for a meaningful mobile state. A visitor can understand the offer but cannot reliably begin it.
Fix and verification: Make the menu dismissible, keep the action inside the viewport, and add a browser assertion for the open-menu state. Repeat the mobile and desktop paths, then save the release identifier beside the passing evidence. The mobile website testing routine covers the focused viewport pass.
Priority 2: the title and description do not match the page promise
Outcome: warning · Owner: content or SEO · Effort: quick
Observed: The visible heading says “Inventory planning for small teams,” while the title is “Welcome” and the description only says “The best tools for business.”
Evidence: The report records the rendered <h1>, <title>, and meta description together. They identify different subjects and do not explain the audience or outcome.
Impact: Search previews and shared links can lose context even when the page itself loads. A vague title also makes it harder for a reviewer to confirm that the indexed result matches the page.
Fix and verification: Write a specific title and description that match the visible page, audience, and outcome. Keep the canonical URL consistent with the final response. Google's title-link documentation and snippet guidance describe how these elements support useful previews without guaranteeing the exact text shown in results.
Priority 2: the main claim has no verifiable proof
Outcome: warning · Owner: product marketing · Effort: moderate
Observed: The page claims “Cut planning time by 70%” but provides no study, customer example, method, date, or link to supporting evidence.
Evidence: The report quotes the visible claim and records that no supporting proof appears in the inspected page or linked documentation.
Impact: A reader cannot judge whether the claim applies to their situation. Unsupported specificity can reduce trust even when the product itself works.
Fix and verification: Replace the number with a supported statement, or add the evidence and its scope. Keep the owner and source in the release task, then audit the public page again to confirm the proof path is visible.
Priority 3: the page omits a support or ownership path
Outcome: warning · Owner: product · Effort: quick
Observed: The page asks visitors to upload data but does not link to support, privacy information, or an explanation of what happens next.
Evidence: The report records the upload action, the visible surrounding copy, and the absence of a reachable support or policy route.
Impact: Visitors have no clear route for questions or concerns, and the reviewer cannot verify the promise made by the action.
Fix and verification: Add a concise explanation, a support route, and the relevant policy links. Test those links from the same public URL and record the final responses.
Copyable website audit report template
Use this compact template in a release issue, pull request, or handoff document. Keep evidence beside the claim it supports.
# Website audit report
- Submitted URL:
- Final URL:
- Release / commit:
- Tested at:
- Viewports:
- Response and content type:
- Coverage:
- Confidence:
- Decision: ship / fix then ship / do not ship
## Executive summary
- What works:
- Release blockers:
- Important limits or unavailable checks:
## Findings
### [P1] Short finding title
- Outcome:
- Owner:
- Effort:
- Observed:
- Evidence:
- Impact:
- Fix:
- Verification:
## Accepted risk
- Finding:
- Why it is accepted:
- Owner:
- Review date:The template is intentionally small. A report should make the next engineering decision easier, not bury a few important failures in a long inventory of low-value observations.
Turn the sample into a launch and regression routine
Use the website launch checklist for developers before the first production release. It covers reachability, mobile behavior, machine-readable files, the primary action, and the final handoff.
After launch, save the accepted report as a baseline. The website regression testing checklist shows how to compare response headers, metadata, crawl controls, browser states, accessibility observations, and performance measurements after a deployment. The canonical URL and redirects guide is useful when a release changes hosts or paths.
Do not treat every difference as a regression. A browser run can be unavailable, a dynamic region can change intentionally, or a third-party request can fail outside your ownership. Mark the comparison incomplete until compatible evidence confirms a change.
What Slop Audit can and cannot verify
Slop Audit accepts a public URL and reports the evidence available from the response and bounded browser checks. Depending on runtime capacity, it can inspect reachability, headers, metadata, crawler files, links, rendered mobile and desktop behavior, accessible names, visible copy, trust paths, and selected performance clues. Findings include the observed value, impact, remediation, and coverage.
It does not log in, bypass access controls, crawl every route, certify WCAG or security, prove analytics attribution, identify who wrote a page, or promise a search position. Treat an unavailable check as missing evidence. Keep your application, integration, accessibility, security, and analytics tests in the release process as well.
For a related content pass, use the website content audit checklist to review placeholders, claims, proof, support paths, and calls to action before you publish.
Run the report against your URL
If you need a concrete pre-launch handoff, review the example report first. Then run a Slop Audit against the public URL you plan to share, inspect the evidence behind each priority finding, and attach the resulting report to your release task.
The best website audit report example is not the one with the biggest score. It is the one that tells the next person exactly what was tested, what remains risky, and how to verify the fix.