Auditing a client's website and sharing the report

A client reads the report without the person who ran it. Every finding has to carry its reason, its evidence and what to do about it.

Scores invite comparison with other tools and other sites, which they cannot support; the findings list is what the work is planned from.

Results are classified as passing, warning, failing, informational or not verifiable, and the last category is the one that protects the report's credibility.

Confidence is carried per finding — verified directly, detected or inferred, or not publicly verifiable — and the score weights results by it.

Scan the client's site with a page limit suited to its size; the coverage figure then tells both of you how much of the site the findings describe.

Where parts of the site are protected — an account area, a staging preview — analyse them from a signed-in browser rather than expecting the crawler to reach them.

A single deeper audit of up to 250 pages, with every check and a full report, exists as a one-off purchase for engagements that need one audit rather than a subscription.

Keep the scan: it is the baseline the next engagement will be compared against.

Where the client's site has several environments or subdomains, scan the ones they asked about and say which ones were left out.

A report share is a random, revocable token pointing at one scan. It grants read-only access to that report and nothing else — no dashboard, no account data, no other scan.

A share can carry an expiry date, and it stops working the moment it is revoked.

Shared report pages are marked `noindex`, so a link forwarded around an organisation does not end up in search results.

A PDF version of the report exists for clients who need a document to attach, archive or print.

Team members can be invited to the account when several people run and review audits together.

Start from the findings with an observable consequence for visitors or for security, not from the score.

Separate what the audit verified from what it could not: backups, internal monitoring, enforcement of multi-factor authentication and similar items are reported as not verifiable by design.

Point out findings the client cannot fix alone — a hosting provider's header, a third-party script, a platform limitation — so the plan assigns them to the right party.

Agree on a rescan date. A comparison between the two runs is the clearest possible evidence that the work was done.

An external audit is not a penetration test, a legal compliance review or a performance guarantee, and should not be sold as one.

It does not prove the absence of problems on pages it did not reach or behind protections it did not cross.

Accessibility results cover what automated checks can establish, which is a part of conformance, not all of it.

Stating these limits in the delivery is part of the deliverable, not a disclaimer.

The report separates the findings still to fix from the checks that pass, and lists separately the checks that could not be verified and those that have become verifiable since an earlier scan.

Each finding carries its evidence — the header, record, file or markup that produced it — so a developer on the client's side can verify it independently.

The PDF is generated in the language selected in the application, so a report prepared for a client can be delivered in that client's language where it is supported.

A detailed audit view presents the audit in full, for clients whose own team wants to review the whole picture rather than the summary.

A share is checked on every visit: once it is revoked, or its expiry date has passed, the link no longer opens the report.