Een middelgroot orthopedisch praktijk in het zuidoosten kwam naar ons toe met een probleem dat pijnlijk gebruikelijk is in healthcare: hun WordPress-site was traag, hun patientinname was een nachtmerrie van PDF-downloads en fax-terugzendingen, en hun IT-complianceofficer verloor slaap over HIPAA-blootstelling. Zes maanden later hadden ze een Next.js frontend, Payload CMS backend, HIPAA-veilige patientinname-formulieren, en Lighthouse scores die de websites van hun concurrenten eruitzagen alsof ze op dial-up draaiden. Dit is precies hoe we het deden.

Inhoudsopgave

Healthcare Practice: WordPress naar Next.js + Payload CMS Migration

Het startpunt: Waar we mee werkten

De praktijk—laten we hen Southeastern Ortho noemen (NDA, je kent het)—liep al sinds 2017 op WordPress. Hun setup was typisch voor een healthcare practice die organisch was gegroeid zonder veel technisch toezicht:

  • WordPress 6.2 met 34 plugins (11 ervan waren meer dan een jaar niet bijgewerkt)
  • Gedeelde hosting op een plan dat $29/maand kostte
  • Contact Form 7 voor patiëntenonderzoeken—geen encryptie, geen BAA met de hostingprovider
  • PDF-inname-formulieren die patiënten moesten downloaden, afdrukken, handmatig invullen en vervolgens per fax of ter plaatse moesten inleveren
  • Laadtijden gemiddeld 6,8 seconden op mobiel
  • Lighthouse mobiele score: 38

Die Lighthouse score is geen typefout. Achtendertig. De site had ongeoptimaliseerde hero-afbeeldingen (één was een PNG van 4,2MB), render-blocking CSS van vijf verschillende plugins, en jQuery laadde drie keer vanwege plugin-conflicten.

Maar het echte probleem was niet prestatie. Het was risico.

Hun contactformulieren verzamelden patiëntnamen, telefoonnummers en soms beschrijvingen van medische klachten. Die gegevens stroomden door een niet-versleuteld form-plugin, werden opgeslagen in een WordPress-database op gedeelde hosting, en werden gebackuped naar een service zonder Business Associate Agreement (BAA). Hun complianceofficer had dit gemarkeerd, en hun malpractice-verzekeringsmaatschappij stelde scherpe vragen.

De opdracht

De praktijk had nodig:

  1. Een snelle, moderne website die de kwaliteit van hun zorg weerspiegelde
  2. HIPAA-veilige patientinname-formulieren die het papierproces vervingen
  3. Een CMS die de kantoorbeheerder kon bijwerken zonder een ontwikkelaar aan te roepen
  4. Betere SEO-prestatie (zij verloren lokale zoekrankings aan nieuwere praktijken)
  5. Dit alles zonder de begroting te sprengen—zij zijn een medische praktijk, geen tech startup

Waarom Next.js en Payload CMS

We evalueerden verschillende architectuuropties. Hier is de eerlijke vergelijking die we aan de cliënt presenteerden:

Optie Voordelen Nadelen Geschatte kosten
WordPress-herbouw (nieuw thema + plugins) Vertrouwd voor personeel, lagere initiële kosten Dezelfde HIPAA-risico's, prestatieplateau, plugin-afhankelijkheid $15-25K
Webflow + formulieren van derden Snel te bouwen, goede prestatie Beperkte HIPAA-complianceopties, doorlopende kosten per persoon, vendor lock-in $20-30K
Next.js + Payload CMS Volledige controle, HIPAA-veilige architectuur, beste prestatie Hogere initiële investering, vereist hosting-beheer $35-50K
Next.js + Sanity Geweldige bewerkingservaring, goed ecosysteem Sanity's prijzen schalen met gebruik, PHI-verwerkingsproblemen met cloud-hosted CMS $30-45K

We aanbevolen Next.js met Payload CMS, en hier is waarom.

Next.js was de juiste frontend

