What a licensed psilocybin practice needs from its site

In July 2026 I launched a site for a psilocybin facilitation practice licensed in Colorado and Oregon, and the first thing I had to accept was that none of it could be advertised. No search ads, no social ads, no boosting a post that did well. Every visitor would arrive from an organic result, an answer engine, or a recommendation. That one constraint reached further into the build than any design decision I made.

The practice is MycoMuse, and I can name it here because the case study is published with permission. It went from brief to a live, crawlable site with its own CMS, lead pipeline and working email inside a week. What follows is the part of that week that would not appear on an ordinary small business build.

Why does none of it run on paid ads?

Because there is no channel to buy, and the platforms are only half the reason. Psilocybin is still a Schedule I controlled substance under federal law, listed by name at 21 CFR 1308.11(d)(29), and that does not change because two states built licensed programs on top of their own law. Google's dangerous products or services policy files it in the same short list as explosives and tobacco:

Ads for substances that alter mental state for the purpose of recreation or otherwise induce "highs" are not allowed. Ads for products or services marketed as facilitating recreational drug use are not allowed.

Licensed facilitation is not recreation, so a lawyer could argue the line. I looked for a published approval path for a state-licensed facilitator on either large ad platform and did not find one. When the honest answer to "can we run ads" is that nobody at the platform has written down a yes, you plan as though the answer is no.

The state rules go further, and this is the part that surprised me. Oregon does not simply restrict what an advertisement may claim, it restricts where a licensee may advertise at all. From OAR 333-333-6110(1):

A licensee may not utilize television, radio, billboards, print media or internet advertising unless the licensee has reliable evidence that no more than 30 percent of the audience for the program, publication or Internet website in or on which the advertising is to air or appear is reasonably expected to be under the age of 21.

Reliable evidence about the age composition of a display network's audience is not something a solo practitioner can produce. So the growth plan is organic and nothing else: six offering pages, seventeen journal articles as of 4 September 2026 counted off the live sitemap, structured data on every page, and a plain-text map of the site for language models next to the usual XML one. The journal opens with the question people actually type first.

I have written the same problem up for therapy practices in why a practice does not show up on Google, and for a directory in learning to scale organic traffic. The difference here is that organic is not the cheap option. It is the only one.

How do you keep under-21 visitors out without hiding the site from search?

You put the gate over the page rather than in front of it. The same Oregon rule that limits where a licensee may advertise also reaches the licensee's own site, in one sentence at OAR 333-333-6110(2):

A licensee who advertises via webpage must make reasonable efforts to prevent individuals under 21 years of age from visiting the webpage.

The usual reading of that produces an interstitial: a separate page that asks your age before sending you to the content. The crawler arrives at that page too, which would take the whole site away from the only channel the practice has. So the gate is a module that renders the full page underneath and lays a full-screen overlay on top of it. Agree posts a form, sets a thirty-day cookie, and bounces you back where you were. It works with JavaScript off, and signed-in editors never see it.

setcookie(AgeGate::COOKIE, '1', [
    'expires'  => time() + 60 * 60 * 24 * 30,
    'path'     => '/',
    'secure'   => !empty($_SERVER['HTTPS']),
    'samesite' => 'Lax',
]);
$back = $_POST['back'] ?? '';
/* only ever bounce within this site */
if ($back === '' || !str_starts_with($back, App::$baseUrl . '/')) $back = url('');

A human meets a wall. A crawler reads the page. Both of those are true at once, which is the only version of this that a practice with no paid channel can afford.

Why does the booking engine live inside the CMS?

Because the first contact with a regulated practice should not happen inside somebody else's subscription, with its own retention policy and its own idea of what to do with a mailing list. That is the same argument I made about agent tooling in rent a bot or own a harness, and it applies harder when the thing being rented is a list of people who enquired about a controlled substance. The scheduling module went in the day after launch, from first line of code to a real booking on a real calendar.

The privacy contract is in the OAuth scopes, so it is checkable rather than promised. The site can ask the calendar when its owner is busy, and it cannot ask what she is doing:

public const SCOPES = 'openid email '
    . 'https://www.googleapis.com/auth/calendar.freebusy '
    . 'https://www.googleapis.com/auth/calendar.events '
    . 'https://www.googleapis.com/auth/calendar.calendarlist.readonly';

Working hours live in the CMS as rules. The slot engine subtracts real busy time from those rules and publishes what is left, sixty days out. At the moment somebody presses the button the whole calculation runs again against a fresh read, because nothing the browser sends back is trusted: if the time went while the page sat open, it says so and shows the current openings. If the calendar cannot be reached, the page says that rather than offering a time it cannot keep. A honeypot field, an invisible bot check and a limit of three bookings per address per hour sit around the rest.

The regulated part is at the bottom of the form. An ordinary booking records who asked and when. This one also records what the person confirmed before the appointment existed: that they are 21 or over, and that facilitation is distinct from medical, psychiatric and psychotherapy services. Both are required to submit, and both are written onto the lead row rather than left in a template nobody can produce later.

if (empty($_POST['ack_age']))   $fail('Please confirm that you are 21 or older.');
if (empty($_POST['ack_scope'])) $fail('Please confirm that facilitation is distinct from medical care.');
// ...
'data' => json_encode([...,'acknowledged' => '21+, non-medical scope', ...]),

