AMP: del dominio de Google a la era de Core Web Vitals

Accelerated Mobile Pages (AMP) es un framework de componentes web de código abierto diseñado para crear páginas web que se cargan casi instantáneamente en dispositivos móviles. A diferencia de lo que muchos creen, AMP no es propiedad exclusiva de Google, aunque el gigante tecnológico fue su principal impulsor y mantiene una participación significativa en su desarrollo a través del proyecto AMP Open Source.

La filosofía detrás de AMP es simple pero radical: imponer restricciones técnicas estrictas que eliminen todo aquello que ralentiza la carga de una página web. Esto significa prohibir JavaScript de terceros sin control, limitar drásticamente el CSS y crear un ecosistema cerrado donde cada elemento está optimizado para la velocidad extrema.

El ecosistema AMP: la tríada de la velocidad

Para comprender verdaderamente AMP, debemos entender sus tres pilares fundamentales:

1. AMP HTML: No es HTML convencional, sino una versión modificada con restricciones específicas. Ciertas etiquetas HTML tradicionales están prohibidas (como <img>, <video> o <iframe>), y en su lugar debes usar componentes AMP específicos (<amp-img>, <amp-video>, <amp-iframe>). Esta restricción no es caprichosa: cada componente AMP está diseñado para optimizar el renderizado y garantizar un layout estable.
2. AMP JS: La biblioteca JavaScript de AMP es el cerebro de la operación. Se encarga de gestionar la carga de recursos de forma asíncrona y priorizada, asegurando que los elementos «above the fold» (visibles sin hacer scroll) se carguen primero. Además, implementa técnicas como el «lazy loading» (carga diferida) de forma nativa, algo que en páginas tradicionales requiere implementación manual.
3. AMP Cache: Aquí reside el verdadero superpoder de AMP. Google (y otros CDN como Bing y Cloudflare) mantienen cachés de páginas AMP que sirven el contenido directamente desde sus servidores, eliminando la latencia del servidor de origen. Cuando un usuario hace clic en un resultado AMP desde la búsqueda de Google, la página ya está pre-renderizada y se muestra instantáneamente.

Evolución histórica: del boom al cuestionamiento

Cuando Google lanzó AMP en octubre de 2015, lo hizo con un mensaje claro: la web móvil estaba demasiado lenta y necesitaba una solución radical. En ese momento, el tiempo promedio de carga de una página móvil superaba los 19 segundos, una eternidad en términos de experiencia de usuario.

La estrategia de Google fue audaz: vincular AMP con el codiciado carrusel de noticias (Top Stories) en los resultados de búsqueda móvil. Durante años, solo las páginas AMP podían aparecer en este carrusel, lo que efectivamente obligó a publishers y medios de comunicación a adoptar el formato si querían mantener su tráfico.

Esta decisión generó críticas feroces sobre monopolio y competencia desleal. Organizaciones de medios y reguladores europeos cuestionaron si Google estaba usando su posición dominante para imponer su tecnología. La controversia llegó a tal punto que, en 2021, Google eliminó el requisito de AMP para aparecer en Top Stories, abriendo este espacio a cualquier página que cumpliera con los estándares de Core Web Vitals.

En 2026, la postura oficial de Google es clara: AMP sigue siendo una forma válida y efectiva de crear páginas rápidas, pero ya no es obligatorio ni proporciona ventajas de ranking directas. La empresa ha pivotado su enfoque hacia métricas más universales (Core Web Vitals) que cualquier sitio puede alcanzar, independientemente de la tecnología utilizada.

La velocidad de AMP no es magia; es el resultado de restricciones arquitectónicas meticulosamente diseñadas que eliminan los principales cuellos de botella del renderizado web. Comprender estas restricciones es fundamental para cualquier profesional SEO que trabaje con AMP o esté considerando su implementación.

Restricciones de HTML: componentes específicos vs. etiquetas estándar

La primera regla de AMP es que no puedes usar HTML estándar para contenido multimedia. Cada elemento que tradicionalmente ralentiza una página tiene su equivalente en AMP:

• <img> → <amp-img>: El componente <amp-img> requiere que especifiques el ancho y alto de la imagen de antemano, permitiendo que el navegador reserve el espacio antes de que la imagen se descargue. Esto previene el Cumulative Layout Shift (CLS), uno de los Core Web Vitals más problemáticos.
• <video> → <amp-video>: Similar al caso de las imágenes, pero con capacidades adicionales como la carga diferida automática y la pausa cuando el video sale del viewport.
• <iframe> → <amp-iframe>: Los iframes son notorios consumidores de recursos. AMP los permite, pero con restricciones: deben estar al menos 600px por debajo del fold inicial o al 75% de la altura del viewport.
• <audio> → <amp-audio>: Gestiona la precarga de audio de forma optimizada.

Estas sustituciones no son negociables. Si intentas publicar una página AMP con etiquetas HTML prohibidas, fallará la validación y Google no la indexará como AMP (aunque sí como página HTML normal).

CSS en línea y el límite sagrado de 75KB

Una de las restricciones más controvertidas de AMP es su política de CSS. Todo el CSS debe estar en línea (dentro de una etiqueta <style amp-custom> en el <head>) y no puede superar los 75KB.

¿Por qué esta limitación draconiana? Para eliminar las solicitudes HTTP adicionales que ralentizan la carga. Cada archivo CSS externo requiere una solicitud al servidor, un proceso de negociación DNS, establecimiento de conexión TCP y, potencialmente, handshake SSL/TLS. Al forzar el CSS en línea, AMP garantiza que el navegador tenga todos los estilos necesarios desde la primera descarga del HTML.

