Blog

Google’s Knowledge Graph is the database of real-world entities – people, places, organizations, things – that Google’s systems connect to each other and to search results; Google’s own documentation describes it as containing “millions of entries that describe real-world entities” where “these entities form the nodes of the graph.” A small site cannot submit, buy, or request a listing in it: there is no form for that. What a small site can do is make its own identity machine-readable – accurate Organization markup, a real sameAs profile link, a crawlable logo – and that markup is also the one documented, non-guaranteed input tied to whether a knowledge panel, if one ever exists, shows the right logo. This site’s own homepage currently ships exactly one sameAs link and no logo property at all, which is the honest starting point for everything below.

What platform documentation actually says

I went looking for a Google page that explains how a site gets into the Knowledge Graph, and found the opposite: a clear description of what the graph is, with no documented submission path at all. Google’s Knowledge Graph page states that “the Knowledge Graph has millions of entries that describe real-world entities like people, places, and things,” and that “these entities form the nodes of the graph.” The page also documents the Knowledge Graph Search API, and is specific about its limits: it “returns only individual matching entities, rather than graphs of interconnected entities.” Nowhere on that page, or anywhere else I could fetch directly, is there a form, a fee, or an application process for adding an entity. The graph is built from what Google’s systems already find and connect, not from a queue small sites can join.

The one documented lever a site does control is structured data, and the practical setup on WordPress starts with Organization markup on the homepage. Google’s own page on this says the markup “can help Google better understand your organization’s administrative details and disambiguate your organization in search results.” The property doing the identity work is sameAs, described as “the URL of a page on another website with additional information about your organization” – and Google is explicit that “you can provide multiple sameAs URLs.” Schema.org’s own definition sets a stricter bar for what belongs there: a sameAs URL should “unambiguously indicate the item’s identity,” the way a Wikipedia or Wikidata page would, not just any link that mentions the business. A logo property matters for a different reason: Google documents that it can “help Google better understand which logo you want to show, for example in Search results and knowledge panels,” with concrete technical requirements – a minimum of 112×112 pixels, a crawlable and indexable URL, a format Google Images supports, and an image that reads clearly on a plain white background.

Every one of those pages carries the same disclaimer, stated directly: “Google does not guarantee that features that consume structured data will show up in search results.” That line is the center of this whole topic. Structured data is an input Google’s systems may use. It is not a switch a site owner flips to turn a knowledge panel on. I cover the same input-versus-outcome distinction in more general terms in entity SEO for sites nobody has heard of, and the asymmetry shows up again on the citation side in whether schema markup actually helps AI citations – no documentation I have found, for knowledge panels or for AI answers, promises a result in exchange for correct markup.

What the independent evidence supports

Documentation describes the mechanism; it does not say how common correct entity markup actually is among real sites, so I checked the 2024 Web Almanac’s structured-data chapter for adoption numbers. JSON-LD, the format Google recommends, is present on 41% of pages measured, up from 34% in 2022. Narrow that to the specific type this topic depends on and the number drops hard: the Organization JSON-LD type appears on only 7.16% of pages, against 12.73% of mobile pages carrying the more generic WebSite type, and 3.97% carrying LocalBusiness. Read plainly: most sites that bother with structured data at all still skip the specific markup that identifies who they are as an organization. Getting this right is uncommon on its own, independent of whether it moves any particular outcome.

I want to be precise about what that adoption figure does and doesn’t support. It is a snapshot of how many pages carry a given schema type – not a measurement of what happened to the sites that carry it. The Web Almanac chapter makes no claim that adding Organization markup changed those pages’ visibility, and this article will not imply a causal link the data doesn’t carry. Google’s own general guidance on structured data reinforces the same caution from the other direction: “don’t create blank or empty pages just to hold structured data, and don’t add structured data about information that is not visible to the user, even if the information is accurate” – a warning against treating markup as a trick rather than an honest description. For how this discipline extends past schema into measurement practice generally, I’ve written separately about how to measure AI citations and about keeping the GEO, SEO, and AEO disciplines distinct rather than collapsing documented mechanism into measured outcome.

I also looked for, and could not verify, a specific list of “eligibility factors” that determine when a knowledge panel appears for a given entity. Google’s knowledge-panel help pages are JavaScript-rendered and returned no readable article text through the fetch tools available to me this session. What I could confirm, through Google’s own stated policy on claiming knowledge panels, is the shape of the process rather than its triggers: panels are generated automatically by Google’s systems, a “claim this knowledge panel” option exists only when a panel already exists and the claimer is eligible, and panels “update automatically as information changes on the web.” None of that describes how to make a panel appear in the first place – because, as far as I can verify, that part isn’t published.

A practical checklist

Given only what’s verified above, here’s what I’d actually implement on a small or unknown site – not to manufacture a knowledge panel, but to make the site’s identity as clear as the documentation says it can be:

• Add Organization JSON-LD to the homepage with accurate name and url fields – the markup Google says helps disambiguate your organization in search results.
• Set sameAs to real, verifiable profile URLs only – a GitHub repo, a LinkedIn page, a Wikidata entry if one exists – and add more than one if you have them; Google explicitly allows multiple.
• Add a logo property pointing to a crawlable image that meets the 112x112px minimum and reads cleanly on white, since it’s the one property Google documents as directly tied to knowledge-panel visuals.
• Keep name, URL, and identity details consistent across every page carrying the markup – inconsistency works against the disambiguation the markup exists to support.
• Do not expect a knowledge panel, a ranking change, or a citation as a direct consequence of any of the above – every primary source in this article disclaims that guarantee.
• If a knowledge panel already exists for your entity, look for the claim option rather than trying to trigger one into existing; claiming and creating are documented as two different things.

