A multi-state sleep medicine practice came to us in March 2026 with a WordPress site that was eight years old, stuck at Lighthouse scores in the 50s, and quietly violating HIPAA every time a patient submitted an intake form. Over April and May 2026 we migrated the site to Next.js on Vercel, moved 250 blog posts without a single redirect break, built 20 city-specific landing pages for local patient acquisition, and replaced the entire form layer with HIPAA-compliant components backed by signed Business Associate Agreements. Performance shipped at Lighthouse 96. The client left a verified five-star review on Clutch covering quality, schedule, cost, and willingness to refer.

This is what that work actually looked like, what we found inside a typical mid-size HIPAA WordPress stack, and what we would tell any healthcare practice running WordPress in 2026.

Why does a HIPAA sleep medicine practice outgrow WordPress?

Three pressures stack up faster than most practices realise. First, plugin sprawl. The site we inherited ran 47 active plugins. Eleven of them touched patient data in some form: an intake form builder, a chatbot, a "schedule a sleep study" widget, an SMS reminder integration, two analytics scripts, an A/B testing tool, and four marketing add-ons that quietly logged form fields to third-party endpoints. Not one of those vendors had a Business Associate Agreement on file. Under the HIPAA Privacy Rule, every one of those data flows is a potential breach.

Second, performance under HIPAA-aware hosting. Most HIPAA-compliant WordPress hosts carry meaningful overhead because the security model requires private networking, signed BAAs, encrypted backups, and tight access control. That hosting profile fights with the WordPress execution model: every page hits PHP, every query touches MySQL, every plugin loads on every request. The result on this site was 4.8s LCP on mobile and a Lighthouse performance score that fluctuated between 48 and 62 depending on the page.

Third, structural SEO debt. The practice had eight years of blog posts (mostly written by clinicians on topics like sleep apnea, CPAP titration, and pediatric sleep studies) and zero city-specific landing pages. Local search for "sleep doctor near me" or "sleep study Phoenix" was dominated by national directories and urgent care chains. The same competitive pattern is covered on our medical practice SEO services page.

What did we actually build?

The architecture is straightforward in shape and deliberate in detail. The frontend is Next.js deployed on Vercel. Content (blog posts, service pages, city pages) is served as fully static HTML built at deploy time, which means every page response is a sub-100ms edge fetch. Where we needed dynamic behaviour (patient intake, appointment requests, the symptom checker), we used Next.js route handlers backed by HIPAA-compliant API endpoints. The headless WordPress backend (kept behind a non-public subdomain at cms.) handles editorial workflow, because the clinical writers were not going to learn a new CMS in six weeks.

Forms moved off the WordPress plugin entirely. We replaced every patient-facing form with a custom React component talking to the HIPAA-aware form handler we maintain. The handler encrypts payloads at rest, logs an audit trail of every submission (who saw it, when, from where), and never touches third-party tag managers, ad networks, or chat widgets that lack a BAA. This is the single biggest source of accidental HIPAA violation we see across mid-size practices, and it does not show up in a security scan because the leakage is by design at the marketing-vendor layer.

Hosting respects the same boundary. Static pages serve from Vercel's edge, but anything touching PHI routes to a separate HIPAA-compliant infrastructure with a signed BAA from the upstream provider. The full architecture is closer to the pattern we describe in HIPAA-compliant website development and HIPAA-compliant hosting.

How do you move 250 blog posts without losing SEO?

Carefully, and with a redirect map verified twice. The 250 posts had been edited, re-edited, and occasionally republished under new slugs over eight years, so the source data was messy: duplicate URLs, two posts with overlapping topics, three with broken internal links to deleted pages, and a tag taxonomy with 180 tags many of which had a single post under them.

We exported the WordPress database, ran an internal cleanup pass to consolidate near-duplicate posts and prune the tag taxonomy down to a usable 24 tags, then imported into the headless WordPress backend with new clean URLs. Every old URL got an explicit 301 to its new equivalent, including the slash and no-slash variants and the legacy ?p=1234 permalinks that WordPress emits for old posts. We hand-mapped 23 edge cases where a single old URL needed to merge into two new posts or vice versa.

Schema parity mattered as much as redirects. Each post got Article schema with datePublished, author as a Person (the clinician who wrote it, not a generic agency byline), and publisher with logo. Google's own guidance on article structured data is explicit about the Person requirement, and missing it on health content is one reason E-E-A-T signals stay weak.

The post-migration Search Console report showed zero indexing dropouts on the migrated posts after the 21-day reassessment window. No traffic was lost. We cover the broader playbook for this on our WordPress to Next.js migration page.

