Idiomas

SEO para AMP

Qué es AMP (Accelerated Mobile Pages), cómo funciona, por qué nunca fue un factor de ranking, por qué dejó de ser necesario para Top Stories en junio de 2021 y cómo decidir si mantenerlo o eliminarlo.

Publicado por primera vez: 27 jun 2026 · Última actualización: 8 ago 2026 · Avanzado
Idiomas
AIEscrito porAI v2

AMP (Accelerated Mobile Pages) es el framework de Google de 2015 para páginas móviles casi instantáneas, pero nunca fue un factor de ranking y desde junio de 2021 ya no es necesario para Top Stories (Core Web Vitals lo sustituyó y se retiró el distintivo AMP). Es opcional y está en declive: no crees AMP nuevo y sopesa el coste operativo antes de mantenerlo.

TL;DR — AMP es el framework de código abierto de Google de 2015 para páginas móviles casi instantáneas: HTML/CSS/JS restringidos más prerenderizado desde la Google AMP Cache. Nunca fue un factor de ranking (Google lo dice explícitamente) y, desde la actualización de Page Experience de junio de 2021, ya no es necesario para Top Stories: Core Web Vitals lo sustituyó y se retiró el distintivo AMP. La versión AMP almacenada en caché sigue sirviéndose bajo google.com/amp/s/…; Signed Exchange (SXG) puede servirla bajo tu propia URL, pero solo en Chrome. La relación canonical empareja una página no AMP con canonical propio (que lleva rel="amphtml") con una página AMP que apunta de vuelta con rel="canonical". Hoy AMP es opcional y está en declive: no crees AMP nuevo y sopesa el coste operativo (sobre todo la analítica) antes de mantenerlo.

Evidence for this claim AMP is not required for Top Stories eligibility; Google removed the AMP requirement with the page experience rollout. Scope: Current official or standards documentation. Confidence: high · Verified: Google Search Central: Page experience rollout Evidence for this claim The Google AMP Cache is a proxy-based CDN that stores and serves valid AMP documents. Scope: Current official or standards documentation. Confidence: high · Verified: AMP: How pages are cached

Un poco de historia

Google lanzó AMP en 2015 y lo puso a disposición en Google Search en octubre de 2015, presentándolo como la respuesta de la web abierta a Facebook Instant Articles y Apple News: una forma de mantener competitivas las páginas de los editores en velocidad móvil. En el lanzamiento contó con socios como Twitter, LinkedIn, WordPress y Pinterest, y el proyecto pasó después a la gobernanza de OpenJS Foundation, aunque Google siguió siendo el principal contribuyente.

La razón por la que la mayoría de los editores lo adoptó no fue ideológica: fue el carrusel de Top Stories. Aproximadamente entre 2016 y 2021, AMP era prácticamente obligatorio para aparecer allí, y Google marcaba los resultados AMP con un distintivo de rayo (⚡).

Cómo funciona AMP técnicamente

AMP compra velocidad mediante restricciones:

  • Marcado restringido. Una página AMP declara <html ⚡> (o <html amp>), carga el runtime de AMP JS (<script async src="https://cdn.ampproject.org/v0.js">) e incluye el boilerplate de AMP junto con la etiqueta meta charset y la etiqueta viewport obligatorias.
  • Sin JavaScript del autor. Tu propio JS no está permitido salvo mediante el componente aislado amp-script; el JS de terceros solo se ejecuta dentro de iframes. Todo lo que se ejecuta lo hace de forma asíncrona, así que nada bloquea el renderizado.
  • CSS insertado y limitado a 75 KB. No hay hojas de estilo externas.
  • Dimensiones de recursos declaradas estáticamente. Las imágenes y los elementos incrustados reservan su espacio por adelantado, lo que evita el desplazamiento del diseño.

Esas reglas permiten a Google prerenderizar una página AMP en un iframe oculto antes de que el usuario pulse, y de ahí procede la sensación de «instantaneidad».

La Google AMP Cache