El límite de 75KB puede parecer generoso, pero sitios con diseños complejos o múltiples plantillas a menudo luchan para cumplirlo. La solución típica implica CSS crítico y minificación agresiva, eliminando estilos no utilizados y optimizando selectores.

Además, AMP prohíbe el uso de !important en ciertos contextos y desaconseja selectores complejos que aumentan el tiempo de parsing. Estas restricciones fuerzan a los desarrolladores a escribir CSS más eficiente y mantenible.

JavaScript asíncrono: control total o nada

Si CSS en AMP es restrictivo, JavaScript es directamente draconiano: no puedes usar JavaScript personalizado excepto dentro de componentes específicos como <amp-script> (con limitaciones severas) o <amp-iframe> (que aísla el código).

Todo JavaScript en una página AMP debe ser asíncrono. La biblioteca AMP JS se carga así:

<script async src=»https://cdn.ampproject.org/v0.js»></script>

Esta restricción elimina el JavaScript bloqueante, uno de los mayores asesinos del rendimiento web. En páginas tradicionales, un script mal colocado puede paralizar completamente el renderizado mientras se descarga y ejecuta.

Para funcionalidades interactivas, AMP proporciona componentes pre-construidos que cubren la mayoría de casos de uso:

• <amp-accordion>: Para secciones expandibles.
• <amp-carousel>: Para galerías de imágenes.
• <amp-lightbox>: Para overlays modales.
• <amp-form>: Para formularios con validación.
• <amp-bind>: Para interactividad reactiva básica (similar a un mini-framework como Alpine.js).

Si necesitas funcionalidad personalizada más allá de estos componentes, debes usar <amp-script>, que ejecuta JavaScript en un Web Worker (fuera del hilo principal) y tiene limitaciones estrictas: máximo 150KB de código y restricciones en la manipulación del DOM.

Carga de recursos priorizada: el layout estático

Una de las innovaciones más inteligentes de AMP es su sistema de layout estático. Cuando defines un componente AMP como <amp-img>, debes especificar sus dimensiones o tipo de layout:

<amp-img src=»imagen.jpg»
width=»800″
height=»600″
layout=»responsive»>
</amp-img>

El navegador conoce el espacio exacto que ocupará cada elemento antes de descargarlo. Esto permite que AMP construya el layout completo de la página de inmediato, reservando espacios en blanco para contenido que aún no ha llegado. El resultado: CLS (Cumulative Layout Shift) prácticamente cero.

Además, AMP implementa un sistema de priorización de recursos sofisticado:

1. Prioridad máxima: Elementos «above the fold» (visibles sin scroll).
2. Prioridad media: Elementos «below the fold» pero cerca del viewport inicial.
3. Prioridad baja: Elementos fuera de pantalla que se cargan solo cuando el usuario hace scroll (lazy loading).

Este sistema es completamente automático, eliminando la necesidad de que los desarrolladores implementen manualmente técnicas como lazy loading o intersección observers.

Ningún tema en AMP genera más confusión que su relación con el SEO. Circulan mitos, medias verdades y malentendidos que pueden llevar a decisiones estratégicas equivocadas. Separemos los hechos de la ficción.

Mito: AMP es un factor de ranking directo

FALSO. John Mueller, Search Advocate de Google, lo ha aclarado múltiples veces: usar AMP no te dará un boost directo en el ranking. AMP no es como HTTPS (que sí es un pequeño factor de ranking confirmado).

Sin embargo, aquí viene el matiz importante: AMP ayuda indirectamente al SEO porque facilita cumplir con factores que sí importan:

• Velocidad de carga: Las páginas AMP cargan más rápido, lo que mejora la experiencia de usuario (un factor de ranking indirecto pero real).
• Core Web Vitals: AMP «aprueba» automáticamente los Core Web Vitals en la mayoría de casos, especialmente LCP (Largest Contentful Paint) y CLS (Cumulative Layout Shift).
• Tasa de rebote y tiempo de permanencia: Páginas más rápidas generalmente tienen mejor engagement, señales que Google considera.

La clave está en entender que AMP es una herramienta para alcanzar objetivos que sí importan para el SEO, no un objetivo en sí mismo.

AMP y Core Web Vitals: aprobado automático (casi siempre)

Cuando Google introdujo Page Experience como factor de ranking en 2021, estableció tres métricas principales (Core Web Vitals):

1. LCP (Largest Contentful Paint): Debe ocurrir en menos de 2.5 segundos.
2. FID (First Input Delay) / INP (Interaction to Next Paint): La respuesta a interacciones debe ser inferior a 100ms (FID) o 200ms (INP).
3. CLS (Cumulative Layout Shift): Debe ser inferior a 0.1.

Las páginas AMP típicamente pasan estos umbrales sin esfuerzo:

• LCP optimizado: Gracias a la priorización de recursos y la caché de Google, el contenido principal se renderiza casi instantáneamente.
• INP excelente: Con JavaScript limitado y asíncrono, las interacciones responden inmediatamente.
• CLS mínimo: El layout estático garantiza que no haya saltos inesperados en el contenido.

De hecho, un análisis de HTTP Archive reveló que más del 90% de las páginas AMP pasan los Core Web Vitals, comparado con aproximadamente el 40% de páginas web tradicionales.

Esto significa que si tu sitio lucha con Core Web Vitals, AMP puede ser un atajo efectivo para aprobar estos exámenes sin una reingeniería completa de tu stack tecnológico.

El carrusel de noticias: del requisito obligatorio a la democratización

