What Is RSL and How Do You Implement It in 2026?

Q: Where does the RSL licence file go and how do crawlers find it?

Convention is a file named license.xml at the origin root, but the filename carries no meaning: what binds the document to your content is the association. RSL 1.0 defines five equivalent ones: a License: directive in robots.txt, an HTTP Link header with rel="license" and type="application/rsl+xml" , an HTML or inline , an element in an RSS item, and embedded metadata in a media or data file. Clients are expected to check every association point available to them.

Q: How is RSL different from Content Signals or a robots.txt disallow?

A robots.txt Disallow asks a crawler not to fetch at all, and says nothing about what happens to content it already has. Content Signals expresses a yes or no preference per usage category with no price attached. RSL keeps that vocabulary, its usage tokens explicitly include the Content Signals ones, and adds what the others leave out: payment terms, reporting obligations, warranties, a rights holder, and an optional protocol for a crawler to acquire a licence. The three layer rather than compete.

RSL states your licensing, payment and reporting terms as XML in a license.xml file, then points crawlers at it from robots.txt, HTTP headers, HTML and RSS. By the end of this page you will have a working licence file, per-page and syndicated terms, and a paid-crawl setup you can deploy.

Check Your Site Now Browse the Glossary

CategoryCrawler access, licensing & indexing StatusLaunched 2025, growing Maintained byRSL Collective Glippy checkMachine Readability (category 6)

RSL (Really Simple Licensing) is an XML vocabulary for declaring, in machine-readable form, how AI systems and other automated clients may use your content and what they owe you for it. A publisher writes one or more <content> scopes into a licence document, usually served at /license.xml, and associates it with the site through robots.txt, an HTTP Link header, an HTML <link> or <script> element, or an RSS module. It is aimed at publishers who want something between "everything is free" and "block every AI crawler".

Why RSL matters for AI visibility

Until RSL, a publisher had two settings: allow a crawler or disallow it. Both are bad for generative engine optimisation. Allowing everything hands over a training corpus for nothing; disallowing everything removes you from the retrieval sets that AI answers are grounded in, and you lose the citations along with the training. RSL gives you a third setting, conditional permission, because <permits> and <prohibits> take a usage vocabulary that separates the cases: search and ai-input (grounding and retrieval-augmented generation) can stay open while ai-train is reserved. That is the shape most publishers actually want, and it is not expressible in robots.txt alone.

Be clear about what RSL is not. It is a declaration, not an access control: a crawler that ignores your licence file still receives the bytes. What changes is that your terms are unambiguous, versioned and machine-readable, and that a client which wants to comply now has a documented route to permission, payment and reporting. Actual enforcement comes from somewhere else, either voluntary compliance, an edge rule that answers unlicensed requests with 401, 402 or 403, or a separate legal process, and none of that is decided by the XML. Treat RSL as the terms layer and keep your robots.txt controls and bot management in place underneath it. Nothing on this page is legal advice.

Where the spec lives

RSL 1.0 is published by the RSL Technical Steering Committee as a Recommendation (document RSL-SPEC-1.0, published 2025-12-10), with a running errata log that has changed real details during 2026. Read the spec before the guides.

RSL 1.0 Specification - the normative document: element and attribute tables, the usage and user vocabularies, discovery mechanisms, OLP and CAP. This is the only source you should copy element names from.
RSL 1.0 errata - dated corrections to the Recommendation. Check it before debugging: the reporting section and the HTML association scope rules both landed here during 2026.
Getting Started guide - the shortest path to a valid file plus the robots.txt directive, including the note that every subdomain needs its own robots.txt reference.
RSL validator - paste or point at your document to confirm it parses and conforms. Run it in CI, because an unrecognised element in the RSL namespace invalidates the whole document.
Crawler Authorization Protocol guide - the crawler side: the License auth scheme, the token flow and the 401/402/403 responses you return when you enforce.
RSL Collective - the nonprofit rights organisation behind the standard, running a shared licence server and a pay-per-output collective licence for publishers who do not want to negotiate individually.

