Fixing Missing or Incomplete JSON-LD

What coverage actually means

JSON-LD coverage is not a count of pages with a <script type="application/ld+json"> block. A page can have one and still say almost nothing. The Agent Readiness Audit reviews coverage as four separate questions, and a gap in any of them is worth fixing:

1. Breadth. Does every template that describes something real, such as a service, a product, a location, a person or an article, output structured data?
2. Type. Is the main entity described with a type that matches what the page is about, rather than a generic WebPage or a copied Article?
3. Depth. Are the properties that hold the useful facts present: price, address, opening hours, author, dates, area served?
4. Connection. Do the page, its main entity and the organisation behind the site link together, so a machine can see they belong to one business?

Structured data states in a fixed vocabulary what the visible page already says. It does not replace the visible text, and it must match it. Its value for AI crawlers is that it removes ambiguity: a price marked as a price, in a stated currency, attached to a named service, is harder to misread than a number in a paragraph.

Which types suit which pages

Use the most specific schema.org type that honestly describes the page's main subject. The table below covers the templates most small-business sites have. Every page can also carry a WebPage (or a more specific kind such as AboutPage or ContactPage) and a BreadcrumbList.

Schema.org is broader than what Google shows as rich results, and the two should not be confused. Google removed HowTo rich results in 2023 and limits FAQ rich results to well-known authoritative government and health sites, but HowTo and FAQPage remain valid schema.org types that describe content accurately. Mark content up because the description is true, not only because a search feature exists for it.

Describe the business once, refer to it everywhere

The most common coverage gap is not a missing page type but a missing publisher. Each template outputs its own small block, and none of them says which business the page belongs to. The fix is to describe the organisation, and the website, once in full, give each a fixed @id, and have every other page refer to those identifiers.

• Describe the Organization or LocalBusiness fully on the home page or the about page: legal or trading name, logo, address, telephone, official profiles.
• Give it an identifier based on your canonical home page address, such as https://www.example.co.uk/#organization, and never change it.
• On every other page, point to it with "publisher", "provider", "brand" or "isPartOf" as appropriate, using only {"@id": "…"}.
• Do the same for the WebSite, and point each WebPage at it with isPartOf.

How identifiers work in detail, and the problems that occur when references point to nothing, are covered in the schema references guide. For coverage, the point is simply that every template should connect to the same business rather than float on its own.

A complete block for a service page

Service pages are the template most often left bare, and often the one that answers the questions people put to AI assistants: what does it cost, where do they work, who provides it. This example for a fictional drainage company shows a service page described fully and connected to the business.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://www.example.co.uk/services/cctv-drain-survey/#webpage",
      "url": "https://www.example.co.uk/services/cctv-drain-survey/",
      "name": "CCTV drain surveys in Leeds and Wakefield",
      "isPartOf": { "@id": "https://www.example.co.uk/#website" },
      "mainEntity": { "@id": "https://www.example.co.uk/services/cctv-drain-survey/#service" },
      "breadcrumb": { "@id": "https://www.example.co.uk/services/cctv-drain-survey/#breadcrumb" }
    },
    {
      "@type": "Service",
      "@id": "https://www.example.co.uk/services/cctv-drain-survey/#service",
      "name": "CCTV drain survey",
      "serviceType": "Drain inspection",
      "description": "Camera inspection of domestic drains with a written report and recorded footage.",
      "provider": { "@id": "https://www.example.co.uk/#organization" },
      "areaServed": [
        { "@type": "City", "name": "Leeds" },
        { "@type": "City", "name": "Wakefield" }
      ],
      "offers": {
        "@type": "Offer",
        "price": "145.00",
        "priceCurrency": "GBP",
        "description": "Standard domestic survey, including VAT"
      }
    },
    {
      "@type": "BreadcrumbList",
      "@id": "https://www.example.co.uk/services/cctv-drain-survey/#breadcrumb",
      "itemListElement": [
        { "@type": "ListItem", "position": 1, "name": "Services", "item": "https://www.example.co.uk/services/" },
        { "@type": "ListItem", "position": 2, "name": "CCTV drain survey" }
      ]
    }
  ]
}
</script>

The organisation and website are not repeated here; they are described on the home page and referenced by identifier. Every value in the block, including the price and the towns served, must also appear in the visible text of the page. If the price changes, the markup must change with it, which is a strong argument for generating it from the same data the page uses.

The gaps audits find most often

Building a coverage matrix

Coverage is a template problem, so measure it by template. A simple spreadsheet is enough.

1. List each template down the side: home, service, location, product, category, article, about, contact, team, event.
2. For each, take one representative URL and fetch the raw HTML, so you see what non-rendering crawlers see:

   curl -s https://www.example.co.uk/services/cctv-drain-survey/ \
     | grep -c 'application/ld+json'

3. Paste the URL into the Schema Markup Validator at validator.schema.org, which checks against the full schema.org vocabulary, and note every type found and its properties.
4. Where Google offers a rich result for the type, also run the Google Rich Results Test, which checks Google's required and recommended properties.
5. Add columns for the four questions: breadth, type, depth and connection. Mark each cell as done, partial or missing.

Compare the validator results with what you see in the browser inspector. Markup that appears in the inspector but not in the curl output is being added by JavaScript, and should be moved to the server. The finished matrix becomes your work list and, later, your regression check.

The fix, step by step

What JSON-LD will and will not do

It is worth being clear about expectations. Structured data is a way of stating facts precisely. It does not make a thin page useful, and it does not oblige any search engine or AI system to show or cite your page.

• Google uses structured data to understand pages and to decide eligibility for rich results, subject to its own guidelines and quality systems.
• AI providers say little publicly about how they use structured data. Markup that is present in the server HTML and matches the visible text is, at worst, harmless to them and, at best, a clear statement of your facts.
• Your own tools can use it too. Well-formed markup makes it easier to feed product data, build internal search or check that prices on the site are consistent.