Schema Wire
15 subscribers
13 photos
3 links
The newsroom for structured data: which schema types Google just started (or stopped) supporting, rich result rollouts, and what the spec changes mean for your markup — before your competitors notice.
Download Telegram
Channel created
Channel photo updated
The MerchantReturnPolicy field everyone forgets is now table stakes

As of this week, more sellers are quietly getting flagged in Merchant listings for shipping Offer markup without a hasMerchantReturnPolicy node. Google's free listings docs have leaned this way for a while, but sources in the SERPs report the warning moving from optional to a soft eligibility gate on product results.

The deeper play: define it once as a MerchantReturnPolicy with applicableCountry and returnPolicyCategory, then reference it across your whole catalog instead of inlining per product. Cleaner graph, one source of truth.

What it means for you — if your shipping and returns live only in Merchant Center settings and not in on-page JSON-LD, your organic product snippets are leaving eligibility on the table.

Watch this: returns markup is the next field to get a dedicated Search Console report.


Больше про gam updates — @AdOpsWire
Two years post-FAQ cull, the orphaned markup is still costing you

Google restricted FAQ rich results to authoritative gov/health sites and killed HowTo on desktop and mobile back in 2023. Plenty of sites left the JSON-LD in place, figuring it's harmless. It isn't — sources in the SERPs note bloated FAQPage blocks still trip 'unparsable structured data' noise and slow your render budget.

The insider move: don't delete the data, repurpose it. Fold those Q&A pairs into a WebPage with mainEntity or feed them into your Article as about nodes. AI engines still parse Q&A pairs for citation even when Google won't draw a rich result.

What it means for you — audit for zombie FAQPage markup this week. Stripped pages render leaner; the answer content stays AI-visible.
Microdata isn't deprecated — but Google's tooling is voting with its feet

Nobody at Schema.org has formally sunset microdata or RDFa, and the spec still treats all three syntaxes as equal. But here's what's actually happening: the Rich Results Test, the structured data report, and nearly every new Google example ships JSON-LD first. Microdata edge cases (nested itemref, split DOM nodes) increasingly parse inconsistently.

The undercurrent — JSON-LD decouples your data from your DOM, which is exactly what AI crawlers want when they read a page without rendering it fully.

What it means for you — if you're maintaining legacy microdata, you're not breaking rules, but you're betting against the toolchain. Migrate high-value templates to JSON-LD; leave the long tail until a redesign.

Watch this: the next parser quirk will hit microdata, not JSON-LD.
The pending.schema.org namespace is where tomorrow's rich results are born

Most markup folks only touch the stable schema.org core. The real signal lives at pending.schema.org — the staging ground where new types incubate before promotion. Terms like 3DModel, EnergyConsumptionDetails and assorted health types all passed through there first.

Why insiders watch it: a type appearing in pending is the earliest public hint that a vertical is getting structured-data attention. By the time it hits the core release and Google docs, the early movers already have templates shipped.

What it means for you — bookmark the pending namespace and the schemaorg GitHub issues. You can deploy a pending type today; it validates and degrades gracefully if it never graduates.

Watch this: energy and sustainability types are the most active pending cluster right now.
Speakable schema never died — it just went voice-only and nobody noticed

Everyone wrote off speakable when it stayed stuck in 'limited' news-publisher beta for years. As of this week it's still in the spec, still parsed, and still feeding Google Assistant news readouts via cssSelector or xpath targeting.

The overlooked angle — speakable is essentially a hint about which 30-40 words summarize your page. That's the exact same signal AI engines crave for extraction. Markup that was built for voice doubles as a citation-targeting beacon.

What it means for you — if you're a news or how-to publisher, drop a speakable block pointing at your TL;DR sentence. Worst case it's inert; best case it shapes both the voice readout and what an LLM lifts verbatim.

Watch this: voice and AI-answer extraction are converging on the same field.
Reading rec

If this channel's your speed, @IndexOrBust runs a sharp feed on indexing issues. Different angle, same depth — worth a follow.
ProductGroup vs variesBy: the variant markup most catalogs get wrong

Google formalized ProductGroup with hasVariant and variesBy so a parent product can declare its color/size axes while each variant carries its own sku, gtin and price. Most stores still publish 40 near-duplicate Product nodes and wonder why their snippets cannibalize each other.

