An illustrative Seryvon audit report
This worked example shows how to read a website audit and turn it into a reviewable action. All scores and findings below are fictional teaching examples. They are not an audit of seryvon.com, a customer result, a benchmark or a literal exported report.
Start with scope and provenance
A useful handoff identifies the audited origin, collection time, engine revision, crawl limits, active connectors and measurement profile. State which templates were inspected and which evidence is unavailable. Retain the report and relevant artifacts so another reviewer can understand a finding without relying on a screenshot of an overall score.
For this fictional scenario, imagine a small public documentation site with an important setup guide and a product overview. The team wants to improve access to those pages and verify that the setup instructions are readable in the initial HTML. No real crawl was performed for this example.
Read the score with coverage
The following hypothetical pillar scores are already adjusted for coverage. Because all five pillars contribute, the weighted global result is 75.76. The percentages are the default pillar weights, not each pillar's measured coverage.
| Pillar | Score | Weight |
|---|---|---|
| SEO | 80 | 30% |
| GEO | 70 | 22% |
| GSO | 72 | 18% |
| AEO | 84 | 15% |
| ASO | 72 | 15% |
80 × 0.30 + 70 × 0.22 + 72 × 0.18
+ 84 × 0.15 + 72 × 0.15 = 75.76Coverage is a separate measurement. For example, three equally weighted eligible checks with scores of 80, 100 and one unmeasured result produce a measured average of 90, coverage of approximately 66.67% and a coverage-adjusted score of 60.00. Consult the methodology before interpreting a low score as a confirmed site defect.
Connect a finding to supporting evidence
Illustrative finding: the setup guide's instructions appear only after JavaScript runs. A convincing report would retain the raw response and rendered content, identify the affected URL and explain how the difference was detected. A low parity signal alone should prompt inspection; it should not justify rewriting unrelated pages.
Proposed action: make the prerequisites and installation steps available in the initial HTML. Assign the task to the documentation owner and developer responsible for rendering. Preserve headings and links so the procedure remains understandable to readers as well as crawlers.
Define acceptance before making the change
- Fetch the deployed guide and confirm the essential instructions are present before JavaScript.
- Open the page in a browser and check that commands, headings and navigation remain readable.
- Rerun an audit with the same scope and comparable configuration.
- Review the finding's evidence and coverage, not only the aggregate score.
This establishes whether the targeted technical change worked. It does not establish an AI citation, improved rankings or additional leads. Those outcomes need their own observations and an appropriate comparison period.
Prepare a useful handoff
Include a short priority list, the evidence for each item, an owner, acceptance criteria and unresolved measurement gaps. Label illustrative material and estimates clearly. Avoid presenting missing connector results as passes. Store the report where the team can retrieve it for the next review.
Run your own evaluation with the quickstart, review interpretation limits and inspect the reporting implementation. The managed product is coming soon; this page demonstrates interpretation rather than an available hosted report service.