usageInfo: the JSON-LD property that points AI systems ...

The Mega Analyzer row reads schema:CreativeWork.usageInfo URL (AI-usage-rights pointer), and it appears only on pages that already carry Article, BlogPosting, NewsArticle or CreativeWork JSON-LD. What it is really asking is whether the structured data you already publish for authorship and dates also tells a reader, human or machine, where your usage terms live. Most sites answer that question per bot in robots.txt and never per work, and that gap is what the row points at.

What the check actually tests

One gate, then one pattern match.

The gate is the type walk. The analyzer parses every <script type="application/ld+json"> block on the page and collects every @type it finds, at any depth, so a CreativeWork nested inside hasPart counts the same as a top-level BlogPosting. If any collected type name contains Article, BlogPosting, NewsArticle or CreativeWork (so TechArticle and ScholarlyArticle qualify too), the row is emitted. If none does, there is no row at all: a page whose only types are LocalBusiness and WebSite never sees this check, pass or fail. A JSON-LD block that fails to parse contributes no types, which is one more reason to run your markup through a validator first.

The match is deliberately literal. The detector runs a case-insensitive regular expression over the raw fetched HTML looking for "usageInfo": in either quote style, with optional whitespace before the colon, or for the escaped form \"usageInfo\" inside an inline JSON string. That is the whole test. It does not confirm the property sits on the Article node rather than some other node, it does not fetch the target URL, and it does not check that the value is a URL at all. An inline script that happens to contain the quoted key trips it just as well as a correct declaration does.

The title is the same in both states. When the key is present, the detail reports that the JSON-LD declares a usageInfo URL and calls it Schema.org's canonical AI-usage-rights pointer. When it is absent, the detail reads: "Add "usageInfo": "https://yourdomain.com/ai-usage" to your Article / BlogPosting / CreativeWork JSON-LD. Schema.org treats this as the canonical pointer to AI usage terms; complements ai.txt for sites with structured article data." One caution on that wording: schema.org's definition never uses the word AI. The label is the analyzer's reading of a property written for any consumer of the work, and I think it is a fair reading, but it is a reading.

Severity is info. The unmet state shows a blue marker instead of a red one. Two things still happen, though: the row costs one weighted point in the crawl score (critical rows weigh two, everything else one), and it is listed with the crawl warnings and carried into the AI fix prompt as a [warn] line. Info means never red. It does not mean never counted.

Why it matters

schema.org defines usageInfo on CreativeWork as further information about how the work may be used, and the definition is unusually specific about scope: it applies "both to works that are freely available and to those that require payment or other transactions," and it can point at "community expectations on preferred linking and citation conventions, as well as purchasing details." The expected value is a URL or another CreativeWork, and it is meant to sit alongside license, which schema.org defines more narrowly as "a license document that applies to this content, typically indicated by URL." license says which license. usageInfo says how you would like the work used, including the parts a license does not cover.

That per-work scope is what makes it different from everything else in the stack. robots.txt and Spawning's ai.txt speak per bot or per media type: a user agent may or may not fetch a path, and images or text may or may not be used for training. The Content-Signal robots.txt directive speaks per site or per path, with three values, search, ai-input and ai-train, each yes or no. The TDM Reservation Protocol, a W3C Community Group report rather than a Recommendation, reserves text and data mining rights per response or per location, with a tdm-policy URL for the terms. The IETF AI Preferences working group is standardizing a vocabulary and ways to attach it, again through robots.txt and HTTP header fields. All of those are site plumbing. None of them ride inside the one JSON object that describes the article itself.

usageInfo does. Google lists author, datePublished, dateModified, headline and image as the recommended properties for Article structured data, which is why most CMS SEO plugins emit that block already. Any parser reading it for a byline is one key away from a URL where your terms live, at the moment it decides whether and how to quote the passage. Note what I am not claiming: Google's Article documentation does not mention usageInfo, and no AI vendor I can cite has published that its retriever honors it. Where Google does document reading a schema.org rights property, it is license on ImageObject, which it requires for the Licensable badge in image results when the rights travel in structured data rather than IPTC metadata. usageInfo is the same kind of signal extended to text, with the honoring still ahead of the publishing.

So the value is consistency, not enforcement. The contentsignals.org policy text says plainly that robots.txt files "express your preferences" and that "courts and regulators may conclude" they impose no enforceable obligations, and the same is true of a JSON-LD key. What a usageInfo URL buys you is one authoritative place where a person or a program can read your terms, provided it agrees with license, with ai.txt and with what robots.txt allows. When those disagree you have not added a signal. You have added a contradiction, and a program that meets a contradiction gets to pick which side to believe.

When I wrote this, the BlogPosting layout on this site did not carry the property either, so the row was blue here too. Nobody had a reason to ask for it until a check did.

How to fix it

1. Write the page before the pointer. Publish a plain HTML page at a stable path. The ai.txt Generator writes Policy: https://yourdomain.com/ai-policy into every file it emits, so /ai-policy/ is the path of least resistance; /ai-usage/ or /usage-policy/ work fine if you use the same one everywhere. State what is allowed (indexing, retrieval and quotation with attribution and a link back, summarization), what is not (training without a license, reproduction beyond a stated length), the attribution format you want, a licensing contact, and a last-updated date. Keep it server-rendered. A policy that only appears after JavaScript runs is invisible to the crawlers it addresses.

