Structured data in 2026: what to add and what to skip

In 2026, structured data (schema.org markup) is not a ranking trick; it is a label that helps Google pin down who you are, what you publish and who wrote it. For most service businesses, an accurate Organization block on the homepage and a proper BlogPosting on articles is enough; FAQPage no longer earns any special search appearance, and Service is optional. The one thing that reliably hurts is markup that describes something other than what is visible on the page.

We are writing this now because over the past year and a half Google has switched off one schema-driven search feature after another, and much of the old advice on what to put in your JSON-LD is out of date. Every new page we ship gets its markup from a template, so we had to rethink what stays in it too.

What is structured data still good for in 2026?

In June 2025 Google phased out seven structured data features from the results page (including Course Info, Estimated Salary and Vehicle Listing), followed by practice problems in November 2025 and FAQ rich results in May 2026. All of it is traceable in the Search Central documentation changelog.

Plenty of people concluded that schema is dead. We think that is the wrong takeaway. The flashy extras are shrinking, but the original job of markup, stating in machine-readable form what is what on a page, is still there. Google's Organization documentation, for example, is explicitly about helping Google tell your company apart from similarly named ones, and it can influence which logo appears in results and in your knowledge panel.

What we will not promise: that schema moves you up the rankings, or that AI search tools will cite you because of it. Google's guidance on AI features says there are no extra technical requirements for appearing in AI Overviews; it points to standard SEO fundamentals and structured data that matches the visible content. We looked at what AI Overviews actually cite in our own measurement.

What should go into your Organization markup?

This is the one type we recommend to every business. Google suggests placing it on the homepage, and it has no required properties: add what is true for you. We include:

• name and, where relevant, legalName (the brand and the registered company name often differ),
• url and logo (keep the logo at a stable URL, not a hashed build asset),
• sameAs: official profiles (LinkedIn, Facebook, GitHub), and only the ones you actually run,
• contact details: email, telephone, address, if they also appear on the site,
• a stable @id so markup on other pages can reference it.

Google's docs also list identifiers such as iso6523Code and naics, used behind the scenes for disambiguation. For a small business they rarely matter; an accurate name, URL and sameAs are worth more.

A minimal but useful example (it goes inside a <script type="application/ld+json"> element; Google recommends JSON-LD):

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "name": "Example Studio",
  "legalName": "Example Studio Ltd.",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/logo.png",
  "email": "hello@example.com",
  "sameAs": [
    "https://www.linkedin.com/company/example-studio"
  ]
}

Organization or LocalBusiness?

If you have a physical location customers walk into (a shop, a clinic, a salon), a LocalBusiness subtype is more precise, with opening hours and an address. If you mostly work online or by appointment, stick with Organization. In our view, your Google Business Profile matters more for local results than any markup.

Do service pages need Service markup?

Short answer: they don't need it, but they can have it. Service is a valid schema.org type, but it is not in Google's list of supported markup, so it does not unlock any search feature. The Rich Results Test will not show it as an eligible result either, which confuses a lot of people.

We add it when a page genuinely describes one well-defined service and the markup simply summarises what is visible: name, description, provider (pointing to the Organization @id), areaServed. Nothing more. Two things we deliberately avoid:

• Prices or offers in the markup that are not on the page. Whatever is in the JSON-LD should be visible to visitors too.
• Your own reviews as stars. Google's review snippet guidelines say self-serving reviews that an Organization or LocalBusiness collects about itself on its own site are not eligible for star display. aggregateRating on a service page is, at best, ignored.

Ecommerce is a different story: Product and merchant listing markup is an area Google actively supports and keeps expanding, and price, stock and shipping can show up in results. We handle that by default in the webshops we build.

What should you do with FAQPage now that FAQ results are gone?

Google had already limited FAQ rich results to well-known government and health sites in August 2023, and on 7 May 2026 it removed them entirely. According to the changelog, the documentation was taken down in June, along with FAQ support in the Rich Results Test and the Search Console report. In the deprecation notice Google also stated that structured data that is not being used does not cause problems for Search.

Our practice:

1. Existing markup on a genuine FAQ block can stay. It is valid schema.org, it does no harm, and we cannot rule out other systems reading it.
2. We no longer add FAQPage for the sake of search appearance. That appearance is gone.
3. The visible Q&A section itself stays. Short, specific questions with direct answers: readers and AI search tools understand that from the text, not from the JSON-LD.

If you used to put an FAQ on every page purely for the rich result, with the same generic questions, now is a good time to clean up. Three real questions beat ten filler ones.

How should you mark up a blog post?

Google's Article documentation accepts Article, NewsArticle or BlogPosting and lists no required properties; you add the recommended ones that apply. We use:

• headline: the article's real title, not a keyword-stuffed variant,
• author: a Person with a name and a url pointing to a real author page (Google recommends marking that page up as ProfilePage, or using sameAs as an alternative),
• datePublished and dateModified, with a time zone,
• image, if the article has one,
• publisher: a reference to the Organization @id, so you don't repeat the company in every post.

We only update dateModified when the content has meaningfully changed. Bumping the date without edits is a cheap trick, and readers notice when an "updated" article still carries old numbers.

How do you check that it is all correct?

We use three tools, because each sees something different:

Tool	Good for	Not for
Rich Results Test	Errors in Google-supported types (Organization, Article, Product)	No longer evaluates Service or FAQPage
Schema Markup Validator	Syntax checks for any schema.org type	Doesn't tell you what Google does with it
Search Console	Live, site-wide issues	Only reports on supported types

The most common problem we find in audits is not a missing property but drift: a template or plugin still writes the old title, phone number or logo into the markup while the page shows something else. That is why our JSON-LD is generated from the same data as the page itself, not kept as a separate hand-edited block. With custom systems this is worth deciding during development; retrofitting it costs more.

For the bigger picture, our technical SEO article covers structured data alongside crawling, rendering and llms.txt.

Frequently asked questions

Does structured data improve my rankings?

It gives no direct ranking boost. It helps Google understand and unambiguously identify your content and your company, and for some types (products, for instance) it enables richer results.

Do I have to remove my FAQPage markup?

No. Google says unused structured data does not cause problems. If the FAQ is genuine and visible on the page, it can stay; if it only went in for the old rich result, feel free to clean it up.

Microdata or JSON-LD?

Google understands both but recommends JSON-LD, because it is separate from the HTML and easier to generate from templates and maintain.

Does schema help ChatGPT or AI Overviews cite me?

We know of no primary source we would build on for that. Google does not require any special markup for its AI features. Accurate, visible, well-structured text is what counts; markup at most supports it.

If you are not sure your site's markup reflects reality, our free SEO and AI visibility audit covers it too: what is missing, what is outdated, and what contradicts the page content.