HANNAH: I want to start before the question even gets framed, because there’s a factual split inside it that changes everything. A pizza chain wants to pile every schema type onto its pages, FAQ, Review, HowTo, Recipe, the lot, to maximize rich-result chances. Here’s the documented reality, and I’ll only state what’s verifiable. Schema makes a page eligible for rich results, it does not guarantee them, and Google has narrowed which types actually produce visible results over the last couple of years. So “add everything” is built on an assumption that’s already partly false, more markup does not mean more rich results.
DANA: Good, then this isn’t one question, it’s two stacked badly. There’s “should we use schema,” which is yes, and “should we use all of it everywhere,” which is where it goes wrong. Let me hold both apart so the room doesn’t argue past each other. Hannah’s saying the premise oversells the payoff. Who’s got the harm side, because I suspect there’s a real cost, not just a wasted effort.
ELENA: That’s mine, and the cost is concrete. Schema is supposed to describe what’s genuinely on the page. The moment you mark up content that isn’t there, or isn’t visible to the user, you’ve crossed from description into misrepresentation, and that’s a structured-data guidelines violation, not a gray area. Marking up FAQ content that doesn’t appear on the page, or Review markup the business generated about itself, can earn a manual action. So “add every type” isn’t just low-value, parts of it are an active risk to the whole site’s standing. The eligibility you wanted gets replaced by a penalty you didn’t.
MARCUS: I’ll push on the chain’s behalf, but only partway, because half of this instinct is fine. Using LocalBusiness and Restaurant markup on a pizza chain, with real address, hours, menu, that’s not just allowed, it’s the single most valuable schema they could ship. So the impulse to mark things up isn’t wrong. The mistake is treating schema like confetti instead of like a label. Where I won’t defend them is the FAQ-and-Review-everywhere part, because that’s not ambition, that’s marking up things that either aren’t on the page or aren’t honest. So this splits cleanly, real on-page entities yes, decorative or invented markup no.
SOFIA: And there’s a payoff question even for the markup that’s legitimate, which is whether a rich result helps the click or just adds noise. Review stars under a restaurant listing can genuinely lift clicks. But cramming FAQ accordions into a search result for a pizza place, even if you somehow qualified, can push the actual thing the user wants, the menu, the order button, the hours, further down. More rich-result real estate isn’t automatically better. The question is whether the enhancement serves the searcher’s intent or buries it.
NOAH: The shape of this request is familiar, and naming it helps. “Add every schema type” is the same instinct as “every keyword in the H1” or “self-canonical everything,” a belief that more of a good signal is linearly more good. It almost never is. Signals have ranges where they help and ranges where they tip into spam or noise. The tell is always the word “every” or “all.” And if they’re reasoning this way about schema, the same maximizing logic is probably showing up elsewhere on the site, worth a look beyond just the markup.
THEO: I’ll skip a framework and name the actual decision rule hiding here, because schema has a clean one. Mark up what is real, on the page, and visible to the user. That single test sorts the whole request. Restaurant, LocalBusiness, Menu, real aggregate ratings from a legitimate source, all pass, because they describe true, present, visible things. Invented FAQs, self-authored reviews, HowTo steps that aren’t on the page, all fail the same test. The chain doesn’t need a list of approved types from us. They need that one question applied honestly to each page.
GRACE: Small content-truth point that sits underneath Theo’s rule. Schema is a promise to the search engine about what the page contains. If the visible page and the markup disagree, you’ve created two versions of the truth, and the search engine increasingly checks one against the other. So the discipline isn’t really technical, it’s honesty, the markup has to match what a human actually sees. The teams that get burned are the ones who treat schema as a separate layer they can inflate independently of the page.
AIKO: Systems note, because schema rots quietly. It’s typically added once at template build and then forgotten, while the visible page changes around it, a menu updates, an FAQ gets removed, hours change, and now the markup describes a page that no longer exists. So the durable practice isn’t just “mark up real things today,” it’s tying schema to the content it describes so they change together, and rechecking it when rich-result types themselves get deprecated, which they periodically do. Static schema on a changing site becomes a liability on a timer.
DANA: This one I can land with a clean line down the middle, because unlike some calls, this one isn’t all conditional. We do not add every schema type. We add the schema that describes what is real, present, and visible on the page, and we refuse the rest, not because it’s low-value but because the invented parts are a guidelines risk that can cost the whole site. Concretely, for this chain, yes to Restaurant, LocalBusiness, Menu, and genuine aggregate ratings from a real review source. No to FAQ or HowTo markup for content that isn’t actually on the page, and a hard no to self-authored Review markup, which is the one most likely to trigger a manual action. We apply Theo’s single test, is it real, on the page, and visible, to each type. We tie the markup to the content so they stay in sync, and we recheck when Google changes which rich results it supports. The instinct to use schema is right. The instinct to maximize it is the part that bites.
HANNAH: Which keeps the eligibility they actually wanted while dropping the markup that would have put it at risk.
DANA: That’s the whole of it. Schema isn’t a volume play. It’s a labeling job, and a label that lies is worse than no label at all.