01 The research
97% of sites with an llms.txt file got no requests
If somebody added a file to make AI read your site, the evidence that anything fetches it is thin.
The authors call their own audit non-systematic and their log study non-probability, which is the reason to read this paper rather than the reason to dismiss it.
Gangzhen Qian and seven co-authors published a review of the /llms.txt file on 28 October. The file is something a website adds to tell AI systems what the site holds and where to look, and it has become a standard line on an AI visibility invoice. Their log study found that 97% of domains with a detected file received no recorded requests for it in May 2026.
A second test pointed the same way. Using fifteen different tools across 45 trials at one endpoint, the authors observed no automatic requests at all. On this evidence the file is not being fetched on its own initiative by the systems it is written for.
The security finding is the one worth your attention. In a pilot of 24 tasks across eight sites and 120 real model responses, the authors supplied adversarial file content to the models directly rather than letting them fetch it, and scoring found the attacker's target adopted in 21 of 24 raw adversarial responses. The authors are explicit that this measured what happens when such content reaches a model, without live retrieval or any external action.
This file is sold across the AI visibility industry, and Forever Cited sits in that industry. The honest position is that the fetch evidence is thin, the paper says so about its own method, and we are not going to repeat a claim we cannot show you.
The limits are the authors' own words. The initial audit covered 39 sources, the fifteen-tool study is described as purposive, the log study as non-probability and the pilot as reduced, and the paper leaves full retrieval and agent testing open.
What to do about it
If an llms.txt file is on an invoice you paid, ask for the server log showing requests for it. An independent insurance broker can settle that question from their own hosting account in a few minutes, and the log either shows requests or it does not.
If the file is already published, read what it actually says. On this evidence its contents deserve the same care as any public page on your site.
Source arXiv, Gangzhen Qian, Kainan Zhou, Chuhong Xu, Hang Xiao, Zhi Jing, Rong Bao, Lu Yi and Zhaoyi Li, “Manifest-Assisted Retrieval in Artificial Intelligence Search: Evidence Gaps and a Security Evaluation,” 28 October 2026 · arxiv.org/abs/2610.38361 (a preprint; the authors describe the audit as non-systematic across 39 sources, the fifteen-tool study as purposive, the log study as non-probability and the model pilot as reduced, and the 97% is of domains with a detected file, a count the paper does not state)
02 The market
The most accurate AI model was likeliest to recommend nobody
An AI agent that cannot confirm you meet a customer's requirement will report no match rather than name you.
ATLAS-Bench graded whether a recommendation actually met the customer's stated requirements, not whether the answer sounded convincing.
Keyun Zhang and seven co-authors released ATLAS-Bench on 29 October, a test of how well AI agents handle local search. It is built from 1,200 queries across three regions, expanded from real search events using place attributes, reviews and user profiles. Each query separates what a customer must have from what they would merely prefer.
The agent's job is the part that matters to you. Given a query, a time and a location, it searches place attributes and reviews, and must either recommend options with evidence behind them or report that no place meets all the mandatory requirements.
Across 14 configurations of 11 models, the strongest on accuracy was GPT-6-Luna, with the highest constraint satisfaction rate among returned recommendations at 71.5% and factual accuracy of 95.6%. Both of those are rates across the recommendations it returned, not across the questions it was asked.
That distinction is the finding. The same model returned at least one acceptable recommendation for 67.3% of satisfiable queries, against 85.3% for GLM-5.3, which scored lower on accuracy. So the more careful model more often answered a question that had a good answer by naming nobody.
For a real estate brokerage this is a practical point rather than a technical one. The evidence the agent reads is your listed attributes and your reviews, and a requirement you meet but cannot prove is a requirement the agent records as unmet.
What to do about it
Open your own listing and read it as evidence rather than as marketing. For each thing a customer might require, ask whether a machine reading only your attributes and your reviews could confirm it.
Hours, service area, languages, accessibility and whether you are taking new clients are the fields that answer mandatory requirements. A blank field is not neutral, because the agent cannot assume in your favor.
Source arXiv, Keyun Zhang, Dapeng Yin, Fanfu Wang, Shuang Lang, Zhenyu Zhu, Yulin Huang, Chong Yang and Pengjie Wang, “ATLAS-Bench: An Agentic Tool-Use Benchmark for Local Area Search,” 29 October 2026 · arxiv.org/abs/2610.39438 (a preprint; 1,200 queries across three regions is the whole benchmark rather than the denominator of the 67.3% and 85.3% figures, which are shares of satisfiable queries, a count the paper does not state)
03 The evidence
List order changed which business every tested model recommended
Which business an AI recommends can turn on list order, so the same question can produce a different name.
Peláez-González, Herrera and Herrera-Poyatos tested a product catalog in a controlled setup rather than live AI assistants, and that limit matters before anyone quotes the number.
Carlos Peláez-González, Francisco Herrera and Andrés Herrera-Poyatos published a study on 27 October of positional bias in AI recommendation. They built a controlled setup on a real product catalog with a fixed prompt wording, then ran 2,000 generated customer questions with 20 different orderings each, 40,000 runs in total.
The result was not a tendency. Both of their detection methods rejected the idea that position made no difference, in every model they evaluated. The paper does not say how many models that was.
One of their three measures is the one to understand. They call it strong positional bias, and it covers the cases where position pushes the recommendation toward items that are clearly less relevant, rather than merely choosing between options that were about as good as each other. That is the difference between an arbitrary pick among equals and a worse option winning.
They also checked whether this was an artifact of their own settings. Varying the number of candidates and the randomness of the output left it in place, which led them to describe the bias as structural and dependent on the model rather than on the setup.
For an admissions consultant the reading is narrow. Nobody can promise you a position in a list whose order they do not control, and the authors' own prescription is routine auditing and standardized prompting rather than any claim about who deserves to win.
What to do about it
Treat any guarantee about being the recommended name with this paper in hand. In the setup these authors tested, the order of a list the customer never sees moved the answer in every model.
What is left is the part you control: the attributes, the reviews and the public record that make you a reasonable answer wherever you land in the order.
Source arXiv, Carlos Peláez-González, Francisco Herrera and Andrés Herrera-Poyatos, “Statistical Detection of Positional Bias in LLM-Based Recommender Systems: Methodologies and Empirical Evidence,” 27 October 2026 · arxiv.org/abs/2610.37962 (a preprint; every result is scoped by the authors to the evaluated setting, which is one controlled retrieval testbed on one product catalog with one fixed prompt wording, and the paper states no count of the models evaluated)
04 The operations
Booking pages keep loading, and agents click the wrong thing
A customer whose software fails on your booking page sees a business that does not work, not a page that loads slowly.
Vasundra Srinivasan measured 65 commercial home pages, which makes this an early warning rather than a settled fact.
Vasundra Srinivasan published a measurement on 29 October of a problem specific to software that uses a website the way a person does. These agents take a screenshot, think for a few seconds, then click a position on the screen, and if the page moved in between, the click lands on something else.
The timing is the whole risk. Measuring planned clicks on 31 public pages, 0.4% of clicks planned on fully loaded pages went stale within 30 seconds, against 17% of clicks planned in the first second after the page opened. Waiting about one second for network activity to stop removes most of it, yet the wait rules of eight of ten widely used open-source agents leave more than 1% of clicks stale.
Commercial pages are the worst case, which is the part that touches you. In the HTTP Archive's public crawl, 15% of 65 desktop booking and buying home pages went 500 milliseconds without a network request within three seconds of the page being parsed, against 63% of 3,028 government pages.
A further figure in the same comparison is about layout. 52% shifted their layout within 6.5 seconds, against 8% for the government pages, although the paper does not state how many pages sit behind that pair.
A charter operator taking booking requests through a web form should read this as a reason to time their own page. The agent is not going to wait for a page that is still settling, and the customer sees a failed booking rather than a slow website.
What to do about it
Time your own booking page on a phone on a normal connection, from tap to the moment nothing moves. Anything past a couple of seconds is the window this paper is about.
The fix is ordinary web work rather than anything to do with AI: fewer things loading after the page appears, and no element that arrives late and shifts what is underneath it.
Source arXiv, Vasundra Srinivasan, “What Does “Now” Mean to Your Computer-Use Agent? Stale Screenshots, Page Loads, and Which Check to Run Before a Click,” 29 October 2026 · arxiv.org/abs/2610.39282 (a preprint; only the 15% and 63% pair carries stated page counts, 65 and 3,028, and the paper states no page count behind the 52% and 8% pair and no click count behind the 0.4% and 17% figures)
05 The platform
Google's Gary Illyes says AI made fake Googlebots worse
The file you set to control AI training is honored by choice, and the crawlers taking your content are the ones ignoring it.
Gary Illyes works on crawling at Google, which makes this a statement about the limits of Google's own instruction file.
Gary Illyes of Google was interviewed on the Odys Podcast by its host Aneta Samkoff, in an episode Search Engine Roundtable wrote up on 30 October. Asked why rogue crawlers pretending to be something they are not had become such a problem, Illyes said “I think it is AI,” and pointed at companies harvesting content to train their own models.
His own test is the detail worth keeping. Illyes says he set up honeypots to attract crawlers and found requests claiming to be Googlebot arriving from addresses unrelated to Google. The write-up puts the effort involved at about 30 seconds, because changing the name a crawler reports is trivial.
The consequence connects directly to yesterday's issue. The write-up describes Illyes characterizing robots.txt, the file at the root of a site that tells crawlers what they may fetch, as a suggestion rather than an enforceable restriction: well-behaved crawlers generally respect it and anything else can ignore it. Owners who need to actually block traffic are pointed instead at network-level protection such as a web application firewall.
There is a real control in here, and it is the one from yesterday's issue. Google-Extended lets a site allow Googlebot to crawl for Search while restricting use of that content for training certain Google AI models, and Illyes notes that Apple has a similar Applebot-Extended token.
For a law firm that has published client-facing explainers, there are two separate conclusions here. The instruction is worth setting, because the companies that negotiate agreements are the ones that read it, and checking the requesting address against Google's own records is what covers the rest.
What to do about it
Ask whoever runs your website one question: does anything verify that a crawler calling itself Googlebot really belongs to Google? The check is a reverse lookup on the requesting address, and it is standard.
If your site has been slow or has fallen over without explanation, this is worth ruling in. A badly built crawler requesting the same pages over and over can take a small site down without intending to.
Source Search Engine Roundtable, Barry Schwartz, “Google’s Gary Illyes: AI Made Bot Impersonation Worse,” 30 October 2026 · seroundtable.com/google-ai-made-bot-impersonation-worse-42422.html (the primary source is a podcast episode, and the quotation, the about-30-seconds figure and the characterizations of robots.txt and of the firewall advice are the publisher's own transcription and summary rather than sentences Illyes is quoted speaking)
