Give it a Hotels.com hotel URL and get that property's guest reviews back as rows: the reviewer, the rating, the date, the headline and the full review text. Four sort orders are chosen before the run - most relevant, most recent, highest guest rating or lowest - so you can pull the complaints without paying for the compliments.
The input is the property, not the review - you name the hotels you want feedback on, pick the order, and the job collects what their guests wrote.
One row per review, each tagged with the query it came from - so a run across fifty properties still reconciles back to your input list.
Most relevant, most recent, highest guest rating or lowest. Put the sort on lowest with a small limit and the first rows in the file are the complaints - the part you were going to read anyway - instead of a whole review history you have to sift afterwards.
Guests write a short verdict and then explain it, and the two arrive as separate columns - title and review. The body comes back verbatim with no preprocessing, so downstream sentiment work reads the guest's own wording rather than ours.
There is no hotel name column and no property id in this export - six columns, and query is the only one that ties a row back to a property. That is worth knowing before you design a table: keep the URL you submitted, because it is what a run across many hotels reconciles against.
Each row carries the review as Hotels.com displays it: who wrote it, the rating, the date, the headline and the full text.
Review text comes back verbatim, with no preprocessing applied. The column list below is the platform's own, and both download paths - JSON and Excel - project through it in the same order, so the file you get carries these six names whichever button you press. Read the note under the table before you write a parser: the names are verified and the value formats are not.
The platform's own column list, in export order, confirmed identical across the JSON and Excel download paths. Descriptions say what each field is for; they claim nothing about its format - see the note underneath.
Read this dictionary as a list of names, not a promise about contents. The six names and their order are solid: they come from the platform's published column list, and the JSON and Excel downloads both project through that same list in that same order. What is not settled is the shape of the values, because we hold no archived Hotels Reviews export at all - not an empty one, not a full one. So this page states no date pattern, no rating scale or range, and no fill rate for any column. query is the exception the mechanism guarantees: the scraper writes it rather than reading it off the page, so it is on every row. Pull a free run and read the first rows before you assume anything else.
A per-query limit decides what a run costs and how much lands in the file. The sort order decides which reviews that limit spends itself on - both are chosen before the job starts.
A few examples of how teams use guest review data to answer a question they actually have.
Pull your own property sorted by lowest guest rating with a modest limit. You get the complaints at the top of the file rather than at the bottom of a full history, which means the read is short and the credits went where the problem is.
Export every hotel on a corridor or in a district and compare what guests actually wrote side by side. Useful before a refurbishment, and useful afterwards for knowing who you are really losing bookings to.
Verbatim reviews across dozens of properties make recurring failures visible as repeated language - noisy, dated, overpriced - instead of as a rating that drifted a tenth of a point. The headline column doubles as a ready-made summary of each one.
No subscription, no minimum, no recurring bill. Your first 500 rows are on us - after that, pay-as-you-go at the same flat rate as every other scraper here.
Every new account, one-time. No credit card required. Per-query limits, every sort order, file upload and every export format included.
Roughly $2 per 1,000 reviews. The pre-flight estimator shows the row count and credit cost before a run starts - no surprise bills, no compute units to translate.
Volume pricing, dedicated workers and an SLA for continuous monitoring or very large historical pulls. Tell us your numbers and we will quote.
LIVESCRAPER10 at checkout.The same hotels as travellers rate them elsewhere, with two columns this one does not have: the kind of trip the reviewer was on, and the language they wrote in.
The other half of where people sleep. Running both across a destination shows whether a complaint is about the property or about the category.
Short answer: yes for the public review content - and this export carries nothing about the booking behind it.
Guest reviews on Hotels.com are published to be read. The rating, the headline, the review text and the date are shown to anyone who opens the property page, signed in or not. Collecting publicly visible feedback for research is long-established practice, and nothing here touches a login, a booking or a paywall.
The reviewer field carries what the site itself publishes, which is a display name rather than a full identity - there is no email and no address in this output. Nothing about the stay behind a review is collected either: not what was paid, not the dates, not the room. If you are processing the review text in the EU, the usual rules still apply to what you do with it downstream.
Hotels.com's own terms restrict automated access, so this is a terms question as well as a legal one - if you have a contractual relationship with the platform, check it. We run no third-party trackers on the data layer, and your exports auto-delete after 30 days.
The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.
500 one-time free rows on every new account - no expiry. After that it is $0.002 per row, pay-as-you-go - no card on file until you say so.
Livescraper's Hotels Reviews Scraper turns a list of properties into review data. You submit Hotels.com hotel URLs - typed one per line, or uploaded as a CSV, XLSX, TXT or Parquet file - cap the rows per query or leave the limit empty to fetch all, choose the sort order, and download what guests wrote as a clean CSV, Excel or JSON file.
Each row carries the review as Hotels.com displays it: the reviewer, the rating, the date, the headline and the full review text. The headline and the body stay separate columns, so the short verdict a guest writes above the explanation is available on its own - and the body arrives verbatim, with no preprocessing, so downstream sentiment work reads the guest's wording rather than ours.
The sort order is the control that decides what a run is worth. Most relevant, most recent, highest guest rating or lowest: put it on lowest with a modest limit and the complaints land at the top of the file instead of at the bottom of a full history. Hotels use that to read their own worst feedback first; strategy teams export a whole corridor and benchmark what guests actually wrote; researchers read verbatim reviews across dozens of properties, where recurring failures show up as repeated language rather than as a rating that drifted a tenth of a point.
One practical note up front: this page describes the six columns and their order, which the platform's published list and both of its download paths agree on exactly, but it claims no date pattern, no rating scale and no fill rates, because no archived Hotels Reviews export exists to base them on. Pull a free run and read the first rows before you build against it. Your first 500 rows cost nothing and need no credit card, and after that it is $0.002 per row, flat.