Schema markup for B2B websites: the types that actually matter

Structured data is one of the few technical SEO jobs with a clear right answer. Either you describe the page in a machine-readable format, or you leave search engines and AI assistants to infer it from your HTML. Most B2B sites leave them guessing, then wonder why their company gets described inaccurately in an AI answer.

What is schema markup, and what does it actually do?

Schema markup is a shared vocabulary, maintained at schema.org, for labelling the meaning of content. You add it to a page as JSON-LD, a block of JSON sitting in the head, that says in machine terms: this page is an article, it was published on this date, by this organisation, and it answers these four questions.

What it does not do is add authority. Marking up a thin page as an Article will not make it rank. Schema removes ambiguity, and ambiguity is expensive: it is the reason a crawler cannot tell your pricing page from your blog, or an AI assistant confuses your company with a similarly named one in another country. Treat markup as an eligibility and clarity layer sitting on top of content that already earns its place. If the content underneath is weak, fix that first, and the wider B2B SEO steps matter far more than any JSON block.

Which schema types actually matter for a B2B website?

Schema.org defines hundreds of types. A B2B site needs a handful. Here is what each one earns.

• Organization. Your sitewide identity: legal name, URL, logo, and sameAs links to your LinkedIn and other verified profiles. This is the anchor every other claim hangs off. It is what lets a search engine or a model tie a mention of your brand elsewhere on the web back to you rather than a namesake. Ship it once, in a sitewide template, with identical values on every page.
• BreadcrumbList. Cheap, and visible. It replaces the raw URL in search results with a readable hierarchy, and it tells a crawler how your site is organised without relying on link discovery alone. There is no reason for any page below the homepage to lack it.
• Article. For every resource, guide or blog post. Include headline, description, datePublished, dateModified, author, publisher, image and mainEntityOfPage. It earns date display, feeds freshness signals, and gives an answer engine a clean attribution line when it quotes you.
• FAQPage. The one with the highest return in B2B. Covered in its own section below.
• Service. Underused. It states plainly what you sell, who provides it, and where you provide it, through serviceType, provider and areaServed. It rarely changes anything visible in a search result, which is why most sites skip it, but it is one of the few ways to declare in machine-readable terms that you are a done-for-you B2B outbound provider serving Europe rather than a generic marketing agency.
• Product with Offer. Only if you genuinely sell a product at a stated price. Software vendors with published tiers, yes. Service businesses, no. Using Product to describe a retainer is one of the most common misapplications in B2B and it produces validation warnings rather than results.
• LocalBusiness. Only if customers physically visit you. A registered office in Vilnius is an address, not a storefront, and marking it up as one adds noise.
• Person. Worth adding for named authors and founders, linked to the Organization node. If you publish opinions under a real name, give that name an entity.

That is the whole list. Everything past it is optional refinement, and the effort is nearly always better spent on the content of the pages themselves.

Why is FAQ schema the highest-leverage type for B2B?

Two reasons, and only one of them is about search.

The search reason has weakened. Google narrowed FAQ rich result display in 2023 to a small set of authoritative sites, so most B2B sites no longer see expandable questions under their listing. If your only motivation was the SERP real estate, that bet has mostly stopped paying.

The reason it still matters is extraction. Answer engines are built to pull short, self-contained answers to specific questions. A page carrying explicit Question and acceptedAnswer pairs hands them that structure with no parsing required. That is the mechanic behind most of what works in generative engine optimization: you make yourself the cheapest correct thing to quote.

Two rules keep FAQ schema honest. First, the answer text in your JSON-LD must match the answer visible on the page. Marking up content a human cannot see is a policy violation, and in practice the drift happens by accident, when someone edits the visible copy months later and forgets the JSON. Second, every answer must stand alone. If it only makes sense with the surrounding page for context, it will read as nonsense when a model lifts it out, and that is precisely what a model will do.

How should you implement it?

Use JSON-LD in the head, not microdata scattered through the markup. Microdata couples your structured data to your presentation layer, so a template refactor silently deletes half of it and nobody notices for a year. A single JSON block is reviewable, diffable and portable.

