Build an evidence-based audit worksheet
Open your most important service page and ask your team to demonstrate that its information is accessible, accurate and useful. That is the purpose of this audit. A completed checklist records work you can verify; it does not certify that an assistant will recommend your business.
Choose three pages: one service, one supporting article and one contact or enquiry page. Include their Turkish, English and Dutch equivalents where relevant. Give each finding a URL, evidence, an owner and a review date. Our AI visibility guide explains the wider concepts; this worksheet focuses on decisions your team can make now.
1. Can the intended search service reach the page?
Have a developer inspect the public URL, response status, indexing instructions and any access challenge. Compare the page visitors see with its retrieved content. Review relevant crawl rules and firewall logs without weakening protections across the whole site. Record the platform being tested: access is not one universal switch.
OpenAI distinguishes OAI-SearchBot for search from GPTBot for model training. Those controls are independent. Choose the intended permissions deliberately, then verify the configuration against the current documentation.
| Worksheet field | What to record |
|---|---|
| Method | Inspect the selected URL and applicable access controls. |
| Evidence | Response, rendered content, relevant rule and test date. |
| Pass or action | Intended access works; otherwise identify the specific blocker. |
| Owner | Developer or hosting administrator. |
2. Does the service description match what you deliver?
Ask the person who delivers the service to review its scope, audience, exclusions and enquiry process. Compare those details with the homepage, contact page and translated version. A Dutch reader should not receive a different offer because one language was updated first.
Try one concrete enquiry: could a prospective customer tell whether a small integration is included, or requires a separate quote? Mark the exact sentence that answers it. If nobody can point to one, assign a clarification.
| Worksheet field | What to record |
|---|---|
| Method | Compare published scope with the current delivery brief. |
| Evidence | Approved service facts and conflicting page excerpts. |
| Pass or action | Details agree; correct omissions or contradictions in all published languages. |
| Owner | Service lead, with an editor responsible for publication. |
3. Can a reviewer substantiate important claims?
Highlight claims about results, credentials, comparisons and technical capabilities. Ask what supports each one and whether you may publish that evidence. An unnamed success story is less useful to audit than a documented project with a stated scope and measurement period. Label invented examples as hypothetical.
Google’s helpful-content guidance discusses experience, expertise, authoritativeness and trust. Treat these as prompts for editorial scrutiny, not a checklist of points that guarantees a ranking.
| Worksheet field | What to record |
|---|---|
| Method | Trace important claims to approved records or sources. |
| Evidence | Source link, project context, reviewer and permission where needed. |
| Pass or action | Evidence supports the wording; qualify or remove unsupported claims. |
| Owner | Subject specialist and content editor. |
4. Does structured data describe the visible page accurately?
If structured data is present, inspect its values and run a suitable validator. Compare business names, URLs, authors and any marked-up claims with the visible page. Save errors separately from optional recommendations; do not invent details to fill a field.
Google does not require special AI schema, an llms.txt file or a fixed word count for generative search. Make this a consistency check, rather than a demand to install another plugin. A valid test result does not prove that the underlying information is true.
| Worksheet field | What to record |
|---|---|
| Method | Validate existing markup and compare its values with the page. |
| Evidence | Test output and the matching visible information. |
| Pass or action | Markup is accurate; fix errors or remove misleading fields. |
| Owner | Developer, with factual approval from the content owner. |
5. Can someone resolve a real buying question?
Choose three questions from recent enquiries. Ask a colleague unfamiliar with the page to locate the answer, explain it back and identify any uncertainty. Record missing conditions, such as what affects cost or when a service is unsuitable.
Use an opening answer followed by the detail the decision needs. Our editorial test is comprehension, not a paragraph quota. Keep a useful comparison together rather than splitting it into several pages just to create more keyword variations.
| Worksheet field | What to record |
|---|---|
| Method | Run a short reading task using actual customer questions. |
| Evidence | Question, answer location and remaining uncertainty. |
| Pass or action | Reader understands the answer; add the missing decision detail. |
| Owner | Content editor with sales or customer-service input. |
6. Are external descriptions genuine and current?
List the business profiles, professional directories and partner pages your customers actually use. Check names, links, service descriptions and contact routes. Distinguish a factual correction you control from an independent opinion you cannot rewrite.
Record genuine reviews or public project references as evidence of what others say, with their original context. Do not commission invented recommendations or seed fake discussions. This exercise gives your team a traceable reputation record; it is not proof that a platform has added you to an entity database.
| Worksheet field | What to record |
|---|---|
| Method | Review the small set of relevant external profiles. |
| Evidence | Profile URL, incorrect detail and who can correct it. |
| Pass or action | Facts agree; request legitimate corrections where necessary. |
| Owner | Marketing or the colleague who maintains business profiles. |
7. Can a visitor read, navigate and enquire comfortably?
Complete the journey on a phone and with a keyboard. Read the service information, open supporting evidence and reach the enquiry form. Check whether overlays hide the text, controls move unexpectedly or a required field is difficult to use.
Core Web Vitals measure loading, responsiveness and visual stability. Combine available field measurements with the issues observed in your test. A performance score alone does not establish AI citation eligibility, and a slow page is not evidence that a specific crawler has deprioritised it.
| Worksheet field | What to record |
|---|---|
| Method | Test one complete mobile and keyboard journey. |
| Evidence | Device, task, observed failure and available performance data. |
| Pass or action | Journey works; prioritise barriers to reading or enquiry. |
| Owner | Designer and developer, with one person responsible for closure. |
8. Can another person repeat your observation?
Keep a modest test set of customer questions in Turkish, English and Dutch. For each manual AI search check, record the product, search mode, date, language, exact question and any linked source. Preserve an excerpt of the answer when useful. Mark a brand mention, a citation and a visit as different observations.
Repeat meaningful tests after changes, keeping the conditions as consistent as possible. One improved answer does not establish that your edit caused it. Use repeated misunderstandings to investigate your published information.
| Worksheet field | What to record |
|---|---|
| Method | Repeat a documented question under recorded conditions. |
| Evidence | Prompt, date, platform, language, answer and source URL. |
| Pass or action | Observation is traceable; investigate inaccuracies and missing context. |
| Owner | Marketing analyst or the person maintaining the audit log. |
A worked example of a service-page audit
Consider two hypothetical service pages. Page A promises “the best solution” but omits scope and supporting material. Page B explains the work, identifies exclusions, links an approved example and provides a working enquiry route.
Page B gives a reviewer more evidence to assess and a customer more information for a decision. That is the defensible comparison. We cannot conclude from this fictional example that an AI system would ignore A or cite B. Keep the worksheet focused on observable improvements.
Assign the next action and a review date
Use three statuses: verified, action required and not yet checked. Fix access failures and incorrect business information first, then address unanswered questions and difficult user journeys. Attach a completion test to every task. Avoid a percentage score that conceals one serious blocker among several easy checks.
Bring your three URLs and the completed notes to Pixel Shield. Our free AI visibility and security scan is a starting point for identifying priorities. Content and design improvements can be scoped with Pixel Studio; development and access issues can be discussed with Pixel Dev.
Frequently asked questions
What should I prepare before an AI search readiness audit?
Choose a service page, a supporting article and an enquiry page. Bring recurring customer questions and access to the people responsible for content, development and measurement. Record observations without including customer personal data in shared notes.
How do I prioritise the findings?
Start with verified access failures, incorrect information and broken enquiry journeys. Then address missing answers or evidence. Give each task an owner, a completion test and a review date rather than relying on one overall score.
How often should I repeat the checklist?
Repeat affected checks after a website release, service change or material correction. Schedule a review that fits how often your content and systems change. Keep dated evidence so a colleague can understand what was checked.