Durante años, el carrusel de Top Stories (noticias destacadas) en Google móvil fue territorio exclusivo de AMP. Solo páginas AMP con markup de artículo estructurado podían aparecer en este codiciado espacio que genera clics masivos.

Esta política cambió radicalmente en 2021. Google eliminó el requisito de AMP para Top Stories, permitiendo que cualquier página con:

• Structured Data correcto (Article schema).
• Core Web Vitals aprobados.
• Cumplimiento de políticas de contenido de Google News.

pudiera competir por este espacio.

¿Qué significa esto para publishers? Que AMP ya no es obligatorio, pero sigue siendo una ruta más fácil para cumplir con los requisitos técnicos, especialmente para equipos con recursos limitados.

Los grandes medios con equipos de desarrollo robustos (The Guardian, The New York Times, etc.) han migrado fuera de AMP, optimizando sus sitios principales para Core Web Vitals. Pequeños y medianos publishers, sin embargo, siguen encontrando valor en AMP como solución «lista para usar».

El impacto de la caché de Google: arma de doble filo

Cuando un usuario hace clic en un resultado AMP desde Google, la página se sirve desde cdn.ampproject.org o google.com/amp/, no desde tu dominio. Esto tiene implicaciones profundas:

Ventajas:

• Velocidad extrema: El contenido ya está pre-renderizado en servidores de Google distribuidos globalmente.
• Ahorro de ancho de banda: Google absorbe el costo del tráfico.
• Resiliencia: Aunque tu servidor caiga, las páginas AMP seguirán disponibles desde la caché.

Desventajas:

• Pérdida de identidad de marca: La URL mostrada no es tu dominio completo.
• Limitaciones en analítica: Tracking más complejo (aunque solucionable con <amp-analytics>).
• Control limitado sobre el cacheado: Google decide cuándo invalidar y actualizar el caché.

Para sitios donde la marca y el dominio son críticos (eCommerce, SaaS, servicios profesionales), esta pérdida de identidad puede ser un factor decisivo contra AMP.

Implementar AMP no es simplemente añadir algunos componentes a tu HTML. Requiere una arquitectura dual bien pensada y validación continua para evitar errores que podrían excluir tus páginas del ecosistema AMP.

Versión canonical vs. AMP: la estrategia de doble implementación

La mayoría de sitios que usan AMP mantienen dos versiones de cada página: la versión normal (canonical) y la versión AMP. Ambas versiones deben estar correctamente vinculadas mediante etiquetas específicas:

En la página canonical (versión normal):

<link rel=»amphtml» href=»https://tusitio.com/articulo.amp.html»>

En la página AMP:

<link rel=»canonical» href=»https://tusitio.com/articulo.html»>

Esta vinculación es crítica por dos razones:

1. Evita contenido duplicado: Le dice a Google que ambas páginas son versiones de lo mismo, no contenido separado que competiría entre sí.
2. Permite la indexación selectiva: Google puede elegir mostrar la versión AMP en contextos móviles y la canonical en desktop.

Error común: Olvidar la etiqueta canonical en la página AMP, lo que puede causar que Google la considere contenido duplicado y penalice ambas versiones.

AMP «Bento»: el nuevo enfoque híbrido

En 2021, el proyecto AMP introdujo «Bento AMP», un cambio filosófico significativo. Bento permite usar componentes AMP individuales en páginas que no son completamente AMP.

Esto significa que puedes, por ejemplo, usar <amp-carousel> o <amp-lightbox> en tu sitio normal sin convertir toda la página a AMP. Los componentes funcionan como web components independientes.

Ventajas de Bento:

• Flexibilidad: Mantén el diseño y funcionalidades de tu sitio, pero aprovecha componentes AMP optimizados.
• Migración gradual: Puedes eliminar AMP progresivamente sin perder funcionalidad.
• Mejor para brands: Tu dominio siempre es visible; no se sirve desde la caché de Google.

Desventajas de Bento:

• Sin caché de Google: Pierdes la ventaja de velocidad extrema de la caché.
• Sin carrusel garantizado: Debes cumplir Core Web Vitals por otros medios.

Bento representa la visión futura de AMP: componentes web de alto rendimiento que cualquiera puede usar, no un ecosistema cerrado.

Herramientas de validación: tu arsenal de diagnóstico

Un código AMP inválido no se indexará correctamente en Google. La validación es un paso no negociable. Estas son las herramientas esenciales:

1. AMP Validator (Extensión de Chrome)

La forma más rápida de validar durante el desarrollo. La extensión muestra un icono que cambia de color:

• Verde: AMP válido.
• Rojo: Errores de validación.
• Gris: La página no es AMP.

Uso recomendado: Instálala y actívala durante el desarrollo para detectar errores en tiempo real.

2. AMP Test Tool (Web)

Disponible en validator.ampproject.org, esta herramienta web permite pegar una URL o código directamente para validación exhaustiva.

Ventaja clave: Proporciona mensajes de error detallados con números de línea exactos y sugerencias de corrección. Por ejemplo:

DISALLOWED_TAG: La etiqueta ‘script’ solo está permitida en ubicaciones específicas.Línea: 45, Columna: 3

3. Informe de AMP en Google Search Console

Una vez que tus páginas AMP están indexadas, Google Search Console proporciona un informe específico que muestra:

• Páginas AMP válidas indexadas.
• Páginas AMP con errores (y qué errores específicos).
• Tendencias de indexación a lo largo del tiempo.

Uso estratégico: Monitorea este informe semanalmente. Un aumento repentino en errores puede indicar un problema en tu sistema de generación de AMP (por ejemplo, si actualizaste una plantilla).