Two smaller decisions on that form came from the other half of my working life. I was a licensed professional counselor for a decade and still do clinical work, and intake teaches you quickly what a first contact should not do. So the note field is optional and says so, because a person deciding something difficult should not have to explain themselves in a text box to get fifteen minutes. And a booking deliberately does not enter the contact form's automated follow-up sequence: an instant confirmation is warm, and a cheerful nudge two days later, to someone who is already on the calendar, is not.

Why did I switch off a feature that works on every other site I run?

Because on this site it is a rule violation, and on the others it is not. On 5 August 2026 I shipped a slide-up card that invites a visitor to leave a Google review: ten seconds on the homepage, five elsewhere, a week's silence once dismissed, several rotating versions of the wording, all of it managed from an admin tab. It is a good pattern, and it went live here with the rest.

Then I read the Colorado facilitator rules properly. Rule 7.4 of 4 CCR 755-1, in force since 14 September 2024, is one sentence long:

While testimonials may be collected and displayed, a facilitator may not solicit testimonials from participants.

A review card on a facilitation site is a solicitation, and the visitors most likely to see it are the people who have worked with her. On 24 August the card came off, permanently. Oregon's psilocybin rules, for what it is worth, do not use the word testimonial at all: I searched the whole of division 333 for it on 4 September 2026. The stricter licence sets the rule for a person who holds both.

The part worth naming is not the finding, it is what switching it off had to mean. A setting is a suggestion. The guarantee is a line of code at the top of the partial, before anything is evaluated:

/* OFF FOR THIS BRAND since 2026-08-24. Colorado's facilitator rules
   (4 CCR 755-1, Rule 7.4) allow a facilitator to collect and display
   testimonials but not to solicit them from participants; a review ask on
   the facilitation site is a solicitation. The early return below is the
   guarantee; the settings and the Reviews tab stay as a record.
   Removing this guard is a developer decision, not a dashboard one. */
return;

Then a migration cleared the stored switches so the data could not disagree with the code, stamped the reason and the date into a settings row, took the "invite a review" checkbox off every edit screen, and turned the admin tab into a read-only record with the rule quoted at the top. It also replaced the chunk the staff-facing assistant reads, so asking the dashboard about reviews now returns the rule and what is still allowed rather than instructions for controls that no longer do anything. Four places, one rule. Any one of them left alone would have been a trap for whoever came next.

Why does the mail split across two providers?

Because the domain arrived with a mailbox already sold on it, and the place a site can authenticate is not always the place mail is delivered. This domain receives through a Microsoft 365 tenant at the registrar and sends through the web host's authenticated SMTP, and both have to be true at once without either breaking the other.

The trap in this arrangement cost me an afternoon before I understood it. A forwarding rule set on the sending host does nothing at all for public mail, because inbound routing follows the MX records and those point somewhere else entirely. The sending mailbox is deaf: it holds one welcome message from the host and will never hold anything else. Any alias or forward has to be configured in the tenant that owns the MX.

One record has to admit both halves, or perfectly ordinary mail from the site starts failing checks. This is the live SPF on 4 September 2026, receiving provider first, registrar second, sending host third:

v=spf1 include:_spf-usg2.ppe-hosted.com include:secureserver.net
       include:_spf.mail.hostinger.com ~all

The open item, since I would rather write it down than leave it flattering: the DMARC record is published but not yet at enforcement. That is the correct place to start and the wrong place to stay, and it is on the list. Tightening it is a change that can bounce real mail from a real practice, so it waits for a window where somebody is watching.

Where does the compliance line actually live?

In the copy, on every page, in the same words each time. Oregon's OAR 333-333-6100(1)(e) bars claims that psilocybin products and services "have curative or therapeutic effects", or any health claim not supported by the totality of publicly available scientific evidence. Colorado's Rule 7.3 requires a facilitator to represent their work and qualifications honestly and accurately. Between the two, a whole vocabulary of ordinary wellness marketing is unavailable: no outcomes, no relief, no before and after.

What is left is better copy anyway. The offering page has a section headed "What facilitation is, and what it is not", and it says plainly that this is a licensed non-clinical role, that the facilitator does not diagnose, treat or prescribe, and that where psilocybin is part of a session it is provided through licensed programs and facilities. The same distinction appears as one of the two checkboxes on the booking form. It is in the template, not in a terms page nobody opens.

What generalizes to any regulated build

Read the licence, not the industry. Everything that shaped this site is published, free, and short: two state rule sets that take an afternoon to read, one federal schedule, one ad platform's policy page. Nobody had to interpret anything for me, and the one rule I did not read in time is the one that cost me a feature I had already shipped.

Put the guarantee where a client cannot reach it. Dashboards exist so people can change things without me, which is the whole point of building on a CMS she edits herself. Compliance is the exception: if a rule says a thing must not happen, the switch belongs in the code path, and the dashboard gets an explanation instead of a toggle.

And expect the constraint to arrive as a channel, not as a paragraph. "No paid ads" sounds like a line item in a marketing plan. In practice it decided the age gate's architecture, the depth of the journal, the structured data, and why every one of those pages had to be readable by a crawler that will never confirm its age.

One thing on this build I still cannot verify from my own desk: whether a message sent to the published address lands where it should. Probes from a laptop are useless against that tenant, and the only real test is a person sending a labelled email and nobody getting a bounce. I have run it once. I will run it again when the DMARC policy moves.