Dataset Schema

Required vs Recommended Properties

Per Google's Dataset structured data documentation, the actual required field list is short, but "short" does not mean "skip everything else." The recommended fields are what separate a page that technically validates from a page that actually competes for visibility in a crowded Dataset Search index.

How to Detect It

Check current state before you touch anything:

1. Google's Rich Results Test (search.google.com/test/rich-results). Paste the URL, look specifically for a "Dataset" item type in the results. If it says no structured data detected, or detects a different type like WebPage, that confirms the gap.
2. Schema Markup Validator (validator.schema.org). This is the general schema.org validator, not Google-specific, useful for checking the raw JSON-LD is syntactically correct and all nested types (DataDownload, Organization) resolve properly.
3. Search Console. Once markup is live, the Enhancements section eventually reports Dataset-eligible pages and any errors Google's crawler hit. This takes time to populate, don't expect same-day feedback.
4. Check Dataset Search directly. Search your dataset's name or a close variant at datasetsearch.research.google.com. If it's not indexed after a few weeks of valid markup and a few crawls, something in the implementation is likely still wrong, or the page hasn't been recrawled yet.

How to Implement It

Add a JSON-LD script block to the dataset's landing page, in the head or body. Here's a working structure with the pieces that actually matter, not a stub:

<script type="application/ld+json">
{
  "@context": "https://schema.org/",
  "@type": "Dataset",
  "name": "2025 County Air Quality Readings",
  "description": "Hourly PM2.5 and ozone readings collected from 42 monitoring stations across the county, January through December 2025. Includes station metadata and calibration notes.",
  "url": "https://example.gov/data/air-quality-2025",
  "sameAs": "https://doi.org/10.1234/example-air-quality-2025",
  "identifier": "https://doi.org/10.1234/example-air-quality-2025",
  "keywords": ["air quality", "PM2.5", "ozone", "environmental monitoring"],
  "creator": {
    "@type": "Organization",
    "name": "County Environmental Health Department",
    "url": "https://example.gov"
  },
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "isAccessibleForFree": true,
  "temporalCoverage": "2025-01-01/2025-12-31",
  "spatialCoverage": {
    "@type": "Place",
    "name": "Example County, State"
  },
  "includedInDataCatalog": {
    "@type": "DataCatalog",
    "name": "County Open Data Portal",
    "url": "https://example.gov/data"
  },
  "distribution": [
    {
      "@type": "DataDownload",
      "encodingFormat": "CSV",
      "contentUrl": "https://example.gov/data/air-quality-2025.csv"
    },
    {
      "@type": "DataDownload",
      "encodingFormat": "application/json",
      "contentUrl": "https://example.gov/data/air-quality-2025.json"
    }
  ],
  "version": "1.2"
}
</script>

Notes on that example: the distribution field is an array because most real datasets ship in more than one format, don't force yourself into a single DataDownload if you offer CSV and JSON both. The contentUrl inside each DataDownload has to actually resolve, a 404 or a redirect chain there is a fast way to get flagged during validation.

Once it's live, run it through the Rich Results Test before you move on. Fix any critical errors it flags. Warnings for missing recommended fields are worth addressing but won't block eligibility the way an error will.

Common Mistakes

The most frequent failure isn't bad syntax, it's scope. Teams apply Dataset schema to a category page listing twelve different datasets, or to a blog post that references a dataset without hosting one. Dataset schema belongs on the specific landing page for one specific dataset. If you've got a catalog of datasets, that catalog page gets DataCatalog schema, and each individual dataset gets its own Dataset markup on its own URL.

Second most common: no distribution, or a distribution with a broken or paywalled contentUrl. Google's guidance is explicit that this field matters for real usability, a Dataset entry that doesn't actually lead to downloadable data is a dead end for anyone who finds it through Dataset Search.

Third: missing or vague license. Anyone doing serious research or building on top of open data needs to know the reuse terms before they touch the file. If you don't specify a license, plenty of legitimate users will just skip your dataset rather than guess at what they're allowed to do with it.

Fourth: treating this as a one-time task. Datasets that get periodically updated need their markup updated too, stale temporalCoverage or a version that never changes tells both Google and researchers this page might not reflect current data.

What Good Looks Like

A well-marked-up dataset page has a specific, human-written description in the 50 to 5000 character range, a creator with a real identifier, a license that's unambiguous, at least one distribution with a contentUrl that actually downloads a file, and coverage fields (temporal, spatial) filled in accurately rather than left blank. It validates clean in the Rich Results Test with zero errors, shows up in Dataset Search within a few weeks of being crawled, and gets kept current every time the underlying data changes. That's the bar, not "the JSON-LD is present," but "someone could find this, understand what it is, trust the license, and actually get the file."

FAQ