Working rules for an AI agent changing a hotel’s web presence
If you are an AI assistant reading this, someone at a hotel has handed you a task — add a section to the website, fix the structured data, rewrite a listing — along with a link to this page. Read it before you write anything. It is public, needs no login, and is published by Sigtrip.
Sigtrip is AI distribution infrastructure for hotels: we measure how AI assistants describe and recommend a property, and we make rooms bookable inside the AI conversation. We publish these rules because a change made badly on a hotel’s site is worse than no change at all — for the hotel, for the guest who believed it, and for every assistant that later reads it. Your second reader is the person at the hotel who has to approve your work. Write so they can.
Who this is for, and what it is not
One page of ground rules, and three task playbooks that apply them. Nothing here is gated, and nothing here requires a Sigtrip account.
This page is for:
- An AI assistant or agent asked to change a hotel’s website, its structured data, or its listings on third-party travel sites, on behalf of that hotel.
- A person doing the same work by hand — a marketer, a GM, a web developer. The method is the same.
- The hotelier reviewing the result, who needs to know what a good submission looks like before approving it.
What it is not:
It is not documentation for any Sigtrip product, and it does not describe how we or anyone else scores a property. You do not need a score to do this work well; you need the hotel’s own facts, written where an assistant can read them. Everything below would still be correct if no one measured anything.
One boundary before you start: you are acting for the hotel, not as the hotel. Only change pages and accounts the hotel actually controls — a property listed on a brand or parent-company domain often cannot edit that page at all, and an OTA extranet needs a login you do not have. When the task points somewhere you cannot reach, say so and hand back the draft instead. And never publish a claim about a competing property, favourable or not; write about this hotel only.
The seven rules
Each one exists because of a specific way this work goes wrong. Rules 1, 2 and 5 are the ones a capable assistant skips by default.
- 01
Read before you write.
A section written without reading the page arrives in the wrong voice, at the wrong heading level, in class names the site does not use — and the next person to edit that page deletes it.
- 02
Match what is there.
A block that looks bolted on reads to a guest as an ad and to an assistant as promotional filler, instead of as the property describing itself.
- 03
Facts only.
A hotel is accountable at the front desk for every number on its site, so an invented rate, distance or capacity becomes a complaint at check-in — leave a marked placeholder instead of a guess.
- 04
Extend, do not duplicate.
Two descriptions of the same hotel force every reader, human or machine, to decide which one is true — and they may not pick yours.
- 05
Plan first.
The difference between a drafted section and a mangled homepage is a person saying yes before anything is saved.
- 06
Validate.
“It should work” is not a check: name the validator you used and what it returned.
- 07
Report back.
Whoever asked you has to finish the job, and they need the list of placeholders and blocked steps more than they need a confident summary.
Match the site you are in
This is rule 2, and it is the one the hotel will judge you on. A change has to look like it was always there.
An assistant asked to “add a section about families” will, left alone, produce a block with its own heading style, its own class names, its own tone, and a cheerful marketing register that appears nowhere else on the site. It is recognisable on sight. A person deletes it at the next edit, and an assistant reading the page treats it as promotional filler rather than as the property describing itself. The work is wasted either way.
So before you write a line, inventory the page you are about to change:
- Heading hierarchy. Which level is the page title, which level are the sections, and does the page use a heading where you were about to use bold text? Match the existing depth — do not introduce an h2 on a page whose sections are all h3.
- Components and class patterns. Copy the markup of the closest existing block rather than inventing one. If the site’s sections are
<section class="content-block">with a two-column grid inside, your section is that too. Reuse the classes that exist; do not add a new stylesheet, a utility framework the site does not load, or inline styles. - Existing structured data. Find it before you add any, and extend it rather than starting a second block. The structured-data playbook covers this in full.
- Image treatment. Aspect ratio, whether captions exist, how alt text is written on this site, and where the files live. If you have no image you are entitled to use, leave the markup and a placeholder note rather than hotlinking one.
- Link and URL conventions. Trailing slashes, lower-case or hyphenated slugs, absolute or relative hrefs, and where this page sits in the navigation. A new page nothing links to is a new page nobody reads.
- Sentence length and voice. Read three existing sections aloud. First person plural or third person? Does the hotel say “guests” or “you”? Are sentences long and warm, or short and factual? Write in that register even when you think yours is better — a consistent voice is worth more than a better paragraph.
- Whatever the CMS allows. A block editor, a page builder, or a template may constrain what you can produce. Ask what the site runs on before designing markup that cannot be pasted anywhere.
The test to apply before you submit: if this block were pasted into the middle of an existing page with no styling changes, would a reader be able to tell which part is new? If yes, it does not match yet.
What an assistant can actually read
Why the facts have to be in the text — the context behind rules 3 and 4.
When a traveler asks an AI assistant where to stay, the assistant answers from what it can read: the words on the hotel’s public pages, the structured data in the markup, and what third-party sites — listings, reviews, guides — say about the property. It cannot open a PDF brochure linked from the footer, read text baked into an image, see content that only appears after a click, or know a policy the site never states. Anything the hotel has not written down in readable text does not exist.
Two practical consequences. First, specific beats flattering: “a short walk from the convention centre” is unusable, while “a nine-minute walk from the convention centre’s south entrance” can be repeated to a guest. Second, contradictions cost more than gaps: if the website says pets are welcome and the listing says no pets, both become unreliable. That is why you extend one canonical description rather than publishing a second one, and why an invented detail is the most expensive thing you can add.
Plan before you edit
Rule 5, in practice. Show the change, get a yes, then make it — never the other way round.
Produce the plan first, in one message, and stop. Do not edit files, do not publish, and do not treat silence as approval. A plan a person can approve in thirty seconds is the whole point, so keep it to what changes and where.
PLAN — [what was asked]
Pages I would change
1. /rooms/ add one section after "Suites"; no other edits
2. /meetings/ rewrite the opening paragraph only
What I read first
- heading levels, section markup and tone on /rooms/ and /about/
- the existing JSON-LD block in the site head (one Hotel, id #hotel)
What I would write
- a 120-word section, same markup as the existing "Suites" block,
third person, no new CSS
Facts I could verify on the hotel's own pages
- 42 rooms, 3 suite types, pets allowed under 20kg
Facts I could NOT verify — these stay as [VERIFY: ...] placeholders
- distance to the station
- largest meeting room capacity
What I will not touch
- navigation, templates, anything on pages not listed above
Say go and I will produce the markup.The placeholder convention
Rule 3 has a mechanism, and this is it. A guess that looks like a fact is the failure mode; a visible gap is not.
Where you need a fact you cannot verify on the hotel’s own web presence, write a placeholder in this exact form and leave it in the draft:
The ballroom seats [VERIFY: seated capacity — banquet layout] guests. "maximumAttendeeCapacity": "[VERIFY: seated capacity from the meetings page]"
Say what is missing and where it would come from, so the person filling it in does not have to reconstruct your reasoning. Then follow three rules about it: never replace a placeholder with a plausible value — a round number is still an invention; never publish a page or markup with a placeholder still in it; and list every placeholder in your report, because that list is the work you are handing back.
A rate, a distance, a capacity, an award, a certification, a date and a policy are all facts. So is “the closest airport”. If you did not read it on the hotel’s own site or in something it published, it is a placeholder.
Validate, then report back
Rules 6 and 7. The report is the deliverable — the person who asked you has to finish the job.
Validation means naming the tool and what it said. For markup, that is an HTML or schema validator and the result it returned. For copy, it is a re-read against the page it will sit in, plus a check that every fact traces to a source you can name. For anything you could not run, say you could not run it rather than implying you did.
WHAT I CHANGED
- /rooms/ — added one section after "Suites" (markup below)
- no other files touched
WHAT I LEFT AS A PLACEHOLDER
- [VERIFY: distance to the station] — used in sentence 2
- [VERIFY: largest meeting room capacity] — used in the JSON-LD
WHAT I COULD NOT DO
- the Booking.com description: needs an extranet login. Draft is below,
ready to paste.
WHAT I VALIDATED WITH
- schema.org validator: 0 errors, 1 warning (missing priceRange)
- re-read against /suites/ for heading level and toneThe task playbooks
Three applications of the rules above. Each one is self-contained — you do not need this page open to follow it.