Use structured data to describe reality

Start with the visible content

Structured data is a standardized format for providing information about a page and classifying its content. Google uses it to understand the page and to power some rich results, and recommends JSON-LD as the format.^[1] The guiding rule is that markup must describe what the visitor can see. Google’s policies treat structured data that does not represent the main content of the page, or that refers to content hidden from users, as a violation that can lead to a manual action, after which the page loses eligibility for the related features.^[2]

Google’s own introduction cites a case study in which Nestlé measured pages that appeared as rich results as having an 82% higher click-through rate than pages that did not.^[1] That is a company-reported figure for a feature that exists only for specific content types. It shows why markup is worth doing where a rich result exists, and it does not apply to pages for which Google offers no feature.

Know what markup is for, and what it is not

The supported features also move. Google’s change log shows the FAQ rich result no longer appearing from May 2026, the How-to rich result deprecated and the practice problem structured data documentation removed in January 2026 because it no longer appears in Search.^[6] Google’s guide to optimizing for generative AI search is explicit: structured data is not required for it, and there is no special schema that you need to add. Markup that is present should match the visible text.^[5][7] Pick markup because it describes your content accurately or because a documented feature rewards it. Do not add it as a hopeful gesture toward AI.

Connect the entities

Most business pages need only a few types: an Organization for who you are, an Article or WebPage for the page, a Person for a named author and a BreadcrumbList for the hierarchy. Google lists no required properties for Organization and recommends a name, URL, logo and links to your profiles elsewhere through sameAs. It uses the logo, which must be at least 112 by 112 pixels and crawlable, when choosing what to show, and notes that the name should match the name you use for your site.^[4] For articles, the example properties include the headline, the publication and modification dates and the author.^[8]

Give each entity an @id and refer to it by that identifier from the pages that depend on it. Then one fact lives in one place: change the organization’s logo once, and every article that names it as publisher inherits the change.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Northside Physio",
      "url": "https://example.com/",
      "logo": "https://example.com/logo-512.png",
      "sameAs": ["https://www.linkedin.com/company/northside-physio-example"]
    },
    {
      "@type": "Article",
      "@id": "https://example.com/guides/hamstring-strain/#article",
      "headline": "Hamstring strain: recovery stages and when to see a physio",
      "datePublished": "2026-03-02",
      "dateModified": "2026-09-14",
      "author": { "@type": "Person", "name": "Sam Okafor", "url": "https://example.com/team/sam-okafor/" },
      "publisher": { "@id": "https://example.com/#organization" },
      "mainEntityOfPage": "https://example.com/guides/hamstring-strain/"
    }
  ]
}
</script>

The example is illustrative: the clinic, person and URLs are invented. JSON-LD 1.1 is a W3C Recommendation, and the vocabulary comes from schema.org.^[9]

Validate the deployed page

Validate the live URL, not just the snippet you wrote. Template logic, caching and plugins can all change what ships. Use the Rich Results Test to see which Google features the page is eligible for, and a general validator such as the Schema Markup Validator to check syntax against schema.org.^[10] In Search Console, the Manual Actions report shows whether Google has applied a structured data action to your site.^[2] Re-test after every template change, and check that the visible page and the markup still agree.

Model one page before scaling the template

Write the markup for one real page by hand, compare it with the visible page and fix the differences. Only then turn it into a template. The dangerous failures are the ones a template repeats across hundreds of pages: a dateModified that updates on every deploy even though the content did not change, an author field that falls back to a generic value or a logo URL that moves after a redesign.

Avoid decorative claims in metadata

Do not mark up what a visitor cannot verify. Star ratings that are not displayed, reviews you wrote about your own business and prices that differ from the page are the usual temptations. Google’s review snippet documentation limits markup for the Organization and LocalBusiness types to sites that capture reviews about other businesses and points to its guidelines on self-serving reviews.^[11] If a claim would embarrass you when printed on the page, it does not belong in the markup either. The same discipline applies to AI-assisted content: Google’s guidance includes structured data among the metadata that must be fact-checked before publishing.^[12]

Apply it to your website

• Every property in the markup has a visible counterpart on the page.
• You use JSON-LD, with only the types that fit the content, and no markup added in the hope of an AI benefit.
• The organization, the page and the author are separate entities linked by @id and shared across pages.
• The deployed URL is validated, and Search Console reports are checked after template changes.
• dateModified changes only when content meaningfully changes, and the author fields name a real person.
• You do not mark up self-serving reviews, hidden content or prices that differ from the page.
• You review your markup when Google changes or removes a feature that you used.