Wix and restaurant
Where the dishes are, on a Wix restaurant site
Wix has a menu manager, which is a much better way to run a menu than editing a page every time the fish changes. It also means the dishes live in a manager and arrive on the page through a component. Before you index anything, it is worth finding out how much of your own menu the page actually contains.
Why this pairing is its own job
The Wix 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.
- Menu content is managed rather than typed. Section names, dish names, prices and the dietary marks are held by the menu app and placed into the layout, so the page you point a crawl at may hold the surrounding design and none of the food.
- Dietary marks are the only part of a menu an assistant is ever allowed to describe, since certifying a dish is off limits in this trade whatever the material says. Losing the marks costs you the safe half of the answer and leaves only the refusal.
- If you take orders through the site, the ordering flow and the cart are pages of your site and carry the tag. That is the screen where a hungry visitor asks whether the burger comes with cheese, which is a good question to catch and a bad screen to obstruct.
- Opening hours on a Wix site are usually a business setting rendered by a component rather than a sentence somebody wrote, and a restaurant needs two different sets of times anyway: the door and the kitchen.
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 Wix guide. Everything below is about where it goes on a restaurant site specifically.
Find out what the menu page returns before you index it
Open the live menu page and use the browser's find function to search for a dish you know is on it. If the browser finds it in the rendered page but a crawl comes back with nothing useful, you have your answer, and the answer is that the menu is being supplied by the app rather than being part of the document.
Do this before deciding anything else, because it changes what the rest of the work is. A menu page that carries its own text needs no intervention. One that does not means the single most requested thing on the site has to be published somewhere else as well.
The ordering pages carry the tag
Online ordering runs through pages of your own site, so the site wide snippet reaches the item screens and the cart. Unlike the menu, this is mostly good: questions about substitutions, portion size and collection times arrive exactly when somebody is deciding to spend money.
The two things to check are width and overlap. Open the cart on a phone and make sure the launcher is not sitting on the checkout button, and remember the assistant cannot see an order, a total or a delivery time. Set the refusal so anything about an order in progress hands over rather than guesses.
Write the times as sentences
Business hours entered into Wix settings appear on the page through a component, and even where they are readable they describe the door rather than the kitchen. A restaurant is asked about last orders far more often than about opening time, and last orders is not a field.
Put a short paragraph on the contact page saying when the kitchen opens and closes each day, when last orders for food and for drinks are, and how Sundays and public holidays differ. It reads as unnecessary duplication until you count how many calls it removes.
Where the answerable material lives
| A plain menu page, published as text | Sections as headings, dishes as lines, prices next to them, and the dietary marks written out as words with a sentence explaining what the marks cover and what they do not. Keep the app version as the one that renders on the site. |
|---|---|
| Kitchen times rather than door times | Written as prose on a page, including last orders and the days that differ. The hours component describes when the building is open, which is not the question anybody is asking at half past nine. |
| Group booking and deposit terms | The party size at which the rules change, the deposit per head, the pre order deadline and the charge for a party that shrinks. These arrive as long emails and every one of them is answerable from a page that takes an afternoon to write. |
| The allergen statement you are prepared to have quoted | One short paragraph, written by you, describing how you handle allergens and instructing the guest to speak to the team before ordering. The assistant will quote it verbatim, so write it as something you would be happy to see repeated to every guest who asks. |
The first thing to get right
Search the live menu page for a dish name, then publish a text menu page if the crawl cannot find what the browser can.
Everything else on a restaurant site is a secondary question. If the menu is not readable, the assistant spends its entire life referring menu questions back to you, which is the traffic you installed it to absorb.
The failure that belongs to this combination
An assistant standing next to a menu it cannot see
A visitor asks whether there is a vegan main. The menu page holds a layout and a component and no dish names, so nothing matches. What does match is a paragraph on the about page about working with local growers, and a page about the private dining room that happens to mention a set menu.
The reply that comes back is polite, cited and useless, and worse, it sounds like the restaurant does not know its own menu. A visitor who gets that answer does not ask a second question, they open a different restaurant's site.
This failure is invisible from the owner's chair, because the owner looks at the menu page and sees the menu. The check that finds it is asking the assistant a question whose answer is a specific dish, and seeing what it cites.
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
- Do we have to keep two copies of the menu up to date?
- In practice yes, and it is less painful than it sounds if the text page is plain. Most restaurants change a handful of lines at a time, and the same edit takes a minute in both places. The alternative is an assistant that cannot answer the only question most visitors have.
- Can it answer questions about an order somebody has already placed?
- No. It has no view of orders, totals, delivery times or payment, and it should not pretend otherwise. Write the refusal so anything about an existing order gives the phone number immediately, because somebody waiting on food is not going to read a paragraph about policy.
- Our menu changes daily. Is any of this worth it?
- Split the menu in two. The parts that hold steady for a season, which is most of it, go on the text page and answer most questions. The daily specials do not, and the assistant should say plainly that specials change daily and point at the board or the phone. That is a true answer and it costs you nothing.
Keep reading
- Installing on WixWix has a Custom Code panel for third-party tags. Apply it to all pages at Body end, load it once, and pick its consent category on purpose.
- Everything for a restaurantHours, last orders, deposits and dietary options are safe ground. Confirming a dish is free of an allergen never is.
- The timetable advice that does not work hereThe usual advice is to crawl your live timetable. On Wix the schedule is drawn by a booking app, so that page has no class names in it.
- A dental practice on Wix, where consent decides who gets the assistantOn Wix the snippet loads only after a visitor accepts the consent banner, and the patient with a broken tooth at midnight is the one who dismisses it.
- 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.
- 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.