Honest limits of current evidence

I checked this site’s own homepage markup while writing this, rather than describing the Knowledge Graph only in the abstract. It currently ships Organization JSON-LD with a name, a url, and exactly one sameAs entry – a link to this project’s GitHub repository. There is no logo property anywhere in the homepage’s JSON-LD right now, which is the specific gap the documentation above ties most directly to knowledge-panel visuals. The site’s separate Person entity is further along, carrying three sameAs links across a personal site, GitHub, and LinkedIn. This site has no knowledge panel today, and nothing in this article changes that by itself – the evidence only supports making the inputs correct, not predicting the output. When a citation or panel-monitoring pipeline exists to check whether anything here moved a real signal, I’ll report it with the same discipline I’ve used elsewhere: state what’s measured, and say plainly when the answer is still zero.

Entity SEO means describing your business as one consistent, well-defined thing – same name, same URL, same logo, same linked profiles – in structured data on your own site, so Google’s systems have a clean record to match against everything else they already know. For a small or unknown site, entity SEO does not buy you a knowledge panel or a ranking boost on its own: Google’s own documentation states plainly that it “does not guarantee that features that consume structured data will show up in search results.” What you control is the input – accurate Organization markup, a sameAs property pointing to real off-site profiles, a crawlable logo – not the output. This site’s own Organization markup currently has one sameAs link and no logo property at all, which is exactly the kind of gap this article is about closing, not hiding.

What platform documentation actually says about entity SEO

“Entity SEO” is not a phrase Google’s documentation uses, so before writing anything else I went looking for what Google actually documents about entities, and how that maps to the practices the term usually describes. Google’s Knowledge Graph page is the clearest starting point: “The Knowledge Graph has millions of entries that describe real-world entities like people, places, and things,” and those entries – “these entities form the nodes of the graph” – are connected to each other, not just to keywords. An entity, in this framing, is a specific, identifiable thing: a person, a place, an organization. Your business is a potential node; the question entity SEO tries to answer is whether Google’s systems can identify that node confidently and consistently.

The practical lever Google documents for that is structured data, and adding it correctly on WordPress starts with Organization markup on the homepage. Google’s own page on the subject says this markup “can help Google better understand your organization’s administrative details and disambiguate your organization in search results.” The property doing most of the identity work is sameAs, which Google describes as “the URL of a page on another website with additional information about your organization” – think a verified social profile or a review-site listing, not a made-up link. Schema.org’s own definition is stricter about intent: a sameAs URL should “unambiguously indicate the item’s identity,” the way a Wikipedia or Wikidata page would. A logo property matters too, and Google is explicit that it connects directly to the feature most people mean when they say “entity SEO worked”: the markup “can help Google better understand which logo you want to show, for example in Search results and knowledge panels,” and can “influence visual elements in Search results (such as which logo is shown in Search results and your knowledge panel).” That’s the one explicit, documented thread I found tying structured data directly to knowledge panel display – not a guarantee, but a stated mechanism.

Every one of these pages carries the same caveat, stated outright rather than implied: structured data is an input Google’s systems may use, not a switch that turns features on. I go through the citation side of that same asymmetry separately in whether schema markup actually helps AI citations – the short version is that no documentation I found promises a result in exchange for correct markup, for AI answers or for knowledge panels.

What independent evidence supports

Documentation describes the mechanism; it says nothing about how common correct entity markup actually is, so I checked the 2024 Web Almanac’s structured-data chapter for adoption data. JSON-LD, the format Google recommends, appears on 41% of pages measured. Narrow that to the specific type this article is about and the number drops hard: the Organization JSON-LD type appears on only 7.16% of pages, against 12.73% of mobile pages carrying the more generic WebSite type. Read plainly, that gap says most sites that bother with structured data at all still skip the specific markup that identifies who they are as an organization – which means getting it right is already uncommon, independent of whether it moves any specific metric.

I want to be precise about what that adoption figure does and doesn’t support. It’s a snapshot of how many pages carry a given schema type, not a measurement of outcomes for the pages that do. Nothing in the Web Almanac chapter claims that adding Organization markup changed those pages’ visibility, and I’m not going to imply a causal link the data doesn’t carry. For the broader landscape this sits in, I’ve separately mapped how entity work overlaps with GEO, SEO, and AEO as distinct disciplines, and how the same honesty-about-evidence discipline applies to answer engine optimization for B2B SaaS more broadly: the documented mechanism and the measured outcome are two different claims, and conflating them is how fabricated statistics end up in SEO advice.

I also considered, and dropped, a commonly repeated claim tying Google’s 2013 Hummingbird update to a specific entity-based ranking timeline. I could not find a current Google source that documents a mechanism or timeline for that claim, so it isn’t in this article. Separately, Google’s Knowledge Panel help page would have been a natural source for a list of panel-eligibility factors, but the page is JavaScript-rendered and returned no readable article text through the fetch tools available to me this session – so that list isn’t here either. Both are reported here as gaps, not filled in from memory or secondary commentary.

A practical checklist

