Schema.org Validity and Rich Result Eligibility: Run Separate Checks

First ask if the encoding can be parsed.

Syntax concerns the format used to express the data. In JSON-LD, broken quotation marks, missing separators or invalid JSON prevent reliable parsing. Repair these before evaluating the meaning of the graph. Valid JSON alone can still contain an incorrect type, false price or unrelated entity.

Keep the syntax result tied to the exact candidate being inspected. Testing a copied fragment does not prove that a CMS emits the same bytes or that a second plugin does not publish a contradictory block. Recheck the combined rendered output after deployment.

Schema.org’s getting started documentation explains the distinction between vocabulary and encoding formats. JSON-LD, Microdata and RDFa can express vocabulary; choosing an encoding does not select a Google feature.

Then ask if the meaning fits.

The Schema.org data model defines types and properties with expected relationships. Check that the selected type describes the entity and that the properties and their contents fit that type. A generic validator helps inspect structure, but cannot establish all underlying facts.

Compare every assertion with visible content and accepted source records. The service provider, article author, business address and product price are factual claims even when written inside JSON. Stable identities and coherent relationships need checking alongside correct property spelling.

A type being available does not mean it is useful on every page. Do not create unseen FAQ answers, reviews, instructions or entities to increase the number of nodes. Resolve conflicting identities and unsupported fields before calling the description ready.

Check the current consumer and its requirements.

Open the current Google structured data gallery and the applicable feature resource. Record the feature name, supported type, required and recommended fields, content rules, technical access, policy conditions and date checked. A search screenshot or old tutorial is not the controlling contract.

Type-specific requirements differ. An accurate general Service description does not become a Product feature merely because it has a name and provider. A supported Article feature has its own guidance. Check applicable market or device restrictions instead of assuming every documented presentation is universal.

Keep eligibility distinct from selection. A page can meet documented conditions without being chosen for a richer appearance. Google’s general guidelines explicitly state that correct markup does not guarantee display. A test result is not a ranking or traffic promise.

Worked decision: valid Service, no Service rich-result promise.

This is an invented teaching record. A fictional business called Example Workshop describes “Bicycle inspection” on example.com/services/inspection/ and visibly identifies itself as the provider. Assume those two facts have been approved for this example; no price, rating, geographic reach or measured result is supplied.

The following JSON is a displayed teaching candidate, not injected production markup. It uses the existing Schema.org Service vocabulary and a provider relationship. The example.com identifiers are placeholders; a real site would resolve its own accepted identities and visible evidence first.

{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://example.com/services/inspection/#service",
  "name": "Bicycle inspection",
  "provider": {
    "@type": "Organization",
    "@id": "https://example.com/#organization",
    "name": "Example Workshop"
  }
}

The candidate is valid JSON by inspection and uses a documented Service description. That does not authenticate a real workshop: the supplied business facts are fictional. No external validator or live deployment is claimed in this lesson.

The Google gallery checked on 23 October 2026 does not list Service as a standalone rich-result feature. The correct recommendation is to retain truthful semantics if a real consumer or data-management purpose needs them, while making no Service rich-result claim. Do not add fabricated stars or recast the page to bypass that boundary.

Choose retain, repair, hold or remove.

Retain an accurate graph when its purpose and maintenance source are clear. Repair a useful description with incorrect properties, identity conflicts or obsolete facts. Hold unsupported assertions until the evidence is available. Remove misleading claims or unused markup when its maintenance burden has no documented purpose.

Feature retirement does not by itself make the remaining vocabulary syntactically invalid. Equally, a semantic purpose is not an excuse to leave false content in a graph. Record the reason for each action rather than treating every unsupported feature as either mandatory deletion or unconditional retention.

Keep the decision, evidence source and date, applicable scope, field owner, unresolved issue and next review trigger. Keep these fields together so another reviewer can understand and maintain the decision.

Use each test for the question it can answer.

A generic vocabulary validator checks a wider Schema.org description; a rich-result test evaluates supported Google features. A missing Service enhancement in the latter is not proof that every Service triple is invalid. Also, passing a generic validator does not establish feature eligibility.

After a real deployment, inspect the live rendered graph, visible content, crawl access and canonical relationships, then use the applicable platform diagnostics. Keep observed test receipts and dates. Do not label this planning example as browser-tested or infer a successful result from a different page.

Changes to visible offers, author identities, page structure or platform rules should reopen the relevant check. Preserve the previous accepted record so a correction can be reviewed and reversed where appropriate.

Keep the two decisions visible to the next owner.

Return to the structured data overview or learning overview. Use products, services and reviews for offer evidence and article descriptions for editorial identity.

MIRENA’s supplied schema planning method requires content support, identity, evidence and review before a production graph. Archived feature-targeting examples do not override current documentation, and the method does not control a search platform’s selection.