Next.js 14 (dit project startte eind 2024, en we draaien nu op 15) gaf ons precies wat een healthcare-site nodig heeft:

  • Statische generatie voor contentpagina's — artsenbiografieën, servicebeschrijvingen, locatiegegevens. Deze pagina's veranderen zelden, dus genereren we ze vooraf bij bouwtime. Zero serverberekening bij requesttijd betekent snelle TTFB.
  • Server Components voor dynamische content — beschikbaarheid van afspraken, blogposts, en logica van inname-formulieren profiteren allemaal van server-side rendering zonder onnodige JavaScript naar de client te sturen.
  • Image optimization uit het vak — next/image met automatische WebP/AVIF-conversie vervangen die 4MB PNG's met correct aangepaste, lazy-loaded afbeeldingen.
  • Middleware voor veiligheidsheaders — we gebruiken Next.js middleware om strikte CSP-headers, HSTS, en andere veiligheidsheaders in te stellen die HIPAA-auditors graag zien.

Als je nieuwsgierig bent naar onze aanpak, hebben we onze Next.js development-mogelijkheden in meer detail gedocumenteerd.

Payload CMS was de juiste backend

We kozen Payload CMS 3.0 boven andere headless-opties om verschillende redenen specifiek voor healthcare:

Self-hosted van nature. Payload draait op je eigen infrastructuur. Dit is niet onderhandelbaar voor HIPAA. Wanneer je Protected Health Information (PHI) verwerkt, moet je precies weten waar je gegevens zich bevinden, wie er toegang toe heeft, en moet je in staat zijn een BAA te ondertekenen met je infrastructuurprovider. Cloud-hosted CMS-platforms zoals Contentful of Sanity slaan gegevens op hun servers op—en hoewel sommige HIPAA-compliance op enterprise-niveau bieden, is de kosten doorgaans 3-5x wat je zou betalen om Payload self-hosted op een HIPAA-geschikt leverancier te draaien.

TypeScript-native. De config van Payload is gewoon TypeScript. Dit betekent dat onze content-modellen, API-responses, en frontend-types allemaal dezelfde waarheidsbron delen. Wanneer de kantoorbeheerder een nieuw veld voegt toe voor "verzekeringspre-autorisatienummer" aan het inname-formulier, weet onze frontend erover door gegenereerde types.

Ingebouwde toegangscontrole. Payload's veldniveau-toegangscontrole betekende dat we rollen konden maken waar de marketingpersoon blogposts en servicepagina's kon bewerken, maar geen raking had aan patientinname-gegevens. De kantoorbeheerder kon intakebijdragen bekijken, maar kon de formulierstructuur niet wijzigen. Deze granulariteit is belangrijk wanneer je toegangscontroles voor compliance documenteert.

Rich text goed gedaan. Payload gebruikt Lexical (voormalig Slate) voor rich text, en de bewerkingservaring is echt goed. De kantoorbeheerder van onze cliënt, die jaren WordPress gebruikte, voelde zich op het adminpaneel van Payload binnen één 45-minuten trainingssessie thuis.

We werken regelmatig met Payload en andere headless CMS-platforms—je kunt meer zien over onze headless CMS development-aanpak.

HIPAA-overwegingen in een headless architectuur

Laat me iets duidelijk stellen: geen technologie-stack is "HIPAA-compliant" op zichzelf. HIPAA-compliance is een organisatorische praktijk, geen software-functie. Wat een tech stack kan zijn, is "HIPAA-veilig"—wat betekent dat het geen onnodig risico introduceert en de administratieve, fysieke, en technische waarborgen ondersteunt die HIPAA vereist.

Hier is wat we implementeerden:

Infrastructuur

  • Hosting: AWS met een getekende BAA. We gebruikten ECS Fargate voor de Payload CMS-container en implementeerden de Next.js frontend op Vercel (wat geen PHI verwerkt—belangrijk onderscheid).
  • Database: Amazon RDS PostgreSQL met encryptie in rust (AES-256) en encryptie in transit (TLS 1.2+). Payload 3.0 ondersteunt Postgres native, wat een grote reden was waarom we op v3 wachtten.
  • Bestandopslag: S3 met server-side encryptie, bucket-beleid dat toegang beperkt, en versiebeheer ingeschakeld voor audittrails.

Gegevensstroom voor patientinname

Dit is waar de architectuur interessant wordt. Het patientinname-formulier leeft op de Next.js frontend, maar we verzenden nooit PHI door Vercel's infrastructuur.

Patiëntbrowser → HTTPS → API Route (Next.js op Vercel) → GEEN PHI opgeslagen hier
                                    ↓
                           AWS API Gateway (met WAF)
                                    ↓
                           Lambda-functie (valideert, versleutelt)
                                    ↓
                           Payload CMS API (op ECS Fargate)
                                    ↓
                           RDS PostgreSQL (versleuteld in rust)

