Where an AX Audit
can save your team time

Copy linkYour content can be read before anyone visits

A customer asks an AI assistant whether a replacement filter fits an appliance they already own. An assistant that searches the web may reply with an answer and links. The retailer might see a visit if the customer follows one. Its site analytics won't show what the assistant said or which part of the page informed its answer.

Open the product page in a browser and the compatibility table looks clear. The model numbers are grouped, with exceptions listed below. A client reading the initial HTML may never receive the table. A client that gets the table might still miss which exceptions apply to which models.

An Agent Experience (AX) Audit can help you check whether a client can retrieve and make sense of the facts it needs. You can test what your site actually serves and see where essential details drop out.

Copy linkWhat an AX Audit checks

Start with a task that matters to your organisation, then agree which pages and resources to assess. A retailer could sample product pages with different variant layouts, a category page and the returns policy. A publisher might choose a recent article, an archive entry and a correction notice. Include a normal case and an exception to see how the templates handle both. Record the authorised scope and any parts of the site excluded from it.

Tityra checks against the AgentReady essentials within the agreed website scope. The assessment looks at discovery and content delivery, semantic structure, metadata, structured data, automated accessibility signals and available source, date and usage context. Comparing the initial HTML with the page after JavaScript runs helps show when an important detail arrives and what a client without rendering capabilities can retrieve.

Record the request conditions with each observation. If a public URL returns a challenge, check the access rules. If it returns an empty page shell, check how the content loads. On an archived article, check whether the date and any correction are visible. When you find a pattern, check where else it occurs before estimating how many pages need work.

How to choose a representative audit sample

Copy linkThree problems worth looking for

First, essential facts arrive too late for the tested client. A product page might load specifications only when someone opens an accordion. The interaction can work well in a browser while a plain fetch receives the product name and little else. Check which details the task depends on. If the page can include those details in its initial HTML, keep the accordion as a way to show and hide them.

Second, two sources give different answers. A product page can say a variant is unavailable while its Schema.org Offer still declares it in stock. Both views may be technically valid, and both can point to the wrong value if they read from the wrong inventory record. Compare the same variant, region and currency under equivalent conditions. Then check which system owns the fact and why the two outputs diverge.

Third, the content lacks the context that tells a reader when it applies. An old policy might still attract inbound links after a replacement is published. Give the old document a visible status and date, and link to the current policy. For duplicate URLs, review how the site identifies the preferred version. A canonical URL can help a search engine choose among duplicates. A correction or a successor link explains a change to the person reading the page.

Copy linkDecide what automated readers should be able to access

Publishing a readable page and setting a policy for its use are separate decisions. Your team may want a public support article to be discoverable while keeping account records, drafts and private downloads behind authentication. OpenAI, for example, documents separate controls for OAI-SearchBot and GPTBot. Check what each service supports before treating a directive as a statement about all uses of the content.

The Robots Exclusion Protocol provides a way to state crawl preferences to cooperating clients. Access control belongs at the application or delivery layer. Compare your stated crawl policy with the response the tested client receives. A challenge on a public help page can be accidental. The same response on a private route may be the intended outcome. Agree the desired behaviour with the team that owns the rules before proposing a change.

Publish usage terms, authorship and dates where they help readers understand the content. For a syndicated article, credit the source and link to the current version. Check those details whenever you update or republish it.

Copy linkHow headings and tables carry meaning

A browser can make a flat set of containers look like a well-organised document. HTML headings give people who use screen readers and software that reads the document a way to follow its sections. In a compatibility table, row and column headers identify which accessory and exception go with each model.

A two-column PDF product sheet can look clear on screen while its extracted text mixes the columns. The W3C's PDF reading-order technique explains how tags express the document's logical order. Start with the authoring template where possible, export with tags, then check the reading order, table relationships and essential links in the output.

The website audit includes a review of the first PDF discovered, where available. You can agree additional PDF reviews separately. Full accessibility conformance requires a dedicated assessment with manual testing.

Copy linkWhat you receive and how to use it

The report in the Tityra workspace brings together documented findings, supporting evidence and practical recommendations. Individually requested reports receive staff quality review before release. Included weekly AX Audit reports are delivered automatically after the required checks. Your team can discuss the findings together and record progress against them.

Read a finding with the affected URLs, the observed behaviour and the method used to check it. Depending on the issue, the evidence may include an excerpt, a location on the page or the check that identified it. That gives the owner enough context to reproduce the issue and understand why it matters. A score summarises the supplied checks. Finding severity helps you decide which issues deserve attention first.

When a fix is ready, repeat the original check and verify the normal browser experience. If the affected pages use a shared component, check an ordinary page and a variant that uses it differently. Marking a finding resolved in the workspace records the team's progress. Keep the retest evidence with the ticket so everyone can see what you verified.

See what Tityra checks in an AX Audit

Copy linkPrioritise the fixes that help people complete the task

When the same returns policy is wrong on several pages, find out where each page gets it. If the pages share a source, compare the time needed to change that source and test the affected pages with the time needed to correct each page separately. Check which pages use the shared source before you estimate the work.

Prioritise by the consequences for the task as well as the size of the affected set. A missing model number can make the compatibility question impossible to answer. A description with untidy metadata may still support the decision. Give delivery issues to the team that owns the response, source corrections to the people who own the data, and template changes to the team that can test them across layouts.

Count the manual edits needed for a policy update before and after the fix. You can also time how long it takes to check that the visible page and its structured data agree. If you track citations or recommendations, measure them separately in each service.

Copy linkKeep the problem from returning at the next release

A site changes each time an editor publishes a new page, a team updates a component or a data feed gains a field. The useful outcome of an audit is a test the team can keep running. For the filter catalogue, require each product variant to carry an explicit model identifier and include the compatible models in its initial response. Add a template check and give editors a way to see when the source record is incomplete.

Build similar checks into the publishing routine for high-value documents. Put effective dates and version links in the policy template. If you publish the policy as both HTML and a PDF, agree who updates each version and check both outputs before release. A returns window may be easy to correct on the website and easy to overlook in a downloadable document that customers still use.

Assign ownership for the public access rules. When a firewall or consent flow changes, ask its owner to check a public help page and a route that should still require authentication. A small check can catch a change the application team would miss if it only tested the site while signed in.

Choose one important task and a representative set of pages your team is authorised to assess. After the audit, take one repeatable issue through to a fix and verify it under the same conditions.