How We Choose Hotels

Last updated: May 2026

This page documents the exact criteria HotelScout uses to decide which properties make it into our catalog, how we sort them on destination pages, and what we do when source data changes. We publish this because trustworthy editorial means showing your work, not hiding it.

Data sources

Every property page draws from three independent sources:

Booking.com source feed — guest rating, category (hotel / resort / B&B / hostel / camp), amenities, property photos, room types, official location coordinates.
Wikidata — entity matching for cities, countries, and named points of interest (Q-IDs). This is how we cross-link an article about Rome to the “Rome” entity Google and other knowledge graphs already know.
OpenStreetMap — independent geo verification for coordinates and administrative hierarchy (region, district, neighborhood).

Inclusion criteria

A property is added to the catalog only when it passes every line below. Properties that fail any line stay invisible until they pass.

Guest rating — at minimum, the property must have a guest score from the Booking.com source feed. Properties with very low scores or without enough reviews to produce a reliable score are excluded.
At least 3 verified photos — every photo is re-hosted on our own CDN (cdn.hotels-world.net) so links don't break and we're not hot-linking third-party assets.
Verified coordinates and address — latitude, longitude, and a postal address must be populated. (0,0) coordinates or null addresses are an automatic reject.
City and country mapping — the property must cluster within one of our editorial destinations. Orphan properties (in an unsupported country or an unmapped region) wait until that destination has its own editorial coverage.
Editorial description that passes the gate — minimum length, no marketing-speak filter (we reject words like “best”, “ultimate”, “premier”), no forbidden phrases, and a real summary of what staying there is actually like.

All five gates run before published_at is set on a property. Properties in the queue are tagged as drafts and are not visible to visitors, not in our sitemap, and not crawlable.

Sorting on our pages

Default — by guest rating (descending). Never by commission rate. We don't have a commission-aware sorting toggle and we never will.
Editorial collections (“boutique”, “family-friendly”, “with rooftop pool”, etc.) — filtered subsets of the city catalog where every property in the subset matches the collection's criteria. A collection is only published if at least five properties pass the gate; otherwise it stays unindexed.
No “sponsored” or “promoted” slots. Nothing on the page is paid for.

Updates and freshness

Source data refresh — weekly via our ingest pipeline. Guest ratings, photos, amenities, and prices stay in sync with Booking.com.
Description regeneration — when source data drifts past a threshold (e.g. major amenity addition, photo set replacement), we regenerate the editorial description.
Visible last-updated dates — every blog article shows when it was last reviewed. Property data freshness is reflected in the page's server-rendered timestamp.
Hotel reassignments — when a property is clearly mis-classified (wrong city, wrong country, closed), we correct it via an editorial override and add a redirect from the old URL so existing links don't break.

Errors and corrections

If you spot a factual error — a property that's closed, a wrong address, an outdated photo, a category mismatch — email [email protected] with the URL and the issue. We respond within 24-48 hours and update the page once the correction is verified.