De Next.js API-route fungeert als een dunne proxy. Het valideert de requeststructuur (CSRF-token, rate limiting, basis veldvalidatie), maar logt of slaat geen PHI op. De werkelijke gegevensverwerking gebeurt volledig binnen AWS's HIPAA-geschikt services.

Encryptiedetails

We implementeerden field-level encryptie voor de meest gevoelige gegevens. Patiënt-SSN-fragmenten (laatste 4), verzekerings-ID's, en beschrijvingen van medische klachten worden versleuteld op het applicatieniveau met AES-256-GCM voordat ze zelfs maar de database raken. Dit betekent dat zelfs als iemand databasetoegang kreeg, zij versleutelde blobs voor gevoelige velden zouden zien.

// Vereenvoudigde versie van onze field-level encryptiehook in Payload
import { encrypt } from '../lib/crypto';

const PatientIntake: CollectionConfig = {
  slug: 'patient-intake',
  hooks: {
    beforeChange: [
      async ({ data }) => {
        if (data.ssnLastFour) {
          data.ssnLastFour = await encrypt(data.ssnLastFour);
        }
        if (data.medicalComplaint) {
          data.medicalComplaint = await encrypt(data.medicalComplaint);
        }
        return data;
      },
    ],
  },
  access: {
    read: ({ req: { user } }) => {
      return user?.role === 'office-admin' || user?.role === 'provider';
    },
    create: () => true, // Openbare formulierinzending
    update: ({ req: { user } }) => user?.role === 'office-admin',
    delete: () => false, // Retentiebeleid - geen verwijderingen via CMS
  },
  fields: [
    // ... veldefinities
  ],
};

Audit-logging

Elke toegang tot patientinname-gegevens wordt gelogd—wie het bekeken, wanneer, en van welk IP. We bouwden een aangepaste Payload-plugin die naar een aparte audit-logtabel schrijft. Deze tabel is append-only; zelfs admin-gebruikers kunnen entries niet wijzigen of verwijderen. Tijdens de jaarlijkse HIPAA-risicobeoordeling van de praktijk werd dit audittrail specifiek genoemd als een sterkte.

Healthcare Practice: WordPress naar Next.js + Payload CMS Migration - architectuur

Het patientinname-herontwerp

Het oude proces: Patiënt downloadt een 6-pagina PDF, drukt deze af, vult deze in met een pen (half de tijd onleesbaar), brengt het naar het kantoor, en een medewerkster voert het handmatig in hun EHR-systeem in. Gemiddelde tijd van download naar EHR-invoer: 3-5 werkdagen.

Het nieuwe proces: Patiënt ontvangt een SMS of e-maillink 48 uur voor hun afspraak, voltooit het multistap-formulier op hun telefoon in ongeveer 8 minuten, en de gegevens zijn beschikbaar in het systeem van de praktijk voordat zij door de deur komen.

Formulier UX-besluiten

We verdeelden het inname-formulier in 7 stappen:

  1. Identiteitsverificatie (naam, geboortedatum, contactgegevens)
  2. Verzekeringsinformatie (maatschappij, ID, groepsnummer, fotoupload van kaart)
  3. Medische geschiedenis (aandoeningen-checklist, operatieve geschiedenis)
  4. Huidige medicijnen (met automatisch aanvullen uit een formularium-database van openbare bronnen)
  5. Reden voor bezoek (vrijwillige tekst + lichaamsdiagram voor pijnlocatie)
  6. Toestemming en overeenkomsten (elektronische handtekening)
  7. Beoordeling en inzending

Een paar UX-details die echt uitmaakten:

  • Voortgangsindicator met "Stap 3 van 7" reduceerde het stopzetten met ongeveer 40% vergeleken met onze initiële prototype dat alle velden tegelijk toonde. We A/B-testen dit tijdens een zachte lancering.
  • Verzekeringkaart-fotoupload met automatische uitsnijding en een voorbeeld. Patiënten fotograferen voor- en achterkant van hun kaart. Dit alleen elimineerde ongeveer 60% van de kantoortafel-gegevensinvoer.
  • Medicijn-automatisch aanvullen met behulp van de RxNorm API. In plaats van dat patiënten proberen "hydroxychloroquine" te spellen, typen zij "hydro" en selecteren uit een gefilterde lijst. Dit reduceerde medicijninvoerfouten aanzienlijk.
  • Sessie-persistentie — als een patiënt het formulier start en wordt onderbroken, wordt hun voortgang opgeslagen (versleuteld in sessionStorage, nooit localStorage) voor 30 minuten. Zij kunnen hervatten waar zij zijn gebleven.
