Day 61: Put Proxy Signals in Their Lane

A weak visibility baseline usually fails in one of two ways.

It either ignores proxy signals completely, because they are not direct evidence of what an answer engine said, or it over-promotes them, because they are easier to collect than the answer itself.

Both mistakes are expensive.

For CMOs, Marketing Directors, and founders trying to understand AI visibility, the useful question is not, "Do we have a signal?" It is, "What kind of evidence is this, what decision can it support, and what should we not infer from it yet?"

A citation, a search ranking, a crawl report, a server log, a referral, a schema check, a public mention, and a saved answer transcript do not carry the same weight.

They belong in different lanes.

Direct evidence is the answer itself

The strongest evidence in an AI visibility baseline is a captured answer.

A real prompt was asked. A real surface responded. The brand appeared, did not appear, was cited, was summarised, was compared, was misunderstood, or was omitted. The transcript, screenshot, timestamp, prompt wording, surface, location settings where relevant, and cited sources create a record that a team can inspect.

That record is not perfect. Answer engines vary by session, geography, user context, index state, retrieval path, model version, and time. A single transcript should not be treated as the whole market.

But it is still direct evidence.

It shows what the buyer or researcher could have seen in that moment. It lets the team assess whether the answer was accurate, whether the brand was positioned correctly, whether competitors were named, whether the cited source was useful, whether a claim was unsupported, and whether the next step made commercial sense.

That is a different class of evidence from a proxy.

A proxy may tell you where to look. A transcript tells you what happened when you looked.

Citation surfaces are useful, but they are not the answer

Citation-surface evidence sits one lane away from the answer itself.

If Perplexity, Google AI features, another answer-led product, a comparison tool, or a vertical research surface repeatedly cites a particular page, publication, dataset, directory, community thread, review site, or partner article, that matters. It tells the team which source trails may be helping systems explain the market.

But a cited source is not automatically proof of favourable visibility.

The answer may cite the company but frame it weakly. It may cite a third-party page that lists the brand beside poor-fit competitors. It may use an old comparison article to explain the category. It may pull a useful source into an answer that never recommends the company. It may cite a page without carrying the page's intended nuance into the summary.

Citation evidence should therefore support questions like:

Which sources are being used when the category is explained?
Which pages or publications appear near our brand and competitors?
Which third-party sources deserve correction, reinforcement, outreach, or replacement?
Which answer transcripts should we capture next because the citation trail looks commercially important?

It should not support a claim like, "We are visible in answer engines," unless the answer itself has been reviewed.

Citation surfaces are not vanity data. They are inspection routes.

Search evidence belongs in the search lane

Search rankings, snippets, People Also Ask results, knowledge panels, crawled result pages, and Google Search Console data still matter.

They matter because answer-led discovery does not replace the public web. Many AI features sit beside, borrow from, or interact with search systems. Buyers still move between search results, answer summaries, vendor pages, review sites, analyst content, and private recommendations. Google's AI features in particular rely on core Search ranking and quality systems, so strong, useful, crawlable, credible content remains important.

But search evidence should not be quietly renamed as answer-engine evidence.

Ranking for a category query does not prove that ChatGPT, Claude, Perplexity, Gemini, Google AI features, or another answer surface will mention the brand. A snippet does not prove the answer will preserve the right framing. Search Console impressions do not prove that a buyer saw the company inside an AI answer. A strong organic page does not guarantee that a generated summary will select the same source, carry the same message, or route the buyer to the right next step.

Search evidence can support search decisions:

Which pages are eligible, crawlable, and competitive in traditional discovery?
Which queries expose category demand, competitor pressure, or buyer confusion?
Which pages already have authority worth strengthening?
Which search surfaces should be monitored alongside answer surfaces?

It can also inform answer-engine work.

But it should not be used as a substitute for captured answers.

Technical readiness is not visibility

Technical signals are often the most tempting proxies because they feel objective.

A page is crawlable. A sitemap is clean. Internal links are sensible. Canonicals are correct. Metadata is coherent. Structured data is valid where it is useful. The site loads quickly. Important content is not trapped behind scripts that make retrieval difficult. A robots file is not blocking the wrong paths.

All of that matters.

Technical readiness increases the chance that useful content can be discovered, interpreted, indexed, cited, and reused correctly. It reduces avoidable friction. It removes excuses. It makes later evidence easier to trust because the baseline is not polluted by basic access problems.

But technical readiness is not visibility.

It does not prove that a buyer question will surface the company. It does not prove that a model will choose the right page. It does not prove that an answer will be accurate, commercially helpful, or current. It does not prove that a competitor will be displaced.

This distinction is especially important around AI-specific shortcuts.

For Google AI features, the practical foundation remains Google's core Search ranking and quality systems. Teams should make useful, crawlable, trustworthy pages that answer real buyer questions. They should not pretend that llms.txt, special AI markup, arbitrary chunking, or over-focused structured data is a required switch for Google AI visibility.

