¿Cómo comprobar la adaptación tras la desactivación de google mobile friendly test?

Google dejó de utilizar en diciembre de 2023 el google mobile friendly test y el informe de "usabilidad móvil" de Search Console. La desaparición de la opción que antes permitía "hacer una prueba y saber si era apto para dispositivos móviles" no significa que la adaptación móvil haya dejado de afectar la indexación y el posicionamiento; Google sigue utilizando principalmente Smartphone Googlebot para rastrear páginas web y toma el contenido de la versión móvil como base para la indexación y evaluación.

Lo que realmente debe sustituirse no es un indicador verde de "aprobado", sino tres tipos de evaluación: si Google puede rastrear y renderizar la página móvil; si los usuarios pueden utilizarla correctamente con redes móviles reales; y si la velocidad y estabilidad del diseño de la página perjudican la experiencia. Una sola herramienta no puede cubrir estos tres aspectos; el enfoque más prudente es combinar la inspección de URL, PageSpeed Insights y pruebas en dispositivos reales.

Primero confirme con la inspección de URL: si la página que ve Google funciona correctamente

Acceda a "Inspección de URLs" en Google Search Console, introduzca la URL completa y consulte prioritariamente la versión indexada. Lo que debe confirmarse no es si la página se puede abrir en su propio ordenador, sino si la página rastreada recientemente por Google se puede indexar, si se ha seleccionado la página canónica prevista y si el rastreo utiliza Smartphone Googlebot.

Si la página se ha modificado recientemente y aún no se ha rastreado de nuevo, o si sospecha que el resultado que obtiene Google difiere del navegador, puede utilizar "Probar URL publicada". Revise especialmente los resultados de rastreo y renderizado: si en la captura aparecen zonas en blanco, falta el contenido principal, ventanas emergentes que bloquean la vista, estilos desordenados o errores, el problema normalmente no está en el "tamaño de pantalla", sino en la carga de recursos, el renderizado frontend o las restricciones de acceso.

• Dependencia de JavaScript: si el contenido principal visible al cargar, los parámetros del producto o el contenido de cambio de idioma dependen completamente de la carga asíncrona mediante scripts, debe confirmar que Google puede obtener realmente estos contenidos tras el renderizado.
• Accesibilidad de recursos: si CSS, JavaScript, CDN de imágenes o archivos de fuentes son bloqueados por robots.txt, WAF, restricciones regionales o verificaciones de inicio de sesión, Googlebot obtendrá una página incompleta.
• Coherencia responsive: las versiones de escritorio y móvil no deben perder información esencial de productos, texto principal, enlaces internos o datos estructurados debido a ocultaciones mediante CSS.
• Códigos de estado anómalos: los accesos móviles redirigidos erróneamente, que devuelven 4xx/5xx o conducen a páginas irrelevantes afectarán el rastreo normal.

La inspección de URL sirve para responder si "el motor de búsqueda puede verla", pero no es una herramienta de prueba de velocidad ni puede sustituir las pruebas de interacción del usuario. Un resultado de inspección normal solo indica que no hay obstáculos evidentes en la cadena de indexación.

PageSpeed Insights permite detectar problemas de rendimiento y diseño móvil

PageSpeed Insights (PSI) debe utilizarse como punto de entrada para las revisiones habituales. Después de introducir la dirección web, preste atención a la diferencia entre los "datos de usuarios reales" y los datos de laboratorio de Lighthouse. Los primeros proceden del conjunto de datos de experiencia de usuario de Chrome que cumple los requisitos y reflejan la experiencia de visitas existentes; los segundos se ejecutan en un entorno móvil simulado y son adecuados para localizar problemas de rendimiento reproducibles en la página actual.

En dispositivos móviles deben vigilarse especialmente tres Core Web Vitals: LCP refleja la velocidad con la que aparece el contenido principal; INP refleja la respuesta de interacciones como clics, apertura de menús y envío de formularios; y CLS refleja si los elementos se desplazan durante la carga. No constituyen toda la "adaptación móvil", pero suelen revelar problemas que afectan las consultas y la navegación, como imágenes grandes sin comprimir en la primera pantalla, demasiados scripts de seguimiento de terceros, banners de cookies que comprimen el contenido o imágenes y contenido incrustado sin dimensiones reservadas.