Given only what’s verified above, here’s what I’d actually implement for a small or unknown site:

• Add Organization JSON-LD to the homepage with accurate name and url fields – the markup Google says helps disambiguate your organization in search results.
• Set sameAs to real, verifiable profile URLs only – a GitHub repo, a LinkedIn page, a Wikidata entry if one exists – never a placeholder or an aspirational link.
• Add a logo property pointing to a crawlable image, since it’s the one property Google documents as directly influencing knowledge-panel and search-result visuals.
• Keep the organization’s name, URL, and identity details consistent across every page that carries the markup – inconsistency undermines the disambiguation the markup exists to support.
• Don’t expect a knowledge panel, a ranking change, or an AI citation as a direct consequence – every source in this article disclaims that guarantee explicitly.
• Re-check adoption against the next Web Almanac release rather than assuming this year’s 7.16% figure holds; structured-data adoption is measured annually and changes.

Honest limits of current evidence

I checked this site’s own homepage markup while writing this, rather than describing entity SEO only in the abstract. It currently ships Organization JSON-LD with a name, a url, and exactly one sameAs entry – a link to this project’s GitHub repository. There is no logo property anywhere in the homepage’s JSON-LD right now, which is the specific gap the documentation above says matters most for knowledge-panel visuals. The site’s Person entity is further along, with three sameAs links covering a personal site, GitHub, and LinkedIn. I’m reporting this as it stands, not as a success story: the organization-level markup is partial, and I have no citation-tracking or knowledge-panel-monitoring pipeline connected to tell me whether any of this has changed how this site shows up anywhere. When that measurement exists, the discipline I’ve described in how to measure AI citations applies here too – report what the data shows, including if it shows nothing yet.

An answer capsule is a short, self-contained paragraph near the top of a page that states the direct answer to the reader’s question before any supporting detail follows. Write it as plain, well-organized prose aimed at a human reader – Google’s own documentation says there is no special markup, no required file, and no content-chunking rule to satisfy for AI features specifically. Google’s systems decide on their own which passage gets elevated into a featured snippet or pulled into an AI-generated answer; the only lever site owners actually have is an opt-out, not an opt-in. Independent research on generative engine optimization has measured visibility gains as large as 40% from combined techniques, but that figure describes a research study’s aggregate result across methods and domains, not a promise attached to any single paragraph you write.

What platform documentation actually says about answer capsules

I read Google’s own developer guidance directly before writing anything else, because “answer capsule” is not a term Google uses, and I wanted to know what its documentation actually supports rather than what the broader AEO commentary assumes it supports. On featured snippets, Google states the decision plainly: “You can’t” choose to win one. Google’s systems determine whether a page would make a good featured snippet for a given search request and elevate it if so. There is no submission form, no tag, and no formatting trick documented anywhere that forces a passage into that position.

The only control Google documents in that same reference is an opt-out, not an opt-in: nosnippet, data-nosnippet on a specific section, and max-snippet for limiting length. Even that lever comes with a caveat in Google’s own text – using it “doesn’t guarantee” removal from every AI surface, only that it limits how the eligible text can be shown. If your goal is to be quoted, there is no equivalent opt-in switch; the write-up I did on the basics of answer engine optimization for B2B SaaS covers why that asymmetry shapes most of what’s actually controllable here.

Google’s separate guide to optimizing for generative AI features is more specific about what it does ask for, and it reads like ordinary editorial advice rather than a technical spec: “Write content for your human audience and make sure the content is well written and easy to follow.” The same page credits value to content organized “by paragraphs and sections, along with headings that provide a clear structure to navigate content” – which is a fair description of what a good answer capsule already looks like, minus any AI-specific dressing. The guide also mythbusts a claim I still see repeated in AEO and GEO comparisons: there is no requirement to break your content into tiny pieces for AI systems to understand it, because Google’s systems are described as capable of understanding “the nuance of multiple topics on a page” and surfacing the relevant piece on their own. On schema specifically, the pattern holds too – I go through the details separately in whether schema markup actually helps AI citations, but the short version is that no AI-specific structured data format is documented as required here either. Nor is any AI-specific text file: Google does not require an llms.txt or comparable markup file to be eligible for AI features at all.

What independent evidence supports

Documentation tells you the eligibility rules and the mythbusted tactics. It says less about whether structuring an opening paragraph as a direct-answer capsule specifically changes your odds of being cited, so I looked outside Google for that. The most concrete figure I found comes from the GEO research paper (Aggarwal et al.), which measured that a combination of generative-engine-optimization techniques could raise a source’s visibility in generative-engine answers by up to 40% in some domains tested. I want to be precise about what that number does and doesn’t say: it’s an aggregate result across a set of techniques and domains, not an isolated measurement of paragraph-opening format alone, and the paper’s own abstract doesn’t credit any single technique with the full 40% ceiling. I tried to pull the full paper for a per-technique breakdown and the source file wasn’t readable through the tools available to me this session, so I’m reporting the claim at the level of precision the abstract itself supports rather than guessing at an attribution I can’t verify.

That gap between “a combined-technique study shows real upside” and “this specific paragraph structure is what does it” is exactly the kind of distinction I try to hold onto in what actually gets a page cited by ChatGPT or Perplexity. Writing a clear, front-loaded answer is a reasonable bet given what both Google’s guidance and the GEO research point toward, but nothing I found this session lets me claim it in isolation moves a specific number for a specific page.

