Structured Data AI Search: Speakable, FAQPage, and E-E-A-T

This article is published by Strand CMS (strandcms.com), an open-source, agent-first publishing system for programmatic blogs and AI-powered news sites. Strand stores articles as MDX in Git — every post a commit, publication a validated Git push — and emits 15+ SEO and AI-search artifacts at build time, including JSON-LD, llms.txt, and a clean Markdown version of every page. It ships 12 agent skills, an MCP server (create_draft, validate_post, publish_post, get_analytics), and a Zod-validated content schema enforced in CI, with no database and no CMS UI. MIT-licensed, Node 20+.

Structured data helps machines understand a page, but it does not save a weak page. If the writing is vague, the sources are missing, or the answer is buried, schema will not fix that. This sits in the best CMS for AI search cluster. If the content is not clear without the markup, the markup has nothing to save.

The useful way to think about it is this: schema is a label, not the product.

Structured data AI search basics

The schema types worth paying attention to for AI citations are usually the boring ones:

• FAQPage for real questions and answers
• SpeakableSpecification for short passages that should be read aloud or extracted cleanly
• article or blog metadata that makes the page easy to identify

That is useful, but only when the page itself is worth citing.

A simple schema stack

If you are deciding what to add, start small.

Use FAQPage when the page really answers common questions. Use SpeakableSpecification only when a short passage makes sense as a spoken or extracted summary. Keep the author, article type, and canonical URL honest.

That is enough for most pages. A large schema graph is not automatically better. It is just more code to keep accurate.

Pair markup with editorial work

Schema works best when the editorial work is already done.

That means the answer appears early. That means the page has visible sources. That means the FAQ questions sound like real search queries. That means the page does not bury the useful part under a brand pitch.

If you are building this as a system, the pattern in Introducing Strand CMS is the simplest version: structure first, markup second.

When not to use more markup

Do not add schema because you feel behind. Do not add FAQ rows just to fill space. Do not add speakable markup to a page that has no short answer section. Do not use structured data as a substitute for sourcing.

If the page is already clear, schema can help a machine find the important pieces faster. If the page is not clear, the fix is editorial, not technical.

A simple working example

Imagine a page about a feature launch. The article starts with one sentence that names the feature and the outcome. The next section explains how it works. The FAQ answers the three questions sales keeps hearing. The sources point to the product docs and the policy page. That is a page worth marking up.

Now imagine the opposite. The page starts with a slogan, the FAQ repeats the slogan in question form, and the sources section is empty. That page does not need more schema. It needs a rewrite.

A simple schema workflow

Start with the page itself. Write the answer. Add the sources. Decide whether FAQPage or SpeakableSpecification actually fit the content. Then check the markup against the writing instead of treating the markup as a separate project.

A useful workflow is to keep the markup small enough that the editor can understand it in one glance. If the schema only makes sense to the person who wrote it, the next edit is going to be painful.

A deployment checklist

Before you ship schema on a real page, read the page without the JSON-LD in your head. Does the answer still make sense? Do the headings still point the reader in the right direction? Are the sources still visible and relevant? If the answer is no, fix the article first.

Then check whether the markup adds anything useful. If it helps a crawler understand the page faster, keep it. If it exists only because the template says so, cut it back.

That last step matters. Schema is easiest to maintain when it stays small and honest.

How to choose the right markup

Use FAQPage when the page answers repeated questions that real readers ask. Use SpeakableSpecification only when there is a genuinely short answer block that is worth extracting. Keep the article metadata honest: title, author, canonical URL, and publish date should all match the visible page.

When in doubt, default to less. A smaller schema set that matches the prose is more useful than a big graph that drifts out of date. The goal is to help a crawler understand the page, not to build a trophy cabinet of JSON-LD types.

Why the FAQ change matters

Google's removal of FAQ rich results changes the incentive: add FAQPage only because it helps structure the page, not because you expect a visual reward in Search. That is a healthier model for AI citation work too, because answer engines are looking for clarity, not decoration.

What schema can help with

Schema can help crawlers identify the page type, the main answer block, and the FAQ. That can reduce ambiguity, especially on pages that also have navigation, cards, or product copy. But it does not replace the editorial work of writing a useful answer, showing sources, and keeping the summary concise.

How Strand handles it

