entitymap.json for Treatment Centers: The Second Two-File Hedge for AI Search

In September 2024, Jeremy Howard proposed llms.txt as a simple markdown file that would tell LLMs what a site is about. Two years later, no major AI system has confirmed reading it, Google Search ignores it, and Lighthouse still lists it as an AI-readability audit item.

Treatment centers we work with ship it anyway. The cost is one static file. The upside, if any AI lab ever consumes it, is non-zero.

In April 2026, Fred Laurent of Waikay and Dixon Jones of InLinks published v1.0 of a second proposed standard called entitymap.json. Where sitemap.xml tells crawlers what pages exist, entitymap.json tells AI systems what a site knows: which entities the site covers, how those entities relate, and which passages of content ground each entity.

Like llms.txt, no major AI lab has committed to consuming it. Unlike llms.txt, the payload is structured JSON with source-attributed evidence chunks that any RAG pipeline can actually parse.

This piece walks what entitymap.json is, why treatment centers benefit from the pre-work regardless of adoption, and how to build one that reflects your parent org, facilities, programs, clinicians, and accreditations. It sits alongside our content and SEO practice, complements our entity SEO explainer, and fits inside the broader AI search stack our team deploys.

What entitymap.json Is

entitymap.json is a proposed open standard published by Fred Laurent (Waikay) and Dixon Jones (InLinks) at entitymap.org, released as v1.0 on April 7, 2026, under a CC BY 4.0 license. The specification lives on GitHub and defines a JSON schema for publishing a machine-readable index of the entities, relationships, and evidence a site covers.

The premise is that AI retrieval systems today operate at the page level. They fetch HTML and extract passages without a structured awareness of the underlying entities, publisher identity, or the relationships between concepts on the site. This produces three specific failures.

Disambiguation. The same concept under different surface forms gets treated as separate signals rather than as one entity. On a treatment center site, “PHP,” “Partial Hospitalization,” and “day treatment” refer to the same clinical program. AI retrieval that reads only the page HTML often does not resolve them cleanly to one entity.

Attribution. When a passage of content gets retrieved into an AI answer, the publisher identity often does not survive the aggregation. Treatment center content that gets consumed into an AI Overview loses the citation trail. That trail would otherwise tell the AI system (or a downstream user) that the content was originally published by a specific accredited operator at a specific URL.

Relationships. Connections between concepts (which clinician works at which facility, which modality is offered in which program, which condition is treated at which LOC) are buried in prose rather than declared as explicit, typed relations.

entitymap.json addresses those three failures by giving publishers a standard way to declare their entities, evidence, and relationships in a machine-readable file at a predictable URL.

What It Looks Like

An entitymap consists of two files published at predictable root-level URLs on your domain. The machine-readable JSON file lives at yoursite.com/entitymap.json. A companion human-readable HTML view lives at yoursite.com/entitymap.html.

The JSON file contains three core building blocks.

Entities are the named things your organization covers. These include your parent org, your facilities, your programs, your clinicians, your accreditations, and your service areas.

Relations map how those entities connect. Which clinician works at which facility, which modality is offered in which program, which LOC is available at which location.

Evidence chunks are passages from your website that support each entity, linked to their source URL with attribution metadata (publisher name, page title, retrieval timestamp).

A minimal entity entry carries an internal entity ID, a type declaration, a name, and a short description. It also carries a sameAs URL that grounds the entity in an external authority (Wikidata, LinkedIn, an accreditation body’s directory), plus one or more evidence chunks.

The specification defines 23 standard relationship predicates in v1.0. These are the verbs that connect entities.

For treatment centers, the predicates that matter most are OFFERS (facility offers program), TREATS (program treats condition), EMPLOYS (facility employs clinician), ACCREDITED_BY (facility accredited by JCAHO or CARF), LOCATED_IN (facility located in service area), and PART_OF (facility part of parent organization).

entitymap.json v1.0 at a glance

Why Treatment Centers Specifically Benefit

Behavioral health has three entity-graph failure modes that make the pre-work more valuable than in most industries.