It’s also worth being clear about what the GEO paper is and isn’t measuring. It evaluates how sources are cited by generative-answer systems the researchers built their test harness around, using a fixed set of query-and-response scenarios – not a live, ongoing measurement of any particular website’s traffic or citation rate over time. A study built that way can tell you techniques exist that correlate with higher visibility inside its test conditions; it can’t tell an individual site owner what will happen to their specific page once it’s live in front of real user queries on real AI products. Treat the 40% figure as evidence that structure and clarity plausibly matter at the margins, not as a number you should expect to reproduce.

A practical checklist

Given only what’s verified above, here’s what I’d actually do when writing an answer capsule:

• Put the direct answer to the reader’s likely question in the first paragraph, in plain prose, before any background or caveats.
• Write it for the person reading it, not for a presumed AI parser – Google’s own guidance frames this as the entire ask, with no separate “AI-quotable” style layered on top.
• Skip content-chunking schemes built around an assumed AI-parsing limitation; Google’s documentation states directly that this isn’t required.
• Don’t build or maintain an llms.txt file expecting it to change citation odds – it isn’t part of Google’s documented eligibility criteria.
• Keep the rest of the page organized into clear paragraphs and sections with descriptive headings, since that’s the specific structural quality Google’s guidance credits, not a single opening line by itself.
• If a page’s business model depends on the click itself rather than being summarized for free, use nosnippet or data-nosnippet deliberately, understanding it limits ordinary Search snippets too, since the control isn’t AI-feature-specific.

Honest limits of current evidence

I want to state a gap directly instead of glossing over it. This site has no citation-tracking pipeline connected yet, so I can’t report how often – or whether – this site’s own content has actually been quoted by an AI engine. I’m not going to state a citation count, including a reassuring zero dressed up as a measurement, because none has actually been taken. I’ve written separately about how to measure AI citations once that kind of tracking exists, and the same discipline applies here: everything in this piece is grounded in platform documentation and one independent academic study, not in this site’s own citation data, because that data doesn’t exist yet. When it does, I’ll report what it actually shows, including if the honest answer turns out to be nothing measurable at all.

Google’s own documentation says there is nothing special to do for AI Overviews: no new file, no dedicated markup, no separate submission process. The eligibility bar is the same one Search has always used – get indexed, be snippet-eligible, meet the normal technical requirements. What you can actually influence is the same thing you could always influence: whether your content is worth citing in the first place, and whether Google can technically reach and understand it. What independent research adds is a harder number on the cost of not being cited: when an AI Overview appears, several studies converge on organic click-through rates dropping by roughly a third to over half for the page that used to sit in position one.

What Google’s documentation actually says you can influence

I read Google’s two most relevant developer pages directly rather than working from secondhand summaries, because this is exactly the kind of topic where confident-sounding advice outruns the source material. The first, AI features and your website, states plainly that there are no additional requirements to appear in AI Overviews or AI Mode, and no other special optimizations are necessary. Sites do not need to create new machine-readable files, AI-specific text files, or new markup to show up in these features – and there is no special schema.org structured data you need to add either.

The technical bar is unchanged from ordinary Search: to be shown as a supporting link in AI Overviews, a page must be indexed and eligible to appear in Google Search with a snippet, meeting the same requirements as regular Search results. If you want to limit or opt out of appearing in these AI features specifically, the same controls that have always governed snippets still apply – nosnippet, data-nosnippet for individual sections of a page, max-snippet, and noindex. There is no separate AI-specific opt-out mechanism; it’s the same levers, reused.

What the optimization guide mythbusts, and what it says actually helps

Google’s companion page, the guide to optimizing for generative AI features, is more useful precisely because it spends as much time debunking tactics as it does recommending them. It states the core requirement is “unique, valuable, good content,” and warns specifically against commodity content – content “often based on common knowledge, which could originate from anyone.” The instruction is direct: don’t “just recycle what others on the internet have already said, or could easily be produced by a generative AI model.”

On the tactics that get repeated in AEO and GEO discussions, the guide is unambiguous. Google Search itself doesn’t use llms.txt files, so adding one to your site neither helps nor hurts your visibility in these features – it’s inert as far as Google’s systems are concerned. There’s no requirement to chop your content into small chunks for an AI system to parse it. And you don’t need to write in some special declarative style purely to be more quotable by a generative AI feature; normal, well-structured writing is the ask, not a new dialect.

Structured data gets the same treatment I’ve covered in more detail on whether schema markup actually helps AI citations: it isn’t required for generative AI search, and there’s no special schema.org markup specific to AI Overviews. Google still recommends using structured data for its ordinary purpose – qualifying for rich results in standard Search – but that’s a normal SEO practice, not an AI Overviews shortcut. Sibling surface AI Mode gets the identical framing, which I went through separately in what changes for publishers under AI Mode; the two features share the same eligibility logic and the same absence of special tricks.

What the guide does say helps: clear technical crawlability so nothing blocks indexing, accurate local and shopping data surfaced through Business Profiles and Merchant Center where relevant, and genuinely useful, non-commodity content that demonstrates direct expertise rather than restating what’s already indexed a thousand times over. None of that is new advice. That’s the point the documentation itself is making – the same fundamentals that were always good Search practice are still the whole answer.

What independent evidence adds about the cost of not being cited

