.svg)
FAQ schema is not what you think it is
Most Webflow developers associate FAQ schema with the /faq page. A dedicated page with accordion dropdowns, marked up with FAQPage structured data. That is the obvious implementation. But it is also the limiting one.
FAQPage schema has nothing to do with a specific URL pattern. It has everything to do with content format. If a page contains questions and corresponding answers written by the site owner, that page qualifies for FAQPage markup. Your homepage. Your pricing page. Your product pages. Your landing pages. Any page with visible Q&A content.
The schema type is called FAQPage, but a more accurate name would be "page that contains FAQ content." Google's own documentation says: "A FAQ page has a list of questions and answers pertaining to a particular topic." It does not say the page must be located at /faq or that the entire page must be devoted to FAQs.
Why this matters now more than ever
In August 2023, Google significantly reduced FAQ rich results. The dropdown accordions that used to appear in search results are now reserved for well-known government and health websites. For most businesses, FAQ schema no longer triggers visible rich results in Google.
This led many teams to abandon FAQ schema entirely. That was a mistake.
The value of FAQ schema has shifted. It is no longer primarily about Google rich results. It is about AI answer engines. ChatGPT, Perplexity, Gemini, and Google's AI Overviews all use retrieval-augmented generation to find and cite sources. These systems parse structured data to identify clean question-answer pairs they can directly use in their responses.
A well-structured FAQPage schema on your homepage gives AI engines five to ten pre-formatted question-answer pairs about your product. That is five to ten opportunities to be cited when someone asks a related question to an AI assistant.
The JSON-LD structure
FAQPage schema is one of the simpler schema types to implement. The structure is a single FAQPage entity containing an array of Question entities, each with an acceptedAnswer.
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "How does your product work?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Our product works by analyzing your website structure and automatically generating optimized structured data markup."
}
},
{
"@type": "Question",
"name": "What platforms do you support?",
"acceptedAnswer": {
"@type": "Answer",
"text": "We currently support Webflow with plans to expand to WordPress and Shopify."
}
}
]
}Each Question has a name (the question text) and an acceptedAnswer containing the answer text. The answer text can include HTML formatting like links, lists, and bold text, though plain text is safer for compatibility.
Where to add FAQ schema beyond the FAQ page
Think about every page on your Webflow site that has a Q&A section. Most B2B SaaS sites have FAQ sections scattered across multiple pages, but only mark up the dedicated /faq page. Here is where you are likely missing opportunities.
Homepage
Most SaaS homepages end with an FAQ section. Questions like "How does pricing work?", "Do you offer a free trial?", "What integrations do you support?" These are high-intent questions that AI engines frequently encounter. Adding FAQPage schema to your homepage connects these answers to your brand entity, especially when combined with @id referencing to your Organization.
Pricing page
Pricing pages almost always have billing FAQs. "Can I cancel anytime?", "Do you offer annual discounts?", "What payment methods do you accept?" These are transactional questions. When someone asks an AI assistant about your pricing, you want your structured answers to be the source it cites.
Product and feature pages
Individual product pages often address common objections in Q&A format. "How is this different from [competitor]?", "What technical requirements are needed?", "How long does implementation take?" These are comparison and evaluation questions that appear frequently in AI search.
Landing pages
Campaign landing pages targeting specific use cases often include tailored FAQ sections. "Is this solution right for healthcare companies?", "Does it comply with SOC 2?", "Can it handle enterprise scale?" These niche questions are exactly what AI engines use to match specific queries to specific sources.
Implementation in Webflow
There are three ways to implement FAQ schema across multiple Webflow pages, depending on whether the page is static or CMS-driven.
Static pages (homepage, pricing)
For static pages, add the JSON-LD directly in the page's custom code settings. Go to Pages, select the page, open Settings, scroll to Custom Code, and paste the script in the "Inside <head> tag" section.
The limitation is that changes require manual updates. If you update an FAQ answer on the page, you must also update the schema code. This is where most implementations drift out of sync.
CMS Collection pages
For CMS-driven pages like blog posts or documentation, you can use Webflow's CMS fields to dynamically populate the schema. For a detailed walkthrough of this approach, see our guide on mastering schema and CMS structure in Webflow. Create dedicated FAQ fields in your Collection (as we do in this AEO collection with FAQ 1 through FAQ 5 and their corresponding answer fields), then reference those fields in the JSON-LD template.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "{{FAQ 1}}",
"acceptedAnswer": {
"@type": "Answer",
"text": "{{FAQ 1 Answer}}"
}
}
]
}
</script>This approach scales. Every new CMS item automatically gets FAQ schema if the FAQ fields are populated.
Automating with Schema HQ
Karpi Schema HQ handles FAQ schema generation as part of its page-level schema management. Define your FAQs in the app, and it injects the correct FAQPage markup on any page, whether static or CMS-driven, without touching custom code. It also ensures the FAQ schema is properly connected to your Organization and Article entities through @id referencing.
Combining FAQPage with other schema types
FAQ schema does not replace other schema types on the page. It sits alongside them. A homepage can have Organization schema, WebSite schema, and FAQPage schema all in one @graph block. A blog post can have Article schema and FAQPage schema together.
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://yoursite.com/#organization",
"name": "Your Company"
},
{
"@type": "WebPage",
"@id": "https://yoursite.com/#webpage",
"about": { "@id": "https://yoursite.com/#organization" }
},
{
"@type": "FAQPage",
"@id": "https://yoursite.com/#faq",
"mainEntity": [
{
"@type": "Question",
"name": "What does your company do?",
"acceptedAnswer": {
"@type": "Answer",
"text": "We build revenue-focused websites for B2B companies."
}
}
]
}
]
}The @graph array bundles all entities for the page. Each entity has its own @id, and they can reference each other. The FAQPage entity is just another node in the graph.
The critical rule: visible content
Google's guidelines are clear on one point. The FAQ content in your schema must be visible on the page. You cannot add FAQ schema with questions and answers that do not appear in the page's visible content. This is not a gray area.
If your homepage has an accordion with five questions and answers, mark up those exact five questions. Do not add extra questions that only exist in the schema. Do not paraphrase the visible answers differently in the schema. The schema text and the visible text should match.
AI answer engines are less strict about this than Google, but matching schema to visible content is still best practice. It builds trust with all systems and avoids any risk of being flagged for deceptive markup.
What to write in your FAQ sections
The questions you choose matter as much as the markup itself. Think about what people actually ask AI assistants about your product category.
Do not write generic questions like "Why choose us?" or "What makes us different?" These are marketing prompts, not real questions. Instead, write specific, queryable questions that match how people phrase things to AI.
Good FAQ questions for a Webflow agency homepage might include: "How much does a Webflow website cost?", "How long does a Webflow migration take?", "Does Webflow support enterprise-level sites?", "What is the difference between Webflow and WordPress for B2B?", "Do I need a developer to maintain a Webflow site?"
These are questions that real people ask AI assistants. If your FAQ schema contains the answer, and your answer matches your visible content, you become a citable source.
Monitoring and validation
After implementing FAQ schema on multiple pages, validate each one. Use Google's Rich Results Test to confirm the JSON-LD is syntactically valid. Use the Schema Markup Validator to check entity relationships.
For ongoing monitoring, check Google Search Console's Enhancements section for FAQ-related errors. If Google detects issues with your FAQ markup, they will appear there.
For AI answer engine visibility, track your brand mentions in tools like Karpi's AEO monitoring to see if your FAQ content is being cited by ChatGPT, Perplexity, or other AI systems.
The bottom line
FAQ schema is one of the easiest schema types to implement and one of the most underutilized across multi-page sites. Most teams add it to /faq and forget about it. But every page with visible Q&A content is a missed opportunity.
Your homepage FAQ section, your pricing page billing questions, your product page objection handlers: all of these qualify for FAQPage markup. Each one gives AI answer engines clean, structured question-answer pairs they can parse and cite.
The implementation is simple. The JSON-LD structure is straightforward. The CMS integration in Webflow is well-supported. The only thing stopping most sites from having comprehensive FAQ schema is the assumption that it belongs on one page.
It does not. Put it everywhere you have FAQ content. Connect it to your entity graph with @id referencing. And let AI engines find the answers you have already written.