Auditing a hotel, travel or booking website

Three detected categories run the same module: hotel, travel and booking. The category engine recognises a hotel from `Hotel`, `LodgingBusiness` or `BedAndBreakfast` markup, room paths such as `/rooms` or `/chambres` and wording such as "per night" or "check-in"; a travel site from `TravelAgency`, `TouristAttraction` or `Trip` markup and paths such as `/destinations` or `/tours`; a booking site from `Reservation` or `ReserveAction` markup and paths such as `/booking` or `/appointments`.

Schema.org types add 30 points, paths 12 and wording 8, and a category needs 24 points. A hotel with a restaurant can be detected as both and receive both modules.

No link or page leading to a booking engine — `book`, `booking`, `reservation` — is reported at high severity: for a hotel, it is the one path that turns a visit into revenue.

Room pages are found by URL — `/rooms`, `/chambres`, `/suites` — and each one without a recognisable price is reported at medium severity. When no room page was reached, the module says so instead of reporting missing rates.

No `Hotel`, `LodgingBusiness` or `BedAndBreakfast` markup anywhere is reported at medium severity, as is the absence of a postal address in markup. No `tel:` link is reported at low severity, because on a phone a number that cannot be tapped is a number people do not call.

No cancellation wording — "cancellation", "free cancellation", "non-refundable", "annulation" — is reported at medium severity, and no date or availability wording such as "check availability" or "select dates" at low severity.

`structure.cta` expects a booking or phone action — book, phone or contact — on all three categories, and reports its absence. `structure.faq` treats a FAQ as relevant for hotels, travel and booking sites, where questions about arrival, pets or payment are predictable.

Only the booking category is treated as a selling site. For it, the commerce checks weigh 1.3 times their base weight in the overall score, privacy, cookies and legal checks 1.2 times, performance, images and mobile 1.2 times and SEO and structured data 1.25 times, and the legal-document discovery expects refund and shipping documents.

Hotels and travel sites keep the default weights. The difference is intentional: the engine has evidence of a transaction only where it detected a booking flow.

Booking engines are often hosted by a third party on another domain. The rules look for a link to one; they do not audit the external engine, fill in dates, check live availability or reach a payment step.

Rates and availability are frequently loaded by JavaScript from that engine. The rules read the HTML the server returned, so a rate that only appears after a script runs can be reported as missing — which is also what a crawler that does not run scripts sees.

Every rule of the module reads the pages the crawl reached. Booking links are looked for in the `href` of every link, so a booking button that is a script handler rather than a link is not seen; room pages are found by their URL, and rates by a price pattern that recognises the dollar, euro and pound signs and the codes USD, EUR, GBP and CHF next to a number.

A rate written in another currency, or as words, is therefore not recognised as a rate. The finding names the page, so it is quick to confirm or dismiss.

The phone rule is stricter here than on a restaurant site: only a `tel:` link counts, because on a phone that is what turns a number into a call. The cancellation and date rules search the page text, the title and the first two levels of headings.

When a site is detected as a hotel and as a restaurant, both modules run and both sets of findings appear; the address rule, shared by both, is then reported by each module on its own terms.