Agentic AEO is the operating layer between answer-engine optimization and coding agents. It is not just “write better content.” It is a way to give an agent a stable spec for how a site should be crawled, structured, internally linked, sourced, tested, and published.

Short version: use the AEO Blueprint Generator to create a Spec Pack, put those files into the project, ask the coding agent to follow them, then verify the live pages before adding URLs to the sitemap or llms.txt source map.

Why this starter kit exists

Most AI-assisted SEO work fails because the instruction is too vague. A prompt like “optimize this site for AEO” gives a coding agent no durable target. The agent might add FAQ sections, throw schema at pages that do not support it, create thin glossary entries, or update a sitemap before the page is actually indexable.

A better workflow starts with project-level instructions. The agent needs to know the site’s entities, source-of-truth pages, content model, internal-linking rules, crawler policy, schema rules, and publish checks. That is what the AEO Spec Pack is for.

The AEO Spec Pack

The Spec Pack is a set of Markdown files that turn an AEO strategy into agent-readable implementation rules. The files are small on purpose. A coding agent can read them before it edits pages, templates, schema helpers, robots rules, or sitemap generation.

File Job Why it matters
AEO.md Defines the site’s AEO thesis, audience, market, and operating formula. Keeps implementation tied to a real source strategy instead of scattered tactics.
AGENTS.md Gives coding agents project instructions, guardrails, and verification expectations. Makes the agent’s work more predictable across sessions and tools.
CONTENT_MODEL.md Defines page types, required sections, proof requirements, and noindex rules. Prevents thin pages and makes templates easier to scale.
ENTITY_MAP.md Lists core topics, services, categories, locations, products, or people. Helps pages reinforce the same topical structure instead of drifting.
SCHEMA_RULES.md Defines which schema types are allowed and what visible content must support them. Reduces unsupported JSON-LD and schema overreach.
INTERNAL_LINKING.md Defines how hubs, tools, glossary entries, guides, case studies, and listings connect. Turns pages into a source system rather than isolated articles.
CRAWLER_ACCESS.md Defines which public pages should be fetchable and which paths should stay blocked. Separates search/retrieval access from training access and private-path blocking.
SITEMAP_POLICY.md Defines what belongs in XML sitemaps and when lastmod should change. Keeps the sitemap limited to canonical, indexable, HTTP 200 pages.
LLMS_TXT.md Drafts a curated source map for assistants and agents. Helps surface the site’s most useful source pages without pretending to control crawling.
QA_CHECKLIST.md Lists the checks that must pass before publishing or indexing. Creates a repeatable human and agent review loop.

The workflow

1. Generate the blueprint before asking the agent to build

Open the AEO Blueprint Generator and describe the site, CMS, audience, market, business model, core entities, proof sources, and competitors. Do not treat this as a keyword tool. Treat it as a project brief for an implementation agent.

The most important fields are the entity list and proof sources. If those are weak, the agent will still be able to create pages, but the pages will not have a strong reason to be cited.

2. Put the Spec Pack where the agent can actually read it

Download the generated files and place them near the root of the project. If the site uses a monorepo, put the main files at the repo root and add narrower files inside the site package when needed.

project-root/
  AGENTS.md
  AEO.md
  CONTENT_MODEL.md
  ENTITY_MAP.md
  SCHEMA_RULES.md
  INTERNAL_LINKING.md
  CRAWLER_ACCESS.md
  SITEMAP_POLICY.md
  LLMS_TXT.md
  QA_CHECKLIST.md
  src/
  public/
  content/

The AGENTS.md project describes the file as a predictable place to give coding agents project context. That is exactly the job here: make AEO rules discoverable before the agent touches the site.

3. Ask the coding agent for a bounded implementation pass

Do not ask the agent to rebuild the whole site in one pass. Give it a bounded task with a clear page type, route set, and verification list.

Read AGENTS.md, AEO.md, CONTENT_MODEL.md, ENTITY_MAP.md, SCHEMA_RULES.md,
INTERNAL_LINKING.md, CRAWLER_ACCESS.md, SITEMAP_POLICY.md, LLMS_TXT.md,
and QA_CHECKLIST.md.

Implement the Bangkok restaurant category hub as an editorial source page.
Use structured listing data where possible. Add internal links to area pages,
restaurant listings, transport guidance, and the Bangkok hub. Add schema only
when visible content supports it. Do not add the URL to the sitemap until the
route returns 200, has a self-canonical URL, and passes the QA checklist.

