Structured Data

Structured data is information on a webpage marked up in a machine-readable format, usually JSON-LD using the Schema.org vocabulary, so search engines and AI engines can understand what the page is about, who published it, and how its facts relate to one another. It powers rich results and AI citations.

For treatment centers, structured data is the difference between a page Google reads as a wall of text and a page Google reads as a set of confirmed entities. The first ranks on luck. The second becomes eligible for rich snippets, knowledge panels, and citation inside AI Overviews.

This page covers what structured data is, why it matters for behavioral health visibility, the core schema types every facility site should ship, and the mistakes that get markup ignored by the engines that count.

What Structured Data Is

Structured data is a code layer that describes a page’s content in a vocabulary the search engines agreed on. Instead of reading “Dr. Jane Smith is the medical director” as a sentence and guessing, the engine reads JSON that says: Person, name: Jane Smith, jobTitle: Medical Director, worksFor: [the facility].

That shared vocabulary is Schema.org, a project Google, Microsoft, Yahoo, and Yandex launched in 2011. Schema.org defines hundreds of types (Organization, Person, MedicalBusiness, Article, FAQPage, Service) and the properties each accepts. When a page uses Schema.org correctly, every major engine reads it the same way.

Three formats can carry Schema.org markup: JSON-LD, Microdata, and RDFa. JSON-LD is the standard now. Google explicitly recommends it. It sits in a single <script> block in the page head or body, separate from the visible HTML, which keeps markup easy to audit and easy for AI engines to parse.

Microdata and RDFa interleave markup with HTML attributes. Both still work technically, but they make audits painful and they fragment the entity map across the document. New structured data in 2026 should be JSON-LD unless there’s a specific legacy reason not to.

Why Structured Data Matters for Treatment Centers

Three reasons, in order of how much they affect patient acquisition today.

First, rich results in the SERP. FAQ accordions, breadcrumbs, review stars, site links, and image carousels all depend on the right schema being present and valid. A page with FAQ schema can occupy three times the SERP real estate of a competitor without it. Measurable click-through gain.

Second, AI citation eligibility. AI Overviews, ChatGPT, and Perplexity parse structured data when deciding which sources to cite. They use it to confirm entities on a page before treating it as a citable source. A page without structured data is harder for an AI engine to trust enough to quote.

Third, entity confirmation in the knowledge graph. Google maintains the Knowledge Graph as a database of real-world entities. Organization markup with sameAs links to LinkedIn, Wikipedia, licensing boards, and accreditation bodies is the primary signal Google uses to add a facility to that graph and surface a knowledge panel.

For behavioral health, where competitor confusion and brand misattribution in AI answers are common problems, that entity confirmation is the difference between owning your facility’s identity online and watching ChatGPT describe a different facility under your name.

How Structured Data Works