La velocidad de AMP no depende solo del framework, sino también de la entrega. Google almacena una copia validada y optimizada de tu página AMP en cdn.ampproject.org, la sirve mediante HTTPS y protocolos modernos y optimiza las imágenes. Una consecuencia que conviene interiorizar: con AMP en caché, la infraestructura de Google se convierte en el host de tu contenido, no tus servidores. Ten en cuenta también que las páginas AMP de escritorio no se sirven desde la AMP Cache; el AMP canonical se comporta allí como un resultado estándar, así que el beneficio de aceleración de la CDN es, en la práctica, móvil.

La cronología que importa:

  • 2016–2021: se mostraba el distintivo AMP (⚡) en los resultados y AMP era necesario para Top Stories.
  • Abril de 2021: Google anunció que, con la actualización de Page Experience, “using the AMP format is no longer required” (traducción) «ya no es necesario utilizar el formato AMP» para Top Stories.
  • Junio de 2021: se desplegó la actualización de Page Experience. Core Web Vitals se convirtió en la señal de rendimiento para la aptitud de Top Stories y Google retiró el distintivo AMP de los resultados.
  • 2021–actualidad: AMP es opcional, no aporta una mejora de ranking y CWV es lo que realmente impulsa las señales relacionadas con el rendimiento.

La idea principal que necesitas: AMP no es un factor de ranking y ya no es tu entrada a Top Stories.

El problema de la reescritura de URL (y Signed Exchange)

Hay tres URL en juego para un único artículo AMP: la URL original del editor, la URL de AMP Cache en cdn.ampproject.org y la URL del Google AMP Viewer, que tiene este aspecto: https://www.google.com/amp/s/[your-domain]/[path]. Como el prerenderizado exige un iframe del mismo origen, el Viewer sirve tu contenido bajo una URL de google.com, por lo que los usuarios ven el dominio de Google y no el tuyo. Esto ha sido una fuente real de confusión de marca y problemas de atribución.

Signed Exchange (SXG) es la solución. Envuelve el documento AMP en una firma criptográfica vinculada a tu URL, de modo que, cuando Chrome la valida, el navegador muestra tu dominio en la barra de direcciones. Google prioriza Signed Exchange sobre AMP Viewer cuando es compatible. Los inconvenientes: SXG solo funciona en Chrome, las firmas tienen una vida máxima de 7 días (el empaquetador debe volver a firmarlas), está limitado a resultados enriquecidos y básicos (no carruseles) y exige ejecutar un servidor amppackager o un proveedor SXG externo. Es el método de entrega «correcto», pero implica una carga operativa considerable.

Etiquetado canonical de AMP

Aquí es donde más suelen romperse las implementaciones de AMP. Hay dos configuraciones:

  • Emparejada (la más común): una página no AMP y una página AMP separada.
    • La página no AMP es su propio canonical y añade <link rel="amphtml" href="https://example.com/article/amp/">.
    • La página AMP añade <link rel="canonical" href="https://example.com/article/">, apuntando a la versión no AMP.
  • Solo AMP: una única URL es a la vez canonical y AMP, así que se referencia a sí misma.

Reglas prácticas: Google indexa la URL canonical (AMP se trata como un duplicado), así que coloca los datos estructurados en ambas versiones, incluye solo las URL canonical en tu sitemap y deja que rel="amphtml" se encargue del descubrimiento de AMP. Google documenta este emparejamiento exacto de rel="amphtml"/rel="canonical"; consulta Acerca de AMP: haz que tu contenido sea descubrible como referencia de la relación si tu configuración no coincide con ninguno de los dos casos anteriores.

Problemas de analítica de AMP

La complejidad del seguimiento de AMP es un coste operativo real, no teórico:

  • El problema de las referencias. El tráfico de páginas AMP en caché aparecía históricamente como referencias de cdn.ampproject.org en vez de búsqueda orgánica; la solución es excluir ese dominio de las referencias.
  • Fragmentación de sesiones. Pasar de una página AMP en caché a la página no AMP iniciaba por defecto una sesión nueva. AMP Linker (pasar el Client ID mediante un parámetro de URL amp_id= a través del límite entre caché y sitio) es lo que las une.
  • GTM para AMP utiliza el componente amp-analytics, una configuración más compleja que el GTM estándar y con menos funciones.
  • GA4 obtuvo compatibilidad AMP nativa en junio de 2024; antes de eso, la medición de AMP dependía de implementaciones de la comunidad.