Modality name collision. The same modality names run across hundreds of centers. “TMS,” “CBT,” “DBT,” “EMDR,” “MAT,” and dozens of other acronyms show up on nearly every BH site. Without an entity map that anchors your specific offering to a canonical modality entity with a sameAs URL to an authoritative reference, AI retrieval cannot tell your TMS program from the TMS program at the center down the street.

Clinician-facility ambiguity. The same clinician often works at multiple facilities under multiple brands, especially in portfolio-operator networks. Without an explicit EMPLOYS relation grounded in Person schema and a sameAs link to the clinician’s state license lookup or LinkedIn, AI retrieval systems cannot reliably associate the clinician with the correct treating facility.

Accreditation and license drift. JCAHO status, CARF accreditation, LegitScript certification, and state license numbers are the highest-authority signals a treatment center can publish. Most sites list them once in the footer and never resolve them as first-class entities.

Those three failure modes are common enough that building the entity inventory has value even if no AI lab ever fetches the file. The inventory itself becomes the source of truth for the Schema.org deployment, the AI Information page, the internal linking discipline, and the anchor text patterns that flow from there.

How to Build One for a Treatment Center

The load-bearing work happens before you touch the JSON file. It is the entity inventory.

Layer one: the parent org and facilities

The parent organization is entity zero. Each physical facility is a distinct entity with a canonical name, physical address, phone number, NPI number, state license number, and sameAs links to Google Business Profile, the state licensing database entry, and any relevant accreditation directory.

Layer two: programs, LOCs, and modalities

Each program (residential, PHP, IOP, outpatient, detox) is a distinct entity, offered by a specific facility via an OFFERS relation. Each modality (individual therapy, group therapy, family therapy, TMS, ketamine-assisted therapy, MAT) is a distinct entity offered by a program via an OFFERS relation.

Layer three: conditions treated

Each primary condition or diagnosis the facility treats (SUD, AUD, dual diagnosis, PTSD, depression, anxiety, bipolar, OCD, eating disorders) is a distinct entity, with TREATS relations declared from the program entity to the condition entity.

Layer four: clinicians and leadership

Each clinical author, medical director, program director, and executive is a distinct Person entity, with sameAs links to LinkedIn, state license lookup (state medical board or DPH directory), and any specialty board certification. Our clinical author bio E-E-A-T pass covers the Person entity fields in depth.

Layer five: accreditations and licenses

Each accreditation (JCAHO, CARF), certification (LegitScript), and state license is a distinct entity, with ACCREDITED_BY relations from the facility entity to the accreditation entity. Each accreditation entity carries a sameAs URL to the accreditation body’s directory listing for that specific facility, which is the load-bearing external signal for the AI system.

Layer six: service areas

Each geographic service area (city, county, MSA) is a distinct Place entity, with SERVES relations from the facility entity to the service area entity. This layer only makes sense for facilities with a meaningful geographic service footprint.

Once the six layers are inventoried, the JSON generation itself is mechanical. The Waikay reference generator handles the conversion. The validator at entitymap.org/validate confirms conformance to v1.0.

Evidence Chunks: The Payload That Matters Most

The predicate graph gets attention, but the evidence chunks are the piece that AI retrieval systems could actually use directly. Each entity in the map should carry one or more evidence chunks: passages from your site content, linked to their source URL, that support the entity.

For a treatment center, the evidence chunks are the passages on your site that describe each entity in your own words with your own operator perspective. The description of your specific TMS protocol from your TMS service page. The description of your specific dual-diagnosis approach from your dual-diagnosis LOC page. The bio-graph passage that describes your medical director’s specific credentials from your team page. Each chunk carries a sourceUrl that anchors it to the source page and metadata that identifies you as the publisher.

Evidence chunks are the mechanism that closes the attribution gap. When a RAG pipeline reads your entitymap, it does not have to guess where the evidence came from. The chunk carries the URL, the page title, the publisher name (your organization), and the retrieval timestamp. If the pipeline uses those chunks to generate an AI answer, the attribution trail survives.

