Why would a med spa website look fine and still bring in few bookings?

Because the booking path is the one part of the site nobody at the practice uses. Staff book from the desk in the vendor’s own software, so a wall, a stale link or a page that only breaks on a phone can stand for months without anyone inside the building meeting it. On 36 of the 140 booking paths we could walk, 25.7%, something like that was on screen.

Is there a Charlotte-specific booking failure rate?

No. 188 of the 221 domains we audited are in the Charlotte area, which is why the audit describes Charlotte more than anywhere else, but the 36 of 140 figure covers the whole corpus and we have not split it by metro. Any Charlotte-only rate quoted from this audit is invented.

Which of the audit’s booking-path findings can a practice reproduce on its own phone?

Most of them. On a phone with no remembered account, tap the booking button and count the screens before a real appointment time appears. A form, a login or a verification code arriving first is the phone-verification, login or account wall, which is the largest finding class in the audit. A button that lands on an error page is the broken booking link. A page wider than the screen is mobile breakage. The widget and redirect findings need a second try on a different day before they mean anything.

The Charlotte med spa booking problem nobody sees

A site that looks finished

The question arrives in roughly the same words every time. The practice is in Charlotte, the website is new or newly redone, the photographs are good, the reviews are good, and the bookings are not what the site was supposed to bring in. The owner has looked at the site, more than once, and it is fine. So the explanation goes looking elsewhere: the ads, the season, the competitor down the road who opened in spring.

We think a fair share of those questions have a duller answer. Somewhere between the homepage and the screen where a patient picks a time, the path does something the owner has never seen it do, because the owner has never walked it as a stranger with a phone. This article is about why that failure is invisible from inside the practice, what we found when we walked 221 booking paths, most of them in Charlotte, and how to look at your own path in a way that would catch it.

Nothing about it looks broken

A broken booking path does not look broken. That is the whole problem, and it is worth sitting with before any number.

A website that is down looks down. A photograph that will not load leaves a grey box. A typo in a service name gets caught by the first friend who reads the page. Those defects are visible to the owner because the owner sees the same thing the visitor sees. The booking path is different. It is the one part of the site the owner never uses. Staff book patients from the front desk, in the vendor’s own software, with a logged-in account and a familiar screen. Nobody in the building has any reason to open the public site on a phone, tap Book Now, and try to get all the way to a Thursday afternoon.

So the path can fail for months in a way that nobody on staff ever encounters. The button is there. The page it opens renders. What is wrong is further along, or only on a phone, or only for somebody without an account, and none of those conditions ever apply to the person who owns the site. There is no channel at the other end either: a site has no form for “the booking page asked for a code before it showed any times.” We want to be precise about the boundary here. We measured what was on screen, and we did not measure what any visitor did next. But it does not take a measurement to see why the owner never hears about it.

What we walked

Between 26 and 27 August 2026 an automated walker took the booking path on 221 med spa domains across North and South Carolina, once each, over about forty-one hours. 188 of the 221 are in the Charlotte area. That is why this article can carry a Charlotte title honestly: it is the market that was actually walked, not a market we are extrapolating to. Greenville, Charleston, Sumter and Columbia make up the rest.

The walk is read-only. It never submits a form and it honours every robots file it meets. It takes the same path a new patient would, from the homepage to the vendor’s first screen and onward, until it either sees selectable appointment times or something stands in the way. Every finding is deterministic and backed by a screenshot. What the walk does, and what it refuses to touch, is described on the methodology page, and the full findings are in the first article. This piece borrows that article’s figures and adds no new ones.

A quarter of the paths we could walk had a finding

36 of 140, or 25.7%.

The denominator is the honest part, so here it is. 140 is the walked population: every domain where the walker reached a booking surface and something happened there, whether a finding, a clean run to appointment times, or a stall at the vendor’s first screen. It leaves out the 19 domains where a booking vendor’s robots file forbade entry and the 62 where the walk never reached a booking surface, because in those cases nothing was walked and counting them either way would be inventing a result.

The 36 is the reviewed figure. The walker originally flagged more, and on 7 September 2026 the operator opened every phone-verification finding against its screenshot and rejected four that had fired on gift-card checkout pages rather than booking flows. The denominator did not move under that review; only the numerator did. The first article walks through the rejection in detail. What matters here is that roughly one walked path in four had something standing on it that the practice, in all likelihood, did not know about.

What the findings look like from the owner’s chair

38 findings across 36 domains, and each class is invisible from inside the practice for a slightly different reason.

