Schema markup for GEO — the structured-data playbook for AI search.

Why schema matters more for GEO than for SEO

For two decades, schema markup was a polite suggestion to Google. You marked up your pages with Article, you crossed your fingers for a rich result, and most of the time Google ignored half of what you sent. Schema was a tax-favored expense — cheap, low-risk, marginal upside. The brands that did it well got a few extra stars and breadcrumbs in the SERP. The brands that skipped it kept ranking anyway.

Generative engines have changed the economics. When ChatGPT pulls a candidate document into its synthesis pipeline, it doesn't render the page like a browser. It parses the HTML, looks for application/ld+json blocks, and treats the structured data as a high-confidence source of facts about the page. The same is true for Perplexity, for Gemini's grounded answers, and for the new generation of retrieval-augmented systems that increasingly sit behind enterprise search.

The asymmetry is sharp. In traditional SEO, schema is a tiebreaker. In GEO, schema is the difference between being a citable entity and being an invisible blob of text.

Generative engines retrieve documents, extract facts, then synthesize an answer. The fact-extraction step rewards structure. A page that says "Citovo is an AI visibility platform" in a SoftwareApplication.description field is more extractable than the same sentence buried in the third paragraph of a hero section.

The three reasons schema is more valuable to an LLM than to a search engine

First, LLMs prefer high-confidence claims. A search engine can hedge by showing ten links and letting the user pick. A generative engine has to commit to a synthesized answer, which means it weights sources by how certain it can be about each claim. Structured data is the highest-certainty source on a page — it is explicit, typed, and self-describing.

Second, LLMs work at the entity level, not the page level. Google's index has always been page-centric. LLMs reason about brands, products and people as entities, and they need a clean way to bind a page to an entity. Schema's @id mechanism, when used correctly, is exactly that binding.

Third, LLMs read the parts of a page that browsers don't show. A hidden BreadcrumbList in JSON-LD is invisible to a human, but it tells an LLM the page's place in your information architecture. That context shapes how the page gets cited.

The seven schema types that move AI visibility

Schema.org defines roughly eight hundred types. You don't need eight hundred. You need seven, in the right combination, with the right @id wiring. Here they are in order of importance.

1. Organization — the brand entity

Organization is the spine of your structured data. It is the type that names you, describes you, links you to your social properties and lets every other piece of schema on your site refer back to a single canonical entity. Every page on the site should have access to one Organization block with a stable @id — typically https://yourdomain.com/#org.

A complete Organization includes: name, url, logo, description, sameAs (an array of your authoritative external profiles — LinkedIn, Crunchbase, Wikipedia, X, GitHub, Wikidata), contactPoint, founder if relevant, and knowsAbout for the topics you cover. The sameAs array is doing more work than it looks. It is the primary mechanism by which an engine binds your @id to its existing entity graph — to its knowledge of you as a real-world entity.

Incomplete Organization blocks are the single most common GEO failure we see in audits. A brand will have a logo and a name, no sameAs, no description, no knowsAbout — and then wonder why the AIs talk about a competitor that has a full Wikipedia article and a complete Crunchbase listing.

2. WebSite — the structured site identity

WebSite is the wrapper that tells an engine "this is a site, not just a collection of pages." It's a small piece of markup with outsized leverage. The required fields are minimal — url, name, publisher (referencing your Organization @id), and ideally inLanguage. The optional but valuable field is potentialAction, which can declare a sitelinks search box for Google.

The WebSite block also serves as the parent that every WebPage can link to via isPartOf. That parent-child relationship is how engines understand your site as a coherent property rather than a set of disconnected URLs.

3. SoftwareApplication or Product — what you sell

If you are a SaaS company, the right type is SoftwareApplication. If you sell physical or e-commerce products, it's Product. If you sell services, it's Service. Pick the one that matches reality and use it on your main commercial pages.

