Common Hotel OTA Listing Mistakes

A public page may omit a field for several reasons that have nothing to do with the property's offer. The value may never have been supplied, it may be mapped differently by that platform, it may be inherited from a connectivity provider that has no value for it, or the page may simply not have been readable when the evidence was captured.

Recording that blank as a negative is how an audit ends up recommending that a property 'add parking' it has had for years, or flagging a pet policy as a conflict when one channel is silent. Worse, a team that acts on such a finding may edit a listing that was correct.

The fix is a vocabulary discipline. Missing evidence and a negative value are different findings with different actions: one means publish the fact, the other means the fact is already published and disagrees. Keep them in separate categories throughout the audit.

• Record 'no value found' as its own state, distinct from 'no'.
• Distinguish a blank field from a page that could not be read.
• Confirm the real value in your own records before publishing anything.
• Never let a blank on one channel override a stated value on another.

Parking, breakfast, accessibility features, and most amenities can apply at property level, at room level, or to a specific rate plan. Comparing a value captured at one scope against a value captured at another produces a conflict that no edit can resolve, because neither listing is wrong.

Google's lodging model and Expedia's content references both separate these scopes explicitly, which confirms that the distinction is built into the data rather than being an artefact of how a particular hotel keeps records. An audit that ignores scope is arguing with the data model.

The tell is a conflict that reappears after every correction. If a finding keeps coming back despite the field being edited, check whether the two sides are describing different scopes before editing again.

A change to breakfast service, pet rules, parking fees, or arrival times is an operational decision with a distribution consequence, and the consequence is routinely forgotten. The decision is made, the channel that prompted it is updated, and the remaining listings keep publishing the previous policy until a guest notices.

Illustrative example: if a property's approved check-in time moves from 14:00 to 15:00, an older public page showing 14:00 should be logged as outdated evidence — not used to guess which time is correct, and not left in place because it is 'close enough'. A guest arriving at 14:15 on the strength of that page is the cost.

The fix is procedural rather than technical. Attach a distribution checklist to whatever process already approves these changes, so updating the channels is part of the decision rather than a task that depends on someone remembering.

• Attach a distribution checklist to policy, fee, and seasonal changes.
• Record the effective date so stale evidence can be identified as stale.
• Verify the guest-facing result rather than assuming a sync succeeded.
• Re-check after promotions end, not only when they start.

A number on its own does not tell a guest what they will pay. A pet fee of twenty is per night or per stay; a breakfast price is per person or per room; a parking charge is per night or per entry; a deposit is refundable or it is not. Each of those pairs produces a materially different bill from the same headline figure.

This is the mistake most likely to reach the front desk as an argument, because the guest has read something specific and is being charged something different. It is also among the easiest to fix, since the information already exists — it simply was not published with the amount.

When auditing, treat amount, currency, and basis as three values rather than one string. A channel with the right amount on the wrong basis will pass a naive text comparison and fail a guest.

• ✓Publish amount, currency, and basis together in every fee field.
• ✓Distinguish a refundable deposit from a non-refundable charge.
• ✓State per-person versus per-room, and per-night versus per-stay, explicitly.
• ✓Test a worked example against what the desk would actually charge.

'€25 per night', 'EUR 25 nightly', and '25 euros / day' describe the same charge. '3:00 PM' and '15:00' are the same time. An audit that reports these as conflicts fills its own output with noise, and a team that has waded through twenty non-findings will not look carefully at the twenty-first, which is real.

Normalise currency symbols, whitespace, capitalisation, boolean wording, and time formats before comparing — but do not normalise away a qualification. 'From €25' is not '€25'. 'Free for members' is not 'free'. 'Subject to availability' is not 'available'. The difference between a formatting variant and a material condition is the line the normalisation must not cross.

Keep the original wording as evidence alongside the normalised value. The normalised form is what you compare; the original is what the guest reads and what you will need if you escalate.

• Normalise format, not meaning.
• Treat 'from X' and 'X' as different values.
• Keep conditions such as 'subject to availability' visible.
• Retain original wording and source URL beside every normalised value.

The most damaging mistake is not in the listings at all. An audit that quietly drops a source it could not read, or that counts a single readable listing as agreement, reports a clean result for a property that has never been checked. That is worse than no audit, because it stops anyone looking.

A field is only consistent if at least two sources were successfully read and contain comparable evidence for it. One source is not agreement; it is a single data point. Zero readable sources is not a pass.

Insist that any tool or spreadsheet you use keeps failed and partial sources visible in both the score and the explanation. If a report cannot tell you what it could not check, you cannot act on what it does tell you.

• Require at least two successfully read sources before calling a field consistent.
• Show failed and unreadable sources in the result, not only in a log.
• Never convert unavailable evidence into a positive finding.
• Treat a high score from few sources as low confidence, not good news.

Booking.com publicly describes a range of factors — performance, commercial, availability, pricing, review, policy, and content — that can influence how properties are ordered. That public explanation does not assign numerical weights, and it does not support a claim that a specific edit will move a property a specific number of positions.

Airbnb's standards for hotels and professional hospitality businesses similarly set out what listings are expected to provide. A platform requirement is evidence of what you should publish; it is not evidence of what publishing it will earn you.

The practical risk is internal as much as external. A team told that a content fix will produce a ranking gain will judge the work by whether the gain appears, and will abandon a genuinely valuable accuracy process when it does not. Make the case on accuracy, which is verifiable, rather than on an uplift that is not.