Copy this report structure before buying an audit
Use the following as an acceptance brief. Ask for an editable report and an evidence folder, with access agreed in advance. Each finding should point to a saved artifact. Enter “not checked” or “access unavailable” where appropriate; an empty field must not silently become a passing result.
| Report block | Fields to complete | Acceptance question |
|---|---|---|
| Decision summary | Scope, main confirmed issues, next decision, limitations | Can the buyer explain what needs attention and why? |
| Test specification | Service, audience, market, language, dates, platforms/modes, question-set version, repeat rule | Can another person reconstruct the test conditions? |
| Question register | Exact questions, IDs, buyer need, branded/non-branded label, selection rationale | Do the questions cover the agreed buying situations? |
| Answer archive | Run IDs, full answers, dates, conditions, failures and exclusions | Can every reported observation be traced to a run? |
| Citation and fact map | Mentioned brands, exact linked URLs, supporting passages, factual conflicts, source ownership | Does the source actually support the claim? |
| Technical findings | Affected URL, test method, response/content evidence, scope of the check | Is this a verified obstacle or still a hypothesis? |
| Action register | Finding ID, evidence, priority reason, task, owner, dependency, acceptance rule | Can someone implement and accept each task? |
| Retest and handover | Baseline, change dates, repeat conditions, reviewer, next review date, export/access details | Can the business repeat the check without the vendor? |
Keep one observation record per answer
Copy these fields for each question, platform and repetition. Store full answers beside the record rather than keeping only a cropped screenshot of a favourable mention. Capture the source links as they appeared, and note redirects separately. Remove personal or confidential data before sharing the archive.
| Field group | What to save |
|---|---|
| Identity | Run ID; question ID/version; exact prompt and relevant conversation context |
| Conditions | Market; prompt and answer language; platform; displayed model/product; search mode; session/personalization state where known |
| Timing and coverage | Date, time and time zone; repetition number; planned/completed/failed status; exclusion reason |
| Answer evidence | Full response or accessible export; screenshot if useful; archive location |
| Brand and citation | Brand mentioned yes/no; description accuracy; linked citation yes/no; exact cited URLs and source type |
| Source inspection | Date inspected; passage supporting the claim; own, independent, paid or unknown relationship |
| Interpretation | Observed fact; alternative explanation; confidence reason; linked finding or next check |
Turn observations into work: an open findings log
These are hypothetical training rows, not observations from a customer site. Replace them with your own evidence. The report should keep the observation, its proposed explanation and the action separate. A missing citation does not, by itself, identify its cause.
| Observation | Evidence to attach | Action and owner | How to verify |
|---|---|---|---|
| A priority page returns 403 in the audit request | URL, timestamp, request conditions and response; real crawler evidence if available | Developer: identify the blocking rule and intended access policy | Repeat the request; inspect verified crawler access separately. A simulated user agent is not proof of a real visit. |
| A saved answer describes an old service scope | Full answer, linked source, dated passage and approved current service facts | Content owner: correct the source under their control; request an external correction where justified | Check the edited facts, then repeat the same question. Do not promise the next answer will update. |
| No linked brand URL in one recorded answer | Run ID, full answer and all citations under the documented conditions | Analyst: repeat the agreed sample and inspect the cited alternatives before proposing changes | Report repeated observations with counts and conditions; keep the cause unresolved if evidence is insufficient. |
- 01Save the observation
- 02Inspect the evidence
- 03Assign a bounded task
- 04Verify and retest
Agree the questions, markets and repeat rule
Begin with the service and decision the business wants to understand. Separate a question naming your brand from one asking for possible suppliers. Include a reason for each question: a documented customer question, an available search query or an explicit research hypothesis. No Search Console access means a data gap, not no demand.
Keep EN, PL and UK samples separate. Localize the buying situation and market rather than mechanically translating every word. Record a displayed model version when available; mark unknown settings as unknown. Do not treat an API test as the same experience as a consumer chat interface.
Agree the number of questions and repetitions before collecting answers. There is no universal sample size prescribed by this template. Report planned, completed and failed runs. For a citation rate, define the numerator and denominator explicitly, exclude failed runs transparently, and show the counts beside the percentage. Changed questions require a new sample version or a comparison limited to the unchanged subset.
Require technical evidence that matches the platform
For each alleged obstacle, ask for the affected URL, test date, method and saved response or content. Separate access restrictions, indexing instructions, wrong canonical targets and missing readable service information. A checklist label such as “AI readiness failed” is too broad to assign or verify.
Google says supporting links in AI Overviews and AI Mode require indexing and snippet eligibility; no special AI markup is required. Eligibility does not guarantee inclusion. Use that guidance for Google rather than presenting it as a rule for every assistant.
Distinguish search access from training access
OpenAI documents independent controls for OAI-SearchBot, used for search, and GPTBot, used for potential training collection. A report must name the relevant bot and purpose. One training setting cannot stand in for a search-access check.
Ask what the test establishes. A successful request with a chosen user-agent string demonstrates that request, not admission of a verified crawler. Where logs or account access are unavailable, record the unverified part and who can check it. Never close a visibility finding solely because a technical request now succeeds.
Keep scores, citations and business outcomes separate
If the provider uses a score, request its formula, component definitions, weights, exclusions and underlying records. Treat it as that provider’s summary. Do not compare scores from different tools as though they measured the same population. “Not observed in this sample” is more defensible than “invisible to AI everywhere”.
Bing’s AI Performance documentation describes citation counts across supported experiences; those counts do not establish answer placement. Grounding queries are a sample of citation activity. If such data is available, preserve its date range and scope rather than relabelling it as all-platform visibility.
Audit the cited page, not just its domain. Check whether the passage supports the answer and whether it comes from the business, an independent publisher or a paid placement. Keep recognised referral visits, accepted inquiries and qualified opportunities in separate columns. Without attribution evidence, do not assign all Direct traffic or later sales to AI.
Accept the report when the next task is clear
Prioritize confirmed access or factual errors that affect the agreed service before speculative enhancements. Explain each priority through the business consequence, strength of evidence, effort and dependency. Use “investigate” for unresolved causes instead of presenting them as confirmed fixes. A three-item list with evidence is more usable than a long unowned checklist.
Before acceptance, choose a finding and follow it from summary to saved answer or request, to source, task, owner and retest rule. Ask for missing evidence or a clearly marked limitation. Agree where exports live and who retains access. Set the next review relative to actual implementation; a 30/60/90-day cadence is a review schedule, not a promise of results.
- Can you inspect the questions, full answers and cited URLs?
- Are unsupported causes marked as hypotheses and missing data disclosed?
- Does every priority have an owner, dependency and acceptance check?
- Can the business retain the evidence and repeat the agreed test?
Bring the template to your scope discussion
Use the GEO introduction below for the wider context and the measurement guide for recurring monitoring. This template addresses a different decision: whether the audit is complete enough to accept and act on.
BeeCited offers GEO work across the website, content, brand information and measurement within an agreed scope. Send your priority service, market and existing report through the inquiry form to discuss the evidence and responsibilities needed. Confirmed technical tasks can be scoped separately through technical maintenance.
Sources & further reading
An original BeeCited report framework, prepared by a GEO service provider. The blank fields and teaching examples are not a completed client audit or an industry standard. Platform guidance was checked on 19 October 2026. Editorial, factual and language checks were performed with AI assistance; independent expert review is not claimed.
