Tu paciente hace clic en 'Formularios de Nuevo Paciente' en tu sitio de WordPress. Pasan seis segundos. El PDF finalmente se carga. Lo imprimen, lo rellenan a mano, luego lo envían por fax porque tu sistema de admisión se construyó en 2014. Mientras tanto, tu oficial de cumplimiento de TI acaba de descubrir datos de pacientes fluyendo a través de tres complementos sin protección, y tu puntuación móvil de Lighthouse es 34. Una práctica de ortopedia de tamaño mediano en el Sureste enfrentó exactamente este escenario. Seis meses después: frontend de Next.js, backend de Payload CMS, formularios de admisión seguros para HIPAA, y puntuaciones de Lighthouse de 94/99. Pero la verdadera victoria no fue la velocidad, sino los cuatro puntos de exposición HIPAA que cerramos antes de su auditoría.

Tabla de Contenidos

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

El Punto de Partida: Con Qué Estábamos Trabajando

La práctica—llamémosla Southeastern Ortho (NDA, ya sabes cómo funcionan estas cosas)—había estado ejecutando WordPress desde 2017. Su configuración era típica para una práctica de atención médica que había crecido orgánicamente sin mucha supervisión técnica:

  • WordPress 6.2 con 34 complementos (11 de los cuales no habían sido actualizados hace más de un año)
  • Hosting compartido en un plan que costaba $29/mes
  • Contact Form 7 manejando consultas de pacientes, sin encriptación, sin BAA con el proveedor de hosting
  • Formularios en PDF de admisión que los pacientes tenían que descargar, imprimir, rellenar a mano y enviar por fax o traer a las citas
  • Tiempos de carga de página promediando 6.8 segundos en móvil
  • Puntuación de Lighthouse móvil: 38

Esa puntuación de Lighthouse no es un error tipográfico. Treinta y ocho. El sitio tenía imágenes hero sin optimizar (una era un PNG de 4.2MB), CSS que bloqueaba el renderizado de cinco complementos diferentes, y jQuery cargaba tres veces por conflictos de complementos.

Pero el problema real no era el rendimiento. Era el riesgo.

Sus formularios de contacto recopilaban nombres de pacientes, números de teléfono y a veces descripciones de quejas médicas. Esos datos fluían a través de un complemento de formulario sin encriptar, se almacenaban en una base de datos de WordPress en hosting compartido, y se respaldaban en un servicio sin Acuerdo de Asociado de Negocio (BAA). Su oficial de cumplimiento había marcado esto, y su aseguradora de negligencia estaba haciendo preguntas directas.

El Requisito

La práctica necesitaba:

  1. Un sitio web rápido y moderno que reflejara la calidad de su atención
  2. Formularios de admisión de pacientes seguros para HIPAA que reemplazaran el proceso en papel
  3. Un CMS que su gerente de oficina pudiera actualizar sin llamar a un desarrollador
  4. Un mejor rendimiento de SEO (estaban perdiendo clasificaciones de búsqueda local frente a prácticas más nuevas)
  5. Todo esto sin quebrar el banco, son una práctica médica, no una startup de tecnología

Por Qué Next.js y Payload CMS

Evaluamos varias opciones de arquitectura. Aquí está la comparación honesta que presentamos al cliente:

Opción Ventajas Desventajas Costo Est.
Reconstrucción de WordPress (tema nuevo + complementos) Familiar para el personal, costo inicial más bajo Mismos riesgos HIPAA, techo de rendimiento, dependencia de complementos $15-25K
Webflow + formularios de terceros Rápido de construir, buen rendimiento Opciones limitadas de cumplimiento HIPAA, costos continuos por asiento, vendor lock-in $20-30K
Next.js + Payload CMS Control total, arquitectura segura para HIPAA, mejor rendimiento Inversión inicial más alta, requiere gestión de hosting $35-50K
Next.js + Sanity Excelente experiencia de edición, buen ecosistema El precio de Sanity escala con el uso, preocupaciones de manejo de PHI con CMS alojado en la nube $30-45K

Recomendamos Next.js con Payload CMS, y aquí está el por qué.

Next.js Fue el Frontend Correcto

