Cuando muchos evaluadores técnicos hablan de amp pages and seo, normalmente no quieren saber simplemente “qué es AMP”, sino dos cosas: si mejorará el rendimiento en los buscadores después de implementarlo y si la experiencia móvil se verá perjudicada en caso de no hacerlo. La conclusión es clara: AMP no es un botón directo para mejorar el posicionamiento. Es más bien una especificación técnica relativamente restrictiva en cuanto a la estructura de las páginas, el uso de scripts y la forma de cargar los recursos. En el pasado tuvo una presencia muy destacada en el ámbito de la experiencia móvil, pero actualmente los motores de búsqueda prestan más atención a las métricas reales de experiencia de página que a si se utiliza AMP o no.
Por eso, al evaluar esta tecnología, no hay que empezar preguntando “¿debemos implementarla?”, sino “¿los problemas actuales del sitio solo pueden resolverse con AMP?”. Si se comete un error en este paso, normalmente el resultado es mantener dos conjuntos de plantillas, dos sistemas de seguimiento y dos procesos de resolución de errores, mientras que los beneficios no necesariamente compensan los costes.
Estos son dos objetivos que se confunden con mucha facilidad. El posicionamiento es un resultado integral en el que influyen múltiples factores, como la calidad del contenido, la accesibilidad para el rastreo, los enlaces internos, los enlaces externos, la experiencia de página y la correspondencia con la intención de búsqueda. La velocidad móvil es solo uno de ellos. AMP influye principalmente en la forma de cargar los recursos, la estabilidad del renderizado y la ligereza de la página; no puede sustituir la calidad del contenido ni la arquitectura de la información.
El método de evaluación es muy directo: hay que revisar las páginas móviles reales y observar la experiencia principal, en lugar de fijarse únicamente en las puntuaciones de laboratorio. Durante la evaluación, conviene prestar atención primero a si el contenido visible en la primera pantalla aparece con suficiente rapidez, si el diseño presenta desplazamientos inesperados y si, después de hacer clic, el usuario debe esperar demasiado para recibir una respuesta.