Documentation tells you the eligibility rules. It doesn’t tell you what happens to your traffic once an AI Overview actually appears above your result, so I looked for independently-run measurement rather than stopping at Google’s page. Ahrefs analyzed 300,000 keywords – 150,000 that triggered an AI Overview and 150,000 comparable informational keywords that didn’t – comparing March 2024 against March 2025. The study, run by Ryan Law and Xibeijia Guan and published April 17, 2025, found that the presence of an AI Overview correlated with a 34.5% lower average click-through rate for the top-ranking organic result, relative to similar keywords without one.

Pew Research Center published a separate short-read on July 22, 2025, built from real browsing-panel data rather than keyword-tool estimates, concluding plainly that “Google users who encountered an AI summary were less likely to click on links to other websites than users who did not see one.” The specific figures reported consistently across several independent write-ups of that same study put it at 8% of visits including a click on a traditional search result when an AI summary appeared, versus 15% when it didn’t – and only 1% of visits included a click on a source actually cited inside the AI summary itself.

I want to label the strength of this evidence honestly. These are two independently-run studies using different methodologies – keyword-panel CTR modeling in Ahrefs’ case, real browsing-panel data in Pew’s – and they land on different magnitudes (34.5% versus a roughly 47% relative decline implied by 15% dropping to 8%). They agree on direction and rough scale, not on an exact number, and neither is a Google-published figure. Google has publicly disputed conclusions drawn from studies like these, with reported statements calling the methodology “flawed” and “not representative of Search traffic,” and saying the company has “not observed significant drops in aggregate web traffic.” I’m reporting both the independent findings and Google’s on-record pushback rather than picking a side neither of us can fully verify from outside either company’s raw logs.

A practical checklist

Given what’s actually confirmed above, here’s what I’d prioritize, in order:

• Confirm the page is indexed and returns a normal snippet in regular Google Search first. AI Overview eligibility rides on ordinary Search eligibility – there’s no separate technical bar to clear.
• Don’t build an llms.txt file or chop content into artificial chunks expecting an AI Overviews advantage. The documentation states directly that neither does anything for Google Search specifically; that effort is better spent elsewhere.
• Treat structured data as a normal rich-results investment, not an AI Overviews lever. If you’re deciding how much time to spend on schema, decide it based on the rich-results case I’ve covered separately, not on an AI-citation promise Google’s own guide doesn’t make.
• Spend the time you were going to spend on AI-specific tricks on the thing Google’s guide actually asks for: content that states something the rest of the internet hasn’t already said, grounded in direct experience or verified fact rather than a restatement of common knowledge.
• If a particular page’s value depends on drawing a click rather than just being read inside a summary, expect that value to compress once an AI Overview starts appearing for its target query – the independent CTR studies above both point the same direction, even if they disagree on magnitude.
• Use nosnippet, data-nosnippet, or noindex deliberately if a specific page’s business model depends on the click itself and you’d rather opt out than be summarized for free – understanding that this also removes it from ordinary Search snippets, since the controls aren’t AI-feature-specific.

What this site hasn’t measured yet

I want to be direct about a gap rather than paper over it. This site has no citation- or appearance-tracking pipeline connected for Google AI Overviews specifically, and no measurement was taken as part of writing this piece. I’m not going to state an appearance count or a citation count, verified or otherwise, because neither was actually checked. I’ve written separately about how to measure AI citations in general, and the same discipline applies here: the independent CTR studies above describe industry-wide samples, not this domain, and the honest starting point for a small, early-stage site like this one is that the AI Overviews question is currently a documentation-and-industry-data question, not yet a measured-on-this-site question. That will change once there’s enough underlying Search volume here to measure against, and I’ll report it plainly, including if the answer turns out to be zero.

Google says there is nothing special to do for AI Mode. A page becomes eligible for an AI Mode citation the same way it becomes eligible for a regular search snippet: get indexed, meet Google’s normal Search technical requirements, and rank well against the query. No new file, no new markup, and no separate submission process exists. The parts that are genuinely new are how AI Mode assembles an answer from many pages at once, and how much of that answer, according to one independent study, now points back to Google’s own properties.

What Google’s documentation actually says

I went straight to Google’s own developer documentation rather than working from secondhand summaries, because this is exactly the kind of topic where speculation spreads faster than the source material. Two pages carry the load: the AI features and your website page, and the AI optimization guide.

The first page states plainly that there are no additional requirements to appear in AI Overviews or AI Mode, and no other special optimizations are necessary. Sites do not need to create new machine-readable files, AI-specific text files, or new markup to show up in these features. The eligibility bar is the same one Search has always used: to be shown as a supporting link in AI Overviews or AI Mode, a page must be indexed and eligible to appear in Google Search with a snippet, meeting the same technical requirements as regular Search results.

The second page makes the strategic framing explicit. Google states that the best practices for SEO continue to be relevant because its generative AI features are rooted in its core Search ranking and quality systems. From Google’s stated perspective, optimizing for generative AI search is optimizing for the search experience, not a separate discipline. That is a direct claim from the documentation, not my interpretation of it, and it is worth taking at face value: this isn’t a new channel with its own rulebook, it’s the same ranking system feeding a different output format.

How AI Mode decides what to cite

The documentation also explains the retrieval mechanism behind these answers. Google defines retrieval-augmented generation, which it also calls grounding, as a technique used to improve the quality, accuracy, and freshness of AI responses by relying on core Search ranking systems to pull relevant, up-to-date pages from the Search index. In plain terms: the model doesn’t invent citations, it queries the same index that powers regular Search, then writes around what it retrieves.

