Evidence-Grounded AI Search Visibility Audit for Brands and Websites

Conduct an evidence-grounded audit of the supplied brand or website for discoverability and citation readiness in AI-generated answers, AI Overviews, answer engines, and related generative search experiences.

## Audit context
Brand or website name: [Brand or website name]
Website URL: [Website URL]
Industry or niche: [Industry or niche]
Target audience and market: [Target audience and market]
Primary offerings and entities: [Primary offerings and entities]
Priority topics and pages: [Priority topics and pages]
Competitor websites: [Competitor websites]
Evidence pack: [Evidence pack]
Technical artifacts: [Technical artifacts]
Constraints and approval boundaries: [Constraints and approval boundaries]
Definition of done: [Definition of done]

## ChatGPT operating boundary
Use only information supplied in this conversation and content ChatGPT can actually inspect through enabled capabilities. A URL is a reference, not proof that its current contents were accessed. Do not imply that ChatGPT browsed a website, queried an answer engine, ran a crawler, validated production markup, accessed analytics, or implemented a change unless that action occurred and its evidence is available here.

You may inspect supplied page exports, crawl reports, rendered HTML, schema extracts, screenshots, query logs, Search Console exports, analytics summaries, citation records, and competitor materials. You may analyze, score, compare, draft recommendations, propose markup, and design tests. You must not publish content, alter pages, deploy schema, edit analytics settings, contact publishers, submit URLs, or approve implementation. Treat every consequential change as proposed until an authorized human approves and executes it.

## Input requirements
Blocking inputs for a website-specific audit are:
- An identifiable brand and website.
- Priority topics or pages tied to business goals.
- Inspectable evidence for the pages being assessed, such as page exports, crawl data, rendered HTML, or supplied page text. A URL alone is insufficient if browsing is unavailable.
- A definition of done or an explicit decision the audit must support.

Useful optional inputs include dated AI-answer screenshots or query logs, target market and language, Search Console data, analytics, backlink or mention exports, robots directives, XML sitemaps, canonical data, structured-data reports, competitor evidence, editorial constraints, and implementation ownership.

If a blocking input is absent, ask up to five focused clarification questions before producing a website-specific score. If answers are unavailable, continue only with a clearly labeled limited-scope framework or partial audit. Preserve missing values as unknown or not assessed; do not estimate them. If sources conflict, record the conflict, identify the competing evidence, and avoid choosing a version without support.

## Evidence and uncertainty rules
1. Assign evidence IDs such as E1, E2, and E3 to supplied artifacts. Record each artifact’s type, source, relevant URL or query, capture date when known, market or locale when relevant, and limitations.
2. Label material statements as one of:
   - Observed: directly visible in supplied evidence.
   - Supplied fact: stated by the user but not independently demonstrated.
   - Inference: reasoned from observations, with the reasoning stated.
   - Hypothesis: plausible but requiring a test.
   - Unknown: evidence is unavailable or inadequate.
   - Conflict: credible inputs disagree.
3. Attach evidence IDs to findings and competitor comparisons. Never create citations, mentions, rankings, traffic figures, query results, or implementation evidence.
4. A screenshot or query log supports only the recorded engine, query, date, locale, device or session conditions. It does not establish persistent, universal, or causal visibility.
5. Separate observed answer-engine presence from readiness signals. Strong SEO, schema, authority, or content structure may support readiness but does not prove inclusion or citation.
6. Treat third-party metrics as directional and identify their provider and date. Do not present proprietary scores as direct measurements of AI visibility.
7. Assign confidence as High, Medium, or Low using evidence coverage, recency, consistency, and directness. Explain Low-confidence consequential findings.

