FAQPage schema on a small site: keep it for AI answers or strip it out?

Google restricted FAQ rich results to government and health sites back in 2023, so for most small sites FAQPage markup no longer gets the expanded snippet it used to. Some people strip it out as dead weight. Others keep it because the same Q and A text still gets pulled into AI answers, and it's cheap to maintain. My hunch is it's not worth a template rewrite on its own, but I'm not sure. The hard part is measurement, since you can't easily isolate FAQ impact in Search Console anymore. How would you judge it: clicks to those pages, citations in ChatGPT or Google AI answers, or just leave it alone?

I don't think markup is what gets a page cited in ChatGPT or Google's AI answers. From what I know, those systems read the visible page text, so a Q&A block that's actually on the page matters much more than the JSON-LD wrapped around it. If the questions are useful, keep them visible and leave the markup alone. Q&A that only exists in the schema is a different problem. For measurement, I wouldn't bother trying to isolate the schema. Track citations for a fixed set of prompts over a few weeks, before and after any change.

Agreed that the visible text does most of the work. My rule is to keep FAQPage markup only when every question and answer in it also shows up on the page, word for word. Google's guidelines expect markup to match what users actually see, so schema-only Q&A is the real risk, not the extra JSON-LD.

Word for word is stricter than Google actually asks for. The rule is that markup should reflect what users can see on the page, so an answer that's lightly reworded but says the same thing should be fine. Forcing exact matches just creates template churn. The thing to avoid either way is Q&A that exists only in the schema and nowhere on the page.

Agreed on the rewording. The test I'd use is simpler: would a real customer actually ask this, and is the answer already on the page? If both are yes, keep the visible block and the markup. If the questions only exist because someone wanted FAQ schema, drop them.

For a clinic or a plumber, the real questions are usually pricing, same-day availability and insurance, the same stuff people ask on the phone. Keep those visible on the page, because then the markup can't drift away from what the page says, and that drift is what gets sites into trouble.

The part that decides this is where the markup comes from. If the template builds the visible FAQ and the JSON-LD from the same data, drift mostly can't happen. It breaks when someone hand-writes the schema in a separate plugin field, because nobody remembers to update it when the price or the same-day policy changes. My rule of thumb is that if the markup and the visible block don't share one source, you either merge them or drop the schema. Pricing answers go stale fastest, so that's usually where it bites first.

Agreed on the shared source. Stale prices hit TikTok traffic harder than search, because short-video viewers often land on the page weeks after the ad was cut, and by then the price they saw may have changed. If the FAQ holds a price, put it in one template field that the ad copy reads from too, so a change updates everywhere at once.

The shared field also makes this measurable. If the price comes from one template value, push it into the dataLayer on page load and send it as a GA4 event parameter. Then when the price changes, you can filter TikTok sessions by the old price string and count how many people landed on a page quoting a number you no longer charge. Without that, stale-price complaints just show up as a vague bounce rate bump that nobody can tie to a specific ad.

The catch is that the parameter has to fire on the live page, not only in GTM preview. Page caches can keep serving the old value for a while after an edit, so spot-check a few real URLs after every change.

Agreed, and it only pays off if you register the parameter as an event-scoped custom dimension in GA4 before the next price change. GA4 doesn't backfill, so anything sent before registration can't be filtered later. Also send the price as a plain number with a separate currency field, not a formatted string like "€89/visit", or the filter gets messy.