What JSON-LD is, and why Google recommends it

Three ways to write structured data

Schema.org markup can go into a page in three ways. Microdata adds attributes such as itemscope, itemtype and itemprop to the HTML elements you already have. RDFa does the same job with its own set of attributes, more expressive and more verbose.

Both tie the data to the template. Redesign a page and you can break the markup without noticing. Add a field and you have to remember to annotate it.

JSON-LD, short for JavaScript Object Notation for Linked Data, avoids that by keeping the data in a block of its own.

What it looks like

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "Do you take reservations?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Yes. Book by phone or on our contact page."
      }
    }
  ]
}
</script>

The type application/ld+json tells the browser this is data, so it never runs it as JavaScript. Google reads the block wherever it sits, in the <head> or the <body>. It can also read JSON-LD that JavaScript adds after the page loads, but a block the server writes into the HTML is the safer choice, because not every crawler runs scripts.

Why Google recommends it

Google's structured data documentation says to use JSON-LD if your site's setup allows it. The reasons are practical.

It is separate from the layout. You can redesign the template, move blocks around or change the theme, and the markup stays as it was.

It is easy to test. The block is self-contained. Paste it into a validator and the errors show up straight away.

One page can describe several things. You can use several script blocks, or one block with an @graph array that lists the items side by side and links them by @id:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "Example Ltd"
    },
    {
      "@type": "WebPage",
      "@id": "https://example.com/about#page",
      "publisher": { "@id": "https://example.com/#org" }
    }
  ]
}

The server can write it. It is text, so the CMS can build it while it renders the page. Nothing has to run in the visitor's browser.

Common types

Testing your markup

Google's Rich Results Test at search.google.com/test/rich-results takes a URL or a code snippet. It shows which Google rich results the markup can qualify for, with errors and warnings. It only checks the types Google supports.

The Schema Markup Validator at validator.schema.org checks any Schema.org markup against the vocabulary, whether Google uses that type or not. I use both. The first tells you what Google makes of it, the second whether it is valid at all.

How AI Boost for Joomla writes it

AI Boost for Joomla writes all its Schema.org output as JSON-LD. Each indexable page gets one <script type="application/ld+json"> block with an @graph, built on the server and placed before </head>. You never write or edit the JSON yourself, and noindexed pages get no block at all.

It builds the block from what you enter on the Structured Data screen, such as organisation name, address, phone and social profiles, and from the page being served. That covers the article, its author and dates, FAQ questions found in the page's headings or, with the YOOtheme extension, in a YOOtheme accordion whose every title is a question, and event details where you have switched events on.

A field you leave empty stays out of the markup. So how well a page does in the Rich Results Test depends on how much you fill in. Passing the test means the markup qualifies, and Google still decides whether to show anything.