How to Audit a Hotels.com Hotel Listing

The first thing to establish is that you are auditing a page nobody edits. Expedia Group's own listing page states that a property's listing will appear on brands including Expedia.com, Hotels.com, Travelocity, Orbitz and Wotif, and that Partner Central will be the primary location for managing reservations, loading inventory, changing rates, and keeping the listing up to date. One record, several consumer front-ends.

That single sentence resolves the question operators most often ask about this channel - where is the Hotels.com login - and it reframes the audit. The finding and the fix live in different systems. You read the problem on Hotels.com, you correct it in Partner Central, and then you come back to Hotels.com to confirm the correction arrived.

It also sets a limit worth knowing before you start: because the brands share a record, there is no documented way to make Hotels.com say something different from Expedia.com. If you find yourself wanting a Hotels.com-only wording, the answer is that the model does not offer one.

If both brands render the same record, it is tempting to check one and assume the other. That assumption is where this channel quietly goes wrong, because the two are separate public pages built by separate front-ends, and Expedia Group publishes no stated delay for a content change reaching its consumer brands.

Without a published propagation time, you cannot reason about how long to wait before concluding something is broken. What you can do is record the date and time you looked at each page, so that a difference you report is anchored to an observation rather than an impression. A difference that resolves on its own over a day or two was propagation; one that persists for weeks is worth raising.

There is a practical reason to prioritise the Hotels.com page rather than treating it as a sibling of lower importance: a guest booking on Hotels.com never sees the Expedia.com page. Whatever the record says, the page they read is the one that sets their expectation and the one they will quote at the desk.

• Check Hotels.com directly rather than inferring it from Expedia.com.
• Record the date and time of every observation on each brand page.
• Expect no published propagation window, so anchor conclusions to repeated observations.
• Treat the page the guest booked on as the authoritative statement of what they were told.

Audit the same factual fields you would on any channel, but record the scope each one belongs to, because that determines where the correction goes. Property-level facts describe the hotel: parking, Wi-Fi, reception, pets, facilities. Room-level facts describe a unit: beds, occupancy, size, in-room amenities. Rate-level facts describe what a particular booking includes: breakfast inclusion, cancellation terms, deposit and prepayment conditions.

The distinction matters more here than elsewhere, because a rate-level fact read from a property-level summary will look like an error on the page when it is simply the wrong place to be reading it. Before recording a finding, note whether you took the value from the property description, the room block, or the rate you were quoted.

Keep the exact public wording with every value. Normalising as you read - writing down 'free parking' when the page said 'parking available, charges apply' - destroys the evidence you will need when you raise the difference with anyone.

• Property scope: parking, Wi-Fi, reception, pets, smoking, facilities, address.
• Room scope: bed configuration, occupancy, room size, in-room amenities.
• Rate scope: breakfast inclusion, cancellation terms, deposits and prepayment.
• Record which scope each captured value came from, every time.
• Keep the original wording beside any value you normalise.

Breakfast inclusion and cancellation terms are the two fields most often reported as Hotels.com errors and most often not errors at all. Both usually belong to a rate plan rather than to the property, so the answer changes with the dates, the occupancy, and which plan the brand chose to display.

So search the same dates and occupancy you used on the other channels, and read the terms attached to the rate rather than the summary near the top of the page. If the rate you are quoted on Hotels.com and the rate you are quoted on Expedia.com are different plans, a difference in their terms is not evidence of anything.

Where you do find a genuine rate-level fault - a plan whose name promises breakfast that is not attached, or terms that do not match the plan as configured - the fix is in the rate plan in Partner Central, not in the property description.

• ✓Search the same dates, occupancy, and length of stay as on other channels.
• ✓Note which rate plan each brand displayed before comparing terms.
• ✓Read cancellation and breakfast terms from the rate, not the page summary.
• ✓Separate a plan difference from a plan fault before recording a finding.
• ✓Correct rate-level faults in the rate plan rather than the description.

Because the fix happens in a system you will have to ask someone else about if it does not work, the evidence has to be good enough to show them. Browse signed out, so you are reading the public page rather than a personalised one, and capture the URL, the date, the field, and the exact wording.

Screenshots are worth taking even when a copied sentence would do, because a page can change under you while a thread is open, and a dated image of the page as it stood is far harder to argue with than a recollection.

Keep the captures organised by field rather than by visit. The question you will be answering later is 'what did this field say on each brand on each date', and notes organised by visit make that reconstruction unnecessarily hard.

• Browse signed out, in a private window, to read the public page.
• Capture URL, date, field, and exact wording for every finding.
• Screenshot the page as well as copying the text.
• File captures by field, not by browsing session.

A difference between Expedia.com and Hotels.com is a specific and unusual finding, because the two are meant to render the same record. It is not something you can fix by editing twice - there is no second place to edit - so the response is to document it and report it.

Before reporting, rule out the ordinary explanations. Are both pages showing the same rate plan? Were both read on the same date? Is one of them a cached or regional variant? Those account for most apparent brand differences, and a report that has not excluded them will be closed without much ceremony.

If the difference survives that, it is worth raising with Expedia Group with your dated evidence. This is the one finding on this channel where the operator genuinely cannot act alone, and it is also the kind of problem that stays wrong indefinitely if nobody reports it.

• Confirm both pages showed the same rate plan and the same search.
• Confirm both were read on the same date, signed out.
• Re-check after a few days to separate propagation from a fault.
• Report a persistent difference with dated evidence rather than re-editing.

If a field you corrected in Partner Central returns to its old value, the record is not the source of truth for that field - something upstream is resending it. That is usually a channel manager or a property management system pushing content on a schedule, and it will keep overwriting the correction for as long as it holds the wrong value.

Diagnose it by the pattern rather than the field: a value that reverts within a day or two, repeatedly, after a manual edit is an integration rewriting it. A value that simply never changed is more likely to be a publication failure or a change made against the wrong property in a multi-property account.

Fix it at the system that owns the field, then re-run the same audit. Correcting the upstream system and never re-checking the public page leaves you with no evidence that the loop closed.

• Reverting repeatedly after manual edits points to an upstream integration.
• Never changing at all points to a publication failure or the wrong property.
• Correct at the system that owns the field, not at the last place you can type.
• Re-audit the public page after the upstream fix to confirm the loop closed.

Run the audit on the public page first and the portal second. That order matters: starting in Partner Central shows you what the record holds, which is not the question - the question is what a guest on Hotels.com is being told.

Our own London study is a useful calibration for how much of this is checkable at all. Across 35 properties, Hotels.com pages were readable for 30 of them, which puts this channel among the ones you can reliably inspect. That is a statement about our access on one run, not about the channel's accuracy - but it does mean that if you cannot read your own Hotels.com page, that is unusual and worth investigating on its own.