How to get your website cited by ChatGPT and Claude
The practical playbook for getting your site cited by ChatGPT, Claude, and AI Overviews: structured data, llms.txt, semantic HTML, and quotable writing.
Ask ChatGPT to recommend a business coach for founders in your city. Then ask Claude. Then read Google’s AI Overview for the same question.
Three answers, each with a short list of names, each with a couple of sources cited underneath. Somebody is on those lists. If it is not you, the reason is almost never that your work is worse. It is that your website is difficult for a machine to read, quote, and attribute.
This article is the whole playbook, including the parts that are inconvenient for us to admit. Everything in it you can do by hand on any platform. At the end I will tell you what StoryPages does automatically, because that is the honest order to put it in.
An AI assistant does not rank pages. It reads a few of them and looks for a sentence it can stand behind. Your job is to be the site that has that sentence, in a form it can lift.
How assistants actually find and choose sources
There are three separate paths and they behave differently.
Training data. The model absorbed a snapshot of the web at some point in the past. You cannot influence this quarter’s answers through it, and you cannot remove yourself from it. Ignore it as a tactic.
Live browsing. When the assistant decides it needs current information, it runs one or more searches, gets back a modest list of results, fetches a few, and reads them. This is the path you can influence. Note how narrow the funnel is: a handful of URLs, not ten blue pages, and the assistant then has to find a passage worth quoting inside whatever it fetched.
Retrieval-augmented answers with citations. Perplexity, AI Overviews, and similar surfaces do a version of the above with the citation shown inline. Same mechanics, more visible attribution.
So being cited is two problems stacked. First be retrievable — indexed, fetchable, fast, and topically obviously relevant. Then be quotable — contain a self-contained claim the model can attribute without risk.
Most people who ask us about “AI SEO” have only thought about the first one.
Structured data: the types that earn their keep
Structured data is JSON-LD in your page’s head that states, unambiguously, what
the page is about. It removes guesswork. A model reading prose has to infer that
“we’ve been doing this since 2011” means a founding date; foundingDate says it.
The types that actually matter for an expert or small-business site:
- Organization (or LocalBusiness if you serve a place) — name, URL,
logo,
sameAslinks to your profiles, contact point, address. - Person — for the named expert. This is the one authors and consultants most often skip, and it is the one that ties your name to your claims.
- WebSite — with
publisherpointing at your Organization. - Article / BlogPosting — headline, author as a
Personreference,datePublished,dateModified. - FAQPage — only where the page genuinely answers questions. It is a gift-wrapped question-and-answer pair, which is exactly the shape an assistant wants.
- Service or Product — what you sell, described as an entity rather than a paragraph.
- BreadcrumbList — cheap, and it tells a reader where the page sits.
Two rules matter more than the list. Use @id and reference entities instead
of repeating them, so your Person on the about page and your Person on the
article byline are the same entity rather than two people with the same name.
And never assert in schema what the page does not say in prose. Contradiction
is worse than absence, and it is the fastest way to be treated as unreliable.
llms.txt, honestly
llms.txt is a plain Markdown file at the root of your domain that tells a
language model what your site is and where the important pages are. It is a
proposal, published in 2024, that spread quickly because it is trivially easy
and obviously sensible.
Here is what an honest status report sounds like: the major model providers have not publicly committed to reading it. Adoption is real among tools, agents, and developer-facing sites; it is not a ratified standard, and nobody should tell you it is the reason you got cited.
We publish one anyway, and we ship one with every site we build, for three reasons. It costs nothing. Agents and internal tooling do read it. And writing it forces you to answer “what is this site, in one paragraph, and which ten pages matter” — which is a useful exercise even if no machine ever opens the file.
A minimal, correct one looks like this:
# Fielding & Co — executive coaching for technical founders
> One-to-one coaching for engineers stepping into leadership roles.
> Based in Berlin, working in English and German. Founded 2016.
## Core pages
- [Coaching programme](https://example.com/coaching): six-month one-to-one
engagement, structure, pricing, and how to apply.
- [About Anna Fielding](https://example.com/about): background, credentials,
and clients served.
- [Contact](https://example.com/contact): how to book an intake call.
## Writing
- [Articles](https://example.com/blog): essays on the engineer-to-manager
transition.
## Optional
- [Press kit](https://example.com/press): bio, headshots, speaking topics.
That is the whole format: an H1 with the site name, a blockquote summary, then H2 sections of annotated links. The annotations are the valuable part. “Coaching programme” tells a model nothing; the sentence after the colon tells it everything.
Semantic HTML and heading structure
An assistant extracting a passage needs to know where the passage begins and ends, and what it belongs to. That is what semantic markup provides.
Practically:
- One
<h1>, describing the page, not your brand. <h2>s that read like the questions a person would ask. “How much does it cost” outperforms “Investment” — for humans too.- Real
<article>,<nav>,<main>,<footer>elements instead of a hundred nested<div>s. - Tables as
<table>with headers. Lists as<ul>. A model can parse a table; it cannot parse a picture of a table. - Descriptive
alttext, because for a text-only fetcher your image is itsaltattribute and nothing else. - Text as text. Prices, hours, phone numbers, and credentials baked into images are invisible.
None of this is new advice. What changed is the cost of ignoring it. A screen-reader user could work around your div soup; a fetcher that reads your page once, for two seconds, will not.
Speed and static delivery
AI fetchers are impatient in a way that Googlebot is not. They are working inside a conversation where a human is waiting. Slow pages get abandoned, and several fetchers execute little or no JavaScript.
Which produces a specific, unromantic requirement: your content must be in the HTML that arrives in the first response. Server-rendered or statically generated, on a CDN, no client-side hydration standing between the fetcher and your claims.
This is why we build static pages and treat it as an AI visibility feature rather than a performance one.
Being quotable, which is the part almost nobody does
Here is where most sites lose, even technically clean ones. The markup is fine and there is still nothing to cite, because the page never says anything specific enough to attribute.
Compare:
We offer bespoke solutions tailored to your unique needs, leveraging decades of combined industry experience.
A six-month engagement, twelve sessions, £4,800. We work with engineers who have been managing a team for less than two years.
The first paragraph cannot be quoted, because quoting it conveys nothing. The second answers three questions a buyer actually asked.
What makes a passage quotable:
- Self-contained. It makes sense lifted out of the page, with no “as mentioned above”.
- Specific. Numbers, durations, names, constraints, prices, geography.
- Front-loaded. The claim in the first sentence, the reasoning after. The inverted pyramid, for the same reason journalists use it.
- Answering a real question. Write the H2 as the question, then answer it in the first forty words, then elaborate.
- Honest about limits. “We do not work with pre-seed founders” is highly quotable and it filters your enquiries for free.
A useful test: take any paragraph on your site, paste it alone into a document, and ask whether a stranger could tell what it claims and who claims it. If not, no assistant will risk citing it either.
Entity consistency across the web
Assistants corroborate. If your site says one thing and every other mention of you says something slightly different, the safe move is to cite somebody else.
So make the boring details identical everywhere — site, LinkedIn, Crunchbase,
directories, podcast bios, your publisher’s author page: the same business name,
the same spelling of your own name, the same city, the same one-line
description, the same URL. Then link them: sameAs in your Organization and
Person schema, pointing at each profile, and links back where you control them.
This is unglamorous and it is often the difference between being a name and being a verified entity. Two variants of your company name across the web is two half-strength entities.
Where the CRM actually comes in
One thing worth saying, because AI visibility is usually discussed as if traffic were the goal. It is not. An assistant recommending you sends a small number of unusually well-qualified people, already convinced, arriving on a page that should capture them.
If a form submission lands in an inbox and nowhere else, you will lose them to the four days it takes you to notice. Enquiries should land in a CRM with a source attached, so you can eventually answer the question “how many of this year’s clients arrived through an AI recommendation”.
The order to do this in
If you have limited time, this is the sequence we would follow:
- Make sure the content is in the initial HTML and the page is fast.
- Fix headings so they read as questions, and one
<h1>per page. - Add Organization, Person, and WebSite schema with
@idreferences, plus Article on posts. - Rewrite your three most important pages to be specific and self-contained.
- Make your name, description, and URL identical everywhere you appear.
- Publish an
llms.txtwith annotated links. - Ask the assistants your buyers’ questions once a month and write down what comes back.
Steps four and five are the ones people skip and the ones that matter most. Steps one, two, three, and six are the ones a platform should just do for you.
What we ship by default
That last sentence is our whole product opinion. Every site StoryPages builds
ships structured data, an llms.txt, semantic HTML, and static pages, without
you asking, because we do not think this should be an upsell or a checklist.
We hold this site to the same rule: it publishes its own llms.txt and full structured data, and you are welcome to read both. The mechanics are documented on AI visibility, the build path is on how it works, and if you want to interrogate your own site’s content from inside Claude or ChatGPT there is an MCP server for that.
If you are an author, a consultant, or a coach — the people we mostly build for — the practical version is: describe your business once, approve the plan, and the machine-legibility is already handled. Then spend your time on the part no platform can do for you, which is having something specific and true to say.