## Safety and approval controls
- Do not request or expose passwords, API keys, private customer data, personal search histories, or unnecessary personal information. Recommend redaction or aggregation if supplied artifacts contain sensitive data.
- Do not bypass authentication, robots controls, paywalls, rate limits, or access restrictions. Do not recommend fabricated reviews, citations, authors, credentials, statistics, consensus, or deceptive schema.
- Flag legal, medical, financial, safety, regulated, or reputation-sensitive claims for qualified editorial or legal review. Do not recommend removing required disclosures merely to improve answer extraction.
- Require human approval before production edits, schema deployment, redirects, canonical changes, robots or noindex changes, publisher outreach, or measurement configuration changes. Recommend backups, staging, validation, and a rollback owner for technical changes.
- Stop and request guidance if the requested work would require unauthorized access, deceptive attribution, disclosure of sensitive data, or a production change outside the stated approval boundary.

## Audit workflow
### 1. Establish scope and evidence coverage
Translate the definition of done into explicit audit questions. Build an evidence register, identify blocking gaps, and state whether the result is a full audit, partial audit, or framework only. Map each priority topic to its target audience, intent, business relevance, preferred landing page, and evidence coverage.

### 2. Record observed AI-answer visibility
When direct query evidence exists, create a query observation matrix containing engine or experience, exact query, intent, locale, date, session conditions, brand mentioned, brand cited, cited URL, competitor mentions or citations, answer position or treatment if observable, evidence ID, and limitations. Keep mentions distinct from linked citations. If no direct query evidence exists, mark observed visibility not assessed and provide a manual test protocol rather than a visibility conclusion.

### 3. Assess entity clarity and corroboration
Check whether supplied evidence consistently identifies the organization, products, people, locations, and relationships across priority pages and relevant corroborating sources. Review naming consistency, About and contact information, authorship, expertise signals, editorial ownership, dates, references, organization details, sameAs targets, and contradictions. Do not equate schema presence with verified entity recognition.

### 4. Assess content and topical coverage
For each priority page, examine intent alignment, direct answerability, factual specificity, definitions, supporting evidence, source attribution, freshness, authorship, unique value, update needs, and overlap or cannibalization. Build a topic-to-page map that identifies covered subtopics, unsupported claims, missing comparison or decision content, orphaned pages, duplicate intent, and opportunities for contextual internal links. Do not recommend content expansion solely for word count.

### 5. Assess citation and source readiness
Evaluate whether important claims are attributable, current, internally consistent, and easy to locate. Distinguish first-party evidence, independent corroboration, primary sources, secondary sources, and promotional assertions. Identify weak provenance, inaccessible evidence, circular sourcing, missing publication or update dates, and claims that require subject-matter review.

### 6. Assess technical discoverability and structured data
Using only supplied technical artifacts, review indexability signals, robots directives, noindex, canonical targets, redirects, status codes, rendered-content availability, sitemap inclusion, duplicate variants, language or regional annotations, and structured-data implementation. For schema, report observed types and properties separately from recommended ones. Recommend only types supported by visible page content and relevant eligibility rules. Syntax validity, search-feature eligibility, indexing, and AI citation are separate states; none guarantees another.

### 7. Compare competitors on equivalent evidence
Compare only pages, queries, dates, markets, and artifact types that are reasonably equivalent. Identify whether a difference is observed, inferred, or unknown. Analyze content coverage, entity corroboration, source quality, answer format, internal linking, schema implementation, and observed mentions or citations. Do not declare a competitor stronger overall when evidence coverage is materially unequal.

### 8. Score readiness
Score each assessed dimension from 0 to 4:
- 0: absent or contradicted by evidence.
- 1: materially deficient.
- 2: partial or inconsistent.
- 3: strong with limited gaps.
- 4: well-supported and consistently implemented.

Use these weights: entity clarity 15%, content and answerability 20%, citation and source readiness 20%, technical discoverability and structured data 15%, topical architecture and internal linking 15%, and observed AI-answer visibility 15%. For each dimension, provide the score, weight, evidence IDs, rationale, confidence, and gaps. Mark unassessable dimensions N/A and calculate an adjusted total using only assessed weights. Disclose omitted dimensions and never convert an N/A into a favorable score. Call the result a readiness score, not a probability of AI inclusion.

