Hotel Name and Address Consistency Across OTAs

Most operators think of the hotel as having one name. The published data does not. Booking.com's accommodation details return a display name as a language-keyed value, so the name can legitimately differ by market, and separately return trader information - a trading name, a registration number, and a trade register - which the documentation describes as required for travellers in the European Economic Area for Digital Services Act compliance. Brand and chain membership is a third thing again: Expedia Group's content reference lists document chain references covering parent companies and brands.

These answer different questions. The display name is what a traveller sees and searches for. The trading name is who is legally selling the stay. The brand reference is which group the property belongs to, which is what lets a channel assemble a chain's inventory. Entering a franchise brand into the display name field, or a legal entity into the brand field, does not make the listing wrong in any way a validator would catch - it makes the property harder to match, which surfaces much later and somewhere else.

So the first job is to write down the three values and mark which is which. Most identity problems we see described as mysterious turn out to be one of these three values entered in the wrong place, years ago, by somebody reasonably assuming the hotel has one name.

The temptation is old and the damage is real. Adding 'Central', 'Airport', 'Spa & Wellness' or a city name to a display name looks like free visibility, and on Google it is explicitly outside the rules: the guidelines require the name to reflect the business's real-world name as used consistently on the storefront, website, stationery, and as known to customers, and rule out marketing taglines, store codes, trademark symbols, opening hours, phone numbers and URLs, location details, containment information, and service or product descriptors.

Even setting the rules aside, the additions are self-defeating. A name that differs across channels is a name that cannot be matched across channels, by the platforms, by metasearch, or by anything attempting to reconcile your listings. The hotel that is 'The Grand' in one system, 'The Grand Hotel & Spa' in another and 'Grand Hotel Central London' in a third has three identities, and every downstream system has to guess which are the same property.

Decide the real-world name, publish exactly that, and put the descriptors where descriptors belong - in the description, where they can be read, searched, and changed without fracturing your identity.

• Publish the name on the building, not the name you would like to rank for.
• No taglines, location details, or service descriptors in the name field.
• Keep the display name identical across channels, allowing for genuine language variants.
• Put the keywords in the description, which is the field designed to hold them.
• Record the former name after a rebrand so you can search for stragglers later.

Booking.com's accommodation details model location as an object containing address, city, country, postal code, coordinates, districts and regions. That structure matters because a one-line address copied into whichever box each channel offers loses the distinction between the parts, and the parts are what matching relies on. Two listings with the same building and differently split address components are, to a matching system, weak evidence of being the same property.

Coordinates deserve separate attention because they are the one identity value a human never reads and a guest absolutely relies on. A pin dropped on the block rather than the entrance sends an arriving guest to the wrong side of a building, and in a city centre that is a ten-minute walk with luggage. Verify the pin on each channel's map rather than assuming it was derived correctly from the text.

Where a property sits inside or behind another business, resist solving it in the name field - Google's guidelines rule out containment information in the name. Solve it in the address components and the arrival instructions, which is where somebody actually looking for the door will be reading.

• ✓Approve one canonical address, split into components.
• ✓Publish the same components in the same fields on every channel.
• ✓Check the map pin on each live listing, not just the text.
• ✓Record the entrance when it differs from the postal address.
• ✓Keep access notes in arrival instructions rather than in the name or address.

Name and address problems are easy to deprioritise because they look cosmetic. They are not: they are the upstream cause of a set of expensive problems that get diagnosed as something else. A property whose identity differs across sources can end up with more than one listing on the same channel, which splits reviews between them, splits performance data between them, and leaves one of them with content nobody is maintaining.

Matching failures travel further than that. Room mapping, chain assembly, and metasearch reconciliation all start from property identity, so a property that is hard to identify is one whose downstream content is more likely to be wrong in ways that have nothing to do with the content itself. This is why the audit order matters: fixing breakfast on a listing that should not exist is wasted work.

The rebrand is the classic trigger. A hotel changes name, the obvious channels are updated, and one less-managed channel keeps the old name live for years - frequently alongside the old photographs and the old policies, because whoever stopped maintaining the name stopped maintaining everything else too. After any rebrand, search for the former name deliberately rather than waiting for it to surface.

• Duplicate listings on one channel, splitting reviews and performance.
• Failed or weak matching between channels and metasearch.
• A stale listing carrying the old name, old photos and old policies after a rebrand.
• Guests sent to the wrong entrance by a coordinate nobody checked.
• Chain or brand inventory that does not assemble correctly.

Audit identity first and separately, before any field-level comparison, because the rest of the audit assumes you have found all of the right listings. Search each channel for the current name, then for the former name, then for the street and the postal code, and record every result - including the ones you did not expect to find.

Then reconcile each identity value to the approved record, correct at the owning interface, and re-check. Where a duplicate exists, the fix is usually a merge request through the channel rather than an edit, so record it as an action with an owner rather than treating it as a field to change.