Schema Markup in the AI Era: The 7 Types That Move the Needle

Schema markup used to be one of those nice-to-have SEO tasks that a developer might get to eventually. In 2026, it is foundational. If your site doesn't have clean structured data, AI systems have no reliable way to identify you, your authors, your content, or your location. I am Jake McCluskey, and over the last two years I have watched schema shift from a marginal ranking signal to the single biggest lever for AI citations. This paper walks through the seven schema types I consider non-negotiable in 2026, with short JSON-LD examples for each and a note on what actually matters in each one.
Why does schema matter more now than it did in 2023?
Schema matters more now because AI systems use structured data as their primary way to identify entities, attribute content, and verify trust. In traditional SEO, schema was a small ranking tiebreaker. In GEO, it is closer to the entry ticket.
The reason is simple. Large language models are probabilistic. When they read your page, they are making guesses about who wrote it, what business it represents, and what question it answers. Schema removes the guessing. It gives the model a declared answer in a machine-readable format.
Without schema, the model defaults to safer choices. It cites pages where the identity and intent are explicit. With schema, you become one of those safer choices. That is the shift that has moved schema from optional to foundational.
What is Organization schema and what fields matter?
Organization schema identifies your business as an entity, with its name, logo, contact info, and links to other web properties that represent the same business. It is the first schema you should ship and it should live in a shared layout so every page on your site inherits it.
The fields that actually matter are name, url, logo, description, sameAs, and (for most businesses) contactPoint. The sameAs property is where most sites fall down. This is an array of URLs pointing to your LinkedIn company page, Google Business Profile, Wikidata entry if you have one, Crunchbase, and industry directories. Those URLs are how AI systems confirm you are a real entity with external corroboration.
Here is a short example of what Organization schema looks like in JSON-LD:
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://example.com/#organization",
"name": "Example Consulting",
"url": "https://example.com",
"logo": "https://example.com/logo.png",
"description": "Independent AI and marketing consultancy based in Denver.",
"sameAs": [
"https://www.linkedin.com/company/example-consulting",
"https://g.page/example-consulting",
"https://www.wikidata.org/wiki/Q00000"
]
}
Ship it once in a shared layout. Do not duplicate it per page with different values. Consistency is the point.
What is Person schema and why does every author need it?
Person schema identifies the human behind your content, with their name, job title, expertise, and external profiles. Every author on your site should have a Person entity, and every article should reference that Person as its author.
The fields that matter are name, url, jobTitle, image, description, and sameAs. The sameAs array for a Person points to their LinkedIn profile, Wikidata entry if they have one, personal site, and any recognized industry profiles. This is what establishes that your author is a real expert and not a generic byline.
A short Person schema example:
{
"@context": "https://schema.org",
"@type": "Person",
"@id": "https://example.com/authors/jane-doe#person",
"name": "Jane Doe",
"url": "https://example.com/authors/jane-doe",
"jobTitle": "Principal Consultant",
"description": "20 years of B2B marketing leadership, former VP Marketing at Example Corp.",
"sameAs": [
"https://www.linkedin.com/in/janedoe",
"https://www.wikidata.org/wiki/Q11111"
]
}
When your Article schema references this Person as author (by @id), you have built a clean identity chain. The model can follow it from article to author to external verification in one pass.
What is WebSite schema and when should you use it?
WebSite schema identifies your entire site as an entity, separate from the Organization that runs it, and optionally declares a site search action that search engines can use. It is small, but it is part of the standard schema stack for a GEO-ready site.
The fields that matter are name, url, publisher (which references your Organization by @id), and potentialAction for the site search. The publisher link is the important one because it formally ties the site to your Organization entity.
Example:
{
"@context": "https://schema.org",
"@type": "WebSite",
"@id": "https://example.com/#website",
"url": "https://example.com",
"name": "Example Consulting",
"publisher": { "@id": "https://example.com/#organization" }
}
Ship it once in your layout, same as Organization. That is all it needs to do.
What is Article or BlogPosting schema and how do you fill it in right?
Article (or BlogPosting, which is a subtype) schema declares that a given page is a piece of content with a headline, author, publication date, and publisher. Every blog post, white paper, and long-form content page should have it. Without it, AI systems often cannot confidently attribute the content.
The fields that matter are headline, description, author (referenced by @id), publisher (referenced by @id), datePublished, dateModified, image, and mainEntityOfPage. The author and publisher references are how you connect this content to the Person and Organization entities you already declared.
Example:
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"headline": "Schema Markup in the AI Era",
"description": "The seven schema types that matter most for AI citations in 2026.",
"author": { "@id": "https://example.com/authors/jane-doe#person" },
"publisher": { "@id": "https://example.com/#organization" },
"datePublished": "2026-04-23",
"dateModified": "2026-04-23",
"image": "https://example.com/articles/schema-ai/cover.jpg",
"mainEntityOfPage": "https://example.com/articles/schema-ai"
}
A few honest notes. Keep dateModified accurate. AI systems use recency as a trust signal, and stale dateModified values on important pages hurt you. And do not fake authorship. If a real human didn't write the piece, don't invent a Person.
What is FAQPage schema and why is it so effective?
FAQPage schema declares that a page contains a list of questions and answers, and it structures each pair so an AI system can retrieve it cleanly. It is one of the highest-leverage schema types for AI citations because the structure mirrors exactly how models retrieve Q&A content.
The fields that matter are mainEntity (an array of Question entities), each with a name (the question) and an acceptedAnswer containing a text field (the answer). Keep answers concise, two to three sentences, with the direct answer up front.
Example with one Q&A pair:
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "How long does GEO take to show results?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Most sites see AI citations within 30 to 90 days of shipping schema and answer-first content, assuming existing topical authority."
}
}
]
}
FAQ schema is the single cheapest win in this list. Adding FAQPage schema to a page that already has a real FAQ block often produces citations within eight weeks with no content change.
What is BreadcrumbList schema and does it actually help AI retrieval?
BreadcrumbList schema declares the hierarchical path from your site root to the current page (Home > Articles > GEO Playbook, for example). It helps AI systems understand how this page fits into your site structure, which can improve both context and trust.
The fields that matter are itemListElement, an ordered array of ListItem entries, each with a position, name, and item (the URL). Every content page should include BreadcrumbList schema that matches its real navigational path.
Example:
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com" },
{ "@type": "ListItem", "position": 2, "name": "Articles", "item": "https://example.com/articles" },
{ "@type": "ListItem", "position": 3, "name": "Schema Markup in the AI Era", "item": "https://example.com/articles/schema-ai" }
]
}
By itself it won't move citations dramatically. Paired with the other six, it tightens your overall structure and makes your site feel cleanly organized to crawlers.
What is LocalBusiness schema and when is it non-negotiable?
LocalBusiness schema is non-negotiable for any business with a physical location or a local service area. It declares your name, address, phone number, hours, geo coordinates, and service areas in a format AI systems use to answer local queries.
The fields that matter are name, address (with full PostalAddress), telephone, openingHours, geo, priceRange, and areaServed. Match these values exactly to your Google Business Profile. Inconsistency between your site schema and your GBP is a common reason local businesses get skipped in AI answers for their own city.
Example:
{
"@context": "https://schema.org",
"@type": "LocalBusiness",
"name": "Example Consulting",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main St",
"addressLocality": "Denver",
"addressRegion": "CO",
"postalCode": "80202",
"addressCountry": "US"
},
"telephone": "+1-303-555-0123",
"openingHours": "Mo-Fr 09:00-17:00",
"priceRange": "$$"
}
If you are a local business and you have not shipped LocalBusiness schema with matching NAP data, that is almost certainly your single highest-leverage fix. It is worth pausing everything else to get this right.
How do the seven schema types connect to each other?
The seven schema types connect through @id references, creating a clean graph of identity, content, and place. Organization and Person are the identity anchors. WebSite points to the Organization as publisher. Article references both Person (as author) and Organization (as publisher). FAQPage and BreadcrumbList live on the page itself. LocalBusiness is a specialized extension of Organization for businesses with a physical presence.
The reason this matters is that AI systems can follow those references to build a complete picture in one pass. When they see an Article, they can trace it to a named Person, verify that Person through sameAs links, trace the publisher to a real Organization, and cross-check the Organization against external profiles. That chain of verification is what produces a confident citation.
If your schema types are correct individually but not referenced to each other, you have given the model isolated facts instead of a graph. That works less well than a properly connected schema stack.
What schema mistakes cost sites the most?
The biggest schema mistakes are missing required fields, duplicate or conflicting schema on the same page, and schema that contradicts the visible content. Each of these can cause AI systems to discard your structured data entirely, which often puts you in a worse position than having no schema at all.
Missing required fields usually show up in Organization schema, where name and url are mandatory, and in Article schema, where headline, author, and publisher are expected. Ship these once, test with a validator, and you avoid the whole category of problem.
Duplicate schema happens when a site has Organization schema in the layout and a different Organization schema injected by a plugin. The two disagree on the logo, description, or sameAs fields, and the model either picks one or discards both. Audit any site with multiple content management plugins for this.
Schema that contradicts visible content is the trust-killer. If your FAQPage schema says one thing and the actual visible FAQ block says something different, the model notices. Once it catches that kind of mismatch, it tends to downgrade the whole site's trust signal. Keep your schema honest.
Shipping all seven types, cleanly and with correct references between them, is about two to three days of focused developer work on most sites. Not a quarter. Not a rebuild. Two to three days. If you want to see how I build the full stack for clients, that is part of what I cover in my services, and a free audit will tell you which of the seven you are missing today. If you want a straight read on whether your current setup is the issue, a short discovery call usually gets us to a yes or no in 20 minutes.