Une pratique orthopédique de taille moyenne dans le sud-est nous a contactés avec un problème qui est douloureusement courant dans le secteur de la santé : leur site WordPress était lent, leur processus d'admission des patients était un cauchemar de téléchargements PDF et de renvois par fax, et leur officier de conformité IT perdait le sommeil à cause de l'exposition HIPAA. Six mois plus tard, ils avaient un frontend Next.js, un backend Payload CMS, des formulaires d'admission des patients sécurisés selon HIPAA, et des scores Lighthouse qui faisaient ressembler les sites de leurs concurrents à des reliques fonctionnant sur une connexion d'accès commuté. Voici exactement comment nous l'avons fait.

Table of Contents

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

Le point de départ : avec quoi nous travaillions

La pratique — appelons-la Southeastern Ortho (NDA, vous savez comment ça marche) — utilisait WordPress depuis 2017. Leur configuration était typique pour une pratique médicale qui avait grandi de façon organique sans beaucoup de supervision technique :

  • WordPress 6.2 avec 34 plugins (11 d'entre eux n'avaient pas été mis à jour depuis plus d'un an)
  • Hébergement partagé sur un plan qui coûtait 29 $/mois
  • Contact Form 7 gérant les demandes des patients — aucun chiffrement, aucun BAA avec le fournisseur d'hébergement
  • Formulaires d'admission en PDF que les patients devaient télécharger, imprimer, remplir à la main, et soit envoyer par fax, soit apporter aux rendez-vous
  • Temps de chargement des pages moyens de 6,8 secondes sur mobile
  • Score Lighthouse mobile : 38

Ce score Lighthouse n'est pas une erreur de frappe. Trente-huit. Le site avait des images héros non optimisées (une était un PNG de 4,2 MB), du CSS bloquant le rendu provenant de cinq plugins différents, et jQuery chargé trois fois à cause de conflits entre plugins.

Mais le vrai problème n'était pas la performance. C'était le risque.

Leurs formulaires de contact collectaient des noms de patients, des numéros de téléphone, et parfois des descriptions de plaintes médicales. Ces données transitaient par un plugin de formulaire non chiffré, stockées dans une base de données WordPress sur un hébergement partagé, et sauvegardées par un service sans Accord d'associé commercial (BAA). Leur officier de conformité avait soulevé ce problème, et leur assureur responsabilité civile posait des questions précises.

Le brief

La pratique avait besoin de :

  1. Un site web rapide et moderne qui reflète la qualité de leurs soins
  2. Des formulaires d'admission des patients sécurisés selon HIPAA qui remplacent le processus papier
  3. Un CMS que leur gestionnaire de bureau puisse mettre à jour sans appeler un développeur
  4. Une meilleure performance SEO (ils perdaient des classements de recherche locale face à des pratiques plus récentes)
  5. Tout cela sans se ruiner — ce sont des médecins, pas une startup technologique

Pourquoi Next.js et Payload CMS

Nous avons évalué plusieurs options d'architecture. Voici la comparaison honnête que nous avons présentée au client :

Option Avantages Inconvénients Coût estimé
Reconstruction WordPress (nouveau thème + plugins) Familier au personnel, coûts initiaux inférieurs Mêmes risques HIPAA, plafond de performance, dépendance aux plugins 15-25 K$
Webflow + formulaires tiers Rapide à construire, bonne performance Options de conformité HIPAA limitées, coûts par siège continus, verrouillage du fournisseur 20-30 K$
Next.js + Payload CMS Contrôle total, architecture sécurisée pour HIPAA, meilleure performance Investissement initial plus élevé, gestion de l'hébergement requise 35-50 K$
Next.js + Sanity Excellente expérience d'édition, bon écosystème La tarification de Sanity augmente avec l'utilisation, préoccupations concernant la gestion des PHI avec un CMS hébergé en cloud 30-45 K$

Nous avons recommandé Next.js avec Payload CMS, voici pourquoi.

Next.js était le bon frontend

Next.js 14 (ce projet a commencé fin 2024, et nous fonctionnons maintenant sur la version 15) nous a donné exactement ce dont un site de santé a besoin :

  • Génération statique pour les pages de contenu — biographies de médecins, descriptions de services, informations sur les emplacements. Ces pages changent rarement, donc nous les pré-rendons au moment de la construction. Zéro calcul serveur au moment de la requête signifie un TTFB rapide.
  • Composants serveur pour le contenu dynamique — la disponibilité des rendez-vous, les articles de blog, et la logique des formulaires d'admission bénéficient tous du rendu côté serveur sans envoyer du JavaScript inutile au client.
  • Optimisation des images prête à l'emploi — next/image avec conversion automatique en WebP/AVIF a remplacé ces PNG de 4 MB par des images correctement dimensionnées et chargées paresseusement.
  • Middleware pour les en-têtes de sécurité — nous utilisons le middleware Next.js pour définir des en-têtes CSP strictes, HSTS, et d'autres en-têtes de sécurité que les auditeurs HIPAA adorent voir.

Si vous êtes curieux de connaître notre approche, nous avons documenté nos capacités de développement Next.js plus en détail.

Payload CMS était le bon backend

Nous avons choisi Payload CMS 3.0 par rapport à d'autres options headless pour plusieurs raisons spécifiques au secteur de la santé :

Auto-hébergé de conception. Payload s'exécute sur votre propre infrastructure. C'est non négociable pour HIPAA. Lorsque vous gérez des Informations de santé protégées (PHI), vous devez savoir exactement où vivent vos données, qui a accès, et être en mesure de signer un BAA avec votre fournisseur d'infrastructure. Les plates-formes CMS hébergées en cloud comme Contentful ou Sanity stockent les données sur leurs serveurs — et bien que certaines offrent la conformité HIPAA aux niveaux entreprise, le coût est généralement 3 à 5 fois ce que vous paieriez pour auto-héberger Payload sur un fournisseur éligible à HIPAA.

Natif TypeScript. La configuration de Payload est juste du TypeScript. Cela signifie que nos modèles de contenu, réponses API, et types frontend partagent tous la même source de vérité. Lorsque le gestionnaire de bureau ajoute un nouveau champ pour « numéro de pré-autorisation d'assurance » au formulaire d'admission, votre frontend le sait immédiatement grâce aux types générés.

Contrôle d'accès intégré. Le contrôle d'accès au niveau des champs de Payload signifiait que nous pouvions créer des rôles où la personne marketing pouvait modifier les articles de blog et les pages de services, mais ne pouvait pas toucher aux données d'admission des patients. Le gestionnaire de bureau pouvait consulter les soumissions d'admission mais ne pouvait pas modifier la structure du formulaire. Cette granularité importe lorsque vous documentez les contrôles d'accès pour la conformité.

Texte enrichi fait correctement. Payload utilise Lexical (anciennement Slate) pour le texte enrichi, et l'expérience d'édition est vraiment bonne. Le gestionnaire de bureau de notre client, qui utilisait WordPress depuis des années, était à l'aise dans le panneau d'administration de Payload en une seule séance de formation de 45 minutes.

Nous travaillons régulièrement avec Payload et d'autres plates-formes CMS headless — vous pouvez en voir plus sur notre approche de développement CMS headless.

Considérations HIPAA dans une architecture headless

Permettez-moi d'être clair sur quelque chose : aucune pile technologique n'est « conforme à HIPAA » d'elle-même. La conformité HIPAA est une pratique organisationnelle, pas une fonctionnalité logicielle. Ce qu'une pile technologique peut être, c'est « sûre pour HIPAA » — ce qui signifie qu'elle n'introduit pas de risque inutile et qu'elle soutient les mesures de sauvegarde administratives, physiques et techniques qu'HIPAA exige.

Voici ce que nous avons mis en œuvre :

Infrastructure

  • Hébergement : AWS avec un BAA signé. Nous avons utilisé ECS Fargate pour le conteneur Payload CMS et déployé le frontend Next.js sur Vercel (qui ne gère pas les PHI — distinction importante).
  • Base de données : Amazon RDS PostgreSQL avec chiffrement au repos (AES-256) et chiffrement en transit (TLS 1.2+). Payload 3.0 supporte Postgres nativement, ce qui était une grande raison pour laquelle nous avions attendu la v3.
  • Stockage de fichiers : S3 avec chiffrement côté serveur, politiques de bucket limitant l'accès, et versioning activé pour les pistes d'audit.

Flux de données pour l'admission des patients

C'est là que l'architecture devient intéressante. Le formulaire d'admission des patients vit sur le frontend Next.js, mais nous n'envoyons jamais de PHI à travers l'infrastructure de Vercel.

Patient Browser → HTTPS → API Route (Next.js on Vercel) → NO PHI stored here
                                    ↓
                           AWS API Gateway (with WAF)
                                    ↓
                           Lambda function (validates, encrypts)
                                    ↓
                           Payload CMS API (on ECS Fargate)
                                    ↓
                           RDS PostgreSQL (encrypted at rest)

La route API Next.js agit comme un proxy fin. Elle valide la structure de la requête (jeton CSRF, limitation de débit, validation de champ basique) mais ne journalise ni ne stocke de PHI. Le traitement réel des données se fait entièrement dans les services éligibles à HIPAA d'AWS.

Détails du chiffrement

Nous avons implémenté le chiffrement au niveau des champs pour les données les plus sensibles. Les fragments de numéro de sécurité sociale des patients (4 derniers chiffres), les identifiants d'assurance, et les descriptions de plaintes médicales sont chiffrés au niveau de l'application en utilisant AES-256-GCM avant même d'accéder à la base de données. Cela signifie que même si quelqu'un accédait à la base de données, il verrait des blobs chiffrés pour les champs sensibles.

// Version simplifiée de notre hook de chiffrement au niveau des champs dans 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, // Public form submission
    update: ({ req: { user } }) => user?.role === 'office-admin',
    delete: () => false, // Retention policy - no deletions through CMS
  },
  fields: [
    // ... field definitions
  ],
};