He visto a muchos equipos tratar AMP como un parche de rendimiento, para descubrir finalmente que lo que realmente ralentizaba la página no era la estructura HTML, sino la gran cantidad de scripts de marketing, códigos de seguimiento, componentes de ventanas emergentes y recursos cargados de forma síncrona integrados en el sitio. AMP limita la forma de implementar estos elementos, por lo que efectivamente puede hacer que la página parezca más rápida, pero el precio es aceptar todo un conjunto de restricciones.
Durante la evaluación técnica, hay que centrarse en cuatro aspectos:
Si los dos primeros aspectos son muy exigentes, AMP normalmente no resulta rentable; si hay muchos elementos de los dos últimos, el mantenimiento posterior se volverá claramente más complejo. En pocas palabras, es más adecuado para páginas de contenido, mientras que debe evaluarse con cautela en páginas funcionales.
La relación entre amp pages and seo no consiste en que “usar AMP produzca una mejora automática”, sino en si puede mejorar indirectamente las condiciones básicas que influyen en el rendimiento en los buscadores. Se recomienda evaluarlo según la siguiente tabla:
Lo que realmente merece atención es si las páginas AMP permiten que los motores de búsqueda rastreen de forma más estable el contenido principal, si reducen la pérdida de usuarios móviles y si evitan problemas de indexación derivados de las dos versiones. Estos factores sí pueden influir en los resultados; el nombre de la tecnología, por sí mismo, no.
Muchos proyectos AMP no fracasan por la velocidad, sino porque la relación entre la página canónica y la página AMP no se ha gestionado correctamente. Desde el punto de vista técnico, los tres problemas más habituales son: una referencia canonical incorrecta, contenido incoherente y datos estructurados no unificados entre ambas versiones. Los dos primeros pueden afectar a la evaluación de la indexación, mientras que el último puede hacer que la presentación de los resultados de búsqueda sea inestable.
Durante la comprobación, no hay que limitarse a verificar si la página puede abrirse; hay que revisar uno por uno los siguientes puntos:
Una experiencia útil para juzgar esta situación es la siguiente: si el sitio ya funciona con varios idiomas, regiones y plantillas en paralelo, añadir otra capa de gestión de versiones con AMP aumentará claramente la probabilidad de errores. Equipos como 易营宝, que llevan tiempo trabajando en proyectos de creación de sitios multilingües y marketing internacional, suelen prestar más atención a la rastreabilidad general, la coherencia de las plantillas y la operatividad posterior que a si una página concreta obtiene una buena puntuación. La razón es que, cuando se desordenan las relaciones entre versiones de un sitio internacional, el coste de diagnóstico es mucho mayor que en un sitio nacional independiente.
La evaluación técnica no puede centrarse únicamente en el frontend. Muchos equipos implementan AMP y descubren después que las métricas no coinciden: las sesiones procedentes de clics publicitarios no se corresponden con los envíos de formularios, los nombres de eventos no están unificados y faltan las audiencias de remarketing. El departamento de marketing empieza entonces a cuestionar los datos y el equipo de desarrollo tiene que volver atrás para completar el trabajo.
Por eso, antes de iniciar el proyecto, hay que aclarar lo siguiente:
Si tu negocio depende en gran medida de la publicidad segmentada y el remarketing, los beneficios de AMP deben ser lo suficientemente grandes como para cubrir los costes de adaptar el seguimiento y analizar los datos; de lo contrario, será difícil que las cuentas cuadren.
Los escenarios que normalmente se adaptan mejor a AMP son los siguientes: páginas de detalle de contenidos, páginas especiales, documentos de ayuda, páginas de noticias e información y páginas de destino ligeras centradas en la lectura y con interacciones simples. La estructura de estas páginas es clara y su objetivo principal es permitir que el usuario vea el contenido rápidamente, no que complete una operación compleja en la primera pantalla.
Los escenarios menos adecuados también están claros: formularios complejos, consultas en varios pasos, páginas de detalle de productos de tiendas online, centros de miembros y páginas que dependen del inventario en tiempo real o del renderizado personalizado. Si se fuerza AMP en este tipo de páginas, el resultado suele ser una reducción de las funciones o la necesidad de escribir una gran cantidad de lógica adicional para garantizar la compatibilidad.
Algunos equipos colocan AMP únicamente en las páginas de entrada de contenidos y después dirigen a los usuarios a las páginas de conversión del sitio principal. Este enfoque no es necesariamente incorrecto, pero hay que comprobar de antemano si la ruta de redirección es fluida y si el usuario pasará de repente de una página ligera a otra demasiado pesada, provocando una ruptura de la experiencia.
Lo que realmente suele resultar problemático de AMP es que no se trata de “terminar el desarrollo y darlo por concluido”, sino de “tener que volver a validarlo cada vez que se modifica una plantilla, un componente o el seguimiento”. Si tu sitio se actualiza con frecuencia, este coste será permanente.
Se recomienda incluir las cuestiones de mantenimiento en el documento de planificación, en lugar de resolverlas después de la puesta en marcha:
Si actualmente nadie se ocupa de estas cuestiones, no conviene apresurarse a implementar AMP. Una solución técnica no debe evaluarse únicamente según si puede desarrollarse, sino también según si podrá seguir funcionando de forma estable seis meses después.
Si necesitas tomar una decisión ahora mismo, te recomiendo seguir este orden para evitar desviaciones.
Primero, analiza el tipo de sitio. Si predominan las páginas de contenido, pasa al siguiente paso; si predominan las páginas funcionales, prioriza la optimización de la arquitectura existente. Después, comprueba si la experiencia móvil real es ya lo suficientemente deficiente como para afectar al acceso y a las conversiones. Si los problemas principales proceden de scripts pesados, de la estrategia de imágenes o del framework frontend, empieza por una optimización convencional del rendimiento y no te apresures a implementar AMP.
A continuación, comprueba la capacidad de gestión de versiones. Si el equipo no controla de forma estable aspectos básicos como canonical, los datos estructurados, la atribución analítica y las plantillas multilingües, después de implementar AMP lo más probable es que simplemente aumente un nivel más la complejidad. En cambio, si ya disponéis de un sistema maduro de creación de sitios, procesos de publicación y procesos de optimización para buscadores, AMP podría convertirse en una opción controlable.
Como apunte, los documentos de evaluación técnica a veces consultan otros materiales especializados sobre digitalización, como Análisis de las estrategias de transformación digital de la gestión de recursos humanos en las instituciones públicas en la era de la inteligencia. La cuestión no es que este contenido tenga una relación técnica directa con AMP, sino que permite tomar como referencia el método de “organizar primero los procesos y evaluar después el coste de adaptación del sistema”. Este método también es aplicable a las decisiones técnicas sobre sitios web.
Si hubiera que resumir esta lista en una sola frase, sería la siguiente: si AMP merece la pena no depende de lo avanzada que parezca la tecnología, sino de si tu sitio reúne la combinación de condiciones de priorizar el contenido, tener un elevado tráfico móvil, obtener resultados lentos con la optimización de rendimiento existente y contar con un equipo capaz de mantener dos versiones a largo plazo.
En la práctica, primero hay que realizar una revisión del estado de las páginas existentes y después decidir si se debe introducir AMP. Conviene revisar prioritariamente los recursos de la primera pantalla, la compresión de imágenes, la estrategia de caché, la cantidad de scripts, los desplazamientos del diseño y la carga de trabajo del seguimiento. Solo después de completar estas acciones básicas, si la experiencia móvil sigue sin alcanzar el nivel requerido y el tipo de página es realmente adecuado para AMP, debe incluirse AMP como solución formal. De este modo, la dirección suele ser más estable y posteriormente resulta más fácil explicar al área de negocio por qué se implementa, qué se debe observar después de hacerlo y qué costes se ahorran al no implementarlo.
Artículos relacionados
Productos relacionados