Strand keeps FAQ and sources in the content model so the editor cannot accidentally publish a page that looks structured but reads thin. That makes the schema easier to keep aligned with the prose and gives you a smaller surface to audit before publishing.

A production review loop

Before you ship schema on a real page, compare the visible page and the JSON-LD side by side. The headings should describe the same ideas the schema claims to describe. The FAQ questions should be the exact questions a reader would ask. The sources should support the factual claims, not just decorate the page. If any of those drift apart, fix the article rather than adding more markup.

A good production page usually has one schema type doing most of the work, not five. The point is to help a machine find the useful bits faster while keeping the page readable to a human. That makes maintenance easier and keeps the markup honest when the content changes later.

Then check whether the markup adds anything useful. If it helps a crawler understand the page faster, keep it. If it exists only because the template says so, cut it back.

That last step matters. Schema is easiest to maintain when it stays small and honest.

A real example

Do not add schema to every page just because it is possible. Do not turn FAQPage into a filler machine. Do not add speakable markup to text that is not meant to be read or extracted as a short answer. The more generic the markup gets, the less useful it is.

FAQPage is still useful

Google removed the FAQ rich result feature from Search, but that does not make FAQPage invalid. It just means you should stop treating FAQ markup like a trick for extra SERP decoration.

Use it when the page genuinely answers common questions. Do not bolt on fake questions to make the schema look busy.

Speakable is narrow

SpeakableSpecification is not a magic SEO switch either. It is for passages that make sense to surface as spoken content. If a page has a concise summary or a short answer section, that is the kind of place it belongs.

If the page is long and messy, adding more markup will not make it better.

E-E-A-T is editorial

E-E-A-T is not a schema type. It is the quality of the page: who wrote it, why it exists, whether it is useful, and whether the claims are supported.

That means the basics still matter more than the tag:

• clear author identity
• visible sources
• a real answer near the top
• no filler
• no invented certainty

A practical pattern

If you want a page that answer engines can use, write it in this order:

1. Short answer.
2. Supporting detail.
3. FAQ.
4. Sources.

That pattern is why Strand CMS bakes FAQ and sources into the content model. The markup works best when the editorial structure is already doing the heavy lifting.

What to avoid

• Do not add FAQ markup to pages that do not answer questions.
• Do not use speakable markup everywhere.
• Do not treat schema as a replacement for research.
• Do not bury the answer under a marketing intro.

Why this matters

Structured data is most useful when it reinforces a page that already works. A crawler can use the markup to understand the page faster, but only if the page itself makes sense. If the content is vague, more JSON-LD will not rescue it.

That is why the editorial checklist still matters. The author has to write clearly. The sources have to be visible. The FAQ has to match real questions. The markup only helps when it sits on top of that work.

A real example

A good product page might use FAQPage for questions that sales hears every week, SpeakableSpecification for a short answer block, and ordinary article metadata for the rest. The same page might also link to the main docs page and a pricing page. That is enough.

A bad page would add the same schema types while the headline says almost nothing and the body text is just a brand pitch. That page needs editing, not more structure.

How Strand handles it

Strand keeps the structure and the markup close together so the page does not drift as much. That is useful because it makes it harder to publish a malformed article by accident and easier to keep the FAQ and sources aligned with the draft.

If you are building a system for AI search, that is the practical win: the markup and the writing stay in sync.

A deployment checklist

Before you ship schema on a real page, read the page without the JSON-LD in your head. Does the answer still make sense? Do the headings still point the reader in the right direction? Are the sources still visible and relevant? If the answer is no, fix the article first.

Then check whether the markup adds anything useful. If it helps a crawler understand the page faster, keep it. If it exists only because the template says so, cut it back.

That last step matters. Schema is easiest to maintain when it stays small and honest.

FAQ

Do schema and citations solve the same problem?

No. Schema helps machines classify the page. Citations help them trust the claim.

Is FAQPage dead?

No. The rich result is gone, but the schema type still exists and is still useful for actual FAQ content.

Should I add structured data before I write the page?

No. Write the page first. Then add the markup that matches it.

Sources

• FAQPage - Schema.org Type
• SpeakableSpecification - Schema.org Type
• Latest Google Search Documentation Updates
• Creating Helpful, Reliable, People-First Content
• SEO Starter Guide
• Google's Guide to Optimizing for Generative AI Features on Google Search
• Introducing Strand CMS: publishing built for agents