Journalisation d'audit

Chaque accès aux données d'admission des patients est enregistré — qui les a consultées, quand, et à partir de quelle adresse IP. Nous avons créé un plugin Payload personnalisé qui écrit dans une table de journal d'audit séparée. Cette table est ajout-uniquement ; même les utilisateurs admin ne peuvent pas modifier ou supprimer les entrées. Lors de l'évaluation annuelle des risques HIPAA de la pratique, cette piste d'audit a été spécifiquement citée comme un point fort.

Healthcare Practice: WordPress to Next.js + Payload CMS Migration - architecture

La refonte de l'admission des patients

L'ancien processus : le patient télécharge un PDF de 6 pages, l'imprime, le remplit à la main (la moitié du temps de façon illisible), l'apporte au bureau, et un membre du personnel le saisit manuellement dans leur système DSE. Temps moyen entre le téléchargement et l'entrée DSE : 3 à 5 jours ouvrables.

Le nouveau processus : le patient reçoit un SMS ou un lien par email 48 heures avant son rendez-vous, remplit le formulaire multi-étapes sur son téléphone en environ 8 minutes, et les données sont disponibles dans le système de la pratique avant qu'il ne franchisse la porte.

Décisions d'expérience utilisateur du formulaire

Nous avons divisé le formulaire d'admission en 7 étapes :

  1. Vérification d'identité (nom, date de naissance, coordonnées)
  2. Informations d'assurance (transporteur, numéro d'identification, numéro de groupe, photo de la carte)
  3. Antécédents médicaux (liste de contrôle des conditions, antécédents chirurgicaux)
  4. Médicaments actuels (avec autocomplétion à partir d'une base de données de formulaire ouverte)
  5. Raison de la visite (texte libre + diagramme corporel pour la localisation de la douleur)
  6. Consentement et accords (capture de signature électronique)
  7. Révision et soumission

Quelques détails d'expérience utilisateur qui ont fait une réelle différence :

  • Indicateur de progression affichant « Étape 3 sur 7 » a réduit l'abandon d'environ 40 % par rapport à notre prototype initial qui affichait tous les champs à la fois. Nous avons testé A/B pendant un lancement doux.
  • Téléchargement de photo de carte d'assurance avec recadrage automatique et aperçu. Les patients photographient le recto et le verso de leur carte. Cela seul a éliminé environ 60 % de la saisie de données à la réception.
  • Autocomplétion des médicaments utilisant l'API RxNorm. Au lieu que les patients essaient d'épeler « hydroxychloroquine », ils tapent « hydro » et sélectionnent dans une liste filtrée. Cela a considérablement réduit les erreurs de saisie de médicaments.
  • Persistance de session — si un patient commence le formulaire et est interrompu, sa progression est sauvegardée (chiffrée dans sessionStorage, jamais localStorage) pendant 30 minutes. Il peut reprendre où il s'était arrêté.
// Autocomplétion des médicaments utilisant l'API RxNorm
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 for 5 minutes
    enabled: query.length >= 3,
  });
};

