Drifter methodology
Drifter measures AI visibility with repeatable traveler questions, a consistent four-system panel, source evidence, and a receipt behind every number. You can inspect what was asked, what the evidence supports, and what the result cannot prove.
Method owner: Drifter · Version 1 · Last reviewed August 3, 2026
See the review-first product workflowEvery Drifter benchmark looks at your place through three lenses. Blind discovery asks the questions travelers ask before they know you exist, and your name appears nowhere in them. Named questions ask what AI tells travelers who are already looking at you. Peer questions ask where AI places you when travelers weigh their options.
Answer Share is a provider-weighted average. Within each provider, Drifter deduplicates eligible blind-discovery questions and divides the questions that mention the target place by all eligible questions sampled for that provider. It then combines those rates using the current configured mix: OpenAI 35%, Anthropic 25%, Gemini 25%, and Perplexity 15%, renormalized when a provider is absent. These are product aggregation weights, not observed market-share measurements.
Your agents don’t run a generic question list. They build a working model of the place you market: the audiences you draw, the seasons that matter, the trips people plan, the markets they come from. The benchmark is generated from that Place Model, which is why two hotels on the same street get two different benchmarks. And the model isn’t hidden: it sits right in your report, so you always know what your benchmark is built on.
A traveler deciding from Seattle may plan differently than one deciding from Dallas. Drifter uses the configured feeder markets to generate relevant question variations. The Place Model and resulting question set remain visible for review.
Generated for your place
“Where should travelers from Seattle go in Southern California for a food-and-culture long weekend?”
One of your blind discovery questions. Your name is nowhere in it. That’s the point.
A configured panel can run the same defined questions across ChatGPT, Claude, Gemini, and Perplexity. Drifter records the provider, exposed model information, question, answer, date, and available citations for completed samples. Provider availability and run cadence can vary by report and plan.
Defined questions · Recorded conditions · Repeated when configured
Drifter records the source URLs exposed with sampled answers and classifies eligible citation occurrences by domain and source type. Authority Share is the number assigned to owned domains, divided by all classified citation occurrences in the eligible sample set. Answers with no exposed citations are reported separately rather than treated as owned or third-party support.
Completed samples retain the question asked, provider, collection time, answer, detected mentions, and available citations. Missing or unavailable evidence is a limitation; it is not filled in or interpreted as proof of source influence.
Question
“Where should travelers from Seattle go in Southern California for a food-and-culture long weekend?”
Engine
Perplexity
Observed
This week’s run
Mentioned
Yes
Answer excerpt
“...for a coastal long weekend, La Jolla stands out: walkable coves, tide pools, and standout dining in a small village footprint...”
Citations
lajolla.travelafar.com
Reported findings retain supporting sample evidence
Technical-audit findings are limited to the signals observed during the run. Here is each check, what it can establish, and what it cannot.
What we observe
We fetch your robots.txt and read the published rules for each AI crawler we track.
What it proves
Whether your published rules allow or disallow those crawlers.
What it cannot prove
Whether a provider actually visits your site, or when.
What we observe
We request /sitemap.xml, follow any sitemap your robots.txt declares, and confirm the winning response is an XML sitemap.
What it proves
A sitemap is published and readable at a discoverable location.
What it cannot prove
Whether search or AI systems have fetched it.
What we observe
We read the canonical link tag from your homepage HTML.
What it proves
The tag is present or missing.
What it cannot prove
How crawlers resolve duplicate URLs across the rest of your site.
Homepage reachable: a completed audit first verifies that the homepage responded with a readable page instead of an error or a security wall. This is a precondition, not a scored check.
What we observe
We read the title tag from your homepage HTML.
What it proves
Presence and the exact text served.
What it cannot prove
Which title an engine chooses to display.
What we observe
We read the meta description from your homepage HTML.
What it proves
Presence and the exact text served.
What it cannot prove
Which snippet an engine chooses to display.
What we observe
We read the lang attribute on your html element.
What it proves
The declared language.
What it cannot prove
How well systems handle your content's language.
What we observe
We read Open Graph and Twitter card tags from your homepage HTML.
What it proves
Presence and completeness of social metadata.
What it cannot prove
How each platform renders your preview.
What we observe
We request /llms.txt.
What it proves
Whether the file is published.
What it cannot prove
Whether any AI provider reads it. Major providers have not confirmed doing so.
What we observe
We parse JSON-LD from your homepage HTML, plus rendered evidence when available.
What it proves
Structured data exists and which types it declares.
What it cannot prove
That any engine uses it in answers.
What we observe
We compare declared types against place and travel types.
What it proves
Whether types relevant to your entity are present.
What it cannot prove
That relevant types improve any specific answer.
What we observe
We count H1 and H2 headings in your homepage HTML.
What it proves
The heading outline as served.
What it cannot prove
Whether the writing under those headings is good.
What we observe
We measure the visible copy on your homepage as it reads before JavaScript runs, with code and styling removed.
What it proves
How much readable text is available in the initial HTML before client-side rendering.
What it cannot prove
Content quality, or what appears after JavaScript runs.
What we observe
We measure sentence length of that same served copy.
What it proves
Average sentence length of the served copy.
What it cannot prove
Whether the writing is clear to a human reader.
What we observe
We check the alt attribute on homepage images. An empty alt counts as an intentional choice for decorative images.
What it proves
Presence of alt attributes.
What it cannot prove
Whether the descriptions are accurate.
What we observe
We count links from your homepage to your own site.
What it proves
How many same-site paths the homepage offers.
What it cannot prove
Your full site architecture.
What we observe
We request Google Lighthouse lab data through the PageSpeed Insights API.
What it proves
Google's lab measurement at audit time.
What it cannot prove
Real visitor experience. When Google returns no data, the check reads unknown and is not scored.
What we observe
We request Google Lighthouse lab data through the PageSpeed Insights API.
What it proves
Google's lab measurement at audit time.
What it cannot prove
Real visitor experience. When Google returns no data, the check reads unknown and is not scored.
Provider statuses on the crawler matrix read your published robots.txt rules. Allowed means your published rules do not disallow that crawler. It is a policy observation, not a visit log.
Drifter inspects the official pages and technical signals available for review, then connects observed answer or source gaps to the page that may need attention. The evidence supports an investigation; it does not prove why a provider produced an answer.
Your pages → observed gap → review
A score does not decide the fix. When the evidence supports it, Drifter can turn a content or technical gap into a reviewable Action and prepare a draft or handoff. When a saved profile or website samples are available, Website Voice guides the draft. A person reviews the work before anything is published.
Evidence → Action → human review
When you ship a fix, it doesn’t disappear into a dashboard. Completed work can sit beside later samples, so teams can compare what was asked, what changed on the site, and what the sampled answers show next. A before-and-after sequence is descriptive unless the measurement design supports a causal conclusion.
See where AI includes you in the sampled answers, which sources appear, and which issue your team may want to review first.