Three ways to implement RSL

The three approaches below are cumulative, not alternatives. Start with the static site-wide licence if you just want your terms discoverable. Add the HTML and RSS associations if different parts of the site carry different rights, which is the normal case once you syndicate anything in or out. Add the licence server and the paid-crawl terms only if you intend to charge and can enforce, because the server attribute makes real demands on clients.

Site-wide licence file plus the robots.txt directive

The minimum viable deployment, and the one every RSL client looks for first. One XML document at the origin root, one absolute URL in robots.txt. This is enough to state terms; it involves no server, no tokens and no payments.

textrobots.txt

# Placed outside any User-agent group, so it applies to every client.
# The value must be an absolute URI.
License: https://example.com/license.xml

User-agent: *
Allow: /

# RSL states terms. It does not refuse anyone, so keep your
# access rules where they have always been.
User-agent: ExampleBot
Disallow: /

xml/license.xml

<?xml version="1.0" encoding="UTF-8"?>
<rsl xmlns="https://rslstandard.org/rsl" max-age="7">
  <content url="/">
    <license>
      <permits type="usage">search ai-input</permits>
      <prohibits type="usage">ai-train</prohibits>
      <payment type="attribution"/>
      <legal type="warranty">ownership authority</legal>
      <legal type="disclaimer">as-is no-liability</legal>
      <legal type="contact">mailto:[email protected]</legal>
    </license>
    <copyright type="organization"
               contactUrl="https://example.com/contact/">Example Media Ltd</copyright>
    <terms>https://rslstandard.org/rsl/default-terms</terms>
  </content>
</rsl>

What this does: a conformant crawler fetches robots.txt, follows the License directive, parses the document and gets a specific answer: it may index the site and ground answers in it, it must credit and link back, and it may not train on it. max-age="7" tells clients they may cache that conclusion for seven days rather than the 30-day default, so a change in your terms propagates within a week.

Page-level and syndicated terms in HTML and RSS

Use this when the site root licence is not the whole truth: wire copy you licensed in, a paywalled archive, user submissions, or a report you sell. The HTML association also matters because plenty of tools read the page and never fetch robots.txt, Glippy included.

htmltemplates/article.html

<head>
  <!-- Document-level association: same file as the robots.txt directive -->
  <link rel="license" type="application/rsl+xml"
        href="https://example.com/license.xml">
</head>
<body>
  <article>
    <h1>Quarterly market report</h1>
    <p>Our own reporting, governed by the site-wide terms.</p>
  </article>

  <section>
    <h2>Syndicated from Example Wire</h2>
    <p>Licensed in, so we cannot license it out.</p>
    <script type="application/rsl+xml">
      <rsl xmlns="https://rslstandard.org/rsl">
        <content url="https://wire.example.com/articles/123">
          <license>
            <prohibits type="usage">ai-all</prohibits>
          </license>
        </content>
      </rsl>
    </script>
  </section>
</body>

xmlfeed.xml

<rss version="2.0" xmlns:rsl="https://rslstandard.org/rsl">
  <channel>
    <title>Example Media</title>
    <item>
      <title>Quarterly market report</title>
      <link>https://example.com/reports/q3/</link>
      <rsl:content url="/reports/q3/">
        <rsl:license>
          <rsl:permits type="usage">search</rsl:permits>
          <rsl:payment type="free"/>
        </rsl:license>
        <rsl:license>
          <rsl:permits type="usage">ai-input</rsl:permits>
          <rsl:payment type="purchase">
            <rsl:amount currency="EUR">49.00</rsl:amount>
            <rsl:custom>https://example.com/licensing/</rsl:custom>
          </rsl:payment>
        </rsl:license>
      </rsl:content>
    </item>
  </channel>
</rss>