4. Prueba de resultados enriquecidos

Disponible en search.google.com/test/rich-results, esta herramienta valida que tu structured data (datos estructurados) sea correcto.

Para páginas AMP de noticias, debes implementar Article schema correctamente:

<script type=»application/ld+json»>
{
«@context»: «https://schema.org»,
«@type»: «NewsArticle»,
«headline»: «Título del artículo»,
«datePublished»: «2026-01-15T08:00:00+00:00»,
«dateModified»: «2026-01-15T09:30:00+00:00»,
«author»: {
«@type»: «Person»,
«name»: «Nombre del Autor»
},
«publisher»: {
«@type»: «Organization»,
«name»: «Tu Medio»,
«logo»: {
«@type»: «ImageObject»,
«url»: «https://tusitio.com/logo.png»
}
}
}
</script>

Sin structured data correcto, tu página AMP no aparecerá en Top Stories, incluso si técnicamente es válida.

Errores comunes de implementación y cómo evitarlos

Después de auditar cientos de implementaciones AMP, estos son los errores más frecuentes:

1. CSS que excede 75KB: Usa herramientas como PurgeCSS o UnCSS para eliminar estilos no utilizados. También considera dividir páginas complejas en múltiples tipos de plantillas AMP.
2. Imágenes sin dimensiones especificadas: Toda <amp-img> debe tener atributos width y height o un layout definido. Error de ejemplo:

<!– INCORRECTO –>
<amp-img src=»foto.jpg»></amp-img>

<!– CORRECTO –>
<amp-img src=»foto.jpg» width=»800″ height=»600″ layout=»responsive»></amp-img>

3. Scripts de terceros no permitidos: Muchos plugins de WordPress o sistemas CMS insertan automáticamente scripts de publicidad o analítica que rompen AMP. Usa <amp-ad> y <amp-analytics> en su lugar.
4. Olvidar la etiqueta canonical: Ambas páginas (AMP y normal) deben tener las etiquetas de vinculación correctas. Establece un sistema de verificación automática en tu proceso de publicación.
5. Fechas de publicación incorrectas en structured data: Google es estricto con esto. Si tu fecha de publicación es futura o muy antigua, la página podría no aparecer en Top Stories.

Ninguna tecnología es perfecta, y AMP viene con trade-offs significativos. Aquí está el análisis honesto que necesitas para tomar decisiones informadas.

Ventajas: por qué AMP sigue siendo relevante

1. Velocidad extrema sin esfuerzo técnico complejo

Para equipos pequeños o sitios con limitaciones técnicas, AMP es el camino más rápido hacia páginas ultrarrápidas. No necesitas ser un experto en optimización de rendimiento; las restricciones de AMP hacen el trabajo por ti.

Un estudio de caso típico: un blog de WordPress con plugins pesados puede tardar 5-8 segundos en cargar. Su versión AMP: menos de 1 segundo. Esa diferencia se traduce directamente en mejor experiencia de usuario y métricas de engagement.

2. Ahorro masivo de ancho de banda

Las páginas AMP son dramáticamente más ligeras que sus equivalentes normales. Un artículo con imágenes que pesa 3MB en versión normal puede pesar solo 300KB en AMP.

Para publishers con millones de páginas vistas mensuales, esto representa ahorro significativo en costos de hosting y CDN. Además, si tus páginas se sirven desde la caché de Google, el ahorro es aún mayor porque Google absorbe el costo del tráfico.

3. Infraestructura de caché global gratuita

La caché de Google proporciona distribución de contenido global de nivel empresarial sin costo. Para sitios internacionales, esto es equivalente a tener un CDN premium sin pagar por él.

Además, la caché mitiga picos de tráfico. Si tu artículo se vuelve viral, la caché de Google puede manejar millones de visitas sin afectar tu servidor original.

4. Core Web Vitals prácticamente garantizados

Si tu sitio principal lucha con Core Web Vitals (especialmente LCP y CLS), AMP es una solución probada. No necesitas reescribir tu frontend completo; implementas AMP en paralelo y obtienes páginas que pasan los umbrales de Google.

5. Ventaja competitiva en móvil

En dispositivos de gama baja o conexiones lentas (común en mercados emergentes), la diferencia entre una página normal y AMP es abismal. Si tu audiencia está en países con infraestructura móvil limitada, AMP puede ser la diferencia entre usuarios que abandonan y usuarios que permanecen.

Desventajas: por qué muchos están abandonando AMP

1. Limitaciones severas en diseño y UX

La restricción de CSS de 75KB y la prohibición de JavaScript personalizado son camisas de fuerza para diseños complejos. Interacciones sofisticadas, animaciones elaboradas o experiencias de usuario innovadoras son extremadamente difíciles o imposibles de implementar.

Para brands donde la identidad visual es crítica, AMP puede sentirse como renunciar a tu diferenciación. Sitios de moda, agencias creativas o eCommerce de lujo raramente pueden expresar su estética completamente en AMP.

2. Complejidad de mantenimiento: dos versiones, doble trabajo

Mantener versiones AMP y normales significa duplicar tu esfuerzo de desarrollo y QA. Cada nueva funcionalidad debe implementarse dos veces, cada bug puede manifestarse de forma diferente en cada versión.

Equipos pequeños pueden encontrarse atrapados en un ciclo donde dedican más tiempo a mantener AMP que a mejorar su producto principal.

3. Limitaciones en analítica y tracking

Aunque <amp-analytics> soporta la mayoría de plataformas principales (Google Analytics, Adobe Analytics, etc.), implementaciones personalizadas son complejas. Tracking de eventos avanzado, embudos de conversión personalizados o herramientas de heat mapping raramente funcionan igual de bien en AMP.

