Seven of Sixty-Eight AI Visibility Vendors Declare Content Signals. None Use the New Field.
We fetched robots.txt from all 69 vendors in our catalogue. Seven declare Content Signals, nobody has adopted the fourth field, and one says no to training.
Content Signals are the one machine-readable way to say what an AI crawler may do with your page after it has read it. They live in robots.txt, they have a specification behind them, and they are free. We asked all 69 vendors in our catalogue for their robots.txt on 14 August 2026. Of the 68 vendors that served a parseable file, 7 declare Content Signals and 0 declare the fourth field.
This is a category whose entire product is being read correctly by machines. It is also a category that, with seven exceptions, has not used the one field designed for saying so.
Disclosure: EchoWi is one of the sixty-nine and one of the seven, and we sell AI visibility measurement, so a study about who declares their preferences properly is a study with an interest. The method is a GET request for
/robots.txtand a search for lines beginningContent-Signal:. The date is 14 August 2026, every declaring vendor is named below with its exact wording, and the counts are in our measurement register. Anyone can run it against us in a minute, and the section on what our own earlier sweep got wrong is there because we ran it against ourselves first.
The short version
- 68 of the 69 vendors serve a robots.txt. One returns a bot challenge instead, which is a challenge and not an absent file, and it is counted separately for that reason.
- 7 of the 68 declare Content Signals. That is roughly one in ten, in a category built on being machine-readable.
- 0 declare
content-use, the fourth field currently being tested. Not one vendor in the category has taken it up. - Six of the seven declare fully permissive, some version of search yes, ai-input yes, ai-train yes.
- One declares
ai-train=nowhile keepingai-input=yes. That is not a contradiction, and treating it as one would be the easy mistake this piece is careful not to make. - Our own earlier count of this same convention was wrong about that vendor, for an instrument reason we describe rather than quietly correct.
What a Content Signal is, and the field that has just appeared
A robots.txt file has always been able to say where a crawler may go. It has never been able to say what a crawler may do with what it finds. Content Signals fill that gap with three fields, written as a directive line inside a group:
User-Agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=yes
Allow: /
The three mean different things and the difference is the entire point:
searchcovers building a search index over the content.ai-inputcovers feeding the content into a model to produce a real-time answer. This is the one that governs citation.ai-traincovers using the content to train or fine-tune a model.
A publisher can hold any combination of positions across those three, and the vocabulary exists so that holding a nuanced one is expressible rather than approximated by blocking a crawler outright.
Cloudflare is currently testing a fourth field, content-use, which describes what may be kept and reused after access. It takes one of three values, least to most permissive: use=immediate means interact but store nothing, use=reference means index, excerpt and link back, and use=full means summarise and reproduce. Cloudflare’s own managed robots.txt writes use=reference alongside its default of search=yes, ai-train=no.
The same catalogue was asked a neighbouring question the same day, with the same instrument: most of the domains that win citations do not ship an llms.txt while most vendors do, which is the other convention this category sells.
That fourth field is why this sweep was worth running now rather than later. It is new enough that adoption is a real question, and the answer turns out to be clean.
What sixty-nine robots.txt files say
The instrument fetches /robots.txt from each vendor’s own origin, follows redirects, and reads every Content-Signal: line in the body. It is deliberately unglamorous, and three of its choices matter:
It uses GET, never HEAD. A server is not obliged to answer a HEAD request, and this is not theoretical here: an earlier link checker in this project reported two perfectly live pages as dead for exactly that reason before it was corrected.
A challenge is not a missing file. Statuses 401, 403, 429 and 999 mean a bot check stood in the way. That is evidence about the edge, not about whether a file exists, and folding it into “no robots.txt” would manufacture a number. One vendor lands in this bucket.
A 200 is not automatically a robots.txt. Some hosts answer any path with a marketing page. The body has to contain an actual directive before the row counts.
The counts on 14 August 2026:
| Outcome | Vendors |
|---|---|
| Served a parseable robots.txt | 68 |
| Returned a bot challenge | 1 |
| No file | 0 |
| Declared Content Signals | 7 |
Declared content-use | 0 |
And the seven, with what each one actually says:
| Vendor | Lines | Declaration |
|---|---|---|
| Airefs | 1 | ai-train=yes, search=yes, ai-input=yes |
| Cloudflare AEO | 1 | ai-train=yes, search=yes, ai-input=yes |
| EchoWi | 2 | search=yes, ai-input=yes, ai-train=yes |
| KIME | 2 | search=yes, ai-input=yes, ai-train=yes |
| Listable Labs | 1 | search=yes, ai-input=yes, ai-train=yes |
| Omnibound | 3 | search=yes, then ai-train=no, then ai-input=yes |
| Rankability | 11 | ai-train=yes, search=yes |
Two things are worth reading off that table before anyone draws a conclusion from the headline number.
The first is that a robots.txt carries one Content-Signal line per group, so the count in the middle column is not decoration. Rankability writes eleven of them, which is a deliberate act of saying the same thing to eleven different crawler groups. Omnibound writes three, and they do not all say the same thing.
The second is that Rankability’s declaration omits ai-input entirely. Under the specification an absent field is not a no, it is silence, so this is not a refusal of citation. It is a vendor that has thought about training and search and has not said anything about the field that governs being used in an answer.
The one vendor that says no, and why that is the considered answer
Omnibound is the only one of the seven that declares a restrictive preference anywhere: ai-train=no, alongside ai-input=yes.
The tempting read is that a vendor selling AI visibility telling AI crawlers not to use its content is a contradiction worth pointing at. That read is wrong, and it is worth spelling out why, because the whole value of this vocabulary rests on the distinction it makes.
Training and answering are different uses. A model trained on your content has absorbed it into weights, cites nothing, and sends nobody. A model using your content as input to an answer can quote it, attribute it and link to it. A publisher who wants the second and not the first is not confused. They are expressing precisely the position the three fields were designed to let them express, and they are the only vendor in this category who has bothered to express it.
On the numbers as we found them, Omnibound has the most considered declaration in the set. Everyone else with a declaration has said yes to everything, which is a defensible position for a business that wants maximum machine reach, and is also what you write when you have not thought about the difference.
The instrument was wrong first, and so was our own earlier count
We ran a version of this sweep three days earlier, on 11 August, as part of a broader audit of what this category ships. That earlier count recorded Omnibound as declaring search=yes, full stop.
That was our instrument, not their file. It read the first Content-Signal: line and reported it as though it were the declaration. Omnibound has three, and the first happens to be the least interesting of them. The published record therefore had a vendor’s position recorded backwards for three days, and nothing flagged it, because a truncated value looks exactly like a complete one.
We are not editing the earlier figure. It is a frozen fact about what our instrument saw on its own day, and its counts are quoted in several places. What we have done instead is record the new sweep separately, store every line with a count beside it, and write into the data itself why the two dates disagree. Whether Omnibound changed the file between the eleventh and the fourteenth, or our earlier instrument simply misread it, is not recoverable now. Picking whichever explanation flattered us would be inventing a fact.
The general rule we took from it: when a format permits a field to appear more than once, the instrument collects all of them and the record stores how many there were. A count sitting next to a value is what makes the next truncation visible.
And the sites that actually get cited are no better
The obvious objection to everything above is that we measured the wrong people. Vendors sell visibility; they do not necessarily win it. So we asked the same question of the domains that do.
The population is every domain this register has recorded as cited in three or more separate probe rows, which is 122 of the 1,019 distinct domains it has seen. The threshold is arbitrary and we are declaring it: high enough that a domain has been cited across several questions rather than once, low enough to leave a sample larger than the vendor catalogue. Of those 122, 113 served a readable file, 5 returned a challenge, 3 failed to resolve and 1 answered 200 with something that is not a robots.txt.
9 of the 113 cited domains declare Content Signals. Against 7 of 68 for the vendors, that is the same rate inside any error worth the name.
That runs against the framing this piece opened with, so we will say it plainly: the category is not unusually negligent about a convention its own product depends on. It is normal. Normal is just very low, in both populations, and a finding about an industry is less comfortable to write than a finding about a competitor set.
Two differences survive the comparison, and one of them is smaller than it looks.
The fourth field exists in the wild and not in the category. No vendor
declares content-use. Two cited domains do. But both write the byte-identical
string search=yes,ai-train=no,use=reference, spacing included, so two adopters
is not evidence of two decisions. The likeliest explanation is one plugin or one
copied snippet, and we are recording it that way rather than as adoption.
Declining training is more common outside the category. Four of the nine
cited domains that declare say ai-train=no, against one of seven vendors.
Those are counts and not rates on purpose: at single digits a percentage would
be theatre, and the honest statement is that the only population where saying no
to training is common is the one we did not build.
What this does not show
One convention, one day, one catalogue. This is 69 vendors we track, on 14 August 2026. It is not a sample of the web and it is not a claim about anyone outside that list.
Declaring is not complying, and not declaring is not blocking. Content Signals express a preference. They do not enforce anything, a crawler is free to disregard them, and a vendor with no declaration has not thereby denied anything. The correct reading of the 61 non-declarers is that they are silent, not that they are hostile.
A robots.txt is what the edge is serving, not what the repository contains. We know this one from experience: our own declaration was invisible to a previous sweep because a CDN was still serving a version cached with a year of TTL. A measurement of what a site declares is a measurement of what its cache is handing out that day.
Zero adoption of a field is not evidence the field is bad. content-use is new and still described as a test. Nobody having taken it up yet is a fact about timing as much as about the field, and the honest thing to do is measure it again later rather than conclude anything now.
We have not measured whether any of this changes citation. Nothing here connects a declaration to being cited more or less often. That would need a different design, and we would rather say so than imply the link.
Common Questions About Content Signals
What are Content Signals in robots.txt?
Content Signals are machine-readable directives inside a robots.txt file that state what a crawler may do with content after accessing it. There are three fields: search for building a search index, ai-input for feeding content into a model to generate a real-time answer, and ai-train for training or fine-tuning a model. They are written as a directive line inside a crawler group, for example Content-Signal: search=yes, ai-input=yes, ai-train=yes, and each field takes yes or no.
How many AI visibility vendors declare Content Signals?
7 of the 68 that served a readable robots.txt, measured on 14 August 2026 across the 69 vendors in our catalogue. One further vendor returned a bot challenge rather than a file, which we count separately because a challenge is not evidence that a file is absent. The seven are named in the table above with their exact declarations.
What is the content-use field?
content-use is a fourth Content Signals field currently being tested, describing what may be kept and reused after access. Its three values run from least to most permissive: use=immediate means interact but store and reuse nothing, use=reference means index, excerpt and link back, and use=full means summarise and reproduce. As of 14 August 2026, none of the 68 vendors we could read declares it.
Does declaring ai-train=no hurt your AI visibility?
Not by itself, because training and answering are separate uses. ai-train governs whether your content may be absorbed into a model’s weights, while ai-input governs whether it may be used as source material for a generated answer, which is the one that produces citations and links. A publisher can decline the first and permit the second, and one vendor in this sweep does exactly that.
Should I add Content Signals to my robots.txt?
It is free, it is a single line per crawler group, and it is the only standardised way to state the distinction between being trained on and being cited. Whether to declare permissively or restrictively is a rights decision rather than a technical one, so the useful step is deciding what you actually want for each of the three uses before writing anything. Declaring does not enforce, so it belongs alongside whatever access controls you already run rather than instead of them.
How do I check what a site declares?
Request /robots.txt from the site’s own origin with a GET, not a HEAD, and read every line beginning Content-Signal:. There can be more than one, because a file carries one per crawler group, and reading only the first is how we got a vendor’s position wrong in an earlier sweep. If the request returns 401, 403, 429 or 999 you have hit a bot challenge and learned nothing about the file.
Ask an AI about this article
Opens your assistant with this page already loaded, so you can check the numbers, argue with the method or ask what it means for you.
- ChatGPT (opens in new tab. the question is pre-filled, press enter to send it)
- Claude (opens in new tab. the question is pre-filled, press enter to send it)
- Perplexity (opens in new tab)
- Google AI Mode (opens in new tab)
Perplexity and Google answer straight away. ChatGPT and Claude fill the box and wait for you to press enter, which is their behaviour and not something we can set.