People searching for “AEO Record Standard alternatives” are usually asking a fair question: there are already several ways to publish information for machines — why add another? This page answers it in the open, including the cases where an existing mechanism is the better tool and a v=AEO1 record adds nothing you need.
The short version is that most of these are not rivals at all. They operate at different layers and solve different halves of the problem, and the strongest setup uses several of them together. Only two questions genuinely separate them: can a consumer tell the domain owner authorized this? and can a consumer tell the facts have not been altered?
| Mechanism | Layer | Best at | Proves owner authorized it | Detects altered facts |
|---|---|---|---|---|
| schema.org | Page | Describing entities inside a page in rich detail | No | No |
| llms.txt | File | Curating which content matters, in prose a model reads well | No | No |
| robots.txt / meta | File / page | Controlling access — who may crawl what | n/a — not a facts mechanism | n/a |
| ai.txt / AIPREF | File | Expressing AI training and usage preferences | n/a — not a facts mechanism | n/a |
| Knowledge panels | Third party | Distribution — reach into products people already use | Via that platform only | No |
| Platform verification | Platform | Proving ownership to one specific vendor | Yes, for that vendor | No |
| Web Bot Auth | Request | Identifying the agent making a request | Opposite direction — identifies the caller | n/a |
| v=AEO1 record | DNS + well-known | Naming the authoritative catalog and proving who authorized it | Yes, via DNS control | Yes, on signed tiers |
Read the last two columns as scope, not scoring. A mechanism that answers “no” there is usually excellent at something this table does not measure.
JSON-LD or microdata embedded in a page, describing the entities on it — an organization, a product, an event, an FAQ. It is the most mature, most widely consumed structured-data vocabulary on the web, and search engines have read it for over a decade.
Its boundary is provenance. Markup lives inside a page, so anyone who can serve or mirror that page can serve that markup, and a consumer reading it has no cryptographic way to distinguish an owner’s canonical statement from a scraped copy, a stale cache, or a third party’s reproduction. It also carries no signature and no declared verification depth — a self-asserted openingHours and a triple-checked one look identical on the wire.
Verdict: complementary, not a rival. The specification lists schema.org as orthogonal and page-level. Keep your markup. A v=AEO1 record answers a different question — which source is canonical, and who signed off — and points at the catalog holding it.
A markdown file at the root of a site that curates what a language model should read: a summary, then links to the pages that matter, in an order the author chooses. Growing adoption, near-zero cost, and genuinely useful.
Its boundary is the same as markup: it is a file on a web server. Anyone able to serve content at that path can publish it, nothing binds it to the domain owner cryptographically, and it carries no signature, no verification tier and no defined freshness semantics. The specification is explicit that a self-declared v=AEO1 record sits at exactly the same trust level as an llms.txt file — that is a concession, stated in the spec rather than hidden.
Verdict: complementary, and composed with deliberately. The AEO1 discovery hierarchy names an llms.txt pointer as one legitimate route to a record, precisely because crawlers already read the file. The two are designed to sit on the same domain.
Access and preference conventions: which crawlers may fetch what, whether content may be used for training, whether a page should be indexed. Universally understood in the robots.txt case, and the work on AI usage preferences is where policy expression belongs.
They are listed here because they surface in the same searches, not because they overlap. They express policy about access; they say nothing about which facts are canonical or whether anyone verified them. The two concerns are genuinely orthogonal — a site can and should do both.
Google Business Profile, Apple Business Connect, Bing Places, Wikidata, industry directories and review platforms. A business claims its listing, keeps it current, and that data flows into products with enormous reach — including, indirectly, into AI answers.
Their boundary is portability and control. Each listing is verified by, held by, and readable through one platform’s terms; the facts live in someone else’s database in someone else’s shape, and an engine outside that ecosystem cannot check them independently. Keeping several listings in agreement is ongoing manual work, and divergence between them is a common cause of an engine answering with the wrong hours.
Verdict: keep them, and keep them accurate. An owner-published catalog with a signature is the portable, self-hosted counterpart — one canonical source any consumer may read, on the owner’s own domain.
The TXT-record or file-upload flows that prove to a specific vendor that you control a domain, unlocking features in that vendor’s product.
It is per-vendor and closed by design: the proof means something to the issuing platform and nowhere else, it is not an open standard anyone can implement, and it verifies ownership rather than facts. v=AEO1 uses the same underlying DNS proof, but publishes the format openly so any consumer — not one vendor — can check it, and extends it from ownership to a signed statement about the facts themselves.
Cryptographic identity for the agent making a request, so a server can tell a legitimate crawler from an impostor.
It points the other way down the wire. Web Bot Auth authenticates the consumer; AEO1 authenticates the publisher. A future in which both exist is strictly better than one with either alone, and nothing about them conflicts.
The default: engines read your pages and infer what they can. Worth naming honestly, because for a great many sites it works acceptably and costs nothing.
Its limits show up on the facts that change — hours, pricing, service areas, staff — where an inference drawn from whichever page ranked can lag reality, and where the engine has no way to prefer your statement over someone else’s description of you. Every mechanism on this page, including the free ones, is an improvement on it.
Narrowly and specifically, two things nothing else in this list provides together:
1. Proof of domain control, at the DNS layer. A record at _aeo.<domain> can only be published by someone with access to that domain’s DNS. That makes it an owner’s statement rather than a page’s claim — the same property that makes SPF, DKIM and DMARC useful in email.
2. A signature over the facts. On signed tiers, an Ed25519 signature covers a canonical hash of the published fact set, so a consumer can detect any alteration since signing without trusting the server that handed it over. Alongside it, a declared tier states how much corroboration stands behind those facts, and a date states when.
Everything else about the design follows from wanting those two properties to be cheap to check: a compact record, a well-known JSON bridge for crawlers that never touch DNS, an ordered discovery hierarchy, and an open zero-dependency verifier — npx aeo-record example.com — so nobody has to take the standard’s word for anything.
llms.txt and keep your schema.org markup accurate. Genuinely, start there.And the honest boundary on the whole page: adoption of v=AEO1 is early. It was first published on 2026-06-29 and filed with the IETF as Internet-Draft draft-miller-aeo-00 on 2026-07-18 — a published, citable working document, not an endorsed standard. The mature mechanisms on this page have consumers today that a new one does not. The case for publishing a record now is tenure and portability, not a promise about what any engine does with it this week.
If you want the definition and the mechanics rather than the comparison, start with what the AEO Record Standard is, then the full specification. The verification methodology states exactly what each tier does and does not attest.
The realistic list is schema.org structured data, an llms.txt file, robots.txt and meta directives, AI-preference conventions such as ai.txt and the IETF AIPREF work, third-party knowledge panels and directories like Google Business Profile or Wikidata, per-vendor platform domain verification, Web Bot Auth for agent identity, and simply letting engines crawl the site. Most of them operate at different layers and compose rather than compete.
Not really a rival — the two are designed to sit on the same domain. llms.txt is excellent at curation and voice, takes minutes to publish and needs no DNS access. The specification concedes plainly that a self-declared v=AEO1 record carries exactly the same trust level as an llms.txt file, and the AEO1 discovery hierarchy names an llms.txt pointer as one legitimate route to finding a record.
It does a different and broader job better. schema.org expresses relationships, types and nuance that a compact DNS record should not attempt, and it has a decade of existing consumers. What it cannot do is prove the domain owner authorized the markup or detect that facts were altered, because markup lives inside a page anyone able to serve that page can produce. Keep the markup; the record answers which source is canonical and who signed off.
For a local business, that should be the first thing kept accurate — it reaches more real queries today than any emerging convention, and several such platforms apply genuine verification. The gap is portability and control: the facts live in one platform's database under its terms, an engine outside that ecosystem cannot check them independently, and keeping several listings in agreement is ongoing manual work.
They answer an unrelated question. robots.txt, meta robots directives and AI-preference conventions express policy about access — who may crawl what, and what may be done with it. A v=AEO1 record expresses which facts are canonical for a domain and who authorized them. The concerns are orthogonal, and a site can and should do both.
No, it points the other direction down the same wire. Web Bot Auth cryptographically identifies the agent making a request, so a server can distinguish a legitimate crawler from an impostor. AEO1 authenticates the publisher of the facts. Both existing is strictly better than either alone, and nothing about them conflicts.
Two things, together. Proof of domain control, because a record at _aeo.<domain> can only be published by someone with access to that domain's DNS. And integrity of the facts, because on signed tiers an Ed25519 signature covers a canonical hash of the published fact set, so alteration is detectable without trusting the server that served it. A declared tier and date state how much corroboration stands behind the facts and when.
No, and the best setup uses several. Publish llms.txt, keep schema.org markup accurate, keep third-party listings correct, and add a record for portable, owner-controlled provenance. They sit at different layers — page, file, platform, DNS — and the specification's own relationship table lists the others as orthogonal and complementary rather than superseded.
An llms.txt file and accurate schema.org markup cost nothing but time and are the highest-value first move for most sites. If you then want owner-provable facts, a self-declared v=AEO1 record is also free, requires no account, and takes one DNS entry plus one JSON file at /.well-known/aeo.json. A no-account generator is available at groundedaeo.com/free-record, and npx aeo-record yourdomain.com checks your work.