What a therapy practice website should never ask for

The site for my own counseling practice is still up. I read all nineteen URLs in its sitemap again on 4 September 2026, looking for a health question, and there are none. There is not a form element anywhere on it today, and back when there was one, it asked for a name, an email, a phone number and a sentence. Modesty had nothing to do with it. That was the only version of the page I could defend.

What does a therapy practice website actually have to do?

Four things, and they are smaller than most practice sites assume.

It has to be findable for what a person in trouble actually types. It has to say who the practice is for, precisely enough that the wrong person can rule themselves out without booking. It has to make the first move take one step. And it has to say plainly what it is not, because a therapy site that oversells creates a clinical problem rather than a marketing one: somebody arrives expecting a thing that is not there.

The findable half is its own subject and I wrote it up separately in why a therapy practice does not show up on Google. What is on the site is the shape of that answer: six pages for the conditions I actually worked with, five for the insurance panels I billed, then telehealth, rates, group and the rest. Nineteen in total, each one aimed at a sentence somebody types at eleven at night.

The fourth job is the one nobody builds. Mine is a sentence in the philosophy section, in my own words: call or schedule a first meeting and we will work out whether it is a fit, and Oregon is full of great therapists, so if you are not feeling it, no problem. A site that says that out loud will lose some inquiries. Every one it loses is a first session that would have ended in a referral anyway.

Is a therapy practice website covered by HIPAA?

The practice is. Most of the website is not. The line moves the moment a visitor types something into it.

Start with who is regulated. The definition at 45 CFR 160.103 is short enough to read in full, and the third clause is the one that catches a private practice:

Covered entity means: (1) A health plan. (2) A health care clearinghouse. (3) A health care provider who transmits any health information in electronic form in connection with a transaction covered by this subchapter.

A practice that bills insurance is transmitting health information electronically. Mine billed five panels, so there was never a question about which side of that line I was on.

Then there is the question of what counts as the protected information. Protected health information is individually identifiable health information held or transmitted by a covered entity, so the definition of that second term, in the same section, is where mental health work stops being an edge case. Information qualifies when it is created or received by a provider, relates to "the past, present, or future physical or mental health or condition of an individual", and either identifies the person or could reasonably be used to. The word that does the work is the last one in that list. Not diagnosis, not treatment: condition. A name next to a reason for getting in touch is already there.

The clearest official statement about what a website is and is not lives in the Office for Civil Rights bulletin on online tracking technologies. It draws its line at the login. For the public half of a site, it says this:

Tracking technologies on many unauthenticated webpages do not have access to individuals' PHI; in this case, a regulated entity's use of such tracking technologies is not regulated by the HIPAA Rules.

Read that next to what the same bulletin says happens when the public page starts asking questions:

tracking technologies might collect an individual's email address, or reason for seeking health care typed or selected by an individual, when the individual visits a regulated entity's webpage and makes an appointment with a health care provider or enters symptoms in an online tool to obtain a health analysis. In this example, the regulated entity is disclosing PHI to the tracking technology vendor, and thus the HIPAA Rules apply.

That is the whole design brief for a practice site in two paragraphs. A page about the practice is an ordinary web page. A box that takes "what brings you in" is not, and the analytics you dropped on it in five minutes came along for the ride.

One honest complication, and it is the reason to read the source rather than a summary of it. Part of that bulletin no longer stands: a June 2024 order out of the Northern District of Texas vacated the theory that HIPAA obligations are triggered where a technology connects an IP address with a visit to a public page about a specific condition or provider, and HHS says it is evaluating its next steps. The appointment and symptom passage above is a different one and the order did not reach it, which I go through at length in the post about what $99 a month buys a practice. I am a builder quoting a regulator, not a lawyer; hhs.gov returns a 403 to my fetcher, so I read the guidance and the FAQ below through the Internet Archive's captures on 4 September 2026, and anyone shipping on this should read the current page themselves.

My own site never got as far as needing the argument. The theme prints a Google Analytics tag only when a settings row holds an ID, and that row is empty, so no tag renders on any page. Web fonts and an icon library are still third-party requests on the inner pages and still see an IP address, which is worth saying rather than claiming a purity the network log would not support. Why the paid version of this refuses scripts outright is in that same post.

What did the contact form ask for?

Four fields, and none of them clinical.

Until August of this year the site had one contact form, in a modal that opened from any contact button. Your name. Email. Phone. And a box labeled "How can I help?", whose placeholder read "A sentence or two about what brings you in." Underneath, one line of fine print: "Confidential. Your message comes straight to Eric, LPC."

No date of birth. No insurance member number. No dropdown of presenting problems, which is the field a booking plugin will happily generate for you and the single worst thing on a practice website. The validation that ran on the way in is the whole policy in six lines:

/* validation: name + message required, a way to reach back required,
   no header injection */
foreach (['name' => $name, 'email' => $email, 'phone' => $phone] as $k => $v) {
    if (preg_match('/[\r\n]/', $v)) $done(false, 'That didn\'t look right.');
}
if ($name === '' || mb_strlen($name) > 120)   $done(false, 'Please add your name.');
if ($email === '' && $phone === '')           $done(false, 'Add an email or phone so I can reply.');
if ($message === '' || mb_strlen($message) > 5000) $done(false, 'Please include a short message.');

A name, a message, and at least one way to reply. That is the entire requirement. Around it sat the ordinary furniture: a CSRF check, a honeypot field that bots fill and people never see, and a limit of five submissions per address per hour.

