Most product pages already have an FAQ section. Sizing, compatibility, what's in the box, whether the app works offline. The questions are useful, and plenty of sites mark them up with FAQPage schema.
The problem is that the FAQPage block usually sits on the page with no connection to the Product or SoftwareApplication it's answering questions about. A search engine sees two separate things: a product, and a list of questions. Nothing in the markup says those questions are about that product.
subjectOf fixes that, and you don't need the FAQPage wrapper to do it. This is what I learnt at Google's Search Central Deep Dive in Barcelona recently: attach each Question, with its acceptedAnswer, directly to the Product.
In this guide I'll show how, why subjectOf is the right property here when hasPart is the right one for articles, and how it ties in with Google Merchant Center's new question_and_answer attribute.
Quick answer
On a product or software page, skip FAQPage. Add subjectOf to the Product or SoftwareApplication and list each Question, with its acceptedAnswer, there.
In an article, use hasPart on the Article instead, because the questions are a section of the article itself.
Why connect FAQ schema at all?
Google stopped showing FAQ rich results for every site on 7 May 2026, after limiting them to government and health sites in 2023. If you only added FAQPage markup for the dropdowns in search results, that reason is gone.
Google has said it still uses FAQ structured data to understand pages, though. AI search experiences such as AI Mode answer detailed product questions, and the clearer the link between a product and its answers, the less a system has to guess.
A standalone FAQPage tells a machine "here are some questions". Questions connected to a Product tell it "here are answers about this specific product, with this SKU, from this brand".
That's the difference between markup for a rich result and markup that describes an entity.
It supports Google Merchant Center product Q&A
Google Merchant Center now has a question_and_answer product attribute. It's optional, available in all countries, and Google says it's mainly meant for conversational experiences such as AI Mode in Google Search.
The limits are generous:
- Up to 30 question and answer pairs per product
- Up to 1,000 characters for each question and each answer
- Up to 10,000 characters in total per product
One thing to be clear about: the help page lists no Schema.org equivalent for this attribute. Google doesn't say it reads Q&As from your on-page markup to fill it. You submit them through your product data source (a file, Google Sheets or the Merchant API). FAQ schema is not a replacement for the feed.
So why bother with both? Because the feed and the page should tell the same story.
One source of truth
When the FAQ on your product page, the Questions linked to your Product with subjectOf, and the question_and_answer values in your feed all come from the same set of Q&As, Google sees the same answers wherever it looks. The feed says "this product has these answers", and the landing page backs it up with visible content and markup that ties those answers to the exact same product.
In practice, store your product FAQs in one field in your CMS or PIM, then use that field to:
- Render the visible FAQ section on the product page
- Output each
Questionand itsacceptedAnswerin the Product'ssubjectOf - Populate the
question_and_answerattribute in your Merchant Center feed
If marketing edits an answer, all three update together. You never end up with a feed answer the page contradicts.
Write FAQs that work for both
Google's content rules for the attribute are good rules for on-page product FAQs too:
- Product information only. Leave out prices, sale dates and shipping deadlines. They go stale, and they belong in other attributes and in your Offer markup.
- No keyword lists. Write a real question a buyer would ask.
- Don't repeat the title or description. Cover what they don't: specifications, materials or ingredients, what's in the box, compatibility, intended use.
- Keep answers accurate and specific. An AI answer engine will quote you. Vague answers don't get used.
Feed format tip
Answers often contain commas, colons and quotes. Google recommends TSV over CSV for text feeds to avoid escaping problems. If you build the feed from the same field that feeds your JSON-LD, test both outputs with an answer that contains every special character.
What subjectOf means?
subjectOf is defined on Thing, so every Schema.org type can use it, including Product and SoftwareApplication. Its value must be a CreativeWork or an Event, and Schema.org describes it as a creative work or event about this thing.
Its inverse is about. These two statements mean the same thing:
- Product
subjectOfQuestion: "this product is the subject of this question" - Question
aboutProduct: "this question is about this product"
You only need one direction. Nesting the questions inside the Product's subjectOf is the simplest option. If you keep each Question as its own node in an @graph, you can add about as well so the link reads both ways.
Why you don't need FAQPage
FAQPage is a subtype of WebPage. It describes a whole page whose purpose is questions and answers. A product page isn't that. It's a page about a product that happens to have a few questions on it.
Adding a FAQPage node means describing a second page on the same URL, then linking that page to the product. Attaching Question nodes directly skips the middle layer and says exactly what's true: these questions are about this product.
It's valid, too. subjectOf accepts any CreativeWork, and Question is one (it's a subtype of Comment). Each Question carries its answer in acceptedAnswer, the same way it would inside a FAQPage.
One caveat to be honest about: when Google said it still uses FAQ structured data, it was talking about FAQPage, and it hasn't documented Question nodes on a Product. Both are valid Schema.org. This approach swaps a familiar container for a more accurate description of the page.
Why subjectOf instead of hasPart for products
hasPart is the property people usually reach for first, because they think of the FAQ as "part of the page". It doesn't fit here, for two reasons.
1. Product can't have hasPart
hasPart is defined on CreativeWork. Product is not a CreativeWork, so hasPart on a Product is not a valid property. The Schema.org validator will flag it as not recognised for that type, and parsers are free to drop it.
If you really want to use hasPart on a product page, it can't go on the Product. You'd need to add a WebPage node, set its mainEntity to the Product, and put hasPart on the WebPage instead. That's an extra layer most Product markup doesn't have, and the questions end up attached to the page rather than the product. subjectOf gets you there with one property on the markup you already output.
2. On SoftwareApplication it says the wrong thing
SoftwareApplication is a CreativeWork, so hasPart validates there. That's the trap. hasPart says the questions are a component of the software, like a module or a plugin. They aren't part of the app you install. They're content that answers questions about the app.
Valid markup that describes the wrong relationship is worse than no markup, because it looks correct in every testing tool.
The relationship is "about", not "part of"
The questions on a product page are about a real-world thing you can buy or download. That's exactly what subjectOf and about express. Here's how the options compare:
| Property | Product | SoftwareApplication | What it says |
|---|---|---|---|
| subjectOf | Valid | Valid | These questions are about the product or app |
| hasPart | Not valid | Valid, but misleading | The questions are components of the product or app |
How to connect FAQs to a Product
Most product pages output a single Product block, usually generated by the ecommerce platform or an SEO plugin. You don't need to wrap it in anything else. Put each question in the Product's subjectOf as a Question, with the answer in acceptedAnswer.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Trail Runner 2",
"sku": "TR2-BLK",
"brand": { "@type": "Brand", "name": "Example Outdoor" },
"offers": {
"@type": "Offer",
"price": "129.00",
"priceCurrency": "GBP",
"availability": "https://schema.org/InStock"
},
"subjectOf": [
{
"@type": "Question",
"name": "Is the Trail Runner 2 fully waterproof?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes. The upper uses a sealed membrane that keeps water out in puddles and wet grass. Water can still enter over the collar if you wade deeper than ankle height."
}
},
{
"@type": "Question",
"name": "Does it fit true to size?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Most runners take their usual size. If you wear thick hiking socks, go up half a size."
}
}
]
}The parts that matter:
Product.subjectOfholds an array ofQuestionnodes, one for each question shown on the page.- Each
Questionhas the question text innameand anacceptedAnswerof typeAnswer. - There's no FAQPage node and nothing else to add. The questions live inside the Product markup you already have, so most sites only need to extend their existing template.
If you'd rather keep each Question as its own node, give it an @id and reference it from subjectOf. My guide to @graph in schema markup covers the pattern in detail.
How to connect FAQs to a SoftwareApplication
Same pattern. Swap Product for SoftwareApplication (or a subtype like WebApplication or MobileApplication) and keep subjectOf even though hasPart would technically validate.
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"@id": "https://example.com/app/#software",
"name": "Example Invoicing",
"applicationCategory": "BusinessApplication",
"operatingSystem": "Web, iOS, Android",
"offers": {
"@type": "Offer",
"price": "0",
"priceCurrency": "USD"
},
"subjectOf": [
{
"@type": "Question",
"name": "Can I import invoices from a spreadsheet?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Yes. Upload a CSV or XLSX file and map each column to an invoice field. Up to 5,000 rows can be imported at once."
}
},
{
"@type": "Question",
"name": "Does it work offline?",
"acceptedAnswer": {
"@type": "Answer",
"text": "The mobile apps let you create and edit invoices offline. Changes sync when you reconnect."
}
}
]
}Save hasPart on software for things that really are parts of it. A SoftwareApplication that bundles add-ons could list them with hasPart. Its help docs and FAQ belong under subjectOf.
When hasPart is the right choice: FAQs in articles
Blog posts and guides often end with an FAQ section. Here the relationship is different. The FAQ isn't about a separate real-world thing. It's a section of the same piece of content, written by the same author, on the same topic.
Article and Question are both CreativeWorks, and the questions are literally contained in the article. That's what hasPart and its inverse isPartOf are for. The Question nodes look exactly like the ones on a product page. Only the property changes.
{
"@context": "https://schema.org",
"@type": "Article",
"@id": "https://example.com/blog/waterproof-shoes-guide/#article",
"headline": "How to choose waterproof running shoes",
"author": { "@id": "https://example.com/#person" },
"hasPart": [
{
"@type": "Question",
"name": "Are waterproof running shoes hotter?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Usually, yes. The membrane that blocks water also slows airflow, so they run warmer than mesh shoes in summer."
}
}
]
}Using subjectOf here would be wrong in the other direction. It would say the article is the subject of the questions, as if they were about the article itself ("When was this post updated?") rather than about waterproof shoes.
A simple test for any page:
- Are the questions a section of this content? Use
hasParton the Article. - Are the questions about this thing? Use
subjectOfon the Product or SoftwareApplication.
A product review article can use both. The Article hasPart its questions, and each Question can also be about the Product being reviewed.
Common mistakes
- Questions with no link to the product. A standalone FAQPage or loose Question nodes are valid, but nothing says what they're about. Put them in the Product's
subjectOf. - hasPart on a Product. Not a valid property for the type. Use
subjectOf. - hasPart on a SoftwareApplication FAQ. Validates, but says the FAQ is part of the software.
- Marking up questions that aren't visible. Every Question in the markup should be on the page.
- Using QAPage for seller-written FAQs. QAPage is for a page built around one user-submitted question with community answers, not questions you write and answer yourself.
- Using suggestedAnswer for your own answers.
suggestedAnsweris for answers that haven't been accepted, such as community replies. Your own answers go inacceptedAnswer. - Mismatched @id values. A trailing slash or http vs https difference breaks the link. Copy @ids from one place.
FAQ
Will subjectOf bring back FAQ rich results?
No. Google stopped showing FAQ rich results for all sites in May 2026. Linking your questions to a Product helps search engines understand which product the answers are about, which matters more now that AI search answers product questions directly.
Should I use subjectOf on the Product or about on the Question?
They're inverses, so either one creates the link. Nesting the questions inside subjectOf is the simplest. If you keep each Question as its own node in an @graph, add about as well so the relationship is clear whichever node a parser reads first.
Do I still need FAQPage schema?
Not on a product or software page. FAQPage describes a whole page of questions and answers. On a product page, Question and acceptedAnswer nodes in the Product's subjectOf describe the content more accurately. FAQPage still fits a dedicated FAQ page.
Does Google Merchant Center read FAQ schema from my product pages?
Google's help page for the question_and_answer attribute lists no Schema.org equivalent. Submit Q&As through your product data source, and keep them in sync with the FAQ on the page and in your markup.
Is hasPart ever right for a SoftwareApplication?
Yes, for things that are actually part of the software, such as bundled modules or add-ons. Use subjectOf for content about the software, like FAQs, help docs and reviews.
