¿Está muerto Google AMP en 2026? (Y qué deberías usar en su lugar)

El rayo se ha desvanecido. En 2016, Google lanzó AMP. En 2026, el requisito para “Top Stories” ha desaparecido.

¿Está muerto AMP? Sí. ¿Deberías usarlo en tu sitio WordPress? No.

En este análisis en profundidad explicamos el auge y la caída de AMP, qué era el framework por dentro, cómo eliminarlo de WordPress sin perder posiciones y qué usar en su lugar.

#¿Sigue siendo relevante AMP en 2026

No. AMP (Accelerated Mobile Pages) ya no es relevante para nuevos proyectos WordPress en 2026. Google eliminó el requisito de AMP para Top Stories en 2021, y Core Web Vitals sustituyó a AMP como la principal señal de rendimiento para el posicionamiento. El plugin AMP para WordPress ha perdido en torno al 80% de sus descargas desde su máximo.

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

#¿Están muertas las páginas AMP

Sí. El formato AMP en sí todavía funciona técnicamente: Google no ha apagado la caché ni el framework. Pero el ecosistema que hacía valioso a AMP se ha desmoronado:

• Sin ventaja de ranking. Las páginas AMP no reciben trato preferente en los resultados.
• Sin requisito de Top Stories. Cualquier página que cumpla los umbrales de Core Web Vitals puede aparecer.
• Éxodo de editores. Muchos grandes editores han retirado sus implementaciones AMP sin reportar pérdida de tráfico.
• Desarrollo detenido. El proyecto AMP recibe actualizaciones mínimas. No se han lanzado funciones significativas desde 2023.

#Estado de Google AMP en 2026

La posición oficial de Google es que AMP sigue “soportado” pero ya no está recomendado ni es obligatorio para ninguna función de búsqueda. La caché de AMP (cdn.ampproject.org) sigue sirviendo páginas, pero Google no ha invertido en nuevas capacidades desde que Core Web Vitals se convirtió en la métrica principal de rendimiento.

Para los propietarios de WordPress, el estado práctico es claro: desinstala el plugin AMP, configura las redirecciones e invierte en optimización de rendimiento nativa.

#Qué era AMP realmente por dentro

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.

#La controversia de la URL y los Signed Exchanges

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. Tapar el problema de la URL con criptografía revelaba lo profundo que era el problema de fondo.

#Parte 1: por qué AMP fracasó

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

#El compromiso

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.

#La controversia anticompetitiva

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.

#El cambio a Core Web Vitals

En 2021, Google introdujo Core Web Vitals (CWV). El mensaje fue claro: “No nos importa SI usas AMP. Solo nos importa que tu página sea RÁPIDA.”

Esta fue la sentencia de muerte de AMP. Si una página responsive estándar supera los umbrales (LCP por debajo de 2.5 s, INP por debajo de 200 ms, CLS por debajo de 0.1), obtiene el mismo trato de ranking que AMP antes condicionaba, sin ninguna de las restricciones. El carrusel de Top Stories, antes exclusivo de AMP, se abrió a todas las páginas que cumplían los umbrales de CWV.

#La línea temporal de la caída de AMP

#Por qué los medios se marcharon en la práctica

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.

#Parte 2: cómo eliminar AMP de forma segura (de-AMPing)

Si tu sitio WordPress sigue con AMP, cargas con todos sus costes y ninguno de sus antiguos beneficios. 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

#Lista de decisión rápida

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.

#Parte 3: la pila de rendimiento moderna (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

Los formatos modernos como AVIF ofrecen hasta un 50% menos de tamaño de archivo que WebP con 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) reproduce casi toda la ventaja de velocidad de AMP sin ceder la URL, con TTFB inferior a 100 ms a nivel global. 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.

<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.

#Mide con datos de campo, no solo de laboratorio

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.

#Parte 4: AMP frente a nativo, la decisión

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

El experimento de AMP ha terminado. La web abierta ha ganado. Desinstala el plugin.

AMP cumplió su propósito en un momento en que la web móvil estaba rota. Pero en 2026, con 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 WordPress bien optimizado sin AMP en 2026 supera en rendimiento y experiencia de usuario a cualquier página AMP.

Explora nuestra optimización de velocidad WordPress para llevar tu proyecto más lejos.