¿Está muerto Google AMP en 2026? Para SEO sí, y qué usar en su lugar

¿Está muerto AMP? Como táctica SEO, sí. La Búsqueda de Google indexa las páginas AMP como cualquier otra, Top Stories dejó de exigir AMP en junio de 2021 y, el 1 de julio de 2026, Google dejó de servir resultados AMP desde su propia caché. El framework no está muerto: el proyecto amphtml sigue publicando versiones y AMP para correo funciona en Gmail. Tanto si tu sitio usa WordPress como Shopify o código propio, ya no hay un motivo de búsqueda para crear o mantener páginas AMP.

En este análisis explicamos qué era el framework por dentro, por qué perdió su lugar en la búsqueda, cómo eliminarlo sin perder posiciones y qué usar en su lugar en cualquier plataforma.

#¿Sigue siendo relevante AMP en 2026?

No para la búsqueda. La documentación de Google dice hoy que la Búsqueda indexa las páginas AMP igual que otras páginas web y aplica el mismo estándar a todas, sea cual sea la tecnología con la que se construyó la página (About AMP on Google Search, actualizada el 1 de julio de 2026, traducción propia). Una página AMP no recibe impulso de ranking ni insignia, y desde julio de 2026 tampoco carga al instante desde la caché de Google.

Si tu sitio usa AMP hoy, la única pregunta relevante es cómo retirarlo de forma segura. Si estás construyendo un sitio nuevo, en WordPress, Shopify o un desarrollo a medida, sáltate AMP y céntrate en la pila de rendimiento que se describe más abajo.

#¿Están muertas las páginas AMP?

Las páginas AMP siguen funcionando y se siguen indexando. Lo que desapareció son los incentivos:

• Sin ventaja de ranking. Google aplica el mismo estándar a páginas AMP y no AMP.
• Sin requisito de Top Stories. Desde 2021 cualquier contenido que cumpla las políticas de Google Noticias puede aparecer.
• Sin carga instantánea desde la caché. Desde el 1 de julio de 2026, un clic en un resultado AMP aterriza en tu propia URL AMP, así que la página AMP es tan rápida como tu servidor.
• Un plugin en modo mantenimiento. El plugin oficial de AMP para WordPress no publica una versión desde abril de 2025.

#¿Google AMP sigue soportado en 2026?

Sí, formalmente. Google mantiene la documentación de AMP, la herramienta de prueba de AMP y el informe de estado de AMP en Search Console. Lo que cambió en julio de 2026 es cómo entrega los resultados AMP: ya no usa el visor AMP, la caché AMP ni los signed exchanges, así que los editores ya no tienen que actualizar la caché ni configurar signed exchanges. El proyecto amphtml también sigue vivo, con tres versiones publicadas en agosto de 2026.

Para cualquier propietario de un sitio, sea cual sea la plataforma, el estado práctico es el mismo: retira AMP, redirige las URL AMP e invierte el esfuerzo en la velocidad de tus páginas canónicas.

#Qué es AMP y cómo funcionaba

AMP nunca fue un lenguaje aparte. Era un perfil restringido de HTML con tres piezas que trabajaban juntas, y entender esas piezas explica por qué el proyecto terminó donde terminó.

AMP HTML. Un subconjunto seleccionado de etiquetas. No podías escribir tu propio <script>. Los elementos estándar se sustituían por componentes AMP: <img> pasaba a <amp-img>, los iframes a <amp-iframe>, la analítica a <amp-analytics>, los carruseles a <amp-carousel>, y el comportamiento dinámico se expresaba de forma declarativa con <amp-bind> y <amp-list> en lugar de código imperativo. El CSS en línea estaba permitido pero limitado por un presupuesto estricto (50 KB en la especificación original, elevado después a 75 KB), y las hojas de estilo externas estaban prohibidas.

El runtime de AMP (v0.js). Cada página AMP cargaba una única librería alojada por Google. Gestionaba la carga de recursos, dimensionaba cada elemento antes de pintarlo para evitar desplazamientos de layout y aplazaba todo lo que estaba por debajo del pliegue. Como el runtime controlaba el pipeline de renderizado, las páginas AMP se comportaban de manera predecible. Esa previsibilidad era todo el argumento de venta.

