Getting cited by AI search — how to be the answer, not the tenth blue link

Search used to end with a list. You typed a query, you got ten links, and your job as a publisher was to be one of them — ideally the first one. Everything we called SEO was built around that single objective: win the position, earn the click, convert the visitor.

That contract is coming apart. A growing share of questions now get answered by a model that has already read the pages for you. ChatGPT with browsing, Claude, Perplexity, Google's AI Overviews — they retrieve candidate documents, synthesise an answer, and attach a handful of citations. The user reads the synthesis. Most of them never click.

This changes the unit of success. It is no longer "rank #1 for this query." It is "be the passage the model quotes when it answers this question." Those are related goals, but they are not the same goal, and optimising for the first does not automatically get you the second.

The pipeline you're actually competing in

An answer engine is a retrieval system with a language model on the end. Understanding the sequence tells you where you can win.

Roughly: the question gets rewritten into search queries; those hit an index (sometimes a conventional web index, sometimes a proprietary crawl); top documents are fetched and split into chunks; the chunks are ranked against the question; a handful survive into the model's context; the model writes an answer and cites what it leaned on.

Every stage is a filter you can fail. Never crawled, you're out at stage two. Content that only exists after JavaScript runs, you may be out at stage three. One long undifferentiated argument with no clear boundaries, your chunks come out as fragments and lose the ranking stage. A paragraph that reads as a partial thought when lifted out of its surroundings gives the model nothing quotable, so it picks someone else.

That last filter is the one most content fails, and the one classic SEO never had to think about. Ranking is about whole documents. Citation is about individual passages surviving decontextualisation.

Zero-click is the point, not the problem

The standard complaint about AI search is that it steals traffic. That's half true and mostly beside the point.

Yes: if the model answers the question completely, the user doesn't visit you. But the citation is still an impression — your name, attached to a correct answer, in front of someone who was actively looking. That's closer to being quoted in a trade publication than to a lost pageview. For anything with a considered purchase behind it — B2B software, agencies, professional services — being the source a model reaches for repeatedly is worth more than a bounce.

The strategic mistake is withholding the answer to force the click. Answer engines route around teasing, gated content by picking a competitor who just answered the question. You win the answer layer by being the most useful thing to quote, then earning the click on depth the summary can't compress: the full reasoning, the tooling, the actual work.

What actually changes versus classic SEO

Most SEO fundamentals still apply. Crawlability, speed, internal linking, topical authority — none of that stopped mattering. But the target moved, and several priorities invert.

The row worth staring at is rendering. Google's crawler executes JavaScript and has for years, so a client-rendered React app usually still gets indexed. That grace does not extend to the broader set of AI crawlers, many of which fetch the HTML and parse it without ever running a browser. If your content is assembled client-side, a meaningful fraction of retrieval systems see an empty shell.

For a Next.js site this is a discipline problem rather than a technical one. Server components and static generation give you real HTML for free; use client on a content component quietly takes it away. Test it the way a crawler would — curl the URL and read what comes back. If your article body isn't in that response, it doesn't exist to a large part of the answer layer.

curl -s https://techkis.com/insights/getting-cited-by-ai-search | grep -c "answer engine"

Structured data: give the machine a skeleton

JSON-LD doesn't get you cited by itself. What it does is make you unambiguous — it tells a retrieval system what this page is, who wrote it, when, and how it relates to everything else you publish. Ambiguity is what makes a system reach for a source it's more confident about.

The types that carry weight for most sites are small in number. Organization on the site root, with a stable name, URL, logo, and sameAs links to your real third-party profiles. Article (or BlogPosting) on every post, with headline, datePublished, dateModified, and a real author. BreadcrumbList so hierarchy is explicit. FAQPage where you genuinely have question-and-answer content. Service if you sell defined services.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Getting cited by AI search",
  "datePublished": "2026-07-09",
  "dateModified": "2026-07-09",
  "author": { "@type": "Organization", "name": "TechKis" },
  "publisher": {
    "@type": "Organization",
    "name": "TechKis",
    "sameAs": ["https://www.linkedin.com/company/techkis"]
  }
}

The underrated part is consistency. An entity becomes resolvable when the same name, the same description, and the same URLs appear across your own pages and the third-party profiles you point to. Mismatched names across your site, your LinkedIn, and your GitHub give a system three weak candidates instead of one strong one. Pick the canonical form and never deviate from it.

llms.txt, and an honest caveat

llms.txt is a proposed convention: a markdown file at your domain root that gives models a curated map of your site — what you do, and links to the pages worth reading. llms-full.txt is the maximal version, the actual content inlined so a model can ingest the whole site in one fetch.

We publish both on this site, at /llms.txt and /llms-full.txt. We also want to be straight about what that buys us: nothing proven. It is a community proposal, not a standard, and no major provider has publicly committed to using it as a ranking or retrieval signal. Anyone selling you "llms.txt optimisation" as a growth lever is selling you a guess.