Next.js 14 (este proyecto comenzó a finales de 2024, y desde entonces hemos estado ejecutando la versión 15) nos dio exactamente lo que un sitio de atención médica necesita:

  • Generación estática para páginas de contenido — biografías de médicos, descripciones de servicios, información de ubicación. Estas páginas rara vez cambian, así que las pre-renderizamos en tiempo de compilación. Cero computación de servidor en tiempo de solicitud significa TTFB rápido.
  • Componentes de servidor para contenido dinámico — disponibilidad de citas, publicaciones de blog y la lógica del formulario de admisión se benefician del renderizado del lado del servidor sin enviar JavaScript innecesario al cliente.
  • Optimización de imágenes lista para usar — next/image con conversión automática WebP/AVIF reemplazó esos PNGs de 4MB con imágenes de tamaño adecuado y carga perezosa.
  • Middleware para encabezados de seguridad — usamos middleware de Next.js para establecer encabezados CSP estrictos, HSTS y otros encabezados de seguridad que los auditores de HIPAA aman ver.

Si te interesa nuestro enfoque, hemos documentado nuestras capacidades de desarrollo de Next.js en más detalle.

Payload CMS Fue el Backend Correcto

Elegimos Payload CMS 3.0 sobre otras opciones headless por varias razones específicas de la atención médica:

Auto-hospedado por diseño. Payload se ejecuta en tu propia infraestructura. Esto es innegociable para HIPAA. Cuando estás manejando Información de Salud Protegida (PHI), necesitas saber exactamente dónde viven tus datos, quién tiene acceso, y poder firmar un BAA con tu proveedor de infraestructura. Las plataformas CMS alojadas en la nube como Contentful o Sanity almacenan datos en sus servidores, y aunque algunas ofrecen cumplimiento HIPAA en niveles empresariales, el costo es típicamente 3-5x lo que pagarías por auto-hospedarse Payload en un proveedor elegible para HIPAA.

Nativo de TypeScript. La configuración de Payload es solo TypeScript. Esto significa que nuestros modelos de contenido, respuestas de API y tipos de frontend comparten la misma fuente de verdad. Cuando el gerente de oficina agrega un nuevo campo para "número de pre-autorización de seguros" al formulario de admisión, tu frontend lo sabe inmediatamente a través de tipos generados.

Control de acceso integrado. El control de acceso a nivel de campo de Payload significaba que podíamos crear roles donde la persona de marketing podía editar publicaciones de blog y páginas de servicio, pero no podía tocar datos de admisión de pacientes. El gerente de oficina podía ver envíos de admisión pero no podía modificar la estructura del formulario. Esta granularidad importa cuando documentes controles de acceso para cumplimiento.

Texto enriquecido hecho bien. Payload usa Lexical (anteriormente Slate) para texto enriquecido, y la experiencia de edición es genuinamente buena. El gerente de oficina de nuestro cliente, quien había estado usando WordPress durante años, estaba cómodo en el panel de administración de Payload dentro de una sola sesión de entrenamiento de 45 minutos.

Trabajamos regularmente con Payload y otras plataformas CMS headless. Puedes ver más sobre nuestro enfoque de desarrollo de CMS headless.

Consideraciones HIPAA en una Arquitectura Headless

Permíteme aclarar algo: ningún stack de tecnología es "compatible con HIPAA" por sí solo. El cumplimiento de HIPAA es una práctica organizacional, no una característica de software. Lo que un stack de tecnología puede ser es "seguro para HIPAA"—significando que no introduce riesgo innecesario y apoya los salvaguardas administrativos, físicos y técnicos que HIPAA requiere.

Aquí está lo que implementamos:

Infraestructura

  • Hosting: AWS con un BAA firmado. Usamos ECS Fargate para el contenedor de Payload CMS e implementamos el frontend de Next.js en Vercel (que no maneja PHI, una distinción importante).
  • Base de datos: Amazon RDS PostgreSQL con encriptación en reposo (AES-256) y encriptación en tránsito (TLS 1.2+). Payload 3.0 soporta Postgres nativamente, que fue una gran razón por la que esperamos a la v3.
  • Almacenamiento de archivos: S3 con encriptación del lado del servidor, políticas de bucket que restringen el acceso, y versionado habilitado para pistas de auditoría.

