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 that includes the homepage, a service or product page, and a page with important supporting information. Record the URL, time, status, response headers and retrieval method. Compare the initial HTML with the rendered page under the same conditions, then check whether any differences affect the task.
First, separate access policy from delivery failure
Read the applicable robots.txt rules and examine the actual response. A crawl rule tells cooperating crawlers what they may request. A CDN challenge or 403 response controls what the client receives. Check both when a resource you mean to publish is hard to retrieve.
Record who needs access, which resource was blocked and what the client received. Check CDN rules, bot protection and server logs with the website owner. Adjust the rules for the public resources you want people to find and keep protections in place for private areas.
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 only has a loading container, a client that doesn't run JavaScript will miss the service description. A client with a browser can still run into failed requests, consent screens or a page that hasn't finished loading.
Compare the content a reader needs in each view. 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. The initial document can carry the main answer while JavaScript handles the interaction.
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. Use structured data to clarify facts the page already provides. Record missing content separately from unclear structure so the team can fix each 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 check the page in a browser. Record which templates and clients the retest covered.
The examples use fictional pages to show how to investigate an access or delivery problem. In Tityra, the report records what the audit observed and the conditions it covered. Individually requested reports receive staff quality review before release. Included weekly AX Audit reports are delivered automatically after the required checks.