Para sitios orientados a conversión (SaaS, eCommerce, servicios), esta limitación puede ser un deal-breaker.

4. Pérdida de control sobre el dominio y cacheado

Ver google.com/amp/ en lugar de tu dominio en la barra de direcciones debilita el reconocimiento de marca. Para negocios donde la confianza y la autoridad de dominio son críticas, esto es problemático.

Además, no controlas cuándo Google actualiza su caché. Puedes solicitar actualizaciones mediante la API de actualización de caché de AMP, pero no tienes control absoluto como con tu propio CDN.

5. Fricción en conversión para eCommerce

Este es quizás el problema más crítico para tiendas online. La experiencia de checkout en AMP es inherentemente limitada. Integraciones complejas con pasarelas de pago, calculadoras dinámicas de envío o personalizadores de productos son extremadamente difíciles.

Estudios de caso de retailers que implementaron AMP mostraron que aunque el tráfico aumentó (más visitas desde búsquedas), la tasa de conversión disminuyó debido a la experiencia de compra limitada. El resultado neto puede ser negativo.

El veredicto: quién debería usar AMP en 2026

Después de analizar pros y contras, aquí está la guía práctica:

AMP sigue siendo una excelente opción para:

• Publishers y medios de comunicación que priorizan alcance y velocidad sobre diseño personalizado.
• Blogs y sitios de contenido sin necesidades de interactividad compleja.
• Equipos técnicos pequeños que necesitan velocidad sin inversión masiva en optimización.
• Sitios con audiencias en mercados con conectividad limitada.

AMP NO es recomendable para:

• Sitios de eCommerce donde la experiencia de compra es diferenciadora.
• Aplicaciones web interactivas o SaaS con funcionalidades complejas.
• Brands premium donde la estética y experiencia personalizada son críticas.
• Equipos con capacidad técnica para optimizar sitios normales y alcanzar Core Web Vitals.

Si tu sitio ya usa AMP, probablemente te enfrentas a esta pregunta: ¿deberíamos mantenerlo, eliminarlo o evolucionar a otra solución? No existe una respuesta universal, pero sí un framework para tomar la decisión correcta.

Cuándo mantener AMP: señales de que aún te sirve

Mantén AMP si:

1. Tus Core Web Vitals en páginas normales están lejos de los umbrales

Si has intentado optimizar tu sitio principal y sigues fallando en LCP, FID/INP o CLS, AMP puede seguir siendo tu mejor solución a corto plazo. Eliminar AMP sin mejorar tu sitio principal resultará en pérdida de tráfico.

Validación técnica: Usa PageSpeed Insights o Chrome User Experience Report para auditar tus páginas normales. Si más del 50% de tus URLs fallan Core Web Vitals, no es momento de eliminar AMP.

2. La mayoría de tu tráfico proviene del carrusel de Top Stories

Para publishers, Top Stories puede representar 40-60% del tráfico orgánico total. Si tu sitio normal no pasa Core Web Vitals, eliminar AMP significaría perder presencia en ese carrusel.

Análisis recomendado: En Google Search Console, filtra el tráfico por tipo de apariencia de búsqueda. Si «Top Stories» es una porción significativa y tus páginas normales no están listas, mantén AMP.

3. Tus recursos técnicos son limitados

Si tu equipo de desarrollo tiene 1-2 personas y están enfocadas en funcionalidad del producto, no en optimización de rendimiento, AMP sigue siendo tu atajo más eficiente.

El costo de oportunidad de migrar fuera de AMP (semanas de desarrollo en optimización) puede superar los beneficios.

4. Operas en mercados con conectividad limitada

Si tu audiencia principal está en regiones con redes móviles lentas (muchos países de América Latina, África, Asia del Sur), la ventaja de velocidad de AMP es más pronunciada que en mercados con 4G/5G ubicuo.

Dato a considerar: En conexiones 3G lentas, una página AMP puede ser la diferencia entre 2 segundos y 15 segundos de carga. En esos contextos, AMP aún proporciona valor real.

Cuándo eliminar AMP: señales de que es momento de evolucionar

Elimina AMP si:

1. Has optimizado tu sitio principal y pasas Core Web Vitals consistentemente

Si has invertido en optimización de rendimiento (lazy loading, CDN, optimización de imágenes, code splitting, etc.) y tus páginas normales aprueban Core Web Vitals en el 75º percentil de usuarios, AMP ya no aporta ventaja técnica.

Test decisivo: Compara el tráfico orgánico de páginas AMP vs. normales en Google Analytics. Si ambas tienen rendimiento similar en términos de CTR y tiempo de permanencia, AMP es redundante.

2. La experiencia de usuario limitada está afectando conversión

Si tus métricas de negocio (conversiones, ventas, leads) son significativamente peores en páginas AMP que en normales, estás sacrificando resultados por velocidad.

Análisis de embudo: Compara tasas de conversión de tráfico que llega a páginas AMP vs. normales. Una diferencia de más del 20% justifica eliminar AMP si puedes mantener la velocidad por otros medios.

3. Mantener dos versiones genera fricción significativa

Si tu equipo dedica más del 30% del tiempo de desarrollo a mantener, debuggear o adaptar funcionalidades para AMP, el costo de oportunidad es demasiado alto.

Señal clara: Si cada lanzamiento de funcionalidad nueva se retrasa porque «hay que hacerlo compatible con AMP», es momento de consolidar en una única versión optimizada.

4. La identidad de marca está siendo comprometida

