WordPress and restaurant
The menu is the material, and on most restaurant sites it is a download
A restaurant site is small and its most important page is usually not a page. The menu is a file, produced in a design tool for print and uploaded at the start of each season, and the dietary information on it is a row of small symbols with a key at the bottom. Everything an assistant here can safely say about food comes out of that file, and everything it must refuse comes from the same place, which makes getting the file in and the refusal right the whole job.
Why this pairing is its own job
The WordPress 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 normally a download rather than a page, because it is designed for print first. A crawl of the site reaches the page that links to it and stops, so the assistant that seems to know nothing about your food has in fact never seen it.
- Dietary marks on a designed menu are symbols. A leaf, a circle, an asterisk against a dish, with a key set in small type at the foot of the last section. Whatever meaning a reader takes from that layout does not survive being read as text, and an assistant answering from a scrambled key is worse than one answering from nothing.
- Reservations finish somewhere else. The table is booked on the booking platform's own domain or in a panel it serves, so the deposit and cancellation terms for a large party are agreed in a place the site does not describe and the assistant cannot read.
- The parts of the offer that change weekly, the specials, the guest chef, the closure for a private event, live on a social feed embedded in the front page rather than in any page of the site. They are the most current thing the restaurant publishes and the least readable.
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 WordPress guide. Everything below is about where it goes on a restaurant site specifically.
Get the menu in as a document, and keep it current
Upload the menu file as a source rather than relying on a crawl to find it. A designed menu produces messy text when it is read, so open what came out and check that dish names and section headings survived before you trust an answer built on it.
The seasonal change is the part that catches people. A restaurant swaps the menu file and leaves the old one uploaded, so both are readable and the assistant has two answers about what is on tonight. Replace the source when the menu changes, in the same job as uploading the new file to the site.
Write the allergen refusal before the menu is even indexed
This is not a settings detail on a restaurant, it is the reason the install is safe. The refusal has to say plainly that the assistant cannot confirm a dish is free from anything, and it has to tell the guest to raise it when booking and again on arrival.
Set the caution level high enough that a question mentioning an allergen never gets answered from a near match. The failure mode you are preventing is not a refusal that annoys somebody, it is a fluent answer built from a symbol key that read badly.
Say what it can do in the same message. Describing the range of options on the menu is genuinely useful and is not a safety claim, and a refusal that offers nothing sends the guest to the phone during service, which is what you were trying to avoid.
Know which domain the reservation ends on
If the booking button leaves your site, the guest reads your terms on your site and agrees to the platform's terms on theirs. Check that those two say the same thing about deposits and cancellation for large parties, because the assistant answers from yours and the guest is held to theirs.
If the booking is a panel embedded in your page instead, the launcher renders around it and not inside it. Either way there is nothing to allowlist on the platform's side, and nothing worth trying.
Where the answerable material lives
| Service times rather than opening times | When the kitchen starts and stops, last orders for food and for drinks, and how both differ on a Sunday or a holiday. The gap between the door being open and the kitchen serving is the misunderstanding a restaurant deals with most, and most sites publish only one of the two numbers. |
|---|---|
| The menu file, uploaded and checked after reading | The current menus as documents, with the dietary key written out in words somewhere the assistant can read it as a sentence rather than as a symbol against a dish. |
| Group booking and deposit terms, written on your own site | The party size at which the rules change, deposit per head, whether a set menu becomes compulsory, the pre order deadline and the charge for a shrinking party. If these currently exist only inside the booking platform, they need writing out here. |
| The practical visit page | Parking and for how long, step free access, whether the dining room is upstairs, high chairs, the outside area and whether it is covered. Small, dull, and asked constantly. |
The first thing to get right
Write the dietary key out as plain sentences on a page of the site, then upload the menu file alongside it.
The symbols carry the meaning on a printed menu and lose it entirely as text. Writing the key out in words is twenty minutes of work that decides whether every answer about food is built on something readable or on a scattering of stray characters.
The failure that belongs to this combination
Two menus indexed, one of them from last season
The version of this that actually happens is not a dramatic allergen failure, because a properly written refusal catches those. It is the autumn menu answering questions in March. The kitchen changed the menu, somebody uploaded the new file to the site, and the old file stayed where it was because deleting uploads feels risky.
Both files are readable, both are correctly cited, and the assistant has no way to know which one is current, because a designed menu rarely carries a date anywhere in its text. A guest is told about a dish that came off in January and books a table for it.
Put a date or a season in the visible text of the menu file itself, and make replacing the source part of the same routine as changing the menu. A restaurant that changes its menu six times a year needs this to be a habit rather than a decision.
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
- Our menu is a PDF. Does that work?
- It works if you upload it as a source and check what came out of it. A menu laid out for print reads back messily, and the dietary key suffers worst because it depends on position and symbols. Read the extracted text once before you rely on it.
- Can it tell a guest whether a dish is gluten free?
- It must not, whatever the menu says. Labelling describes the recipe as written and the guest is asking about the plate they will be served tonight, which depends on substitutions and on the kitchen. Set the refusal so every allergen question ends with the guest talking to a person, before they book and again when they arrive.
- Can it hold a table for someone?
- No. It reads pages and documents, and your reservation platform is neither. It answers what comes before the booking, states your deposit terms for a large party, and points at the booking link, which is the honest and the fastest route.
Keep reading
- Installing on WordPressHook the tag into wp_footer with a snippet plugin, keep it out of the theme, and stop optimisation plugins from deferring it away.
- Everything for a restaurantHours, last orders, deposits and dietary options are safe ground. Confirming a dish is free of an allergen never is.
- A WordPress site for a law firm, and the pages a crawl comes back empty fromFee tables hidden in page builder accordions, a client area the widget must stay out of, and costs documents published as files rather than pages.
- A dental site on WordPress, and the frame in the middle of itThe booking software sits in a frame served from another origin, and the cancellation terms live inside it. What that leaves the assistant able to answer.
- A Squarespace restaurant site, and the two surfaces the tag never reachesThe menu is a PDF and the reservation form belongs to another company. What the footer tag reaches on a restaurant site, and what it never will.
- 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.
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.