¿Qué es AMP (Accelerated Mobile Pages)?

Las siglas corresponden a Accelerated Mobile Pages. El proyecto nació en octubre de 2015, cuando las páginas de noticias tardaban varios segundos en abrirse en el móvil y algunas plataformas ofrecían formatos cerrados como alternativa al navegador.

No se trata de un lenguaje nuevo. Una página AMP sigue siendo HTML, pero un HTML con reglas estrictas. El JavaScript propio está prohibido, el CSS va en línea y con un límite de tamaño, y las imágenes, los vídeos o los anuncios se declaran mediante componentes del propio framework en lugar de las etiquetas habituales. Un validador comprueba si el documento cumple esas reglas, y solo las páginas válidas obtienen sus ventajas.

Conviene separar tres cosas que suelen mezclarse bajo la misma palabra. La primera es el formato, un estándar abierto que cualquiera puede servir desde su propio servidor. La segunda es la caché de Google, la infraestructura que copia y entrega páginas AMP válidas desde su propio dominio. La tercera es el trato preferente que la Búsqueda daba a esas páginas, el verdadero motivo por el que los editores adoptaron el formato. Las tres han seguido caminos distintos, y por eso la pregunta sobre AMP ya no tiene una respuesta única.

La velocidad de AMP no procede de un truco de compresión, sino de lo que el formato prohíbe. Sin scripts de terceros durante la carga, el navegador no espera a código desconocido antes de pintar la página. Las dimensiones de imágenes y anuncios se declaran de antemano, de modo que el diseño no salta mientras llegan los recursos.

A ese diseño se sumaba la caché. Cuando una página AMP es válida, la infraestructura de Google puede copiarla, optimizarla y entregarla desde cdn.ampproject.org, además de precargarla: mientras el usuario recorre los resultados, el documento ya está descargado. De ahí venía la sensación de apertura instantánea que hizo famoso al formato, y también las direcciones con aspecto de google.com/amp que sustituían al dominio del editor en la barra del navegador. La documentación actual de la Búsqueda indica que la URL de tu página AMP es visible para el usuario al abrirla, como en cualquier otro resultado.

El precio de esa velocidad son las restricciones. Los formularios, los muros de pago, la personalización y buena parte de los sistemas publicitarios necesitan componentes específicos o rodeos. Mantener una versión AMP junto a la normal significa además dos plantillas, con el riesgo de que un cambio se aplique solo en una de ellas. Ese coste pesa hoy más que hace diez años, porque un HTML bien construido alcanza cifras de carga parecidas con carga diferida, prioridades de recursos y un CDN.

En abril de 2021, Google anunció que usar el formato AMP dejaba de ser un requisito y que cualquier página sería elegible para el carrusel de Top Stories. El cambio llegó con la actualización de experiencia de página, desplegada entre mediados de junio y finales de agosto de 2021, y en el mismo movimiento desapareció el icono del rayo que identificaba los resultados AMP. Con ello se fue el argumento que sostenía la adopción del formato en los medios.

La documentación actual de Google Search Central es explícita en el otro punto: las páginas AMP se indexan igual que cualquier otra página y se les aplica el mismo criterio, con independencia de la tecnología con la que estén hechas. El formato no aporta por sí mismo ninguna ventaja de posicionamiento.

Como software, el proyecto sigue en marcha. Está alojado en la OpenJS Foundation y su repositorio ha publicado versiones a lo largo de 2026, la última estable con fecha del 15 de julio de 2026. Lo que cambió no fue el mantenimiento, sino el incentivo. Para un sitio nuevo ya no existe la razón que justificaba adoptar AMP. Para un sitio que ya lo usa y funciona, tampoco hay una fecha de apagado que obligue a correr.

• Mide antes de tocar nada. Exporta de Search Console y de tu analítica las impresiones, los clics y las conversiones de las URLs AMP de los últimos doce meses. Sin esa base no podrás demostrar después si el cambio ayudó o perjudicó.
• Comprueba qué versión indexa Google. Si la canónica es la página normal y AMP es solo la variante enlazada con rel=amphtml, retirarla es una limpieza. Si tus páginas AMP son autocanónicas o la única versión existente, estás ante una migración.
• Compara el rendimiento real de ambas versiones con datos de campo en móvil (LCP, INP y CLS). Si tu HTML normal ya cumple los umbrales, el argumento técnico para conservar AMP desaparece.
• Si decides retirarlo, redirige cada URL AMP a su equivalente con un 301 uno a uno, nunca a la portada, elimina la etiqueta rel=amphtml y actualiza el sitemap. Deja esas redirecciones activas de forma permanente, porque hay enlaces externos que apuntan a la variante AMP.
• Hazlo por fases. Retira primero una sección, espera de cuatro a seis semanas, vigila la cobertura en Search Console y compara con la base que mediste. Si nada empeora, continúa con el resto.
• Si decides mantenerlo, trátalo como código en producción. Valida las páginas de forma periódica, comprueba que el contenido no se desincroniza de la versión canónica y verifica que el consentimiento de cookies y la analítica funcionan igual en ambas.

• Borrar las URLs AMP sin redirección. Se convierten en errores 404 y arrastran consigo los enlaces externos que apuntaban a esa variante.
• Redirigir todas las páginas AMP a la portada. Google tiende a tratar esas redirecciones como soft 404 y el usuario que venía de un artículo concreto aterriza en un sitio que no pidió.
• Dejar la etiqueta rel=amphtml apuntando a páginas ya retiradas. El resultado son avisos en Search Console y señales contradictorias sobre qué versión rastrear.
• Dar por hecho que AMP sigue dando ventaja de posicionamiento y aplazar por ese motivo las mejoras de rendimiento en la versión principal, que es la que se evalúa.
• Publicar cambios solo en una de las dos versiones. Con el tiempo aparecen dos textos distintos, con precios o avisos legales desactualizados en la variante olvidada.