Para brands donde la confianza y autoridad son críticas (servicios financieros, salud, legal), la URL de Google en lugar de tu dominio puede erosionar la percepción de legitimidad.

Esto es especialmente cierto en un entorno donde phishing y sitios fraudulentos son preocupación creciente. Los usuarios educados buscan señales de autenticidad, y tu dominio es una de ellas.

Guía paso a paso para una transición segura fuera de AMP

Si has decidido eliminar AMP, hacerlo incorrectamente puede causar caídas dramáticas en tráfico y ranking. Aquí está el proceso validado para minimizar riesgos:

Fase 1: Preparación y auditoría (Semanas 1-2)

1. Audita el rendimiento actual de tus páginas normales

Usa PageSpeed Insights en una muestra representativa (al menos 50-100 URLs) de tus páginas normales. Necesitas datos baseline de:

• Puntuación general de rendimiento.
• Core Web Vitals: LCP, INP, CLS.
• Métricas específicas: FCP, TBT, Speed Index.

Objetivo: Confirmar que tus páginas normales pueden competir con AMP en velocidad.

2. Optimiza las páginas normales si es necesario

Si tus páginas no pasan Core Web Vitals, debes optimizarlas ANTES de eliminar AMP. Prioriza:

• Optimización de imágenes: WebP, lazy loading, dimensiones correctas.
• Reducción de JavaScript: Code splitting, defer/async de scripts no críticos.
• CSS crítico: Inline del CSS critical path, defer del resto.
• CDN: Asegúrate de que todos los assets estáticos se sirven desde CDN con caching agresivo.

3. Implementa monitoreo avanzado

Configura Google Analytics 4 o tu plataforma de analítica para rastrear:

• Tráfico por tipo de página (AMP vs. normal).
• Core Web Vitals en campo real (usa eventos personalizados con Web Vitals library).
• Conversiones segmentadas por tipo de página.

También configura alertas en Google Search Console para errores de indexación y caídas de rendimiento.

Fase 2: Implementación de redirecciones (Semanas 3-4)

1. Configura redirecciones 301 de páginas AMP a normales

En tu servidor (Apache, Nginx, etc.), implementa redirecciones permanentes:

Nginx:

location ~* \.amp\.html$ {
rewrite ^(.*)\.amp\.html$ $1.html permanent;
}

Apache (.htaccess):

RewriteEngine On
RewriteRule ^(.*)\.amp\.html$ /$1.html [R=301,L]

Importante: Las redirecciones deben ser 301 (permanentes), no 302 (temporales). Google transfiere señales de ranking completas solo con 301.

2. Actualiza las etiquetas canonical y amphtml

Elimina las etiquetas <link rel=»amphtml»> de tus páginas normales. Si mantienes páginas AMP temporalmente (durante la transición gradual), las etiquetas canonical en AMP deben seguir apuntando a las páginas normales.

3. Solicita re-indexación en Google Search Console

Usa la herramienta de inspección de URLs para solicitar la re-indexación de tus páginas normales más importantes. No puedes solicitar re-indexación masiva, así que prioriza:

• Landing pages principales.
• Páginas de alto tráfico.
• Contenido reciente (últimos 3-6 meses).

Fase 3: Monitoreo intensivo (Semanas 5-8)

1. Rastrea métricas clave diariamente

Durante las primeras 4-6 semanas post-migración, monitorea obsesivamente:

• Tráfico orgánico total: Cualquier caída superior al 10% requiere investigación inmediata.
• Posiciones de ranking: Usa herramientas como SEMrush o Ahrefs para rastrear cambios en keywords principales.
• Errores de crawling: Revisa Google Search Console diariamente para errores 404 o problemas de indexación.
• Core Web Vitals: Confirma que tus páginas normales mantienen buenos scores en el mundo real (data de campo, no solo lab).

2. Ten un plan de rollback listo

Si observas caídas de tráfico superiores al 20% mantenidas por más de 2 semanas, considera temporalmente:

• Reactivar páginas AMP para tráfico crítico (ej: artículos top 10 de tráfico).
• Investigar qué específicamente causó la caída: ¿Core Web Vitals? ¿Pérdida de featured snippets? ¿Problemas técnicos?

3. Comunica cambios a stakeholders

Informa a tu equipo de marketing, dirección y cualquier stakeholder sobre:

• Expectativas realistas: Puede haber fluctuaciones temporales.
• Timeline: La transición completa tomará 2-3 meses.
• Métricas a vigilar: Define qué constituye éxito vs. señales de alarma.

Fase 4: Optimización post-migración (Meses 3-6)

1. Analiza el comportamiento del usuario

Compara métricas de engagement pre y post migración:

• Bounce rate: ¿Aumentó significativamente?
• Páginas por sesión: ¿Disminuyó?
• Tiempo en sitio: ¿Se mantuvo o mejoró?

Diferencias sustanciales indican problemas de UX o rendimiento que necesitan corrección.

2. Continúa optimizando Core Web Vitals

La migración fuera de AMP no es el final; es el comienzo de un compromiso continuo con el rendimiento. Implementa:

• Monitoreo de Real User Metrics (RUM).
• Presupuestos de rendimiento: Establece umbrales máximos de tamaño de página, número de requests, etc.
• Revisiones trimestrales de optimización.

3. Capitaliza nuevas capacidades

Ahora que no estás limitado por AMP, explota funcionalidades que antes eran imposibles:

• Interactividad avanzada: Personalización, recomendaciones dinámicas.
• Tracking y analítica sofisticados.
• Experiencias de usuario ricas: Animaciones, transiciones suaves.