Flujo de Datos para Admisión de Pacientes

Aquí es donde la arquitectura se pone interesante. El formulario de admisión de pacientes vive en el frontend de Next.js, pero nunca enviamos PHI a través de la infraestructura de Vercel.

Navegador del Paciente → HTTPS → API Route (Next.js en Vercel) → NINGÚN PHI almacenado aquí
                                    ↓
                           AWS API Gateway (con WAF)
                                    ↓
                           Función Lambda (valida, encripta)
                                    ↓
                           API de Payload CMS (en ECS Fargate)
                                    ↓
                           RDS PostgreSQL (encriptado en reposo)

La API route de Next.js actúa como un proxy delgado. Valida la estructura de solicitud (token CSRF, limitación de velocidad, validación básica de campos) pero no registra ni almacena ningún PHI. El procesamiento de datos real sucede enteramente dentro de los servicios elegibles para HIPAA de AWS.

Detalles de Encriptación

Implementamos encriptación a nivel de campo para los datos más sensibles. Fragmentos de SSN de pacientes (últimos 4 dígitos), IDs de seguros y descripciones de quejas médicas se encriptan en la capa de aplicación usando AES-256-GCM antes de que siquiera lleguen a la base de datos. Esto significa que incluso si alguien obtuviera acceso a la base de datos, vería blobs encriptados para campos sensibles.

// Versión simplificada de nuestro hook de encriptación a nivel de campo en 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, // Envío de formulario público
    update: ({ req: { user } }) => user?.role === 'office-admin',
    delete: () => false, // Política de retención - sin eliminaciones a través de CMS
  },
  fields: [
    // ... definiciones de campos
  ],
};

Registro de Auditoría

Cada acceso a datos de admisión de pacientes se registra: quién lo vio, cuándo y desde qué IP. Construimos un plugin personalizado de Payload que escribe en una tabla de registro de auditoría separada. Esta tabla es de solo anexión; ni siquiera los usuarios administradores pueden modificar o eliminar entradas. Durante la evaluación anual de riesgos HIPAA de la práctica, esta pista de auditoría fue específicamente señalada como una fortaleza.

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

El Rediseño de Admisión de Pacientes

El proceso anterior: El paciente descarga un PDF de 6 páginas, lo imprime, lo rellena con un bolígrafo (la mitad del tiempo de forma ilegible), lo trae a la oficina, y un miembro del personal lo ingresa manualmente en su sistema EHR. Tiempo promedio desde descarga hasta entrada en EHR: 3-5 días hábiles.

El nuevo proceso: El paciente recibe un mensaje de texto o enlace de correo electrónico 48 horas antes de su cita, completa el formulario de varios pasos en su teléfono en aproximadamente 8 minutos, y los datos están disponibles en el sistema de la práctica antes de que cruce la puerta.

Decisiones de UX del Formulario

Dividimos el formulario de admisión en 7 pasos:

  1. Verificación de identidad (nombre, fecha de nacimiento, información de contacto)
  2. Información de seguros (aseguradora, ID, número de grupo, carga de foto de la tarjeta)
  3. Historial médico (lista de verificación de condiciones, historial quirúrgico)
  4. Medicamentos actuales (con autocompletar de una base de datos de formularios abiertos)
  5. Razón de la visita (texto libre + diagrama corporal para ubicación del dolor)
  6. Consentimiento y acuerdos (captura de firma electrónica)
  7. Revisar y enviar

Algunos detalles de UX que hicieron una diferencia real:

  • Indicador de progreso que muestra "Paso 3 de 7" redujo el abandono aproximadamente 40% en comparación con nuestro prototipo inicial que mostraba todos los campos a la vez. Hicimos pruebas A/B durante un lanzamiento suave.
  • Carga de foto de tarjeta de seguro con recorte automático y vista previa. Los pacientes fotografían el frente y la parte posterior de su tarjeta. Solo esto eliminó aproximadamente 60% de la entrada de datos de recepción.
  • Autocompletar de medicamentos usando la API de RxNorm. En lugar de que los pacientes intenten deletrear "hydroxychloroquine", escriben "hydro" y seleccionan de una lista filtrada. Esto redujo significativamente los errores de entrada de medicamentos.
  • Persistencia de sesión — si un paciente comienza el formulario y se ve interrumpido, su progreso se guarda (encriptado en sessionStorage, nunca localStorage) durante 30 minutos. Pueden reanudar donde dejaron.