// Medicijn-automatisch aanvullen met RxNorm API
const useMedicationSearch = (query: string) => {
  return useQuery({
    queryKey: ['medications', query],
    queryFn: async () => {
      if (query.length < 3) return [];
      const res = await fetch(
        `/api/medications/search?q=${encodeURIComponent(query)}`
      );
      return res.json();
    },
    staleTime: 1000 * 60 * 5, // Cache voor 5 minuten
    enabled: query.length >= 3,
  });
};

De server-side medicijnzoekpunt bevraagt RxNorm via onze AWS backend, houdt de externe API-oproep weg van de client en stelt ons in staat resultaten in cache op te slaan.

Prestatieresultaten en Lighthouse scores

Hier is de voor en na:

Metriek WordPress (Daarvoor) Next.js + Payload (Daarna) Verbetering
Lighthouse Mobiel 38 94 +147%
Lighthouse Desktop 61 99 +62%
First Contentful Paint (Mobiel) 4,2s 0,8s -81%
Largest Contentful Paint (Mobiel) 8,1s 1,4s -83%
Total Blocking Time 1.840ms 45ms -98%
Cumulative Layout Shift 0,34 0,01 -97%
Time to Interactive 9,3s 1,2s -87%
Paginagewicht (Homepage) 4,8MB 340KB -93%
Core Web Vitals Pass Nee Ja (alles groen) —

De mobiele Lighthouse-score van 94 (niet 100, en ik zal uitleggen waarom in een moment) werd gemeten op de patientinname-pagina, wat de meest JavaScript-zware pagina op de site is. Contentpagina's zoals de homepage en servicepagina's scoren consistent 98-100 op zowel mobiel als desktop.

Waarom niet een perfect 100 op mobiel? Twee redenen:

  1. De medicijn-automatisch invullen widget vereist client-side JavaScript die ongeveer 12KB gzipped aan de inname-formulierpagina toevoegt.
  2. We gebruiken reCAPTCHA v3 op het inname-formulier als een bot-preventielaag, en Google's reCAPTCHA-script is niet bepaald licht. We lazy-loaden dit, maar het kost ons nog steeds een paar punten.

We hebben overwogen reCAPTCHA te verwijderen om 100 te bereiken, maar het voordeel van veiligheid weegt op tegen de vanity-metriek. Een healthcare inname-formulier zonder botbescherming vraagt om spamverzendingen gemengd met echte patiëntgegevens.

Migratiestrategie: Nul downtime, nul verloren rankings

De migratie van een healthcare practice-website is stressvol omdat downtime letterlijk betekent gemiste patiëntafspraken. Hier is hoe we het aanpakten:

Content-migratie