La caché de AMP y el prerenderizado. Esta es la pieza que casi todos olvidan. Google no solo posicionaba las páginas AMP: las copiaba a su propia CDN (cdn.ampproject.org) y las prerenderizaba dentro de los resultados de búsqueda antes de que tocaras el enlace. Por eso un resultado AMP se sentía instantáneo: los bytes ya estaban en el edge de Google y parcialmente pintados fuera de pantalla. La sensación de inmediatez nunca fue solo el formato, sino el formato más el prefetch de Google desde su propia infraestructura. Ese trato, velocidad a cambio de entregar tus páginas a Google, es la semilla de todo lo que salió mal.

#Por qué AMP mostraba una URL de Google y qué cambió SXG

Como las páginas se servían desde la caché de Google, el usuario veía una dirección google.com/amp/... en la barra, no tu dominio. Compartir, copiar y hasta el reconocimiento básico de marca se rompían. Google entendió el daño y dedicó años a un parche: los Signed HTTP Exchanges (SXG), parte del esfuerzo Web Packaging, que permitían a la caché servir una copia firmada criptográficamente mientras mostraba la URL real del editor. SXG funcionaba, pero era complejo, tenía poco soporte fuera de Chrome y llegó cuando muchos editores ya habían perdido la paciencia. El 1 de julio de 2026 Google retiró de la documentación de la Búsqueda el visor AMP, la caché AMP y los signed exchanges, porque la Búsqueda enlaza ahora directamente al servidor AMP del editor. El problema de la URL terminó cuando Google salió de la entrega.

#Por qué fracasó Google AMP

El objetivo era la velocidad. La solución fue prohibir JavaScript. Ese planteamiento resolvió un problema real de 2015 y creó varios nuevos.

#Cuáles eran las desventajas de AMP

El coste fue alto:

1. Dilución de marca: google.com/amp/tudominio.com. Compartir, copiar y el reconocimiento de marca se rompían al servirse desde la caché de Google.
2. Asesino de conversiones: sin formularios complejos ni flujos de pago personalizados. Los formularios de captación en varios pasos, los precios dinámicos, los checkouts protegidos y los widgets de reserva de terceros o no funcionaban o exigían reescrituras frágiles específicas de AMP.
3. Pesadilla de mantenimiento: dos versiones de cada plantilla, dos rutas de código, dos tandas de errores y dos QA por cada cambio.

#AMP y la demanda antimonopolio contra Google

Con el tiempo, AMP pareció menos un proyecto de rendimiento y más una palanca. Una demanda antimonopolio ampliada, liderada por una coalición de fiscales generales estatales de Estados Unidos, alegó que Google usó AMP para favorecer su propio intercambio de anuncios y frenar los formatos rivales. Al margen de su recorrido judicial, la percepción caló: un formato vendido como estándar abierto de velocidad tenía en realidad un único guardián, el mismo que controlaba la caché y buena parte de los ingresos publicitarios.

#Cómo Core Web Vitals sustituyó a AMP

Google anunció Core Web Vitals (CWV) en 2020 y los incorporó al ranking con la actualización de experiencia de página de junio de 2021. La misma actualización abrió Top Stories a todo el contenido de noticias que cumpla las políticas de Google Noticias, con AMP o sin él e independientemente de su puntuación de Core Web Vitals, y retiró la insignia AMP.

Así AMP perdió su razón de ser en la búsqueda. Una página responsive estándar que supera los umbrales (LCP por debajo de 2,5 s, INP por debajo de 200 ms, CLS por debajo de 0,1) se mide igual que una página AMP, sin ninguna de las restricciones. Google aclara que no existe una única señal de experiencia de página y que unos buenos Core Web Vitals no garantizan las primeras posiciones.

#Cronología de AMP de 2016 a 2026

#Por qué los medios dejaron de usar AMP

