Someone in your organisation has seen a slide claiming that one particular kind of site dominates the sources AI assistants cite. Maybe it was a community platform, maybe a review directory, maybe a wire service. Whatever it was, a plan is now forming around it, and nobody has checked whether it holds for the questions your buyers actually ask.
It probably does not. Citation mixes vary by category, by assistant, and by how the question is phrased, and the only version of this finding that should drive your budget is the one you produced from your own prompt set. This is a method for producing it, written so that a colleague with the same prompts and the same coding scheme would get comparable results.
Why the general answer misleads
Aggregate claims about "the most-cited sources in AI answers" fail for your purposes in four specific ways.
Category structure varies. A category with mature independent review coverage, a category served mainly by vendor documentation, and a category discussed mostly in professional communities will not draw on the same kinds of sources. An aggregate across all categories describes none of them.
Assistants differ. Different systems assemble answers differently, and what one surfaces as a citation another may use without attribution or not use at all. A single blended number hides that split, which is the part you need.
Phrasing moves the mix. This is the most under-appreciated one. "Best project management software," "project management software for construction teams," and "alternatives to [named product]" are three different retrieval problems, and because each is a different query they can pull from noticeably different source pools. Treat phrasing as a variable, not as noise.
Non-determinism. Repeated runs of the same prompt do not return identical answers or identical citations. Any finding based on a single run per prompt is describing one sample from a distribution and calling it the distribution. A defensible run carries its prompt set, model versions, dates, sample size, and variance, and this publication does not assert a universal ranking of cited sources without that evidence. Neither should you, internally, unless you measured it.
Collecting citations at scale from your own prompt set
The unit of work is: prompt set → repeated runs across models → a row per citation. Use official provider APIs. Do not automate consumer accounts or scrape assistant web interfaces; it breaches provider terms and it produces data you cannot defend.
Build the prompt set. Thirty to sixty prompts is a workable range for a single category. Draw them from real buyer language — sales call notes, support tickets, the questions your solutions team answers on first calls. Cover the phrasing families deliberately:
- Category discovery ("best X for Y")
- Constraint-shaped ("X for regulated industries," "X for teams under 20")
- Comparison ("X vs Y," "alternatives to X")
- Problem-shaped ("how do I stop Z happening")
- Verification ("is X any good," "who uses X")
Keep the families labelled in your sheet. You will want to split by them later.
Decide the run plan before you start. Fix the models and versions, the number of runs per prompt per model, the dates, and the locale or personalization settings. Write them down. If you change any of them mid-collection, you have two datasets, not one.
Record every citation as a row. Minimum columns:
| Column | Why it is there |
|---|---|
prompt_id | Lets you split by phrasing family |
phrasing_family | The variable most people forget to control |
model + version | Splits are meaningless without it |
run_date | Answers drift; undated rows are unusable later |
run_index | Which of the N repeats this was |
cited_domain | The aggregation key |
cited_url | Needed to classify page type |
page_type | Coded later, from the URL and the page |
position_in_answer | Optional; first citation may differ in role from fifth |
brand_mentioned | Whether your brand or a competitor appeared in that answer |
Sample size. More runs per prompt narrows the interval around any frequency you report. There is no universal correct number; it depends on how variable the answers are and how small a difference you need to detect. Run enough that the top of your frequency table is stable when you split the data in half and compare the halves. If it is not stable, you have not run enough.
Coding sources into types
Domains are the wrong altitude for decisions. Code every cited URL into a type, using a scheme fixed before you look at results. Ours:
| Code | Type | Definition | Boundary note |
|---|---|---|---|
OWN | First-party | The brand's own domain, docs, or support content | Includes subdomains and doc sites |
COMP | Competitor first-party | A direct competitor's own domain | Distinguish from OWN even when structurally similar |
REV | Review / comparison platform | Third-party site whose primary content is user or editor reviews of products in the category | Not editorial roundups by a publication |
ED | Editorial / trade press | A publication with a masthead and editorial staff | Includes their listicles and roundups |
COMM | Community | Forums, Q&A sites, discussion platforms | Code by platform, not by thread quality |
REF | Reference / encyclopaedic | General references, standards bodies, government sources | Includes official statistical sources |
ACAD | Academic / research | Journals, preprints, institutional research | |
DIR | Directory / listing | Catalogues, marketplaces, integration directories without substantive review content | Overlaps REV; decide by whether reviews are the main content |
AGG | Aggregator / low-substance | Sites republishing or thinly rewriting others | The judgement call; log examples in your codebook |
OTH | Other | Anything that does not fit | Should stay under about 5% of rows |
Three rules keep the coding reproducible:
- Write a codebook with three example URLs per code, taken from your actual data, before you code the bulk.
- Double-code a sample. Have a second person code 10% of rows independently and compare. Disagreement above roughly one in ten rows means the definitions are too loose — tighten them and re-code, rather than arguing case by case.
- Log every ambiguous decision with the reason. The
REV/DIRandED/AGGboundaries generate most of them.
Also code page_type separately from source type: comparison, listicle, review, documentation, news, thread, landing, other. Source type tells you who to approach; page type tells you what shape of page gets used, which is often the more actionable finding.
Reading the pattern: dominance, concentration, volatility
Three readings, in this order.
Dominance — what type leads. Share of citations by source type, split by model and by phrasing family. Do not report the blended number alone; the splits are the finding. A category where REV leads on one assistant and ED leads on another needs two different plans, not an average of them.
Concentration — how few domains carry it. Count how many distinct domains account for the top half of citations. A handful means a small set of sources effectively decides the category and your effort has an obvious focus. Dozens means influence is diffuse, no single placement will move much, and your own pages likely deserve more of the budget.
Volatility — how stable it is. Split your runs into two halves by run index or date and compare the type shares and the top domains. Sources that appear in one half and not the other are unstable and should not anchor a plan. Report volatility honestly; it is the difference between a finding and an anecdote.
While reading these, keep two cautions in view. Frequency is not endorsement — a source can be cited often and be wrong about you, which is a brand-safety issue rather than an opportunity. And a citation is not the same as a recommendation; the answer may cite a source while naming a competitor. Keep brand_mentioned in the analysis so you can tell those apart.
Turning the pattern into a shortlist of targets
Convert the reading into a short, defensible list.
- Take the domains and types that survive the volatility check.
- Remove anything with no legitimate route in. Scraper aggregates and platforms whose rules exclude your participation are not targets.
- Sort what remains by observed citation frequency against the effort of the legitimate route.
- Keep the list to a handful of items with named owners. A shortlist of twenty is a wish list.
The routes themselves — what each platform's own rules permit, and where participation stops and manipulation starts — are covered in earning cited sources. One thing to be clear about here: nothing in this method is a case for manufacturing presence on a dominant source. Discovering that a community or review platform carries most of your category's citations tells you where to participate openly under your real identity, not where to create accounts. Where a source is cited frequently and you have no honest way in, the correct output is "no action," written down.
Pair the source shortlist with the page-type finding. If comparison pages are what gets cited, the highest-return work may be publishing a genuinely useful comparison on your own domain, which sits inside a wider competitor teardown rather than in an outreach plan.
Re-running it, because the mix changes
A citation profile is a dated measurement, not a fact about your category. Models change, sources get created and abandoned, and competitors publish.
A workable cadence:
- Quarterly full re-run. Same prompt set, same models where the versions still exist, same run count. Report what moved and what did not.
- Monthly light run on a fixed subset of ten to fifteen prompts, as an early warning that something has shifted.
- Ad-hoc re-run after a known model update, a major change in your own publishing, or a visible competitor launch.
- Prompt-set review twice a year. Buyer language changes. Version the prompt set when you edit it, keep the old version, and never silently swap prompts between runs — that is the fastest way to manufacture a trend that is not there.
Record for every run: prompt-set version, models and versions, run dates, runs per prompt, coding scheme version, and who coded. If a finding cannot be traced back to that block, it is not a finding you should be defending in a budget meeting.
In Plain English
The general claim about which sources dominate AI citations is not usable for your decisions. Build a prompt set from real buyer language, run it repeatedly across the assistants your buyers use via official APIs, record every citation as a row, and code each one into a fixed source-type scheme.
Then read three things: which types dominate, how concentrated the domains are, and how stable the picture is across halves of your data. Split everything by model and by phrasing family, because both change the answer. Turn what survives into a short target list with owners, drop anything without a legitimate route in, and re-run quarterly with the prompt set and coding version recorded.
This helps most if you are about to commit outreach or content budget and have no evidence for the direction. If repeated measurement is not available, start with the competitive-intelligence protocol and apply the research evidence specification before treating a result as reusable evidence.
Download the competitor teardown worksheet to run the collection, coding, and reading steps in one sitting.
Primary-source verification
Checked July 28, 2026. The operational and factual guidance above was reviewed against the primary references below. Provider features, prices, policies, interfaces, jurisdictions, and account-specific results can change; recheck the controlling first-party document and your own account or measured data before acting.
- Google Search: AI features and your website - How Google describes eligibility, preview controls, and appearance in its AI search features.
- Google: common crawlers and special-case user agents - Current Googlebot and Google-Extended identities and controls.
- OpenAI: overview of OpenAI crawlers - Current GPTBot, OAI-SearchBot, and ChatGPT-User descriptions and publisher controls.
- Anthropic: web-crawler controls - Current ClaudeBot, Claude-SearchBot, and Claude-User descriptions and controls.
- Perplexity: crawler and user-agent documentation - Current PerplexityBot and Perplexity-User descriptions and controls.
- FTC: Endorsement Guides Q&A - Current U.S. regulator guidance on endorsements, disclosures, and reviews.
- FTC: Consumer Reviews and Testimonials Rule Q&A - Current U.S. rule guidance on deceptive review practices.