Wix and salon or spa
A salon site where the prices are drawn rather than written
Wix gives salons a booking app that handles services, durations, staff and payment, and it is genuinely good at that. The side effect is that the numbers a client came to find are held by the app and painted onto the page at the moment of viewing, which is a different thing from being written on it, and only one of those two can be read back.
Why this pairing is its own job
The Wix install guide covers the tag, and the salon or spa guide covers what the assistant has to know. What follows is the part that belongs to neither.
- The service list is an app rather than page copy. Prices, durations and the description attached to each service are managed in the booking area and rendered into the page, so what a crawl comes back with is the layout around them.
- The conditions that matter in this trade get typed into a service description field, which is short. Patch test requirements, what a price does not include and how long a correction really takes are the first things trimmed to make the field fit.
- The booking app runs its own multi step flow through to a payment step, and those are pages of your site, so the tag is on them. A launcher over a card form is a different proposition from a launcher over a gallery.
- Salon enquiries arrive on a phone in the evening from someone who has never visited the site before, which is precisely the visitor most likely to dismiss a consent banner. Whether the snippet loads for that person is decided by the category it was filed under months earlier.
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 salon or spa site specifically.
Apply to all pages, then look at the booking flow on a phone
Set the snippet to every page and place it at body end. Then open the booking flow on a phone as a client, all the way to the payment step, and watch where the launcher sits. On a narrow screen the flow uses the full width and the corner the launcher occupies is not always empty.
If it lands somewhere awkward, the useful question is not how to hide it but whether the client should have needed to ask anything by that point. A treatment page that already states the deposit, the duration and the patch test rule removes the reason to open a chat panel mid payment.
Give the crawl a services page it can actually read
Keep the booking app exactly as it is, and add an ordinary page beside it that lists the same services as text: name, starting price, how long, and one line on what moves the price. This is not duplication for its own sake. It is the only version of that information anything can read back.
Write the sentence about what moves the price properly, because it is what turns a refusal into a useful reply. Length, density, existing colour, whether a toner or a cut is included. A client who understands why the number is a range stops treating the range as evasion.
Whenever a price changes in the booking app, change it on the page in the same sitting. A stale text page is worse than none, because the assistant will quote it and cite it.
The plan, and the category you file it under
Custom Code needs a premium plan with a domain connected, so a salon still running on the free address has an upgrade in front of the install. There is no way round that inside Wix and no arrangement of elements that substitutes for it.
When you add the snippet, treat the consent category as a decision about who gets help rather than a form field. A client who declines a category and then cannot find anyone to ask about a patch test is a booking that quietly does not happen, and you never see it.
Where the answerable material lives
| A text services page alongside the booking app | The same list the app shows, written as words, with starting prices and durations. The app stays the place clients book. The page becomes the place the information is legible to anything other than a pair of eyes. |
|---|---|
| The patch test policy on its own page | Too long for a service description field and too important to shorten. Which services, how far ahead, how long it lasts, and that the appointment does not go ahead without it. Written to be quoted exactly rather than paraphrased. |
| Price list graphics converted to words | Salons keep a designed price card in the media manager and drop it onto a page. It looks right and it reads as nothing. Retype the contents onto the page under it; the design can stay for the people who like it. |
| Gift voucher terms as published text | Validity, whether it is a value or a named treatment, part redemption, transferability and what happens if prices rise first. If these live only in a product field on the voucher you sell, they are not readable and they are the terms most likely to be disputed. |
The first thing to get right
Publish a plain text services page with starting prices and durations, and index that page rather than the booking app page.
Price is the question that decides whether somebody books, and on this platform it is the question the site is least able to answer to anything that reads it. One page closes that gap and every other improvement here depends on it being closed.
The failure that belongs to this combination
Nobody available at nine in the evening, invisibly
The salon's enquiries cluster in the evening, on phones, from people who found the site through a search and have never seen it before. That visitor meets the consent banner cold, taps whatever dismisses it fastest, and if the snippet was filed under a category they declined, Wix never puts the tag on the page.
Nothing about this looks like a failure from your side. There is no refused origin, no missing key, no console message, because there is no script. The owner opens the site, sees the launcher because they accepted the banner in spring, and concludes it is working.
The consequence in this trade is specific: the patch test question is the one that has a deadline attached, and it is asked at night by somebody booking colour for the weekend. Reproduce a first visit in a private window, decline the banner, and see whether anybody would have been there to answer it.
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 salon or spa 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 prices out of our Wix booking app?
- It reads pages, not apps. The booking app holds those values and paints them into the page when a browser asks for it, which is not the same as the page containing them. Assume they are unreadable and publish a text version of the same list. That takes an hour once and then needs updating when prices change.
- Should we keep the launcher out of the booking flow?
- Look at it on a phone before deciding. The flow is made of pages of your own site, so the site wide snippet reaches them, and on most layouts that is fine. Where it is not, the better fix is usually upstream: put the deposit, the duration and the patch test rule on the treatment page so nobody needs to ask during payment.
- It works for us but a client says there is no chat. What is that?
- Check consent before anything else. Your browser is holding an acceptance from months ago and theirs is not, so for them the tag was never added to the page. It is not an allowlist problem and there will be nothing in the console to find, because there is no script running to complain.
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 salon or spaPrices depend on hair length and condition, so a real quote needs a consultation. Patch tests and pregnancy questions need a person.
- 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 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.
- 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.
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.