What does schema markup do for AI search?
Schema markup gives engines a machine-readable declaration of what a page is: its type, its author and publisher, the organization behind it, the questions it answers, and where it sits in the site. Engines that reason about entities use it to confirm what they infer from the text, which supports entity clarity and, through it, citation.
It is not a ranking trick, and no schema type guarantees inclusion in an AI answer. It is a way of being unambiguous, which is the same goal as the rest of AI-search discipline.
Which types matter for a B2B site?
Organization schema on the root declares who you are, with name, logo, URL, and contact points, and is the anchor for every other declaration. Article or BlogPosting schema on content pages declares headline, description, author, publisher, dates published and modified, and the main image, which is how an engine knows who wrote what and when.
FAQPage schema declares question-answer pairs, but only where a visible FAQ block exists on the page. BreadcrumbList declares the page's position in the site. Product or Service schema declares what you sell, and ItemList can declare a catalogue such as a set of Digital FTE roles. Speakable can mark passages suitable for voice.
- Organization: who you are, on the root layout
- Article or BlogPosting: every content page, with author, publisher, dates
- FAQPage: only where the FAQ is visible on the page
- BreadcrumbList: page position in the site
- Product, Service, ItemList: what you sell and the catalogue
- VideoObject: only where a real video is embedded
Why must it be server-rendered?
It must be server-rendered because many AI crawlers fetch the initial HTML and execute no JavaScript. Schema injected by a client-side effect after page load is invisible to them, and the page appears to have none. The declaration has to be in the HTML the server sends.
On ftes.ai every page's JSON-LD is rendered inline in the server component as a script tag of type application/ld+json, never from a client effect. This is a non-negotiable in the site's build standard, because a schema block that a crawler cannot see is a schema block that does not exist.
What is the one rule?
The one rule is that schema describes only what is visibly on the page. FAQPage schema on a page with no visible FAQ, VideoObject on a page with no video, review markup for reviews that are not shown, or an author who did not write the piece: each is a mismatch between declaration and content, violates engine guidelines, and risks the page's ordinary ranking as well as its citation.
The rule protects trust. An engine that finds a page's schema honest learns to rely on it; one that finds it inflated learns the opposite, and that lesson applies to the whole domain.
How should you maintain it?
Maintain schema by generating it from the same data that renders the page, so that the two cannot drift. On ftes.ai the blog data model produces the BlogPosting, FAQPage, and BreadcrumbList blocks from the same fields that render the article, so a post with no FAQs gets no FAQPage block automatically.
Validate with the engines' own testing tools after any change, and check the dates: a dateModified that never updates tells an engine the content is stale. The AI search visibility audit guide includes schema as one of its checks.
What does the schema on a single ftes.ai library page contain?
As a labelled example, a single library page on ftes.ai carries four server-rendered JSON-LD blocks in its initial HTML. A BlogPosting with the headline, description, image, published and modified dates as ISO strings, article section, keywords, word count, author and publisher as organizations, the canonical page as its main entity, and a speakable specification pointing at the visible short-answer box and the section headings. A BreadcrumbList placing the page under Insights and Home. A FAQPage mirroring the visible FAQ block verbatim, present only because the block is visible. And, inherited from the root layout, the Organization and WebSite declarations.
What it does not carry is a Blog or ItemList of every post; those live on the index page only, so a detail page describes itself and the collection describes the collection. Every block is generated from the same data that renders the page, so a post with no FAQs gets no FAQPage automatically and a modified date changes when the content does. The same pattern, described here as one page, is what the audit guide checks across the site.