I audited 456 Michigan wellness and med spa websites. The finding that has stayed with me is not the slow ones or the ugly ones. It is this: 217 of them threw JavaScript errors on the homepage at phone width.
Not a layout that looked cramped. Errors — the browser hitting something it could not execute and giving up on that piece of the page. Often the piece that takes bookings.
And here is the part that matters more than the number: in every one of those cases, the business had no way to find out.
Why doesn't anyone tell you the booking form is broken?
Because the person who hits it does not contact you. That is the entire problem, and it is worth sitting with, because it inverts the normal assumption that bad things generate complaints.
Picture the actual sequence. Someone searches on their phone at nine in the evening — which is when people book this kind of appointment, not during business hours. They land on your site. They tap "Book now". A panel opens and sits there blank, or the date picker will not advance to next month, or the submit button does nothing at all.
They do not email you to say your form is broken. They do not ring to report a bug. They go back to the search results and tap the next place.
You have lost that appointment, and the only trace it leaves is an absence. Your phone did not ring. Your inbox has nothing in it. There is no row anywhere in any system recording the person who tried and could not.
This is why a broken booking form can run for months. It does not look like a fault; it looks like a quiet week.
What's actually breaking
It is almost never the thing people expect. Four patterns came up again and again:
The booking widget's script fails to load. Most spas use an embedded scheduler from their practice software. That embed is a script fetched from someone else's server. If it is slow, blocked, or has changed its URL since your site was built, the container renders and stays empty. Your page is fine. The booking is gone.
A plugin conflict kills every script after it. JavaScript on a page is not independent. One script throwing an uncaught error can stop the ones queued behind it from running at all. So a decorative animation nobody would miss takes the booking form down with it — and the animation is usually the thing that was added last, by someone who tested on a laptop.
The tap target is there but unreachable. A sticky header, a cookie banner, or a chat bubble sitting on top of the button. The click lands on the overlay. On a desktop you would notice; on a phone the overlay often is the whole bottom of the screen.
It works on the owner's phone. This is the one that keeps the fault alive. You have the site cached, you may be logged in, your phone is newer, and you know where the button is so you tap accurately. A first-time visitor on an older device over a weak signal is having a different experience, and yours is not evidence about theirs.
How would you know? Check it the way a customer would
You do not need a developer for the first pass. You need to stop testing like an owner.
Use a phone that is not yours, on mobile data, not your own wifi. Borrow one. An older model is better. Mobile data matters because a slow connection is when script-loading failures actually show up — on fast wifi the broken thing often loads just in time to hide the problem.
Complete a real booking, start to finish. Not "the page loads". Pick a service, pick a date in the next month, fill the form, submit it, and then confirm the appointment actually arrived in your system. Half of what I found fails at a step people never reach when they are just glancing at the page.
Try it in a private window. That removes your cached files and your session, which is the closest you can get to being a stranger.
Tap the phone number. On a phone, a number that is typed as plain text instead of marked up as a link does nothing when tapped. People assume it will dial. When it does not, they usually do not retype it.
If any of that fails, you have found something that has been costing you appointments silently, and you found it in about ten minutes.
The honest caveat about fixing it
Sometimes the answer is cheap. A script tag pointing at a URL that moved, an overlay with the wrong z-index, a plugin that can simply be removed — those are an hour of someone's time, and you should not let anybody sell you a rebuild for them.
Sometimes the booking flow is genuinely the wrong tool for your business and no amount of patching helps. That is a real conversation, but it is the second conversation. Have the first one first, because it is free and it might be the whole answer.
What you should not do is accept "it works for me" as a diagnosis. That sentence is how 217 sites kept throwing errors at the people trying to give them money.
If you want to see exactly what your own site does, my website check is free, needs no signup, and takes about a minute — it loads your pages the way a visitor's phone would and tells you what broke, including the console errors you cannot see from the front. It is the same check I ran across all 456 sites.
If it turns up something structural rather than a quick fix, the 30-minute Operations Audit also costs nothing and I will tell you plainly whether it is worth paying to solve. Builds start from $6,000, and "this is a one-hour fix, go get it done" is an answer I give often. Get in touch.
