I rebuilt turva.dev around the report
Erik Rekola · 2026-09-07
The updated site puts sample reports beside the services they describe, with evidence, correction owners and acceptance checks visible before purchase.
I have rewritten turva.dev and rebuilt the pages around the work a buyer receives. The home page now leads into two services and their sample reports. Each report shows how an observation becomes a finding, a correction and a check that the correction worked.
That is the part I want someone to be able to inspect before buying an audit.
On this page
What changed on the site
The home page separates the focused Shopify storefront check from the broader website and API audit. Each has its own scope and a public example of the deliverable. The process is written out too: agree the question and scope, receive the findings, then make and verify the corrections.
The pages share a common layout. Headings, navigation and report sections follow the same structure across the site. The reports put the summary or decision before the contents and engagement details. Someone opening a long report can see the recommended action first, then follow the evidence behind it.
The guides are grouped by what a reader is trying to do:
- Audit, visibility and priorities.
- Content and crawl access.
- Discovery and authentication.
- Commerce and agent operations.
Their source-check dates are separate from the layout update. A redesigned page does not, by itself, establish that its technical advice is current.
This rewrite changed the pages, not the service scopes or the prices.
What the report template has to carry
The useful unit in the template is a finding with enough information for someone else to act on it:
- What was checked, under which conditions, and what came back.
- Why the result matters to the business question agreed at the start.
- Which correction comes first and who owns the work.
- What must be available before that work can begin.
- How to check the result afterwards, including anything still unresolved.
The website and API report keeps scanner readings, manual observations and answers from AI assistants identifiable as separate sources of evidence. They answer different questions. A reachable interface can return incorrect data. An assistant can repeat an old address even when the current page is accessible.
The report also names the boundary of a correction. Changing a response at the edge can correct what a client receives while leaving the underlying source unchanged. The person responsible for the source needs to know that, and the acceptance check needs to cover the surfaces that matter.
The finding that changes no scanner points
The sample website and API audit uses an invented fastener wholesaler. Every company detail, reading and date in it is fictional.
In that example, the visible product pages show real prices, while the structured data says the products cost zero and are in stock. The API provides another inconsistent representation. Correcting those facts comes before the fixes that improve the scanner result.
That ordering is deliberate. The company's question concerns what a buyer's assistant will read about its products. The report has to follow that question through the evidence and the correction plan, even where the scanner awards no points for the fix.
The sample shows the format and reasoning. It provides no evidence of a result achieved for a real client.
A smaller report for a Shopify question
The Shopify sample report uses a second invented business. It compares selected product variants across the storefront and the agent-shopping surfaces available in the example.
One fictional product has different prices in the storefront and the remote catalog. Another has conflicting availability. The report records the market, variant and session conditions, then gives each mismatch a correction and a retest condition.
It also records where the buyer journey stops. Reaching a checkout handoff does not establish that payment or order creation succeeded. The sample describes no paid order.
This is a narrower deliverable than the website and API audit. Its structure follows the merchant's immediate question: whether the tested interfaces agree about the products, and what the supported journey actually permits.
What I can claim about the update
The site now makes the report structure, service boundaries and next steps explicit. The two samples let a reader inspect the evidence format and correction instructions before contacting me.
I have not measured whether the redesign improves sales or AI citations. Those would need their own observations. Both sample reports remain synthetic, and neither is a certification of a real business.
For someone considering the work, the most useful place to start is the sample for their situation. It shows what I mean by an audit more precisely than a list of protocol names can.
Frequently asked
What should an agent-readiness audit report include beyond a scanner score?
The agreed scope, dated evidence, manual findings, priorities, correction owners and acceptance checks. If AI answers are included, the questions and measurement conditions should be documented separately from the technical scan.
Are the public sample reports real client work?
No. Both use invented businesses and observations to demonstrate the deliverable. They do not show measured client outcomes.
Can a team use the report without buying implementation?
Yes. The correction instructions and acceptance checks are part of the report. Implementation is a separate purchase, with access requirements and responsibilities agreed for that work.