Structured Data for B2B Sites: A Practical Guide

Search engines read your pages as text, and they work out a lot from that text alone. Structured data gives them explicit, machine-readable facts as well: this page is an article, this is its author, this is when it was published and updated, this is the organisation behind it. Google uses structured data to understand content and, for some types, to make pages eligible for richer displays in search results. It is best treated as a way to describe content accurately rather than as a ranking tactic, and some rich result types come and go, but accurate structured data is part of a well-built site. This guide explains how structured data works, which types suit a B2B site, how to implement and test it and the rules that keep it from causing problems.

What structured data is

Google's introduction describes structured data as a standardised format for providing information about a page and classifying its content, and notes that most Search structured data uses the schema.org vocabulary while Google's own documentation defines which properties matter for its features (Google Search Central: Introduction to structured data).

Google supports three formats: JSON-LD, Microdata and RDFa. Its guidance is to use the format that is easiest to implement and maintain, which in most cases is JSON-LD, and it says all three are equally fine as long as the markup is valid.

What structured data can and cannot do

Structured data can make a page eligible for features such as rich results and helps search engines understand entities on the page. It does not guarantee those features. Google's structured data policies state plainly that it does not guarantee your structured data will show up in search results, even if the page is marked up correctly according to the Rich Results Test (Google Search Central: Structured data policies).

Features also change. Google's Search Central updates log records that documentation for the FAQ rich result was removed because that feature is no longer shown in Google Search results (Google Search Central: Latest updates). Plan structured data around accurately describing your content, not around a particular display that may not last.

Types that suit a B2B site

For a company site with services and a blog, a few types cover most needs:

• Article, for blog posts and guides, describing headline, author, images and dates.
• Organization, describing the company, its logo and its official profiles.
• BreadcrumbList, describing where a page sits in the site structure.
• Product or Service-related markup only where Google documents a feature for it and the content genuinely matches.

Google's Article documentation notes there are no required properties for Article markup; instead, you add the recommended properties that apply to your content. Its example includes headline, images, datePublished, dateModified and author details (Google Search Central: Article structured data).

Keep markup consistent with the page

The most important rule is that structured data must describe what users can see. Google's introduction says not to add structured data about information that is not visible to the user, even if the information is accurate, and not to create blank or empty pages just to hold structured data.

In practice, that means the author in the markup is the author shown on the page, the dates match the visible published and updated dates and the headline matches the visible title. Mismatches are a common source of warnings and lost eligibility.

Generate it from your content system

Hand-written structured data drifts out of date. The reliable approach is to generate it from the same fields that render the page: title, author, publish date, update date and featured image. When an editor updates a post, the markup updates with it. Our guide to headless CMS architecture explains how to structure content fields so that pages, feeds and markup all draw from the same source.

Worked example: Article markup fields mapped to a CMS

The table below is a hypothetical mapping for a company blog. It shows where each Article property comes from, so that markup always matches the visible page.

Article propertySource field in the CMSVisible on the page?NotesheadlinePost titleYes, as the H1Keep identical to the visible titleauthor nameAuthor profile nameYes, in the bylineLink to an author page if one existsdatePublishedOriginal publish dateYesDo not change when editingdateModifiedLast significant updateYes, as updated dateUpdate only for real content changesimageFeatured imageYesUse an image that appears on the pagepublisherOrganization settingsYes, logo in headerDefined once, reused on every post

A mapping like this also makes it easy to spot gaps, such as posts without a visible updated date.

Test before and after release

Google's introduction recommends the Rich Results Test as a tool for validating structured data and, in some cases, previewing a feature (Rich Results Test). Test a sample of each page template, not just one page. After release, watch the relevant enhancement reports in Search Console for errors and warnings, and recheck after any template change.

Avoid problems with policies

Google's policies explain that a structured data issue can lead to a manual action, which removes a page's eligibility for rich results without affecting how it ranks in web search. Avoid marking up content that is hidden, misleading or irrelevant to the page, and avoid reviews or ratings that are not genuine. If a manual action appears, the Manual Actions report in Search Console explains it.

Keep an inventory of markup

Over time, plugins, themes and custom code can each add their own structured data, sometimes describing the same page twice with conflicting details. List which templates output which types, and from which component. When you change themes or add a plugin, check the output again with the Rich Results Test and remove duplicates. One clear, consistent block per page is easier to maintain than several overlapping ones.

Fit it into your technical SEO work

Structured data works alongside, not instead of, the basics: crawlable pages, correct canonicals, sensible internal links and fast loading. Our technical SEO checklist covers those foundations. Treat structured data as a final layer that describes a site that is already in good order.

Frequently Asked Questions

What is structured data?

It is machine-readable information added to a page, usually in JSON-LD using the schema.org vocabulary, that describes the page's content, such as an article's author and dates.

Does structured data improve rankings?

Google's documentation describes it as helping Google understand pages and making them eligible for rich results, and says it does not guarantee those results appear. Treat it as description, not a ranking tactic.

Which structured data format should I use?

Google supports JSON-LD, Microdata and RDFa, and recommends the one that is easiest to implement and maintain, which in most cases is JSON-LD.

Should blog FAQs use FAQ markup?

Google's updates log says the FAQ rich result is no longer shown in Google Search. Keep FAQ content for readers, and focus markup on types such as Article.

Describe your content accurately

We add structured data to site templates, generate it from your content system and test it so that it stays accurate. See our technical SEO and content publishing service, or talk to us about structured data.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.