Cómo comprobar si un sitio web es compatible con móviles ahora que la prueba de optimización para móviles de Google ya no existe
Para comprobar si un sitio web es compatible con móviles ahora que la prueba de optimización para móviles de Google (Mobile-Friendly Test) ya no existe, combina cuatro métodos: Lighthouse (en Chrome DevTools o a través de PageSpeed Insights) para una auditoría detallada con emulación de teléfono, el modo dispositivo de DevTools para ver la página con un ancho de 360–430 px, un teléfono real para detectar lo que la emulación no muestra, y nuestra Mobile-Friendly Test para una revisión rápida del código de la página, sin registro: meta viewport, media queries, anchos fijos, texto pequeño y áreas táctiles, junto con una captura de pantalla en iPhone.
A continuación: qué retiró exactamente Google, qué usar en su lugar, una lista de verificación de 15 minutos y soluciones para copiar y pegar de los problemas más comunes.
Qué pasó con la Mobile-Friendly Test de Google
En diciembre de 2023 Google desactivó tres cosas a la vez: la propia Mobile-Friendly Test, su API y el informe de usabilidad móvil de Search Console. La dirección antigua search.google.com/test/mobile-friendly ahora redirige a la descripción general de Lighthouse, que es la indicación de Google sobre su reemplazo.
La herramienta desapareció, pero el requisito no. Google sigue indexando los sitios con su rastreador de smartphone, así que la usabilidad móvil importa tanto como antes. Simplemente ya no existe un veredicto listo de Google que diga "la página es compatible con móviles", así que tienes que comprobarlo tú mismo.
Comparativa de alternativas a la Mobile-Friendly Test de Google
| Método | Qué muestra | Ejecuta JavaScript | Úsalo para |
|---|---|---|---|
| Lighthouse en Chrome DevTools | Auditoría con emulación de teléfono: rendimiento, accesibilidad, SEO y buenas prácticas, incluida la falta de meta viewport | Sí, un navegador real | Un análisis detallado de una página, incluidas páginas protegidas con inicio de sesión o en localhost |
| PageSpeed Insights | El mismo Lighthouse en la nube, más datos de usuarios reales de Chrome (LCP, INP, CLS) cuando Google tiene suficientes | Sí | Velocidad móvil y Core Web Vitals |
| Modo dispositivo de DevTools | La página con el ancho de pantalla elegido, con limitación opcional de red y CPU | Sí | Detectar desbordamientos, solapamientos y elementos que no se pueden tocar |
| Un teléfono real | Toque real, teclado, fuentes del sistema y barras del navegador | Sí | Revisión final de formularios, menús y ventanas emergentes |
| Nuestra Mobile-Friendly Test | 8 comprobaciones de HTML y CSS con pesos transparentes, una puntuación de 0–100 y una captura de pantalla en iPhone | No | Una revisión rápida de cualquier URL, sin instalar nada |
El modo dispositivo es el icono de teléfono y tableta en DevTools, o Ctrl+Shift+M (Cmd+Shift+M en Mac). Consulta la documentación de Chrome para más detalles.
Cómo comprobar si un sitio web es compatible con móviles: paso a paso
- Empieza por el código. Pasa la página por la Mobile-Friendly Test. La falta de viewport, un contenedor de 960–1200 px o el zoom desactivado aparecen de inmediato, incluso antes de abrir un navegador.
- Revísala en DevTools. Activa el modo dispositivo y prueba con 360 px (teléfonos Android estrechos comunes) y 390–430 px (iPhones recientes). Recorre toda la página: ¿hay una barra de desplazamiento horizontal, texto cortado o bloques superpuestos?
- Ejecuta Lighthouse en modo móvil. Pestaña Lighthouse → Dispositivo: Móvil → Analizar carga de página. Lee los hallazgos individuales con referencias a los elementos, no solo las puntuaciones.
- Comprueba la velocidad en PageSpeed Insights. Si el informe muestra arriba una sección de datos de usuarios reales, eso es lo que ve Google. Si no, el sitio tiene muy poco tráfico de Chrome y los números de laboratorio son tu guía.
- Abre la página en un teléfono real. Rellena un formulario, abre el menú, cierra la ventana emergente, gira la pantalla. La emulación no te dirá que el pulgar no alcanza el botón de cerrar o que el teclado tapa el campo de entrada.
- Prueba varios tipos de página. Las páginas de inicio suelen estar bien pulidas; los problemas se esconden en páginas de producto, artículos antiguos con tablas anchas y plantillas de blog.
- Compara el contenido móvil y el de escritorio. El texto, los encabezados, los enlaces, los datos estructurados y los atributos alt deben estar presentes en ambos.
Problemas comunes y cómo solucionarlos
Sin meta viewport
Sin esta etiqueta, el teléfono maqueta la página con unos 980 px de ancho y la reduce, así que todo el texto se vuelve diminuto. Añade esto en <head>:
<meta name="viewport" content="width=device-width, initial-scale=1">Elimina user-scalable=no y maximum-scale=1: bloquear el zoom perjudica a las personas con baja visión, y nuestra herramienta descuenta puntos por ello.
Diseños de ancho fijo
Lo clásico de las plantillas antiguas es width: 960px en el contenedor: una barra de desplazamiento horizontal garantizada en un teléfono. Limita el ancho en su lugar:
.container { max-width: 1200px; width: 100%; margin: 0 auto; padding: 0 16px; box-sizing: border-box; }
img, video, iframe { max-width: 100%; height: auto; }Tablas anchas
Una tabla de seis columnas nunca cabrá en 360 px. La solución más sencilla es dejar que se desplace dentro de su propio contenedor en lugar de romper toda la página:
<div class="table-wrap"><table>…</table></div>
.table-wrap { overflow-x: auto; -webkit-overflow-scrolling: touch; }Si hay muchas columnas y los datos son importantes, convierte las filas en tarjetas en pantallas estrechas con una media query.
Texto pequeño y áreas táctiles pequeñas
Procura que el texto del cuerpo sea de unos 16 px y usa unidades rem. Para las áreas táctiles, el criterio de éxito 2.5.8 de WCAG 2.2 pide al menos 24×24 px CSS, y Material Design recomienda alrededor de 48×48 con espacio entre enlaces vecinos:
html { font-size: 100%; } /* 16px by default */
body { font-size: 1rem; line-height: 1.5; }
.nav a, button { min-height: 48px; padding: 12px 16px; display: inline-flex; align-items: center; }Media queries para pantallas estrechas
Los diseños de varias columnas deben colapsar en una sola columna en un teléfono:
.grid { display: grid; grid-template-columns: repeat(3, 1fr); gap: 24px; }
@media (max-width: 768px) {
.grid { grid-template-columns: 1fr; }
}Ventanas emergentes a pantalla completa
Las directrices de Google indican que no se debe cubrir toda la página con un intersticial, salvo que sea un requisito legal (consentimiento de cookies, verificación de edad). Muestra los avisos de newsletter o de instalación de apps como un banner pequeño que no impida la lectura.
Tecnología obsoleta
Flash, los applets de Java y los framesets no funcionan en teléfonos. Reemplázalos con video HTML5, un diseño normal y páginas separadas.
Por qué importa: la indexación mobile-first
Google usa la versión móvil del contenido de un sitio, rastreada con el agente de smartphone, para la indexación y el posicionamiento. Eso no significa que un sitio sin diseño responsivo desaparezca de los resultados de búsqueda: Google dice que una versión móvil no es obligatoria, pero sí muy recomendable. La conclusión práctica es otra: lo que ve el teléfono es lo que se indexa. Si la versión móvil recorta texto, oculta enlaces o elimina datos estructurados, el buscador tampoco los recibe. Más información en nuestro artículo sobre la indexación mobile-first.
Core Web Vitals en móvil
La usabilidad incluye la velocidad. Google recomienda un LCP (carga del contenido principal) de máximo 2,5 segundos, un INP (capacidad de respuesta) inferior a 200 milisegundos y un CLS (cambio de diseño) inferior a 0,1. En los teléfonos estas cifras casi siempre son peores que en escritorio: CPU más lentas, redes más lentas. Revisa la pestaña móvil de PageSpeed Insights y el informe de Core Web Vitals en Search Console, que separa las URL móviles y de escritorio. Qué significa cada métrica se explica en Core Web Vitals; por dónde empezar a acelerar tu sitio, en velocidad de carga de la página.
Cómo ejecutar la revisión en nuestro Mobile-Friendly Test
Introduce una URL en el Mobile-Friendly Test. La herramienta carga el HTML con un user agent de teléfono Android, lee hasta seis hojas de estilo de tu propio dominio y ejecuta ocho comprobaciones. Cada una vale un número fijo de puntos, y los pesos se muestran en la página:
| Verificación | Puntos | Qué busca |
|---|---|---|
| Meta viewport | 30 | Si la etiqueta existe y usa width=device-width |
| CSS adaptable | 20 | Media queries basadas en el ancho; flex, grid o clamp sin ellas obtienen puntos parciales |
| Anchos fijos | 10 | Reglas CSS y estilos en línea con width superior a 480 px |
| Riesgo de scroll horizontal | 10 | Atributos de ancho grandes, imágenes sin max-width, diseños con tablas anidadas |
| Tamaño de fuente | 10 | Fuente base menor de 12 px, muchas reglas por debajo de 11 px |
| Áreas táctiles | 10 | Enlaces y botones con fuente diminuta o un tamaño menor de 24 px en estilos en línea |
| Zoom | 5 | user-scalable=no o maximum-scale menor que 2 |
| Plugins obsoletos | 5 | Flash, Java, frames |
Junto con los hallazgos recibes una captura de pantalla en emulación de iPhone. Si muestra texto cortado o una barra de desplazamiento, confía más en la captura que en la puntuación. Las señales de ventanas emergentes y el peso de la página se muestran como sugerencias y no afectan la puntuación. Sin cuenta tienes 15 verificaciones al día, 45 con una cuenta gratuita y sin límite en Pro.
Otras herramientas que ayudan
- Captura de pantalla de sitio web: capturas móviles y de escritorio para mostrarle el problema a un desarrollador o comparar el antes y el después. Cómo interpretarlas: captura de pantalla de sitio web en línea.
- Analizador de velocidad de página: peso de HTML, imágenes, CSS y JS, más el tiempo de carga: las imágenes pesadas son una causa frecuente de que una página móvil sea lenta.
- Search Console: el informe de Core Web Vitals con datos separados para móvil y escritorio.
