Schema markup (JSON-LD structured data) tells search engines and AI systems precisely what your content is and who stands behind it. For AI visibility the essentials are: one consolidated @graph per page, Organisation and named-Person nodes, FAQPage where real FAQs exist, and Article with real dates — never markup for content that is not visibly on the page.
Why does schema matter more in the AI era?
Classic search used schema mostly for rich results — stars, FAQs, breadcrumbs in the SERP. AI engines use it differently: as ground truth for attribution. When a model assembles an answer, schema tells it which organisation published this, which person wrote it, and what the page's key entities are. Content without schema can still be cited, but content with clean schema is cheaper to verify — and engines, like people, take the cheaper path.
What does correct implementation look like?
- One @graph per page — a single JSON-LD block containing every entity, linked by stable @ids. Scattered plugin-generated blocks contradict each other and dilute the signal.
- Named Person for authorship — a real human with sameAs links, not your brand name stuffed into an author field.
- FAQPage only for visible FAQs — the questions and answers must appear on the page; invisible FAQ markup is a policy violation and a trust risk.
- Real dates — datePublished and dateModified that change only when the content actually changes.
- Validation in the build — schema checked mechanically on every deploy, not once during setup and never again.
Which schema mistakes actively hurt you?
Three patterns draw penalties or distrust. First, aggregate ratings you did not collect — marking up supplier or third-party scores as if they were your reviews is a manual-action risk. Second, markup that does not match the visible page — schema describing a different product, price or author than what a reader sees. Third, schema spam — marking up every block on the page because a plugin can, which tells engines you optimise for the markup, not the reader.
How do you prove your schema works?
Test the rendered page, not the code. View source on the live URL and confirm there is exactly one JSON-LD block, that it parses, that every @id reference resolves inside it, and that nothing in it contradicts the visible content. Then re-check after every deploy — schema decays silently when templates change, and the first symptom is usually a dropped rich result or a missing citation weeks later.
Do you need schema on every page?
You need the right schema on every page, which is mostly the same foundation — Organisation, WebSite, the page node with real dates — plus page-type extras where genuine: Article on posts, FAQPage where visible FAQs exist, Service on service pages. A page with only the foundation is fine. A page with invented extras is not. When in doubt, mark up less.
Schema validated in the build, not by annual audit.