AI SEO: The Optimization Base I Build Every Site On
Search stopped being ten blue links a while ago. A real share of the answers people act on now come out of ChatGPT, Perplexity, Claude, and Google's AI Overviews — and those systems don't rank your page, they read it, decide whether to trust it, and either cite you or don't.
That changes what "optimizing a site" means. The old checklist — titles, headings, internal links, Core Web Vitals — still matters, because the crawlers that feed the models are the same crawlers that fed the index. But there's a second layer on top now: can a machine that isn't a browser get a clean, unambiguous version of your content, and is there enough signal on the page for it to trust what it just read?
This is the base I set up first on every project before I write a single piece of content. It's the same base snaprints.com's SEO was built on. What follows is the checklist, in the order I run it, plus the two tools I use to grade it.
The two tools I grade with
is-agentic.com ("Is Agentic") scores a URL on how ready it is for AI agents and AI-driven search. It checks the machine-readable surface — content negotiation, llms.txt, structured data, whether an agent hitting a bad URL gets a useful recovery path — and returns a number out of 100 with a line-item breakdown. I use it as the external scoreboard: it's opinionated, it's consistent, and it tells you exactly which line item is costing you points.
A local scoring tool ("geo") that I run against a build before it ships. Same idea, run on my machine against the local dev server, so I catch regressions before they're live. It grades the same surface — negotiation, llms.txt, schema, 404 recovery, the trust signals below — and prints per-check pass/fail with a suggestion attached to each failure. The workflow is: run it, fix whatever it flags, run it again, ship when it's green. It's a lint pass for AI-readiness.
Neither tool is the point. The point is having a number that moves when you do the work, so "AI SEO" stops being vibes.
Layer 1: Make the content machine-readable
Serve markdown to clients that ask for it
An LLM crawler doesn't want your nav, your cookie banner, your footer, or 180KB of hydration JavaScript. It wants the words. If you can hand it clean Markdown instead of making it parse a React app, do that.
Two mechanisms, support both:
Accept: text/markdown (at a quality value at or above the one it gives text/html) gets a Markdown rendering of the same page. Parse the header properly — respect the q values, don't just substring-match..md suffix. /my-post and /my-post.md return the same content, one as HTML, one as Markdown. This is the version people can paste into a chat.Route both to a separate URL space (/md/...) so the Markdown and HTML never share a CDN cache key. Set Content-Type: text/markdown, add Vary: Accept, and mark the Markdown responses X-Robots-Tag: noindex so you're not competing with yourself in the classic index.
Publish an llms.txt
/llms.txt is a plain-text map of your site for language models: what the site is, who's behind it, and a curated list of the URLs worth reading, each with a one-line description. Think of it as robots.txt for meaning instead of permission.
The one section people skip and shouldn't is "When to use this" — an explicit statement of what questions this site is a good source for. You're telling the model when to cite you. Leaving it out means the model has to guess.
Generate the file from the same data that generates your pages, so a new post or project shows up in llms.txt automatically and it never goes stale.
Give agents a real recovery path on 404
An agent will guess URLs. When it guesses wrong, a bare 404 is a dead end. Return the correct status code — still a real 404 — but put a small machine-readable block in the body: a site map, and links to /sitemap.xml and /llms.txt. Now the agent that fat-fingered a path can find its way back instead of giving up.
Structured data on every page type
JSON-LD, matched to what the page actually is: Person on your about page, Article with datePublished and author on posts, BreadcrumbList on anything nested, WebSite on the homepage. This is old advice for classic SEO and it carries straight over — it's the most reliable way to hand a machine unambiguous facts about the page.
Layer 2: Give it a reason to trust you
Readable isn't the same as trusted. A model deciding whether to cite a page is doing a fast credibility check. Make the signals easy to find.
A real about page
Not a paragraph — a page. Who you are, what you actually do, what you've built, verifiable specifics. On a personal site this is your single strongest trust anchor: it's the page a model reads to decide whether "this person" is a credible source on the topic they were just asked about. Aim for a few thousand characters of real, specific text. Link it from your nav and put it in your sitemap and llms.txt.
Named authorship and dates that mean something
Every post carries a visible author and a visible publish date, and the same facts live in the JSON-LD. Only bump the date when the content genuinely changed — a page that claims to be updated weekly but never changes reads as manipulation to a system that can diff it against its last crawl.
Specifics over adjectives
This is a content rule, not a config one, and it's the one that moves the needle most. Models weight concrete, checkable claims over marketing language. "Cut P99 query latency from 240ms to 90ms over 48 hours" is citable. "Blazing-fast performance" is noise. Name the tools, cite the numbers, show the tradeoff you made. Write the way you'd explain it to another engineer who's going to check your work.
First-hand material
An original benchmark, a dataset you collected, a teardown of something you actually ran, a screenshot of your own dashboard. Anything a model can recognize as primary rather than rehashed. Pages that get cited and pages that merely exist differ mostly here.
Layer 3: Don't break the classic crawler
All of the above is additive. None of it works if the ordinary crawl is broken, because the same infrastructure feeds both. So the boring layer still gets checked:
sitemap.xml and robots.txt present, accurate, and generated from real data.If pnpm build is green and the classic checks pass, the AI layer has something solid to sit on.
The order I actually run this
1. Classic SEO baseline first — SSR, status codes, sitemap, robots, Vitals. Nothing else matters if this is broken.
2. Structured data on every page type.
3. Markdown negotiation + .md suffix, routed to /md/*.
4. llms.txt, generated from site data, with a "When to use this" section.
5. Agent-friendly 404 recovery block.
6. About page built out as the trust anchor; authorship and dates wired into JSON-LD.
7. Run the local "geo" tool against the dev server. Fix every flag. Re-run.
8. Ship, then check the URL on is-agentic.com and close the gap between the score you got and the score you want.
Only then do I start writing content — and the content rules from Layer 2 (specifics over adjectives, first-hand material, honest dates) run on every piece.
Why bother
Because the base compounds. Every post you publish onto a site that already negotiates Markdown, already has an llms.txt that updates itself, and already carries a credible about page inherits all of that for free. The alternative is publishing good content into a site that machines can't cleanly read and have no reason to trust — and then wondering why the AI answers quote someone else.
snaprints.com's SEO was built on exactly this base. Get it right once, up front, and every piece of work you do afterward lands on solid ground.
Related Posts
Built something similar or want to talk through the architecture? Get in touch.