Las recomendaciones de diagnóstico de PSI deben evaluarse según la funcionalidad real de la página, sin perseguir mecánicamente una puntuación perfecta. Los scripts multilingües, herramientas de atención al cliente, validación de formularios, mapas y vídeos habituales en sitios web de comercio exterior incrementan los costes de carga. El orden de actuación más valioso es: primero asegurar que el contenido esencial de la primera pantalla y la entrada de consulta sean utilizables; después comprimir imágenes y retrasar scripts no críticos; por último, evaluar si deben eliminarse componentes de terceros no necesarios.

El modo de dispositivos del navegador solo sirve para una revisión inicial; las pruebas en dispositivos reales siguen siendo indispensables

La barra de herramientas de dispositivos de Chrome DevTools permite cambiar rápidamente el ancho de pantalla, la densidad de píxeles y la limitación de velocidad de red, por lo que resulta adecuada para revisar puntos de ruptura durante un rediseño: si la navegación se contrae correctamente, si las tablas se desbordan horizontalmente, si los botones se recortan o si la información de contacto fija inferior bloquea formularios. Su ventaja es la eficiencia; su limitación es que no puede simular por completo navegadores de distintos sistemas, la aparición del teclado, ventanas de permisos ni fluctuaciones reales de red.

Las páginas que implican consultas, pedidos o descarga de materiales deben completar al menos una prueba de recorrido completo en navegadores móviles habituales: entrar desde una página de destino de búsqueda, cambiar de idioma, abrir el detalle del producto, pulsar WhatsApp, correo electrónico o formulario, y confirmar tras el envío que el aviso de éxito y la notificación por correo funcionan correctamente. Muchas páginas están "adaptadas" visualmente, pero el campo de código de país no puede activar el teclado numérico, el código de verificación queda cubierto por un botón flotante o falla la carga de archivos adjuntos; este tipo de problemas no era detectado automáticamente por el antiguo mobile friendly test.

No confunda "diseño responsive" con "apto para dispositivos móviles"

El CSS responsive resuelve el problema de que el diseño cambie según la pantalla, pero no resuelve automáticamente la experiencia móvil. Los riesgos habituales incluyen: imágenes grandes de escritorio que, al reducirse directamente, hacen que la primera pantalla cargue demasiado lento; tablas de especificaciones de producto difíciles de leer en móviles; jerarquías de menú excesivamente profundas; fuentes pequeñas y enlaces densos que provocan pulsaciones erróneas; ventanas emergentes o anuncios que cubren el contenido principal; y demasiadas animaciones y vídeos de reproducción automática en la versión móvil.

Para las páginas que dependen del tráfico orgánico de Google, también debe comprobarse si las señales de contenido de las versiones móvil y de escritorio son coherentes. Si la versión móvil elimina modelos de productos, descripciones de aplicaciones, FAQ, migas de pan y enlaces a productos relacionados para ser más "concisa", la información que Google puede leer al crear el índice con la versión móvil también se reducirá. La forma correcta no es ocultar simplemente la información, sino mejorar la lectura mediante secciones desplegables, navegación por anclas, párrafos cortos y tablas desplazables horizontalmente, conservando al mismo tiempo el contenido esencial rastreable.

Integre las comprobaciones en el proceso de publicación, en lugar de corregir problemas tras anomalías de indexación

Después de cada cambio de tema, modificación de navegación, integración de scripts de marketing, adición de páginas multilingües o ajuste de CDN, deben revisarse de forma selectiva la página de inicio, las páginas de productos principales, las páginas de contenido y las páginas de destino de formularios. Primero confirme el diseño en el modo de dispositivos del navegador, después consulte el rendimiento móvil y los desplazamientos de diseño con PSI y, por último, realice pruebas de URL publicadas en Search Console para las URL importantes. Si una página ya está indexada pero presenta anomalías de tráfico o impresiones, determine entonces el alcance del problema combinando el estado de "Indexación de páginas", el tiempo de rastreo y la información de página canónica de Search Console.

Tras la retirada de google mobile friendly test, el trabajo de comprobación pasó de un "aprobado/no aprobado" puntual a una verificación continua. Para la ejecución operativa, lo más importante no es buscar un botón de sustitución exactamente igual, sino distinguir entre los tres tipos de problemas de renderizado, rendimiento y recorrido de conversión: si Google no puede ver la página, resuelva primero el rastreo y los recursos; si la página carga lentamente, atienda primero la primera pantalla y los scripts; si los usuarios no pueden completar una acción, vuelva al proceso de prueba en dispositivos reales y corrija cada elemento.