Subdomain vs Subfolder for AEO: How AI Engines Treat Host Boundaries

For AEO, put citable content in a subfolder when you have the choice. The mechanism is simple: crawlers and answer engines draw a hard boundary at the hostname. blog.example.com is a different host from example.com - it needs its own robots.txt, its own llms.txt, its own crawl treatment - while example.com/blog inherits everything the root domain has already earned and configured. Entity association, the thing that turns "a page on the web" into "a page by your brand," has to be re-established across a host boundary and comes free within one.

That does not make subdomains wrong everywhere. An app, a status page, a community forum, or a docs platform that genuinely cannot live on your main stack are all legitimate subdomain tenants. The mistake is putting your primary citation surface - the blog, the guides, the comparison pages - on a separate host without noticing what that separation costs and what per-host files it obligates you to maintain.

Here is how the boundary actually works, where teams get burned, and how to decide.

The hostname is a hard technical boundary

Everything in the crawling and fetching stack keys on the full host, not the registrable domain.

robots.txt is per host. RFC 9309 scopes robots.txt to the exact scheme and host it is served from. GPTBot fetching blog.example.com checks blog.example.com/robots.txt and only that file. Your carefully tuned rules at example.com/robots.txt do not apply. If the subdomain is hosted on a third-party platform, that platform's default robots.txt is in charge - and some hosted platforms and CDN presets block AI crawlers by default. Our robots.txt guide for AI crawlers covers what those rules should say; the point here is that you need a correct copy on every host you run.

llms.txt is per host too. The llms.txt convention mirrors robots.txt: fetchers look for it at the root of the host they are on. An llms.txt at example.com/llms.txt that lists your best blog posts does nothing for a fetcher visiting blog.example.com, and blog.example.com almost never has one - this is one of the most common gaps we see in audits. If your citable content lives on a subdomain, that subdomain needs its own file; how to generate llms.txt walks through building one, and the free llms.txt checker will show you in seconds whether each of your hosts serves one.

TLS, headers, and bot protection are per host. A WAF rule allowing ClaudeBot on the apex does not extend to a subdomain fronted by a different CDN configuration. Each host is a separate access-control surface, which means each one can silently fail. The AI crawler access checker tests the host you give it - run it against every subdomain that carries content you want cited.

Sitemaps and canonicals cross the boundary awkwardly. A sitemap on one host can reference URLs on another only if the referenced host is verified appropriately, and cross-host canonical signals are weaker and slower to consolidate than same-host ones.

Entity association weakens across subdomains

The technical boundary would be a mere checklist item if engines stitched hosts back together perfectly. They do not stitch them together perfectly.

Traditional search engines treat subdomains as closely related but separable sites - Google has long said it handles both fine, while site owners have observed for years that authority consolidation behaves differently across the boundary. AI engines add a second layer: entity resolution. When a model or a grounding pipeline decides "this page is from Example Corp, whose product does X," it leans on co-occurrence - the brand name, the domain, the Organization schema, the internal links all appearing together. Content at example.com/blog sits inside that cluster natively. Content at blog.example.com shares only a name suffix, and the association has to be asserted explicitly and repeatedly.

You can partially rebuild the bridge - identical Organization schema with the same @id on both hosts, sameAs arrays that cross-reference, heavy interlinking, the subdomain listed in the apex llms.txt as an official property. That work is real and worth doing if the subdomain is non-negotiable; entity alignment for AI citations covers the technique. But "partially rebuild with ongoing effort" versus "get it free" is the actual trade-off, and it should be named honestly in any architecture discussion.

There is also a retrieval-side effect: when an engine has fetched and liked several pages from a host, adjacent pages on the same host benefit from established trust and crawl familiarity. A subdomain starts that accumulation from closer to zero.

blog.example.com vs example.com/blog through the citation lens

Run the standard case through the mechanism above.