El objetivo no es solo «mantener» lo que tenías con AMP, sino superar esa experiencia aprovechando la flexibilidad total de tu stack.

Alternativa: el enfoque híbrido con Bento AMP

Si no estás listo para eliminar AMP completamente pero quieres más flexibilidad, Bento AMP ofrece un camino intermedio:

Estrategia Bento:

1. Elimina páginas AMP completas.
2. Mantén componentes AMP específicos en tus páginas normales (ej: <amp-carousel>, <amp-lightbox>).
3. Optimiza tu sitio principal para Core Web Vitals usando técnicas tradicionales.

Ventajas:

• Más flexibilidad de diseño que AMP puro.
• Tu dominio siempre visible (no hay caché de Google).
• Componentes optimizados donde realmente agregan valor.

Desventaja clave: Sin caché de Google, pierdes el boost de velocidad extrema que eso proporcionaba.

Infografía: el viaje de un paquete de datos en AMP

Para visualizar cómo AMP logra su velocidad, comparemos el flujo de una página normal vs. una página AMP:

Página web tradicional:

1. Usuario hace clic en resultado de búsqueda.
2. DNS lookup del dominio → 20-50ms.
3. Conexión TCP establecida → 50-100ms.
4. Handshake SSL/TLS → 100-200ms.
5. Descarga del HTML → 200-500ms.
6. Parser encuentra CSS externo → nueva solicitud → 200-400ms.
7. Parser encuentra JavaScript → descarga y ejecución (bloquea rendering) → 500-2000ms.
8. Imágenes descargadas bajo demanda → 300-1000ms c/u.
9. Total: 3-5 segundos (en conexiones buenas).

Página AMP desde caché de Google:

1. Usuario hace clic en resultado de búsqueda.
2. Pre-renderizado: Google ya descargó y renderizó la página en background.
3. Transición instantánea desde la página de resultados.
4. Total: 0-300ms (percepción de instantaneidad).

Esta diferencia no es simplemente optimización; es un cambio arquitectónico fundamental donde el contenido se anticipa y pre-renderiza antes de que el usuario siquiera lo solicite.

Tabla comparativa: AMP vs. PWA vs. Responsive Design

Ninguna tecnología existe en vacío. AMP debe evaluarse contra alternativas para tomar decisiones informadas:

Criterio	AMP	PWA (Progressive Web App)	Responsive Design Optimizado
Velocidad inicial	⭐⭐⭐⭐⭐ (Instantánea desde caché)	⭐⭐⭐⭐ (Rápida en segunda visita)	⭐⭐⭐ (Depende de optimización)
Flexibilidad de diseño	⭐⭐ (Muy limitada)	⭐⭐⭐⭐⭐ (Total)	⭐⭐⭐⭐⭐ (Total)
Capacidades offline	❌ (No soportado)	⭐⭐⭐⭐⭐ (Excelente con Service Workers)	⭐ (Requiere implementación manual)
Experiencia de app	⭐ (Muy básica)	⭐⭐⭐⭐⭐ (Similar a app nativa)	⭐⭐⭐ (Depende de implementación)
Core Web Vitals	⭐⭐⭐⭐⭐ (Automático)	⭐⭐⭐⭐ (Alcanzable con esfuerzo)	⭐⭐⭐ (Requiere optimización continua)
Complejidad de desarrollo	⭐⭐⭐⭐ (Curva de aprendizaje moderada)	⭐⭐ (Alta complejidad inicial)	⭐⭐⭐⭐⭐ (Familiar para desarrolladores)
Costo de mantenimiento	⭐⭐ (Dos versiones)	⭐⭐⭐⭐ (Una versión)	⭐⭐⭐⭐⭐ (Una versión)
Soporte de analítica	⭐⭐⭐ (Funcional pero limitado)	⭐⭐⭐⭐⭐ (Completo)	⭐⭐⭐⭐⭐ (Completo)
SEO y crawling	⭐⭐⭐⭐⭐ (Excelente)	⭐⭐⭐⭐ (Bueno, mejorado con prerendering)	⭐⭐⭐⭐⭐ (Excelente si está optimizado)
Cacheo global	⭐⭐⭐⭐⭐ (Gratis con Google)	⭐⭐⭐ (Requiere CDN propio)	⭐⭐⭐ (Requiere CDN propio)

Interpretación:

• AMP gana en velocidad pura y simplicidad para alcanzar Core Web Vitals.
• PWA gana en experiencia de usuario rica y capacidades offline.
• Responsive Design optimizado gana en flexibilidad y costo de mantenimiento.

La elección óptima depende de tus prioridades: velocidad máxima vs. experiencia rica vs. simplicidad de mantenimiento.

Checklist de validación: 10 puntos críticos

Antes de lanzar o auditar páginas AMP, verifica estos 10 elementos esenciales:

1. ¿Todas las etiquetas HTML prohibidas han sido reemplazadas?

• [ ] No hay etiquetas <img>, solo <amp-img> con dimensiones.
• [ ] No hay <video> sin <amp-video>.
• [ ] No hay <iframe> sin <amp-iframe>.

2. ¿El CSS cumple las restricciones?

• [ ] Todo el CSS está en <style amp-custom>.
• [ ] El CSS no supera 75KB (verifica con herramientas de medición).
• [ ] No hay referencias a hojas de estilo externas (excepto fonts permitidos).

3. ¿Las etiquetas de vinculación son correctas?

• [ ] Página AMP tiene <link rel=»canonical»> apuntando a la versión normal.
• [ ] Página normal tiene <link rel=»amphtml»> apuntando a la versión AMP.