For SaaS, the fields that matter for GEO are name, applicationCategory, applicationSubCategory, operatingSystem, featureList, description, publisher (referencing Organization), offers (with at least a basic Offer declaring pricing or "starts free"), and keywords. The featureList field is the one that gets quoted most often when an LLM is asked "what does X do?"

For Product, the must-haves are name, brand, description, image, offers with price and availability, and reviews via aggregateRating. LLMs cite reviews more than humans realize — both for B2C shopping queries and for B2B "is X any good" prompts.

4. Article or BlogPosting — the content entity

Every editorial page on the site — blog posts, guides, news, case studies — should have an Article or BlogPosting block. Article is the parent type; BlogPosting is the more specific child. Use whichever fits the page, and be consistent across the site.

The fields are: headline (verbatim from the H1), description (the page's lead paragraph), image, datePublished, dateModified, author (a Person or Organization), publisher (your Organization @id), mainEntityOfPage (referencing the WebPage), articleSection (your content category) and keywords.

The two fields that punch above their weight in GEO are dateModified and author. Generative engines weight freshness heavily for commercial and "best X" queries — a page with a dateModified of 2026 outperforms a page with a 2022 modified date on the same topic. And LLMs increasingly attribute claims to named authors when they can find them, which means an author field with a real Person behind it is more citable than an anonymous post.

5. FAQPage — the most extracted type

FAQPage is the schema type LLMs love most, because the question-and-answer structure maps directly onto how they synthesize answers. A well-structured FAQPage with eight clean Q&A pairs is one of the highest-leverage things you can add to a page. The mainEntity array contains Question objects, each with an acceptedAnswer of type Answer and a plain-text text body.

The non-negotiable rule: the FAQ in your JSON-LD must match the FAQ visible on the page, verbatim. Google explicitly penalizes mismatched FAQ schema, and LLMs increasingly cross-check before trusting it. If you have ten FAQs on the page, your FAQPage has ten Q&As. If you delete one from the page, you delete it from the schema. Treat the two as one source.

Google reduced FAQ rich results in the SERP in 2023, which led some teams to skip FAQ schema entirely. That was a mistake for anyone serious about GEO. The Google SERP impact is smaller, but the LLM extraction value is significantly larger than it was three years ago.

6. HowTo — for instructional content

HowTo is the schema type for step-by-step instructional pages. It declares a name, a description, a list of step objects (each with a name and text), optional supply and tool arrays, and a totalTime if relevant. Use it on every "how to do X" page on the site.

HowTo is especially valuable because LLM answers to "how do I do X" queries draw heavily from structured step lists. A page with HowTo schema is the rare type that gets quoted nearly verbatim in AI answers — the engine can pull the steps as a list and re-present them.

7. BreadcrumbList — site context

BreadcrumbList is the lightest of the seven. It declares the page's path through the site hierarchy as an ordered ListItem array. It's trivial to generate and it gives engines a clean signal about content categorisation, which feeds into how they associate the page with topical clusters in their entity graph.

Every page on the site that isn't the home page should have a BreadcrumbList. The breadcrumb shown on the page should match the JSON-LD verbatim.

The @graph pattern — one block, one entity model

The naive way to add multiple schema types to a page is to publish multiple JSON-LD blocks — one for Organization, one for WebPage, one for Article, one for FAQPage. This works. It also makes a mess. Each block is an island. Nothing references anything else. Engines have to guess that the Article's publisher is the same Organization declared in the other block.

The @graph pattern fixes this. You publish one JSON-LD block with a @graph array, and the array contains all your schema items as siblings. Items reference each other by @id. The result is one connected entity model per page, expressed in one script tag.

The structure of a graph block on a blog post is the one you're reading right now. The top-level object has @context set to https://schema.org and a @graph array. Inside the array: an Organization with a stable site-wide @id, a WebPage that isPartOf the WebSite, an Article whose publisher references the Organization @id and whose mainEntityOfPage references the WebPage @id, a BreadcrumbList, and a FAQPage.

Five interconnected items. One script. Every engine that reads it gets the same coherent picture: this page is an Article, published by this Organization, on this WebSite, with these FAQs, at this point in this breadcrumb.

The @graph pattern is the closest thing structured data has to a database schema. Use it. The performance and clarity gain over multiple independent blocks is significant, and the cost is the same number of bytes.

Entity coherence: Organization @id reuse across pages

Schema markup is rarely a per-page problem. It's a per-site problem. The single biggest determinant of how engines model your brand is whether the Organization block is identical, with the same @id, across every page on the site.

Pick one canonical @id for your Organization. We use https://citovo.com/#org. Every JSON-LD block on every page should declare that Organization with that exact @id. Every Article, every Product, every WebPage that needs to reference the publisher should do so via "publisher": { "@id": "https://citovo.com/#org" } — by reference, not by re-declaration.

Why does this matter so much? Because an engine that sees five subtly different Organization blocks across your site — one missing a logo, one with a different description, one without sameAs — has to choose which one to trust, or worse, has to maintain a fuzzy union of all of them. The result is a diluted entity. The brand looks like multiple half-similar entities rather than one strong one. Citation rate drops.

The fix is mechanical. Define Organization once, in a build-time include or a templating partial, and import it everywhere. If you don't have a build system, paste the identical block on every page. The marginal cost of paste-by-hand is zero compared to the cost of inconsistency.

The sameAs array is the entity-binding mechanism

Inside the Organization, the sameAs array is the single most important field for binding your @id to an engine's existing knowledge of you. sameAs should list every authoritative external property your brand controls: LinkedIn company page, Crunchbase listing, Wikipedia article if you have one, Wikidata entry, official X account, GitHub organization, YouTube channel, Product Hunt page, AngelList — whatever is relevant.

The richer your sameAs array, the easier it is for an engine to look up your brand in its existing graph and bind your @id to the entity it already knows. Brands with three sameAs entries are routinely confused with similarly named competitors. Brands with twelve are not.

Common schema mistakes that quietly cost citations

From hundreds of GEO audits, the same five mistakes recur. None of them is dramatic. All of them are silently expensive.

Mistake 1: Incomplete Organization

Name, URL, and logo, and nothing else. This is the most common Organization block on the open web. Missing description, missing sameAs, missing contactPoint, missing knowsAbout. The result is a thin entity that engines can't reliably bind to. Fix it once, propagate it everywhere.

Mistake 2: No @id reuse

Organization declared fresh on every page with no stable @id, or with an @id that drifts across pages. Every page's Article block re-declares its publisher inline instead of referencing the canonical Organization. Engines treat each page's Organization as a separate entity. The brand fragments.

Mistake 3: FAQ schema that doesn't match the page

A FAQPage block with twelve questions, but only six visible on the page. Or the schema text uses one wording and the page uses another. Or someone updated the page FAQ and forgot the JSON-LD. Google penalizes this category of mismatch explicitly. LLMs ignore the schema and trust the visible page, which means you got nothing for the effort.

The fix is to treat the visible FAQ and the FAQ schema as one source of truth — ideally generated from the same data. If you can't automate it, audit it quarterly.

Mistake 4: dateModified that lies

Pages with a dateModified of 2024 on content that's clearly been touched in 2026. Or, the reverse: a dateModified updated automatically every day even though the content hasn't changed. Both undermine the freshness signal. Engines are starting to cross-check the claimed dateModified against the actual content delta, and a lie gets caught.

The right behavior: update dateModified when you make a substantive change to the content. Not when you tweak CSS. Not on every deploy. When the words on the page change.

Mistake 5: Generic Article schema on pages that should be more specific

A how-to page that has Article schema but no HowTo. A product page that has Article schema but no Product. A news page that has BlogPosting but no NewsArticle. The more specific type carries more signal. Use it.

How to validate schema

Two validators, used in parallel, cover everything.

Google's Rich Results Test (search.google.com/test/rich-results) tells you what Google detects on the page, which rich-result categories you qualify for, and which fields are missing for richer presentation. It is the practical "will Google use this?" check. Run it on every important page on the site at launch and quarterly thereafter.

The Schema.org Validator (validator.schema.org) is stricter and engine-agnostic. It catches structural errors, malformed JSON, invalid type references, and missing required properties that Google's tool sometimes lets through. It's the "is this technically correct?" check. Use it whenever you make a schema change.

For ongoing monitoring, you need automated coverage. A GEO audit in Citovo runs validation across every URL on the site, flags pages with missing or broken schema, and tracks the trend so you can catch regressions before they cost citations. Schema is one of those things that's correct on launch and slowly degrades as the site ships changes — automated monitoring is how you keep it from drifting.

Beyond Schema.org — llms.txt and AI-crawler access

Schema is necessary but not sufficient. Two newer signals belong in any 2026 GEO stack.

llms.txt — the new robots.txt

llms.txt is a proposed standard, introduced in 2024, for telling large language models how to navigate a site. It lives at /llms.txt, like robots.txt, and it's a plain-text file with a structured outline of your site: a brief description of what the site is, a list of your canonical pages organized by category, and optional descriptions of each.

llms.txt is not formally adopted. It is not required. It is not yet honored by every engine. But it is increasingly read by the major ones, it is cheap to publish, and it lets you give an LLM a clean summary of your site instead of relying on it to crawl the whole property and guess at what matters.

If you have a marketing site with twenty important pages, your llms.txt should list those twenty pages, with one-line descriptions, organized into three or four sections. That's the whole job. Publish it, link it from your homepage if you want, and move on.

AI-crawler access in robots.txt

Open your robots.txt and check whether any of these are blocked: GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended, CCBot. Each of these is the user-agent string for an AI crawler. GPTBot is OpenAI's training crawler. OAI-SearchBot is its retrieval crawler. ClaudeBot is Anthropic. PerplexityBot is Perplexity. Google-Extended is Google's AI training opt-out signal. CCBot is Common Crawl, which feeds many models.

If any of these are blocked, you are voluntarily invisible to that engine. There are legitimate reasons to block — paywalled content, contractual restrictions, specific privacy concerns — but for most marketing content, blocking AI crawlers is leaving citations on the table.

The default in 2026: allow all of them. Audit your robots.txt the same week you finish your schema work. It is the single most common GEO mistake we see in audits — schema done well, AI crawlers quietly blocked, and a brand wondering why its citation rate isn't moving.

Quick-start checklist for a new site

If you're standing up a new property and want the GEO-correct schema stack from day one, here is the minimum viable kit. Eight steps. Most can be done in a half-day.

1. Define one canonical Organization block with @id set to https://yourdomain.com/#org. Include name, URL, logo, description, full sameAs array (LinkedIn, Crunchbase, Wikipedia if applicable, X, GitHub, Wikidata), contactPoint and knowsAbout.
2. Define one WebSite block with @id set to https://yourdomain.com/#website, referencing your Organization as publisher.
3. Add SoftwareApplication or Product on your main commercial pages, with full featureList or offers, and reference the canonical Organization.
4. Add Article or BlogPosting to every content page, with datePublished, dateModified, named author, and publisher referencing Organization.
5. Add FAQPage to every page that has a visible FAQ, with the schema text matching the visible Q&As verbatim.
6. Add BreadcrumbList to every page that isn't the home page.
7. Publish /llms.txt with a short site description and the list of your most important pages.
8. Audit /robots.txt to confirm GPTBot, OAI-SearchBot, ClaudeBot, PerplexityBot, Google-Extended and CCBot are not blocked. Validate every schema block in the Rich Results Test and the Schema.org Validator.

That's the stack. Eight items, one afternoon, materially better AI visibility from week one.

If you'd rather have someone else run the audit, generate the schema and monitor it weekly, Citovo does that across every page on the site, with validation, automatic @id consistency checking and trend tracking. Read more on the GEO methodology, on how we run AI visibility tracking across six engines, or how Citovo compares to point tools like Profound. Demo : call +91 84272 69387 or email tarunsahnan98@gmail.com.