llms.txt for hotel websites: what the file is, and what it will not do

llms.txt is a proposed plain-text file, published at a website's root, that gives language models a short map of the site's key pages in Markdown. Jeremy Howard proposed it on llmstxt.org on 3 September 2024. It is a proposal, not a standard, and Google's own documentation says Google Search ignores it.

A web agency emails the hotel's marketing manager: the site needs an llms.txt file, or AI assistants will not find the hotel. The file is real, cheap and harmless. The promise attached to it is not supported by anything the search engines have published. After reading this you will know what the file is, how it differs from robots.txt and a sitemap, what Google has actually said, and what to check before you pay anyone for one.

What is llms.txt?#

llms.txt is a proposed plain-text file, written in Markdown, that sits at a website's root and gives a language model a short map of the site's key pages. It is a proposal published on llmstxt.org (opens in a new tab), not a standard that anyone enforces.

Markdown means plain text with light formatting symbols. A heading is a line starting with a hash mark; a link is a name in square brackets followed by a web address in round brackets. Anyone can read and edit it in a text editor, which is the whole point: no special tooling, no agency retainer required to read it.

Jeremy Howard proposed the file; the proposal on llmstxt.org is dated 3 September 2024 and was revised as v2 in August 2026. The file sits at the site's root, at yourdomain.com/llms.txt, or at any subpath such as /docs/llms.txt, where it covers the pages under that path.

In order, the file holds:

The proposal also recommends clean Markdown versions of pages at the same address, with .md added or the extension replaced, and v2 recommends two link relations (rel="alternate" type="text/markdown" and rel="describedby") so an agent can find them. The author states a different purpose from robots.txt: agents use the file on demand when they need information, and it was expected to serve inference rather than training.

llms.txt, robots.txt and the sitemap: three different jobs#

robots.txt tells crawlers what they may fetch, a sitemap lists addresses so they can be discovered, and llms.txt offers context to a model that already has a question. They serve different readers at different moments, and none replaces another.

robots.txt is a permission file: it answers "may this crawler fetch this part of the site". A sitemap is a completeness file: it answers "which addresses exist" and helps discovery and indexing. llms.txt is a reading map: it answers "which pages explain this hotel, and in what order should I read them".

The moments differ. A crawler acts at crawl time, on its own schedule. A model acts when someone asks it a question, on demand. Adding llms.txt changes nothing that robots.txt allows and submits nothing for indexing; removing a sitemap does not make llms.txt do its work.

Which crawlers a hotel allows is a separate decision with its own consequences. Keep that decision in robots.txt and do not try to make llms.txt carry it. A hotel can reasonably have all three files, or only robots.txt and a sitemap, and still be found.

Does Google read llms.txt?#

No. Google's own documentation says Google Search does not use llms.txt, and lists it among the things site owners can ignore for Google Search.

The statement is in Google's Guide to Optimizing for Generative AI Features on Google Search (opens in a new tab), announced on the Search Central Blog on 15 May 2026 in a post by John Mueller and last updated on 10 July 2026. The guide puts "LLMS.txt files and other 'special' markup" among the items site owners can ignore, and gives three reasons: no new machine-readable files, AI text files, markup or Markdown are needed to appear in Google Search including its generative AI features; Google may crawl and index many kinds of files, which is not the same as treating one specially; and keeping the file for other services is fine.

It adds that the file will neither harm nor help a site's visibility or rankings in Google Search, because Google Search ignores it. A separate page, AI features and your website, last updated 10 December 2025, says there are no additional requirements to appear in AI Overviews or AI Mode and no need for new machine-readable files.

What we could not establish: no provider documentation we can cite says an assistant reads the file. Until you see that statement in the provider's own documentation, with a date, treat the claim as unproven. Absence of evidence is not proof of absence; a file that takes an hour to write is not a mistake, but a promise attached to it is.

Documentation changes. Check the guide's last-updated date before you repeat this to a client or an owner. For the wider picture of what changes when travelers ask instead of browse, see our article on how AI search changes what a hotel website has to do, and the AI search terms hotel marketers keep meeting.

What would a hotel put in its llms.txt?#

A short list of the pages that answer a traveler's real questions: rooms, facilities, policies, location, contact and the booking page. It is a map, not a copy of the site.

Keep it small. For a single hotel, ten to twenty links is plenty; a long file is a maintenance debt, not a signal. Link the page that answers the question, not the home page, and use absolute addresses on the live domain.

Write the note after each link as a fact, for example "check-in from 14:00", not as a slogan. Do not put live rates in the file: rates change, and a stale number is worse than no number. Point at the booking page instead.

Publish Markdown copies of pages only if you can keep them identical to the HTML page; a second copy is a second thing to maintain. Put secondary links, such as a blog or a press page, under a section called Optional. Test the file before you ship it: open every address in it in a private browser window and confirm each one loads.

If you have not yet written down the hotel's core facts in one place, start with the hotel fact sheet an AI assistant needs first, and check the pages against the hotel website checklist for content and the booking path.

Who keeps the file current?#

The same person who owns the hotel's fact sheet, on the same review calendar. A stale file points at pages that moved, which is worse than having no file.

One owner, one source: if the fact sheet and the file are maintained by different people, they will disagree within a season. Set review triggers rather than a vague intention: a new room type, a renamed restaurant, a changed check-in time, a new domain, a site redesign, a new booking engine.

Keep the file in the website's repository or content system, not in a personal folder, so it survives staff changes and agency changes. If an agency builds the site, write the handover into the agreement: who edits the file, where it lives, how a change is requested and how quickly. A monthly link check takes minutes and catches the most common failure, which is a page that moved after a redesign. Date the file, or note its last review somewhere the owner can see it, so an old copy is obvious.

What matters more than the file?#

The pages themselves. An assistant quotes the page it read, and a map that points at contradictory pages only makes the contradiction easier to find.

Two check-in times, two phone numbers or an old address produce a wrong answer whether or not an llms.txt file exists. One fact, one value, one owner: the fact sheet holds the value and every page, profile and booking engine entry copies it.

The file and the pages must agree. If the file says check-in from 14:00 and the page says 15:00, you have created a second inconsistency. Order of work: fix the facts first, then add the file. Doing it the other way round publishes the mess faster.

Check the places you do not control as well: the profiles your agency or a former employee set up years ago still get read. This is the part that costs attention rather than money, and it is the part that changes what a traveler is told. For the full method, see keeping your hotel's facts consistent wherever an assistant reads them.

What to do next#

Before you accept or reject the file, ask the person proposing it for the provider documentation and its date, then open your own pages and check that one set of facts is repeated everywhere. If you still want the file, list the pages from the checklist, name one owner next to the fact sheet, and treat it as a map that helps only when the pages behind it agree.