Search, filters and the map

Your booking site’s search runs against the same calendar your team works in. There is no nightly export and no cached availability to fall behind, which is why a night that is sold cannot be offered: the oversell guard is a uniqueness rule in the database, not a job.

Nothing on this page needs configuring. It works from the moment you publish, on the properties you published, and this article is about what your guests get and what you can do to make it answer better.

The search box

Field	What it does
Location	Type-ahead over your cities and your property names, so “Zeta” and “Islamabad” both work.
Dates	One calendar that stays open across the check-in and check-out clicks, showing two months. Sold-out nights are drawn as unavailable rather than free.
Adults / children	Capped at 10+ so a real group fits.

The results page is a plain URL. It is shareable, bookmarkable, back-button-correct, and you can paste a guest’s link into your own browser to reproduce exactly what they saw when they tell you “it said there was nothing”.

More than one city means the guest must choose one

If your portfolio spans several cities, a search with no location returns “please choose which location you would like to stay in” rather than results. This is deliberate - a portfolio-wide list across cities is not a useful answer - but it surprises operators testing their own site. A single-city portfolio hides the field entirely.

“I’m flexible”

A guest with no dates picks a length (weekend, 1 week, 2 weeks, 1 month) and a month, or Anytime, and gets back when the portfolio is free for that length.

Most direct enquiries start here rather than with a date, so it is worth checking that your rates are set far enough forward for the flexible search to have something to say.

Filters and sorting

The filter rail is built from the amenities your units actually carry, with a live count beside each. A guest cannot pick a filter that returns nothing, because a filter matching nothing is not offered.

Sorting is a <select> inside the same form: lowest price, highest price, capacity, or name. The server orders the list, so the order is a fact about your inventory rather than something the browser decided.

The amenity list comes from your listings

If a filter you expect is missing, the amenity is not set on any published unit. Amenities are inherited - a listing with no amenities of its own takes its type’s, and a type with none takes the property’s. See Content and policies.

When the dates do not work

Rather than an empty page, the search offers alternative dates near the ones asked for. A guest who wanted the 14th and can take the 16th is a guest you keep.

The map

Map view puts results beside a map with a price pin on each property, drawn for the guest’s own dates. Hovering a pin shows the listing details and rating; clicking opens the property card with its photos and arrows.

The map needs a Google Maps key on the deployment

Without one, the map does not render at all and the toggle is not shown - the rest of the search is unaffected. This is a platform-level setting, not something you configure per workspace. If your map is missing, tell us rather than editing anything.

What the guest carries with them

The search travels: dates, guests and destination are carried onto every property page, room page, city hub, collection and the booking form itself. A guest who clicks into a room and back out has not lost their search.

What’s next

• Collections and destination hubs - the pages a filter cannot express.
• What your site charges.
• Block dates - the other way a night stops being sellable.