Websites for dental practices

Most dental websites are judged on two questions a visitor answers in about fifteen seconds: can I book an appointment without picking up the phone, and do they take my insurance. Everything else on the page is competing for attention that has already been spent.

The intake form is the compliance surface

A dental enquiry form almost always collects a name alongside a reason for visiting, and that pairing is what turns ordinary form data into protected health information. It is not the medical detail on its own and it is not the name on its own. It is the two together, in one submission, which is exactly what a contact form produces by default.

That has a practical consequence most practice sites get wrong. Webflow's terms of service, section 3.6, are headed HIPAA Non-Compliance and have the site owner agree not to provide, or enable visitors to provide, protected health information in connection with the platform. Read on 5 October 2026, that is a contractual undertaking rather than a note about a missing feature. A native Webflow form collecting a dental enquiry is a breach of the agreement the practice accepted, whatever anyone decides about HIPAA itself.

So the form goes somewhere that will sign a business associate agreement, and gets embedded. Jotform states that its Gold and Enterprise plans unlock HIPAA features and a signed agreement. Others do the same at their own tiers. The vendor matters less than two questions: which plan carries the agreement, and where the submission goes afterwards.

The agreement covers the form, not the inbox

This is where the most common failure sits. A business associate agreement with the form vendor covers the form. It does not cover the notification email that lands in a practice inbox, the practice management system the lead is copied into, or the spreadsheet somebody exports on a Friday. Regulated data usually ends up in all three, and none of them was in scope when the form was chosen.

The second failure is quieter: an embedded form that posts to a compliant vendor and also fires an analytics event carrying the field values has put the data back on the page. We see that more often than the first one.

Booking is the thing the site is for

A dental practice has an unusual conversion pattern: the person deciding is often doing it in the evening, after the surgery has closed, frequently in pain or on behalf of a child. A phone number is the wrong answer to that moment. Whether booking is a real integration with the practice management system or a request form that somebody confirms in the morning matters much less than whether it exists at all.

What it must not do is ask for more than it needs. A booking step that demands insurance details, a full medical history and a date of birth before it will accept anything loses the people it was built to catch, and collects a larger regulated payload for the privilege.

The insurance question, answered in public

Almost every new patient wants to know whether their plan is accepted, and almost every dental site answers with a sentence inviting them to call and ask. Naming the plans you accept, and saying plainly what happens when somebody is out of network, removes the single biggest reason a visitor leaves to check a competitor. It is also the page that tends to pick up search traffic nobody planned for, because it is written in the words patients actually use.

What a build here actually includes

Every build is scoped to the practice, but on this kind of site these are the parts that are not optional.

• An embedded intake and booking form from a vendor that signs a business associate agreement, so no regulated data touches the site builder's own form handling
• A written note of where submissions travel afterwards: the notification inbox, the practice management system, anywhere they are exported
• An insurance page that names plans rather than inviting a phone call
• Service pages for the treatments that actually get searched, separated from the ones that only matter to clinicians
• New patient information that answers the first visit, the cost question and the parking, because those are the three things people look for
• Analytics configured so no form field value is ever sent as an event parameter

What we keep seeing go wrong

None of these are hypothetical. They are the things that turn up again and again on sites in this vertical, and most of them are cheap to avoid and expensive to undo.

• A native builder form collecting symptoms, which is both a compliance problem and a breach of the platform's own terms
• A business associate agreement on the form vendor and nowhere else, with the notification email going to a personal inbox
• Booking that is a phone number, when most of the deciding happens in the evening
• An insurance page that says to call for details
• Before and after photography used without separate written authorisation for marketing
• A single services page listing thirty treatments, which ranks for none of them

Questions we get asked first

Can we use a normal contact form on a dental website?

For general enquiries with no health detail, yes. For anything that pairs a name with a symptom, a treatment or a reason for visiting, no: that combination is protected health information, and most site builders both lack the agreement and forbid it in their terms. Webflow's section 3.6 is explicit about it.

Does a business associate agreement make our website HIPAA compliant?

No, and the phrase is doing a lot of work. A website is not compliant or non-compliant on its own. The agreement covers one vendor handling one flow. Compliance is the practice's processes, agreements and hosting taken together, most of which sit outside the site.

Can we still use Webflow for a dental practice?

Yes, and we build dental sites on it. The site is built in Webflow and the regulated flow lives in an embedded form from a vendor that signs an agreement, so nothing protected passes through Webflow's own form handling.

Should the site show before and after photos?

They work, and they need their own written, revocable authorisation from the patient for marketing use, which is separate from treatment consent. Keep the photography conditions consistent, because inconsistent lighting between the two shots is what makes a genuine result look edited.

How long does a dental website take?

Six to ten weeks for a practice site with booking and real service pages. The variable is almost never design: it is how long the insurance list, the treatment copy and the clinician bios take to confirm.