JSON-LD Examples for Every Schema Type

You know your page needs structured data, so you go looking for an example to copy — and end up with ten browser tabs, each showing a slightly different JSON-LD block, none of them explaining which properties are actually required versus optional for your content.

This guide skips the theory and goes straight to working code. Below is a complete, copy-ready JSON-LD example for every major schema type, with the properties that matter called out so you know exactly what to change before it goes live on your own page.

What is a JSON-LD example, exactly?

A JSON-LD example is simply a filled-in template. It follows the JSON-LD (JavaScript Object Notation for Linked Data) syntax that schema.org vocabulary is written in, wrapped inside a script tag so a browser ignores it visually while a search engine reads it as data.

• @context anchors the vocabulary. Nearly every example starts with the same line — "@context": "https://schema.org" — telling the parser which dictionary of terms to use.
• @type declares the category. This single field decides which other properties are expected: Article expects a headline and author, Product expects a price and availability.
• Properties describe the specific page. Everything after @type is just key-value data — name, image, datePublished — that should match what's genuinely visible to a visitor.
• Nesting represents real relationships. A Product example often nests an Offer and an AggregateRating because price and reviews are properties of the product, not standalone entities.

Once you can read one example, you can read all of them — the shape stays consistent, only the type and its required fields change.

Why working examples matter more than theory

Reading the schema.org documentation for a type tells you every possible property. A working example tells you the small subset that's actually worth filling in:

• Examples show realistic minimums. A type might list dozens of optional properties, but a working example shows the handful search engines actually look for on most pages.
• Examples prevent structural mistakes. Copying a correct nesting pattern for something like Offer inside Product avoids the guesswork of building that structure from a property list.
• Examples double as a checklist. Once pasted, each field name in an example becomes a prompt to confirm — "does my page actually show this?" — before publishing.
• Examples save validator round-trips. Starting from correct syntax means the first thing you test is content accuracy, not comma placement.

Step-by-step: using an example on your own page

1. Identify what your page actually is. A blog post is Article, a product listing is Product, a support section is FAQPage — pick the type that matches the content, not the one with the flashiest search result.
2. Copy the matching example below. Each one is complete and valid as written, ready to be edited in place rather than built from scratch.
3. Replace every placeholder value. Swap the example's name, URL, image, price, and dates for your page's real details — nothing from the sample should survive into production.
4. Remove properties that don't apply. If your page has no rating, delete the aggregateRating block entirely rather than leaving it with fabricated numbers.
5. Paste the script tag into your page. Place it in the head, or just before the closing body tag, so it stays out of the visible content area.
6. Validate before and after publishing. Run the edited code through Google's Rich Results Test, then re-check the live URL once it's public.
7. Update the block whenever the content changes. A price change, a rewritten FAQ answer, or a new author all need the matching property updated in the script too.

Common mistakes when copying an example

1. Leaving example.com URLs in place

It's an easy field to miss because it doesn't visibly break the page — but a url or image property still pointing at a placeholder domain tells a search engine the data doesn't describe this page at all.

2. Keeping properties that don't apply to your content

An example built to show every possible field often includes optional properties like aggregateRating or review. If your page doesn't have that content, the property needs to be deleted, not filled with invented numbers.

3. Using the wrong date format

Dates in JSON-LD need ISO 8601 format (2026-07-04), and copying a date typed in a different style from elsewhere on the page is one of the more common validator errors.

4. Duplicating the same block across every page

An Article example copied unchanged onto ten different blog posts still points to the first post's headline and date — each page needs its own values, even when the structure is identical.

JSON-LD examples by schema type

Complete, copy-ready blocks for the schema types most sites actually need. Replace every value before publishing.

Article

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Your Article Title Here",
  "image": "https://yoursite.com/images/article-cover.jpg",
  "author": {
    "@type": "Person",
    "name": "Author Name"
  },
  "datePublished": "2026-07-04",
  "publisher": {
    "@type": "Organization",
    "name": "Your Site Name"
  }
}

Product

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Your Product Name",
  "image": "https://yoursite.com/images/product.jpg",
  "description": "A short, accurate description of the product.",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "49.00",
    "availability": "https://schema.org/InStock"
  }
}

Only add an aggregateRating block if your page shows real, visible reviews.

FAQPage

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Your question, exactly as shown on the page?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The answer, matching the visible text on the page."
      }
    }
  ]
}

Recipe

{
  "@context": "https://schema.org",
  "@type": "Recipe",
  "name": "Your Recipe Name",
  "image": "https://yoursite.com/images/recipe.jpg",
  "author": {
    "@type": "Person",
    "name": "Author Name"
  },
  "prepTime": "PT15M",
  "cookTime": "PT30M",
  "recipeYield": "4 servings",
  "recipeIngredient": ["2 cups flour", "1 tsp salt"]
}

Organization

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Your Company Name",
  "url": "https://yoursite.com",
  "logo": "https://yoursite.com/logo.png",
  "sameAs": [
    "https://www.linkedin.com/company/yourcompany",
    "https://twitter.com/yourcompany"
  ]
}

BreadcrumbList

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://yoursite.com" },
    { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://yoursite.com/blog" }
  ]
}

Which schema type fits your page

A quick reference for matching your content to the right example above, before you copy anything.

Generate your JSON-LD in seconds — free

If editing raw JSON still feels error-prone, the Rebrixe Schema Generator builds the same structures shown above from a simple form — Article, Product, FAQPage, Recipe, and more — with nothing to type by hand and nothing to debug.

Frequently asked questions