This is also the reason the entitymap pre-work is valuable regardless of AI adoption. Producing the evidence chunks forces you to write and maintain the specific passages that describe each entity in a way that would hold up under retrieval. That discipline is the same one behind the E-E-A-T standard for clinical content and the get-cited-in-AI-search framework our practice deploys.

Publishing and Declaring the Map

The publishing step is straightforward. Upload entitymap.json and entitymap.html to the root of your domain. On WordPress, that means uploading them into the site root at the same level as robots.txt and sitemap.xml, not into /wp-content/uploads/.

The declaration step has three pieces per the v1.0 specification.

The first is a line in robots.txt declaring the file location. The specification uses the syntax EntityMap: https://yourdomain.com/entitymap.json, added as a new line alongside your existing sitemap declarations.

The second is a <link> tag in the site <head>, with rel="entitymap" and type="application/json" and href pointing to the JSON file. This is analogous to the way sitemap.xml gets declared via the <link rel="sitemap"> pattern.

The third is a sitewide footer link to the human-readable entitymap.html companion. The specification calls the footer the most reliable discovery mechanism because it survives changes to robots.txt and head-tag parsing quirks.

Where entitymap.json Fits Alongside the Rest of the Stack

entitymap.json does not replace Schema.org, llms.txt, or the AI Information page. It complements them. The v5.7 AI-readability stack for treatment centers now has four surfaces, each with a different consumer and a different failure mode when it is missing.

Schema.org (Organization, LocalBusiness, MedicalClinic, Person, MedicalSpecialty) is consumed by Google, Bing, and every major crawler. It is the load-bearing surface. Missing schema breaks Rich Results, Knowledge Graph inclusion, and entity resolution across every retrieval system.

llms.txt is a proposed markdown standard for AI systems. Not confirmed consumed by any major AI lab. Cheap to ship. Same two-surface hedge as entitymap.json but with a fluffier payload.

entitymap.json is a proposed JSON standard for AI systems. Not confirmed consumed by any major AI lab. Ship the pre-work regardless.

The AI Information page is a human-readable page at /ai-information/ or /about-for-ai/ (Webserv’s own version lives at webserv.io/ai-instructions/). It is the canonical, label-value factual reference that ChatGPT, Claude, Perplexity, and Gemini can crawl at page load and cite verbatim.

The relationship between the four surfaces is that they carry the same underlying entity model rendered in four different formats for four different consumers.

The entity inventory that produces entitymap.json is the same inventory that produces the Schema.org markup, the llms.txt file, and the AI Information page. Doing the inventory once and rendering it four ways is materially cheaper than treating each surface as an independent project. Our AI Mode vs AI Overviews piece covers where each surface tends to matter most across the current AI search landscape.

What Not to Expect

Two expectations get set incorrectly around entitymap.json.

The first is that shipping entitymap.json will produce a measurable rank or citation lift on its own. It will not, at least not attributable to entitymap.json itself. No major AI lab has confirmed consuming the file. The citation lift the Waikay case study reports comes from a compound intervention (entitymap + Schema.org + evidence chunks). That compound intervention would produce similar lift with or without the entitymap file. The correct frame is that entitymap.json is a low-cost hedge, not a rank lever.

The second is that entitymap.json replaces the AI Information page or the Schema.org markup. It does not. The four surfaces are complementary. Building entitymap.json without also deploying Organization + MedicalClinic + Person schema leaves the highest-ROI surface untouched. The pre-work of inventorying entities produces value on all four surfaces at once, which is why treating them as a unified stack rather than four independent projects is the right operating frame.

The correct adoption timeline for entitymap.json matches what llms.txt got in late 2024. Ship it, publish it, forget it. If an AI lab announces consumption, the file is already in place. If none ever does, the pre-work still produced the entity inventory that improved the other three surfaces.

Frequently Asked Questions

Trevor Gage is the Director of Marketing at Webserv, a digital marketing agency for treatment centers.