Your booking vendor tells crawlers to stay out
The short answer
If your practice books appointments through a hosted scheduling vendor, there is a fair chance that nothing which honours a robots file can see your booking page. Not a search crawler, not an AI assistant, not an audit like ours. Your own website is visible. The page where a patient picks a time is behind a door your vendor closed, and the vendor closed it for every practice on its platform at once.
We know this because we tried. On 19 of the 221 med spa domains we audited across the Carolinas, every route to booking led to a known booking vendor whose robots file forbids entry, and the walk stopped there. This article is about those 19: who they were, whose decision it was, and what it does and does not mean for you.
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. The walk is read-only, it never submits a form, and it reads a site’s robots file before it goes anywhere. What it does and what it refuses to touch are described on the methodology page; the findings it produced are in the first article. This piece is about a lane that produced no findings at all.
The sample is a prospecting list, not a survey. 188 of the 221 are in the Charlotte area, and the queue it came from excludes practices we had already written to. Whatever the 19 measures, it measures this corpus on that date.
Nineteen domains, one file each
The audit sorts every domain into a lane. The table is the set as the walker flagged it, before review, because it is the only set that sums to 221.
| Lane | Domains | What it means |
|---|---|---|
| Findings | 40 | At least one screenshot-backed defect or wall on the booking path |
| Clean | 27 | Reached selectable appointment times, or a form with no wall |
| Incomplete | 73 | Stalled at the booking vendor’s first screen |
| Robots-blocked | 19 | A booking vendor’s robots file forbids entry |
| Unreachable | 62 | Never reached a booking surface |
| Total | 221 |
Robots-blocked is the lane this article is about, and it has a property none of the others have: it records a decision rather than an observation. The walker did not fail on these 19 domains and it did not find anything. It read a published instruction and obeyed it.
The 19 break down by whose file did the forbidding.
| Vendor | Domains |
|---|---|
| Vagaro | 12 |
| Boulevard | 3 |
| Mangomint | 3 |
| 1 other | 1 |
The last row is collapsed on purpose. In a sample that is 85% one metro, a one-domain vendor cell names a practice by elimination, and no practice is named anywhere in this audit.
Twelve of the 26
The vendor that appears most often in the whole corpus is Vagaro, on 26 domains. Twelve of those 26 are in the robots-blocked lane. So for the most common booking vendor in the sample, the walker could not photograph the booking flow on close to half of the practices that use it.
That is the finding, stated as narrowly as it can be. It is a fact about one vendor’s robots file and about this corpus. It is not a fact about the remaining Vagaro domains, where the walk went past the file and landed in some other lane, and it says nothing about whether the flow behind the block works well or badly. We could not see it, which is the whole point.
It is also worth saying what the 12 does not prove. A lane that is mostly one vendor may say something about that vendor’s policy, or it may say only that the vendor is common. Twelve domains cannot separate those two readings on their own. The 12 of 26 can, a little, because it is the same vendor on both sides of the fraction.
Four more, in a different lane
There is a second cohort, and it is important that it stays separate.
The unreachable lane holds 62 domains where the walk never reached a booking surface. Most of them, 47, are an absence claim by a detector: nothing on the homepage offered a way to book and no tap-to-call link was found. But 4 of the 62 are robots blocks of a different shape: the practice’s own site, or a path on it, carries a robots file that disallows every booking path, so there was no vendor handoff to follow.
Those 4 and the 19 are not added together anywhere in this article, and you should be suspicious of anybody who adds them for you. They are different cohorts with different causes. The 19 are a vendor’s file on a vendor’s domain. The 4 are a file the practice’s own site serves, which may or may not be a decision anyone at the practice remembers making.
Whose choice it is
A robots file is a request, not a lock. It is trivially ignorable, and plenty of automated traffic ignores it. We honour it anyway, because the pitch of this audit is that somebody checked carefully and will show their work, and a screenshot we were asked not to take is not one we could stand behind.
For the 19, the file belongs to the vendor. A practice on that platform did not write it, cannot edit it, and in many cases will not know it exists. It is one setting, made once, covering every customer. That is not underhanded. A scheduling product holds appointment inventory, and appointment inventory is exactly the kind of thing that gets scraped. A vendor that keeps crawlers out is protecting its customers’ calendars from load and from harvesting, which is the same instinct that keeps our walker read-only.
Two things this does not mean. It does not mean your site is hidden from search: your own domain, where the robots file is yours, is indexed like any other, and nothing here says otherwise. And it does not mean a patient has trouble booking. A patient arrives with a browser, not a crawler, and the file says nothing to her.
What it does mean is narrower and, for the question people have started asking, whether an AI assistant can see your booking page, decisive. Anything that respects robots files, which includes the assistants people are starting to ask for appointments, sees your site and then stops at the door where the booking happens. It can describe your practice. It cannot see whether Thursday is open.
What we could not see
For these 19 domains we have no observation at all, and this section exists to keep that plain.
We do not know whether a phone-verification wall stands behind any of them. We do not know whether the calendar loads on a phone. We do not know whether the practice’s Book Now link even reaches the right scheduler, because we stopped before finding out. The lane records that the flow could not be photographed, and nothing else.
The 19 are also excluded from the headline. Our finding rate is 36 of 140, or 25.7%, and 140 is the walked population: findings plus clean plus incomplete. The robots-blocked and the unreachable are left out because nothing was walked there, and counting them either way would be inventing a result. If every one of the 19 had a wall behind it our rate would be higher; if every one were clean it would be lower; and we would not know in either case. Leaving them out is the only treatment that does not require a guess.
What this does not measure
A robots file is a text file. It can change tomorrow without anybody announcing it. The 19 is a count on the day we walked, in the paths we tried, and it is pinned to two dates: measured 27 August 2026, reviewed 7 September 2026.
The lane is a count of domains, not of vendors. One vendor appears 12 times. Read the table as which files stopped us, not as a ranking of policies.
Nothing here is a ranking claim. We did not measure where any of these practices appear in search or in an assistant’s answer, and the data cannot support a sentence that starts with “this costs you.” The claim is only that the booking flow could not be seen by anything that honours the file.
The sample biases this in a direction we cannot name. It is 85% one metro and came off a prospecting queue, so the vendor mix reflects who sells into that market. A different metro would have a different lane.
How to check your own
This takes about a minute and you do not need us for it.
- Open your own site and click your Book Now button. Watch the address bar. If the domain changes, that second domain is your scheduler.
- Add
/robots.txtto the end of that second domain and load it. - If you see
Disallow: /, or a rule covering the booking path, then automated visitors stop there, ours included. If you do not, they can go on.
Finding a block is not something you need to fix, and it may not be something you can. It is worth knowing, because a clean report from any tool that audits booking paths, including ours, was never going to include you, and because the assistants people are starting to ask whether Thursday is open will be stopping at the same file.
If you would rather we walked the rest of the path, we will do that for free, and you keep the written report either way.