¿Más del 50 % de las visitas proceden de móvil y la web tarda más de 3 segundos en cargar? Lectores se marchan, la publicidad rinde menos y la propietaria teme que un cambio técnico reduzca ingresos o genere costes inesperados.
Cuándo merece la pena AMP en medios locales
AMP suele ser rentable cuando el tráfico móvil representa una parte significativa de las visitas y la web sufre problemas claros de rendimiento. Si más del 50% del tráfico proviene de móvil y el LCP supera 2.5 segundos, aplicar AMP puede reducir tiempos y aumentar sesiones móviles.
La evidencia apunta a que la mejora en Core Web Vitals tras pasar a AMP se traslada a una mejor experiencia de usuario. El impacto en rankings no es directo; lo que cambia es la experiencia móvil y, con ella, el CTR y la retención.
El error más frecuente en este punto es decidir sin datos: muchas redacciones activan AMP por moda y no miden LCP, INP o RPM antes y después.
¿Qué métricas medir antes de decidir?
Medir LCP, INP (o FID si la herramienta lo muestra) y CLS en móvil durante 14 días da un baseline fiable. Registrar RPM por sección y CTR de noticias completa el cuadro económico.
Usar CrUX, Lighthouse y Google Search Console evita sorpresas. La recomendación práctica es guardar 14 días de datos antes y comparar 6 semanas tras el cambio.
¿Qué impacto económico justificaría la migración?
Ese umbral del 10% debe presentarse como una regla heurística, no como una garantía universal: en sitios pequeños o con alta variabilidad en RPM un 10% puede no cubrir costes de ingeniería; por ello conviene contextualizarlo según volumen de tráfico, secciones afectadas y significación estadística de la mejora. Para anuncios complejos, planear pruebas A/B de 4 a 8 semanas ayuda a decidir.
Medio local con más de 50% tráfico móvil: plan de acción
En medios con tráfico móvil mayoritario la prioridad es velocidad sin perder control de anuncios ni datos. El plan mínimo son pasos técnicos, pruebas publicitarias y ajuste de redacción para AMP.
Esto funciona bien en teoría, pero en la práctica hay que coordinar redacción y TI: las plantillas AMP cambian el HTML y los redactores deben seguir reglas concretas de marcado y metadatos.
Un caso habitual: un diario provincial con LCP 4.2s pasa a AMP y en 6 semanas baja LCP a 1.5s; las sesiones móviles suben 18% y el RPM general se mantiene tras ajustar wrappers publicitarios.
¿Qué pasos técnicos seguir en WordPress?
Hacer una copia de staging y activar un plugin fiable. Configurar rel=amphtml y canonical en cada entrada y añadir JSON-LD NewsArticle con metadatos de localización.
Probar con el plugin oficial AMP o el modo manual según el control deseado. Validar cada plantilla con el validador AMP antes de enviar a producción.
¿Cómo coordinar redacción y SEO?
Definir plantillas de titular, entradilla y metadatos que funcionen en AMP y desktop. Incluir campos obligatorios en el CMS para JSON-LD y sitemaps de noticias.
Formar a periodistas en 1 sesión práctica para que publiquen con todos los campos necesarios y eviten iframes o scripts no permitidos.
Medio con bajo tráfico móvil o publicidad compleja
Si el móvil supone menos del 30% del tráfico o si la pila publicitaria usa wrappers no compatibles, AMP puede generar más problemas que beneficios. Priorizar mejoras responsive o una PWA suele ser mejor opción.
La mayoría de guías dicen que AMP es siempre mejor; lo que no mencionan es el coste de adaptar wrappers de anuncios y CMPs a AMP.
Si la inversión técnica y las pérdidas potenciales en RPM superan el beneficio esperado, no aplicar AMP y mejorar el sitio responsive es una decisión razonable.
¿Cuándo elegir PWA en lugar de AMP?
Elegir PWA cuando se necesita funcionalidad offline, autenticación de usuarios o interacción avanzada que AMP no soporta bien. PWA permite control total sobre scripts y monetización.
Si ya existe una arquitectura responsive optimizada y control sobre ads, la PWA o mejoras de servidor pueden dar más retorno que AMP.
¿Qué mejoras responsive conviene aplicar primero?
Optimizar imágenes con formato next-gen, aplicar lazy loading y mejorar servidor/CDN reduce LCP sin cambiar plantillas. Vigilar fuentes web y minimizar CSS crítico ayuda notablemente.
Errores que rompen ingresos y SEO al pasar a AMP
El mayor error técnico es no configurar canonical y rel=alternate correctamente, lo que puede causar contenido duplicado y pérdida de indexación. Vigilar esto evita caídas en Search Console.
Ignorar la compatibilidad publicitaria produce pérdidas de ingresos. Muchos venden la idea de "AMP y listo"; la realidad exige adaptar wrappers, Prebid y comprobación de iframes.
¿Qué fallos de canonical causan pérdidas de tráfico?
No poner rel="canonical" en la versión canónica o rel="amphtml" en la versión desktop genera confusión para Google. Comprobar ambos enlaces en cada entrada es imprescindible.
¿Por qué fallan los anuncios en AMP?
Porque muchos tags publicitarios usan scripts no permitidos en AMP. Hay que migrar a amp-ad o a iframes seguros y revisar la compatibilidad con partners publicitarios.
Migración práctica: WordPress, drupal y CMS a medida
La migración efectiva combina plantillas AMP, canonical correctos, JSON-LD y pruebas A/B en fases de despliegue. Seguir un plan evita pérdidas de tráfico y de ingresos.
El error más frecuente al migrar es hacerlo directo a producción. Hacer canary releases y medir 5%–25% del tráfico reduce riesgos.
Según la guía oficial de AMP, usar componentes como amp-img y amp-analytics facilita compatibilidad con AMP Cache; más información en amp.dev.
¿Cómo hacer la migración en WordPress?
Instalar el plugin oficial AMP y elegir modo Standard o Reader según el control deseado. Configurar rel=amphtml automáticamente y añadir JSON-LD en el head.
Crear un staging y validar con el validador; luego hacer despliegue gradual (canary 5% → 25% → 100%). Vigilar RPM y LCP tras cada paso.
¿Y en drupal o CMS propio?
En Drupal usar el módulo AMP y Views para generar versiones amphtml. En CMS propio crear ruta /amp/ que devuelva AMP HTML server-side.
Asegurar que los componentes multimedia usen amp-video o amp-carousel y que los anuncios salgan por iframes seguros o amp-ad.
En migraciones reales a AMP para medios locales la operación suele desglosarse en pasos concretos que merece la pena enumerar con ejemplos: en WordPress conviene crear un entorno staging, instalar el plugin “AMP” (o “AMP for WP” según control deseado), decidir modo Standard/Reader y mapear campos obligatorios del CMS (titulo, entradilla, author, fecha, imagen principal) para que el plugin genere el JSON-LD correcto; habilitar rel="amphtml" en el head y comprobar que el canonical apunta a la versión desktop. En Drupal es habitual usar el módulo AMP y Views para exponer una ruta /amp que consuma los mismos campos que la vista canonical; en CMS a medida se implementa un endpoint server-side (/noticia/1234/amp) que sustituye scripts por componentes amp- (amp-img, amp-video) y emite amp-analytics.
Finalizar con validación en el validador AMP y despliegue canario (5%→25%→100%) permite aislar problemas de compatibilidad publicitaria y metadatos sin interrumpir la indexación ni Google News.
¿Cómo hacer la migración en WordPress?
Instalar el plugin oficial AMP y elegir modo Standard o Reader según el control deseado. Configurar rel=amphtml automáticamente y añadir JSON-LD en el head.
Crear un staging y validar con el validador; luego hacer despliegue gradual (canary 5% → 25% → 100%). Vigilar RPM y LCP tras cada paso.
¿Y en drupal o CMS propio?
En Drupal usar el módulo AMP y Views para generar versiones amphtml. En CMS propio crear ruta /amp/ que devuelva AMP HTML server-side.
Asegurar que los componentes multimedia usen amp-video o amp-carousel y que los anuncios salgan por iframes seguros o amp-ad.
En migraciones reales a AMP para medios locales la operación suele desglosarse en pasos concretos que merece la pena enumerar con ejemplos: en WordPress conviene crear un entorno staging, instalar el plugin “AMP” (o “AMP for WP” según control deseado), decidir modo Standard/Reader y mapear campos obligatorios del CMS (titulo, entradilla, author, fecha, imagen principal) para que el plugin genere el JSON-LD correcto; habilitar rel="amphtml" en el head y comprobar que el canonical apunta a la versión desktop. En Drupal es habitual usar el módulo AMP y Views para exponer una ruta /amp que consuma los mismos campos que la vista canonical; en CMS a medida se implementa un endpoint server-side (/noticia/1234/amp) que sustituye scripts por componentes amp- (amp-img, amp-video) y emite amp-analytics.
Finalizar con validación en el validador AMP y despliegue canario (5%→25%→100%) permite aislar problemas de compatibilidad publicitaria y metadatos sin interrumpir la indexación ni Google News.
Monetización en AMP: qué funciona y qué no
AMP soporta anuncios, pero requiere formatos compatibles como amp-ad y Ad Manager. También acepta soluciones de header bidding adaptadas a AMP.
La realidad práctica es que algunos partners publicitarios no funcionan igual en AMP. Probar y medir RPM por 4 a 8 semanas es imprescindible antes de decidir.
Usar amp-ad para Google Ad Manager y iframes certificados para socios. Para header bidding, emplear Prebid AMP o wrappers compatibles.
¿Cómo controlar el RPM y viewability?
Medir RPM, CTR y viewability por versión (AMP vs desktop) y por sección. Definir umbrales de alerta, por ejemplo caída de RPM superior al 15% obliga a rollback parcial.
En monetización AMP conviene mostrar ejemplos concretos y límites prácticos: un tag básico de Google Ad Manager en AMP puede lucir como <amp-ad width="300" height="250" type="doubleclick" data-slot="/1234/noticia_300x250"></amp-ad>; para header bidding existe Prebid AMP (que moviliza un flujo distinto al desktop y requiere configurar adapters AMP y server-side auctions). Las limitaciones frecuentes son: no se pueden ejecutar scripts asíncronos arbitrarios, muchos wrappers desktop no funcionan y la viewability puede variar según el formato amp-ad o el uso de iframes certificados.
En la práctica, combinar amp-ad para inventario estándar y soluciones de header bidding compatibles con AMP, medir RPM por formato y sección y aplicar A/B testing en canary releases permite recuperar o mejorar ingresos, pero es imprescindible contar con ejemplos de configuración concretos para cada partner publicitario.
Consentimiento y cumplimiento RGPD en páginas AMP
Las AMP necesitan amp-consent para gestionar consentimiento sin bloquear funcionalidades ni anuncios. Configurar amp-consent correctamente permite respetar RGPD y LOPDGDD.
La AEPD exige registros de consentimiento y transparencia, por eso hay que documentar los flujos y conservar logs accesibles para auditoría. Más información en AEPD.
¿Cómo integrar un CMP con amp-consent?
Configurar amp-consent con el proveedor CMP para que envíe la decisión a los iframes y a amp-analytics. Testear tres estados: otorgado, denegado y sin respuesta.
¿Qué auditoría legal ejecutar antes del despliegue?
Registrar el flujo de consentimiento, el tratamiento de datos y el proveedor de anuncios. Preparar documentación para LSSI-CE y RGPD y conservar registros de cada consentimiento.
Pruebas, métricas y checklist operativo para equipos
Un checklist claro evita errores comunes y reduce tiempo de rollback. Dividir tareas entre redacción y TI agiliza el despliegue y mejora control de calidad.
La mayoría de guías omiten el checklist de redacción; incluir pasos para metadatos y plantillas evita rechazo en Google News y problemas de indexación.
¿Qué pruebas técnicas ejecutar antes del push?
Validar AMP HTML con el validador, comprobar sitemaps de noticias y revisar Search Console para errores. Probar en dispositivos reales y en Lighthouse.
¿Qué pruebas económicas ejecutar tras el cambio?
Realizar pruebas A/B para anuncios, medir RPM y comparar CTR en 4–8 semanas. Vigilar indicadores y preparar rollback si RPM cae más del 15%.
Snippets y plantillas útiles para noticias locales
Aquí hay ejemplos listos para copiar: rel=canonical/rel=amphtml y JSON-LD NewsArticle adaptado a localización. Pegar en la plantilla de single del CMS o en el endpoint /amp/.
El siguiente bloque es un snippet típico de rel y canonical que funciona en WordPress o CMS propio:
Y este es un JSON-LD básico para noticias locales:
{
"@context": "https://schema.org",
"@type": "NewsArticle",
"headline": "[TITULAR]",
"datePublished": "2024-06-01T08:00:00Z",
"dateModified": "2024-06-01T09:00:00Z",
"author": {"@type": "Person","name": "Redacción"},
"publisher": {"@type": "Organization","name": "Diario Local","logo": {"@type": "ImageObject","url": "https://ejemplo.com/logo.png"}},
"mainEntityOfPage": {"@type": "WebPage","@id": "https://ejemplo.com/noticia/1234"},
"locationCreated": "Provincia X"
}
Comparativa empírica
Caso típico: reducción de LCP de 4.2s a 1.5s tras pasar a AMP y ajuste de imágenes en 6 semanas. Las sesiones móviles aumentaron 18% y el RPM se mantuvo tras adaptar wrappers publicitarios.
Google lanzó el Page Experience como factor relacionado con Core Web Vitals. Medir antes y después con CrUX y Search Console proporciona evidencia objetiva.
Un ejemplo reproducible de comparativa aporta contexto más allá de una anécdota:
- midiendo con CrUX y Lighthouse durante 28 días de baseline y 42 días tras la migración, un conjunto de tres diarios locales mostró cambios típicos —Sitio A: LCP 4,2s→1,5s, INP 320ms→120ms, sesiones móviles +18%, RPM total −2% que luego se recuperó tras ajustes publicitarios
- Sitio B: LCP 3,1s→1,3s, INP 250ms→100ms, sesiones +12%, RPM +4%
- Sitio C (pila publicitaria compleja): LCP 3,8s→1,9s, INP 280ms→140ms, sesiones +9%, RPM −15%—. Estos números muestran que la mejora en Core Web Vitals suele traducirse en más sesiones móviles pero el impacto en RPM depende de adaptaciones de wrappers y partners
- documentar la metodología (herramientas, ventanas temporales y segmentación por sección) permite interpretar la significancia de cambios
Comparativa técnica: AMP vs PWA vs responsive
| Opción |
Coste (estimado) |
Impacto en CWV |
Compat. Anuncios |
Tiempo implementación |
| AMP |
Medio (2-6 semanas) |
Alto (reduce LCP) |
Buena, requiere adaptaciones |
3–8 semanas |
| PWA |
Alto (desarrollo) |
Variable (depende) |
Total control |
2–4 meses |
| Mejorar responsive |
Bajo-med (optimización) |
Medio (si se hace bien) |
Completa |
2–6 semanas |
1
Auditoría inicial (14 días)
Medir LCP, INP, RPM y compatibilidad ads.
2
Staging y validación
Configurar rel=amphtml, JSON-LD y validar AMP HTML.
3
Canary y pruebas publicitarias
Desplegar 5%→25% y medir RPM 4–8 semanas.
Preguntas frecuentes
¿Qué son las páginas AMP?
Son versiones ligeras de páginas web diseñadas para cargar rápido en móvil. AMP usa AMP HTML y componentes como amp-img.
¿Las AMP mejoran el SEO directamente?
Mejoran la experiencia móvil que puede influir en métricas como CTR y retención. El contenido y la indexación siguen siendo decisivos.
¿Cómo se valida que una AMP es correcta?
Usar el validador AMP y Search Console. Corregir errores hasta que el validador marque OK antes de enviar sitemap a Google.
¿Perderé ingresos al pasar a AMP?
No necesariamente, pero requiere adaptar wrappers y anuncios. Probar RPM durante 4–8 semanas evita sorpresas.
¿Cómo responder a una caída de RPM tras lanzar AMP?
Revisar compatibilidad de tags, ajustar ubicaciones y, si hace falta, reducir rollout al 25% hasta estabilizar ingresos.
¿Qué reglas legales debo cumplir al usar AMP?
Registrar consentimiento con amp-consent, conservar logs y publicar información clara según RGPD y LSSI-CE. Documentar todo para auditoría.
Para quien necesite evidencia o una auditoría técnica rápida, puede pedirse una revisión de 1 día que incluya Core Web Vitals, comprobación AMP y pruebas básicas de anuncios.
Qué hacer ahora
Priorizar datos antes de decidir: medir 14 días de Core Web Vitals y revenue para tener una base objetiva. Sin datos no se puede justificar la migración.
Si más del 50% del tráfico es móvil y LCP supera 2.5s, preparar un plan de 3–8 semanas con staging y pruebas publicitarias. Si el móvil supone menos del 30% o la pila publicitaria es inflexible, mejorar responsive o construir una PWA puede ser mejor opción.
Para ejecutar: definir fases, responsables y criterios de rollback antes del primer despliegue. Vigilar LCP, INP, CLS, sesiones y RPM durante 6 semanas tras cada cambio.
No conviene migrar a AMP cuando el sitio tiene muy bajo tráfico móvil, cuando la inversión técnica supera el beneficio esperado, o cuando ya dispone de una arquitectura responsive/PWA optimizada y control total sobre monetización y funcionalidades avanzadas que AMP no soporta.
