Adding Structured Data Without Promising Rich Results

Structured data gives machines an explicit description of content that people can already see on a page. A product can have a name, price, availability, and reviews; an event can have a date and location.

Search engines may use that information for enhanced search results. “May” is doing useful work here: valid markup does not guarantee a rich result or a ranking improvement.

JSON-LD keeps the markup separate

JSON-LD is the format I would normally start with because it sits in a script block rather than being spread across the visible HTML:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Adding Structured Data Without Promising Rich Results",
  "author": {
    "@type": "Person",
    "name": "Ronalds Vilciņš"
  }
}
</script>

The values must match the page. Structured data is not a place to add a five-star review, price, or author that visitors cannot verify in the content.

Choose a type the page genuinely represents

Schema.org defines a large vocabulary, while search engines document the types and properties they may use for particular search features. Those are related but not identical sets.

Choose the most specific accurate type, add the required properties for the search feature you care about, and include recommended properties when the data is available. Do not mark a normal article as a product because product results look nicer.

Test the result with Google’s Rich Results Test when targeting Google features and use a schema validator for the wider vocabulary. After publishing, Search Console can report eligible enhancements and markup problems.

Structured data is worth adding when it describes important content cleanly and can be kept accurate. If the visible page changes but the JSON-LD does not, the extra markup becomes an extra source of bugs—which is less rich than advertised.