How to Add Structured Data in 2026

Tomohiro Iida · Published: June 26, 2026Last updated: September 20, 2026

This guide covers the role of Schema/JSON-LD structured data, how to write it, and how to validate it, from a practical BtoB perspective.

What structured data is

Structured data is a way of labeling the meaning of the information on a web page in a format that search engines and AI can understand. A human reading the text 'Example Co., Ltd.' recognizes it as a company name, but to a machine it is just a string of characters. Structured data attaches labels — 'this is a company name,' 'this is an address,' 'this is a publication date' — using a shared vocabulary. That shared vocabulary is Schema.org.

Schema.org is a vocabulary standard jointly established by Google, Microsoft, Yahoo, and Yandex, defining 'types' such as Organization and Article, and 'properties' such as name and url. Structured data annotates page content using this Schema.org vocabulary.

The key point is that structured data is only a way of conveying information — it does not improve the content itself. Adding structured data to a thin page does not make the content any richer. Structured data's role is to take information already on the page and hand it to machines in a clearly labeled form.

It's a common question when structured data is added but ranking doesn't move and no rich result appears — this is expected once you understand what structured data actually does. It's an investment in conveying information accurately, not a guarantee of results.

Types and what each is for

Schema.org defines hundreds of types, but a BtoB site only needs to know a handful in practice. Here are the main ones and their roles.

Organization

Conveys the company name, logo, address, contact details, and official profiles. Google recommends putting Organization markup on the homepage or a single page describing the organization, such as About; it does not need to be repeated on every page. Keep it aligned with visible facts.

WebSite

Represents the website as a whole. For Google site-name preference, WebSite structured data belongs on the domain or subdomain homepage and does not need to be repeated on every child page. The old SearchAction sitelinks-search-box use case is discontinued.

BreadcrumbList

Conveys where a page sits in the site's hierarchy, making a structure like 'Home > Services > SIGNAL' machine-readable. Search-result URL displays sometimes take a breadcrumb format, so this is a type with a clear, easy-to-see benefit relative to its low implementation effort, making it a high priority.

Article / BlogPosting

Conveys a blog or column article's headline, author, publication date, and update date. NewsArticle is a reasonable choice for news-like content, BlogPosting for general blog posts. Indicating an author and publisher helps signal where the information comes from.

FAQPage

Structures visible questions and answers. Google FAQ rich results stopped appearing on May 7, 2026, and Google removed the corresponding documentation on June 15, 2026. Schema.org FAQPage still exists as a semantic type. Keep the visible FAQ useful on its own and do not equate semantic markup with a current Google Search feature.

Product

Schema.org defines Product broadly as an offered product or service. That semantic validity is separate from Google Product feature eligibility: product snippets require a page focused on a specific product and the required Product properties, while merchant listings add purchase and Offer requirements.

Service

Schema.org Service directly describes a service. Google Search does not list Service as a standalone rich-result feature, but that does not mean services can never use Product semantically. Choose the type that best matches the visible offering, then evaluate any Google feature separately.

LocalBusiness

Used by businesses with a physical location or premises that receive visitors, conveying business hours, address, and phone number. BtoB companies may consider this where office visits or local recognition matter; for online-only businesses without visitors, Organization is often sufficient, and there's no need to force in LocalBusiness.

The principle for choosing a type

Choose the type that matches the page's actual meaning, then separately decide whether it qualifies for a Google Search feature. Do not treat Organization or WebSite as decorative markup repeated everywhere; follow their recommended placement and add supporting types such as BreadcrumbList where they reflect the visible page structure.

The basics of writing JSON-LD

Structured data can be written in JSON-LD, Microdata, or RDFa, but JSON-LD is the common approach today and the one Google recommends. Because it sits in a script tag separate from the body HTML, it is easier to maintain.

A minimal Organization block, placed inside the HTML head (it also works in the body, but head is standard), is a JSON object with three parts: "@context" set to https://schema.org, "@type" set to "Organization," and properties such as name, url, and logo set to the company's actual name, URL, and logo image address.

