JSON-LD structured data: copy-ready examples you can test

By SEOgrinder · Published November 4, 2026 · 9 min read

Short answer: JSON-LD is a block of JSON inside a <script type="application/ld+json"> tag that describes a page to search engines, and it is the format Google recommends for structured data. Copy one of the two examples below, swap the example.com values for facts that are visible on your page, and check the result in Google's Rich Results Test. Valid code makes a page eligible for rich results; Google does not guarantee that they appear.

What is JSON-LD, and what does Google do with it?

Google defines structured data as "a standardized format for providing information about a page and classifying the page content" (Google). Most of the vocabulary comes from schema.org, and JSON-LD is one of three ways to write it down. The other two, Microdata and RDFa, add attributes to the visible HTML. JSON-LD keeps everything in one separate block, so you can add or repair it without touching the layout.

Google says all three formats are equally fine as long as the markup is valid and properly implemented. It still recommends JSON-LD when your setup allows it, because it is "the easiest solution for website owners to implement and maintain at scale" (Google).

What you can gain: Google writes that structured data "can enable search results that are more engaging to users", which it calls rich results. It keeps a gallery of supported features, among them Article, Breadcrumb, Event, Organization, Product and Recipe. One more point from Google's introduction: for how Search behaves, rely on Google's own documentation rather than on schema.org, which has more attributes and objects than Google Search needs.

Three rules from Google's general structured data guidelines apply before you write any code:

Describe the page the markup sits on, and only what visitors can see there.
Do not block pages that carry structured data from Googlebot with robots.txt, noindex or similar.
Fill in every required property of the type you use. Items that miss one "are not eligible for rich results".

Example 1: Organization markup for your start page

Google recommends putting Organization markup on your home page or on one page that describes the organization, such as an About page. You do not need it on every page (Google). The type has no required properties; Google recommends adding those that apply. Replace every value:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Example Bikes",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/images/logo.png",
  "description": "Example Bikes builds made-to-measure bicycles.",
  "email": "contact@example.com"
}
</script>

What the properties do, according to Google's page:

name: use the same name you use as your site name.
url: the address of your website, which helps Google identify the organization uniquely.
logo: at least 112 × 112 px, crawlable and indexable. It can help Google decide which logo to show in search results and knowledge panels.
description and email: optional details. Add address, contactPoint or sameAs (a profile page on another site) only if they apply to you.

If a more specific subtype fits, Google recommends it, for example OnlineStore for a shop or a subtype of LocalBusiness for a restaurant.

Example 2: Article and breadcrumbs on a blog post

Google understands several items on one page, whether you nest them or list them separately (Google). This example lists two items in a JSON array, each with its own @context, the pattern Google shows for individual items:

<script type="application/ld+json">
[
  {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": "How to choose a bicycle helmet",
    "image": [
      "https://www.example.com/photos/helmet-16x9.jpg",
      "https://www.example.com/photos/helmet-4x3.jpg",
      "https://www.example.com/photos/helmet-1x1.jpg"
    ],
    "datePublished": "2026-10-12T08:00:00+02:00",
    "dateModified": "2026-11-04T09:20:00+01:00",
    "author": [
      {
        "@type": "Person",
        "name": "Jane Doe",
        "url": "https://www.example.com/team/jane-doe"
      }
    ]
  },
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      { "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://www.example.com/blog" },
      { "@type": "ListItem", "position": 2, "name": "Cycling", "item": "https://www.example.com/blog/cycling" },
      { "@type": "ListItem", "position": 3, "name": "How to choose a bicycle helmet" }
    ]
  }
]
</script>

Article. Google accepts Article, NewsArticle and BlogPosting. It lists no required properties and recommends author, datePublished, dateModified, headline and image, to help Google "show better title text, images, and date information" (Google). Give dates in ISO 8601 with a time zone; without one, Google uses the time zone of Googlebot. List each author as its own entry with type, name and url. Keep the headline short, because "long titles may be truncated on some devices". For images, Google recommends several high-resolution files in the ratios 16x9, 4x3 and 1x1 that are relevant to the article, not logos.

Breadcrumbs. Here the rules are strict. A BreadcrumbList needs at least two ListItem entries, and each normally needs position, name and item (the address). Only the last entry may leave out item; Google then uses the address of the page itself (Google). Google recommends a typical user path rather than a copy of the URL structure, and lists the feature as available on desktop. Our reading of the guidelines: show the same trail on the page, because markup for things readers cannot see is not allowed.

How do you test JSON-LD before and after publishing?

