An experimental guide to technical AEO

About 68% of Google searches ended without a click in early 2026. AI referral traffic to major websites grew 357% year over year in 2025. When someone asks ChatGPT or Perplexity "what's the best Canadian hosting platform," the answer may come from whatever the model already knows, or whatever it can fetch in real time.

That changes the job of a marketing site. It still needs to rank, load quickly, and convert humans. But it also needs to be easy for AI systems to read, summarize, and cite accurately.

That is answer engine optimization (AEO) in practice. Not a guaranteed traffic channel, just making your content easier for answer engines to understand.

This covers the technical delivery side: content format, routing, and metadata. Content strategy, keyword research, and what to write are separate problems.

Fair warning: the standards here are still experimental. llms.txt and the IETF AI preference drafts are still proposals, and I cannot measure a direct lift in AI citations yet. I tried this anyway because the direction seems real, and the changes also made the site easier to maintain.

What I changed

I rebuilt the content pipeline around four ideas:

1. Keep source content in markdown.
2. Publish an llms.txt index.
3. Serve markdown when a client explicitly asks for it.
4. Add enough metadata for AI systems to identify the business and cite pages correctly.

You do not need to copy every implementation detail. The useful pattern is simpler: make the authoritative content available as clean text, then point agents to the right place.

Keep source content in markdown

A browser can handle a deeply nested React page. An answer engine often wants the text, headings, links, and facts as directly as possible.

Moving page content into markdown gives you that clean source. Your rendered site can still use React components, custom sections, feature grids, and calls to action. The source file just becomes easier for both humans and tools to inspect.

For MapleDeploy, Markdoc was a good fit because it lets us keep markdown as the source while mapping custom tags to React components at render time. MDX can solve the same problem. The specific tool matters less than the outcome: the page content lives in a text format that is readable before the browser renders anything.

That also gives you a better internal source of truth. Blog posts, comparison pages, docs, and landing pages can all be indexed, transformed, and served from the same content directory.

Add llms.txt

The llms.txt convention is a text file at /llms.txt that gives AI systems a curated map of your site.

Think of it as a table of contents for language models. A sitemap says "these URLs exist." An llms.txt file says "this is who we are, these are the pages that matter, and this is where to go for more detail."

A useful llms.txt includes:

• A short description of the site.
• Key product pages.
• Important comparison pages.
• Blog posts worth citing.
• A link to full markdown content if you publish one.

We also publish /llms-full.txt, which combines the markdown body of published content into one response. That gives research agents a single place to fetch complete site context.

Keep both files generated from your content source. Filter out unpublished posts, and cache the result so it is cheap to serve.

Serve markdown on explicit request

Once the content source is markdown, give clients a predictable way to request it.

There are two useful triggers:

• Accept: text/markdown
• A .md version of the URL, such as /canadian-hosting.md

The important word is explicit. I would not serve markdown based on user-agent sniffing. AI tools, browsers, crawlers, and preview clients all change their user agents over time. If a client asks for HTML, serve HTML. If it asks for markdown, serve markdown.

You can verify the behaviour with simple requests:

curl -H "Accept: text/markdown" https://yoursite.com/some-page
curl https://yoursite.com/some-page.md

For .md URLs, add a canonical Link header that points back to the HTML page. That tells search engines which version is authoritative and avoids treating the markdown copy as a competing page.

Add useful metadata

Markdown is clean, but a single markdown page can lose context. An HTML page has meta tags, OpenGraph properties, canonical links, and structured data. A markdown response should carry the same basic facts.

For MapleDeploy, the markdown response includes page frontmatter plus site-level metadata such as:

• Site name
• Locale
• Canonical URL
• Author
• Business region
• Pricing summary
• Link to /llms.txt

The goal is not to stuff keywords into the response. The goal is to remove ambiguity. If an answer engine fetches a page and needs to answer "what does this company do?" or "what does it cost?", it should not have to guess.

Keep this metadata in the served response, not necessarily in every raw source file. Page-specific frontmatter should remain readable for authors.

On the HTML side, keep using JSON-LD structured data where it fits: Organization, Article, FAQPage, BreadcrumbList, or product-specific schema. Traditional search and AI retrieval both benefit from clear structure.

Set permissions clearly

Making content easier to fetch is one decision. Saying what systems can do with it is another.

At minimum, keep robots.txt intentional. If you are open to crawling, a normal wildcard allow rule is enough. If you want to block specific crawlers, robots.txt is where that policy belongs.

For more granular signals, the IETF AI Preferences drafts are still in flux. The expired attachment draft used Content-Usage examples such as:

Content-Usage: train-ai=n

Adoption is early, so treat this as a signal, not enforcement. The practical value is that your intent is clear.

What I would skip

I would skip anything that depends on guessing bot identities. It is brittle and easy to get wrong.

I would also avoid overbuilding metrics too early. Watch logs for /llms.txt, /llms-full.txt, .md URLs, and Accept: text/markdown requests. That tells you whether tools are using the paths. It does not prove that the work is improving citations or revenue.

Finally, do not make the markdown version worse for humans just to satisfy a theory about AI. Clear headings, short paragraphs, accurate links, and factual copy help both audiences.

Conclusion

The whole pipeline is simple: write content in markdown, publish an AI-readable index, serve markdown when asked, and include enough metadata to keep citations accurate.

Is all of this necessary? Nobody knows yet. The line between "website" and "document an AI can read" is getting thinner, but the winning standards are still unsettled.

What I do know is that clean markdown content, useful metadata, and explicit routes are a better foundation than burying every important fact inside rendered components. If AI-mediated discovery keeps growing, the site is ready. If it does not, the content system is still cleaner than before.

MapleDeploy is a managed Coolify hosting platform on Canadian infrastructure, with plans starting at $45 CAD/month and a 30-day free trial. If you're building something that needs Canadian data residency, take a look.