Thirteen are a phone-verification wall: a form asking for a name, an email address and a phone number, then an SMS code, before any appointment time is shown. All 13 are AestheticRecord’s default hosted booking flow. It is a vendor setting, made once, that an owner may never have seen, and from the front desk it does not exist. It is worth being fair about it. SMS verification before booking is a defensible feature, it cuts no-shows, and the data records only that the wall stands before any times are shown. It does not measure what that costs.

Eleven are phone only: no online booking mechanism found on the pages walked. Nothing about this looks broken to the owner, because it is not broken. It is a business model, and the audit counts it only because the question it asks is whether somebody can book online at all. A practice that chose phone-only on purpose is entitled to disagree.

Four are a broken booking link: the button resolves to an error page, a dead URL, or a rate-limit response. The button is present, styled and clickable, and the page it lands on is one nobody on staff has visited since the scheduler was last changed.

Three are mobile breakage, meaning the page renders wider than a 390px viewport. The owner checks the site on a laptop, where it is fine. Two are a login wall, where the booking path resolves to a sign-in form with no visible route for a new patient, which every member of staff sails through because they have an account. Two are a widget failure: the embedded booking widget rendered nothing after a 22-second settle. One is an account wall, one is a form error surfaced while filling a form that was never submitted, and one is a booking URL caught in a redirect loop.

Every one of those is a description of what was on screen when the screenshot was taken. None of them says what a visitor did, would have done, or lost.

Why there is no Charlotte number

A reader who came here for a Charlotte-specific failure rate will not find one, and that is deliberate.

188 of the 221 domains are in the Charlotte area, which is enough to say the audit describes Charlotte more than anywhere else. It is not the same as having computed a rate for Charlotte alone, and we have not. The 36 of 140 is the whole walked corpus, every metro together, and splitting it by metro is a derivation nobody has done and this article will not imply. If somebody quotes a “Charlotte rate” from this audit, they made it up.

The same discipline runs the other way. The sample is a place; the business is a region. We work with practices across the Carolinas, and nothing here should be read as a claim about which city we serve.

What this is not

It is not a survey. The 221 came off an outbound prospecting queue, found through metro text searches for med-spa-type businesses and then filtered by a predicate that exists to find practices worth writing to. That predicate excludes practices we had already written a friction brief about, which means some of the sites most likely to have something wrong were never in the set. Whatever this measures, it biases the finding rate down.

Findings are machine-flagged. A deterministic walker recorded them, not a person, and over-reporting is its expected failure mode. That is why the operator review exists and why the rejected findings are kept in the run files rather than deleted. The right sentence is “the audit flagged,” never “the site is broken.”

A headless browser is not a patient. One visit per site, inside one window of about forty-one hours, on an unattended machine. Two of the four broken-link findings were HTTP 429 responses, and a 429 for our bot is not proof of a 429 for a human. Thresholds are measurements, not verdicts.

Nothing here measures a consequence. We did not count visitors, bookings or revenue. The claim is narrower: on the day we walked, this was on screen.

Every figure is pinned to two dates: measured 27 August 2026, reviewed 7 September 2026. Sites get fixed. Some of these will have been.

What we could not see

The larger half of the audit is the part where nothing was proven, and a Charlotte owner reading this should know how large it is.

73 domains were incomplete. The walker’s click grammar stalled at a booking vendor’s first screen, with neither appointment times nor a wall visible. That lane measures our walker, not the practice. 19 were robots-blocked: every route to booking led to a vendor whose robots file forbids entry, and we stopped at the door. 62 were unreachable, and most of those, 47, are an absence claim by a detector that found no booking affordance and no tap-to-call link on the homepage. A practice in any of those lanes got no verdict from us in either direction, which means absence from this audit’s findings is not the same as a clean path.

The walk you can do yourself

None of this needs a walker. It needs a phone, a stranger’s point of view, and about ten minutes.

Borrow a phone that has never logged into anything of yours, or use your own in a private window so no account is remembered. Open your site from a search result rather than a bookmark. Tap the booking button and keep going, all the way to the last screen before an appointment would be confirmed, then stop.

Count the screens between the button and the first real appointment time. If a form, a login, or a verification code arrives first, you have found the largest class in this audit, and the vendor setting behind it is yours to change or to keep. Look at the address bar when the button is tapped, because a booking link that lands somewhere stale is the failure nobody on staff will ever trip over. Notice whether the page is wider than the screen. Then hand the phone to somebody at the front desk and ask them to do the same thing without being told what to look for.

If the path is clean, you needed ten minutes, not us. If it is not, we will walk it properly for free, and you keep the written report either way.