Squarespace and restaurant
A Squarespace restaurant site, and the two surfaces the tag never reaches
The install here is one paste and it is finished in a minute. The work is everything after it, because the two things a restaurant is asked about most are the two things on the site with no readable text in them: a menu published as a designed file, and a reservation form rendered by a company that is not Squarespace.
Why this pairing is its own job
The Squarespace install guide covers the tag, and the restaurant guide covers what the assistant has to know. What follows is the part that belongs to neither.
- The menu is the single most requested item on the site and usually the only one a crawl comes back from empty handed. A designed PDF or an exported image sits inside an ordinary page, so what gets read is the sentence above the download link and nothing on the plate.
- Reservations run inside an embedded frame from a booking provider. The deposit, the notice period and the charge for a shrinking party are written in that frame, served from that provider's address, which is neither crawled as your site nor covered by anything you paste into your own settings.
- Site wide injection puts the launcher on the reservation page too, over a half completed form, which is the one screen on a restaurant site where a floating panel costs a booking rather than saving a phone call.
- Seasonal pages are published and then left. A festive menu from two winters ago is still a live page on the site, and a crawl reads it with exactly as much confidence as the one the kitchen is cooking this week.
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 restaurant site specifically.
Decide about the reservation page before you paste anything
The Footer field is site wide by definition, so the moment it is saved the launcher exists on the page where guests are picking a time and typing a phone number. For most restaurants that is acceptable and the launcher is small enough to ignore. For a restaurant whose booking frame is tall and already crowded on a phone, it is not.
If you want it off that one page, the site wide field is the wrong tool and you run it per page instead. On a restaurant site that is a short list: the menu page, the about page, find us, and private hire. Four pastes is more maintenance than one, so make the choice deliberately rather than discovering it after launch.
Whichever route you take, verify on the live reservation page on a phone. A launcher that overlaps a submit button is only visible at the width where it matters.
The plan gate, in restaurant terms
Code Injection is on the business tier and above. A restaurant sitting on a personal plan has no field to paste into at all, so this begins as a billing decision. It is worth pricing that against what the phone currently costs during service, which is the only comparison that matters here.
If you also sell gift vouchers or supper club tickets through Squarespace, note that the checkout those go through is served by Squarespace rather than assembled from your layout. Treat the assistant as something that answers questions before a purchase starts, not during one.
Fix the menu before you index anything else
A crawl reads what a browser would render as text. A menu exported from a design tool is a picture of words, and a picture of words answers nothing, however beautifully the dishes are set. Every question about dietary marks, prices, courses and whether the set lunch is still running dies at that file.
The fix is not to abandon the designed version. Publish the same menu as an ordinary page with a heading per course and the dietary marks written out as words, and keep the designed file as a download underneath it for the people who want to print it. The page answers questions and the file goes on being the thing you hand to a printer.
Where the answerable material lives
| The menu, as a page rather than a file | Courses as headings, dishes as lines, and the dietary marks spelled out in words with a plain sentence saying what those marks mean and what they do not cover. This one rewrite converts the most asked question on the site from unanswerable to answerable. |
|---|---|
| The booking terms, copied out of the frame | Whatever your reservation provider shows on its own screens about deposits, notice periods and large parties needs to exist as text on a page of your own site. Nothing inside that frame is readable from the outside, so if it is only there, it is nowhere. |
| The seasonal pages that are still live | Go through the pages list and unpublish the menus, events and set offerings that have finished. Anything still published is still read, and a confident answer about last year's Christmas menu is worse than no answer at all. |
| What the map block does not say | A Squarespace map block renders a pin. It does not render the fact that parking is on the street after six, that the dining room is up a flight of stairs, or that the accessible entrance is round the side. Those go in the paragraph next to the map, in words. |
The first thing to get right
Republish the current menu as an ordinary Squarespace page with the dietary marks written as words, and leave the designed file as a download below it.
Until that page exists the assistant is standing next to the material it is most often asked about with no way to read it. Every other improvement on this list is worth less than this one, because every other question on a restaurant site is asked less often than the menu.
The failure that belongs to this combination
An allergen answer assembled from everything except the menu
A guest asks whether anything on the menu is dairy free. The menu is a picture, so there is nothing there to match against. What the assistant does find is a paragraph on the about page about seasonal produce and a two year old post announcing a vegan night, and it answers from those, because those are the pages that mention food.
The reply reads plausibly and cites its sources honestly, and it is still the wrong shape of answer to the one question in this trade where the wrong shape matters. The restaurant rule holds regardless: never certify a dish. But a restaurant that cannot even describe its own labelling has given up the safe half of the answer as well as the unsafe half.
Set the caution level so anything mentioning an allergen returns your wording and a route to the kitchen. Then fix the menu page, so the assistant has something real to describe when it says what the menu marks.
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 restaurant 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
- Can it read the PDF menu if we upload it as a document instead of crawling it?
- It depends entirely on how that file was made. A menu exported from a word processor carries real text and is readable. A menu exported from a design tool as flattened artwork is an image in a wrapper, and there is no text in it to read. Open the file and try to select a dish name with your cursor. If nothing highlights, the assistant sees what you see, which is a picture.
- Will it appear inside our reservation widget?
- No. That widget is served from your booking provider inside its own frame, and your tag is on your page rather than inside theirs. Nothing you paste into Squarespace reaches into it, and nothing inside it is readable as source material either. If the terms a guest agrees to only exist in there, copy them onto a page of your own.
- Should we keep it off the reservation page?
- Judge it on a phone rather than in principle. Open the live booking page at phone width with the launcher present and see whether it lands on top of anything a guest has to tap. If it does, move to per page injection and accept the extra maintenance. If it does not, leave it site wide, because a guest who stalls on that form is exactly the person worth catching.
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 restaurantHours, last orders, deposits and dietary options are safe ground. Confirming a dish is free of an allergen never is.
- When the booking page is not part of your siteSquarespace scheduling runs on its own address, so the deposit and patch test rules live where the tag cannot go. Publish them on the site first.
- The page password protects the crawl, not the uploadSquarespace page passwords keep the arrival pack out of a crawl. The upload field is where owners hand over the door code without noticing.
- Where the dishes are, on a Wix restaurant siteWix manages menus as app data, so a crawl of the menu page can come back with no dishes at all. Check what the page returns before indexing.
- The menu is the material, and on most restaurant sites it is a downloadMenus published as files, dishes marked with icons instead of words, and a reservation flow that finishes on a booking platform's own domain.
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.