A website can load correctly for its owner while a search crawler sees an empty page, a keyboard user cannot complete a form, or a certificate is close to expiry. These failures belong to different systems. One score cannot explain all of them.
Start with a precise question: can our intended customer discover this page, understand the offer and complete the important task safely? A full audit supplies evidence for parts of that question. It still needs a person to interpret the business context and test the complete journey.
What this audit covers
What can be measured
- Available security modules, bounded SEO and AI content samples, public integration signals, static accessibility checks and selected-device performance measurements.
- Findings and positive checks with the evidence, target and measurement scope returned by each engine.
What it cannot prove
- An automated result is not an exhaustive penetration test, complete accessibility assessment or guarantee of search visibility.
- A finished runner may have partial or unavailable measurements; inspect coverage separately from completion.
Available audits, security modules and crawl allowances depend on the connected plan and remaining usage. Check the current pricing page; protected testing also requires appropriate target authorization.
1. Choose the question before choosing the scan
Define the pages and user journey that matter: a product landing page, pricing page, signup route and support route are a useful starting set for a subscription business. A shop may instead prioritize a category, product, cart and checkout. Record the exact hostname, environment and device.
Agree who owns the target and which tests are authorized. Public observation and active security testing have different consequences. The OWASP Web Security Testing Guide provides a broader security testing framework; an automated audit covers only part of it. Keep authenticated workflows and destructive test scenarios in a separately controlled review.
2. Understand the six audit areas
| Area | Useful question | Important boundary |
|---|---|---|
| Security | Which exposed settings or services need investigation? | Selected modules and authorization determine coverage. |
| SEO | Can crawlers discover and interpret sampled content? | A bounded HTML crawl does not prove indexing. |
| AI visibility | Is content clear, accessible and attributable? | Readiness is not a live AI citation measurement. |
| Integrations | Which public integration signals appear? | Script presence does not prove event delivery. |
| Accessibility | Which static markup barriers are detectable? | Keyboard and assistive-technology testing remain necessary. |
| Performance | What delays loading or interaction? | Lab runs and available field data answer different questions. |
Read these areas together. A third-party widget can affect performance, accessibility and data collection at once. Fix the shared cause instead of creating three disconnected tickets.
3. Rank findings by evidence and impact
The priorities below are illustrative triage decisions, not promises that a particular scanner assigns these exact severities. Record the affected page, observed value, expected behavior and how to reproduce it before assigning an owner.
| Illustrative observation | Priority in context | Evidence to request |
|---|---|---|
| Public page exposes an actual secret | Critical if usable; contain immediately | Redacted location, exposure scope and credential owner |
| Commercial page unintentionally has noindex | High for acquisition | Response metadata and intended indexing policy |
| Required form field lacks a usable label | High when it blocks a core task | Markup plus manual interaction test |
| Unused social preview metadata | Low or informational | Relevant sharing surface and current preview |
Severity is not business priority by itself. A modest issue on every checkout can deserve attention before a severe-looking advisory on an unused staging route.
4. Turn a finding into an executable repair
- Reproduce: inspect the exact URL and response, using the reported device or crawler assumptions.
- Find the source: distinguish application markup, hosting, CDN rules and third-party behavior.
- Make the smallest coherent correction: repair the responsible template or policy so equivalent pages improve too.
- Define acceptance: write the observable condition that will prove the issue resolved.
- Assign ownership: include an accountable person, affected pages and release window.
For a hypothetical blank pricing page, “improve SEO” is not a useful ticket. “Make the public plan content available to the renderer while keeping private API routes protected; confirm the plan table appears” is testable. The Google JavaScript guidance explains why the original response and rendered content can differ.
5. Retest the repair, then the user journey
Repeat the original check under comparable conditions, and record the new evidence beside the old result. Do not compare a desktop home-page run with a mobile checkout run and call the difference a regression. If a dependency failed, retry the missing measurement before judging the site.
- Confirm the reported URL now satisfies the acceptance condition.
- Check another page that shares the changed template.
- Complete the main action with a keyboard and at a narrow viewport.
- Check errors, validation messages and loading states.
- Record remaining manual review and intentionally excluded areas.
For accessibility, the W3C preliminary checks are a practical manual starting point. A clean automated result does not replace that work.
6. Avoid the reassuring but misleading conclusions
complete: true means a workflow finished; it does not mean every possible condition was measured or passed. Read coverage, unavailable providers, skipped modules and sampled URLs. “Not applicable” is different from “passed,” and an unreachable page cannot supply evidence of good configuration.
Do not optimize only for a composite score. Removing a useful feature can raise a performance score while damaging the product. Likewise, adding schema does not guarantee rankings and an AI readiness score does not show how often assistants cite you. Treat a score as a triage aid, and preserve the specific observations that justify a change.
7. Establish a repeatable review rhythm
Save a baseline for important templates before a substantial release. After changes to hosting, consent, navigation, authentication or page templates, repeat the relevant audits and the affected journeys. Use comparable targets and settings so the result tells you something about the change.
A team handoff should contain four things: confirmed defects, verified repairs, unavailable measurements and manual follow-up. Track successful customer actions alongside technical measurements. The Web Vitals guidance helps distinguish user-experience metrics from a general quality score.
Start with one business-critical public page. Review the scope, fix the most consequential evidenced issue, and rerun that check. For assistant-based access, use the Sitelemetry MCP setup guide; compare the current audit allowances on pricing.
Common questions
Does a full audit test every page?
No. Crawl limits, reachable content, selected modules, authorization and provider availability define the actual scope. Read the sampled URLs and coverage in the result.
Is a high overall score proof that the website is safe?
No. A score summarizes the checks that produced measurements. It cannot rule out untested vulnerabilities, broken authenticated journeys or manual accessibility barriers.
Should every informational finding be fixed?
Not necessarily. First establish whether the observation describes a defect for your website. Record accepted behavior so the same advisory does not repeatedly distract from important work.
Sources & further reading
- OWASP Web Security Testing Guideowasp.org
- Google: JavaScript SEO basicsdevelopers.google.com
- W3C: preliminary accessibility checkswww.w3.org
- web.dev: Web Vitalsweb.dev
Written by the Sitelemetry team, checked against the product’s audit scope and linked primary sources. Examples are illustrative unless an observed case is explicitly identified.