Le point de terminaison de recherche de médicaments côté serveur interroge RxNorm via notre backend AWS, gardant l'appel API externe loin du client et nous permettant de mettre en cache les résultats.

Résultats de performance et scores Lighthouse

Voici le comparatif avant et après :

Métrique WordPress (Avant) Next.js + Payload (Après) Amélioration
Lighthouse Mobile 38 94 +147%
Lighthouse Desktop 61 99 +62%
First Contentful Paint (Mobile) 4.2s 0.8s -81%
Largest Contentful Paint (Mobile) 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%
Page Weight (Homepage) 4.8MB 340KB -93%
Core Web Vitals Pass No Yes (all green) —

Le score Lighthouse mobile de 94 (pas 100, et je vais vous expliquer pourquoi dans un instant) a été mesuré sur la page d'admission des patients, qui est la page la plus lourde en JavaScript du site. Les pages de contenu comme la page d'accueil et les pages de services obtiennent régulièrement des scores de 98-100 sur mobile et desktop.

Pourquoi pas un parfait 100 sur mobile ? Deux raisons :

  1. Le widget d'autocomplétion des médicaments nécessite du JavaScript côté client qui ajoute environ 12 KB compressé à la page du formulaire d'admission.
  2. Nous utilisons reCAPTCHA v3 sur le formulaire d'admission comme couche de prévention des bots, et le script reCAPTCHA de Google n'est pas exactement léger. Nous le chargeons paresseusement, mais il nous coûte quand même quelques points.

