Check the response an agent actually receives before changing the words on the page.
One URL can return different views
Your browser combines the server response, JavaScript, network requests and stored preferences into a page. An agent may use a plain HTTP fetch, a search result or a browser with different capabilities. The view you recognise is only one of those paths.
Start with a small, authorised sample: the homepage, a service or product page, and a page that carries important evidence. Record the URL, time, status, response headers and the retrieval method. Compare the initial HTML with the rendered page under stated conditions. A difference is a lead to investigate, not automatically a defect.
First, separate access policy from delivery failure
Read the applicable robots.txt rules and then examine the actual response. A crawl rule expresses a policy for cooperating crawlers; a CDN challenge or 403 response changes what the client can retrieve. An allow rule does not guarantee that a bot will get through the edge layer.
A useful finding identifies the intended audience, the blocked resource and the observed response. Check CDN rules, bot protection and server logs with the website owner. Keep private areas private. The fix is an intentional access policy for the resources you want discoverable, rather than disabling protection for the whole site.
Illustrative access finding
- Observation
- A public service URL returns a browser challenge instead of the service description to the tested client.
- Next step
- Review the edge rule for that route, preserve protections on private paths, and repeat the same request after the change.
Check whether JavaScript carries the answer
A successful HTTP response can still contain little useful content. If the initial HTML contains only a loading container, a client that does not execute JavaScript cannot read a service description that appears later. Browser-capable agents may also encounter failed requests, consent conditions or incomplete hydration.
Compare meaningful content, not just byte counts. Is the service explanation present? Can a reader identify prices, conditions and the next step? Where appropriate, render essential public content on the server or generate it at build time. JavaScript can enhance interaction while the initial document still communicates the main answer.
Illustrative content finding
- Observation
- The rendered page shows the service description, but the initial HTML contains only an application shell.
- Next step
- Include the essential description and its heading in the initial HTML, then verify it without JavaScript and in the normal browser flow.
Readable text still needs a structure
Once content is available, examine how its meaning is expressed. A visual heading made from a generic container may not communicate the same outline as a heading element. A product comparison can lose its meaning when cells have no clear relationship to row and column headings.
Use descriptive headings, appropriate landmarks and semantic tables where they fit the content. Structured data should describe facts already supported by the page. It can add context; it does not replace the underlying information. Treat missing content and unclear structure as separate findings so the recommended change addresses the cause.
Retest the same path
Keep the observation, expected behaviour, affected resources and verification steps together. After a change, repeat the recorded retrieval method and also check the human experience. A fixed sample does not establish that every template or client now works.
These examples illustrate types of AX findings; they are not published customer case studies or measurements of your website. Tityra’s AX audits combine the agreed website checks with evidence and staff review. The report should tell your team what was observed and where the limits of that observation are.
Sources and further reading
See what your website delivers.
Choose an agreed scope and get findings your team can act on.