El éxodo de los editores no fue una protesta coordinada, sino la suma lenta de pequeñas derrotas. Un equipo de un medio descubría que su artículo AMP no podía mostrar el mismo banner de consentimiento que el sitio principal, así que el cumplimiento de la normativa de cookies exigía una segunda implementación. En España eso significaba adaptar el aviso a la guía de la AEPD dos veces, una para la versión canónica y otra para AMP. El equipo de publicidad comprobaba que un formato de anuncio exclusivo de AMP rendía menos que su stack habitual. La analítica llegaba a través de <amp-analytics> con un hilado de sesiones ligeramente distinto, de modo que las cifras nunca cuadraban con el sitio canónico y cada informe trimestral necesitaba una nota al pie. El equipo de diseño pedía una función interactiva que los componentes AMP no soportaban, y la respuesta siempre era la misma: en AMP no. Cada fricción era soportable por separado. Juntas significaban mantener un producto paralelo completo solo para conservar una insignia que Google acabó retirando.

#Cómo quitar AMP de WordPress sin perder posiciones

Si tu sitio sigue con AMP, cargas con todos sus costes y ninguno de sus antiguos beneficios. Los ejemplos usan WordPress porque el plugin oficial es la fuente más común de páginas AMP, pero el orden es el mismo en Drupal, en un CMS propio o en una tienda Shopify que añadió AMP con una app. La retirada es sencilla, pero los pasos de redirección y canónicas son donde los sitios pierden posiciones si se precipitan. Hazlo en orden.

#Paso 1: mide el tráfico AMP que realmente tienes

Antes de tocar nada, abre tu analítica y Search Console y cuantifica cuántas sesiones e impresiones siguen llegando a URLs /amp/. Exporta la lista de URLs AMP que aún reciben impresiones para redirigir las rutas correctas y vigilar regresiones después.

#Paso 2: asegúrate primero de que las canónicas son rápidas

No retires AMP mientras tu plantilla estándar sea lenta, o cambiarás una página rápida-pero-restringida por una lenta-y-libre. Pasa tus plantillas canónicas principales por PageSpeed Insights y confirma que superan Core Web Vitals en móvil. Arregla la plantilla primero y retira AMP después. El orden importa.

#Paso 3: redirige cada URL AMP

Las URLs de AMP como /nombre-post/amp/ deben redirigirse a la canónica (redirección 301). Cubre los dos formatos que genera AMP: las de ruta se resuelven con una regla de reescritura en el servidor, y las de parámetro de consulta conviene tratarlas en PHP para no dejar cabos sueltos. Redirigir solo las de ruta y olvidar las de parámetro deja URLs indexadas devolviendo 404 durante semanas, que es el mayor riesgo SEO de todo el proceso.

Regla Nginx:

rewrite ^/(.*)/amp/?$ /$1/ permanent;

Regla Apache (.htaccess):

RewriteEngine On
RewriteRule ^(.+)/amp/?$ /$1/ [R=301,L]

WordPress (functions.php), para las URL de parámetro ?amp=1:

function wppoland_redirigir_amp() {
    if ( isset( $_GET['amp'] ) ) {
        wp_safe_redirect( remove_query_arg( 'amp' ), 301 );
        exit;
    }
}
add_action( 'template_redirect', 'wppoland_redirigir_amp' );

#Paso 4: repara las canónicas y los sitemaps

Con AMP activo, tus páginas estándar solían apuntar su rel="canonical" a la versión AMP, o la versión AMP se autocanonizaba. Cada página debe llevar ahora una canónica autorreferenciada a su URL limpia. Yoast y Rank Math lo gestionan automáticamente una vez retirado AMP, pero verifica una muestra a mano. Regenera el sitemap XML para que ya no anuncie URLs de AMP.

#Paso 5: actualiza y monitoriza en Search Console

Solicita una nueva indexación de las páginas afectadas y vigila el informe de páginas durante las siguientes semanas:

• Comprueba errores 404 en las antiguas URLs AMP
• Verifica que las redirecciones funcionan con Screaming Frog o similar
• Monitoriza Core Web Vitals y el tráfico orgánico durante al menos 30 días
• Cuando el informe de estado de AMP en Search Console deje de mostrar páginas, la migración ha terminado

#Lista de comprobación antes de quitar AMP

Antes de tocar nada, responde con honestidad:

• ¿Tus plantillas canónicas ya pasan LCP, INP y CLS en móvil con datos de campo? Si no, arregla la plantilla primero.
• ¿Tienes inventariadas todas las URL /amp/ que aún reciben impresiones? Expórtalas antes de desactivar el plugin.
• ¿Tus redirecciones 301 cubren tanto las URL de ruta (/entrada/amp/) como las de parámetro (?amp=1)?
• ¿Cada página canónica apunta su rel="canonical" a sí misma y no a la antigua versión AMP?
• ¿Has regenerado el sitemap para que ya no anuncie URL de AMP?

Si respondes que sí a las cinco, la retirada es una limpieza segura, no un riesgo de posicionamiento.

#Qué usar en lugar de AMP en 2026

No necesitas AMP para ser rápido. Retirar AMP solo ayuda si el sitio nativo es genuinamente rápido, porque AMP imponía buenos hábitos por decreto y ahora tienes que elegirlos. En lugar de un framework propietario, Google mide el rendimiento real con tres métricas y algunas piezas de infraestructura.

#Hosting y tiempo hasta el primer byte

Todo lo demás se apoya en el tiempo de respuesta del servidor. Un hosting compartido que responde la primera petición en 800 ms ya ha gastado la mayor parte del presupuesto de LCP antes de que un solo byte de tu HTML optimizado llegue al navegador. Pon el origen en un hosting que devuelva un documento cacheado en bastante menos de 200 ms, y confírmalo bajo carga real, no en un staging inactivo. AMP escondía el hosting lento detrás de la caché de Google; cuando sirves tus propias páginas, el servidor vuelve a quedar expuesto.

#LCP (Largest Contentful Paint)

Mide cuanto tarda en renderizarse el elemento más grande visible. Objetivo: menos de 2.5 segundos.

• Precarga la imagen hero con <link rel="preload">
• Usa formatos modernos (AVIF con respaldo WebP)
• Implementa un CDN para servir assets globalmente
• Optimiza el TTFB con caché de servidor

#INP (Interaction to Next Paint)

Reemplazo de FID en marzo de 2024. Mide la latencia de las interacciones del usuario. Objetivo: menos de 200 ms.

• Minimiza el JavaScript del hilo principal
• Usa defer y async para scripts no críticos, y requestIdleCallback para el trabajo diferible
• Implementa Web Workers para tareas pesadas
• Elimina plugins innecesarios que bloquean la renderización

#CLS (Cumulative Layout Shift)

Mide la estabilidad visual de la página. Objetivo: menos de 0.1.

• Define dimensiones explícitas para imágenes y videos
• Usa aspect-ratio en CSS para contenedores multimedia
• Precarga fuentes web con font-display: swap
• Reserva espacio para anuncios y embeds dinámicos

#Imágenes en AVIF

AVIF suele generar archivos más pequeños que WebP con una calidad visual equivalente. Todo sitio WordPress en 2026 debería servir AVIF con respaldo WebP y JPEG.

<picture>
  <source srcset="imagen.avif" type="image/avif">
  <source srcset="imagen.webp" type="image/webp">
  <img src="imagen.jpg" alt="Descripción" loading="lazy">
</picture>

#Caché y CDN

No necesitas la caché de AMP de Google: necesitas tu propia caché en el borde. La caché de página completa servida desde un CDN cercano al usuario (Cloudflare, Fastly, Bunny.net, o el CDN integrado en Shopify) reproduce casi toda la ventaja de velocidad de AMP sin ceder la URL. Desde julio de 2026 incluso las páginas AMP salen de tu propio servidor, así que esta capa importa mantengas AMP o no. Añade caché de objetos (Redis o Memcached) por detrás para que las peticiones dinámicas y de usuarios logueados sigan siendo rápidas.

#CSS crítico y fuentes

Inserta en línea el CSS necesario para el contenido above-the-fold y aplaza el resto para que el primer pintado no se bloquee con la hoja de estilos completa. Precarga las fuentes del hero, usa font-display: swap y subconjunta las fuentes a los caracteres que realmente usas. WP Rocket y FlyingPress lo hacen automáticamente.