Nous avons envisagé de supprimer reCAPTCHA pour atteindre 100, mais le bénéfice de sécurité l'emporte sur la métrique de vanité. Un formulaire d'admission aux soins de santé sans protection contre les bots demande aux soumissions de spam de se mélanger aux données réelles des patients.

Stratégie de migration : zéro temps d'arrêt, zéro classement perdu

Migrer un site web de pratique médicale est stressant car les temps d'arrêt signifient littéralement des rendez-vous de patients manqués. Voici comment nous l'avons géré :

Migration de contenu

Nous avons écrit un script de migration qui a extrait le contenu de l'API REST de WordPress et l'a transformé en documents Payload CMS. Le script a géré :

  • 47 pages de services
  • 12 profils de médecin/prestataire
  • 89 articles de blog (avec réhébergement d'images)
  • 6 pages d'emplacements
  • Toutes les métadonnées SEO (titres, descriptions, URL canoniques)

Mappage des URL

Chaque URL WordPress a été mappée à son équivalent Next.js. Nous avons maintenu la même structure d'URL où possible et configuré des redirections 301 dans next.config.js pour la poignée d'URL qui ont changé :

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

Basculement DNS

Nous avons utilisé une stratégie de déploiement bleu-vert. Le nouveau site s'exécutait en parallèle pendant deux semaines pendant que nous testions. Le jour du basculement, nous avons mis à jour les enregistrements DNS lors d'une fenêtre de maintenance dimanche soir. Temps d'arrêt visible total : environ 3 minutes (la propagation DNS était rapide parce que nous avions pré-abaissé les TTL à 60 secondes une semaine avant).

Résultats SEO

Trois mois post-lancement :

  • Le trafic organique a augmenté de 34 %
  • La position moyenne pour « orthopedic doctor near me » s'est améliorée de la position 14 à la position 5
  • Le taux de clics depuis Google a augmenté de 28 % (meilleur Core Web Vitals = meilleure expérience mobile SERP)
  • Zéro erreur 404 dans Search Console pour les URL précédemment indexées

Plongée profonde dans l'architecture technique

Pour ceux qui veulent l'image complète :

┌─────────────────────────────────────────────┐
│                  Vercel                       │
│  ┌─────────────────────────────────────────┐ │
│  │  Next.js 15 App Router                  │ │
│  │  - Static pages (ISR, 60s revalidation) │ │
│  │  - Server Components                    │ │
│  │  - API routes (proxy only, no PHI)      │ │
│  └─────────────────────────────────────────┘ │
└──────────────────┬──────────────────────────┘
                   │ HTTPS
┌──────────────────▼──────────────────────────┐
│              AWS (HIPAA BAA)                 │
│  ┌──────────────┐  ┌─────────────────────┐  │
│  │  API Gateway  │  │  CloudFront (assets)│  │
│  │  + WAF        │  └─────────────────────┘  │
│  └──────┬───────┘                            │
│         │                                    │
│  ┌──────▼───────┐  ┌─────────────────────┐  │
│  │  ECS Fargate  │──│  RDS PostgreSQL     │  │
│  │  (Payload 3)  │  │  (encrypted)        │  │
│  └──────┬───────┘  └─────────────────────┘  │
│         │                                    │
│  ┌──────▼───────┐  ┌─────────────────────┐  │
│  │  S3 (uploads) │  │  CloudWatch (logs)  │  │
│  │  (encrypted)  │  │  (audit trail)      │  │
│  └──────────────┘  └─────────────────────┘  │
└─────────────────────────────────────────────┘

Coût d'infrastructure mensuel : environ 180-220 $/mois sur AWS (ECS Fargate est étonnamment abordable à cette échelle) plus 20 $/mois pour Vercel Pro. Comparez cela à l'hébergement partagé de 29 $/mois sur lequel ils étaient auparavant — oui, c'est plus cher, mais ils obtiennent une infrastructure éligible à HIPAA, une mise à l'échelle automatique, et une véritable sécurité.

Leçons apprises

1. Commencez les conversations HIPAA tôt. Nous avons passé trois semaines à la planification de l'architecture avant d'écrire une seule ligne de code. Cela nous a sauvés d'au moins deux redessins potentiels.

2. Payload CMS v3 valait l'attente. Nous avons commencé ce projet lorsque Payload 3.0 était en bêta. Il y avait des aspérités — la documentation de migration était incomplète, et certains plugins n'avaient pas été mis à jour. Mais le support Postgres natif et l'amélioration de l'interface d'administration en ont fait le bon choix.

3. Ne pas sur-concevoir le formulaire d'admission. Notre premier prototype avait une logique conditionnelle à six niveaux de profondeur. Le gestionnaire de bureau l'a regardé et a dit : « Ne pouvons-nous pas simplement poser les questions dans l'ordre ? » Il avait raison. Nous avons simplifié, et les taux d'achèvement ont augmenté.

4. Les clients de santé ont besoin d'accompagnement sur la formation du CMS. Nous avons fourni trois sessions de formation au lieu de notre habituelle, plus des vidéos Loom enregistrées pour les tâches courantes. L'investissement dans la formation s'est amorti en un mois lorsque le gestionnaire de bureau a pu ajouter une nouvelle page de prestataire sans déposer un ticket de support.

5. Les budgets de performance sont non négociables. Nous avons établi un budget de performance de <400 KB de poids de page et <100 ms de temps de blocage total au début du projet. Chaque PR a été vérifiée par rapport à ce budget dans CI. La seule fois où nous avons essayé d'ajouter une bibliothèque d'illustration animée, elle a dépassé le budget, et nous l'avons attrapée avant qu'elle ne soit déployée.

Si vous envisagez une migration similaire pour un site de santé ou d'industrie réglementée, nous serions heureux de discuter des spécificités. Vous pouvez nous contacter directement ou consulter notre page de tarification pour les plages de projets.

FAQ

L'utilisation de Next.js et Payload CMS rend-elle automatiquement un site conforme à HIPAA ?

Non. Aucune pile technologique n'est intrinsèquement conforme à HIPAA. La conformité HIPAA exige des mesures de sauvegarde administratives (politiques, formation, évaluations des risques), des mesures de sauvegarde physiques (contrôles d'accès aux installations), et des mesures de sauvegarde techniques (chiffrement, contrôles d'accès, journaux d'audit). Ce que Next.js et Payload CMS vous donnent, c'est une architecture flexible où vous pouvez implémenter correctement les mesures de sauvegarde techniques — en particulier la nature auto-hébergée de Payload, qui vous permet de contrôler où vivent les PHI.

