Can a website "be HIPAA compliant"?
Not as a unit. The hosting provider receives one set of data, the form vendor another, the chat vendor a third, and every tag on the page its own. Each recipient either is or is not under a business associate agreement, and each flow either is or is not minimized. The honest form of the question is a table, so here is the table.
Component by component
| Component | What it receives | What it requires |
|---|---|---|
| Hosting / infrastructure | IPs, request logs, stored content | An infrastructure BAA - generally available from the major clouds; the configuration is still yours |
| CMS | Admin access; form data when forms are native | A BAA if PHI touches it, or an architecture that keeps PHI out of it |
| Forms | Whatever patients type, plus hidden fields | BAA-covered vendor; link-not-data notifications; a clean thank-you page |
| Chat | Symptoms and identity in free text | BAA, access controls, transcript retention limits |
| Analytics | IP plus health-context URLs and titles, every pageview | BAA-covered or first-party measurement; verified minimization elsewhere |
| Call tracking | Caller number, recording, prompting page context | BAA, recording controls, retention limits |
| Video embeds | Viewing behavior on the pages that host them | Placement review on condition pages; privacy-mode embeds where offered |
| Fonts / CDNs | IP and page URL on every load | Low content, but still a recipient - self-host where it is trivial to do so |
| Social / ad pixels | Page context joined to platform identity | Removed from sensitive paths or consent-gated - and verified, not assumed |
| Patient portal | Authenticated PHI by definition | A fully covered stack, kept architecturally separate from marketing-site tooling |
The unauthenticated-page question
Regulators took the position that tracking on unauthenticated health pages can transmit protected information; litigation in 2024 vacated part of that guidance for unauthenticated pages. It would be a mistake to read the vacatur as clearance: the civil litigation record against hospitals over exactly this data kept growing on other legal theories, state privacy laws increasingly treat health-context browsing as sensitive on their own force, and the FTC has pursued health platforms outside HIPAA entirely. Designing to the floor of what survived one ruling is a bet, not a posture - and the bet is placed with the organization's name on it.
The embed problem
Every embed is someone else's code running on your page: a video player, a map, a social feed, a review widget. Each brings its host's tracking with it, and each was almost certainly added by someone thinking about content, not recipients. On a condition or service-line page, an embed's telemetry is health-context data like any pixel's. The audit treats embeds as tags, because technically that is what they are.
Working rule: the compliance status of a page is the compliance status of its worst recipient. One uncovered vendor on an oncology page sets the exposure for the whole template.
What order should remediation follow?
Runtime inventory first - every outbound request per template, before and after consent. Classify each recipient: BAA in place, BAA available, or no path. Minimize what remains, then re-verify at runtime. None of this is legal advice; it is the engineering sequence that gives your legal and privacy teams something true to review.