Put related nodes in one @graph array on the page rather than shipping three separate script tags. It keeps the relationships explicit and stops two blocks from contradicting each other.

Generate the values from the same source of truth as the visible content. If your CMS holds the publish date, the JSON should read that field, not a hand-typed copy of it. Every value typed twice will eventually disagree with itself.

And be consistent sitewide. The same organisation name, the same URL, the same logo, the same sameAs list, on every page. Entity resolution works on repetition. Three spellings of your company name across a site is how you end up as three fuzzy half-entities instead of one solid one.

The mistakes that make schema useless

• Marking up content that is not on the page. The rule is simple and it is enforced: structured data must describe visible content. Invisible FAQ answers are the usual offender.
• Drift after an edit. Copy changes, JSON does not. Add a review step, or generate the JSON from the copy.
• Bumping dateModified without modifying anything. A freshness trick that fools nobody, and it destroys your ability to tell which pages genuinely changed.
• Product schema on a service business. Wrong type, wrong properties, no benefit.
• Two conflicting blocks. A plugin emits Organization, a developer hand-added another with a different logo URL. Now the page contradicts itself. Audit for duplicates before adding anything new.
• Self-serving AggregateRating. Review markup for ratings you collected and displayed yourself, or worse, invented, is the fastest route to a manual action. If you did not earn the reviews on a page a visitor can read, do not mark them up.
• Copy-paste leftovers. A new page cloned from an old one, still pointing mainEntityOfPage at the old URL. Check the canonical and the mainEntityOfPage agree on every page.
• Article on everything. Your pricing page is not an article. Type it honestly or leave it typed only as part of the Organization graph.

Does schema markup improve AI search visibility?

Honest answer: there is no published evidence that ChatGPT, Perplexity or Google's AI answers apply a bonus for JSON-LD. Anyone selling you a schema package on the promise of AI rankings is guessing.

What markup does is make you cheap to quote correctly. It pins down the facts a model would otherwise infer: who publishes this, when was it written, what is the company called, what does it sell, where does it operate. When those facts are stated unambiguously and repeated consistently across a site, answers that mention you tend to describe you accurately. When they are not, you get the version assembled from whatever a crawler could piece together, which is where wrong founder names and wrong countries come from. That accuracy problem is the practical reason to bother, and it is closely tied to getting cited in the first place.

A rollout order that gets it done

Most sites stall because they try to do everything at once. Ship it in this order and each step is a contained piece of work.

• 1. Organization, sitewide. One template change, applies everywhere. Get the name, URL, logo and profile links exactly right, because everything downstream references them.
• 2. BreadcrumbList on every page below the homepage. Usually generated from the existing route structure.
• 3. Article across the resource library, generated from CMS fields.
• 4. FAQPage on pages that genuinely answer questions, with the answers visible and self-contained.
• 5. Service on the pages that describe what you sell, including areaServed.
• 6. Product only if there is a literal product at a literal price.

How do you test what you shipped?

Validate twice, with different tools. Google's Rich Results Test tells you what Google can use; the Schema Markup Validator at validator.schema.org tells you whether the markup is actually valid schema, which is a different question. A block can be technically valid and still ineligible for any rich result.

Then watch Search Console's enhancement reports over the following weeks. They surface errors at scale, across pages you would never have spot-checked, and they catch the regression that arrives three months later when someone changes a template.

Finally, re-run the check after every template or CMS change. Structured data breaks silently. Nothing on the page looks wrong, no test fails, and the markup has simply been gone since the last deploy.

Schema is plumbing, so keep it in proportion

Do this work, because it is cheap, it is finite, and it stops machines from misdescribing your company. But keep it in proportion. Schema makes you easier to find and easier to quote when someone is already looking for what you do. It does not create demand in a market that has not started searching, which is what outbound is for, and the two work best in the same quarter rather than as alternatives. If you would rather have the conversations while the content compounds, our pricing is public.