What this does: the inline <script> scopes a stricter licence to one section and pins it to the syndicator's canonical URL, so the restriction travels with the text if it is copied again. In the feed, two <license> elements inside one <rsl:content> express two term sets for the same asset: free to index, paid to ground an answer in. Note that every element in a feed must carry the rsl: prefix.

Priced crawling with a licence server and edge enforcement

For publishers who want money rather than credit. The server attribute names a licence server implementing the Open License Protocol, either your own or a shared one such as the RSL Collective's; <accepts> advertises a payment protocol; and the Crawler Authorization Protocol turns the licence into something your CDN can check on every request.

xml/license.xml

<?xml version="1.0" encoding="UTF-8"?>
<rsl xmlns="https://rslstandard.org/rsl" max-age="1">
  <!-- Site-wide: collective licence, publisher paid per AI output -->
  <content url="/" server="https://api.rslcollective.org">
    <license>
      <permits type="usage">ai-all</permits>
      <payment type="use">
        <standard>https://rslcollective.org/license</standard>
      </payment>
    </license>
  </content>

  <!-- Archive: priced per crawl, settled with x402, telemetry required -->
  <content url="/archive/*">
    <license>
      <permits type="usage">search ai-input</permits>
      <payment type="crawl">
        <amount currency="USD">0.015</amount>
        <standard>https://example.com/licenses/pay-per-crawl</standard>
        <accepts type="application/x402+json"><![CDATA[
          {"scheme": "deferred", "network": "example-network-provider"}
        ]]></accepts>
      </payment>
      <reporting type="telemetry"
                 profile="https://contenttelemetry.org/profiles/spur"
                 endpoint="https://example.com/rsl/telemetry"/>
    </license>
  </content>
</rsl>

httpedge exchange

GET /archive/2019/ HTTP/1.1
Host: example.com
User-Agent: ExampleBot/1.0

HTTP/1.1 402 Payment Required
WWW-Authenticate: License error="invalid_token"
Link: <https://example.com/license.xml>; rel="license"; type="application/rsl+xml"
Cache-Control: no-store

# The crawler reads the terms, acquires a token, and retries.

GET /archive/2019/ HTTP/1.1
Host: example.com
User-Agent: ExampleBot/1.0
Authorization: License rsl_cnNsLWNsaWVudC0xMjM6czNjcjN0S0VZ

What this does: the archive scope is more specific than url="/", so it wins for those paths and the collective terms cover everything else. The 402 response carries the licence reference in a Link header, which is how a compliant crawler discovers where to buy access without ever parsing your HTML. OLP, CAP and encryption are optional extensions: you can publish RSL terms and skip all three.

Implementation guidelines

These are the things that break in production rather than in the validator.

Keep one canonical document. The robots.txt directive, the HTTP Link header and the HTML <link> should all resolve to the same absolute URL. Clients check every association point they can see, and conflicting documents are resolved to the most restrictive reading, which is rarely the one you meant.
Serve it as application/rsl+xml. A licence file returned as text/html, or behind a redirect chain, or 404ing after a deploy, leaves the asset unlicensed as far as the spec is concerned. Add it to your smoke tests alongside robots.txt and the sitemap.
Set max-age deliberately. Clients may treat the document as authoritative for that many days, defaulting to 30 if you omit it. Lower it before you plan a change in terms, and serve Last-Modified and ETag so clients can revalidate cheaply instead of guessing.
Order does not matter, specificity does. Element order is explicitly irrelevant; scope is not. Put the permissive default on url="/" and narrow it with additional <content> elements, remembering that a prohibition always beats a permission for the same usage.
Do not set server until one exists. When <content> carries a server attribute, clients must obtain a token from it before access even when the payment type is free. Pointing at a server that is not live is a self-inflicted block.
Handle subdomains and user-agent groups explicitly. Each subdomain serves its own robots.txt and needs its own License line. A directive inside a User-agent group replaces the global ones for crawlers that select that group rather than adding to them, so a per-bot licence must be complete on its own.
Version the file like code. Keep license.xml in the repository, validate it in CI, and record when terms changed. If you ever need to show what a crawler was told on a given date, a commit history is the cheapest possible evidence.

