Squarespace and holiday rental
The page password protects the crawl, not the upload
A holiday let site here has a shape you can predict: a gallery, a paragraph of description, a booking button that leaves for somewhere else, and a page locked with a password where the arrival instructions live. Two of those four decide what the assistant can safely be given, and the locked one is not the safe one people assume it is.
Why this pairing is its own job
The Squarespace install guide covers the tag, and the holiday rental guide covers what the assistant has to know. What follows is the part that belongs to neither.
- Squarespace lets you password protect a single page, which is where owners keep the address, the key safe code and the driving directions. A crawl of the public site cannot reach that page, and that is exactly right. The exposure comes from the upload field instead, where the same pack goes in as a file with nobody thinking about it.
- Squarespace commerce sells products, not nights. Any real availability lives in an embedded booking engine from another provider, on another address, and the terms a guest ticks are agreed inside that frame rather than on your page.
- Most lets are also listed on a third party site, which means two different cancellation policies exist and which one binds depends on where the guest booked. A site built here normally states one of them, so the assistant confidently gives the wrong one to half the people who ask.
- The page is a gallery with captions. Everything guests actually message about, cots and towels and parking and whether the dog can come, has no text behind it unless somebody writes an inventory page nobody would design.
What changes about the install here
<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>The tag is the same one on the Squarespace guide. Everything below is about where it goes on a holiday rental site specifically.
The locked page is a boundary, so treat it like one
Password protection on a page is a real boundary for a crawl. Nothing behind it is fetched, so the address and the entry code cannot arrive that way. Keep using it, and keep the arrival pack on exactly one page rather than sprinkled through the site.
Then apply the same rule to uploads, where the boundary does not exist. A file you add as source material is read in full, and the welcome pack is usually a single document with the code, the lane, the neighbour's phone number and the alarm sequence all in it. Nothing about the page password stops that file being indexed once it has been uploaded separately.
The safest arrangement is the simplest one: the arrival pack exists in one place, behind the password, and is never uploaded anywhere. What the assistant is given is a separate document written for people who have not booked yet.
The booking frame is somebody else's page
Whatever availability calendar you embedded renders inside its own frame from its own address. Your tag does not run in it, and its content is not readable as source material, so the terms displayed at the moment of payment are invisible to everything on your side of the glass.
The practical consequence is that the assistant's usefulness ends at the click. Put the deposit, the changeover day, the minimum stay and both cancellation positions on the page above that frame, so the questions are answered before somebody leaves for it.
Site wide is the right setting here
A let site is small enough that there is no page worth excluding, and the enquiries arrive from whichever page a search engine dropped somebody on. Paste it once into the Footer field and leave it. Code Injection is on the business tier, which for a single property is a genuine cost to weigh rather than a formality.
Do check the locked page while you are there. The launcher appearing on the password screen itself is harmless, but it is worth knowing it is there before a guest asks it something on that page.
Where the answerable material lives
| An inventory page, written as a list | Linen, towels, beach towels, cot, high chair, hair dryer, washing machine, dishwasher, what is in the cupboard and what is not. It reads like a spreadsheet and it answers more messages than the entire rest of the site, because it is what people pack around in the last week. |
|---|---|
| Arrival and departure in general terms only | Check in from, check out by, whether a late arrival can be arranged, and the departure routine for bins, dishwasher and beds. Written so it is genuinely useful without containing a single detail that identifies the door or opens it. |
| Both cancellation policies, side by side | Yours for a direct booking and the platform's for a booking made there, labelled so the assistant can say which one applies to a booking made where rather than blending them into one confident wrong answer. |
| Local rules, tax and the registration number | Tourist tax collected on arrival, any registration or licence number you are required to display, quiet hours, waste and recycling, parking permits and the permitted occupancy. None of this is guessable and all of it is asked. |
The first thing to get right
Write the inventory page, publish it publicly, and index it before anything else on the site.
It is the highest volume question in the trade, it takes twenty minutes to write, and it is the one document a holiday let site almost never has because it looks nothing like marketing. Until it exists the assistant is answering packing questions from a page of photographs.
The failure that belongs to this combination
The welcome pack uploaded as a document
The pack is one tidy file, it answers everything a guest asks during a stay, and it is sitting right there on the desktop. Uploading it feels like the obvious move and it takes ten seconds. It also puts the full address, the key safe code and the alarm sequence into the material the assistant answers from, for anybody who asks in a way that gets near it.
The password on the arrival page did nothing to prevent this. That setting governs what a crawl of your site can fetch. It has no bearing on a file you handed over yourself through a completely different route, and there is no warning at the moment you do it.
Split the pack in two before it goes anywhere. A pre arrival version with the inventory, the routine and the local rules, which is safe to index and useful to everybody. A confirmed guest version with the address and the codes, which lives behind the password and is never uploaded. If the fact is not in the material, no instruction is needed to keep it out of an answer.
Before you go live
- The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.
- Open the site as a visitor would, on the pages a holiday rental visitor actually lands on, and ask it something only your own material could answer. A widget that renders is not the same as a widget that has read anything.
Questions
- Does the page password stop it reading the arrival instructions?
- For a crawl, yes. A protected page is not served without the password, so it is not fetched and not read. That protection is entirely separate from uploads, though. Anything you add as a document is read in full regardless of what the site does, which is why the pack has to be split rather than trusted to the page setting.
- Can it tell somebody whether the property is free in August?
- No. It cannot see a calendar and your calendar lives in a booking engine it has no view of. What it can do is state the minimum stay, the changeover day and the seasons from your published terms, then send them to the booking page or take their dates as an enquiry so you can answer with real availability.
- We list on a third party site as well. Which cancellation policy should we index?
- Both, labelled by booking route. Index them as two clearly separated sections rather than one merged paragraph, because merged is how an assistant ends up quoting your generous direct policy to somebody who booked through a platform with a stricter one. The guest will hold you to whichever version they were shown.
Keep reading
- Installing on SquarespaceThe exact Code Injection footer setup for Squarespace, the plan it needs, and the two surfaces it will never reach.
- Everything for a holiday rentalWhat is provided, deposits and cancellation terms answer well. The exact address and the door code stay back until a booking exists.
- Open mornings, member areas, and an install you cannot subtract fromPast open mornings stay published, the member area shows a launcher to parents while hiding its pages from a crawl, and injection can add but not subtract.
- A marketing agency on Squarespace, where the work is images and the answers are notAn agency site is mostly pictures. If the case study text sits inside the image, a crawl finds a client name and a caption, and nothing to answer with.
- One page, one document, and why uploads are the only real sourceOne page means a crawl gives the assistant nothing the visitor cannot already scroll to. On a Carrd let, uploads are the whole of the material.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.