Schema markup that earns AI citations (with examples)

Schema markup will not rank you, but it makes your page easier for an AI answer engine to parse, and easier to trust, which is what gets you cited. The trick is that some markup helps and some quietly backfires. Here is what actually earns citations, with examples, and the mistake I recently fixed on this very site.

What schema does for AI answers

An AI answer engine has to work out what your page is about and whether to trust it before it will quote you. Clean, valid structured data hands it that on a plate: what the entity is, who wrote it, when, and how it relates to other things. It is not a ranking lever, and it is not a shortcut past good content. It is the machine-readable layer that removes ambiguity, so an engine spends less effort guessing and is more confident lifting your page into an answer. That confidence is exactly what the getting cited in AI answers work depends on.

The schema types that earn their keep

For a personal brand or a small site, a short list does most of the work:

• Person and Organization. Who you are, what you know (knowsAbout), your credentials (hasCredential), and crucially sameAs links to your other profiles. This is entity linking, and it is one of the strongest trust signals available.
• Article / BlogPosting. Author, publish and modified dates, and the topic. Dates matter: engines favour content that is clearly current — AirOps' 2026 State of AI Search found pages not refreshed at least quarterly are roughly 3x more likely to lose their AI citations — so a visible dateModified on a genuinely updated post is a cheap recency signal.
• FAQPage. Google rarely shows FAQ rich results now, but LLMs still parse the question-and-answer pairs heavily, so keep it where the Q&A is genuinely on the page.
• BreadcrumbList. Cheap structure that helps engines place the page within your site's hierarchy.
• SoftwareApplication / CreativeWork. For tools and case studies, so each one is a distinct, citable entity an engine can name when asked "tools built by an individual".

An example: the Person node

A useful Person node gives an engine concrete fields to resolve, not just a name. On this site the node carries a @type of Person, a name, a canonical url, a jobTitle, a knowsAbout list (Technical SEO, Generative Engine Optimization, Answer Engine Optimization), and a sameAs array linking the LinkedIn and GitHub profiles. Each field does a job: knowsAbout tells the engine what this person is an authority on, and sameAs tells it that all those profiles are the same entity.

The value is not the syntax, it is the sameAs links. A sameAs claim is strongest when the profile it points to points back, and the name, headshot, and one-line bio match across all of them. Consistent, reciprocal profiles are how you get Google and LLMs to treat every "Surya L" reference as one entity, which is the groundwork for a knowledge panel.

The rule that governs all of it: mark up what is real

Every type above shares one rule: the markup must describe what is actually on the page. Schema for content a user cannot see (a FAQPage whose questions are not rendered, Review text that is hidden) is a guidelines violation, not a clever hack. Keep the JSON valid too, because one trailing comma silently kills the whole block, and use absolute URLs for every url, image, and item. Validate with the Rich Results Test and Schema.org's validator before you ship.

The markup that backfires (a real example)

Recently, Search Console flagged two invalid items on this site: "multiple reviews without aggregateRating object". I had mapped two genuine testimonials into Review objects on a ProfessionalService node, with no aggregateRating, which makes the items invalid. The tempting fix is to add a five-star aggregateRating and move on. That is the wrong move twice over. First, inventing a rating that no user gave is fabricated structured data, against Google's guidelines. Second, it would not even help: Google reaffirmed in December 2025 that self-serving reviews, where the entity controls the reviews about itself, are ineligible for the star rich result on Organization and LocalBusiness types anyway. So the markup was pure downside, an error with no possible upside. I removed the Review block; the testimonials still render on the page as social proof, they just no longer emit invalid schema. The lesson: never fake a rating, and do not mark up reviews of yourself. (Product reviews on your own product pages are the one case Google does allow.)

Where schema fits in the bigger picture

It is worth being honest about the ceiling. Schema is a supporting act, not the headline. It will not rescue thin content, and it will not manufacture the off-site mentions that actually drive most AI citations. What it does is remove friction: a page that is already good, already answer-first, and already cited elsewhere gets parsed and trusted faster when its structure is machine-readable. Treat it as the last 10% that compounds the other 90%, not as the lever itself. If your structured data is perfect but your page buries its answer, fix the page first.

A quick pre-ship checklist

1. Does the markup describe content a user can see on the page?
2. Is the JSON valid, with absolute URLs throughout?
3. Any multiple Review objects without an aggregateRating? Any self-serving review stars? Remove them.
4. Does the Person or Organization node have sameAs links to real, matching, reciprocal profiles?
5. Did it pass the Rich Results Test and the Schema.org validator?

Get those five right and your schema is helping, not risking. For the layer that surfaces pages to AI crawlers in the first place, see llms.txt and AI crawler control, and for how the pieces fit together, GEO vs AEO vs SEO.

Want your structured data audited for AI visibility? See how I run a GEO audit.

Further reading

• AI Overviews and GEO
• Google: intro to structured data
• Google: Review snippet structured data