¿Se recomienda usar páginas AMP en 2026? Accesibilidad, usabilidad y SEO

En pocas palabras: no, no conviene adoptar AMP en 2026 (salvo para casos muy concretos). Las ventajas que ofrecía cuando se lanzó se han reemplazado por prácticas nativas y, en muchos casos, AMP complica la accesibilidad y la usabilidad frente a una implementación bien hecha con HTML semántico y adaptable.

¿Cuando y para qué funcionó AMP?

En 2015 ya teníamos smartphones en los bolsillos y 4G era una realidad, teníamos auténtica banda ancha en la palma de la mano. Sin embargo, aún nos costaba poder visualizar bien webs en nuestros dispositivos móviles. AMP (Accelerated Mobile Pages) se lanzó en 2015 como un formato que obligaba a páginas a respetar un conjunto de reglas (HTML limitado, componentes específicos y una optimización) para conseguir cargas extremadamente rápidas en el móvil.

En su momento fue atractivo para medios editoriales y plataformas de contenido porque reducía fricción técnica para ofrecer páginas rápidas sin cambios profundos en infraestructura. Eso si, suponía el desarrollo de dos versiones de sus webs en paralelo (AMP + canonical), lo cual supone costes y fricciones de mantenimiento

El LCP (Largest Contentful Paint), un indicador importante de que la web ya está completamente cargada, se reducía drásticamente en página AMP. Lo cual daba una vía rápida para que medios con menos ingeniería ofrecieran páginas móviles “instantáneas”. Además, esto los crawlers de los buscadores como Google lo valoraban muy positivamente, con lo que los medios que aportaban versiones AMP de sus contenidos se colocaban en primeras posiciones en buscadores.

Con el tiempo los navegadores y la web evolucionaron (mejoras en HTTP/2 y HTTP/3, optimización de imágenes, lazy-loading nativo, Service Workers), y Google pasó a priorizar métricas de experiencia (Core Web Vitals) y señales de comportamiento por encima del formato AMP en sí.

¿Es AMP accesible?

AMP impone componentes y restricciones, limitando el uso directo de elementos HTML semánticos y patrones accesibles; complicando la correcta implementación de roles, estados ARIA y estructuras que facilitan la navegación por teclado.

Algunos behaviors (por ejemplo, modales o widgets complejos) requieren soluciones alternativas en AMP que pueden fallar en la gestión del foco o en el orden tabular, incrementando el riesgo de incumplir WCAG.

El runtime y los componentes AMP a veces introducen diferencias en el árbol DOM que requieren auditoría específica para detectar problemas de accesibilidad.

En suma, AMP no facilita la accesibilidad por defecto (lo cual me parece una oportunidad perdida), y en proyectos donde no se audita, suele empeorarla frente a HTML puro bien construido.

¿Es AMP usable?

AMP ofrecía una carga inicial muy rápida, pero a costa de restricciones en la personalización UX (microinteracciones, animaciones, formularios complejos). Eso puede afectar la experiencia de usuario en flujos críticos (por ejemplo, formularios, pagos, comentarios).

Cuando los sitios mantenían una versión AMP y otra “normal”, era común encontrar inconsistencias de características (botones ausentes, formularios simplificados), lo que genera confusión, frustración e impacta en las conversiones.

Integrar librerías JS complejas o microfrontends es más difícil en AMP, limitando la capacidad de hacerlo más cómodo de usar. El objetivo de AMP era mostrar información, no sitios web complejos.

¿Es AMP una herramienta de SEO?

Como hemos visto, en los sus primeros años AMP ayudó a muchos publishers a mejorar métricas móviles y acceder a ubicaciones privilegiadas en buscadores/agrupadores de noticias.

Sin embargo, los motores de búsquda han dejado de usar AMP como criterio exclusivo; hoy pesan la calidad del contenido, señales de experiencia (Core Web Vitals), estructuras de datos y relevancia semántica. Mantener AMP no aporta una ventaja SEO y puede introducir problemas que jueguen en contra (contenido duplicado / canonicals o incoherencias en datos estructurados).

Para SEO (y mantenimiento) mejor un sitio con contenido único, bien marcado y que optimize métricas SEO. Tendrá mejor resultado que otro que dependa sólo del formato AMP.

¿Qué es mejor que AMP actualmente?

Una sola fuente de verdad: evita versiones separadas; construye páginas únicas y bien optimizadas que sirvan a todos los dispositivos.

HTML semántico y accesibilidad desde el diseño: prioriza etiquetas correctas, roles ARIA solo cuando hacen falta, gestión de foco, órdenes tabulares lógicos y pruebas con lectores de pantalla. Datos estructurados con JSON‑LD: artículos, eventos, productos y FAQ para que buscadores lean y muestren rich snippets sin depender de AMP.

Optimización para Core Web Vitals: optimiza LCP (imágenes, lazy-loading, preloading, critical CSS), minimiza CLS (dimensiones reservadas, evitar inyectar contenido sin espacio), mejora INP/TTI (bootstrap ligero, dividir código). Imágenes modernas y responsive: AVIF/WebP, srcset, sizes, lazy-loading nativo. SSR/Edge rendering y CDNs: entrega HTML inicial desde el servidor o en el edge (Next.js, SvelteKit, Cloudflare Workers, Vercel) para mejorar TTFB y LCP sin necesidad de AMP.

PWA y Service Worker: reproduce ventajas de velocidad percibida de AMP (carga instantánea en visitas repetidas, offline, navegación rápida) manteniendo control total sobre la UX y accesibilidad

Pero ¿hay casos en los que considerar AMP?

Aunque en general es una mala idea, tanto para nuevos proyectos como para evolucionar existentes, hay casos muy concretos en los que considerarlo:

• El partner de distribución exige AMP.
• Proyectos con tráfico masivo de dispositivos muy antiguos (optimizados para el runtime AMP).
• Plataformas de terceros antiguas que ya tienen desarrollos que integran AMP, y donde no se pueden hacer cambios o el coste de hacerlos es superior a desarrollar una solución AMP.

Pero hay que tener en cuenta:

• Coste de ingeniería real: si tu organización no puede invertir en optimización nativa y , puede ser una solución temporal; pero siempre auditada.
• Requisitos de ecosistemas concretos: algunos agregadores o plataformas de terceros aún pueden integrar mejor versiones AMP, así que evalúa caso por caso.

En lugar de mantener /articulo/slug (HTML) y /amp/articulo/slug (AMP), crea una sola /articulo/slug que:

• entregue HTML semántico desde el servidor (SSR/Edge),
• inserte JSON‑LD de Article, author y publishDate,
• use imágenes responsive y preloads para la hero image,
• reserve el espacio de imágenes y anuncios para evitar CLS,
• cargue interacciones no críticas de forma asíncrona y registre métricas con la API de Performance.

AMP tuvo su momento y solucionó un problema real en el breve periodo entre 2015–2022, pero hoy ya no es la respuesta general; mejor invertir en rendimiento y accesibilidad nativos que te den control y menores costes de mantenimiento.