JSON-LD Examples: Organization, BlogPosting, and Breadcrumb Markup

Check what your CMS already outputs before pasting another schema snippet into the page.

You may already have an Organization from the site layout, a BlogPosting from the article template, and breadcrumbs from a plugin. Adding a second version can leave the same publisher with two names or the article with two different dates.

This guide uses three JSON-LD examples to show the implementation: Organization, BlogPosting, and BreadcrumbList. The examples describe a fictional company and article. Replace their values with facts from your own site, then check the public output after deployment.

For the broader role of structured data in AI discovery, see our LLMs.txt, robots.txt, and structured data comparison. Here, we will work through the code and the checks.

What does a JSON-LD script contain?

JSON-LD is a JSON format for linked data. For website schema markup, you normally put a JSON object inside a script whose type is application/ld+json. The browser does not execute that block as application JavaScript.

These fields appear throughout the examples:

An ID can include a fragment such as #organization. It identifies the entity; it does not require a visible element with that HTML ID. The W3C JSON-LD specification explains node identifiers and references.

Choose stable IDs before spreading the markup across templates. In the examples, the homepage URL with a #organization fragment identifies the publisher. The article gets its own ID ending in #blogposting.

1. Organization JSON-LD example

Use Organization to describe the company publishing the site. Google's Organization guidance discusses placing this information on the homepage and using accurate organization details.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.com/#organization",
  "name": "Example Workflow",
  "url": "https://example.com/",
  "logo": "https://example.com/images/logo.png"
}
</script>

Replace the company name, homepage, and logo URL. Check that the logo exists and represents the organization. Do not copy an address, founder, or registration identifier from another site's template.

If you add sameAs profiles, use pages that identify this organization. A link to an article mentioning the company serves a different purpose from the company's official profile.

This is a small starting example. Add other properties only when they apply and you can keep them accurate. More fields create more facts to maintain.

Keep one identity across templates

Use the same organization ID wherever the same company appears as publisher. A homepage and an article can describe that organization without creating a new identity for each route.

Repeating consistent entity information across different pages is normal. The problem to investigate is conflicting descriptions, such as different company names or logos for the same publisher on one page.

2. BlogPosting JSON-LD example with a connected publisher

Use BlogPosting for an actual blog article. Google's Article documentation covers Article, NewsArticle, and BlogPosting, including author, headline, image, and date information.

This example contains two nodes in one graph. The BlogPosting refers to the Organization through publisher.@id, and the same graph supplies that organization's details.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#organization",
      "name": "Example Workflow",
      "url": "https://example.com/",
      "logo": "https://example.com/images/logo.png"
    },
    {
      "@type": "BlogPosting",
      "@id": "https://example.com/blog/launch-checklist#blogposting",
      "url": "https://example.com/blog/launch-checklist",
      "headline": "A practical launch checklist",
      "description": "Checks to complete before a product launch.",
      "image": "https://example.com/images/launch-checklist.jpg",
      "datePublished": "2026-11-06T09:00:00+05:30",
      "dateModified": "2026-11-06T09:00:00+05:30",
      "author": {
        "@type": "Person",
        "name": "Mira Shah",
        "url": "https://example.com/authors/mira-shah"
      },
      "publisher": {
        "@id": "https://example.com/#organization"
      },
      "mainEntityOfPage": "https://example.com/blog/launch-checklist"
    }
  ]
}
</script>

The company, author, dates, images, and article in this code are placeholders. The snippet is not a description of the SavageAudit guide you are reading.

Keep the article URL and identity aligned with the intended canonical page. The @id identifies the article entity, while url gives its page location. The publisher reference points to the organization rather than to a second article.

Replace dates and authors from the actual article

Use the real publishing date. Update dateModified when the article changes meaningfully, and keep it consistent with the page's information. A deployment that changes nothing in the article does not need a new article update date.

Use the actual author or publishing organization. A team byline does not become an individual person because a template contains @type Person. Choose the type and name that reflect the real attribution.

The image should represent this article and be accessible. Check the final image URL after CMS transformations; a valid-looking path in a snippet does not establish that the file exists.

3. BreadcrumbList JSON-LD example

For this fictional article, assume the page offers the navigation trail Home, Blog, A practical launch checklist. The markup describes that path.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "@id": "https://example.com/blog/launch-checklist#breadcrumb",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://example.com/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "A practical launch checklist",
      "item": "https://example.com/blog/launch-checklist"
    }
  ]
}
</script>

The positions make the order explicit. Check the names and destinations against the page's navigation. Do not invent a category level that visitors cannot use.

Google's BreadcrumbList guide documents its properties and examples. A breadcrumb path expresses the site's hierarchy; splitting a URL at each slash is not enough to decide the right trail.

You can keep this in its own script or include the node in a larger graph. Choose the arrangement your templates can maintain. One large graph is not inherently a better result than consistent linked nodes in separate scripts.

Where to add the markup

First inspect the initial page source and the rendered page. Identify whether the CMS, theme, SEO plugin, or application template already owns these fields.

Make the change in that existing source where possible. A second hand-written script can go stale when the CMS updates the title, author, or canonical URL.

Server-delivered JSON-LD makes it available to clients that read the initial HTML. JavaScript-generated structured data also needs testing in the rendered output. Our JavaScript SEO checklist covers the delivery and rendering investigation.

If the application constructs JSON from CMS text, use proper JSON serialization and safe HTML embedding. Quotes and special characters in a headline must not break the script. Inspect the deployed result rather than assuming that valid source code guarantees valid output for every article.

How to validate JSON-LD without confusing the checks

Use three distinct checks, then inspect the live page.

Google's structured-data testing page distinguishes the Schema Markup Validator from the Rich Results Test. Use the result's actual scope when reporting it.

For each example, extract the JSON between the script tags and check its syntax. Then run the markup through the appropriate validators. After deployment, test the public URL as well as the code you intended to publish.

Review errors in context. A missing required property for a supported Google feature needs a different response from an optional recommendation. An unsupported type not appearing in a Google feature report does not by itself establish that its Schema.org markup is invalid.

Google's structured-data policies also require accurate, relevant information. Correct punctuation cannot make a fabricated rating or a false author acceptable. Even correctly marked-up pages have no guaranteed rich-result appearance.

A real check of our initial HTML

On 6 November 2026, we fetched three public SavageAudit pages and parsed their application/ld+json blocks. We counted top-level nodes inside @graph as separate nodes, rather than assuming one script equals one entity.

The sitemap article included Organization, WebSite, BreadcrumbList, WebPage, BlogPosting, and FAQPage nodes. The pricing page's inspected blocks described Organization and WebSite.

Those counts show what our server response contained at the time. They do not score the pages. Two blocks can describe the intended entities correctly; six blocks can still contain inaccurate properties.

This check established JSON syntax and a type inventory. We did not treat it as a Schema Markup Validator result, a Rich Results Test result, or proof that Google displays an enhancement.

For the three code examples in this guide, we also parsed the JSON, checked the article's publisher reference against its organization node, and checked the breadcrumb positions and final destination. These local checks catch specific mistakes. Run the appropriate external validation on your own replaced values before releasing them.

Check the deployed page before closing the task

Open the anonymous public URL after deployment. Confirm that the headline, author, article dates, publisher, and breadcrumb destinations agree with the page. Look for competing descriptions left by another plugin or template.

Test a second article with different text and attribution. A snippet that works for one fixed example can still fail when the title contains quotes or the CMS leaves a field empty.

Keep the result specific: the URL checked, the markup found, the tool used, and the remaining issue. That gives someone enough information to repeat the check after the next template change.