Both AI Overviews and AI Mode may use a technique Google calls query fan-out, where a single user question is expanded into multiple related searches behind the scenes. Because more advanced models can identify a wider set of supporting pages this way, Google says the result can be a broader and more diverse set of helpful links than a traditional results page would surface for the same query. Google positions AI Overviews as a way to get the gist of a complicated topic quickly, and describes AI Mode as particularly useful for queries that need further exploration, reasoning, or comparison across several options. If that framing holds, comparison-heavy and multi-part questions are where fan-out retrieval does the most visible work, which is one reason this topic overlaps so directly with how I think about GEO, SEO, and AEO as related but distinct disciplines.

What independent research adds, and where it disagrees

Documentation tells you what a system is designed to do. It doesn’t tell you what it actually does at scale, so I looked for independent measurement rather than stopping at the official page. An SE Ranking analysis dated February 2026, sampling 68,313 keywords across 20 industries and covering more than 1.3 million AI Mode citations, found that google.com itself was the single most-cited domain in AI Mode answers, at 17.42% of all citations. That is up from 5.7% in June 2025, roughly a tripling over that period.

The breakdown inside that Google-to-Google share is specific enough to be useful. Of citations pointing back to Google properties, 59% went to traditional Google Search results pages, 36.1% to Google Business Profiles, 1.7% to Google Support, and 0.1% to Google Flights. Once YouTube is included alongside those properties, Google-controlled domains accounted for roughly 20% of all AI Mode citation sources in that sample. I want to label the strength of this evidence honestly: it is one independent dataset from one vendor, not a Google-published figure, and it describes a specific sample window rather than the entire live system. It is directional evidence, not a guarantee about how any individual query will resolve.

I looked for a second study to corroborate the tripling figure and did not find one I could independently fetch and confirm during this research pass, so I’m reporting the SE Ranking numbers as a single, clearly sourced data point rather than as an established industry consensus. If Google’s own properties are absorbing a growing share of citations, particularly through Business Profiles and Search itself, that has a practical implication worth sitting with: a meaningful slice of AI Mode’s supporting links may not be competitive real estate for an independent publisher at all, regardless of how well the publisher’s page is optimized.

A practical checklist

Given what’s confirmed above, here’s what I’d actually prioritize, in order:

• Confirm the page is indexed and returns a normal snippet in regular Google Search first. AI Mode eligibility is gated on ordinary Search eligibility, not a separate check.
• Skip building an AI-specific text file or a new markup format for AI Mode specifically. The documentation states none is required, and inventing one wastes engineering time that could go toward normal Search fundamentals.
• Treat schema markup as a normal Search quality signal, not an AI Mode shortcut. I’ve covered the evidence on this directly in whether schema markup actually helps AI citations, and the conclusion there is consistent with what Google’s AI Mode documentation implies: markup helps machines understand a page, it does not buy placement.
• For comparison-style or multi-part queries in your niche, structure the page so a single section directly and completely answers one sub-question. Query fan-out rewards pages that answer a narrow slice cleanly, rather than pages that gesture at many topics at once.
• Watch how much of the answer space in your query set is already occupied by Google-owned properties before assuming a ranking problem. If Business Profiles or Google Search results are absorbing most citations for a given query cluster, better content on your own domain may not close that gap.
• Keep working the fundamentals shared across every AI answer surface. The overlap between AI Mode and the practices covered in how ChatGPT search sourcing works and how Perplexity’s sourcing differs is large: indexability, clear single-topic pages, and demonstrable expertise show up as prerequisites across all three systems, even though each one retrieves and cites differently underneath.

What this site hasn’t measured yet

I want to be direct about a gap rather than paper over it. This site does not have a citation-tracking pipeline connected for Google AI Mode specifically, and no measurement was taken as part of writing this piece. I am not going to state a citation count, verified or otherwise, because none was actually checked. That absence is itself useful information: if you’re deciding whether to invest in AI Mode citation tracking, the honest starting point is that most independent sites, including this one, do not yet have a clean way to see it. The SE Ranking figures above are the closest thing to hard data cited here, and they describe an industry sample, not this domain. Anything more specific than that would be a guess dressed up as an answer, and this site’s whole approach is built on not doing that.

Perplexity publishes detailed documentation about what its crawlers do: PerplexityBot indexes pages for search results, and a separate fetcher called Perplexity-User retrieves a page only when a user asks a direct question about it. What Perplexity does not document is how it ranks the pages it retrieves – its Search API guide describes filtering and content controls, not a ranking method. Independent evidence adds a live, unresolved dispute on top of that documentation gap: Cloudflare says Perplexity crawled disallowed sites using an undeclared, browser-mimicking identity in 2025, and Perplexity has publicly rejected that framing. On this site, referrals from perplexity.ai have been zero in every check I’ve run so far, and I’m reporting that number as it stands rather than waiting for a better one.

What Perplexity’s documentation actually says

Start with the part Perplexity does explain. Its Search API documentation describes an endpoint that returns real-time, ranked web results as structured data, and it documents the controls you’d expect: you can filter by domain, restrict by language or region, and tune how much retrieved content the model gets to work with via context-size settings. What the same page does not do is explain the ranking technique behind those results. There’s no published formula, no disclosed weighting of freshness versus authority versus relevance – just the fact that results come back ranked, without a description of how.

