Klairia Blog
Googlebot Read Our llms.txt. A Second Crawl Signal, Not a Verdict.
A Googlebot request to Klairia's short llms file shows why teams should measure both crawler discovery and downstream AI visibility.
Earlier this month, we saw Googlebot request Klairia’s llms-full.txt. In our latest daily check, Googlebot requested the shorter /llms.txt file too.
The event happened at 03:06 UTC on July 10. Our request log classified it as Googlebot, operated by Google, in the search_crawler category. It was one read of /llms.txt; /llms-full.txt had no read in that 24-hour window.
This is a second crawl signal, not a verdict on GEO.
It confirms that the short file is publicly reachable and that we can distinguish requests to it from requests to the fuller document. It does not show that Google gives the file special treatment, that an AI assistant read it, or that it changed how Klairia appears in AI-generated answers.
That distinction is the point.
What changed
Klairia publishes two related files:
/llms.txtis a concise map of the public site, app entry points, and API surfaces./llms-full.txtadds a fuller product description, scan workflow, routes, and implementation context.
The short version is designed to help a crawler orient itself quickly. The full version gives it more depth when that is useful.
Our earlier observation showed that Googlebot could discover and request the longer file. This latest event shows that the shorter file is independently reachable too. Because both URLs are included in our sitemap, ordinary sitemap discovery remains the most plausible explanation.
That is useful operational evidence. It is not proof that either file affects rankings or AI answers.
Why the short file is worth measuring separately
It would be easy to combine these URLs into one metric called “llms file reads.” That would hide an important detail.
The two files have different jobs. The short file acts as a compact directory; the full file carries more context. A crawler may request one without requesting the other. If we only tracked a combined count, we would not know which public surface was actually discovered.
Separate tracking lets us answer more useful questions over time:
- Do search crawlers request the short file, the full file, or both?
- Does one file become the more common entry point?
- Do AI-specific crawlers show a different pattern from search crawlers?
- Do changes to the sitemap, internal links, or file content change crawl behavior?
Those are input signals. They tell us whether a system reached the context we published. They do not tell us what the system did with that context.
What one Googlebot request can and cannot tell us
The raw user agent for this event identified itself as Googlebot, and our analytics classified it as a Google search crawler. That is enough to say Googlebot requested /llms.txt once.
It is not enough to claim any of the following:
- Google uses
llms.txtas a ranking signal. - Google interprets the file as a standard with special semantics.
- An AI assistant consumed the file.
- Klairia’s visibility score, citations, or recommendations improved because of the request.
These are separate questions with separate evidence requirements. Crawler telemetry answers the discovery question. Search performance data can help answer the indexing question. AI visibility scans are needed to assess whether a brand is mentioned, cited, or recommended in the contexts that matter.
Treating those as one measurement problem is how teams end up attributing results they cannot support.
The practical measurement loop
For teams publishing llms.txt, the useful workflow is straightforward:
- Publish accurate, crawlable files at stable URLs.
- Include the relevant URLs in the sitemap where appropriate.
- Log every request with the path and raw user agent.
- Classify known readers by bot name, operator, and category.
- Review reads by file over weeks, not isolated days.
- Compare that crawl evidence with search data and actual AI visibility measurements.
The first five steps establish whether your machine-readable context can be found. The last step keeps the work honest. A read is a discovery event, not an outcome event.
What we will watch next
This latest request gives us a clearer baseline: both the concise and detailed files can be observed as distinct crawl targets.
Now we will watch for patterns rather than celebrate a single event. Useful follow-up signals include repeat requests, whether both files are requested in the same crawl cycle, the arrival of AI-specific crawlers, and whether any pattern later coincides with a measurable change in Klairia’s AI visibility.
Until then, the conclusion stays modest. Googlebot found and requested /llms.txt. That makes the files measurable infrastructure, not a magic shortcut.
FAQ
Does this mean Google uses llms.txt for ranking?
No. The event only shows that Googlebot requested the URL. Because the URL is listed in the sitemap, ordinary crawl discovery is a sufficient explanation.
Why publish both a short and full file?
The short file offers a compact route map. The full file provides deeper product and implementation context. Tracking them separately shows which version a crawler actually requested.
What is the next meaningful signal?
Repeated access patterns are more useful than one event. The stronger outcome signal is still a change in measured AI mentions, citations, recommendation rate, or answer accuracy.