FAQ Schema and the Extra SERP Real Estate
Structured data is worth adding for what it says to machines, not for the rich results Google may or may not grant you this year.
For a few years there was a gold rush around a small block of JSON. If you marked up the questions and answers on your page with FAQ schema, Google might display them directly in the search results, expandable under your link, and your listing would suddenly occupy twice the vertical space of your competitors’. SEO people called this “SERP real estate,” and the phrase tells you exactly how they thought about it: territory to be grabbed. So it was grabbed. Pages sprouted FAQ sections that existed for no reason except the markup — three softball questions bolted to the bottom of a product page, each “answer” a sales pitch. Then Google, drowning in this, cut FAQ rich results back to a small set of trusted sites, and for everyone else the extra real estate vanished as abruptly as it had appeared.
I find this episode more instructive than most SEO stories, because it separates two things that usually get conflated: what structured data is, and what Google currently pays for it.
Start with what it is. Schema.org markup — usually a block of JSON-LD in the page head — is a way of stating in machine-readable form what your page contains. Your HTML shows a question in bold and an answer below it; a human infers the relationship instantly. A machine sees a styled div and a paragraph. The markup removes the inference: this text is a Question, this text is its acceptedAnswer, this page is an FAQPage. Nothing about this is a trick. It’s closer to labeling boxes before a move. The contents don’t change, but anyone handling the boxes suddenly knows what’s in them without opening them.
Now, what Google pays for it. That’s a business decision, revised constantly. Rich results for FAQs were generous, then rationed. Other types — recipes, products, reviews, events — have their own histories of expansion and pullback. The pattern to internalize is that presentation in search results is rented, not owned. Google decides what its results page looks like, quarter by quarter, and any strategy premised on a particular presentation format is a strategy premised on a landlord’s mood.
This is why the gold rush framing was wrong even when the gold was real. The people adding fake FAQ sections weren’t describing their content to machines; they were manufacturing content to qualify for a display format. When the format was withdrawn, they were left with pages made worse — cluttered with filler Q&As nobody asked — for a payoff that no longer existed. Meanwhile the sites whose FAQ markup described real questions their visitors actually asked lost nothing but pixels. Their pages were already the honest shape the markup claimed.
So is structured data still worth adding? I think yes, and more than before, for a reason that has little to do with Google’s results page. The population of machines reading your site is growing. It’s no longer just search crawlers; it’s the language models and answer engines that increasingly stand between people and the web, reading pages and synthesizing responses. Nobody outside those companies knows precisely how much they lean on schema markup, and I won’t pretend to. But the general bet seems safe: when software is trying to extract facts from your page — what this product costs, whether this business is open, what question this text answers — an explicit machine-readable statement of those facts can only help, and ambiguity can only hurt. Structured data is how a page says what it means in a form that survives being read by something that doesn’t see your typography.
There’s a discipline worth adopting if you do add it, and it’s the same discipline Google’s guidelines formally require: the markup must match the visible page. If your JSON-LD claims an FAQ that visitors can’t see, that’s not clever, it’s lying to one audience about what you’re showing the other, and it’s the specific behavior that gets rich results revoked. The rule generalizes nicely. Markup is a description, not a costume. The honest workflow runs in one direction only: build the page people need, then describe what you built. The moment the arrow reverses — the moment you’re shaping content to fit a markup opportunity — you’ve rejoined the gold rush, and we know how that ends.
I’ll admit the machine’s-eye view comes naturally to me, because GazeSite, the audit tool I built, spends its whole life looking at pages the way software does: fetch the HTML, render it, and reason about what’s actually there rather than what the owner remembers building. From that vantage, most pages are startlingly mute. The information is present, but almost none of it is stated; it’s all implied by layout and left for the reader to reconstruct. Humans reconstruct it effortlessly. Machines do it unreliably. Markup narrows that gap for the price of a few lines of JSON.
The general principle, and the reason the FAQ episode is worth remembering: distinguish between features of your site and features of someone else’s product. The rich result was a feature of Google’s product, extended to you temporarily. The accurate description of your content is a feature of your site, and it keeps working — for the next crawler, the next answer engine, the next reader that isn’t a person — no matter what the results page looks like this year. Build for the durable one. Accept the rented one gratefully when it’s offered, and shrug when it’s taken back.
More articles
The title tag's length limit is not a constraint to resent but a discipline that improves your thinking.
Read →Every extra competing call-to-action on a page is a symptom of an organization that couldn't decide what it wants the visitor to do.
Read →When a tool reports a missing H1 on a page that visibly has one, the markup and the delivery are different suspects, and they need different fixes.
Read →