Pourquoi ne pas simplement utiliser un service de formulaire conforme à HIPAA comme Jotform ou FormStack ?

Vous pouvez absolument le faire, et pour les cas d'utilisation plus simples, c'est un choix raisonnable. Nous avons évalué le plan HIPAA de Jotform (99 $/mois) et FormStack (83 $/mois). Le problème pour ce client était la profondeur d'intégration — ils voulaient que les données d'admission circulent dans un flux de travail personnalisé qui vérifiait l'admissibilité de l'assurance en temps réel et pré-remplissait leur système DSE. Les outils de formulaire prêts à l'emploi ne pouvaient pas le gérer sans middleware important, auquel cas vous construisez une infrastructure personnalisée de toute façon.

Quel a été le coût total du projet et le calendrier ?

Le projet s'est élevé à environ 42 000 $ sur 14 semaines. Cela incluait la découverte et la planification de l'architecture (3 semaines), la conception (2 semaines), le développement (7 semaines), et les tests/migration (2 semaines). L'hébergement et la maintenance continus fonctionnent à environ 250 $/mois incluant les coûts d'infrastructure et une petite retenue de support.

Payload CMS peut-il gérer plusieurs emplacements pour un groupe de santé ?

Oui. Nous avons créé une collection « Emplacements » dans Payload avec des champs pour l'adresse, les horaires, les prestataires, l'assurance acceptée, et le contenu spécifique à l'emplacement. Chaque emplacement obtient sa propre page générée par Next.js avec un balisage de données structurées (schéma LocalBusiness) pour le SEO local. L'ajout d'un nouvel emplacement est aussi simple que de créer une nouvelle entrée dans le panneau d'administration de Payload.