This framing is stronger than “make the page SEO friendly” because it gives the agent a source role, a route, internal-link expectations, schema limits, and a publish gate.

4. Build source pages before scale pages

For AEO, the first pages should explain the system: the main hub, methodology, strongest guides, tools, glossary definitions, research pages, category hubs, and case studies. Only after those pages are strong should you scale into many lower-level pages.

This is especially important for directories, local sites, SaaS comparison sites, and affiliate sites. Scale pages depend on the authority and clarity of the source pages around them.

5. Keep crawler policy separate from source mapping

Robots rules, sitemap policy, and llms.txt should not be merged into one vague “AI file” task. They do different jobs. Robots controls access. XML sitemaps expose canonical URLs for discovery. llms.txt is best treated as a curated source map for assistants and agents.

OpenAI’s crawler documentation separates OAI-SearchBot, GPTBot, and ChatGPT-User use cases. Google’s AI features documentation points site owners back to Googlebot, noindex, nosnippet, and snippet controls for Search visibility. The practical lesson is simple: decide crawler access by crawler purpose, not by hype around AI.

6. Verify before publishing

A coding agent can generate a good page and still miss the live-readiness details. Before a page is published, added to a sitemap, or added to llms.txt, verify the boring mechanics:

  • The live route returns HTTP 200.
  • The canonical URL points to the final public URL.
  • The page is not accidentally noindexed.
  • The main content is visible in HTML, not hidden behind fragile client-only rendering.
  • Schema matches visible content.
  • Internal links connect the page to its parent hub and related source pages.
  • The page has evidence near claims.
  • The sitemap includes only canonical, indexable URLs.
  • llms.txt lists only durable source pages, not every page on the site.

What a good agent pass looks like

A good implementation pass should end with a concise report. The agent should tell you which files changed, which routes changed, whether schema changed, whether sitemap or llms.txt changed, which checks passed, and what still needs human judgment.

The final answer should not be a victory lap. It should be an audit trail. That is how you make hands-off publishing safer without becoming blind to what changed.

Good task

“Build the /bangkok/restaurants/ category hub using CONTENT_MODEL.md and INTERNAL_LINKING.md. Keep it editorial, use listing data, add BreadcrumbList and ItemList only if visible content supports it, then run the QA checklist.”

Weak task

“Make the restaurant page rank better.” This leaves page role, evidence, internal links, schema, crawler policy, and publish checks up to guesswork.

Where this fits in an AEO program

The Spec Pack does not replace research, writing, design, or source quality. It makes those things easier to preserve when agents are doing the implementation. The goal is not to automate taste away. The goal is to make the site consistent enough that every page strengthens the same answer-engine footprint.

Recommended first implementation sequence

  1. Create or improve the homepage, methodology page, tools page, glossary, and core topic hub.
  2. Create the strongest guide or category hub for the site’s highest-value prompt family.
  3. Add supporting glossary entries and internal links from existing pages.
  4. Add schema only where the visible page content supports it.
  5. Verify robots, noindex, canonical, sitemap, and llms.txt behavior.
  6. Run a small prompt panel across target answer surfaces and record whether the page is mentioned, cited, or ignored.
  7. Improve the source page before scaling into dozens of similar pages.

Starter prompt for Cursor, Codex, or Claude Code

You are working on this website as an AEO implementation agent.

Before editing, read:
- AGENTS.md
- AEO.md
- CONTENT_MODEL.md
- ENTITY_MAP.md
- SCHEMA_RULES.md
- INTERNAL_LINKING.md
- CRAWLER_ACCESS.md
- SITEMAP_POLICY.md
- LLMS_TXT.md
- QA_CHECKLIST.md

Your job is to improve one bounded page type or route cluster.
Do not invent facts, statistics, sources, reviews, screenshots, or schema claims.
Use visible content as the source of truth for schema.
Keep sitemap and llms.txt changes behind the QA checklist.
At the end, report changed files, changed routes, schema changes, sitemap changes,
llms.txt changes, tests run, and remaining risks.

Source notes

  • AGENTS.md is a simple open format for guiding coding agents with project context.
  • OpenAI crawler documentation separates search, training, and user-triggered user agents.
  • Google’s AI features documentation points site owners to normal Search controls such as Googlebot, noindex, nosnippet, and snippet controls.
  • llms.txt is a proposal for a Markdown source map to help LLMs use a website at inference time.

Related tools and reading