// Autocompletar de medicamentos usando API de 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 por 5 minutos
    enabled: query.length >= 3,
  });
};

El endpoint de búsqueda de medicamentos del lado del servidor consulta RxNorm a través de nuestro backend de AWS, manteniendo la llamada a la API externa lejos del cliente y permitiéndonos almacenar resultados en caché.

Resultados de Rendimiento y Puntuaciones de Lighthouse

Aquí está el antes y después:

Métrica WordPress (Antes) Next.js + Payload (Después) Mejora
Lighthouse Móvil 38 94 +147%
Lighthouse Escritorio 61 99 +62%
First Contentful Paint (Móvil) 4.2s 0.8s -81%
Largest Contentful Paint (Móvil) 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%
Peso de la Página (Homepage) 4.8MB 340KB -93%
Paso Core Web Vitals No Sí (todo verde) —

La puntuación de Lighthouse móvil de 94 (no 100, y explicaré por qué en un momento) se midió en la página de admisión de pacientes, que es la página más pesada en JavaScript en el sitio. Las páginas de contenido como la página de inicio y las páginas de servicios consistentemente puntuam 98-100 en móvil y escritorio.

¿Por qué no un perfecto 100 en móvil? Dos razones:

  1. El widget de autocompletar de medicamentos requiere JavaScript del lado del cliente que añade aproximadamente 12KB comprimidos a la página del formulario de admisión.
  2. Usamos reCAPTCHA v3 en el formulario de admisión como capa de prevención de bots, y el script de reCAPTCHA de Google no es exactamente ligero. Lo cargamos perezosamente, pero aún nos cuesta algunos puntos.

Consideramos eliminar reCAPTCHA para alcanzar 100, pero el beneficio de seguridad supera la métrica de vanidad. Un formulario de admisión de atención médica sin protección contra bots es pedir envíos de spam mezclados con datos de pacientes reales.

Estrategia de Migración: Cero Tiempo de Inactividad, Cero Clasificaciones Perdidas

Migrar un sitio web de práctica de atención médica es estresante porque el tiempo de inactividad literalmente significa citas de pacientes perdidas. Así es como lo manejamos:

Migración de Contenido

Escribimos un script de migración que extraía contenido de la API REST de WordPress y lo transformaba en documentos de Payload CMS. El script manejaba:

  • 47 páginas de servicios
  • 12 perfiles de médicos/proveedores
  • 89 publicaciones de blog (con re-hospedaje de imágenes)
  • 6 páginas de ubicación
  • Todos los metadatos de SEO (títulos, descripciones, URLs canónicas)

Mapeo de URL

Cada URL de WordPress se mapeó a su equivalente de Next.js. Mantuvimos la misma estructura de URL donde fue posible y configuramos redirecciones 301 en next.config.js para el puñado de URLs que cambiaron:

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

Cambio de DNS

Usamos una estrategia de implementación azul-verde. El nuevo sitio se ejecutó en paralelo durante dos semanas mientras lo probábamos. El día del cambio, actualizamos los registros de DNS durante una ventana de mantenimiento del domingo por la noche. Tiempo de inactividad visible total: aproximadamente 3 minutos (la propagación de DNS fue rápida porque habíamos pre-bajado los TTL a 60 segundos una semana antes).

Resultados de SEO

Tres meses después del lanzamiento:

  • El tráfico orgánico aumentó 34%
  • La posición promedio para "orthopedic doctor near me" mejoró de posición 14 a posición 5
  • La tasa de clics desde Google aumentó 28% (mejores Core Web Vitals = mejor experiencia móvil en SERP)
  • Cero errores 404 en Search Console para URLs previamente indexadas

Análisis Profundo de la Arquitectura Técnica

Para los que quieren la imagen completa:

