Half your AI citations aren't on your site

A business listing is a structured record of your company (name, address, phone, hours, category, description) held on a third-party platform such as Google Business Profile, Apple Business Connect, or a vertical directory, and in AI answers it behaves as a citation source that competes with your own website.

Most GEO advice treats your site as the whole surface area. Write the answer-first page, mark it up, keep it fresh, wait for the citation. That advice is fine as far as it goes, but it quietly assumes the engine is choosing between web pages. For a large class of questions it is not.

#The number that reframes the problem

Yext analyzed 6.8 million citations drawn from more than 1.6 million AI-generated responses across ChatGPT, Gemini, and Perplexity, collected between July 1 and August 31, 2025 (Yext). The source breakdown was closer than most teams expect: first-party websites accounted for 2.9 million citations (44%), and listings accounted for 2.9 million (42%), with reviews and social at 545,000 (8%) (Yext).

Put together, that is 86% of citations coming from records a brand can edit directly (Yext). The same analysis identified 20,820 unique citation domains, which is a useful reminder that the long tail is real even when a few platforms dominate the headlines (Yext).

The engines were not interchangeable. Gemini pulled 52.1% of its citations from websites, while OpenAI's model pulled 48.7% from listings (Yext). If you measure visibility on one assistant and assume the mix carries over, you will misread your own results.

#Why listings show up at all

The mechanism is not mysterious. When a question has any location or place dimension, the fastest reliable grounding available to a model is not a crawl of your site. It is a structured place record with a name, an address, a category, and hours.

Google is explicit that local results are "mainly based on relevance, distance, and prominence," and that prominence draws on links, review counts, and ratings (Google). Those inputs live largely outside your CMS. Google's own structured data guidance says a LocalBusiness record requires only name and address, and recommends telephone, url, openingHoursSpecification, geo, and aggregateRating (Google). That is the shape of the data an assistant wants when someone asks whether you are open on Sunday.

A page of prose cannot compete with that record on precision, and models appear to know it.

#Where the finding does not apply

This is the part most write-ups skip, so read it before you reorganize a roadmap.

First, the study is vendor research from a company that sells listings management. That does not make the numbers wrong, but it does mean the query set was built by people whose product benefits from a strong listings result. Treat it as a directional finding from an interested party, not as a neutral benchmark.

Second, the mix moves sharply by vertical. In the same analysis, healthcare saw 52.6% of citations come from listings and food service saw 41.6%, while finance saw 48.2% come from brand-owned websites and retail 47.6% (Yext). Those are different businesses with different answer surfaces, not one number with noise around it.

Third, and most important: if you sell B2B software with no physical premises, no service area, and no directory presence worth speaking of, the listings half of this result is largely not addressable by you. A developer asking an assistant to compare two API providers is not triggering a place lookup. Your citation competition is documentation, comparison pages, and third-party writeups. Applying a local-heavy citation split to a SaaS content plan is how teams end up optimizing a surface their buyers never touch.

The honest version of the finding is narrower and more useful: the more your category involves places, hours, coverage areas, or regulated provider directories, the more of your AI visibility sits in records you do not host.

#What to do if listings are in scope

Treat the listing layer as content with an owner, a review cadence, and a definition of correct. Three things carry most of the weight.

Make one description canonical. The category, the one-line description, and the service list should read the same everywhere, because an assistant reconciling four different self-descriptions has to pick one, and it may not pick yours. This is the same entity-resolution problem covered in our post on entity clarity, applied to records you do not control the rendering of.

Wire the graph explicitly. Schema.org defines sameAs as the "URL of a reference Web page that unambiguously indicates the item's identity," giving Wikipedia, Wikidata, and the official website as examples (Schema.org). Listing your directory profiles, your Wikidata entry if you have one, and your primary social accounts in the sameAs array of your Organization markup is the cheapest way to tell a machine that these scattered records are one company.

Fix the boring fields first. Hours, address formatting, phone, and category are the fields most likely to be quoted verbatim and most likely to be stale. A wrong closing time in an assistant's answer is a worse outcome than no citation at all, because it is confidently wrong and it is attributed to you.

#How this changes measurement

If you only track whether your domain appears in AI answers, you will undercount yourself in categories where listings carry the load, and you will have no idea when a directory is repeating a stale fact about you.

The fix is to track cited domains as a set rather than a boolean on your own URL. In our own audits, the useful question is not "were we cited" but "which record answered on our behalf, and was it right." Those are different failures with different owners: one is a content problem, the other is a data hygiene problem, and the second one is usually cheaper to fix and more embarrassing to leave alone.

The web page is still the thing you control most tightly. It is just not the only thing an assistant is reading about you.