Found when people ask: how an assistant reads a stay's website

A guest planning a trip used to open a booking site first. Increasingly, they ask first. The question goes to an assistant, in plain words — a quiet two-bedroom near the tower, a terrace, somewhere you can walk to breakfast — and the assistant reads pages, weighs them, and answers. Whether your stay can appear in that answer turns on something unglamorous: whether the pages that describe it can actually be read.

This is the layer we call being found when people ask, and it deserves to be understood mechanically, not mystically.

An answer engine reads text that arrives with the page itself — server-rendered, present in the document from the first byte, not painted in afterwards by scripts. It reads plain factual sentences: *the apartment sleeps four, across two bedrooms, on the top floor* is a sentence a machine can quote; a slogan is not. It reads structured data — the machine-readable layer beneath the page that names the property, its location, and what it offers, in terms machines already understand. It rewards a page per real question — where do I park, are children welcome, what is nearby — because an assistant answers questions, and a page that already holds the answer is the easiest thing in the world to cite. And it reads prices stated in the open. A price behind a form is, to a machine, no price at all.

It cannot watch your film. It cannot read the words locked inside an image, however beautiful the image. It cannot run the clever parts of a page — text that appears only after scripts execute may as well not exist. And it cannot guess what was never written down: if no page says the terrace faces west into the sunset, no assistant will ever say it either. Machines do not reward beauty here. They reward legibility.

A platform listing lives on someone else's domain, in someone else's template — one of thousands, shaped to be compared rather than quoted. Your own site is the one place on the open web where the facts of your stay exist in your own words, at a stable address, with nothing standing between the question and the answer. When an assistant looks for something to cite about your stay by name, your site is the page it can actually hold up. This is not an argument against the platforms — the booking can land wherever your guest is happiest placing it. It is a reason the page you own has to be worth reading.

Every property site the studio builds carries its facts as server-rendered text, so the words arrive with the page. It carries structured data describing the stay in the terms machines quote. It carries a page for each question guests genuinely ask, and its prices stated in the open. None of this is exotic. It is the discipline of the open web, applied without shortcuts — and it is the same standard this site practices on itself. The journal entry you are reading is built the way we advise. The full picture of what ships with every commission is on the kit page.

Here is the line we will not cross: nobody can promise an assistant's answer. Anyone who does is selling weather. What can honestly be done is to build the conditions — readable pages, plain facts, open prices — and then measure what happens. That is our practice: AI-sourced visits appear in the monthly evidence, alongside a log of what the assistants actually say about the stay, month by month. Measured, not promised.

When people ask, the stays that can be found are the ones whose pages can be read. Everything we build for this layer begins from that plain fact — and the report shows, month after month, what came of it.

⁂