The crawler documentation is more specific, and worth reading carefully because it draws a distinction most SEO advice glosses over. Perplexity’s own crawler resource page states that PerplexityBot exists to “surface and link websites in search results on Perplexity” and explicitly says it “is not used to crawl content for AI foundation models.” The same page recommends allowing PerplexityBot in robots.txt if you want to appear in Perplexity’s results, though it stops short of an explicit promise that PerplexityBot will always obey a disallow rule – it’s a recommendation to allow-list, not a compliance guarantee spelled out in those terms.

Perplexity-User is a different animal entirely, and the documentation is unusually direct about it. It’s described as supporting “user actions within Perplexity” rather than search indexing, and the docs state plainly that “since a user requested the fetch, this fetcher generally ignores robots.txt rules.” That’s Perplexity’s own language, not a third-party inference: a live, user-triggered fetch is treated differently from a standing crawl, and robots.txt is not expected to stop it. Perplexity also publishes IP ranges and exact user-agent strings for both PerplexityBot and Perplexity-User so site owners can verify traffic against something more reliable than a user-agent header alone, which is the same kind of verification approach I’ve recommended when writing about what an llms.txt file can and can’t control on a WordPress site – a directive is only as good as your ability to confirm who’s actually reading it.

What the independent evidence supports

Outside Perplexity’s own documentation, the most concrete recent evidence is a dispute, not a settled fact, and I want to present it as one. In August 2025, Cloudflare published a post alleging that Perplexity used an undeclared, Chrome-impersonating user agent and rotated across different network ranges to keep fetching content from domains that had explicitly disallowed its declared crawler in robots.txt – Cloudflare’s own words describe this happening “across tens of thousands of domains and millions of requests per day.” That’s a serious, specific accusation from a company with visibility into a large share of global web traffic, and it names exact behavior rather than gesturing at a vague concern.

Perplexity disputed the characterization publicly, with the company’s response – reported by outlets covering the exchange – describing Cloudflare’s post as closer to a sales pitch or a publicity move than a technical finding. I’m not going to adjudicate that argument here; both sides have an incentive in how this story gets told, Cloudflare sells crawler-management tools and Perplexity sells an AI search product. What I can say with confidence is that this wasn’t the first time Perplexity’s crawling behavior drew scrutiny – an earlier investigation in June 2024 reported the company accessing a test site from unpublicized IP addresses despite a robots.txt disallow rule, which means the current dispute sits on top of an existing pattern of questions rather than arriving out of nowhere. If you’re deciding how much weight to put on any single crawler’s stated intentions, that history is worth knowing, in the same way I’ve argued that overlapping AI-search terminology deserves scrutiny in GEO versus SEO versus AEO – a label is not the same thing as a verified behavior.

A practical checklist

Given what’s actually documented versus what’s disputed, here’s where I’d focus effort:

• Allow-list PerplexityBot in robots.txt if you want your pages eligible for Perplexity’s search results at all – the documentation recommends this explicitly.
• Don’t assume an allow rule for PerplexityBot changes anything about Perplexity-User’s behavior; the docs describe the two as separate fetchers with separate purposes.
• Verify crawler traffic against Perplexity’s published IP ranges and user-agent strings rather than trusting the user-agent header alone, especially given the Cloudflare allegations about undeclared identities.
• Don’t treat “ranked web results” in the Search API docs as a description of an SEO ranking algorithm – it describes an output format, not a disclosed methodology you can optimize against.
• Read the Cloudflare-versus-Perplexity dispute as two companies with conflicting incentives making conflicting claims, not as a resolved technical verdict either way.
• If you’re building a broader AI-citation strategy, treat structural fixes like clean answer formatting and clear sourcing as more durable than reacting to any single crawler controversy – the mechanics I cover in how to get cited by ChatGPT and Perplexity hold regardless of how this particular dispute resolves.

Honest limits of current evidence

I don’t have a ranking formula to give you, because Perplexity hasn’t published one, and I’m not going to invent one dressed up as an estimate. I also don’t have an independent, large-sample study of what actually predicts citation frequency on Perplexity specifically, the way some researchers have attempted for ChatGPT – if that research exists and holds up, I haven’t found it verified enough to cite here. That’s a real gap, not a number I’m rounding down to zero for effect.

What I do have is this site’s own data, and I’m reporting it as-is: across the GA4 referral pulls I’ve run recently, sessions arriving from perplexity.ai have been zero every time, out of a small total session count overall. That’s a small sample from one site, not evidence about Perplexity broadly, and it may simply reflect that this site doesn’t yet have enough total traffic or enough Perplexity-relevant content for a citation to show up as a referral. I’m not framing zero as proof of anything beyond what it is – the current measured state of one site’s own numbers. The same caution applies to structured-data efforts more broadly, which is why I’ve been careful to describe schema’s effect on AI citations as still evidence-thin rather than a settled win when I’ve looked at it directly. When this site’s Perplexity referral count changes, up or down, I’ll report the new number here.

OpenAI has documented how ChatGPT decides to search, how it formats citations, and which crawlers control whether a site shows up at all – but it has not published a ranking formula for what actually gets cited. That split matters. The crawler-access and citation-mechanics questions have real, sourced answers you can act on today: allow OAI-SearchBot, do not confuse it with GPTBot, and structure pages so an answer can be lifted cleanly. The ranking-weight question – how much domain authority, link volume, or freshness matters – is still an open argument between independent researchers, not a documented fact. Treat any specific percentage you see attached to ChatGPT search ranking as someone’s estimate, not OpenAI’s word.