Technical work belongs in the readiness lane.

It can justify fixing access, clarity, structure, performance, duplication, and content hygiene. It cannot, by itself, justify claiming answer-engine share.

Public-corpus clues show possible inputs, not guaranteed outputs

A brand's public footprint is another important proxy lane.

Third-party articles, podcasts, review sites, partner pages, directory listings, analyst mentions, community discussions, GitHub repositories, documentation, social profiles, job posts, old landing pages, and competitor comparisons can all shape how the company is represented across the web.

These traces matter because answer systems often work from public material. If the public corpus describes the company inconsistently, thinly, or incorrectly, the answer environment has more ways to compress the brand badly.

But public-corpus evidence is still not the generated answer.

Finding a strong third-party mention does not prove that an answer will cite it. Finding a weak directory listing does not prove that it is causing a bad recommendation. Finding an old page does not prove that it is currently shaping a model's response. Finding repeated category language does not prove that a buyer will see that exact language in a generated summary.

Public-corpus clues are useful for source hygiene and hypothesis building:

Which external descriptions of the company are outdated, thin, or misleading?
Which high-authority sources explain the category in ways that help or hurt the brand?
Which competitor comparisons appear repeatedly enough to deserve direct inspection?
Which claims need stronger public support before they can be expected to travel?

That is valuable work.

It just needs the right label: possible input, not confirmed output.

Analytics and referrers need careful handling

Analytics can show that answer-led journeys are commercially real.

A referral from Perplexity, ChatGPT, Gemini, Google, Claude, a vertical assistant, or another AI-related surface may reveal demand that would otherwise be invisible. A landing page pattern may show that answer-led visitors expect a certain next step. A CRM note may show that a prospect used an answer engine before arriving. A server log may expose a crawler, user agent, or route that deserves inspection.

Those signals are worth preserving.

But analytics rarely tells the whole story.

A referrer may be missing, stripped, misclassified, or blended into search. A buyer may use an answer engine, copy a URL, return later through direct traffic, and then convert. A sales note may say "AI" without naming the prompt or answer. A spike in visits may be caused by a citation, a social post, a newsletter, a partner link, or a competitor comparison rather than a clean answer-engine recommendation.

Analytics should therefore support routing questions:

Which journeys deserve qualitative follow-up?
Which pages are receiving answer-led or AI-adjacent traffic?
Which source labels need better sales capture?
Which prompt families, surfaces, or buyer questions should be sampled next?

Analytics can reveal where commercial activity may be happening.

It cannot replace the evidence of what the buyer actually saw or asked.

Build the baseline as labelled lanes

A practical AI visibility baseline should not flatten all signals into one score.

It should label the evidence lane before assigning meaning.

One simple structure is enough:

Direct answer evidence: captured prompt, surface, answer, timestamp, brand treatment, competitors, citations, and commercial interpretation.
Citation-surface evidence: sources used by answer-led products, citation frequency, citation context, and source quality.
Search evidence: rankings, snippets, query data, indexability, search demand, and Google Search Console patterns.
Technical readiness: crawlability, internal linking, canonicals, performance, content accessibility, metadata, and appropriate structured data.
Public-corpus clues: third-party descriptions, reviews, listings, old pages, partner references, comparison content, and repeated category language.
Analytics and referrers: traffic sources, landing paths, CRM notes, sales capture, and conversion patterns.

Each lane should have its own decision rule.

Direct answer evidence can support visibility, accuracy, positioning, competitor, and answer-quality decisions. Citation-surface evidence can support source prioritisation and transcript sampling. Search evidence can support search investment and page competitiveness. Technical readiness can support site fixes. Public-corpus clues can support cleanup, outreach, and proof-building. Analytics can support journey investigation and qualification.

The management error is treating all six lanes as if they answer the same question.

They do not.

The executive question is evidence discipline

The next time a dashboard says the company has AI visibility, ask for the lane.

Was the brand present in a captured answer, or did a relevant page rank in search? Was the company cited, or was it merely crawlable? Did a buyer arrive from an answer-led surface, or did analytics only show a referrer with no prompt context? Did a third-party source mention the brand, or did an answer actually use that source to explain the brand well?

Those distinctions are not pedantic.

They protect budget.

A direct answer problem may need content, positioning, source, or comparison work. A citation-surface problem may need third-party source repair. A search problem may need page quality and authority. A technical readiness problem may need crawl and structure fixes. A public-corpus problem may need cleanup or stronger external proof. An analytics problem may need better capture at sales handoff.

Different evidence. Different decision. Different work.

Proxy signals are not bad signals.

They become bad when they are promoted beyond what they can prove.

Put them in their lane, label them honestly, and use them to decide the next inspection. That is how AI visibility measurement becomes a management system instead of a confidence trick.