The right shape — one ProductGroup, variants linked by inProductGroupWithID, and variesBy pointing at the literal property paths (https://schema.org/color). That tells the parser the relationship instead of making it guess.

What it means for you — consolidating variant markup cuts duplicate-content noise and gives Merchant listings a cleaner price range. It also stops AI shopping agents from treating one product as a dozen.

Watch this: variant-aware shopping results are expanding; flat catalogs get left behind.
Stop repeating yourself: @id referencing is the pro move in JSON-LD

The single biggest tell of amateur markup is the same Organization block copy-pasted into every entity. Pros use a @graph array with stable @id values (#org, #website, #logo) and then reference by ID everywhere else. Define the publisher once, point to it forever.

Why it matters beyond elegance — a connected graph with resolved IDs is what lets Google and AI crawlers build a clean entity model of your site instead of reconciling a hundred duplicate org nodes.

What it means for you — refactor your template to a single @graph with a node for Organization, WebSite, WebPage, and the page's primary entity, all wired by @id. Smaller payload, zero contradictions, stronger entity signals.

Watch this: contradictory duplicate nodes are a quiet cause of 'eligible but not shown.'
The self-serving review rule still nukes star ratings — and it's widening

Google's policy that you can't show review stars for reviews you host about your own Organization or your own products-as-a-brand has been on the books, but enforcement keeps tightening. Sources in the SERPs report more LocalBusiness and brand pages silently losing stars even with valid AggregateRating markup.

The nuance people miss — it's allowed for products you SELL but not for your own org/service reviews. The markup validates either way, so you get no error, just no stars.

What it means for you — if your homepage or service pages mark up self-authored testimonials with AggregateRating, that's the classic self-serving pattern. Move review stars to product/third-party-reviewable entities only.

Watch this: 'valid but not eligible' is the new normal — validation isn't a guarantee.
Carousel rich results need ItemList scaffolding most people skip

Google's host carousels (recipes, courses, restaurants, movies) don't fire off your detail-page markup alone — they need a summary page carrying an ItemList of ListItem nodes with position and url pointing to each detail page that carries the real schema. Two-tier structure, and the top tier is what most sites omit.

The insider detail — the ItemList page itself doesn't repeat the full recipe/course data; it just orders and links. The detail pages do the heavy lifting. Get the wiring wrong and you get individual rich results but no carousel.

What it means for you — if you have a category of richly-marked pages and no carousel, check whether you've built the ItemList hub. That's usually the missing piece.

Watch this: carousel eligibility is the cheapest SERP real-estate upgrade going unused.
Clip and SeekToAction markup is the key chapters nobody implements

Google's video key-moments rely on either explicit Clip markup (manual start/end with names) or SeekToAction that tells Google your URL fragment pattern so it can auto-detect chapters. Most channels rely on YouTube's own chapters and never touch the on-page VideoObject extension.

The edge — for self-hosted or embedded video on your own domain, Clip markup is the only way to claim key-moments real estate in the SERP. Each Clip needs a startOffset, name, and a deep-linkable url.

What it means for you — if you publish tutorial or product video on your own pages, add Clip nodes to your VideoObject. You turn one blue link into a stack of jump-to-moment links.

Watch this: AI video summarizers read Clip names too — free chapter labels for the machines.
Your JSON-LD has a render budget — and bloated graphs blow it

Here's the unglamorous truth: Googlebot fetches your raw HTML for structured data before full render in many cases, but if your JSON-LD is injected client-side by a tag manager, it may miss the first pass entirely. As of this week, more crawl-diagnostics threads point to GTM-injected schema as the silent reason 'no items detected' shows up despite working markup in the browser.

The rule pros follow — render JSON-LD server-side, in the initial HTML, never via deferred JavaScript. If a tag manager is your only option, accept that it's a gamble on the rendered pass.

What it means for you — view-source (not inspect-element) your pages. If schema isn't in view-source, Google's first crawl can't see it, and AI crawlers that don't execute JS definitely can't.

Watch this: JS-injected schema is the most common invisible failure of 2026.
QAPage survived the FAQ purge — and it's the markup forums forgot

When Google gutted FAQPage rich results, it left QAPage alone — the type built for single-question pages where users post answers (forums, Q&A communities, support threads). It still earns rich results with upvote counts and accepted-answer badges via acceptedAnswer and suggestedAnswer.

The distinction that trips people — FAQPage is author-written Q&A; QAPage is user-generated single-question threads. Mislabel a forum thread as FAQPage and you get nothing; label it QAPage and you can still earn vote-count snippets.

What it means for you — if you run community, support, or UGC Q&A, you have a live rich-result type while everyone else mourns FAQs. Mark upvoteCount and the accepted answer.

Watch this: UGC Q&A is one of the last expanding rich-result surfaces in Google.