What OpenAI’s documentation actually says

Start with the model itself. In the Responses API, OpenAI’s own guide on web search as a tool states that the model decides whether to invoke search based on the content of the prompt. It is not forced to search on every request the way a search engine always returns a results page. If a query does not read like it needs current information, the model can answer from what it already knows and skip the search step entirely.

When it does search, the citations are structured data, not decoration. The same documentation describes citations as url_citation annotation objects that carry the source’s URL, title, and position in the response, and it requires that this citation be presented as a clearly visible, clickable link in any interface built on top of the API. A source that gets consulted but never surfaces as a link is not doing what OpenAI’s own guidance says a citation should do.

One parameter people over-read is search_context_size, the low/medium/high setting that controls how much retrieved content the model gets to work with. The documentation is explicit that this does not set an exact token count and does not guarantee a specific number of sources or citations back. Setting it to “high” does not mean more of your pages get cited; it means the model has more retrieved text available when it decides whether to cite anything at all.

The three crawlers, and why mixing them up costs you citations

Most of the actionable, verifiable work in this space is about crawler access, not content tricks. OpenAI runs three separate bots, and treating them as one is the most common mistake I see in robots.txt files. GPTBot is the training crawler. OAI-SearchBot is the one that retrieves and can cite pages for ChatGPT search. ChatGPT-User is a third, separate bot used for live, user-triggered fetches. Per OpenAI’s publisher documentation, these are configured independently – blocking GPTBot to opt out of training does not block OAI-SearchBot, and blocking OAI-SearchBot does not touch GPTBot or ChatGPT-User. If your goal is to stay out of citations while still controlling how your content is used elsewhere, or the reverse, you need to disallow the right bot by name, not just add one blanket rule and assume it covers all three. This is the same crawler-directive precision I’ve written about in the context of what an llms.txt file can and can’t control on a WordPress site – a directive file only works if it names the right agent.

There is also an edge case worth knowing before you rely on robots.txt as a full opt-out. OpenAI’s documentation notes that disallowing OAI-SearchBot does not necessarily remove a site from every surface ChatGPT touches – in ChatGPT Atlas, a link and title sourced from a third-party search index can still appear even when your own crawler access is blocked, because that surfacing pathway does not depend on OAI-SearchBot fetching your page directly. A noindex meta tag is the documented way to suppress that fallback path if full removal is the goal. If your actual objective is inclusion rather than exclusion, the practical steps overlap with general AI-citation hygiene, which I’ve laid out in more detail in how to get cited by ChatGPT and Perplexity.

What independent research adds – and where it disagrees

Past the documented mechanics, you are in estimate territory, and the estimates do not agree with each other. I looked for an official OpenAI statement describing how much weight domain authority, content freshness, or any other factor carries in citation selection, and did not find one. No such formula has been published. That absence is itself the useful fact: any number you see online describing exact percentage weights for ChatGPT citation ranking is a third party’s reverse-engineered estimate, not something OpenAI has confirmed.

Independent researchers who have studied citation patterns do not converge on a single answer either. One analysis found only a weak correlation, around 0.27, between a site’s raw domain authority and how often it gets cited. A separate large-sample study from SE Ranking, covering roughly 129,000 domains, found that referring-domain counts correlated more strongly with citation frequency than authority scores did. A third analysis, looking at which sources tend to get cited together, found a much stronger co-occurrence correlation, around 0.74. These numbers are not measuring identical things, and I am not going to average them into a false consensus. The honest read is that authority and backlinks probably matter to some degree, multiple independent groups disagree on how much, and none of them are OpenAI. Some of this same measurement uncertainty is why I’ve argued that schema markup’s effect on AI citations is still evidence-thin rather than a settled win, and why the terminology fight over GEO versus SEO versus AEO mostly obscures how little of this is actually standardized yet.

A practical checklist

Given what is actually documented versus what is disputed, here is where I would spend effort first:

• Check your robots.txt for OAI-SearchBot specifically. Confirm it is not disallowed, unless staying out of ChatGPT search results is the explicit goal.
• Do not assume a GPTBot rule covers OAI-SearchBot or ChatGPT-User. Write separate directives for each bot you actually intend to control.
• If you want full removal from ChatGPT surfaces, including the Atlas fallback path, add a noindex meta tag rather than relying on robots.txt alone.
• Write pages so a single paragraph near the top can be lifted as a self-contained answer – this is a formatting choice, not a ranking hack, but it affects whether a citation is even usable once your page is retrieved.
• Ignore any specific percentage-weighted ranking formula you encounter online. None of it traces back to an OpenAI publication.
• Treat domain authority and backlink volume as plausibly relevant, not proven, and do not restructure your entire content strategy around a single correlation study.

What this site hasn’t measured yet

In the interest of reporting this honestly rather than picking a flattering number: I have not connected a citation-tracking pipeline for AI answer engines to this site, and I did not run one for this article. I don’t know how often, or whether, organicos.shivaatripathi.com currently gets cited in ChatGPT search results. That is a gap in my own measurement, not a claim of zero, and not a claim of some other number I have not actually checked. When I do build that measurement, I will report the real figure here, including if it turns out to be zero.