How did you build 20 city-specific landing pages without spammy templates?

The Achilles heel of programmatic city pages is duplicate-flavoured content. If a "Sleep Doctor in Phoenix" page reads identically to "Sleep Doctor in Tucson" with the city swapped, Google treats it as scaled content abuse, which is now an explicit spam policy violation. We built each city page from three differentiated layers: a clinical content layer (same for every city, because the medicine does not change), a local proof layer (NAP, location-specific reviews, accepted insurance carriers in that state, in-person clinic hours, parking and access notes), and a competitive context layer (we research the dominant 2-3 local competitors per market and frame our differentiators against them).

Each page got MedicalBusiness and LocalBusiness schema with verified address, geo, openingHoursSpecification, and medicalSpecialty properties. Local search visibility for queries like "sleep apnea Phoenix" and "pediatric sleep study Tucson" started appearing on page one within four weeks. For other practices, we apply the same pattern from healthcare SEO and SEO for medical practices.

What does HIPAA-compliant form handling actually require?

Most "HIPAA-compliant form" plugins are HIPAA-aware in name and HIPAA-leaking in practice. To handle protected health information legally, the form layer needs all of these, not most of them: a signed BAA with every vendor in the data path, including the analytics provider and the email sender; no third-party scripts in the form's network graph (no Hotjar, no Facebook Pixel, no Google Tag Manager containers that could load arbitrary code, no chat widgets); end-to-end encryption between browser and backend; encryption at rest in the database; access logs that record every read of the data with timestamp, user, and source IP; automatic redaction of fields in error logs; and an explicit consent string captured at submission time.

We rebuilt the practice's seven patient-facing forms (new patient intake, sleep study referral, CPAP titration follow-up, billing inquiry, records request, telemedicine consent, and general contact) on top of this stack. Every submission produces an audit-log entry that the practice's compliance officer can pull on demand. The full pattern lives at HIPAA-compliant forms and chat development.

What did the numbers actually look like?

Before our work, the practice's site averaged Lighthouse 52 on mobile and 71 on desktop. After launch, Lighthouse mobile shipped at 96. Largest Contentful Paint dropped from 4.8s to 1.1s. Cumulative Layout Shift fell from 0.34 to 0.02. Time to First Byte at the edge holds under 80ms in most US cities. Web.dev's Core Web Vitals documentation sets the "good" threshold at LCP under 2.5s and CLS under 0.1; the site cleared both with margin.

The Clutch review captures the rest: five out of five on quality, schedule, cost, and willingness to refer. The client noted the depth of the pre-launch verification work as the standout (a 50+ item checklist covering BAA verification, redirect QA, schema validation, accessibility audit, form-security testing, and a competitor SEO analysis the practice had not asked for).

What is the 50-point pre-launch verification checklist?

The full checklist is internal, but the categories are: BAA verification on every vendor in the data path (12 items), redirect QA across the old URL set with a crawler that diffs status codes and Location headers (8 items), schema validation against Google's Rich Results Test on a sampled subset of posts and pages (6 items), WCAG 2.2 AA accessibility audit including keyboard navigation, focus order, colour contrast, and screen-reader labels (9 items), form security testing including XSS, SQL injection, and PHI leakage to third parties (7 items), Core Web Vitals snapshot from a controlled environment using mobile-throttled Lighthouse (5 items), and a competitor SEO analysis covering the top three local competitors per market (4 items).

Nothing on the checklist is exotic. Almost every item is something most agencies say they do and very few actually verify before turning the DNS over. The 50-point list is what we run on every migration; the same discipline is reflected on our HIPAA-compliant website redesign and HIPAA-compliance audit pages.

What does this mean if you are running WordPress and HIPAA in 2026?

The honest answer is that the cliff is real. WordPress is not unsafe for HIPAA workloads inherently, but the plugin ecosystem actively encourages patterns that are. Every form vendor without a BAA, every analytics script loaded on a page that displays patient data, every chatbot offering "convenient patient communication" is a potential reportable breach. The penalty under the HHS Office for Civil Rights HIPAA enforcement framework starts at $137 per violation and tiers up to $68,928 per identical-violation per year. A single misconfigured form on a busy practice site can clear that ceiling in a quarter.

Migrating off WordPress is not the only answer. Some practices stay on WordPress with a much tighter plugin profile and BAA-backed vendor stack. What matters is that the data path is audited end to end, not assumed safe because the host advertises HIPAA compliance.

If you are working through this for your own practice and want a second pair of eyes, our HIPAA-compliance consulting and HIPAA-compliant website development pages walk through how we approach it.

The verified Clutch review for this engagement is at clutch.co/profile/social-animal.