Making a Content Site AI Actually Cites
published 2026-07-22 · Start & Ship
A citation isn't a ranking. Ranking well in Google and being the source an AI system quotes back to a user are two different outcomes, judged by two different kinds of readers, and most content sites are built for only the first one. This page is a working example of the second: the JSON-LD in this site's app/page.tsx, the FAQPage schema under every FAQ block including the one at the bottom of this post, and the /llms-full.txt file concatenating this entire site into one document, are all real and all live right now, not a mockup of what AI-readiness could look like.
What “citable” actually means
Three things, none of them exotic: the claim is dated, so a system can judge whether it's still current; the claim is sourced, so it can be checked instead of trusted; and the page is structured so machine parsing doesn't require guessing what a blob of prose means. A human reader tolerates ambiguity. A retrieval system either finds a clean answer or moves to the next result — there's no partial credit for a page that's directionally right but structurally unreadable.
The four pieces, as they actually exist on this site
llms.txt — a curated index at /llms.txt: what the site is, the real offers with real prices, and links to the fuller documents. It's the front door for a system that wants a summary before deciding whether to read further.
llms-full.txt— the whole site's substantive text in one file, for systems that ingest a single document rather than crawl a sitemap. Every offer, the full FAQ, and every blog post's plain-text mirror, concatenated. It exists because crawling is expensive and unreliable for a lot of these systems; one file removes the excuse not to read the whole thing.
JSON-LD, per page type— Product schema on the pricing offers with real prices and availability, Article schema on every blog post with a real publish date, FAQPage schema wherever there's a real FAQ block. Not one schema pasted everywhere; the schema type matches what the page actually is, because a mismatched type is worse than none.
Dated, sourced prose — the part no template can do for you. Every number on this site traces back to site.config.ts or the public ledger at realnumbers.online ↗, so nothing here can quietly drift out of sync with the number a system might cite. Structure gets a page read. Real, checkable content is what gets it trusted.
Why most sites skip this
Not because it's hard, exactly — it's tedious in a way that's easy to defer indefinitely. A blank Next.js repo has no JSON-LD factory, no llms.txt convention wired to a config file, no pattern for keeping a plain-text mirror honest against the styled version of a post. Every site ends up rebuilding this from scratch, once, badly, or not at all. It's wired into every page template here from the start, which is the same reason the rest of the kit exists: not because any one piece is hard, but because rebuilding the same foundation for every new site is what actually eats the time.
FAQ
What is llms.txt?
A plain-text index at the root of a site — /llms.txt — written for AI systems and agents instead of human browsers or Google's crawler. It's a proposed convention, not a guarantee any given system reads it, but it costs nothing to publish and it's exactly the kind of legible summary these systems are built to prefer over scraping rendered HTML.
Does this replace normal SEO?
No. Traditional SEO — page speed, backlinks, on-page structure — still matters, and this site isn't claiming otherwise anywhere. The AI-surface layer is additive: it targets a different consumer (an LLM doing retrieval or answering a question) that traditional SEO wasn't built for.
Do I have to maintain the JSON-LD and llms.txt files by hand?
The structure is templated so you fill in content once, in site.config.ts or a post's frontmatter, and it propagates to the JSON-LD, llms.txt, and llms-full.txt automatically. The one manual step is a plain-text mirror of each blog post's body, kept in the post file itself, because Next.js Route Handlers can't render React to a string — that's a deliberate constraint, not an oversight, and it's documented right next to the code.
Will this actually get my site cited?
No one can promise that, and this site doesn't. What it can promise is that the content is structured the way these systems are documented to prefer: dated, sourced, machine-parseable. That's a real, checkable difference from a site with none of it — not a citation guarantee.
all sales final · every sale logged on the public ledger