Do this, not that

Do

Add <link rel="license" type="application/rsl+xml"> to <head> as well as the robots.txt directive, so page-level tools see your terms.
Split search and ai-input from ai-train if you want citations without donating a training set.
Use lowercase booleans (encrypted="true") and ISO 4217 codes on <amount currency="USD">; both are normative requirements.
Run the document through the RSL validator on every deploy, since one unknown element in the RSL namespace makes the whole file non-conformant.

Do not

Do not invent payment types. RSL 1.0 defines purchase, subscription, training, crawl, use, contribution, attribution and free, and nothing else.
Do not permit ai-train in the licence file while your robots.txt Content-Signal line says ai-train=no; pick one story.
Do not reference a <standard> URL whose terms contradict your own elements, such as CC BY alongside a blanket ai-train prohibition.
Do not present <prohibits> to stakeholders as a block. It stops no request on its own and it is not a substitute for legal advice.

How Glippy checks this

Glippy scores licensing signals inside Machine Readability (category 6). The Content Licensing check reads the rendered page and looks for a link[rel="license"] element, a dc.rights or rights meta tag, or a Creative Commons URL in the markup, which means an RSL deployment that exists only as a root licence file plus a robots.txt directive is invisible to it. Adding the HTML association from example 02 is what turns that check green. The same category also parses the Content-Signal directive out of robots.txt and credits agent-discovery Link headers, so a site that ships RSL, Content Signals and a licence Link header together picks up points in all three places.

Check your RSL setup

Glippy runs 240+ checks across 16 categories on any page, including Machine Readability (category 6). No sign-up required.

Try the Glippy Chrome extension

Frequently asked questions

Does RSL actually block AI crawlers from taking my content?

No. RSL publishes machine-readable terms; it does not refuse a request. A crawler that never fetches your licence file still receives the page. Enforcement comes from elsewhere: a crawler choosing to comply, an edge or bot-management rule that answers unlicensed requests with 401, 402 or 403 under the Crawler Authorization Protocol, or a legal process outside the standard. Keep robots.txt rules and bot management in place underneath RSL rather than replacing them with it.

Where does the RSL licence file go and how do crawlers find it?

Convention is a file named license.xml at the origin root, but the filename carries no meaning: what binds the document to your content is the association. RSL 1.0 defines five equivalent ones: a License: directive in robots.txt, an HTTP Link header with rel="license" and type="application/rsl+xml", an HTML <link> or inline <script type="application/rsl+xml">, an <rsl:content> element in an RSS item, and embedded metadata in a media or data file. Clients are expected to check every association point available to them.

How is RSL different from Content Signals or a robots.txt disallow?

A robots.txt Disallow asks a crawler not to fetch at all, and says nothing about what happens to content it already has. Content Signals expresses a yes or no preference per usage category with no price attached. RSL keeps that vocabulary, its usage tokens explicitly include the Content Signals ones, and adds what the others leave out: payment terms, reporting obligations, warranties, a rights holder, and an optional protocol for a crawler to acquire a licence. The three layer rather than compete.

Do I need a licence server to use RSL?

No. The Open License Protocol, the Crawler Authorization Protocol and the encrypted media format are optional extensions; a conformant implementation can be a static XML file plus one discovery mechanism. Use <standard> to point at a shared framework such as a Creative Commons licence or the RSL Collective's, or <custom> to point at your own licensing page. Only add the server attribute once a licence server is actually live, because its presence obliges clients to obtain a token before access even when the payment type is free.

Reviewed against the primary sources on 27 August 2026. These standards move quickly, so check the linked specs before you ship.