Answer in brief
A hotel website sells something the guest cannot touch before arrival. Here are the eight jobs a generic company site never has to do: room pages, rates, the booking engine handover, photography, languages, directions, cancellation terms and mobile.
What a hotel site does that a company site does not
A company website explains who you are. A hotel website has to carry a guest to a reservation: they pick dates, a room and a price, and they leave either into a confirmation or towards the place down the street whose page answered faster and more clearly.
The difference is not visual. It is the set of decisions a guest makes on the way: which room this is, what the price includes, what it costs on those particular dates, whether it can be cancelled, and how to get to the door with a suitcase.
None of those questions ever reach a company site. That is why the familiar home, about, services and contact structure looks tidy on a hospitality project and quietly fails: it does not lead to a single one of those decisions.
What follows is one section per decision: rooms and rates, availability, photography, languages, directions, cancellation, reviews and the phone most bookings start on. Not one of them can be replaced by a better about page.
Room types and rates: a page read like a product
A room is a product page, not a paragraph inside a services section. It needs a name, occupancy, floor area, beds, the view, what the price includes and what separates it from the room next door in the same category.
Giving each room type its own page solves two problems at once. Guests compare in lines rather than in guesses, and search gets a specific answer to a specific query: a question about a double room with a balcony is answered by the room page rather than the home page.
A rate is not the same thing as a room. The same room sells as non-refundable, with breakfast, with a late checkout, and the difference between those has to be readable in two lines beside the price instead of a footnote in small type.
A guest house with four rooms needs this as much as a hundred-room hotel does. The smaller the choice, the more each room has to be described to the end, because a guest cannot simply settle for a similar one instead.
Availability and the booking engine handover
A hotel website rarely works out free dates on its own. That normally sits with the booking engine or the property management system, and the site's job is to deliver the guest there with dates, guest count and room type already selected.
The weak point is the handover itself. When the calendar on the page and the calendar in the engine live apart, the guest picks dates twice, and at the second step some people close the tab, convinced they have landed somewhere else.
So the date form belongs on the first screen, and its values are passed to the engine through link parameters. The guest sees a continuation of their own choice rather than a fresh form, and the move between two systems stops feeling like a break.
It is worth deciding separately what happens when the answer is no availability. Nearby free dates or another room type keep the conversation alive; an empty screen sends the guest back to search, where they are no longer looking at you.
Photography is the actual product
A guest cannot touch a room before arrival. All they have are pictures, so photography here is not page decoration but the product itself, and its quality moves the decision more than any sentence written beside it.
A useful minimum per room type is a wide shot, the bed, the bathroom, the view and the detail people choose that room for. Five honest frames work better than twenty near-identical angles taken on a very wide lens.
Shared spaces are photographed separately: the entrance, the desk, breakfast, the courtyard, the stairs. Guests assemble a sense of the place from those, and check whether the picture will match what they see stepping out of a taxi on your street.
Large images are the main reason a page loads slowly on a phone. Serve them in modern formats and in several sizes for different screens, or a beautiful gallery turns into the reason someone leaves before the price.
Guests arrive speaking different languages
A property almost always sells beyond its own language. An English version is the minimum, and after that the choice follows where guests actually travel from: one house needs Chinese, another French, a third is fine with two languages.
Translation is not only page copy. Rate names, cancellation terms, photo captions, confirmation emails and the booking engine itself have to speak the guest's language, otherwise the translation breaks off at the single most important step.
Technically each language version gets its own address, and the versions are tied together with hreflang annotations; Google documents that mechanism in its guidance on localized versions of a page. Unconnected versions compete with each other instead.
Currency and date format belong to the same question. The string 03/04 reads differently in London and in Saint Petersburg, and on a booking page that difference costs more than it does anywhere else on the site.
Maps, directions and the question of getting there
An address is not the same as directions. A guest with a suitcase wants to know how long the ride from the station and the airport takes, by what transport, where exactly the entrance is, and what to do arriving at three in the morning.
So the contact page carries a map with a pin, a short written route from two or three transport hubs, and a photograph of the entrance. That last one saves guests more time than it appears to, especially in courtyards and on long streets.
Parking, a lift, steps at the door, step-free access: these are not small print but reasons to decline. If they are not written down, some guests simply choose the place that wrote them down, and you never hear about it.
The property's own details are worth repeating in structured data. Schema.org defines the Hotel type as a specialisation of LodgingBusiness, which hands search the address, phone and opening hours in machine-readable form rather than as an image.
Cancellation terms that do not turn into an argument
Cancellation is the most-read condition on a hospitality site and the most frequent place a dispute starts. A guest has to understand it before paying rather than from an email afterwards, and understand it on the first reading, without a legal dictionary.
The wording works when it carries a deadline, an amount and an action: until when cancellation is free, what is held after that moment, and exactly how to cancel, whether by a link in the email, by phone or inside the engine.
When there are several rates, the terms are written beside each of them rather than as one paragraph in the footer. A non-refundable rate is cheaper precisely because its condition is different, and that has to be visible while choosing, not after paying.
The same holds for check-in and check-out times, deposits, pets and children. Somebody searches specifically for each of those rules, and each is better kept on its own line so it can be found by eye in a second.
Reviews and what you can show on your own pages
Reviews on your own site do work, but other platforms remain the main place people read them. It is sensible to show yours and not pretend that scores collected elsewhere do not exist, because a guest will check both sides anyway.
Two things need to stay distinct: a review left with you, and a rating collected on another platform. The first is your content, the second is a quotation, and platforms keep their own rules about displaying their scores off-platform.
Google documents review markup separately, and it is not there to lift a score. It exists so the reviews you already have are read by a machine the way a person reads them, and appear in results in an intelligible shape.
The most honest way to work with reviews is to answer them and fix whatever repeats inside them. Then the site shows exactly what happens in the house, and that turns out to be its strength rather than its risk.
People book on phones, so the phone is the primary version
Guests look for rooms in transit, in the evening, on somebody else's Wi-Fi. Google indexes and ranks pages from the mobile version, which its mobile-first indexing documentation sets out, and for a property that is not an abstract point.
In practice it means dates chosen with one thumb, a price visible without scrolling, a phone number that dials, a map that opens, and a gallery that does not eat mobile data. Everything else on the page is discussed after that list.
This is worth testing on a real phone over a slow connection rather than on a mockup in a wide window. The gap between working and working on the designer's iPhone shows up right there, usually within a couple of minutes.
VITON13 builds these sites remotely from Saint Petersburg: the room and rate structure, the engine handover, language versions, structured data and the mobile layout. Some tasks inside a project run with AI under human direction, from $13 to $113.
Practical checklist
- Give every room type its own page with occupancy, size, beds and what the price includes.
- Describe each rate separately: what it covers, what it excludes and how it differs from the next one.
- Confirm that dates chosen on the first screen reach the booking engine without being typed again.
- Shoot at least five honest frames per room type and serve them in modern, lightweight formats.
- Write directions from the station and the airport, photograph the entrance and state the parking situation.
- Put cancellation terms beside the price: the deadline, the amount held and the way to cancel.
Questions and answers
How is a hotel website different from an ordinary company site?
By its purpose and by the decisions it has to carry. A company site explains who you are; a hospitality site walks a guest to a reservation. Along the way the guest decides which room, what the price includes, what it costs on their dates, whether it can be cancelled and how to reach the door. A company site is never asked any of that, so it is built differently.
Does every room type really need its own page?
Yes, for two reasons at once. Guests compare rooms line by line rather than through one general description, and a dedicated page puts occupancy, size, beds, view and the price contents in a single place. Search needs that page too: a query about one specific room type is answered by the room page, not by the home page.
Should the website calculate availability itself?
Usually not. Availability lives in the booking engine or the property management system, and the website's job is to bring the guest there with dates, guest count and room type already chosen. The fragile part is not the calculation but the handover: when a guest has to enter dates a second time, some of them leave at exactly that step.
How many languages does a guest house site need?
As many as the guests actually arrive with, and English at minimum. Completeness matters more than the count: rate names, cancellation terms, photo captions and confirmation emails all have to speak the guest's language. A translation that stops just before the booking form does more harm than no translation at all.
Where should cancellation terms appear on the site?
Beside the price and beside each rate, not as one paragraph in the footer. The wording works when it carries a deadline, an amount and an action: until when cancellation is free, what is held afterwards and exactly how to cancel. It is the most-read condition on a hospitality site and the most common source of a dispute.