AI-Answer and Search Presence Audit

AI-Answer and Search Presence Audit

Overview

A brand can rank well and still be absent from the answers that buyers read. This audit takes a set of real buyer questions, observes which sources the public search and answer surfaces cite for each one, and records whether the brand's own domain appears. Every observation is dated and sourced. Anything that could not be observed is recorded as UNKNOWN, never as absent, because a false zero distorts the priorities.

When to Use

• Measuring how a brand appears in search results and AI answers for a defined set of buyer questions.
• Deciding which content to add or improve, based on the pages that the answer surfaces actually cite.

Skip it for ranking monitors (one observation per question and surface is enough here), for competitor deep-dives, and for question sourcing (use ai-search-question-bank first).

Features

• Question phrasing taken from real autocomplete suggestions, saved verbatim, with the seed recorded for each question.
• A surface-by-surface probe before the run, which marks each surface as observable or unknown.
• Validation that flags result sets that are off-topic or identical to another question's set.
• A matrix generated by script from the raw observation files.
• A report that ranks content recommendations by ease and impact, with the unobservable surfaces listed.

Benefits

• A zero result means the surface was observed and returned nothing, and that is stated on the matrix.
• Every citation can be traced to a dated observation.
• Gaps are named, so the next session can close them instead of assuming them away.

Procedure

1. Set the scope. Read-only observation only. Do not log in, sign up, solve challenges or contact anyone. Send public GET requests to the brand's own hosts at no more than two per second. Work in a fresh branch from the main branch, with the commit identity the request names.
2. Source the questions. Query a public autocomplete endpoint with one seed per topic, about 0.6 seconds apart. Save the raw responses. Use only strings that appear verbatim in them, and record the seed for each question. Autocomplete shows how people phrase questions, not how often they ask them.
3. Probe every surface once before the run. For each candidate search or answer surface, record the status, any challenge text and any redirect. Classify each as observable or unknown. Bot challenges, sign-up walls and sign-in redirects are unknown. Do not attempt to get past them. Add one control question with a known answer to each surface that returns empty results, so that an empty set can be told apart from a filtered one.
4. Collect on observable surfaces. Save each surface's results to its own file, one line per question, with a timestamp for each query. Record the cited addresses, the surface name and the first part of the raw text.
5. Validate each result set. Flag sets that are off-topic for the question, and sets that are identical to another question's set, which means the engine has degraded the query. Mark those rows as not valid and leave them out of the conclusions. A missing citation in an invalid set is not evidence.
6. Do not trust site-restricted queries on general search engines. A site-restricted query often returns nothing or is treated as plain text. Do not report index counts from it as fact. Use brand-name queries and search-API results instead, and mark index counts as unknown.
7. Inventory the brand's own surfaces. Read the robots file for each bot, both the response header and the page meta robots tag, the sitemap, and the agent files. Count the pages in each category, learning and certificate section. A block on the site means every question that depends on it is blocked by policy. Report it as a decision for the owner, and do not change it.
8. Label the winning content type. For each question and surface, name the format of the top results, for example a category page, a product page, a how-to article, a comparison list, a directory, or a discussion thread.
9. Rank the recommendations. Rank the top questions by purchase intent multiplied by the ability to win. State the rubric. Map each question to an existing page or to a named gap. Say which items depend on a blocked policy decision.
10. Generate the matrix from the raw files. Write a script that builds the matrix from the raw observations. Keep editorial inputs, such as content-type labels and validity calls, in one marked block. Emit an unknown row for every question and surface that could not be observed.
11. Write the report and open a draft. The report ranks the top recommendations, gives the cited evidence, lists the unknown surfaces and states the caveats and next steps. Commit the matrix, the report and the raw snapshots of the robots and agent files, so that the claims can be checked. Open a draft pull request and never merge it.

Matrix columns

question, surface, timestamp, status, brand_present (1 or 0), top_cited, content_type, gap_note, evidence_url

• status is one of OK (results parsed, at least one organic result), EMPTY (the surface returned no results), BOT_WALL (challenge, rate limit or sign-in), or UNKNOWN (not tried).
• brand_present is 1 only when a cited host matches a brand host literally. Answer engines sometimes paraphrase brand names, so flag any paraphrase separately.

Pitfalls

• Report presence precisely. State "zero of N observed sets, M of them valid", and list the unknown surfaces separately. Combining them overstates the finding.
• Verify an empty result on a second surface before recording it, because one empty result often hides a challenge page.
• Treat unknown as unknown. A surface that challenged the client is not an empty surface.
• Use the search engine's own result page with its parameters for buyer queries. A default page can return dictionary entries for buyer intent, and that would invent a competitor that does not exist for the buyer.
• Check whether a stale host is indexed before concluding the current host is absent. Caches can show previews of pages that are now gone, so separate "not indexed" from "indexed but dead".
• Gemini-style source chips show publisher names with extra sources collapsed into a count. Treat the cited sources as a floor. A single run per question varies, so say so.
• Intent and ability scores are judgements. Say so, and show the rubric.
• Never place keys or tokens in the report or the matrix.
• Start writing the report early. A matrix that is committed on time is worth more than a report that is never finished.

Verification

• Every observed row has a timestamp and a status from the closed set.
• The matrix is generated from the raw files by script, and rerunning it gives the same output.
• Each unknown surface is listed in the report with its reason.
• Each invalid set is marked and excluded from conclusions.
• The draft pull request contains the matrix, the report and the raw snapshots, and has not been merged.

Attribution

Query-sourcing and matrix steps follow the public autocomplete endpoint behaviour used by common search tools. No external project's code is adapted.