Here is the honest boundary, because a form cannot enforce restraint. Somebody will type a diagnosis into a free-text box no matter what the label says, and I have no way to stop them. What I decide is what the page invites, where the answer lands, and how far it travels. It landed in one row of a leads table and one email to the practice inbox, and nothing more was ever asked for.

What about email, which is not encrypted?

HIPAA permits it, and the condition it attaches is about restraint rather than technology. OCR's answer to that exact question, FAQ 570, has been on the HHS site since the Privacy Rule was young:

while the Privacy Rule does not prohibit the use of unencrypted e-mail for treatment-related communications between health care providers and patients, other safeguards should be applied to reasonably protect privacy, such as limiting the amount or type of information disclosed through the unencrypted e-mail.

Limiting the amount or type of information. On a website, the field list does that limiting, not a policy, an encryption setting or a banner. Whatever the form asks for is the ceiling on what arrives in an ordinary inbox, gets quoted into a reply, and sits in a mail archive for years. A privacy policy is a paragraph a person has to believe. The field list is the policy that actually runs.

Where does the intake actually happen?

One link away, behind a login, on a domain where the paperwork is somebody's contractual job.

The booking button never posted to my server. It carried a single setting, booking_url, pointing at a client portal on the scheduling vendor's own domain, and the site's booking page says plainly what happens on the other side of it: appointments, digital paperwork, secure messaging, billing on file. That is where a real intake belongs, because that is where a business associate agreement already exists and where the same OCR bulletin says the rules unambiguously apply. Its words for the other side of the login: "Tracking technologies on a regulated entity's user-authenticated webpages generally have access to PHI."

The comparison I keep coming back to is a regulated practice I built for a client, where the booking engine lives inside the CMS instead of on a vendor's portal, described in what a licensed practice site needs. That was the right answer there and the wrong one here, and the difference comes down to who signs for the data rather than to taste. Building the calendar means accepting the record; linking to the portal means declining it. Both are defensible. Doing the first by accident, because a plugin made it easy, is not.

What does the site do about money?

It publishes numbers and takes none.

The rates panel says $160 for fifty minutes one to one and $185 for couples, lists the five panels I billed with the Oregon Health Plan line carrying a zero dollar copay badge, and is headed "I handle the billing for you." There is no card field anywhere on the domain, and no payment script in any of the nineteen pages: no Stripe, no PayPal, nothing. Cards live in the health record system, on autopay, next to the claims they belong to.

Printing the fee is the part solo clinicians resist and the part that pays. A person deciding whether they can afford therapy this month should not have to perform an inquiry to find out, and a practice with a waiting list does not need the inquiries it turns away.

Why are there no client testimonials on it?

Because a counselor licensed in Oregon is not allowed to ask for one.

The Board of Licensed Professional Counselors and Therapists adopts the 2014 ACA Code of Ethics as its code of conduct, and its own advertising rule, OAR 833-100-0012(3), says this: "Testimonials from current clients are not solicited for advertising or other purposes due to the client's vulnerability to undue influence." Read the reason rather than the prohibition. The person you would be asking is a person you hold power over, a request from a therapist is not a neutral request, and that objection bites earlier than the Federal Trade Commission's, which is about the reader being misled. Where the Oregon rule, the stricter ACA standard and the FTC's 2024 review rule actually part company is worked through in that post about the $99 subscription, because a review tool has to answer all three.

Which leaves a practice site with no social proof at all, and something has to stand in its place. On mine it is the license number printed under the hero, the credential next to it, the fee, the panels, and a verification badge from a directory that checks licenses. Facts a stranger can go and confirm, none of them a promise about how anyone turns out. The same advertising rule handles that half too: an outcome is not the clinician's to guarantee, so a claim about one is misleading before it is anything else.

What those refusals turned into

A set of defaults I now ship to other clinicians instead of re-deciding.

Everything above started as a series of small refusals on one site, and it is now the shape of Grow Your Clinical Practice, the subscription I build practice sites under. Foundation, at $99 a month, carries forms written to this standard and no tracking scripts on any page that has one. Consult bookings go to the practice's own Google Workspace or Microsoft calendar, both of which are covered by a business associate agreement, rather than to a calendar I hold. The consult message box asks for "anything you'd like me to know before we talk" and stops there, and even so the request is treated as protected from the moment it is stored, because that is the cautious reading and it costs nothing. It is all written out on the page listing what the service stores and what it never touches.

The portable version, the thing I would tell any developer taking on a clinical client: decide what a form is allowed to receive before you decide what it looks like. Field lists are cheap to write and expensive to remove, and every extra question is a promise about storage, about mail, about somebody's fifth year of therapy showing up in a search of your inbox. Where the instinct comes from, I wrote up separately in the post about the clinical decade behind the engineering. The practice itself, and what the site was built to do while it was running, is the case study at CUTI Therapy.

The last feature I shipped to my own practice site was a way to leave it. On 5 August 2026 the booking and contact buttons stopped opening a form and started opening a five-second notice that sends people to a directory of other Oregon providers instead. The form came out of the theme that day. Writing this post, I went looking for it and found that the route behind it is still registered, because the module loader picks up every folder it finds, and the empty leads table is still in the schema. The page title still says accepting new clients, and the contact section still carries a now accepting badge, which is the same problem one layer up in the copy. Retiring all four is the next thing I owe the site. It is the sort of thing you only find by going to look for what you removed.