2. Add the property to the article node. In the shape this site's own post layout uses:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/blog/your-post/#blogposting",
  "headline": "Your post title",
  "datePublished": "2026-09-21T09:00:00-06:00",
  "dateModified": "2026-09-21T09:00:00-06:00",
  "author": {"@id": "https://example.com/#author"},
  "publisher": {"@id": "https://example.com/#organization"},
  "mainEntityOfPage": {"@id": "https://example.com/blog/your-post/#webpage"},
  "isPartOf": {"@id": "https://example.com/#website"},
  "url": "https://example.com/blog/your-post/",
  "inLanguage": "en",
  "usageInfo": "https://example.com/ai-policy/",
  "license": "https://creativecommons.org/licenses/by-nc/4.0/"
}

Include license only where a formal license actually applies. If your terms are "ask us," leave license out and let the policy page say so. A Creative Commons URL you did not mean is a grant you cannot take back.

3. Cover the rest of the site. WebSite and WebPage are CreativeWork subtypes, so the same property is valid on the site-wide node most layouts already emit:

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "@id": "https://example.com/#website",
  "url": "https://example.com/",
  "name": "Example",
  "usageInfo": "https://example.com/ai-policy/"
}

The analyzer will not show this row on a page without Article-family types, so this step is for readers, not for the score.

4. Make the other layers agree. Regenerate ai.txt with the ai.txt Generator so its Policy: and License: header lines match the URLs above. The generator also writes comment lines, trimmed here:

Contact: mailto:licensing@example.com
License: https://creativecommons.org/licenses/by-nc/4.0/
Policy: https://example.com/ai-policy

User-agent: *
Allow: /

User-agent: GPTBot
Disallow: /

Then add the Content-Signal line to robots.txt in the contentsignals.org form and keep the per-bot rules consistent with it. OpenAI documents GPTBot as the crawler that makes its foundation models "more useful and safe" and OAI-SearchBot as the one that surfaces sites in ChatGPT search, so a policy of no training and yes to search disallows the first and leaves the second alone:

Content-Signal: search=yes, ai-input=yes, ai-train=no

User-agent: GPTBot
Disallow: /

User-agent: OAI-SearchBot
Allow: /

Finally, list the policy page under a ## Policies heading in llms.txt so the third discovery surface points at the same URL.

5. Audit the whole stack at once. Run the AI Posture Audit on the article URL. It fetches robots.txt, ai.txt at the root and under /.well-known/, the page's meta robots and the X-Robots-Tag header, then lays the allow and disallow signals out per bot and highlights each disagreement. Re-run the Mega Analyzer and the row should turn green. If it does not, look at the raw HTML the analyzer fetched, not the DOM after your scripts ran, and search for usageInfo. A key written into the page by a script the browser loads from a separate file never reaches the detector, and neither does one behind a bot challenge page.

When to leave it alone

Skip it when the page has no Article-family JSON-LD. The row will not appear, and adding BlogPosting markup to a motel's rooms page just to carry a pointer creates a type mismatch that costs more than the pointer earns. Put usageInfo on the WebSite node if you want it there, and accept that the analyzer stays silent.

Skip it when you are not going to write the policy page. The detector does not follow the URL, so a pointer to a 404, or to a terms page that never mentions machine use, passes the row and helps nobody. Info severity exists so you can leave this blue without guilt.

Skip it for works you do not control. Syndicated articles, guest posts published under the author's own terms, and user-generated content are not yours to grant usage on. Declaring terms for them is a misstatement, not a signal.

And if a formal license already says everything you want said, license alone is enough. usageInfo is for the parts a license leaves open: citation format, a commercial contact, the difference between quoting and reproducing. If you have nothing to add, the blue row is telling the truth.

Fact-check notes and sources

Source: https://schema.org/usageInfo establishes the definition ("further information about a CreativeWork," applicable to free and paid works, covering "community expectations on preferred linking and citation conventions"), the expected types (CreativeWork or URL) and the domain (CreativeWork).
Source: https://schema.org/CreativeWork establishes that Article and NewsArticle are CreativeWork subtypes and that usageInfo and license are both CreativeWork properties.
Source: https://schema.org/license establishes the narrower definition, "a license document that applies to this content, typically indicated by URL."
Source: https://developers.google.com/search/docs/appearance/structured-data/article establishes Google's recommended Article properties (author, datePublished, dateModified, headline, image), the three supported types, and the absence of any mention of usageInfo.
Source: https://developers.google.com/search/docs/appearance/structured-data/image-license-metadata establishes that Google requires license on ImageObject for the Licensable badge and defines it as a URL to a page describing the license.
Source: https://www.w3.org/community/reports/tdmrep/CG-FINAL-tdmrep-20240202/ establishes the TDM Reservation Protocol (Final Community Group Report, 2024-02-02): tdm-reservation (0 or 1) and tdm-policy (URL) via HTTP header, HTML meta or /.well-known/tdmrep.json, referencing Article 4 of Directive 2019/790.
Source: https://datatracker.ietf.org/wg/aipref/about/ establishes the AI Preferences working group's deliverables (a vocabulary document and attachment documents covering robots.txt and HTTP header fields) and that technical enforcement is out of scope.
Source: https://contentsignals.org/ establishes the Content-Signal: robots.txt directive with search, ai-input and ai-train values, and the statement that robots.txt files express preferences rather than enforceable obligations.
Source: https://site.spawning.ai/spawning-ai-txt establishes Spawning's ai.txt as a root or /.well-known/ text file that declares per media type whether content may be used to train AI models, with no guaranteed enforcement.
Source: https://developers.openai.com/api/docs/bots establishes the stated purposes of GPTBot, OAI-SearchBot and ChatGPT-User.

usageInfo: the JSON-LD property that points AI systems to your usage terms