Cuando Search Engine Land desactivó AMP, «una imagen más clara de la analítica de su audiencia» fue una de las ventajas que comunicaron, así que este es un punto débil conocido.

Otras superficies AMP (para no confundirlas)

  • Web Stories (lanzadas como AMP Stories en 2018 y renombradas Google Web Stories en 2020) son un formato de historias visuales e interactivas basado en AMP. Aparecen en Search, Discover e Images. Son distintas de los artículos AMP estándar.
  • AMP for Email lleva contenido interactivo (formularios, carruseles y datos en tiempo real) a Gmail y a algunos clientes más. Es una función de correo electrónico, no de SEO de búsqueda; basta con saber que existe, no afecta al ranking.

Bing y AMP

Bing se sumó al proyecto de código abierto AMP en septiembre de 2016 y durante un tiempo tuvo su propio visor y caché AMP, con su propio tratamiento de rayo. Pero, según Bing, AMP no afectó de ninguna forma a sus algoritmos de ranking, y el soporte de Bing para AMP es ahora en gran medida histórico: no existe un carrusel de noticias actual que lo exija ni informes destacados de AMP en Bing Webmaster Tools. En la práctica, la postura de Bing refleja la de Google: opcional y sin mejora de ranking.

¿Deberías seguir usando AMP?

Casos en los que puede tener sentido mantener AMP:

  • Un editor de noticias o medios que ya usa AMP, tiene pocas incidencias en Search Console y afronta un alto coste de cambio.
  • Un sitio de contenido sencillo en el que AMP resulta ser el camino de menor resistencia para conseguir buenos Core Web Vitals.

Casos en los que conviene eliminarlo:

  • Sitios empresariales con funciones que AMP no puede admitir; este es exactamente el caso que defendí en SMX West: para una empresa grande con una estructura compleja, AMP puede ser demasiado difícil de implementar y conllevar un riesgo excesivo, y hay razones empresariales reales para conservar elementos del sitio que AMP no permite.
  • Sitios que ejecutan AMP solo por un distintivo de Top Stories que ya no existe.
  • Sitios donde importa la claridad de la analítica: la complejidad de seguimiento de AMP es un coste real.
  • Sitios que ya cumplen Core Web Vitals: AMP no aporta un beneficio adicional.
  • Cualquier sitio donde la reescritura de URL de AMP esté provocando problemas de marca o atribución.

La respuesta honesta en 2026: AMP es opcional y está en declive. Para proyectos nuevos, no lo implementes. Para los existentes, evalúa el coste operativo frente al beneficio que queda.

Cómo eliminar AMP (si decides hacerlo)

  1. Elimina la etiqueta rel="amphtml" de tus páginas canonical (no AMP).
  2. Redirige con 301 las URL AMP a sus equivalentes canonical no AMP.
  3. Deja de supervisar el informe de estado de AMP en Search Console.
  4. Comprueba que los errores de AMP desaparecen de Search Console durante las semanas siguientes.

Si se hace correctamente, las páginas canonical siguen indexándose y posicionándose. Grandes editores, incluido Search Engine Land, han eliminado AMP con una interrupción mínima del tráfico.

Mitos que conviene eliminar

  • «AMP mejora el ranking». No es cierto. AMP no es un factor de ranking; la velocidad sí importa y AMP es solo una forma de conseguirla.
  • «Necesitas AMP para Top Stories». Falso desde junio de 2021.
  • «AMP siempre es más rápido que una página normal». No: la ventaja procede del prerenderizado de Google de la copia en caché. Una página no AMP rápida puede superar a una AMP lenta.
  • «Las URL AMP son tus URL». Solo con Signed Exchange (exclusivo de Chrome). El Viewer predeterminado muestra google.com/amp/s/….
  • «Eliminar AMP hundirá el tráfico». Gestiona correctamente canonical y redirecciones y el impacto suele ser mínimo.

Para las señales de rendimiento que sí importan ahora, consulta Core Web Vitals y el grupo más amplio de Rendimiento web.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.