Formato nuevo
Páginas Google AMP: qué eran y si las necesitas ahora
AMP (Accelerated Mobile Pages) es un formato abierto de páginas ligeras que Google impulsó desde 2015: HTML/JS limitado, paint rápido y a menudo entrega desde la caché de búsqueda.
A mediados de los 2020 AMP ya no es una capa obligatoria de SEO móvil: el carrusel y los privilegios en la SERP se fueron, y la velocidad la deciden los Core Web Vitals en tu propio sitio. Abajo: cómo funcionaba el formato, qué ayudaba y qué hacía daño, y cuándo aún tiene sentido. Las guías paso a paso de «instala un plugin y sube posiciones» están obsoletas.
Cómo funcionaba AMP
La página se construía bajo reglas AMP HTML: componentes permitidos en lugar de scripts arbitrarios, validación del markup. El objetivo — carga rápida predecible en el teléfono.
Los usuarios podían abrir AMP en tu dominio (a menudo un sufijo `/amp` o `?amp`) o ver una copia en caché en la infraestructura de Google. En el segundo caso algunas métricas y la sensación del sitio diferían de una visita completa a tu host.
Qué se solía recortar:
- JavaScript arbitrario pesado
- widgets complejos y algunos formularios
- gráficos y efectos pesados
- algunos bloques de ads y sociales sin componentes especiales
Pros y contras de la era AMP
La ventaja era velocidad en redes móviles débiles y una plantilla ligera compartida para medios. Los inconvenientes: UX más pobre, analytics y conversiones más difíciles, riesgo de confusión canónica, dependencia de reglas de plataforma y caché.
No reutilizamos benchmarks viejos de PageSpeed «era 61 — pasó a 87» de casos 2019–2020: cambiaron las herramientas y los pesos de las métricas. Mira informes actuales en tus URLs.
Problemas típicos de rollout:
- baja conversión en la página reducida
- goals y eventos más difíciles en analytics
- duplicados/problemas de canonical por un setup malo
- mantener dos plantillas en lugar de un buen móvil
¿Necesitas AMP ahora?
Para la mayoría de sitios comerciales en 2026 la respuesta sensata es no como capa obligatoria. Invierte en diseño responsive, compresión, fuentes, imágenes, caché/CDN y Core Web Vitals en las URLs canónicas.
AMP solo tiene sentido si tienes un caso de contenido estrecho, soporte del formato ya en el stack y analytics claros. No arrancamos proyectos nuevos por un checkbox AMP.
Dónde poner el esfuerzo:
- layout móvil y legibilidad
- velocidad LCP/INP/CLS
- CTAs claros en el sitio completo
- una plantilla sin un universo ligero paralelo
FAQ
¿AMP sigue siendo obligatorio para SEO móvil?
No. Primero un sitio responsive rápido. AMP es un caso estrecho/histórico — no un sustituto de la UX móvil real.
¿En qué se diferenciaba AMP de una página normal?
Un set estricto de tags y componentes, poco JS arbitrario, layout reducido. Google podía servir una copia desde su caché — más rápido en conexión débil, pero parte de la sesión no estaba en tu host.
¿AMP es lo mismo que Yandex Turbo?
La idea es similar (una copia móvil ligera), los ecosistemas difieren. Turbo en la búsqueda también se fue apagando — la apuesta es tu propio sitio.
¿Debo borrar ya las URLs /amp antiguas?
No siempre. Comprueba que canonical y analytics apunten a la versión principal, que no haya confusión de índice ni redirects muertos. Lo que importa es la calidad móvil de la principal.
¿AMP da un boost de posiciones?
No hay «puntos AMP» directos como factor obligatorio. Importan velocidad y comportamiento — los cubres en URLs normales.
¿Sigues manteniendo AMP «por SEO» mientras los Core Web Vitals del sitio principal van atrasados?
Centramos velocidad y UX móvil en las URLs canónicas — AMP solo si ya tienes un caso de contenido claro.
Hablar del proyecto
