JSON-LD Implementation for iGaming Websites

Why JSON-LD

Google supports three formats for structured data and says "all 3 formats are equally fine for Google, as long as the markup is valid." It still recommends JSON-LD "if your site's setup allows it", because it is "the easiest solution for website owners to implement and maintain at scale." On gambling sites, where templates are shared across many brands and markets, that maintainability matters more than anything else.

JSON-LD itself is a W3C standard. Version 1.1 became a W3C Recommendation on July 16, 2020, together with its processing algorithms and framing specifications.

Step 1: decide what each template describes

Before writing code, list templates and the entity each one is about. A home page describes the site and the organization. A help article describes an Article and its trail. A game page describes a WebPage whose main entity is a Game. The table in the entity SEO guide gives a starting map. If a template has no clear entity, it may not need markup beyond WebPage and BreadcrumbList.

Step 2: one graph per page

A single @graph holding every node on the page, linked by @id, is easier to read and test than several unrelated blocks. Google's general guidelines allow both nesting and separate items, and note that @id can link related items. Keep the shared nodes, such as the Organization and WebSite, identical on every page, and generate them from one place in the code.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://verdantcrown.example/#org",
      "name": "Verdant Crown Casino",
      "url": "https://verdantcrown.example/",
      "logo": "https://verdantcrown.example/media/logo-512.png",
      "sameAs": [
        "https://social.example/verdantcrown"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://verdantcrown.example/#website",
      "name": "Verdant Crown",
      "url": "https://verdantcrown.example/",
      "publisher": {
        "@id": "https://verdantcrown.example/#org"
      }
    },
    {
      "@type": "WebPage",
      "@id": "https://verdantcrown.example/about/#page",
      "url": "https://verdantcrown.example/about/",
      "name": "About Verdant Crown",
      "isPartOf": {
        "@id": "https://verdantcrown.example/#website"
      },
      "about": {
        "@id": "https://verdantcrown.example/#org"
      }
    }
  ]
}

Step 3: placement and rendering

The script block can sit in the head or the body. What matters is that the markup describes the page it is on; Google's guidelines say to "Put the structured data on the page that it describes, unless specified otherwise by the documentation."

Server-side rendering is the simplest and most predictable. If your platform adds JSON-LD with JavaScript, Google says it "can understand and process structured data that's available in the DOM when it renders the page." Test such pages with the Rich Results Test using the page URL, not pasted code: Google recommends "the URL input instead of the code input" because code input has JavaScript limitations.

Step 4: write values that survive

• Escape the closing tag. A string containing </script> ends the block early. Encode < as \u003c when you serialize.
• Use real JSON. No comments, no trailing commas, double quotes only.
• Dates in ISO 8601. Add a time zone offset to date-times. Google's Article documentation recommends time zone information; otherwise it uses Googlebot's.
• Absolute https URLs. Relative URLs and http links are common causes of confusion.
• Exact type names. Organization, not Organisation; WebSite, not Website.
• Plain text in text fields. Strip HTML from names and descriptions before you serialize them.

Step 5: test in three passes

1. Syntax. Does the JSON parse? Our workbench reports the line and column.
2. Vocabulary and Google requirements. The Schema Markup Validator checks Schema.org usage; Google's Rich Results Test checks Google feature requirements.
3. Truth. Compare every value with the visible page. No tool does this for you.

Errors and their fixes are listed in structured data validation errors.

Step 6: keep it working

Template changes break markup more often than anything else. Add a test to your build that parses every page's JSON-LD and fails on errors. SchemaReel does this for its own pages: every page's graph runs through the same checklist as the workbench before the site can be published. Then watch the rich result reports in Search Console after each release.

Sources

How SchemaReel chooses, reads and dates its sources is set out on the data sources page.

1. Google Search Central, Introduction to structured data markup, last updated December 10, 2025.
2. Google Search Central, General structured data guidelines, last updated July 10, 2026.
3. Google Search Central, Generate structured data with JavaScript, last updated December 10, 2025.
4. Google Search Central, Article structured data, last updated September 8, 2026.
5. W3C, JSON-LD 1.1 Specifications are W3C Recommendations, July 16, 2020.