Comment gérez-vous les exigences de rétention et de suppression des données des patients ?

Nous avons implémenté des politiques de cycle de vie de données automatisées. Les soumissions de formulaires d'admission sont conservées pendant 7 ans (correspondant à l'exigence de rétention des dossiers médicaux de l'État de la pratique), après quoi elles sont automatiquement archivées sur S3 Glacier et finalement supprimées. Les patients peuvent également demander l'accès aux données ou la suppression conformément aux lois de confidentialité des États — nous avons créé un flux de travail administrateur dans Payload où le personnel peut traiter ces demandes avec une piste d'audit complète.

Que se passe-t-il si le serveur Payload CMS tombe en panne ?

Le frontend Next.js sert des pages statiquement générées à partir du CDN de Vercel, donc le site web principal reste actif même si le backend Payload est complètement hors ligne. Le formulaire d'admission des patients ne serait pas disponible pendant une panne du backend, mais nous avons configuré ECS avec des politiques de redémarrage automatique, des vérifications de santé toutes les 30 secondes, et des alarmes CloudWatch qui alertent à la fois notre équipe et le contact informatique de la pratique. En 6 mois de production, nous avons eu zéro temps d'arrêt non planifié.

Cette architecture est-elle exagérée pour une petite pratique avec un seul emplacement ?

Cela dépend de ce que vous faites avec les données des patients. Si vous avez juste besoin d'un site d'information avec un numéro de téléphone et une adresse, WordPress avec un bon thème va bien — vous n'avez besoin d'aucun de ceci. Mais au moment où vous collectez des PHI via votre site web (formulaires d'admission, questionnaires médicaux, demandes de rendez-vous avec des détails médicaux), vous avez besoin d'une infrastructure qui supporte les contrôles de sécurité appropriés. L'architecture que nous avons construite se met à l'échelle vers le bas bien — une pratique à emplacement unique coûterait moins cher sur l'infrastructure en raison du trafic inférieur.

Comment la migration a-t-elle affecté les classements Google ?

Nous avons vu une brève fluctuation de classement (environ 10 jours) immédiatement après la migration, ce qui est normal. À la semaine trois, les classements s'étaient stabilisés et tendaient à la hausse. À trois mois, le trafic organique était en hausse de 34 % et les mots-clés primaires de la pratique s'étaient améliorés en moyenne de 4 positions. L'amélioration du Core Web Vitals était le facteur le plus important — Google pénalisait le site ancien pour sa mauvaise performance mobile dans les résultats de recherche.