• @context specifies the vocabulary source, always https://schema.org.
• @type specifies what kind of data this is.
• Everything after that is a set of properties and values defined for that type.

Values must always match what's actually displayed on the page — this is the fundamental rule of structured data.

Organization example

A typical Organization block adds sameAs entries — links to the company's official X (Twitter) and LinkedIn profiles, for example — alongside name, url, and logo.

BreadcrumbList example

A BreadcrumbList lists each level of the site hierarchy as a ListItem, with position for the order, name for the display label, and item for that page's URL. Keep the order and labels consistent with what your breadcrumb navigation actually shows.

BlogPosting example

A BlogPosting block sets headline to match the page title, and datePublished/dateModified to the actual publication and update dates, in ISO 8601 format (for example, 2026-06-26), along with author and publisher information.

Placing multiple types on one page — putting BlogPosting, BreadcrumbList, and, where relevant, FAQPage in separate script blocks, or combining them into one script using @graph — is fine either way, as long as each block's content matches the page's actual content.

What to prioritize for a BtoB site

Not every type needs to be added. For a BtoB site, prioritize the types with clear benefit and low risk of drifting from reality.

The starting point is placement, not a universal bundle on every page: Organization on home/about, WebSite on the homepage, BreadcrumbList on hierarchical pages, and Article markup on articles. For Product and Service, choose the semantic type first and then evaluate Google Product feature eligibility separately. FAQPage remains a Schema.org semantic type, separate from the Google FAQ rich-result feature retired on May 7, 2026.

Implementation checkpoints and how to validate

Here are the failure patterns that come up most often in structured-data reviews. Most trace back to a mismatch with reality or a skipped validation step.

Common checkpoints

• Marking up information not shown on the page — writing a price, rating, or review into structured data alone that isn't displayed in the body text. This is a policy violation and the first point to check.
• Missing required properties — leaving out properties recommended or required for a given type, so it isn't recognized as eligible.
• Syntax errors — broken JSON from mismatched commas, unclosed quotes, or mismatched braces.
• Type/reality mismatch — attaching a type that doesn't fit the page, such as Product on an article page or Article on a service page.
• Inconsistent URLs or dates — an item URL that doesn't exist, or a datePublished that doesn't match the actual publication date.
• Markup on a noindex page — adding structured data to a page that isn't indexed in the first place won't make it eligible for display.
• Missing absolute image paths — writing a logo or image as a relative path that search engines can't resolve.

How to validate

Always check with the following tools before and after publishing.

• Schema Markup Validator — first check whether the graph is valid against Schema.org vocabulary and type semantics, including types without a Google rich-result feature.
• Rich Results Test (Google) — for Search features Google actually supports, check whether Google detects the required markup and whether errors or warnings remain.
• URL Inspection and Search Console — after deployment, inspect what Google fetched from the production URL and monitor the relevant structured-data and performance reports. A validator pass is not production acceptance.

Validation isn't a one-time step. Site changes or template updates can break structured data, so keep checking Search Console periodically after publishing too. Not treating it as 'done once it's added' is the key to keeping structured data healthy.

Netsujo separates three structured-data gates

In our implementation workflow, a validator pass is not the definition of done. We separate three questions: (1) is the markup semantically and syntactically valid Schema.org, (2) is the page eligible for the particular Google Search feature we care about, and (3) does the deployed production URL expose the accepted markup to Google as expected?

FAQPage remains a Schema.org semantic type even though Google FAQ rich results were retired on May 7, 2026. Whether a page emits FAQPage markup is therefore an implementation decision about semantic data, not evidence of a current Google FAQ Search feature.

Official sources checked on September 20, 2026

Google: Organization structured data

Google: site names and WebSite structured data

Google: Search documentation updates (FAQ rich-result retirement)

Schema.org: FAQPage

Schema.org: Product

Schema.org: Service

Google: Product snippets

Google: merchant listings

Google: AI features and your website

Structuring for AI

