Google Dataset Search (datasetsearch.research.google.com) is not a curated directory that dataset owners submit to. It is a crawler-driven index that reads schema.org Dataset structured data already published on a dataset’s own landing page. Nobody at Google reviews or approves individual datasets for inclusion — a dataset appears when its landing page is crawlable and carries correctly formed markup, and it stops appearing if that markup disappears or breaks. That single mechanical fact is the whole story behind why some deposited datasets show up in Dataset Search and others, described identically well in prose, never do.
For a researcher who has already done a Data Management Plan correctly — named a real repository, deposited with complete metadata, obtained a DataCite DOI — this is genuinely good news: in most cases the repository has already done the markup work, and discoverability follows automatically from metadata quality rather than requiring a separate SEO exercise. This guide explains the actual mechanism connecting the two, not a generic “how to submit your dataset” checklist.
How Google Dataset Search actually works
Per Google’s own documentation, Dataset Search is built entirely on structured data that already exists on the open web: Google’s crawler parses Dataset-typed markup written as JSON-LD, RDFa, or Microdata (JSON-LD is what Google recommends and what nearly every implementation in practice uses), and it also recognizes datasets described with the W3C’s DCAT vocabulary. There is no separate submission form, no application, and no fee. A dataset repository — or, less commonly, a single researcher’s own institutional page — marks up a landing page once, and any crawler, not only Google’s, can pick up the same metadata.
Two properties are functionally required for a page to be eligible at all: name and description (Google’s guidance specifies the description should be a genuine 50–5,000 character summary, not a placeholder). Everything else is recommended, not mandatory, but each recommended property is what actually makes a listing useful and trustworthy once it appears: creator, identifier (the DOI or other persistent identifier), license, isAccessibleForFree, distribution (the actual downloadable file or API endpoint), keywords, temporalCoverage, spatialCoverage, variableMeasured, funder, and citation. Dataset itself is a subtype of schema.org’s general CreativeWork, which is why it inherits properties like creator, publisher, and license rather than defining them from scratch.
Once markup is live, Google’s own Dataset Search help documentation describes the practical verification path: check the markup with the Rich Results Test, optionally submit a sitemap through Search Console to speed up crawling, and then wait for the page to be recrawled and indexed — there is no guaranteed timeline. It is worth being precise about what this markup does and doesn’t buy you: it is the only path into the Dataset Search index, but it is not a Google Search rich result in the classic sense, and correct markup is a necessary, not sufficient, condition — a page still has to be crawlable, public, and not blocked by robots.txt or a login wall.
The part a generic SEO guide won’t tell you: your repository’s metadata is usually already doing this
This is where CASRAI’s actual area of standards work becomes directly relevant, and it’s the reason this guide exists rather than restating Google’s documentation. Most researchers depositing through a DOI-registering repository never write a line of schema.org markup themselves — the repository generates it from the same DataCite metadata schema record created at deposit time, via one of two real mechanisms documented by DataCite:
- DataCite Content Negotiation. DataCite’s own content-negotiation service can return a DOI’s metadata directly in schema.org/JSON-LD format on request. A repository’s landing-page template calls this service (DataCite publishes a reference JavaScript implementation for exactly this) so that the schema.org markup embedded in the page is generated dynamically from the live DataCite record, rather than maintained as a separate, driftable copy.
- A published crosswalk. DataCite also documents a direct field-by-field mapping from its own metadata schema to schema.org properties, for repositories that prefer to generate the markup themselves rather than call the content-negotiation service at request time.
DataCite’s guidance is explicit that the underlying DOI has to be in the Findable state and its metadata’s resourceTypeGeneral has to be set to Dataset for this crosswalk to produce correct, complete schema.org output. In other words: a deposit with an incomplete or incorrectly typed DataCite record can still get a working DOI, but that same gap in the metadata is very often exactly what keeps the resulting schema.org markup thin or missing the properties (creator, license, distribution) that make a Dataset Search listing useful rather than a bare title.
Real repositories confirm this is how it works in practice, not just in specification documents. Dryad has published a technical account of adding schema.org markup driven by its own DataCite-registered metadata specifically so its datasets would surface in Google Dataset Search. Figshare’s own support documentation states plainly that a deposited item is included in Dataset Search results when it is (a) typed as a dataset item, (b) public, and (c) carries schema.org JSON-LD on its metadata HTML page — and recommends the Rich Results Test as the way to confirm the markup rendered correctly. Neither repository asks the depositing researcher to write any markup by hand; both generate it from the metadata already captured at deposit.
The practical conclusion: getting a dataset into Google Dataset Search is, for the overwhelming majority of researchers, not a separate task at all. It is a direct, mechanical consequence of two things this site already covers as core RDM practice — depositing in a repository that implements the DataCite–to–schema.org path (see How to Choose an Open Data Repository), and filling in the DataCite metadata record completely and correctly at deposit time, particularly title, creators/contributors, description, resource type, license, and related-identifier fields. Do those two things and markup, crawling, and (eventually) indexing follow without further action. Skip fields or deposit into a repository that never implemented the crosswalk, and no amount of separate “SEO for datasets” work compensates for it, because Google isn’t reading your dataset’s description page as prose — it’s reading the structured data behind it.
What a complete, discoverable dataset record actually looks like
Mapped from the recommended schema.org Dataset properties above onto the DataCite deposit fields that typically populate them:
- name / description — the DataCite
TitleandDescription. A generic title (“Dataset 1”) or a boilerplate description meets the technical minimum but defeats the point; Google’s guidance is explicit that the description should genuinely summarize the dataset’s content. - creator — DataCite
Creator, ideally each with an ORCID iD as a persistent identifier, so the person, not just the name string, is machine-linkable. - identifier — the DataCite DOI itself, the anchor the whole crosswalk depends on.
- license / isAccessibleForFree — DataCite
Rights. An empty rights field is one of the most common gaps in real deposits, and it is also one of the recommended properties Google’s documentation lists explicitly — leaving it blank doesn’t just create ambiguity for a human reader, it leaves a real, checkable field empty in the resulting markup. - distribution — the actual file or access URL the repository serves. This is why a dataset landing page that links out to the real files matters structurally, not just for human navigation.
- temporalCoverage / spatialCoverage / variableMeasured — drawn from DataCite’s
Date,GeoLocation, andSubject/description fields where present. These are the properties most often left blank in a minimal deposit, and also the ones that make a dataset genuinely findable by a researcher searching Dataset Search with a specific variable or region in mind rather than by exact title. - funder / citation — DataCite
FundingReferenceandRelatedIdentifier(a citation relation, or a link back to the paper the dataset supports). CASRAI’s own guide to writing a data availability statement covers the citation side of this same DOI from the article’s perspective.
Choosing a repository with this already built in
Not every repository implements the DataCite-to-schema.org crosswalk to the same depth, and CASRAI’s guide to choosing an open data repository covers the fuller decision (discipline-specific vs. generalist, trust certification via CoreTrustSeal, verifying a candidate repository through re3data). For discoverability specifically, the practical check is simple and doesn’t require reading a repository’s technical documentation in full: deposit a small test record (or find an existing public record from that repository), fetch its landing page, and look for a <script type="application/ld+json"> block containing "@type": "Dataset". If it’s there and populated, Google’s Rich Results Test will confirm it’s well-formed. If it’s absent entirely, that repository is not currently exposing deposits to Dataset Search regardless of how good the underlying metadata is — a gap worth knowing about before committing a DMP’s sharing commitment to it.
Frequently asked questions
Do I need to add schema.org markup myself?
Almost never, if you’re depositing through a repository that implements the DataCite crosswalk (Dryad, Figshare, Zenodo, and most DataCite-member repositories fall into this category). The exception is a dataset described on a standalone institutional or lab web page with no repository DOI behind it at all — in that case there is no DataCite record to crosswalk from, and the markup has to be written directly into that page’s HTML for Dataset Search to pick it up.
How long does it take to appear in Google Dataset Search after deposit?
Google does not publish a guaranteed timeline; its own guidance frames it as “wait for Google to recrawl and index” your page, optionally sped up by submitting a sitemap through Search Console. This is a normal web-crawling timeline, not a real-time process — a newly deposited dataset with a correctly typed record will not appear instantly.
Does having a DOI guarantee my dataset shows up?
No. A DOI proves the record is registered and persistently resolvable; it does not by itself guarantee the schema.org markup was generated or that the page is publicly crawlable. A DOI in Findable state with resourceTypeGeneral correctly set to Dataset, deposited into a repository that implements the crosswalk, on a public, crawlable landing page, is what actually produces eligibility.
Does correct markup or metadata affect how high a dataset ranks within Dataset Search?
Google’s published guidance covers eligibility and correctness, not a ranking algorithm for Dataset Search results, and no primary Google source describes one publicly. Treat complete metadata as what determines whether your dataset appears and how accurately it’s described, not as a lever for outranking other datasets.
Does this markup produce a Google Search “rich result” the way FAQ or How-To markup used to?
No — Dataset markup’s entire function is enabling inclusion in the dedicated Dataset Search index and tool, not a rich snippet within general Google Search results. It’s a different, narrower payoff than typical rich-result structured data, and one that’s specifically useful for research data rather than general web content.
My dataset repository doesn’t have a landing page at all — just a raw file download. Can it still be discoverable?
Not via this mechanism. Dataset Search indexes HTML landing pages carrying structured data; a bare file with no accompanying web page has nothing for a crawler to read. This is one of the practical reasons a proper dataset landing page, not just file storage, is part of what “depositing in a repository” means as a DMP commitment.
