Una práctica de ortopedia de tamaño mediano en el Sureste vino a nosotros con un problema que es dolorosamente común en la atención médica: su sitio de WordPress era lento, su proceso de admisión de pacientes era una pesadilla de descargas de PDF y devoluciones por fax, y su oficial de cumplimiento de TI estaba perdiendo el sueño por la exposición a HIPAA. Seis meses después, tenían un frontend de Next.js, backend de Payload CMS, formularios de admisión de pacientes seguros para HIPAA, y puntuaciones de Lighthouse que hacían que los sitios de sus competidores parecieran estar funcionando en módem de acceso telefónico. Aquí está exactamente cómo lo hicimos.

Tabla de contenidos

Práctica de atención médica: migración de WordPress a Next.js + Payload CMS

El punto de partida: con qué estábamos trabajando

La práctica—llamémosla Southeastern Ortho (NDA, ya sabes cómo funciona)—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 plugins (11 de los cuales no habían sido actualizados en 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 de admisión en PDF que los pacientes tenían que descargar, imprimir, rellenar a mano, y luego enviar por fax o traer a 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 la renderización de cinco plugins diferentes, y jQuery cargándose tres veces por conflictos de plugins.

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

Sus formularios de contacto estaban recopilando 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 plugin de formulario sin encriptación, se almacenaban en una base de datos de WordPress en hosting compartido, y se hacía copia de seguridad en un servicio sin Acuerdo de Asociado de Negocios (BAA). Su oficial de cumplimiento había marcado esto como una bandera, y su aseguradora de responsabilidad civil estaba haciendo preguntas directas.

El encargo

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. Mejor rendimiento de SEO (estaban perdiendo rankings de búsqueda local ante prácticas más nuevas)
  5. Todo esto sin quebrar el banco—son una práctica médica, no una startup tecnológica

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 estimado
Reconstrucción de WordPress (tema nuevo + plugins) Familiar para el personal, costo inicial más bajo Mismos riesgos de HIPAA, techo de rendimiento, dependencia de plugins $15-25K
Webflow + formularios de terceros Rápido de construir, buen rendimiento Opciones limitadas de cumplimiento de HIPAA, costos por asiento continuos, bloqueo de proveedor $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 Gran experiencia de edición, buen ecosistema El precio de Sanity se 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 funcionando en 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 del servidor en tiempo de solicitud significa TTFB rápido.
  • Componentes del servidor para contenido dinámico — disponibilidad de citas, posts 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 de WebP/AVIF reemplazó esos PNGs de 4MB con imágenes de tamaño adecuado y carga perezosa.
  • Middleware para headers de seguridad — usamos middleware de Next.js para establecer headers de CSP estrictos, HSTS y otros headers de seguridad que los auditores de HIPAA aman ver.

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

Payload CMS fue el backend correcto

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

Auto-alojado por diseño. Payload se ejecuta en tu propia infraestructura. Esto es innegociable para HIPAA. Cuando manejas Información de Salud Protegida (PHI), necesitas saber exactamente dónde viven tus datos, quién tiene acceso, y ser capaz de 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 de HIPAA en niveles empresariales, el costo es típicamente 3-5x más de lo que pagarías para auto-alojar 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 añade un nuevo campo para "número de pre-autorización de seguros" al formulario de admisión, nuestro frontend lo conoce 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 posts de blog y páginas de servicios, pero no podía tocar datos de admisión de pacientes. El gerente de oficina podía ver presentaciones 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, que había estado usando WordPress durante años, se sintió cómodo en el panel de administración de Payload dentro de una única sesión de entrenamiento de 45 minutos.

Trabajamos regularmente con Payload y otras plataformas CMS sin cabecera—puedes ver más sobre nuestro enfoque de desarrollo de CMS sin cabecera.

Consideraciones de HIPAA en una arquitectura sin cabecera

Déjame ser claro sobre algo: ninguna pila de tecnología es "compatible con HIPAA" por sí sola. El cumplimiento de HIPAA es una práctica organizacional, no una característica de software. Lo que una pila de tecnología puede ser es "segura para HIPAA"—lo que significa 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—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 de forma nativa, que fue una gran razón por la que esperamos v3.
  • Almacenamiento de archivos: S3 con encriptación del lado del servidor, políticas de bucket restringiendo acceso, y versionado habilitado para rastros de auditoría.

Flujo de datos para admisión de pacientes

Aquí es donde la arquitectura se vuelve 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 → Ruta de API (Next.js en Vercel) → NO se almacena PHI aquí
                                        ↓
                               Puerta de enlace de API de AWS (con WAF)
                                        ↓
                               Función Lambda (valida, encripta)
                                        ↓
                               API de Payload CMS (en ECS Fargate)
                                        ↓
                               RDS PostgreSQL (encriptado en reposo)

La ruta de API de Next.js actúa como un proxy delgado. Valida la estructura de la solicitud (token CSRF, limitación de velocidad, validación básica de campos) pero no registra ni almacena ningún PHI. El procesamiento actual de datos ocurre completamente 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), IDs de seguros, y descripciones de quejas médicas se encriptan a nivel de aplicación usando AES-256-GCM antes de que ni 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 gancho 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, // Presentación 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 los 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 solo añadir; ni siquiera los usuarios administradores pueden modificar o eliminar entradas. Durante la evaluación anual de riesgos de HIPAA de la práctica, este rastro de auditoría fue específicamente mencionado como una fortaleza.

