Un fallo en AMP o en la invalidación CDN suele provocar caídas de tráfico y pérdida de posiciones en 48–72 horas. Los responsables técnicos y propietarios que gestionan WordPress necesitan procesos fiables que reduzcan riesgos: backups y snapshots, staging reproducible, validaciones automáticas y rollback preparado.
Actualizaciones para sitios móviles y AMP híbrido: para actualizar estos sitios sin riesgos, realiza prechecks (backup completo, staging, validación AMP y pruebas de Core Web Vitals), aplica actualizaciones por fases con pruebas automatizadas (CI/CD), controla cache/CDN e invalidaciones, supervisa Search Console y métricas 48–72 horas y ten listo un rollback automatizado. Aplicar este flujo reduce impactos, acelera recovery y mantiene SLA de rendimiento y seguridad.
Resumen del proceso
Resume el proceso y tendrás la lista de pasos ejecutables para desplegar sin sorpresas.
- Backup completo y snapshot de base de datos, conservar dos copias. (10–30 minutos según tamaño)
- Replica producción en staging con las mismas versiones de PHP, servidor y cache. (30–90 minutos)
- Validación AMP y Lighthouse en staging; bloquear deploy si fallan tests. (el tiempo real por URL depende de la infraestructura y del número de recursos: optimiza ejecutando auditorías en paralelo, muestreo por rutas críticas y uso de cachés de ejecución para reducir tiempos). En pipelines grandes es preferible ejecutar una muestra representativa y checks completos en paralelo para acelerar el feedback loop.
- CI/CD: lint AMP, pruebas E2E, regresión visual y Lighthouse como gates.
- Despliegue por fases con canary, purga por tags en CDN y actualización AMP Cache.
- Monitorización intensiva 48–72 horas y rollback automático si se supera un umbral.
Qué conseguirás con este flujo
Tendrás un deploy repetible que reduce la ventana de riesgo y guarda evidencia para SEO. La estrategia disminuye la probabilidad de perder impresiones o posiciones en Google en las 72 horas siguientes.
El pipeline debe incluir umbrales configurables: por ejemplo, bloquear si aparecen errores AMP críticos o si el LCP/CLS/INP muestra una regresión superior a un umbral adaptado al sitio (por ejemplo 10–20% para páginas críticas), definido a partir de la telemetría real (RUM/CrUX) y validado en staging. Esto evita aplicar un valor único a todos los proyectos y permite ajustar la sensibilidad según SLA y tráfico.
Paso 1: prechecks y backups
Realiza el backup y tendrás una copia completa lista para restaurar en minutos.
Antes de tocar código, exporta la base de datos y copia el wp-content. Esto evita pérdidas si la actualización falla.
Ejecuta un snapshot a nivel de almacenamiento (LVM, ZFS o snapshot del proveedor). El snapshot restaura archivos y estado del servidor con mayor rapidez.
Backup y snapshot
Crea dos copias: una local cifrada y otra offsite en S3 o similar. Mantén retención mínima de 30 días para auditoría legal.
Comandos prácticos:
bash
wp db export backup_preupdate.sql --path=/var/www/html
rsync -avz --delete /var/www/html s3://empresa-backups/site
lvcreate --snapshot --name snap_preupdate --size 5G /dev/vg/www
Entorno staging idéntico
Replica versiones exactas de PHP, Nginx/Apache, Redis/OpCache y configuración del CDN si es posible. Un staging que difiere en PHP o en cache da falsos negativos.
Usa imágenes etiquetadas por versión y provisionamiento con IaC para evitar diferencias humanas. Esto permite reproducir el rollback en el mismo entorno.
Validación AMP previa
Valida cada plantilla que genera AMP con amphtml-validator. Guarda el informe JSON para compararlo tras el deploy.
Comando de ejemplo en CI:
bash
npx amphtml-validator https://staging.example.com/pagina/amp/ --output=json > amp-report.json
La captura de Core Web Vitals en staging sirve como línea base sintética, pero debe complementarse con métricas de campo (RUM/CrUX) para definir umbrales reales; staging puede ayudar a detectar regresiones introducidas por cambios de código, mientras que la validación final debe contrastarse con los datos de producción y Search Console antes de decidir rollback.
Paso 2: CI/CD y validaciones AMP
Configura el pipeline y evitarás desplegar código que rompa AMP o degrade rendimiento.
Integra en la pipeline pasos de lint AMP, Lighthouse CI, regresión visual y pruebas E2E. Si cualquiera falla, el merge queda bloqueado.
Automatiza artefactos: reportes Lighthouse, screenshots, logs de validación AMP y resultados de E2E.
Lint y validación AMP
Añade amphtml-validator al build. Si se detecta HTML inválido, la pipeline debe notificar y crear un issue.
Ejemplo de step en GitHub Actions:
yaml
- name: Validate AMP
run: npx amphtml-validator "https://staging.example.com/${{ matrix.path }}" --output=json > amp-report.json
Lighthouse y pruebas automatizadas
Usa Lighthouse CI para auditar LCP, CLS y INP. Define un presupuesto y falla el build si se supera.
Comando ejemplo:
bash
lhci autorun --url=https://staging.example.com/pagina-amp/ --preset=mobile
Regresión visual y E2E
Ejecuta Playwright o Cypress para clicks, formularios y amp-form. Añade Percy o BackstopJS para comparar screenshots.
Esto funciona bien en teoría, pero en la práctica la mayor fuente de falsos positivos son los datos dinámicos (comentarios, anuncios). Excluir selectores dinámicos reduce ruido.
Frase de recomendación
El pipeline debe publicar artefactos JSON y capturas para cada despliegue, con enlaces accesibles por el equipo SEO y soporte.
Commit en repo
→
Build (lint AMP)
→
Lighthouse CI
→
E2E + Regresión visual
→
Canary deploy
Para que el CI/CD no sea solo un pipeline de checks, incorpora canary deploys y rollback automático orquestados desde el propio flujo. Un esquema habitual: desplegar primero al 1–5% de la capa de tráfico (canary), ejecutar pruebas E2E, regresión visual y Lighthouse sobre ese segmento y comprobar métricas agregadas de LCP/CLS e informes de validación AMP; si LCP sube >15% o aparecen errores AMP bloqueantes, el pipeline ejecuta rollback automático y lanza purga de cache/tag en la CDN. En la práctica esto se implementa con feature flags o control de pesos en el balanceador (ej. NGINX/upstream weights o Cloud Load Balancer), y pasos en GitHub Actions/GitLab CI que llaman la API de Cloudflare para purga de cache y scripts que realizan wp plugin deactivate o wp option update como hotfix. Incluir triggers automáticos para rollback reduce RTO y evita acciones manuales en las primeras 48–72 horas post-deploy.
Paso 3: cache, CDN e invalidaciones
Configura purgas y TTL para evitar servir HTML AMP obsoleto tras el deploy.
Define cabeceras Cache-Control y usa purgas por tags o por rutas específicas. Evitar purgas masivas reduce coste y carga al origen.
Programa invalidación en CDN directamente desde la CI tras el deploy exitoso.
Cabeceras y TTL recomendados
Para HTML AMP, use: Cache-Control: public, max-age=60, stale-while-revalidate=300. Esto mantiene frescura y reduce carga.
Recursos estáticos deben versionarse y recibir max-age alto: 31536000 y immutable cuando usen hash en el nombre.
Purgas por etiqueta y rutas AMP
Etiquetar objetos en CDN por site y por tipo (ej. Tag=site-1234, tag=amp). Purga por tag tras deploy para invalidar solo AMP.
Ejemplo Cloudflare API:
bash
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone}/purge_cache" /
-H "X-Auth-Email: [email protected]" /
-H "X-Auth-Key: $CF_KEY" /
-H "Content-Type: application/json" /
--data '{ "files": ["https://example.com/pagina/amp/"] }'
Purgas de AMP cache
Cuando sea necesario, solicitar actualización de AMP Cache siguiendo la especificación del AMP Project. Esto acelera la propagación en caches externos.
Enlace de referencia: AMP Project
Service worker y SW conflictivo
Si hay Service Worker, coordinar su versión y estrategia cache. Para AMP, usa network-first para páginas; de lo contrario, el SW puede servir versiones antiguas durante horas.
Paso 4: pruebas en staging y migración a AMP híbrido
Ejecuta pruebas completas y la migración por fases para no romper la indexación móvil.
Audita plantillas, plugins y genera inventario de rutas AMP antes de activar el modo híbrido.
Realiza despliegues canary y escala según métricas en las primeras 72 horas.
Checklist de migración
Inventario de templates que generan AMP. Revisar single.php, page.php y partes del theme que inyectan scripts.
Probar en staging dominios con paridad de headers y CDN. Simular Googlebot Smartphone en peticiones.
Comandos WP-CLI y search-replace
Desactivar plugins problemáticos:
bash
wp plugin deactivate plugin-slug --path=/var/www/html
Configurar modo híbrido (ejemplo si el plugin usa option JSON):
bash
wp option update amp_options '{"template_mode":"hybrid"}'
Buscar y reemplazar atributos masivos:
bash
wp search-replace 'rel="amphtml"' 'rel="amphtml" data-migrado="1"' --skip-columns=guid
Tabla de compatibilidad de plugins
| Plugin / Theme |
Compatibilidad |
Problemas comunes |
Recomendación |
| AMP for WordPress (Automattic) |
Alta |
Ajustes de templates requieren revisión |
Usar modo híbrido y probar plantillas |
| Yoast SEO |
Alta |
Metadatos y breadcrumbs OK |
Verificar output JSON-LD |
| WooCommerce |
Parcial |
Checkout y scripts personalizados |
Excluir checkout de AMP o aplicar patches |
| Elementor / Divi |
Parcial |
Widgets que inyectan JS no permitido |
Revisar plantillas y evitar widgets problemáticos |
| WP Rocket / Varnish |
Alta con configuración |
Cache TTL en HTML debe ajustarse |
Configurar TTL corto para HTML AMP |
Paso 5: rollback y mitigación
Prepara scripts de rollback y reducirás el tiempo fuera de servicio a minutos.
Define modo mantenimiento, restauración de BD y purga CDN como pasos automáticos del rollback.
Documenta las acciones y asocia responsables para cada paso en el playbook.
Rollback desde snapshot
Bloquea las escrituras, restaura la BD desde backup_preupdate.sql y sincroniza ficheros desde el snapshot.
Comandos prácticos:
bash
wp db import backup_preupdate.sql --path=/var/www/html
rsync -avz --delete s3://empresa-backups/site/ /var/www/html/
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone}/purge_cache" ...
Hotfixes y mitigaciones parciales
Si el rollback total es inviable, aplicar un hotfix en el template que elimina la inyección de JS. Esto suele resolver errores AMP en menos de 30 minutos.
Caso habitual: un plugin de marketing inyectó inline script y rompió miles de AMP. Revertir el plugin restauró validación en 25 minutos.
Errores que arruinan el resultado
Identifica y evita los errores que causan la mayor parte de los incidentes.
El error más frecuente en este punto es actualizar plugins o themes directamente en producción sin pasar por staging. Esto suele producir páginas AMP inválidas y pérdida de impresiones.
Errores típicos:
- No purgar CDN tras cambios en plantillas AMP (sirve HTML antiguo).
- Plugins que inyectan JS inline (rompen AMP).
- Cambios en canonical/hreflang sin actualización de sitemap.
Los casos reales ayudan a priorizar respuestas. Ejemplo A:
- un marketing plugin fue actualizado en producción y comenzó a inyectar inline JavaScript en plantillas AMP
- en T+2h Search Console mostró cientos de errores AMP y las impresiones móviles cayeron ~60% en 48h. Acción: desactivar el plugin con wp plugin deactivate, restaurar snapshot de ficheros, purgar por tag en la CDN y solicitar reindex con URL Inspection
- recuperación completa en ~72h. Ejemplo B: un deploy que actualizó plantillas AMP pero olvidó ejecutar la invalidación por tags dejó la CDN sirviendo HTML antiguo
- síntoma: divergencia entre LCP sintético (staging) y producción
- solución: ejecutar purga por tag vía API (o purge list de URLs /amp/), canary re-deploy y monitorizar LCP/CLS
- la corrección tardó minutos en propagarse y la visibilidad en GSC se normalizó en 24–48h
Incluir mini-postmortems con timeline y comandos (wp, rsync, Cloudflare API) en el playbook acelera la respuesta en incidentes reales.
Comprobación final y seguimiento
Verifica métricas y comunica el estado para cerrar el ciclo de despliegue.
Revisar Core Web Vitals, Search Console y logs durante 48–72 horas. Registrar cualquier desviación mayor al 15%.
Mantener un changelog con artefactos y reportes para auditoría y SEO.
Métricas y umbrales
Capturar LCP, CLS e INP. Umbrales orientativos: LCP <2.5s, CLS <0.10, INP <100ms.
Alerta si cualquiera excede 15% respecto a la línea base en las primeras 24 horas.
Monitorización y alertas
Configurar alertas en Slack/Email desde Prometheus/Datadog para 5xx, degradación de LCP y errores AMP. Revisar Mobile Usability en Google Search Console cada 24 horas.
Esta guía no aplica si el sitio no usa AMP (solo responsive) o si un proveedor gestionado realiza actualizaciones y pruebas por acuerdo SLA; en esos casos, coordinar con el proveedor para integrar las validaciones descritas.
Para asistencia en un despliegue inminente, se puede solicitar revisión de predespliegue con tiempos de respuesta en menos de 24 horas a través del servicio de mantenimiento especializado.
Las actualizaciones en WordPress, en plugins o en la librería AMP pueden impactar la indexación y las Core Web Vitals de forma distinta: un cambio en el theme que altera el orden de carga de CSS o añade imágenes no optimizadas tiende a aumentar el LCP; un script inyectado puede generar CLS al insertar elementos después del render; y una actualización del runtime AMP puede cambiar el comportamiento de lazy-loading y afectar INP. En la práctica conviene mapear por tipo de cambio (core, plugin, assets, runtime) el riesgo sobre LCP/CLS/INP y correlacionarlo con datos de campo (Search Console - Core Web Vitals y CrUX) y sintéticos (Lighthouse).
Por ejemplo, una modificación que aumenta el LCP más de un 15–20% en sintético suele reflejarse en degradación de impresiones en 24–72 horas si además provoca errores AMP en Search Console. Por eso, captura métricas antes del despliegue (staging idéntico o scraping sintético) y compáralas con la telemetría real para priorizar rollbacks o hotfixes en caso de desviaciones.
Preguntas frecuentes
¿Cómo evitar que una actualización rompa AMP?
Evitar actualizar en producción sin staging y pipeline de validaciones. Testear AMP y Lighthouse en staging y bloquear merge si falla.
¿Cuáles son las pruebas mínimas antes del despliegue?
Validación AMP, Lighthouse móvil, E2E sobre rutas críticas y regresión visual. Guardar artefactos del build.
¿Cómo purgo solo las páginas AMP en cloudflare?
Purgar por URL o usar cache-tags. Enviar POST a la API de Cloudflare con la lista de URLs /amp/ que cambian.
¿Qué métricas vigilar tras el deploy?
LCP, CLS, INP, errores AMP en Search Console y tasa de 5xx. Revisar las primeras 72 horas intensivamente.
¿Se puede automatizar el rollback?
Sí. Automatizar restauración de snapshot, purga CDN y desactivar el nuevo release reduce RTO a minutos.
¿Qué hacer si Google detecta páginas AMP inválidas?
Restaurar la versión previa o aplicar hotfix que elimine la inyección de JS. Después, forzar revalidación con Search Console.
¿Puedo activar actualizaciones automáticas en WordPress?
Se puede, pero no para plugins que afecten AMP sin pipeline de staging. Activarlas aumenta riesgo si no hay pruebas automáticas.