┌─────────────────────────────────────────────┐
│                  Vercel                       │
│  ┌─────────────────────────────────────────┐ │
│  │  Next.js 15 App Router                  │ │
│  │  - Páginas estáticas (ISR, revalidación) │ │
│  │  - Componentes de servidor              │ │
│  │  - API routes (solo proxy, sin PHI)     │ │
│  └─────────────────────────────────────────┘ │
└──────────────────┬──────────────────────────┘
                   │ HTTPS
┌──────────────────▼──────────────────────────┐
│              AWS (HIPAA BAA)                 │
│  ┌──────────────┐  ┌─────────────────────┐  │
│  │  API Gateway  │  │  CloudFront (assets)│  │
│  │  + WAF        │  └─────────────────────┘  │
│  └──────┬───────┘                            │
│         │                                    │
│  ┌──────▼───────┐  ┌─────────────────────┐  │
│  │  ECS Fargate  │──│  RDS PostgreSQL     │  │
│  │  (Payload 3)  │  │  (encriptado)       │  │
│  └──────┬───────┘  └─────────────────────┘  │
│         │                                    │
│  ┌──────▼───────┐  ┌─────────────────────┐  │
│  │  S3 (uploads) │  │  CloudWatch (logs)  │  │
│  │  (encriptado) │  │  (pista de auditoría)│  │
│  └──────────────┘  └─────────────────────┘  │
└─────────────────────────────────────────────┘

Costo de infraestructura mensual: aproximadamente $180-220/mes en AWS (Fargate de ECS es sorprendentemente asequible a esta escala) más $20/mes para Vercel Pro. Compáralo con los $29/mes de hosting compartido en el que estaban antes. Sí, es más caro, pero están obteniendo infraestructura elegible para HIPAA, escalado automático, y seguridad genuina.

Lecciones Aprendidas

1. Comienza conversaciones de HIPAA temprano. Pasamos tres semanas en planificación de arquitectura antes de escribir una sola línea de código. Esto nos ahorró de al menos dos rediseños potenciales.

2. Payload CMS v3 valía la pena esperar. Comenzamos este proyecto cuando Payload 3.0 estaba en beta. Había aspectos ásperos: la documentación de migración estaba incompleta, y algunos complementos no habían sido actualizados. Pero el soporte nativo de Postgres y la interfaz de administrador mejorada lo hicieron la opción correcta.

3. No sobre-ingenierices el formulario de admisión. Nuestro primer prototipo tenía lógica condicional seis niveles de profundidad. El gerente de oficina lo miró y dijo: "¿No podemos simplemente hacer las preguntas en orden?" Tenía razón. Simplificamos, y las tasas de finalización subieron.

4. Los clientes de atención médica necesitan apoyo en el entrenamiento de CMS. Proporcionamos tres sesiones de entrenamiento en lugar de las que normalmente ofrecemos, más videos de Loom grabados para tareas comunes. La inversión en entrenamiento se pagó a sí misma en el primer mes cuando el gerente de oficina pudo agregar una página de nuevo proveedor sin presentar un ticket de soporte.

5. Los presupuestos de rendimiento son innegociables. Establecimos un presupuesto de rendimiento de <400KB de peso de página y <100ms Total Blocking Time al inicio del proyecto. Cada PR fue verificado contra este presupuesto en CI. La única vez que intentamos agregar una biblioteca de ilustración animada, superó el presupuesto, y lo detectamos antes de que se implementara.

Si estás considerando una migración similar para una práctica de atención médica o un sitio de industria regulada, estaríamos encantados de hablar a través de los detalles específicos. Puedes comunicarte directamente con nosotros o verificar nuestra página de precios para rangos de proyectos.

Preguntas Frecuentes

¿Usar Next.js y Payload CMS automáticamente hace que un sitio sea compatible con HIPAA? No. Ningún stack de tecnología es inherentemente compatible con HIPAA. El cumplimiento de HIPAA requiere salvaguardas administrativos (políticas, entrenamiento, evaluaciones de riesgo), salvaguardas físicos (controles de acceso a instalaciones), y salvaguardas técnicos (encriptación, controles de acceso, registros de auditoría). Lo que Next.js y Payload CMS te dan es una arquitectura flexible donde puedes implementar los salvaguardas técnicos correctamente, especialmente la naturaleza auto-hospedada de Payload, que te permite controlar dónde vive el PHI.