Questions like 'does adding structured data get us into AI search' come up more often in the context of AI search (AI Overviews, ChatGPT, Perplexity, and similar). This is an area where the premises easily blur, so it's worth spelling them out carefully.

For Google specifically, AI Overviews and AI Mode do not require special Schema.org markup. The normal Search eligibility rules still apply, and structured data should match visible text. Do not generalize Google's documentation into citation rules for ChatGPT, Perplexity, or other AI services.

Structured data is still useful as a machine-readable meaning layer for visible facts such as company name, service, location, contact details, and publication dates. That is different from treating it as an AI-placement tactic. If critical information exists only inside an image or PDF, make the information retrievable as body text first.

What matters for conveying facts to AI is not just the 'format' of structured data but the organization of the body text itself. Writing that helps both machines and people includes:

• Leading with the conclusion (answer-first)
• Covering one point per paragraph
• Including specific numbers, conditions, and sources
• Answering a question-form heading concisely right after it

Structured data's role is to attach the correct label to facts that are already organized this way. Body-text organization (the substance) and structured data (how it's conveyed) work together — adding structured data alone will not substantially change how much gets through to AI.

Priority order for fixing things

Trying to fix everything about your structured data at once tends to balloon the workload. Splitting it into stages by impact and effort works better.

The order matters, but the foundation is not a bundle copied to every page. Put entity and site-level markup where Google recommends it, choose page-level semantic types from visible content, and then test Google feature eligibility separately. Production observation comes after both checks.

Structured-data work pays off more when it's done alongside body-copy improvements (making the substance clearer). Structured data is an improvement in how you convey things; pair it with improving what you're conveying.

Summary

• Structured data makes visible facts machine-readable; it does not guarantee ranking, rich results, or AI citation.
• Schema.org semantic validity and Google Search feature eligibility are separate questions.
• Organization belongs on home/about; WebSite belongs on the domain or subdomain homepage; BreadcrumbList belongs on hierarchical pages that actually show that navigation.
• Schema.org Product can include offered services. Google Product snippets and merchant listings have separate, narrower feature requirements.
• Google FAQ rich results have not been shown since May 7, 2026; FAQPage remains a Schema.org semantic type.
• Validate with Schema Markup Validator, Rich Results Test where applicable, and then the production URL through URL Inspection/Search Console.
• Google AI features do not require special Schema.org markup.

Frequently asked questions

Does adding structured data raise search ranking?

Not necessarily. Structured data helps convey content accurately; it does not directly raise ranking. Ranking is determined by other factors, such as content quality and match with search intent.

Does adding structured data guarantee a rich result will display?

No. Whether a rich result displays is the search engine's own decision, and it may not display even when the structured data is correct. Being recognized as eligible by the Rich Results Test and actually being displayed are two different things.

Should I write JSON-LD or Microdata?

JSON-LD is the common approach today, and Google recommends it. Because it can be written separately from the body HTML, gathered inside the head, it's easier to maintain.

Should I add FAQPage structured data?

Google FAQ rich results stopped appearing on May 7, 2026. Schema.org FAQPage remains defined, so you may keep matching semantic markup when it accurately reflects visible FAQs, but it no longer represents a current Google FAQ rich-result feature.

Can I mark up a price or review that isn't shown on the page?

No. Writing information into structured data that isn't shown on the page is a policy violation, and it works against you in evaluation too. Only mark up information that's actually displayed.

How do I check whether structured data is correct?

Use Schema Markup Validator for Schema.org semantics, Rich Results Test for Google-supported Search features, then inspect the deployed URL with URL Inspection and monitor the relevant Search Console reports.

What structured data should a BtoB site add first?

Do not copy one basic set onto every page. Put Organization on home/about, WebSite on the homepage, BreadcrumbList on hierarchical pages, and Article/BlogPosting on articles. Choose Product or Service from the visible offering, and assess Google Product feature eligibility separately.

Does adding structured data get a page cited by AI?

No. Google says AI Overviews and AI Mode require no special Schema.org markup beyond ordinary Search requirements. Structured data should match visible text. Do not infer the citation rules of other AI services from the Google specification.