Rich Results Test (search.google.com/test/rich-results). Google calls it "the official Google tool for testing your structured data". The tool page takes either an address or pasted code, so you can test an example before it goes live. Fix critical errors first; Google says non-critical hints are optional for eligibility.
Schema Markup Validator (validator.schema.org). Google's testing page describes it as checking all schema.org-based markup "without Google feature specific warnings". Use it when no Google feature fits your type.
URL Inspection in Search Console after you deploy a few pages. Google asks you to confirm that the page is not blocked by robots.txt, noindex or a login; crawling a new page may take several days.
Rich result reports in Search Console. Google notes that markup can break after deployment through templates or serving problems, so look again after every template change (Google).

How we checked the two examples above on 4 November 2026: both blocks parse as valid JSON (Python's json module), and the properties follow Google's Organization, Article and Breadcrumb pages (last updated 8 September 2026). We did not paste them into Google's tool, so your first paste is the real test.

What JSON-LD does not do

It does not guarantee a rich result. Google writes: "Google does not guarantee that your structured data will show up in search results" (Google). Its reasons include that the algorithm may decide a plain text result fits better, and that markup can be wrong in ways the test cannot catch.
It is not a ranking promise. We found no statement on these Google pages that structured data lifts rankings. Google describes the benefit as eligibility for rich results. A structured data manual action, Google adds, removes that eligibility and "doesn't affect how the page ranks in Google web search".
AI answers do not need it. Google's guide to generative AI features says: "Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add" (Google). It still calls structured data a good idea for rich-result eligibility. SEOgrinder does not measure whether any AI system names your site.
FAQ markup no longer has a Google result. Google's changelog says: "This feature will no longer appear in Google Search starting May 7, 2026" (Google). Do not add FAQPage markup for that purpose.

Common mistakes: 5 JSON-LD errors

1. Marking up what nobody can see

Google's guideline: "Don't mark up content that is not visible to readers of the page." Google's own example: if the markup describes a performer, the page body must describe that same performer.

2. Broken JSON

One syntax slip breaks the whole block. Google's Unparsable structured data report in Search Console names error types such as a missing comma or closing brace, a missing colon and a bad escape sequence in a string, for example a stray backslash such as \q inside a text value. Google's tip for finding the slip: start from an empty object and add your code back piece by piece.

3. Missing required properties

Google says items without their required properties are not eligible for rich results. The usual case is breadcrumb entries without position, name or item.

4. A type that does not match the page

Google asks for the most specific applicable type. Its examples of irrelevant markup: a sports streaming site labeling broadcasts as local events, and a woodworking site labeling instructions as recipes.

5. Blocking the page or its images

Pages with structured data must stay open to Googlebot, and image URLs in the markup must be crawlable and indexable. A Disallow rule for your image folder can undo careful markup.

How does SEOgrinder check structured data?

SEOgrinder is our tool, and we build it. Scan a page, open the section "Page on Google" and look at two cards. "Structured data" lists the types found in JSON-LD and Microdata. "Field check" counts the entities and shows how many are "Invalid" (a required field is missing) or "Incomplete" (only recommended fields are missing), with the missing field names. In the task list these appear as "Structured data missing required fields", "Structured data incomplete", "No structured data" and, for code that cannot be parsed, "One broken structured data block". After a fix, press Check again.

Four limits. SEOgrinder reads the HTML your server delivers, so JSON-LD that only a script adds in the browser is not seen, although Google can read it. It reads JSON-LD and Microdata, not RDFa. It knows the required fields of a list of common types, not of every type. And it does not decide whether Google will show a rich result; the Rich Results Test does that preview.

We read our own pages the same way on 4 November 2026. This command prints 1 for an article and 0 for the start page:

curl -sS https://seogrinder.com/en/blog/seo-audit-checklist | grep -c 'application/ld+json'

The single block on the article holds a BlogPosting and a BreadcrumbList with three entries (SEOgrinder, Blog, the article). On the start page we have no structured data.

FAQ

Do I need structured data on every page?

No. Add a type only where one fits the page: Organization on the start page or About page, Article on posts. Many pages have no matching type, and that is fine.

Can I add JSON-LD with a plugin or with JavaScript?

Yes. Google says CMS users may find a settings page or plugin for structured data, and that Google can read JSON-LD injected by scripts (Google). Check the result with the Rich Results Test and remember that SEOgrinder only sees what the server delivers.

Does JSON-LD improve my rankings?

Google's pages describe rich-result eligibility, not better positions. Nobody can promise a ranking.

Your next step

Pick the page that matters most. Paste Example 1 or 2 into the Rich Results Test with your own values and fix what it flags. Publish, then scan the page with SEOgrinder, open "Page on Google" and read the "Field check" card. For the wider picture, our SEO audit checklist shows where structured data sits among the other checks.