Práctica de atención médica: migración de WordPress a Next.js + Payload CMS - arquitectura

El rediseño de admisión de pacientes

El proceso antiguo: El paciente descarga un PDF de 6 páginas, lo imprime, lo completa con un bolígrafo (la mitad del tiempo ilegiblemente), lo trae a la oficina, y un miembro del personal lo ingresa manualmente en su sistema EHR. Tiempo promedio de descarga a ingreso en EHR: 3-5 días de negocio.

El nuevo proceso: El paciente recibe un mensaje de texto o enlace de correo 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 tarjeta)
  3. Historial médico (lista de verificación de condiciones, historial quirúrgico)
  4. Medicamentos actuales (con autocompletado de una base de datos de formulario abierto)
  5. Motivo de la consulta (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 mostrando "Paso 3 de 7" redujo el abandono aproximadamente 40% comparado con nuestro prototipo inicial que mostraba todos los campos a la vez. A/B probamos esto durante un lanzamiento suave.
  • Carga de foto de tarjeta de seguros con recorte automático y vista previa. Los pacientes fotografían el frente y reverso de su tarjeta. Solo esto eliminó aproximadamente 60% de ingreso de datos de recepción.
  • Autocompletado de medicamentos usando la API de RxNorm. En lugar de que los pacientes intenten deletrear "hidrocloroquina," escriben "hidro" y seleccionan de una lista filtrada. Esto redujo significativamente errores de ingreso de medicamentos.
  • Persistencia de sesión — si un paciente comienza el formulario e interrumpe, su progreso se guarda (encriptado en sessionStorage, nunca localStorage) por 30 minutos. Pueden reanudar donde lo dejaron.
// Autocompletado 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 punto final de búsqueda de medicamentos del lado del servidor consulta RxNorm a través de nuestro backend de AWS, manteniendo la llamada de API externa fuera del cliente y permitiéndonos cachear resultados.

Resultados de rendimiento y puntuaciones de Lighthouse

Aquí está el antes y el 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 página (Página de inicio) 4.8MB 340KB -93%
Core Web Vitals Pass 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 del sitio. Las páginas de contenido como la página de inicio y páginas de servicios consistentemente obtienen 98-100 en móvil y escritorio.

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

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

Consideramos remover 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 está pidiendo presentaciones de spam mezcladas con datos de pacientes reales.

Estrategia de migración: sin tiempo de inactividad, sin pérdida de rankings

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

Migración de contenido

Escribimos un script de migración que extrajo contenido de la API REST de WordPress y lo transformó en documentos de Payload CMS. El script manejó:

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

Mapeo de URL

Cada URL de WordPress fue mapeada 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 corría en paralelo por dos semanas mientras probábamos. En el día de cambio, actualizamos registros de DNS durante una ventana de mantenimiento de domingo por la noche. Tiempo de inactividad total visible: aproximadamente 3 minutos (la propagación de DNS fue rápida porque habíamos pre-bajado los TTLs a 60 segundos una semana antes).

Resultados de SEO

Tres meses post-lanzamiento:

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

Análisis profundo de arquitectura técnica

Para aquellos que quieren la imagen completa:

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

Costo de infraestructura mensual: aproximadamente $180-220/mes en AWS (ECS Fargate es sorprendentemente asequible a esta escala) más $20/mes para Vercel Pro. Compara eso con los $29/mes del 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 valió la pena esperar. Comenzamos este proyecto cuando Payload 3.0 estaba en beta. Había detalles ásperos—la documentación de migración era incompleta, y algunos plugins no habían sido actualizados aún. 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 profunda. El gerente de oficina la miró y dijo, "¿No podemos simplemente hacer las preguntas en orden?" Ella tenía razón. Simplificamos, y las tasas de finalización subieron.

4. Los clientes de atención médica necesitan acompañamiento en el entrenamiento de CMS. Proporcionamos tres sesiones de entrenamiento en lugar de la nuestra usual, más videos grabados en Loom para tareas comunes. La inversión en entrenamiento se pagó a sí misma en el primer mes cuando el gerente de oficina pudo añadir 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 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 añadir una biblioteca de ilustraciones animadas, reventó el presupuesto, y lo capturamos antes de que se implementara.

Si estás considerando una migración similar para un sitio de atención médica o industria regulada, estaríamos felices de hablar sobre los detalles específicos. Puedes contactarnos directamente o revisar 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. Ninguna pila de tecnología es inherentemente compatible con HIPAA. El cumplimiento de HIPAA requiere salvaguardas administrativos (políticas, entrenamiento, evaluaciones de riesgos), 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 correctamente los salvaguardas técnicos—especialmente la naturaleza auto-alojada de Payload, que te permite controlar dónde vive el PHI.

¿Por qué no solo usar un servicio de formulario compatible con HIPAA como Jotform o FormStack? Absolutamente puedes, y para casos de uso más simples, esa es una opción razonable. Evaluamos el plan de 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 hacia un flujo de trabajo personalizado que verificara la elegibilidad del seguro en tiempo real y pre-poblara su sistema EHR. Las herramientas de formulario listas para usar no podían manejar eso sin middleware significativo, en cuyo punto estás construyendo infraestructura personalizada de todas formas.

¿Cuál fue el costo total del proyecto y la línea de tiempo? El proyecto llegó a aproximadamente $42,000 sobre 14 semanas. Esto incluyó descubrimiento y planificación de arquitectura (3 semanas), diseño (2 semanas), desarrollo (7 semanas), y prueba/migración (2 semanas). El hosting continuo y mantenimiento corre aproximadamente $250/mes incluyendo costos de infraestructura y una pequeña retención de soporte.

¿Puede Payload CMS manejar múltiples ubicaciones para un grupo de atención médica? Sí. Construimos una colección "Ubicaciones" 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 de LocalBusiness) para SEO local. Añadir 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 presentaciones de formularios de admisión se retienen por 7 años (coincidiendo con el requisito de retención de registros médicos del estado de la práctica), después de lo cual se archivan automáticamente a S3 Glacier y eventualmente se eliminan. Los pacientes también pueden solicitar acceso a datos o eliminación bajo leyes de privacidad estatal—construimos un flujo de trabajo de administrador en Payload donde el personal puede procesar estas solicitudes con un rastro de auditoría completo.

¿Qué sucede si el servidor de Payload CMS se cae? El frontend de Next.js sirve páginas generadas estáticamente desde la CDN de Vercel, así que el sitio principal se mantiene incluso si el backend de Payload está completamente fuera de línea. El formulario de admisión de pacientes estaría no disponible durante una interrupción de backend, pero hemos configurado ECS con políticas de auto-reinicio, verificaciones 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 planeado.

¿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 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 adecuados. La arquitectura que construimos escala bien hacia abajo—una práctica de una sola ubicación costaría menos en infraestructura por tráfico más bajo.

¿Cómo afectó la migración a los rankings de Google? Vimos una breve (aproximadamente 10 días) fluctuación de ranking inmediatamente después de la migración, que es normal. Por la semana tres, los rankings se habían estabilizado y estaban tendiendo 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 su sitio antiguo por el pobre rendimiento móvil en resultados de búsqueda.