#Plugins recomendados para rendimiento en 2026

• WP Rocket: caché de página, CSS crítico, defer de JS
• Perfmatters: desactivar scripts innecesarios por página
• ShortPixel / Imagify: conversión automática a AVIF/WebP
• FlyingPress: alternativa ligera a WP Rocket

#Speculation Rules para navegación instantánea

Este es el reemplazo honesto del truco de prefetch de AMP. La API de Speculation Rules permite al navegador prerenderizar la siguiente página probable antes de que el usuario haga clic, logrando la misma sensación instantánea desde tu propio origen, en tu propia URL y sin framework. Es una etiqueta <script>, así que funciona igual en WordPress, en un tema de Shopify o en código propio. Los niveles de eagerness y las páginas que conviene excluir están en la guía de la Speculation Rules API para WordPress y WooCommerce.

<script type="speculationrules">
{
  "prerender": [
    {"where": {"href_matches": "/*"}, "eagerness": "moderate"}
  ]
}
</script>

#View Transitions y PWA

Las transiciones de página nativas del navegador (View Transitions API) proporcionan la sensación de “app nativa” que AMP prometía, sin sus limitaciones. Y las Progressive Web Apps ofrecen funcionalidad offline, notificaciones push y experiencia de aplicación sin frameworks restrictivos.

#Datos de campo frente a datos de laboratorio en Core Web Vitals

Un error frecuente al abandonar AMP es optimizar contra la puntuación de laboratorio de PageSpeed Insights y dar el trabajo por terminado. Esa puntuación es una simulación en un dispositivo y una red concretos. Lo que Google usa para el ranking son los datos de campo reales de tus usuarios, agregados en el informe CrUX (Chrome User Experience Report) y visibles en el panel de Core Web Vitals de Search Console. Un sitio puede sacar 100 en laboratorio y seguir fallando INP en móviles reales de gama media, que es exactamente el hardware de buena parte del tráfico en España y Latinoamérica. Deja pasar al menos 28 días tras retirar AMP antes de sacar conclusiones, porque CrUX trabaja con una ventana móvil de 28 días.

#¿Vale la pena usar AMP en 2026?

Para un sitio público, nuevo o existente, la decisión no está reñida. El único uso genuinamente vivo de la tecnología es AMP para correo (AMP for Email): Gmail todavía renderiza correos AMP dinámicos que permiten al destinatario confirmar asistencia, navegar o enviar un formulario dentro del propio mensaje sin salir de la bandeja de entrada. Es un producto distinto del AMP web, funciona sobre un runtime diferente y no le afecta nada de lo anterior. Si tu única exposición restante a AMP es un equipo de marketing experimentando con correo interactivo, no hay problema y no tiene relación con la construcción de tu sitio web.

#Resumen

AMP cumplió su propósito en un momento en que la web móvil estaba rota. Pero en 2026, con Google sirviendo los resultados AMP desde tu propio servidor, Core Web Vitals, CDNs modernos, formatos de imagen avanzados y APIs del navegador como Speculation Rules, no hay razón para usar un framework restrictivo que limita tu creatividad y cede el control de tu contenido a Google.

Plan de acción:

1. Audita tu rendimiento actual con PageSpeed Insights y datos de campo (CrUX)
2. Optimiza LCP, INP y CLS en tus páginas canónicas
3. Desactiva y elimina AMP si todavía lo usas
4. Redirige con 301 cada URL AMP (ruta y parámetro) y repara canónicas y sitemaps
5. Monitoriza Core Web Vitals mensualmente

Un sitio bien optimizado sin AMP, en WordPress o en cualquier otra plataforma, mide lo mismo en Core Web Vitals sin renunciar a formularios, analítica ni a tu propia URL.

Antes de quitar el plugin, las plantillas canónicas tienen que aprobar con datos de campo. Eso es lo que mide mi auditoría de Core Web Vitals: con el dominio, y acceso de lectura a Search Console si lo tienes, recibes una línea base por plantilla y la lista de correcciones que deben estar hechas antes de redirigir las URL AMP. Para las correcciones en sí, consulta la optimización de velocidad WordPress.