4. ¿El structured data está presente y válido?

• [ ] Schema.org implementado (preferentemente Article o NewsArticle).
• [ ] Fechas de publicación y modificación correctas.
• [ ] Información de autor y publisher completa.

5. ¿Todas las imágenes tienen tamaños y alternativas apropiadas?

• [ ] Atributos width y height presentes.
• [ ] Atributo alt con texto descriptivo (accesibilidad y SEO).
• [ ] Layout responsivo (layout=»responsive» o similar).

6. ¿Los componentes de terceros están correctamente implementados?

• [ ] Analítica usa <amp-analytics> con configuración correcta.
• [ ] Ads usan <amp-ad> con redes soportadas.
• [ ] Social sharing usa <amp-social-share>.

7. ¿La página pasa el AMP Validator?

• [ ] Validación en extensión de Chrome: ícono verde.
• [ ] Validación en validator.ampproject.org: sin errores.

8. ¿Google Search Console muestra la página como válida?

• [ ] Aparece en el informe de AMP sin errores.
• [ ] No hay advertencias críticas.

9. ¿La caché de Google se actualiza correctamente?

• [ ] Tested URL en google.com/amp/s/tusitio.com/pagina.
• [ ] Contenido es actual (no versión antigua cacheada).

10. ¿El rendimiento cumple expectativas?

• [ ] LCP < 2.5s (en PageSpeed Insights o Lighthouse).
• [ ] CLS < 0.1.
• [ ] INP < 200ms.

Si algún punto falla, detén el lanzamiento y corrige. Las páginas AMP inválidas no solo no obtendrán beneficios de AMP, sino que pueden generar confusión y duplicación de contenido.

Script de monitoreo: comparación AMP vs. No-AMP en GA4

Para tomar decisiones basadas en datos, necesitas comparar el rendimiento real de páginas AMP vs. normales. Este script de Google Analytics 4 te ayudará:

Configuración en Google Tag Manager:

1. Crea una variable personalizada de JavaScript:

function() {
var pageURL = {{Page Path}};
if (pageURL.includes(‘.amp’) || pageURL.includes(‘/amp/’)) {
return ‘AMP’;
} else {
return ‘Non-AMP’;
}
}

2. Envía esta variable como dimensión personalizada con cada pageview:

• Nombre de la dimensión: page_type
• Valor: La variable creada arriba

3. En GA4, crea una exploración comparativa:

• Dimensión primaria: page_type (AMP vs. Non-AMP)
• Métricas a comparar:
  • Sesiones
  • Tasa de rebote
  • Tiempo medio de permanencia
  • Conversiones (si aplica)
  • Páginas por sesión

4. Crea un informe de Core Web Vitals: GA4 captura automáticamente Core Web Vitals si implementas la biblioteca web-vitals. Compara:

• LCP por tipo de página
• CLS por tipo de página
• INP por tipo de página

Análisis recomendado:

• Si páginas AMP tienen 2x más sesiones pero 30% menos tiempo de permanencia, indica que AMP atrae más tráfico pero la experiencia es menos engaging.
• Si tasa de conversión es significativamente menor en AMP, el trade-off de velocidad por funcionalidad está perjudicando tu negocio.
• Si Core Web Vitals son similares entre AMP y No-AMP, AMP es redundante y puedes eliminarlo.

Hemos recorrido un viaje exhaustivo por el ecosistema AMP, desde su arquitectura técnica hasta decisiones estratégicas de implementación y migración. La conclusión fundamental es que AMP ya no es la única ruta hacia la velocidad, pero sigue siendo una ruta válida y eficiente para ciertos contextos.

AMP fue revolucionario en 2015 cuando la web móvil era dolorosamente lenta y las herramientas de optimización eran primitivas. Forzó a la industria a tomar la velocidad en serio y demostró que las páginas instantáneas eran posibles. Su legado incluye la adopción masiva de lazy loading, priorización de recursos y métricas de rendimiento centradas en el usuario.

Sin embargo, el ecosistema web ha evolucionado. Core Web Vitals proporcionan un marco universal para medir y optimizar velocidad. Tecnologías como HTTP/3, imagen WebP/AVIF, Service Workers y herramientas modernas de bundling (Vite, esbuild) permiten que sitios tradicionales alcancen niveles de rendimiento antes exclusivos de AMP.

La decisión de usar, mantener o eliminar AMP debe basarse en un análisis pragmático:

• Evalúa tu capacidad técnica actual: ¿Puedes optimizar tu sitio principal para Core Web Vitals?
• Considera tus restricciones de recursos: ¿Tienes un equipo capaz de mantener dos versiones?
• Prioriza tus objetivos de negocio: ¿Es la velocidad pura más importante que la experiencia de marca?
• Analiza tu audiencia: ¿Están en mercados con conectividad limitada donde AMP ofrece ventaja real?

No existe una respuesta única para todos. Publishers con recursos limitados pueden seguir beneficiándose enormemente de AMP. Grandes marcas con equipos de desarrollo robustos probablemente obtendrán mejores resultados optimizando su sitio principal y conservando total control sobre su experiencia de usuario.

Lo importante es tomar una decisión informada basada en datos, no en modas tecnológicas o presiones externas. Monitorea tus métricas, entiende las implicaciones técnicas y estratégicas, y elige el camino que mejor sirva a tus usuarios y objetivos de negocio.

AMP no está muerto, pero tampoco es obligatorio. Es una herramienta más en el arsenal del SEO técnico moderno, una herramienta poderosa cuando se usa en el contexto correcto, pero no una solución universal para todos los problemas de velocidad web.