We schreven een migratiescript dat inhoud uit de WordPress REST API haalde en transformeerde naar Payload CMS-documenten. Het script verwerkte:

  • 47 servicepagina's
  • 12 arts-/zorgverlener-profielen
  • 89 blogposts (met afbeelding die opnieuw worden gehost)
  • 6 locatiepagina's
  • Alle SEO-metagegevens (titels, beschrijvingen, canonieke URL's)

URL-mapping

Elke WordPress URL werd in kaart gebracht naar zijn Next.js-equivalent. We handhaafden dezelfde URL-structuur waar mogelijk en richtten 301-omleidingen in next.config.js in voor de handvol URL's die veranderden:

// next.config.js
const redirects = async () => [
  {
    source: '/services/:slug',
    destination: '/orthopedic-services/:slug',
    permanent: true,
  },
  {
    source: '/team/:slug',
    destination: '/providers/:slug',
    permanent: true,
  },
  // ... 23 meer omleidingen
];

DNS-cutover

We gebruikten een blue-green deployment-strategie. De nieuwe site liep twee weken parallel terwijl we testten. Op cutover-dag hebben we DNS-records bijgewerkt tijdens een zondagavond-onderhoudsvak. Totale zichtbare downtime: ongeveer 3 minuten (DNS-propagatie was snel omdat we TTL's een week vooraf hadden verlaagd naar 60 seconden).

SEO-resultaten

Drie maanden na lancering:

  • Organisch verkeer nam toe met 34%
  • Gemiddelde positie voor "orthopedisch arts in mijn buurt" verbeterde van positie 14 naar positie 5
  • Click-through rate van Google nam toe met 28% (betere Core Web Vitals = betere mobiele SERP-ervaring)
  • Nul 404-fouten in Search Console voor eerder geïndexeerde URL's

Technische architectuur diepgaande analyse

Voor degenen die het volledige plaatje willen:

┌─────────────────────────────────────────────┐
│                  Vercel                       │
│  ┌─────────────────────────────────────────┐ │
│  │  Next.js 15 App Router                  │ │
│  │  - Statische pagina's (ISR, 60s revalidatie) │ │
│  │  - Server Components                    │ │
│  │  - API-routes (alleen proxy, geen PHI)  │ │
│  └─────────────────────────────────────────┘ │
└──────────────────┬──────────────────────────┘
                   │ HTTPS
┌──────────────────▼──────────────────────────┐
│              AWS (HIPAA BAA)                 │
│  ┌──────────────┐  ┌─────────────────────┐  │
│  │  API Gateway  │  │  CloudFront (activa)│  │
│  │  + WAF        │  └─────────────────────┘  │
│  └──────┬───────┘                            │
│         │                                    │
│  ┌──────▼───────┐  ┌─────────────────────┐  │
│  │  ECS Fargate  │──│  RDS PostgreSQL     │  │
│  │  (Payload 3)  │  │  (versleuteld)      │  │
│  └──────┬───────┘  └─────────────────────┘  │
│         │                                    │
│  ┌──────▼───────┐  ┌─────────────────────┐  │
│  │  S3 (uploads) │  │  CloudWatch (logs)  │  │
│  │  (versleuteld)│  │  (audittrail)       │  │
│  └──────────────┘  └─────────────────────┘  │
└─────────────────────────────────────────────┘

Maandelijkse infrastructuurkosten: ongeveer $180-220/maand op AWS (ECS Fargate is verrassend betaalbaar op deze schaal) plus $20/maand voor Vercel Pro. Vergelijk dat met de $29/maand gedeelde hosting waar zij voorheen op waren—ja, het is duurder, maar zij krijgen HIPAA-geschikt infrastructuur, automatische schaling, en echte veiligheid.

Geleerde lessen

1. Begin vroeg HIPAA-gesprekken. We besteedden drie weken aan architectuurplanning voordat we een enkele regel code schreven. Dit bespaard ons van minstens twee mogelijke herontwerpen.

2. Payload CMS v3 was het wachten waard. We startten dit project toen Payload 3.0 in bèta was. Er waren ruwe randen—migratie-docs waren onvolledig, en sommige plugins waren nog niet bijgewerkt. Maar native Postgres-ondersteuning en het verbeterde adminpaneel maakten het de juiste keuze.

3. Over-engineer niet het inname-formulier. Ons eerste prototype had voorwaardelijke logica zes niveaus diep. De kantoorbeheerder keek ernaar en zei: "Kunnen we niet gewoon de vragen op volgorde stellen?" Zij had gelijk. We vereenvoudigden, en voltooiingspercentages gingen omhoog.

4. Healthcare-cliënten hebben begeleiding nodig bij CMS-training. We boden drie trainingssessies in plaats van onze gebruikelijke één, plus opgenomen Loom-video's voor veelgestelde taken. De investering in training betaalde zichzelf terug in de eerste maand toen de kantoorbeheerder een nieuwe zorgvereldenarpagina kon toevoegen zonder een supportticket in te dienen.

5. Prestatiebudgetten zijn niet onderhandelbaar. We stelden aan het begin van het project een prestatiebudget van <400KB paginagewicht en <100ms Total Blocking Time in. Elke PR werd in CI tegen dit budget gecontroleerd. De ene keer dat we probeerden een geanimeerde illustratiebibliotheek toe te voegen, overtrof het het budget, en we vingen het op voordat het werd verzonden.

Als u een vergelijkbare migratie voor een healthcare- of gereglementeerde-industrie-site overweegt, helpen we graag met de specifieke details. U kunt rechtstreeks contact met ons opnemen of onze prijzenpagina raadplegen voor projectbereiken.

Veelgestelde vragen

Maakt het gebruik van Next.js en Payload CMS een site automatisch HIPAA-compliant? Nee. Geen technologie-stack is inherent HIPAA-compliant. HIPAA-compliance vereist administratieve waarborgen (beleid, training, risicobeoordeling), fysieke waarborgen (faciliteittoegangscontroles), en technische waarborgen (encryptie, toegangscontroles, audit-logs). Wat Next.js en Payload CMS u geven, is een flexibele architectuur waar u de technische waarborgen goed kunt implementeren—vooral de self-hosted aard van Payload, waarmee u kunt controleren waar PHI zich bevindt.

Waarom niet gewoon een HIPAA-compliant formulierservice gebruiken zoals Jotform of FormStack? U kunt absoluut, en voor eenvoudiger gebruikssituaties is dat een redelijke keuze. We evalueerden Jotform's HIPAA-plan ($99/maand) en FormStack ($83/maand). Het probleem voor deze cliënt was integratiesdiepte—zij wilden dat de intakegegevens in een aangepaste workflow stroomden die verzekeringskwalificatie in real-time controleerde en hun EHR-systeem vooraf invulde. Kant-en-klaar formuliertools konden dit niet aanpakken zonder aanzienlijke middleware, op welk moment u toch aangepaste infrastructuur bouwde.

Wat waren de totale projectkosten en tijdlijn? Het project kwam uit op ongeveer $42.000 over 14 weken. Dit omvatte ontdekking en architectuurplanning (3 weken), ontwerp (2 weken), ontwikkeling (7 weken), en testen/migratie (2 weken). Doorlopend hosting en onderhoud kost ongeveer $250/maand inclusief infrastructuurkosten en een kleine ondersteuningsvergoeding.

Kan Payload CMS meerdere locaties voor een healthcare-groep verwerken? Ja. We bouwden een "Locaties"-verzameling in Payload met velden voor adres, uren, zorgverleners, geaccepteerde verzekeringen, en locatiespecifieke inhoud. Elke locatie krijgt zijn eigen pagina gegenereerd door Next.js met structured data markup (LocalBusiness-schema) voor lokale SEO. Het toevoegen van een nieuwe locatie is zo eenvoudig als het creëren van een nieuw item in Payload's adminpaneel.

Hoe verwerkt u retentie- en verwijderingsvereisten voor patiëntgegevens? We implementeerden geautomatiseerd beleid voor gegevenscycli. Intakformulierinzendingen worden behouden gedurende 7 jaar (aansluitend op de voorschrift voor het bewaren van medische documenten van de praktijk), waarna zij automatisch naar S3 Glacier worden gearchiveerd en uiteindelijk worden verwijderd. Patiënten kunnen ook verzoeken om gegevenstoegang of -verwijdering onder staatsprivacywetten—we bouwden een adminworkflow in Payload waar personeel deze verzoeken kan verwerken met een volledig audittrail.

Wat gebeurt er als de Payload CMS-server uitvalt? De Next.js frontend dient statisch gegenereerde pagina's vanuit Vercel's CDN, dus de hoofdwebsite blijft actief, zelfs als de Payload-backend volledig offline is. Het formulier voor patiëntinname zou niet beschikbaar zijn tijdens een backend-onderbreking, maar we hebben ECS geconfigureerd met auto-herstart-beleid, gezondheidscontroles elke 30 seconden, en CloudWatch-alarmen die zowel ons team als de IT-contactpersoon van de praktijk waarschuwen. In 6 maanden productie hebben we nul ongeplande downtime gehad.

Is deze architectuur overkill voor een kleine praktijk met één locatie? Het hangt ervan af wat u met patiëntgegevens doet. Als u alleen een brochuresit met een telefoonnummer en adres nodig hebt, is WordPress met een goed thema prima—u hebt niets van dit alles nodig. Maar op het moment dat u PHI door uw website verzamelt (intakeformulieren, medische vragenlijsten, afspraakaanvragen met medische details), hebt u infrastructuur nodig die juiste veiligheidscontroles ondersteunt. De architectuur die we bouwden schaalt goed omlaag—een praktijk met één locatie zou minder op infrastructuur kosten vanwege lager verkeer.

Hoe beïnvloedde de migratie Google-rankings? We zagen een korte (ongeveer 10-dagen) rangschikkingsfluctuatie onmiddellijk na migratie, wat normaal is. Bij week drie waren de rangschikkingen gestabiliseerd en trending omhoog. Bij maand drie was organisch verkeer met 34% gestegen en waren de primaire trefwoorden van de praktijk gemiddeld met 4 posities verbeterd. De Core Web Vitals-verbetering was de grootste factor—Google had hun oude site's slechte mobiele prestaties in zoekresultaten gestraft.