Webflow for Health Tech
A marketing site where the technical details matter. Patients need to understand coverage, providers need to be discoverable, booking has to work, and accessibility cannot be an afterthought.
Built for Nourish and Wild Health.
What these builds involve
What these sites need, and what we figure out first.
What these sites need
- Eligibility and insurance coverage explained where a patient will actually look for it
- Provider and location directories built as collections rather than hand-built pages
- Booking and intake flows handed off cleanly to the scheduling system
- Analytics scoped so no health information ends up in a third-party tool
- Accessibility treated as a requirement, because the audience includes people it was written for
What we figure out first
- What the tracking is allowed to see. Page URLs and form fields in a health context can carry more than they look like they do. Which events fire, and what they carry, is a decision to make before the tags go on rather than after.
- Who signs off on the claims. Copy about outcomes, coverage or clinical process usually needs a named reviewer. Knowing who that is changes the timeline more than any build decision.
- Whether the directory is real data or a page. Twelve providers is a page. Two hundred across forty locations is a collection with a filter, and it decides the CMS structure.
- Where intake actually happens. Embedded, handed off, or rebuilt. Each one changes what the site is responsible for and what happens when someone abandons halfway.
Health tech websites have to do more than explain a product. Patients need to understand coverage. Providers need to be discoverable. Booking has to work. Analytics needs boundaries. Accessibility cannot be an afterthought.
I build those requirements into the site from the beginning.
Make the important questions easy to answer
Healthcare journeys are full of uncertainty.
Do you accept my insurance? Is this available in my state? What will it cost? Can I see someone who specializes in my condition? What happens after I sign up?
Those answers should not be buried across five pages. I build eligibility, insurance, provider, specialty and location content so people can get to the information they need quickly.
Directories that can actually grow
Provider and location directories become difficult when they are treated as ordinary pages.
I structure them as data. Providers, specialties, insurance plans, states and locations can live in CMS collections and feed search, filtering and programmatic landing pages without maintaining hundreds of pages manually.
That creates a better user experience and a much stronger foundation for organic search.
Be deliberate about analytics
Health websites need more restraint around tracking than a normal SaaS site. URLs, form fields and event properties can reveal more than expected.
We first identify what data each page, form and integration actually handles, including the addresses and referrers around them. I work with your privacy and security team to agree the collection rules, the approved systems and the boundary between the marketing site and patient workflows, then implement the approved events across tools like GTM, GA4 and product analytics platforms.
Analytics in a health context
Proposed for review
- Page views on public marketing pages
- Outbound clicks and scroll depth
- Campaign parameters and referrer
- Form submissions as a count, without the fields
Not proposed without an answer
- URLs that name a condition or a treatment
- Form field values posted to a general-purpose tool
- Events that only fire on a patient-only page
- Anything that could join a session to a person
Experiments belong on the marketing side
The line between website and product has a useful consequence: the marketing site is where you can actually test things.
On Nourish I ran a four-variant homepage hero test through Statsig, on the production Webflow site. Not a mockup, not a staging copy: the live page, four versions, real traffic. Nothing about that required moving off Webflow, and nothing about it touched the product.
That is worth saying because the assumption runs the other way. Teams often decide they need to leave Webflow to experiment seriously, when what they actually need is a component system the variants can be assembled from and an experimentation tool that was never Webflow’s job in the first place.
Booking is part of the website experience
A conversion does not end when someone clicks “Get started.”
The transition into eligibility, scheduling, intake or signup has to work. I treat that handoff as part of the build, including attribution persistence, third-party integrations, error states and testing the complete path rather than stopping at the button click.
Where Webflow stops
Marketing, the shared part, and the covered systems
Webflow
The marketing site
- Service and condition pages
- Provider and location directories
- Resources and education content
- SEO and accessibility
The handoff
Decided together
- Scheduling route
- Intake destination
- Analytics scope
- Clinical review
Covered systems
Patient information
- The EHR
- The patient portal
- Anything holding PHI
- Access control and audit
Accessibility belongs in the build
Accessible markup, keyboard behavior, focus states, contrast and sensible content structure are easier to build correctly than retrofit later.
For healthcare, that work is especially important because accessibility directly affects the people the site exists to serve.
The decision worth making before any design happens is which parts of the site could ever touch patient information. Most cannot, and knowing that lets the rest move quickly. Walk me through it and I will tell you where the line falls on yours.
What it connects to
The stack these sites usually run on.
-
Calendly
Embed Calendly in Webflow with prefilled details, campaign attribution, CRM updates and a widget that does not slow every visitor down.
-
HubSpot
Connect Webflow and HubSpot so forms, contacts, attribution and tracking work without giving up the site’s design.
-
Google Analytics
GA4 and Tag Manager set up on Webflow with clean events, consent behavior and performance-conscious loading.
-
Typeform
Embed Typeform in Webflow with hidden fields, attribution, completion handling and downstream delivery to the tools that need the answers.
-
Airtable
Use Airtable as the source of truth and publish selected records into Webflow CMS, with field mapping, deletes and failures all handled deliberately.
-
Zendesk
Add Zendesk chat, support routing or help-center content to Webflow, with loading rules that protect the page and a deliberate plan for where the content lives.
And what they are usually moving off
Before you ask
Questions I get asked about Health Tech.
Is Webflow HIPAA compliant?
Wrong shape of question, and the better one is whether anything on the marketing site needs to handle PHI at all. Usually nothing does: service content, provider information and ordinary lead capture are not patient records. I structure the build so marketing content stays on the marketing site and patient information stays in systems chosen for it. Whether a given vendor will sign a BAA is a contract question for your plan and their current terms, and it gets confirmed before anything is designed around it rather than assumed from a blog post.
Do you need to sign a BAA with us?
Only if the work has me handling PHI, and a well-scoped marketing build does not. The first step is walking the site and deciding which parts touch patient information before any design happens, because that is the decision everything else follows from. If something in scope does, the agreement gets sorted before it is built rather than after.
Can we use a Webflow form for patient intake?
Not for patient intake, and this is the one I would put in writing. A standard Webflow form posts to Webflow, which is the right destination for a contact enquiry and the wrong one for patient information, so an intake form built the easy way is a problem that looks like a working feature. Intake gets handed to the system chosen to hold that data, and Webflow builds the page around it.
Where does the line between the marketing site and the product actually sit?
At the point where a visitor becomes a patient. Everything up to that moment is website work: how you explain the thing, who it is for, what it costs. Everything after is product. That transition is the one seam worth real time, because two teams own it and therefore nobody does.
Can you handle clinical claims review?
I cannot review them, but I can build so review is not painful. Claims are structured as content rather than typed into pages, so a reviewer redlines copy without a developer and a change propagates everywhere. Assume review is the longest step and plan around it.
What about accessibility requirements?
Not a checkbox here, it is part of whether the site works for the people it is for. WCAG 2.2 AA: real contrast ratios, keyboard paths, headings that describe the page, forms usable without a mouse. Easier during the build than as the remediation most audits turn into.
Can you integrate our EHR, scheduling, or patient portal?
The site hands off to them cleanly, which is almost always right. Scheduling widgets, portal logins and intake flows get embedded or linked rather than rebuilt, so the covered system stays covered. If something needs to read data before the page is sent, it belongs in your product.
We already have a site. Can you fix it rather than rebuild it?
Often, and I would rather tell you that than sell you a rebuild. The first step is an assessment: sometimes three specific things, sometimes the platform itself is the constraint and a migration is the honest answer. You get the recommendation either way.
Will our non-technical team be able to manage it?
That is a build decision, not a training problem. I scope the Editor so marketing or communications can change words, images and content without touching layout or code. If your team needs a developer to fix a typo, the previous build made a choice, and it is reversible.
Do you work with early-stage health tech companies?
Yes, and it is often the better time. The structural decisions about where content lives and where PHI does not are much cheaper before there is a site to unpick. A monthly retainer suits that stage better than a scope written before you know what the site needs to say.
Building something else?
Reach out and see if we are a good fit.
Currently booking two to four weeks out.