A practical pre-launch website risk checklist for healthcare practices

Most healthcare website problems are not exotic. They are a handful of ordinary web-development defaults that become genuinely risky in a healthcare context — an analytics tag on a booking page, a contact form posting over plain HTTP, a privacy policy copied from a template in 2017. The pattern in recent enforcement and litigation is remarkably consistent, which means a checklist can cover most of it.

This is the checklist we wish every practice ran before (and after) launch. It is ordered roughly by severity-per-minute-of-effort. None of it is legal advice; all of it is checkable from the outside, today.

1. Transport security: the table stakes

Everything over HTTPS, no exceptions. If any page of the site — or any form action — is reachable over plain http://, anything a visitor types can be observed in transit. For a site where people type symptoms and insurance details, that is a critical issue, not a technicality.

• Serve every page over HTTPS and 301-redirect HTTP to HTTPS.
• Check the certificate: valid, not expiring imminently, hostname matching (including www.). Automate renewal — most expiries are forgotten cron jobs, not decisions.
• Add Strict-Transport-Security once you are confident, so browsers stop trying HTTP at all.
• Hunt down mixed content: an HTTPS page loading scripts or images over HTTP undermines the lock icon you just earned.

2. The tracker inventory: where the enforcement risk lives

If you read only one section, read this one. Advertising pixels and analytics on patient-facing pages are the fact pattern behind the breach notifications, class actions, and the joint FTC/OCR warning of 2022–2024 (the Meta Pixel story is the canonical example).

• List every third-party script, pixel, and iframe on the site. Include tags loaded indirectly via Google Tag Manager — audit the container itself.
• Classify your pages: which ones are appointment booking, intake/registration, patient portal, or condition-specific scheduling? Those are patient-facing.
• Remove ad pixels (Meta, TikTok, Google Ads remarketing) and session-replay tools (Hotjar, FullStory, Clarity) from patient-facing pages. This is the highest-value single change on this list.
• For analytics on general marketing pages, make sure nothing identifying leaks: no emails or names in URLs, no health details in event parameters. (More nuance in our Google Analytics explainer.)

3. Forms: how data actually leaves the page

Intake and contact forms are where visitors hand you information, so the mechanics matter.

• Never use method="GET" on a form that collects anything sensitive — GET puts submitted values into the URL, where they persist in server logs, browser history, and Referer headers sent to third parties.
• Form action URLs must be HTTPS, and ideally on your own domain. A form posting directly to a third-party endpoint means that vendor is receiving the data — which is fine only if you know it, chose it, and have the right agreement in place.
• Mark sensitive fields (identifiers, insurance numbers) with autocomplete="off" so shared and kiosk devices do not retain them.
• Do not let session-replay or "advanced matching" tooling capture form field contents. Test this empirically — watch the network tab while typing.
• Put a short note near the form telling people not to submit detailed medical information through general contact forms.

4. The privacy policy: cheap to fix, telling when wrong

Plaintiffs' complaints repeatedly leaned on the gap between what a privacy policy said and what the site actually did. The fix costs a few hours with counsel.

• Have a privacy policy, linked from every page footer.
• It should disclose the analytics and advertising technologies you actually use — after you complete the inventory in step 2, this becomes a factual exercise rather than guesswork.
• It should say whether information is shared with third parties and offer a privacy contact method.
• For a healthcare organization, reference your health-information practices (and your Notice of Privacy Practices, which is its own HIPAA requirement).
• Check the "last updated" date. A policy untouched since before December 2022 predates the entire online-tracking guidance era and is probably stale.

5. Security headers: defense in depth

These response headers cost minutes to add and quietly prevent whole bug classes. External scanners (ours included) check for:

• Content-Security-Policy — constrains what scripts can load; the structural defense against injected or forgotten tags. Start in report-only mode.
• X-Frame-Options (or CSP frame-ancestors) — stops clickjacking.
• X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy — small, sensible defaults; a restrictive Referrer-Policy also keeps your page URLs out of third-party logs.

6. Infrastructure hygiene: the embarrassing failure modes

Rare, but severe when present, and trivially findable by anyone:

• No exposed .git/ directory or .env file in the web root — these leak source code and credentials.
• No directory listings on upload folders (a classic WordPress default) — patient documents have ended up browsable this way.
• No database dumps or site archives (backup.sql, site.zip) sitting at guessable URLs.

7. Make it repeat

The uncomfortable truth: this checklist decays. Marketing adds a campaign tag, a redesign swaps the form handler, a certificate renewal silently fails. The practices that stay clean are the ones that re-check on a schedule — weekly or monthly, automatically, with an alert when something new appears.

That is the product case for continuous monitoring, but even if you never pay anyone a dollar: put a quarterly calendar reminder on this checklist. The 2022–2024 enforcement wave happened to organizations that checked never.

Want the inventory done for you? A free Sift Health scan runs the external-facing parts of this checklist in about a minute — transport security, tracker inventory with patient-page classification, form analysis, privacy-policy signals, headers, and hygiene probes — and returns a 0–100 risk score with a recommendation for every finding. It is a risk indicator, not a compliance audit or legal determination. But it is the fastest way to find out whether your launch checklist actually held.