The honest case for doing it is cost. If you already generate a sitemap from your content, generating a markdown index from the same source is an hour of work and near-zero maintenance. It's cheap insurance on a convention that might matter later. Do it for that reason, and don't let it displace the work that definitely matters — server-rendered HTML and content worth quoting.

robots.txt and the AI crawlers: a real trade-off

There is a specific set of user-agents fetching pages for AI systems. The main ones are GPTBot (OpenAI), ClaudeBot (Anthropic), PerplexityBot (Perplexity), and Google-Extended (Google's control for AI training and grounding, which is a robots.txt token rather than a distinct crawler). Each is documented publicly by its operator, and each respects robots.txt.

User-agent: GPTBot
Allow: /

User-agent: ClaudeBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Google-Extended
Allow: /

Blocking them is a legitimate choice with a real cost. If your content is the product — a paywalled archive, a subscription research business, licensed material — keeping it out of models protects the thing you sell, and publishers with that model have chosen to block for defensible reasons. If your content is marketing for something else you sell, blocking removes you from the answer layer entirely while your competitors stay in it. You do not get partial credit for being uncrawled.

Worth knowing: training and retrieval are different uses, and the available controls don't map cleanly onto that distinction. Some operators publish separate agents or tokens for each; some don't. If your position is "fine to cite, not fine to train on," expect to express it imperfectly and to revisit it as the controls evolve.

Writing for extractability

This is where most of the leverage is, and it costs nothing but discipline. The question to hold in your head while writing: if a model lifted this paragraph out with no surrounding context, would it stand on its own?

Answer in the first sentence under each heading. Not context, not a wind-up. If the heading poses a question, the sentence beneath it should answer it, and the rest of the section should support that answer. This is the inverted pyramid, and it exists because it survives truncation.

One idea per paragraph. A paragraph carrying three ideas ranks poorly for all three, because its embedding is a blurry average of them. Split it.

Define terms inline. Write "reranking — scoring retrieved candidates against the query with a second, more accurate model" the first time you use it, not three sections later. A chunk containing both the term and its definition is a complete answer; one containing only the term is a dangling reference.

Prefer specific numbers to adjectives. "Cuts prefill latency" is weak. "Cuts a 40KB payload to 6KB" is quotable. Specificity is what makes a passage worth citing rather than paraphrasing — and paraphrase without attribution is exactly what you're trying to avoid.

Use tables and definition lists for comparisons. Structured content chunks cleanly and reads as authoritative because the boundaries are explicit. A comparison written as flowing prose gets sliced in half.

Date everything and name the author. Visible dates in the page, matching dates in the JSON-LD. Models and their rankers use recency as a tiebreak, and undated content looks stale by default.

Measuring something you mostly can't see

There is no clean analytics answer here, and anyone claiming precise "AI citation share" numbers is estimating. What you can do:

Watch referrals from chat hosts. Users who do click arrive with referrers like chatgpt.com or perplexity.ai. It's a small, biased sample — it counts only the clicks, not the citations — but it's a real signal and it's free.

Probe the assistants on a schedule. Once a month, run a fixed list of prompts — branded ("what does TechKis do?") and unbranded category questions you'd want to own — against each major assistant, and log whether you appear and what gets quoted. Crude, manual, and by far the most direct evidence available. Keep the prompt list stable so the results are comparable.

Check Search Console for AI Overview impressions. Google folds AI Overview appearances into Search Console data. It isn't broken out cleanly, but pages with high impressions and unusually low click-through are often being summarised rather than clicked.

Track the input, not just the output. Server-rendered HTML on every content page, valid JSON-LD, correct dates, AI crawlers unblocked. These are binary and checkable in CI. Since the outcome is hard to measure, hold yourself to the preconditions.

TL;DR

Answer engines retrieve, chunk, rank, and synthesise. The unit of success moves from the ranking page to the quotable passage, and a citation is a real impression even when nobody clicks.

Ship server-rendered HTML — many AI crawlers never execute JavaScript, so client-only content is invisible to them. Add JSON-LD for Organization, Article, BreadcrumbList, and FAQPage, and keep entity details identical across your site and your third-party profiles.

Publish llms.txt because it's an hour of work, not because it's proven. Decide deliberately on GPTBot, ClaudeBot, PerplexityBot, and Google-Extended: block if content is the product, allow if content sells the product.

Write for extraction — answer first, one idea per paragraph, terms defined inline, numbers instead of adjectives, tables for comparisons, dates on everything. Measure by chat-host referrals, scheduled manual prompt probes, and Search Console.

The durable moat is being genuinely worth quoting: original data, clear positions, honest specifics. Thin content used to land on page two. In the answer layer it doesn't land at all — a model synthesising from five sources has no reason to pick the one that only restates the other four.

If you're rebuilding a site to be readable by machines as well as people, let's talk.