Structured Data That Earns Citations vs Schema That Just Sits There
Table of contents
I opened the page source of a small flooring installer last month, the kind of site a plugin built in an afternoon, and started reading the structured data near the bottom. It claimed a product catalog of forty items. It declared an aggregate rating of 4.8 from a review count. It described an FAQ section with six questions and answers. None of that was on the page. The visible page was a phone number, a service area, three photos of finished jobs, and a contact form. The catalog did not exist. The reviews lived on a third-party site the markup never pointed to. The FAQ had been deleted from the visible page a year earlier and left behind in the code. That gap, between what the markup announced and what the page actually showed, is the whole subject here: the line between schema that works and schema that just sits there. The owner had been told "add structured data, it helps with AI and Google," ticked the box, and walked away sure the job was done. The job was the opposite of done. Most of what that plugin emitted was inert, and an engine reading the page had no reason to believe any of it.
The dominant question owners actually have is narrower than "is schema good": it is which structured data does something for a small business and which is decoration. Structured data is markup added to a page's code that states facts about the business in a form a machine reads directly, instead of making the machine infer them from the visible text. That is all it is. Whether any given piece of it helps depends entirely on one thing the plugin never checked: does it confirm something real that the page already shows, or does it describe something that is not there.
Which structured data actually helps a small business?
Structured data helps when it confirms facts the page already shows a human, in a machine-readable form an engine can use, and agreeing with the visible text. Markup that describes things the page never displays, contradicts the content, or marks up data no engine consumes is ignored.
That is the short answer. The rest of this is what each half of that line looks like on a real site, why an engine discards most of what plugins emit, and how to tell which kind you are sitting on without reading a line of code yourself.
Two kinds of markup on the same kind of site
Picture two small businesses in the same trade, both with structured data on their sites. The difference between them is not how much markup they have. It is whether the markup is true to the page.
The first site is the flooring installer above. Its markup is generous and almost entirely fictional. The catalog is invented. The rating is unsourced. The FAQ is a ghost of a section that no longer exists. An engine reading that page sees the visible content say one thing and the markup say another, and it has to decide which to believe. It believes the visible page, because that is what a human sees, and it treats the markup as unreliable. Every false property drags the credibility of the rest down with it. The owner added fifty hopeful properties and got nothing, because not one of them was checkable against the page.
The second site is a competitor down the road. Its markup is small and dull and entirely accurate. It states the business name, exactly as it appears in the visible header. It states the service area, the same one written on the page. It states the phone number that matches the one a visitor would tap. Three or four properties, every one of them confirming something the page already shows a human. An engine reading that page finds the markup and the visible content saying the same thing, in agreement, and it can use the markup as a clean machine-readable copy of facts it already trusts. That site gets pulled into answers the first one never reaches, not because it has more markup, but because its markup is the kind an engine can act on.
States facts the page already shows a human: the business name in the header, the service area on the page, the phone number a visitor would tap. Every property is specific, checkable, and matches the visible text. The engine reads it, finds it agrees with the page, and uses it as a trusted machine-readable copy of facts it already believes. Small, dull, and pulled into answers.
Describes a product catalog the page never shows, an aggregate rating from reviews that live elsewhere, an FAQ that was deleted a year ago. The markup contradicts the visible page or describes nothing on it. The engine cannot confirm any of it against what the page displays, so it treats the whole block as unreliable and discards it. Generous, hopeful, and ignored.
The owner of the first site and the owner of the second both believe they "have schema." Only one of them has the kind that does anything. The volume of markup told you nothing about which was which. The agreement with the page told you everything.
Why the engine ignores most of what a plugin emits
The consumers of this markup are search engines and AI platforms generally, Google and assistants like ChatGPT, Claude, Gemini, and Perplexity, and none of them can take a page's markup on faith. Markup is trivially easy to fake; anyone can declare a 5-star rating and a thousand reviews in code. So the engine does the only sensible thing: it checks the markup against the visible page, and against what it can verify elsewhere, and it uses the parts it can confirm. The parts it cannot confirm, or that contradict what it can see, it sets aside.
This is the mechanism behind the inertness, and it is worth being precise about what is actually observable here. Nobody on the outside knows the exact internal weight an engine assigns to each property; that is hidden and it shifts. What you can watch happen is the pattern. Markup that confirms a checkable fact the page already shows gets used. Markup that claims something absent or contradicts the visible content gets skipped. The reason is not mysterious. The engine had no reason to trust the unconfirmable property, and a system answering real questions for real people does not stake an answer on a claim it cannot verify.
Plugins produce a great deal of exactly the markup that lands in the skip pile. They emit it by default, generically, for pages that do not have the things being described. They mark up review widgets that pull from elsewhere, FAQ blocks that were later removed, product types for a business that sells a service, organization details that were filled in once and never matched the rebranded site. The markup is generated from a template, not from the actual content of the page, so it drifts out of step with what the page shows the moment anything changes. Worse, it often marks up data no engine has a use for in the first place, properties that describe the business in ways no answer ever needs. That is effort with no payload. This is the same reason an engine quietly drops other things it cannot use; a model reads the plain text and structure of your page and works only from what it can actually confirm, and what an AI model reads on your page and what it discards is the wider version of that behavior. Inert schema is one more item on the discard list.
The instinct to add every property a plugin offers backfires. One false or unconfirmable property does not just fail on its own; it makes an engine trust the whole block less. Five accurate properties an engine can confirm outperform fifty hopeful ones it cannot. The goal is not coverage. It is agreement with the page.
None of this means structured data is useless. That is the wrong lesson, and it is the opposite of the point. Accurate markup is real and worth having; it gives an engine a clean, machine-readable confirmation of facts it can act on, and it is part of what makes a business legible to a machine at all. The problem is never that schema does nothing. The problem is that most of what gets added is not the accurate kind, so the owner pays the effort and the engine pays it no attention.
What an owner should actually do about it
You do not need to read code to judge your own markup. You need to know the test the engine applies and apply it yourself, in plain terms. Working markup has a few attributes you can check by eye against your own page.
- It states a fact the page already shows. If a property describes something a visitor can see on the page, it is a candidate for working markup. If it describes something the page does not show, it is a candidate for the skip pile.
- The fact is specific and checkable. A named service area, an exact phone number, a real business name. Not a vague claim a machine cannot pin to anything.
- It agrees with the visible content. The markup says the same thing the page says. No rating the page does not display, no catalog it does not list, no FAQ it no longer has.
- An engine actually consumes it. It marks up the kind of fact answers are built from for your kind of business, not an obscure property nothing reaches for.
Run your own site against that test and the markup usually sorts itself into two piles fast. The first pile is the small set of properties that confirm real, visible facts; keep those and make sure they match the page exactly. The second pile is the contradictory and empty markup, the ghost FAQ, the invented catalog, the rating sourced from nowhere; that pile is what to cut or fix, because every item in it is dragging down the credibility of the first pile. The direction of the fix is the same for almost every small business: fewer properties, all of them true, all of them in agreement with the page a human sees.
Read each piece of markup and ask: does this confirm something the page already shows a human, in a form a machine can check? If yes, it is working for you. If it describes something absent or contradicts the visible page, it is sitting there at best and hurting you at worst. Keep the confirmable. Cut the rest.
This is also where being legible to a machine connects to being believed by one. An engine that finds your markup and your visible page in agreement has one more reason to treat your business as real and your claims as trustworthy; the same agreement between what you say and what can be verified is what earns belief in the first place, and how a machine decides your business is real and trusts what it claims is the broader judgment that accurate markup feeds into. Contradictory markup does the reverse. A page whose code claims things its content denies is a page giving a machine a reason to doubt it.
What this post does not do is hand you the implementation. Which schema types a small business should actually use, how to write the properties so a machine reads them, how to ship the markup and confirm it validates, the per-type detail of where each fact goes, that is a build, not a diagnosis, and it has its own home. If you want which structured-data types are worth adding and how to mark them up correctly, that guide owns the implementation end to end. This piece is only the diagnosis: working markup versus inert markup, and why an engine ignores most of what you were sold. The deeper prior on how schema and entities fit together, if you want the ground underneath all of this first, is in what schema and entities actually are for a small business.
The move from here is not to add more. It is to open your own page, sort your markup into the two piles, and go read the structured-data guide to fix the pile that is sitting there.
