Your schema markup is valid JSON. Google still shows no rich result.
You added structured data, the page parses fine in your editor, and you assumed the stars or the FAQ accordion would show up in search. Weeks later, nothing. No error in Search Console, no warning, no star rating. Just a plain blue link like every page that has no markup at all. This is the defining failure mode of structured data: it does not fail loudly, it fails silently, and the silence is the whole problem.
Structured data is one of the highest-leverage on-page SEO investments you can make, because it changes how your result looks in search and feeds the machines that increasingly summarize the web. But the leverage cuts both ways. A single missing required field, or one trailing comma that breaks JSON parsing, disqualifies the entire block from rich results. Google does not partially honor a broken block. It ignores it, says nothing, and moves on. Most teams ship structured data once, never confirm it produced anything, and assume it works because it "looks right." This post is about why it usually does not.
What's in this post
- @context, @type, and why JSON-LD wins
- Required vs. recommended fields, and the silent disqualifier
- Markup must match what the page actually shows
- The 2023 FAQ and HowTo change, and why the markup still matters
- Validator vs. Rich Results Test, and what each one tells you
@context, @type, and why JSON-LD wins
Every block of structured data is an entity description: a machine-readable statement of what a thing is. Two properties anchor every block. @context tells the parser which vocabulary you are using (almost always https://schema.org), and @type declares what the entity is: an Organization, an Article, a Product. Get either wrong and nothing else in the block can be interpreted.
There are three syntaxes for embedding this on a page: JSON-LD, Microdata, and RDFa. Google explicitly recommends JSON-LD, and the reason is structural. Microdata and RDFa interleave attributes directly into your HTML, so the markup is scattered across the elements it describes and breaks the moment someone refactors the template. JSON-LD lives in one self-contained <script> block you can drop in, read, and validate in isolation, with no coupling to your visual markup. That is exactly why it is easier to maintain and harder to break by accident.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Acme Inc",
"url": "https://acme.example.com",
"logo": "https://acme.example.com/logo.png"
}
</script>
That is the whole pattern. One script tag, valid JSON inside, a context and a type, and then the fields that describe the entity. The simplicity is deceptive, because the rules about which fields are mandatory are where most pages quietly fall apart.
Required vs. recommended fields, and the silent disqualifier
Google's documentation splits every type's properties into two tiers. Required fields are the minimum for the block to be eligible for a rich result at all. Recommended fields are not mandatory, but they unlock richer presentations and give search engines more to work with. The trap is that the consequences are wildly asymmetric: skip a recommended field and you get a plainer result, but skip a single required field and you get nothing.
Here is the practical breakdown for the four types most sites actually need, drawn from the per-type guidance in Google's structured data reference and schema.org:
TYPE | TYPICALLY REQUIRED | COMMONLY RECOMMENDED
---------------------------------------------------------------------------
Organization | name, url | logo, sameAs, contactPoint
Article / | (none strictly required; | headline, image, author,
BlogPosting | all are recommended) | datePublished, dateModified
Product | name, image, offers | brand, aggregateRating, review
BreadcrumbList | itemListElement (name, | (position should be
| item, position) | sequential and complete)
Always confirm the current required set against the documentation for your specific type, because Google revises these lists. Article is a notable case: Google lists all of its properties as recommended rather than strictly required, so an Article block won't be disqualified the way a Product block missing offers, or a BreadcrumbList missing item, will be: those genuinely produce no rich result at all. The point is the pattern: for the types with hard requirements, a missing required field is not a weaker rich result, it is no rich result. And because the failure is silent, you cannot rely on the page to tell you. You have to check the fields explicitly, which is what a structured data validator is for: it extracts every JSON-LD block, identifies the @type, and flags the required and recommended fields that are missing before they cost you anything.
Markup must match what the page actually shows
There is a rule that catches more sophisticated implementations than missing fields do: your structured data must describe the content that is actually visible on the page. Google's quality guidelines for structured data are explicit that markup describing content not visible to users, or contradicting the visible page, is a violation. The penalty ranges from quietly ignoring the block to a manual action against the site.
This is where teams get clever and lose. A few common mismatches:
- A
Productblock hard-codes"price": "49.00"in JSON-LD while the page renders$59.00, because someone updated the template but not the schema. - An
aggregateRatingof4.8with200reviews appears in the markup, but no rating or review count is shown anywhere on the page. - An
FAQPageblock lists questions and answers that do not appear in the rendered HTML, added purely to chase the rich result.
Each of these is the same mistake: treating structured data as a separate channel you can stuff with claims, rather than a mirror of what the user sees. The fix is a discipline, not a feature. Generate the schema from the same source of truth that renders the page, so the price, the rating, the dates, and the FAQ text cannot drift apart. When the markup and the page agree by construction, this entire class of penalty disappears.
The 2023 FAQ and HowTo change, and why the markup still matters
In 2023, Google substantially restricted FAQ and HowTo rich results. FAQ rich results were limited to a narrow set of authoritative government and health sites, and HowTo rich results were deprecated entirely. For almost every commercial site, this means the FAQ and HowTo JSON-LD you ship today produces no visible rich result in Google search. The accordion is gone, and it is not coming back for most domains.
The contrarian read, and the correct one, is that this does not make the markup worthless. It makes the reason for adding it different. Structured data was never only about the visual rich result. It is the most reliable way to hand search engines and AI systems an unambiguous, machine-readable description of your entities. Google still parses your FAQ markup to understand the page even when it shows no accordion, and the same JSON-LD that no longer earns a SERP feature helps AI systems like ChatGPT, Perplexity, and Google's AI Overviews parse your content into structured facts rather than guessing from prose. Machine-readability is increasingly what determines whether an AI surface understands and cites you correctly, a shift covered in depth in the AI crawler accessibility guide.
So the honest framing for 2026: do not add FAQ or HowTo markup expecting a rich result, because for most sites you will not get one. Add it because clean, accurate structured data is now table stakes for being legible to both search engines and the AI systems reading on their behalf. The rich result was always a side effect. The legibility is the point.
Validator vs. Rich Results Test, and what each one tells you
Two checks confirm structured data, and they answer different questions. Conflating them is why teams think they have shipped working markup when they have not.
A validator checks fields and syntax. It parses your JSON-LD, confirms the JSON is well-formed, identifies each @type, and tells you which required and recommended fields are present or missing. This is the fast, repeatable check you run while building, and it catches the two most common failures: a parse error from a stray comma or unescaped quote, and a missing required field. You can also run it across many pages at once.
Google's Rich Results Test answers the final question: is this specific URL actually eligible for a rich result, in Google's eyes, right now. It fetches the live page, applies Google's current eligibility rules (including the FAQ and HowTo restrictions above), and reports whether a rich result can be generated. It is the authoritative eligibility check, but it is per-URL.
The workflow that works: validate fields and syntax first to catch the silent disqualifiers across your templates, then run the Rich Results Test on representative URLs to confirm final eligibility. The validator tells you the block is correct and complete. The Rich Results Test tells you Google agrees it qualifies. Get both green before assuming anything works.
The LintPage Structured Data Validator does the first half in one request: it extracts every JSON-LD block on the page, catches JSON parse errors, detects each schema.org @type, and validates the required and recommended fields for Organization, Article, Product, and more against Google Search Central guidance. It finds the silent disqualifiers, the ones that produce no error and no rich result, so you can fix them before you ever open the Rich Results Test.
Structured data problems rarely travel alone. The same pages that ship a broken Product block tend to have other on-page issues hiding in the HTML, so it is worth running the full site audit and walking through how to audit a website for SEO while you are in there.
The 30-second version
Structured data is high-leverage and fails silently: for types with hard requirements, one missing required field or one JSON parse error disqualifies the whole block, with no error and no rich result, just a plain link. Use JSON-LD, because Google recommends it and it lives in one self-contained script block instead of being smeared across your HTML. Get @context and @type right, then fill every required field for your type (Product and BreadcrumbList have strict ones; Article's are technically recommended) before worrying about the rest. Make the markup match the visible page, because mismatches get ignored or penalized. Know that since 2023, FAQ and HowTo rarely produce a visible rich result anymore, but the markup still earns its keep by helping search engines and AI systems parse your entities. Finally, remember the division of labor: a validator confirms fields and syntax, and Google's Rich Results Test confirms final eligibility. Run both, and stop assuming "valid JSON" means "working."