Every JSON-LD block opens with two declarations: @context and @type. The context tells the engine which vocabulary is in use (almost always https://schema.org). The type tells it what kind of thing the block describes (Organization, Service, Article, etc.).

After that, properties describe the entity. An Organization block might include name, url, logo, address, sameAs, and contactPoint. A Person block might include name, jobTitle, image, and worksFor pointing back to the Organization. Each property maps to a Schema.org definition that specifies the value it accepts.

The signal multiplier is the @graph array. Instead of three separate JSON-LD blocks for Organization, Person, and Service, a single @graph holds all three as connected nodes, each with its own @id. Properties on one node reference another by @id, building a map of the entity relationships.

That graph structure is the level of detail AI engines reward. They parse the relationships, not just the nodes. A MedicalBusiness node with medicalSpecialty pointing to a Service, employee pointing to a credentialed Person, and sameAs linking to LegitScript or CARF gives the engine an entity it can confirm.

Core Schema Types for Behavioral Health

A treatment center website rarely needs more than ten types, but those ten need to be tight and connected.

Organization and MedicalBusiness

Organization is the base type for any entity that publishes content. MedicalBusiness is the subtype for licensed medical providers. A facility should mark up as MedicalBusiness on the homepage and About page, with address, phone, founder, employee list, and sameAs links to LinkedIn, the licensing board, JCAHO, CARF, or LegitScript.

Person

Every clinical leader and clinical reviewer should have a Person node with jobTitle, hasCredential (degrees and licenses), worksFor (the MedicalBusiness), and sameAs (LinkedIn, state licensure registry). Person markup is the schema layer that supports E-E-A-T for YMYL content.

Service

Each level of care (detox, residential, PHP, IOP, outpatient) and each specialty program (dual diagnosis, trauma, MAT) maps to a Service node. The Service connects back to the MedicalBusiness via the provider property, which is how the engine understands that the facility offers that service.

FAQPage

FAQPage markup powers the FAQ accordion rich result and gives AI engines a clean question-answer structure to quote from. The schema must match visible FAQs on the page. Webserv standardizes on the Rank Math FAQ Block, which generates the visible Q&A and the FAQPage JSON-LD together.

Article

Article (or MedicalWebPage for clinical content) marks up blog posts and resource pages with author, datePublished, dateModified, mainEntityOfPage, and image. For YMYL behavioral health content, MedicalWebPage with a reviewedBy property pointing to the clinical reviewer’s Person node is the stronger signal.

Review and AggregateRating

Review markup is high-risk in healthcare. Google has tightened policy: review schema must reflect first-party reviews shown on the page, not aggregated third-party data. Misuse triggers a manual action. Skip review markup unless the site shows moderated alumni testimonials.

Place and ImageObject

Place handles the physical address and geo coordinates for location pages. ImageObject describes facility photos with contentUrl, width, height, and a caption. That strengthens image carousels in the SERP and gives AI engines a confirmed image for the entity. Both pair with entity SEO on the primary location page.

Structured Data and Rich Results

A rich result is anything more than the standard blue-link, three-line snippet. They expand the page’s footprint in the SERP and pull users in before the click decision happens.

The rich results most relevant to behavioral health: FAQ accordions (FAQPage), breadcrumb trails (BreadcrumbList), site links (sitewide architecture plus Organization), knowledge panels (Organization with sameAs), image carousels (ImageObject), and review stars (with policy caveats).

Google has been narrowing rich result eligibility. HowTo was deprecated for non-DIY content. Review markup got tightened. FAQ rich results stopped showing on commercial pages and now favor informational ones. Schema isn’t decoration; it has to match page intent and visible content.

The win is still real. A treatment center informational page with FAQ schema and a breadcrumb trail occupies more pixels in the SERP than a competitor without either, even when ranking positions are identical. That’s not a minor advantage on mobile.

Structured Data and AI Citation

AI engines do not rank pages the way classic search does. They synthesize answers from multiple sources, then cite the sources that helped them build the answer. Citation selection is influenced by structured data in two specific ways.

First, entity confirmation. Before quoting a fact about a facility, an AI engine wants to confirm the facility is real, identifiable, and qualified. Organization plus MedicalBusiness markup with sameAs links to licensing boards is fast confirmation. Without it, the engine has to prove the same facts through inference.

Second, entity-fact pairs. The @graph structure lets the engine extract not just facts but the relationships between them. Person worksFor Organization. Organization provides Service. Service treatsCondition Addiction. That’s a set of semantic triples the AI engine can quote without paraphrasing into something inaccurate.

The practical result: pages with a complete, connected @graph get cited more often than pages with the same content and no markup. Webserv ships a full @graph on every capability page on this site as proof-of-concept. The structure isn’t theoretical; it’s the same pattern we build for client facilities.

Implementing Structured Data

The implementation answer in 2026 is JSON-LD, placed in the page head or body, generated either by a schema plugin (Rank Math, Yoast, Schema Pro) or by hand-coded blocks in the theme.

Hand-coded @graph in the theme is the stronger pattern because it connects nodes across templates. The homepage Organization, the About page Person nodes, the service page Service nodes, and the blog Article nodes all reference each other by @id, building one entity graph the engines read at any URL.

Plugin-generated markup is fine for simple sites but tends to ship disconnected blocks: an Organization block here, an Article block there, no @id linking between them. The engines still parse it, but they don’t get the relationship signals that drive citation eligibility.

Validators are non-negotiable. Google’s Rich Results Test checks rich-result eligibility. The Schema.org validator at validator.schema.org checks the broader vocabulary. Both should pass before deploy. Markup that throws errors gets dropped.

Common Structured Data Mistakes

Five patterns account for most of the structured data problems we see on audits.

Markup that doesn’t match the visible page. FAQ schema with five questions when the page shows two. Review stars from offsite testimonials. Service descriptions in JSON that don’t appear in body copy. Google requires schema to describe what the user sees. Mismatches trigger manual actions.

Missing required properties. Every Schema.org type defines required and recommended properties. An Article without author, datePublished, and image is technically valid but won’t qualify for the Article rich result. The Rich Results Test flags these as warnings; treat warnings as failures.

Organization markup without sameAs. The sameAs property is the strongest entity-confirmation signal in the vocabulary. It tells the engine this is the same entity as the LinkedIn profile, the LegitScript listing, the JCAHO record. Without it, the engine can’t disambiguate the facility from others with similar names.

Schema spam. Some sites stuff every available property with promotional copy, repeat the brand name in fields meant for other entities, or claim accreditations they don’t hold. Google catches this. It costs more than it saves.

Validator errors left in production. Rich Results Test reports both errors and warnings. Sites push markup with errors anyway because the page still “works.” It doesn’t. The schema gets dropped from the indexed signal set, and the rich result never appears. Fix every error before deploy.

Where Structured Data Fits in the AEO Stack

Structured data is foundational, not optional, for answer engine optimization. It carries the entity signals AI engines parse before citation. It carries the FAQPage and Speakable schema that AI Overviews and voice assistants quote from. It’s the signal layer that turns content into the entity profile topical authority rests on.

Webserv builds structured data into every SEO engagement as part of the technical foundation, and extends it into the deeper @graph patterns through our AEO practice. The two layers run together because they have to.

Frequently Asked Questions