• Configuration surface. The subfolder blog is covered by the robots.txt, llms.txt, schema plumbing, and bot-access rules you already maintain. The subdomain blog needs all four duplicated and kept in sync forever. Every future policy change - allowing a new crawler, adding a curated llms.txt section - now has two places to be done and one place it will be forgotten.
• Entity gravity. Blog posts are usually where your definitions, statistics, and comparisons live - the passages engines actually lift. On a subfolder, every citation of a post is unambiguously a citation of example.com. On a subdomain, engines attribute to blog.example.com, which dilutes brand-level visibility measurement and weakens the "this brand is an authority on this topic" accumulation.
• Failure modes. The subfolder's worst case is a path-level misconfiguration. The subdomain's worst case is a whole host silently dark to AI crawlers because a hosted blog platform shipped a restrictive default robots.txt nobody ever read.

If your blog is currently on a subdomain and earning citations, do not panic-move it - see the migration caution below. If you are choosing today, choose the subfolder and use a reverse proxy to mount a hosted platform under /blog if the platform itself demands a separate origin.

When a subdomain is right anyway

Subdomains earn their place when the thing being hosted is not your citation surface, or when isolation is the point.

• The app itself. app.example.com keeps authenticated, noindex application traffic cleanly separated from marketing content. Nothing there should be cited, so nothing is lost.
• Status pages, docs platforms, community forums running on third-party infrastructure that cannot be proxied. Accept the boundary, then pay the tax deliberately: own robots.txt, own llms.txt, shared Organization schema, links both ways.
• Regional or brand separation where the entities genuinely are distinct and you want engines to treat them distinctly.
• Risk isolation. User-generated content you cannot fully vouch for is safer on its own host, precisely because engines will treat it as separable from your main site.

The decision rule: if you want the content's citations to accrue to your brand, put it inside the host. If you want separation, the subdomain gives you exactly that - separation.

Migration cautions if you consolidate

Moving an established subdomain into a subfolder is a real migration with everything that implies: a full one-hop 301 map, schema and llms.txt parity on the destination, and a months-long lag before AI answers stop referencing the old host. Model weights that learned blog.example.com will keep emitting it until retraining catches up, so the subdomain must keep resolving and redirecting indefinitely. The full two-clock playbook is in site migrations without losing AI citations - read it before you move anything that currently earns citations, and time the move for a quiet period so you can attribute any citation change to the move itself.

Also update the boring references: the sitemap locations, the sameAs and url fields in your Organization schema, your llms.txt entries, and any directory listings that point at the subdomain.

Frequently asked questions

Does Google treat subdomains and subfolders the same for AI Overviews?

Google's public position is that its systems handle both. But AI Overviews inherit Google's crawl and entity infrastructure, where each host has its own robots.txt and its own consolidation history, so the practical differences described above still apply. The safer default for content you want cited remains the subfolder.

Do I really need a separate llms.txt for each subdomain?

Yes. llms.txt follows the robots.txt pattern: fetchers look for it at the root of the specific host. A file on the apex does not cover blog.example.com or docs.example.com. Generate one per content-bearing host and check each with the free llms.txt checker.

My blog platform forces a subdomain. What is the mitigation checklist?

Serve a correct robots.txt and llms.txt on the subdomain, mirror your Organization schema with the same @id and cross-referencing sameAs values, interlink heavily in both directions, and list the subdomain in the apex host's llms.txt as an official property. Alternatively, reverse-proxy the platform under a subfolder if it supports a custom origin path.

Is www.example.com a subdomain for these purposes?

Technically yes - www and the bare apex are different hosts, each with its own robots.txt scope. In practice you should pick one as canonical, 301 the other to it at every path, and serve your robots.txt and llms.txt on the canonical host. What you must not do is serve different content on both.

Will moving my blog from a subdomain to a subfolder immediately boost citations?

No. The consolidation benefit accrues over months as engines recrawl, re-consolidate, and eventually retrain. In the short term a move is a disruption, which is why it only makes sense as a deliberate migration with full redirect and parity discipline, not as a quick win.

Audit every host you own, not just the apex

The subdomain trap is invisible from the apex: example.com can score perfectly while blog.example.com serves a platform-default robots.txt that blocks GPTBot and has no llms.txt at all. Run the free crawler access and llms.txt checkers against each host you operate, and a full Citevera audit against the ones that carry your citable content. One config file per host is the rule; the audit is how you find the host where the file is missing.