### 9. Prioritize recommendations
Create recommendations tied to findings, affected pages, intended outcomes, dependencies, risks, owners, and validation methods. Rank them using impact, confidence, effort, and reversibility. Separate:
- Quick, low-risk editorial improvements.
- Evidence or subject-matter work.
- Technical changes requiring staging and approval.
- Experiments requiring a baseline and observation period.

For every schema recommendation, name the candidate type or property, the page evidence supporting it, prerequisites, validation steps, and the human approval required. Do not output invented production-ready values where facts are missing.

### 10. Build the 30/60/90-day plan
Assign sequenced actions, owners, dependencies, approval gates, expected evidence, and completion criteria. The first 30 days should address measurement baselines and high-confidence blockers; later phases may cover content clusters, corroboration, technical work, and monitored experiments. Keep proposed, approved, implemented, and verified states distinct.

### 11. Define verification and acceptance
Create a verification matrix with recommendation ID, baseline, expected observation, test method, required tool or artifact, responsible owner, actual observation, evidence ID, status, and follow-up date. Leave actual observations blank or not run unless execution evidence is supplied.

At minimum, include checks for:
- Priority-page crawl and render behavior against expected status, indexability, canonical, and content availability.
- Structured-data syntax and eligibility separately, followed by rendered-page confirmation after authorized deployment.
- Internal-link presence and destination correctness after implementation.
- Content claims, citations, dates, and author information against approved sources.
- Repeated AI-answer query observations using the same query, locale, engine, and documented session conditions, while acknowledging volatility.
- Analytics or Search Console monitoring only where configuration and access are confirmed.

A recommendation may be marked verified only when the expected result matches an actual observation and an evidence ID is present. Otherwise mark it proposed, awaiting approval, implemented but unverified, failed, blocked, inconclusive, or not run. Reconcile failed or conflicting checks and retain unresolved items in the final handoff.

## Required deliverable
Produce the audit with these sections and fields:

1. **Scope, Decision, and Audit Status** — decision supported, in-scope properties and pages, market, definition of done, audit status, exclusions, and blocking limitations.
2. **Evidence Register** — evidence ID, artifact, source, date, scope, directness, limitations, and sensitive-data handling note.
3. **AI-Answer Query Observation Matrix** — include all specified query fields, or state not assessed and provide a manual collection protocol.
4. **Readiness Scorecard** — dimension, weight, 0–4 score or N/A, weighted result, evidence IDs, confidence, rationale, and material gap; include the adjusted-total calculation.
5. **Priority Page Findings** — page, target intent, observed strengths, issue, evidence IDs, finding class, consequence, confidence, and recommended disposition.
6. **Entity and Corroboration Map** — entity, claimed attributes, first-party evidence, independent corroboration, inconsistencies, and required validation.
7. **Topic and Internal-Link Map** — priority topic, current page, coverage state, overlap or gap, source page, suggested destination, anchor rationale, and user value.
8. **Citation and Claim Register** — claim or claim type, page, current source, source quality, freshness, risk, and remediation.
9. **Technical and Schema Register** — URL, observed technical signal, observed markup, issue, supported recommendation, prerequisite, approval gate, validation method, and rollback consideration.
10. **Competitor Evidence Matrix** — comparison unit, brand observation, competitor observation, evidence parity, evidence IDs, confidence, and bounded implication.
11. **Prioritized Recommendation Backlog** — ID, finding addressed, affected asset, action, impact, confidence, effort, dependency, risk, owner, approval, and acceptance evidence.
12. **30/60/90-Day Plan** — phase, action IDs, sequence, owner, dependency, approval gate, deliverable, and exit criterion.
13. **Verification Matrix** — baseline, expected and actual observations, method, evidence, owner, status, follow-up, and unresolved discrepancy.
14. **Decision Handoff** — actions ready for approval, evidence still required, unresolved conflicts, items not assessed, monitoring cadence, and named human decisions.

End with a concise statement distinguishing what was observed, what was inferred, what remains unknown, and what is merely proposed. Do not state that the website is optimized, visible, fixed, validated, approved, or complete unless the corresponding execution and acceptance evidence is present.