¿Por qué no simplemente usar un servicio de formulario compatible con HIPAA como Jotform o FormStack? Definitivamente puedes, y para casos de uso más simples, esa es una opción razonable. Evaluamos el plan HIPAA de Jotform ($99/mes) y FormStack ($83/mes). El problema para este cliente era la profundidad de integración: querían que los datos de admisión fluyeran a un flujo de trabajo personalizado que verificara la elegibilidad del seguro en tiempo real y pre-completara su sistema EHR. Las herramientas de formulario listas para usar no podían manejar eso sin middleware significativo, en cuyo punto estabas construyendo infraestructura personalizada de todas formas.

¿Cuál fue el costo total del proyecto y el cronograma? El proyecto llegó a aproximadamente $42,000 durante 14 semanas. Esto incluía descubrimiento y planificación de arquitectura (3 semanas), diseño (2 semanas), desarrollo (7 semanas), y pruebas/migración (2 semanas). El hosting continuo y el mantenimiento corre aproximadamente $250/mes incluyendo costos de infraestructura y un pequeño contrato de soporte.

¿Puede Payload CMS manejar múltiples ubicaciones para un grupo de atención médica? Sí. Construimos una colección "Locations" en Payload con campos para dirección, horarios, proveedores, seguros aceptados, y contenido específico de ubicación. Cada ubicación obtiene su propia página generada por Next.js con marcado de datos estructurados (esquema LocalBusiness) para SEO local. Agregar una nueva ubicación es tan simple como crear una nueva entrada en el panel de administración de Payload.

¿Cómo manejas los requisitos de retención y eliminación de datos de pacientes? Implementamos políticas automatizadas de ciclo de vida de datos. Los envíos de formularios de admisión se retienen durante 7 años (coincidiendo con el requisito de retención de registros médicos del estado de la práctica), después de los cuales se archivan automáticamente en S3 Glacier y eventualmente se eliminan. Los pacientes también pueden solicitar acceso a datos o eliminación según las leyes de privacidad estatal. Construimos un flujo de trabajo administrativo en Payload donde el personal puede procesar estas solicitudes con una pista de auditoría completa.

¿Qué sucede si el servidor de Payload CMS se cae? El frontend de Next.js sirve páginas generadas estáticamente desde el CDN de Vercel, así que el sitio web principal permanece activo incluso si el backend de Payload está completamente sin conexión. El formulario de admisión de pacientes no estaría disponible durante una interrupción del backend, pero hemos configurado ECS con políticas de reinicio automático, controles de salud cada 30 segundos, y alarmas de CloudWatch que alertan tanto a nuestro equipo como al contacto de TI de la práctica. En 6 meses de producción, hemos tenido cero tiempo de inactividad no planificado.

¿Es esta arquitectura excesiva para una pequeña práctica con una ubicación? Depende de lo que estés haciendo con datos de pacientes. Si solo necesitas un sitio de folleto con un número de teléfono y dirección, WordPress con un buen tema está bien. No necesitas nada de esto. Pero en el momento en que estés recopilando PHI a través de tu sitio web (formularios de admisión, cuestionarios médicos, solicitudes de cita con detalles médicos), necesitas infraestructura que apoye controles de seguridad apropiados. La arquitectura que construimos escala bien hacia abajo. Una práctica de una sola ubicación costaría menos en infraestructura porque tiene menos tráfico.

¿Cómo afectó la migración a las clasificaciones de Google? Vimos una breve fluctuación de clasificación (aproximadamente 10 días) inmediatamente después de la migración, lo cual es normal. Por la semana tres, las clasificaciones se habían estabilizado y tenían una tendencia al alza. Por el mes tres, el tráfico orgánico estaba arriba 34% y las palabras clave principales de la práctica habían mejorado un promedio de 4 posiciones. La mejora de Core Web Vitals fue el factor más grande: Google había estado penalizando el rendimiento móvil deficiente de su sitio anterior en los resultados de búsqueda.