Structured Data: Schema That Matches What the Page Shows

Structured data is code in a standardized format, usually schema.org vocabulary written as JSON-LD, that describes a page’s entities and their properties to search engines. This article defines structured data, sets out the schema.org types that matter for service businesses, and explains JSON-LD and one connected graph built from @id references. It then covers matching markup to visible content, testing structured data, and structured data on holisticradar.com as a worked example. It closes with structured data in technical SEO services, followed by rich results eligibility, structured data in AI answers, and schema plugins.

What structured data is

Structured data is code in a standardized format that describes a page and the entities on it, such as an organization, a person, a service, or an article, using a shared vocabulary that search engines read without interpreting prose.

The shared vocabulary is schema.org, launched in June 2011 by Google, Microsoft, and Yahoo, with Yandex joining later that year. Schema.org defines types, such as Organization and BlogPosting, and properties, such as name, author, and datePublished. A page uses those types and properties to state facts that its visible text already contains, in a form a parser can read directly.

Google supports three formats for structured data:

• JSON-LD. A JavaScript object placed in a script element of type application/ld+json, separate from the visible HTML. Google recommends it as the easiest format to implement and maintain.
• Microdata. Attributes added to the visible HTML elements themselves.
• RDFa. An HTML extension that also adds attributes to visible elements.

Structured data does two jobs. It makes a page eligible for rich results, the enhanced search displays such as breadcrumbs or article features that only appear when the required properties are present. It also states entity facts explicitly: who publishes the site, who wrote the article, which service a page describes, and how those entities relate. Google’s documentation describes Organization markup, for example, as a way to help Google understand an organization’s administrative details and disambiguate it in search results.

Schema.org types for service businesses

Seven schema.org types describe a service business website: Organization, WebSite, Service, Person, BlogPosting, FAQPage, and BreadcrumbList.

Each type has a different relationship with Google’s search features. Organization markup has no required properties in Google’s documentation, and it supports the logo and knowledge panel details shown for a business. WebSite markup on the home page is one of the sources Google uses for the site name shown in results. Article markup, which BlogPosting extends, helps Google read an article’s title, images, and dates. BreadcrumbList is eligible for the breadcrumb display in results. Service has no dedicated Google rich result, but it states which services the Organization provides. FAQPage remains a valid schema.org type, although Google stopped showing FAQ rich results in Search on May 7, 2026.

The most specific accurate type is always chosen. Google’s guidelines ask for the most specific applicable type, so an article is a BlogPosting or an Article, not a generic CreativeWork, and an author is a Person linked to the Organization, not a free-text name.

JSON-LD and one connected graph

A connected graph is one JSON-LD block whose @graph array defines each entity once, gives it an @id, and refers to it by that @id everywhere else on the site.

An @id is an identifier for a node, conventionally the URL of the page that defines the entity followed by a fragment, such as https://holisticradar.com/#organization. It does not have to resolve to a separate page. Any other node that needs the organization, such as a WebSite’s publisher or an article’s publisher, points to it with {"@id": "https://holisticradar.com/#organization"} instead of describing it again.

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization", "@id": "https://holisticradar.com/#organization",
      "name": "Holistic Radar", "url": "https://holisticradar.com/" },
    { "@type": "WebSite", "@id": "https://holisticradar.com/#website",
      "url": "https://holisticradar.com/",
      "publisher": { "@id": "https://holisticradar.com/#organization" } },
    { "@type": "BlogPosting", "@id": "/learn/structured-data/#article",
      "headline": "Structured Data: Schema That Matches What the Page Shows",
      "publisher": { "@id": "https://holisticradar.com/#organization" },
      "isPartOf": { "@id": "https://holisticradar.com/#website" } }
  ]
}

A connected graph is built in five steps:

1. List the entities. Name every entity the site describes: the organization, the website, each person, each service, and each page type.
2. Assign one @id to each. Fix the identifier pattern once, such as the home URL plus #organization and #website, and each page URL plus #webpage or #article.
3. Define each entity in one place. The full Organization node, with its description and logo, is defined once; every other node refers to it.
4. Connect with properties. Use publisher, author, worksFor, provider, isPartOf, mainEntityOfPage, and breadcrumb to state how the nodes relate.
5. Output one block per page. Each page emits a single script containing its own nodes and references to the shared ones.

The connected graph prevents the most damaging structured data fault: two descriptions of the same entity that disagree. When a theme outputs one Organization node and a plugin outputs another with a different name or description, the page makes two conflicting claims about who publishes it. One graph with one definition per entity makes that conflict impossible.

Matching markup to visible content

