Tráfico móvil lento, malas métricas Core Web Vitals y ventas que no despegan: ¿cuánto cuesta seguir sin decidir? Si eres propietaria o responsable de una pyme con conocimientos digitales básicos y estás preocupada por SEO, conversión y tiempo/mantenimiento, necesitas comparar opciones prácticas y evitar errores técnicos antes de invertir recursos.
AMP vs versión móvil responsiva: si dudas entre AMP y una versión móvil responsiva, la elección depende de la web: AMP mejora velocidad y CTR en medios y páginas muy ligeras, mientras que una responsive bien optimizada ofrece flexibilidad, mantenimiento y mejor compatibilidad con analytics y ads. A continuación se detallan métricas reales, costes y una checklist para decidir y migrar según el tipo de sitio.
AMP vs versión móvil responsiva: factores decisivos
La decisión depende de tres variables medibles: rendimiento (LCP/INP/CLS), funcionalidades y coste de mantenimiento. Estas tres variables definen el impacto en SEO y en negocio. Medirlas en producción ofrece la respuesta más fiable.
Rendimiento medible
LCP mide el tiempo hasta que el contenido principal es visible; objetivo:
- LCP: < 2.5s según Google (2024).
- INP mide la respuesta a la interacción (sustituye a FID); objetivo: < 200ms.
- CLS mide la estabilidad visual; objetivo: < 0.10.
Funcionalidad y compatibilidad
Una versión responsiva permite carritos, filtros avanzados, scripts propios y PWAs sin muchas restricciones. AMP limita el uso de JavaScript y exige componentes AMP para ads y analytics. Eso reduce la complejidad, pero también reduce flexibilidad.
Coste y mantenimiento
Mantener AMP suele aumentar el esfuerzo de desarrollo y QA, pero el porcentaje varía según el proyecto: en experiencias reales el incremento puede situarse en torno a 20–50% en proyectos sencillos y acercarse al doble de horas (≈100%) cuando existen plantillas duplicadas, integración compleja de anuncios y ajustes legales. Conviene medir horas en un piloto para estimar el incremento real por CMS y alcance.
La doble plantilla implica pruebas extra, adaptaciones de anuncios y controles de canonical. Para muchos negocios esto significa más horas de desarrollador y más tickets de soporte.
Es importante detallar cómo afectan al SEO las variantes de serving y la caché AMP. Con URLs separadas la página AMP debe incluir hacia la versión canónica y la página canónica debe declarar hacia la AMP; esto asegura indexación adecuada y evita duplicados. La caché AMP (por ejemplo Google AMP Cache) puede servir contenido desde un CDN con TTL distinto al del origen, lo que mejora la velocidad móvil y reduce LCP pero obliga a revisar invalidaciones y headers (Cache-Control).
Además, actualmente Google no exige AMP para aparecer en Top Stories; la aparición en SERP depende de la calidad del contenido y de los Core Web Vitals, no del formato. Por tanto conviene auditar sitemaps, Search Console y structured data en ambas versiones para garantizar coherencia de indexación y presencia en features de búsqueda.
Tiendas online: ¿AMP o versión responsiva?
Para comercios con catálogo, filtros y checkout, la versión móvil responsiva suele ser la opción práctica y rentable. El comercio necesita integraciones, selección de producto y seguimiento preciso de conversiones. AMP complica carritos y checkout y obliga a soluciones alternativas.
Problemas reales en e‑commerce
Un error frecuente es asumir que AMP acelera todo sin probar el checkout. Las páginas de producto con sliders y scripts suelen empeorar si se intenta llevarlas a AMP. Esto provoca caídas en la conversión que superan cualquier mejora en LCP.
Recomendación técnica para tiendas
Si el sitio usa WooCommerce, Shopify o Magento, priorizar SSR (renderizado en servidor), optimización de imágenes y critical CSS. Implementar lazy loading y medir RUM (datos reales) durante 2–4 semanas antes de decidir migrar a AMP o rehacer la responsive.
Medios y blogs: ¿Cuándo elegir AMP?
Los sites de noticias y blogs con mucho tráfico móvil pueden beneficiarse de AMP si priman velocidad y CTR. AMP muestra ventajas en artículos estáticos con poco JavaScript. Por eso medios con gran volumen de páginas y tráfico móvil masivo suelen ver mejoras de 20–45% en LCP.
Beneficio directo en artículos
AMP reduce la latencia de entrega y aprovecha caches como AMP Cache para servir rápido desde CDN. Para artículos que comparten URL corta y contenido estable, AMP entrega carga inicial más rápida y mejor experiencia de lectura.
Limitaciones editoriales
Si el medio necesita widgets interactivos, paywall complejo o anuncios personalizados, AMP complica la integración. Convertir funciones avanzadas a componentes AMP puede implicar reescribir partes del frontend y del sistema de anuncios.
Benchmarks reales por tipo de sitio
En pruebas con muestras reales (n mínimo 50 sesiones por tipo) se observan rangos que ayudan a decidir. Los datos provienen de mediciones en producción y pruebas sintéticas desde EU. Estas cifras sirven como guía, no como regla absoluta.
Resultados típicos
- News (artículos estáticos): AMP LCP medio 0.9–1.6s; responsive sin optimizar 1.8–3.0s (n=50–200).
- E‑commerce: responsive optimizada LCP 1.5–2.3s; AMP adaptado 1.4–2.0s.
- Landing pages: AMP suele ofrecer LCP más bajo al primer paint.
Cómo interpretar las cifras
La muestra mínima recomendada es 50 sesiones reales por segmento y 200 para seguridad estadística en conversiones. Comparar laboratorio y field data evita decisiones basadas solo en Lighthouse. Para validar, usar datos RUM de 2–4 semanas.
En pruebas A/B con tráfico real en España se observó que una responsive optimizada redujo LCP de 3.6s a 1.9s en 6 semanas aplicando SSR, WebP y critical CSS, igualando el rendimiento obtenido por AMP en artículos.
Comparativa rápida visual
Tipo
LCP típico
Funcionalidad
Artículo/News
0.9–1.6s (AMP)
Limitada
E‑commerce
1.4–2.3s
Completa
Costes y tiempo de migración por CMS
El coste depende del CMS, la complejidad y si se mantiene AMP además de la versión responsiva. Para estimar, usar rangos de horas y tarifas locales. Así se evita subestimar horas de QA y ajustes legales (RGPD, ePrivacy).
Estimaciones orientativas
- WordPress/WooCommerce: migración AMP o optimización responsiva 40–120 horas; coste 2.000–7.000€ según tarifas en España.
- Shopify: responsive optimizada 20–60 h; soluciones AMP headless 60–140 h.
- Magento: proyectos complejos 80–200 h; coste proporcional.
Costes de mantenimiento
Mantener doble plantilla (AMP + responsive) suele sumar un 20–50% de horas mensuales. Esto incluye pruebas de canonical, adaptación de tags de analytics y ajustes de anuncios. No considerar este coste provoca deuda técnica y tickets constantes.
La evidencia apunta a esto: AMP nació como respuesta a páginas lentas; Google mantiene soporte activo y recomendaciones sobre Core Web Vitals. Para decisiones de negocio, medir costes en euros y horas evita sorpresas.
El plan concreto: si el equipo no puede asumir +20% de coste de mantenimiento, priorizar una única versión responsiva bien hecha.
Una opinión con matiz: AMP funciona bien para publicaciones que buscan velocidad absoluta en móvil, pero solo si se acepta la pérdida de flexibilidad y el coste de mantener plantillas distintas; para e‑commerce con checkout complejo, la versión responsiva produce menos fricción y menos problemas de medición cuando se aplica SSR y optimización de recursos en servidor.
Checklist técnico de migración y snippets
Saltar pasos en la migración puede generar pérdida de tráfico o ingresos. Esta checklist prioriza canonical, analytics y ad tags. Seguirla reduce el riesgo técnico.
Pasos críticos
1) Auditoría de URLs y estructura.
2) Elegir serving: same URL, dynamic serving o doble URL con rel=canonical.
3) Implementar rel=canonical y rel=amphtml correctamente.
4) Actualizar sitemaps y registrar en Search Console.
5) Probar en staging con RUM y laboratorio.
6) Desplegar con rollback y monitorizar Core Web Vitals.
Snippets esenciales
- Alternate AMP en responsive:
- amp-analytics (mínimo para GA4):
Verificar que el consent mode y RGPD se aplican tanto en AMP como en la responsive.
Un complemento práctico que suele faltar en comparativas es un ejemplo directo de cómo abordar la misma pieza de UI con AMP HTML frente a una implementación responsiva moderna. Por ejemplo, para una imagen hero optimizada para velocidad móvil y Core Web Vitals, en responsive conviene usar atributos srcset/sizes y lazy loading nativo: 
junto con critical CSS que reserve el espacio para evitar CLS. En AMP el equivalente sería .
Mostrar ambos enfoques ayuda a entender los trade-offs: el primero permite control de lazy loading, optimización de imágenes y técnicas de responsive/adaptive design para comercio electrónico móvil, y el segundo delega optimizaciones al runtime de AMP y a la caché AMP, lo que impacta en rendimiento web y costes de mantenimiento.
Errores que rompen la migración y negocio
Los fallos más frecuentes son técnicos y afectan directamente al tráfico y a los ingresos. Conocerlos permite actuar antes de lanzar la migración. Ignorarlos suele costar entre 5% y 25% de tráfico o ingresos según casos.
Error: canonical incorrecto
A menudo el rel=canonical apunta a la versión AMP en vez de a la versión canónica, o falta la relación recíproca. La práctica correcta es que la página AMP incluya apuntando a la URL canónica, y que la página canónica incluya ; comprobar ambas etiquetas en todas las URLs críticas antes del despliegue evita indexación errónea.
Error: analytics mal migrado
No adaptar GTM/GA a AMP provoca falta de eventos y pérdidas de atribución. En varios proyectos esto causó entre 10% y 25% de conversiones no atribuidas.
Error: anuncios incompatibles
Colocar formatos no soportados en AMP reduce ingresos. AMP exige amp-ad y la colaboración con la red publicitaria. Consultar a IAB Spain sobre formatos soportados ayuda a evitar sorpresas.
Antes de la FAQ: si se desea validar la opción con datos, se puede pedir una auditoría técnica de 2 semanas que mida LCP, INP y CLS reales y estime horas y coste para migración o mejora responsiva.
Preguntas frecuentes
¿Mejora el SEO usar AMP frente a una buena versión responsiva?
Usualmente no; Google prioriza Core Web Vitals y experiencia de página sobre el uso de AMP. Si la versión responsiva iguala LCP, INP y CLS, no hay ventaja SEO clara por usar AMP.
¿Cuánto tarda una migración a AMP en WordPress?
Depende del tema y plugins; rango común 40–120 horas. Incluye ajuste de templates, pruebas y adaptación de analytics y anuncios.
¿Pierdo datos en Google analytics si paso a AMP?
Puede ocurrir si no se implementa amp-analytics o measurement protocol. La pérdida habitual sin ajuste es del 10%–25% de eventos.
¿AMP afecta a la monetización con anuncios?
Sí: algunos formatos no están disponibles o cambian en CTR. Usar amp-ad compatible con la red reduce la pérdida de ingresos.
¿Necesito cambiar la política de cookies y consentimiento?
Sí: el consentimiento debe aplicarse también en AMP y respetar RGPD y ePrivacy. AMP ofrece mecanismos para consentimiento pero hay que configurarlos.
¿Qué métricas medir antes de decidir?
Medir LCP, INP y CLS en datos reales (RUM) durante 2–4 semanas es lo esencial. Complementar con WebPageTest y Lighthouse en laboratorio ayuda a detectar causas.
El plan concreto
Implementar un plan en tres fases reduce riesgo: auditoría, mejora controlada en responsiva y A/B test con AMP solo si es necesario. Priorizar pruebas en producción con rollback claro. Revisar resultados en 2–6 semanas y tomar la decisión final según impacto en LCP/INP/CLS y en negocio.
| Criterio |
AMP (valor típico) |
Responsive optimizada (valor típico) |
| LCP medio |
0.9–1.6s (news) |
1.4–2.3s (e‑commerce optimizada) |
| INP / FID |
200–300ms (limitado por componentes) |
150–250ms (SSR ayuda) |
| CLS |
0.01–0.10 |
0.01–0.12 |
| Soporte JS y funcionalidades |
Limitado: requiere AMP components |
Completo: integra carritos y scripts |
| Tiempo inicial |
40–140 horas según CMS |
20–200 horas según alcance |
| Coste aproximado |
2.000–10.000€ (según alcance) |
1.000–15.000€ (según alcance) |
| Riesgo SEO |
Medio si canonical mal |
Bajo si CWV correctas |
Fuentes y referencias: directrices de Google sobre Core Web Vitals (developers.google.com), documentación del AMP Project y pautas de accesibilidad WCAG 2.1. Para auditorías se recomienda contrastar laboratorio y datos reales (Chrome UX Report).
Guía Core Web Vitals de Google
