How do I optimise my website so LLMs cite it?
CANLAH AI optimises a website for LLM citation by repairing the machine-reading layer: unblocking AI fetchers, rewriting sections so each one survives being cut out of the page, and reclaiming the name string a resolver matches — a string that, for most brands, a directory or a platform wrote first.
What is LLM SEO, and how is it different from SEO?
LLM SEO is a misleading name. Nothing published on a public website touches a model's weights. What a technical lead can actually change sits between the page and the model: the fetch, the parse, the chunk, and the organisation a passage gets attributed to. That layer is dull, concrete and testable.
LLM SEO is optimisation of the machine-reading layer, not of a model
LLM SEO is the work of making a page readable by the software that reads on a user's behalf: the crawler that fetches it, the parser that strips it to text, the chunker that splits it into passages, and the resolver that decides which organisation a passage belongs to. Almost all of the risk sits in fetcher access, passage self-containment, and entity-string consistency. Most items on a typical LLM SEO checklist are downstream of those layers, and several popular ones are downstream of nothing measurable at all.
What is LLM SEO, and how is it different from SEO?
The unit of citation is the passage, not the page
A model rarely cites a page. It cites a passage that survived retrieval and made a claim clean enough to restate. That changes how a page gets written. A section that only makes sense after the sections above it cannot be lifted, so it cannot be cited, however good the argument inside it is. The working test is blunt: paste a section into a blank document, read it cold, and check that it still states something true, scoped, and attributable to a named organisation.
SEO wins the retrieval slot; LLM SEO decides what gets quoted from it
In most cases the two disciplines share a workload: crawlability, internal linking, render performance, topical coverage. The divergence is narrow and it matters. Classic SEO competes for a position in a list; LLM SEO competes to be the passage a generator finds easiest to restate accurately. A site can win the first contest and lose the second, which is why the two surfaces need separate diagnosis rather than one blended score.
Is there an LLM index of your site to optimise against?
The costliest misreading of this term is that a model somewhere holds a ranking function for your domain, and that the job is to move a score inside it. No such score exists, and chasing it burns the budget the access layer needed.
There is no model-side score to chase
Most assistants do not maintain an index of a site. They query a retrieval layer — often a conventional search index — then fetch live pages to compose an answer. So there is no model-side score and no algorithm update to react to. There is a fetch that succeeds or fails, a chunk that stands alone or does not, and a name string that resolves to your organisation or to a competitor's. All of that is inspectable from your own infrastructure, today, without a vendor.
Training data and answer citations are different pipelines
A model's training corpus is fixed long before a buyer types a question, and nothing published this quarter enters it in time to matter. Citations inside a live answer come from retrieval, not from memory. Teams that conflate the two optimise for an event that already happened. Write for the retrieval path — fetchable, chunkable, attributable — and treat any training-corpus effect as a side benefit that nobody can measure or invoice for.
Instructions addressed to the model are not a tactic
Hidden directives in page copy, white text aimed at an assistant, comment blocks that instruct a crawler: none of it survives extraction, and all of it gets caught. Publishers have lost distribution for less. The honest surface area is the one an engineer already controls — response headers, rendered HTML, markup fields, and the records third parties hold about the organisation.
Can an AI fetcher actually reach the page?
Access failures are the cheapest and most common cause of zero citations, and this is the only layer where a wrong setting produces a hard zero rather than a weak result. Audit it before writing a word of new content, because content behind a blocked fetch has no measurable value.
AI crawlers are not covered by your Googlebot rules
AI crawlers announce themselves with their own user agents, and rules written for a search crawler do not apply to them. A disallow added during a scraping incident, an allowlist that predates the current crop of agents, or a directive copied from a template will each remove the page from consideration silently — no error, no report, no ranking drop to notice.
Training, retrieval and live fetching are separate consent decisions
A crawler collecting training data, a crawler building a retrieval index, and a fetcher pulling a page because a user asked a question this second are distinct agents with distinct user-agent strings. Blocking every one of them to stop the first is a common self-inflicted wound on this layer. Decide per agent, in writing, record the decision with a date, and re-read the file when a new agent appears — a disallow added during an incident outlives the incident by years.
Verify from outside your own network
Issue a request that carries the AI agent's user-agent string from an address outside your own network, and read the body that comes back rather than trusting the response status. Office IP allowlists, staging redirects and cached edge rules all make a page look reachable from a desk and unreachable from anywhere else. Repeat the check after every infrastructure change, because this setting drifts without anyone editing it deliberately.
What blocks a fetch without showing an error?
The blocks that matter most sit above robots.txt and return a valid-looking response, so nothing appears broken from outside. Each one is invisible in analytics and obvious in a raw server log.
Bot mitigation returns a page that is not your page
Managed challenges, rate limits and geographic rules refuse fetches while returning a body that parses cleanly. The fetcher receives a challenge document, extracts whatever text it contains, and moves on. Nothing in the response status says the content was withheld. Allowlist the agents you have consented to at the edge, not only in robots.txt, and confirm the allowlist survives the next vendor configuration push.
Consent overlays and login walls gate the part that matters
A cookie interstitial or a registration wall that covers the article body has the same effect as a disallow, with none of the visibility. The page returns a success status; the answer text simply never appears in the fetched HTML. If a passage is meant to be cited, it belongs above the gate — and deciding which passages those are is a commercial choice, not a technical one.
Client-side rendering leaves a fetcher holding the shell
If the article text arrives only after JavaScript executes, assume a fetcher may see the shell. Server-render the body copy, keep visible text in the HTML source rather than in a hydration payload, and remove redirect chains and soft error pages that return a success status with an empty body. None of this is new advice; what changed is the tolerance. A search crawler returns tomorrow and forgives a bad render. A one-shot fetcher answering a live question does not.
How do you write a passage an LLM can lift?
This is the layer most teams get wrong while doing everything else right. It is a writing constraint rather than an engineering one, but a machine enforces it, so it can be specified as precisely as a lint rule and reviewed the same way.
Question as heading, answer as the very next element
The strongest pattern in CANLAH AI's citation records is dull: a literal question as a heading, and the answer as the immediately following element, with nothing between them. Put the organisation name first in the answer sentence. If a reader has to scroll past a narrative build-up to reach the sentence that answers the heading, an extractor will usually take the build-up instead, and the resulting quotation is vague rather than wrong — which is worse, because a vague quotation cannot be corrected.
Self-containment means no orphan references
Delete 'as mentioned above', 'this approach', 'we', 'our', and any pronoun whose antecedent lives in another section. Repeat the noun instead; repetition reads slightly clumsy to a person and reads correctly to a machine. Restate the qualifier too — 'in Singapore', 'for a business-to-business site', 'at the retrieval layer'. A passage that quietly inherits its scope from a heading further up loses that scope the moment it is chunked, and a scopeless claim is the fastest route to an inaccurate citation.
One claim per paragraph, claim first
Put the claim in the opening sentence; everything after it is support, and support is what an extractor discards first. If a sentence would embarrass the organisation when restated with no surrounding context, rewrite it rather than publish it. This is the cheapest quality gate on the page: read each paragraph's first sentence alone, in order, and check that the sequence still argues something.
How long should a passage be, and where should it break?
A retrieval system splits a page on its own boundaries, usually a fixed window that ignores your section logic. You cannot control where the cut lands. You can control whether a cut anywhere plausible still leaves two usable halves.
Give the chunker clean seams
Put a heading in front of every distinct question the page answers, open each paragraph with its own claim, and never let an argument span a heading. If a paragraph's first sentence depends on the paragraph before it, the split lands mid-argument and both halves become unusable. Sections that each answer a single named question survive chunking; a long essay with implied structure does not, because the chunker will split it anyway, just not where a writer would have.
Keep an answer short enough to be quoted whole
A quotable answer is a claim sentence, its qualifier, and at most one sentence of support. Anything longer and an extractor takes the front and drops the caveat, which is how an accurate page produces an inaccurate quotation. Move the elaboration into the paragraph beneath, where losing it costs nothing. Where a section runs long, split it into two sections with their own headings rather than trusting a reader — or a chunker — to find the seam.
Figures and tables travel badly
Keep every figure inside the sentence that interprets it: a number lifted without its qualifier is the most common way a correct page becomes a wrong quotation. Tables help when the header row carries the meaning and hurt when the meaning lives in a merged cell, a colour, or a footnote marker. Anything that would confuse a screen reader will be dropped by an extractor for the same reason.
Why does the same brand get named inconsistently?
Entity work is where engineering meets brand governance. A retrieval system has to decide that a passage, a company profile and a product listing describe one organisation. Inconsistent strings make that decision harder, and an unsure resolver attaches the claim elsewhere.
Variants are competing candidates, not synonyms
Pick one canonical name string and use it in that exact casing: in the title element, the organisation markup, the footer, the company registry entry, the social profiles and the article byline. A resolver does not read 'Acme Pte Ltd', 'ACME Singapore' and 'Acme.' as one organisation with a relaxed style guide; it reads them as candidates to choose between. The same discipline applies to the registered address, the entity type and the product names.
The string a resolver trusts was usually typed by somebody else
This is the layer most technical leads have never inventoried: the machine-readable name of a brand is rarely authored by the brand. A directory editor typed one version, a marketplace onboarding form generated another, a registry clerk entered a third, and an integration partner copied whichever was to hand. The brand's own site is one voice among those records, and often not the loudest. Before writing anything new, find out who signs the entity string a resolver is actually matching against.
An unsure resolver picks the competitor with cleaner naming
When the same claim can plausibly attach to two organisations, resolution favours the one whose name, address and entity type agree across every surface a machine can read. That is a scenario in which the better-argued page loses to the better-governed one. The fix is not more content: it is making every record agree, and doing it once, so that ambiguity stops being a standing tax on the citation work.
Where does a brand's machine-readable identity actually live?
Most of it is not on the website. It sits in records other organisations maintain, and those records are editable — usually by email, occasionally by form, rarely by anything a developer needs to build.
Inventory the records before editing any of them
List every surface that states the organisation's name to a machine: directory listings, marketplace profiles, partner pages, code repositories, dataset entries, conference speaker bios, the company registry. Note the exact string each one carries. The inventory itself is the deliverable — most teams discover at this point that no two records agree, and that the disagreement predates anyone currently employed.
Correcting a third party's record beats publishing another article
Where an external record holds the name, the address or the entity type incorrectly, filing the correction is worth more than a new blog post, because the corrected record feeds resolution everywhere it is quoted. This work is unglamorous, it has no dashboard, and it competes badly for attention against content production — which is precisely why it stays undone and stays valuable.
Make one page the canonical hub
Link the off-site records from a single canonical page and, where a platform allows it, link back. The purpose is not link equity. The purpose is that a resolver arriving from any of those surfaces lands on the same organisation, spelled the same way and described the same way. Keep that page boring, current and machine-parseable; it is doing identity work, not persuasion.
What structured data actually helps?
Structured data does not make a model cite a page. It removes a class of parsing ambiguity, which is a smaller and far more reliable benefit. Treat markup as hygiene with a low ceiling: worth doing correctly once, not worth iterating on, and easy to make worse by adding more of it.
Article, Organisation, and exact parity with the visible page
Mark the page as an Article and the publisher as an Organisation, then keep the fields in exact parity with what a reader sees: the headline string identical to the title element, the description identical to the meta description, the name identical to the H1. Parity is the whole point. A mismatch hands a parser two candidate answers for one field and no rule for choosing, and the version it picks is the version quoted back at your sales team.
What structured data actually helps?
Breadcrumbs and dates carry more weight than they look like they should
Add a breadcrumb trail and make the final crumb the question the page answers rather than a category label; that single string tells a parser what the page is for. Publish real publication and modification dates, and change the modification date only when the content genuinely changed. An organisation block with the canonical name, a canonical URL and links to the off-site records does more entity work than any content-level markup on the page.
Skip the rest, including the markup everyone recommends
Google has retired FAQ rich results, and in CANLAH AI's teardown of pages cited inside AI Overviews, FAQPage, Question and speakable markup were absent altogether. HowTo markup on a page that is not a procedure, review or rating markup a business writes about itself, and speculative properties added because a plugin offered them all add parse ambiguity for no measured return. Fewer correct types beat a long list of half-populated ones.
How do you test whether an LLM cites you?
Citation is a sampled quantity, not a state. A single check tells you almost nothing, because the same prompt does not return the same answer twice. Any test worth acting on has a sampling design written down before the first run and left alone afterwards.
Design the sample before reading any result
CANLAH AI's audit sampling design — 36 questions × 2 engines × 2 rounds — is set out in full on our AI visibility guide, and the shape matters more than the total. The question set is the sampling frame: a set made mostly of brand-name queries reports health that no buyer ever experiences. More than one engine exposes divergence between engines. More than one round exposes instability. Drop any dimension and the number stops being comparable with the next measurement.
How do you test whether an LLM cites you?
Instability is larger than most teams expect
In CANLAH AI's self-audit, the same prompt returned three rounds returned three different vendor sets; our AI visibility guide carries that run. A screenshot is therefore not evidence, and a single missing mention is not a finding. It is also why changing the model, the prompt wording or the engine mid-programme destroys the trend line — the instrument changed, so the before and after no longer measure the same thing. Freeze the instrument, store the raw answers, and let sample size carry the argument.
Your server log is stronger evidence than any checklist
Log incoming requests by user agent and confirm that AI fetchers reach the pages that matter, with the response status and body size you expect. That evidence is first-party, it fails loudly, and it settles access questions no external tool can settle for you. On the claim side, hold the same standard: CANLAH AI's verification corpus of 116 citation records, and 56 mechanism claims / 53 confirmed / 3 weakened / 0 overturned, is documented on our AEO versus GEO guide.
What does not move the needle, in most cases?
A technical lead deserves a straight answer about the tactics currently circulating. In most cases the gap between them is far smaller than the gap between a page that is fetchable and one that is not — and several of them quietly consume the budget the access layer needed.
llms.txt: cheap, harmless, unproven
Publishing an llms.txt file is inexpensive and breaks nothing, so publish it if it helps the team feel organised. It is not a substitute for the access work, and the evidence behind it is not in the same class: an access decision can be verified in your own server log today, whereas a proposed convention cannot be verified at all until a fetcher actually requests the file. Check the log before crediting it with any result.
Padding, density and volume
Word-count padding, keyword density targets and synonym stuffing do not help at this layer, and in most cases they hurt, because they push the answer further from its heading and dilute the passage that would otherwise have been lifted. The same applies to publishing volume: a set of pages that each answer one question cleanly outperforms a long page gesturing at many.
Ranking does not transfer to citation
Do not assume search performance carries over. On the pure-SEO query 'best SEO agency Singapore', CANLAH AI was named 0/5 in its own audit, which our AI SEO guide documents. A site can rank well and still be absent from the generated answer, because the passage that got lifted came from a page that answered the question directly rather than from the page that ranked. Diagnose the two surfaces separately, with separate question sets.
Should a technical lead do this work in-house?
Most of this page is genuinely do-it-yourself, and a capable in-house team will move faster than any vendor on it. The part that is not do-it-yourself is repeatable measurement, and that is also the part worth paying for. Here is the honest split.
Access and entity work is about one sprint of in-house effort
A competent team can finish the access layer and the entity layer inside a single sprint with no external help: audit the agent rules, verify fetches from outside the network with real user-agent strings, server-render the body copy, unify the canonical name string across on-site and off-site records, file corrections with the third parties holding the wrong string, and fix markup parity. In most cases an external vendor does not improve on the team that owns the deployment pipeline.
Where in-house effort usually breaks
Rewriting for extractable passages is slower, because it is editorial work governed by a machine-readable specification, but it stays in-house for most teams. What breaks internally is repeatable measurement: a frozen question set, fixed engines, repeated rounds, stored raw answers, and the discipline to leave the instrument alone for a full quarter. That is a small data pipeline with an owner, not a checklist, and it is what an agency fee should be buying.
What to ask a provider, and what nobody can promise
Judge a provider on whether they will hand over raw answers and a fixed sampling design, not on a promised position; published Singapore retainer ranges for this work sit on our AEO versus GEO guide, where the pricing question is answered properly. No provider can guarantee a citation, and the reason is measurable rather than rhetorical: an instrument that returns different vendor sets on repeat runs cannot underwrite a fixed outcome.