Structured data must describe content that is visible on the page, and Google’s general structured data guidelines state that content not visible to readers should not be marked up.

The guidelines set out the conditions that markup has to meet before it is used for rich results:

• Relevance. The markup describes the page it is on; a page of instructions is not marked up as a recipe.
• Completeness. All required properties for the rich result type are present.
• Location. The markup sits on the page it describes, not on a different page of the site.
• Specificity. The most specific applicable type and property are used.
• Accuracy. The values match what the page shows, and they are current.
• Images. Referenced images are crawlable, indexable, and relevant to the page.

Markup that violates the guidelines can lead to a manual action, which removes the page’s eligibility for rich results. The rule also has a reason beyond penalties: structured data that repeats visible facts confirms them, while structured data that adds facts the page does not show gives a search engine two versions of the page to reconcile.

Testing structured data

Structured data is tested with three tools: the Rich Results Test for Google rich result eligibility, the Schema Markup Validator for schema.org validity, and Search Console reports for errors across the live site.

The Schema Markup Validator, hosted by schema.org since 2021, replaced Google’s older Structured Data Testing Tool for general validation. A full test runs in order:

1. Validate the vocabulary. Run one page of each template through the Schema Markup Validator and fix every type and property error.
2. Check eligibility. Run the same pages through the Rich Results Test and add any missing required properties.
3. Count the blocks. Read the rendered source of each template and confirm one JSON-LD graph per page, with no second Organization or WebSite node from another system.
4. Compare with the page. Check every marked-up value against the visible text, including dates, names, and FAQ answers.
5. Monitor the live site. Watch the Search Console reports for new errors after every template, theme, or plugin change.

Structured data on holisticradar.com

The holisticradar.com theme outputs one schema graph in JSON-LD, containing Organization, WebSite, founder Person, WebPage, Service, BlogPosting, FAQPage, and BreadcrumbList nodes.

The SEO plugin on the site keeps its other jobs (titles, meta descriptions, and the XML sitemap), but its JSON-LD output is disabled, and older schema functions in the theme were retired. As a result, no node is ever described twice. The Organization is defined once with the identifier /#organization and one description, the WebSite once as /#website, and every other node refers to them.

Social profiles are declared with sameAs on the Organization and Person nodes rather than as visible outbound links in articles. The graph still connects each entity to its profiles elsewhere on the web, while every article keeps its rule of zero outbound links. Every author in the graph resolves to a team profile, and every FAQPage node is generated from the same questions and answers a reader sees, so the markup never states a fact the page does not show.

Structured data in technical SEO services

Structured data is simple on one page and difficult across a site. The faults that matter only appear when every template is read together: duplicate nodes from a theme and a plugin, an Organization described two ways, authors with no link to a profile, and markup that no longer matches the page after a redesign.

Holistic Radar’s technical SEO services build one structured data graph per site, in which every entity is defined once and referenced by its identifier everywhere else. The work includes choosing which system owns the JSON-LD, switching off every other emitter, and testing each template against both schema.org and Google’s eligibility rules.

→ Technical SEO services: one structured data graph per site, with one owner, one definition per entity, and markup that matches the page.

Structured data for rich results eligibility, AI answers, and schema plugins

Does structured data guarantee rich results?

Structured data does not guarantee rich results; it makes a page eligible, and Google decides whether to show the enhanced display. Google also retires rich result types: HowTo rich results were removed in 2023, and FAQ rich results stopped appearing in Search on May 7, 2026, with the FAQ report removed from Search Console afterwards. Markup for retired features is still valid schema.org and still describes the page, but it no longer produces a visible result on Google.

Does structured data help a page appear in AI answers?

Structured data is not required to appear in Google’s AI features; Google’s documentation states that there are no additional requirements, and no special schema.org structured data, needed to appear in AI Overviews or AI Mode. What structured data does provide is an explicit statement of the entities on a page and how they relate, which removes ambiguity about who published a fact and who wrote it. That value holds only when the markup matches the visible text, because an answer engine quotes the page, not the JSON-LD.

Should a site use a schema plugin?

A site can use a schema plugin when the plugin is the only system that outputs structured data. Conflicts start when a theme, an SEO plugin, and a second plugin each emit their own Organization or WebSite node with different values. The decision that matters is not which tool generates the markup but that exactly one tool does, and that every other emitter is switched off.

→ Entity SEO: how the entities a structured data graph declares are defined and made consistent across a site.

→ AI search optimization: how AI search engines select and cite pages, and what structured data contributes.

→ Technical SEO checklist: where structured data testing sits among the other technical checks a site needs.

Schema consistency is one input to the AI Confidence method. → AI Confidence