Prueba de optimización para móviles: cómo comprobar tu web ahora que la herramienta de Google ya no existe

En resumen: Google retiró su prueba de optimización para móviles (Mobile-Friendly Test), la API de la prueba y el informe de usabilidad móvil de Search Console el 1 de diciembre de 2023. El móvil no se volvió menos importante: Google rastrea e indexa los sitios solo con su rastreador de smartphone, y el contenido al que no se puede acceder desde un teléfono no es indexable. Para probar un sitio hoy, revisa lo básico (etiqueta viewport, imágenes que se adaptan, texto legible, áreas táctiles) con un verificador rápido y Lighthouse, mira la página en teléfonos reales y confirma que la versión móvil tiene el mismo contenido que la de escritorio.

Durante años, "prueba de optimización para móviles" significaba una sola cosa: pegar una URL en la herramienta de Google y obtener un banner verde de "La página está optimizada para móviles". Esa herramienta ya no existe, y muchas guías todavía enlazan a ella. Este artículo explica qué pasó, qué espera Google ahora de las páginas móviles, cómo probarlas con herramientas que sí funcionan, incluida nuestra prueba de optimización para móviles gratuita, y cómo corregir cada problema.

Qué pasó con la Mobile-Friendly Test de Google

En una publicación de abril de 2023 sobre la experiencia de página, Google anunció: "Also starting December 1, 2023, we'll be retiring Search Console's 'Mobile Usability' report, the Mobile-Friendly Test tool and Mobile-Friendly Test API." El motivo que dio no fue que lo móvil dejara de importar. Señaló que habían surgido muchos recursos sólidos para evaluar la usabilidad móvil, "including Lighthouse from Chrome".

Así que desde diciembre de 2023 no existe un aprobado o suspenso oficial de Google para la optimización móvil. Los verificadores de terceros, Lighthouse y tus propias pruebas llenan ese vacío.

Por qué el móvil sigue decidiendo cómo te indexan

Dos anuncios importan más que la herramienta retirada:

1. La indexación mobile-first está completa. En octubre de 2023 Google escribió que "the trek to Mobile First Indexing is now complete" (anuncio). Su página de buenas prácticas define qué significa: "Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking."
2. El rastreo con escritorio terminó para Search. En junio de 2024 Google dijo: "After July 5, 2024, we'll crawl and index these sites with only Googlebot Smartphone" y "If your site's content is not accessible at all with a mobile device, it will no longer be indexable" (anuncio).

La consecuencia práctica: lo que muestre tu versión móvil es tu página a ojos de Google. El texto oculto en móvil, una sección que falta o un título distinto en la plantilla móvil es lo que se indexa.

La experiencia de página añade una segunda capa. La guía de experiencia de página de Google pregunta "Does your content display well on mobile devices?" y dice que sus sistemas principales de clasificación "look to reward content that provides a good page experience", aunque insiste en que no existe una única señal de experiencia de página.

Qué significa "optimizado para móviles" en la práctica

Ya no hay una lista oficial, pero la documentación de Google y web.dev cubren el terreno:

Google recomienda el diseño web adaptable (responsive) "because it's the easiest design pattern to implement and maintain". Una URL, un documento HTML, CSS que se adapta: los problemas de paridad casi desaparecen.

Cómo probar la optimización para móviles hoy

Usa varias herramientas, porque cada una ve una parte distinta del panorama:

1. Una revisión rápida de lo básico. Nuestra prueba de optimización para móviles gratuita comprueba la etiqueta viewport, las imágenes adaptables, el favicon y el idioma de la página en unos 20 segundos (detalles más abajo).
2. Lighthouse en Chrome. Ejecútalo desde DevTools con la configuración móvil. Desde Lighthouse 13 (octubre de 2025), la comprobación del viewport está en el insight "Optimize viewport for mobile", y la antigua auditoría de tamaño de fuente legible se eliminó sin sustituto.
3. Modo dispositivo de Chrome DevTools. Arrastra el ancho desde 320 px hacia arriba y busca barras de desplazamiento horizontales, elementos superpuestos y texto que se sale de su caja.
4. Teléfonos reales. Usa al menos un Android pequeño y un iPhone. Prueba el menú, los formularios y el proceso de compra con el pulgar.
5. Inspección de URL de Search Console. La prueba en vivo muestra una captura de la página tal como la renderiza Googlebot Smartphone, además del HTML renderizado, para que confirmes que el contenido que te importa está ahí.
6. Datos de velocidad de usuarios reales. Core Web Vitals de los visitantes desde teléfono, a partir del Chrome User Experience Report. Nuestra guía de Core Web Vitals explica cómo interpretarlos.

Cómo funciona la prueba de optimización para móviles de Searvia

La prueba de optimización para móviles gratuita ejecuta nuestra auditoría web completa (38 comprobaciones) y coloca las cuatro comprobaciones móviles arriba del todo. Introduce un dominio o la dirección de una página y obtiene esa página (la página de inicio si solo pones el dominio), siguiendo las redirecciones, y lee el HTML que envía tu servidor sin ejecutar JavaScript.

Algunos detalles sobre cómo evalúa:

• La comprobación del viewport da fallo y no aviso porque una página sin etiqueta viewport está rota en todos los teléfonos, no solo un poco peor.
• En los favicons, el recurso alternativo /favicon.ico solo cuenta si devuelve un archivo real, no una página de error HTML.
• La comprobación del idioma muestra las dos primeras letras del código, así que en-GB aparece como "en".

El informe completo incluye también la sección de velocidad, donde la comprobación de Core Web Vitals lee el LCP, INP y CLS en el percentil 75 de los visitantes desde teléfono a partir de los datos de usuarios reales de Chrome: de la página que introdujiste si Chrome tiene datos suficientes, y si no, de todo el sitio.

Lo que no hace: no renderiza la página en un navegador del tamaño de un teléfono, así que no ve el desbordamiento horizontal, los tamaños de fuente, el espaciado de las áreas táctiles ni los pop-ups. Para eso están Lighthouse, el modo dispositivo y los teléfonos reales. Piensa en el verificador como el triaje de cinco minutos y en las pruebas manuales como la inspección.

Cómo leer los resultados

• Viewport con fallo: corrígelo primero; nada más en la página importa hasta que el diseño se ajuste a la pantalla.
• Aviso de imágenes adaptables: los teléfonos descargan imágenes del tamaño de escritorio. No está roto, pero es más lento, sobre todo en redes móviles.
• Avisos de favicon o idioma: arreglos pequeños y rápidos que mejoran cómo apareces en los resultados de Google y cómo los lectores de pantalla tratan la página.
• "Too few images to judge": neutral. Con menos de tres imágenes, la proporción no dice mucho.

Cómo corregir cada problema

"The page has no mobile viewport tag."

1. Añade esta línea dentro de <head> en todas las plantillas:

<meta name="viewport" content="width=device-width, initial-scale=1">

1. No añadas user-scalable=no ni un maximum-scale bajo. web.dev lo desaconseja "because they can prevent the user from zooming".
2. Comprueba que solo haya una etiqueta viewport. Un tema y un plugin pueden imprimir una cada uno; la segunda puede anular a la primera.
3. Recarga en un teléfono. Si ahora la página muestra un diseño de escritorio apretado en lugar de uno diminuto, el viewport funciona y el CSS necesita reglas responsive (ver más abajo).

Hacer el diseño adaptable

Una etiqueta viewport solo le dice al navegador que use el ancho de pantalla. El CSS aún tiene que adaptarse:

• Da a imágenes y vídeos max-width: 100%; height: auto; para que nunca se desborden.
• Usa anchos flexibles (porcentajes, fr, min()) en lugar de anchos fijos en píxeles para los contenedores.
• Añade media queries donde el diseño se rompa, no en anchos de dispositivos concretos. web.dev: "Design the content to fit on a small screen size first, then expand the screen until a breakpoint becomes necessary."
• Envuelve las tablas anchas en un contenedor con desplazamiento en lugar de dejar que la página se desplace hacia los lados.

"N of M images use srcset."

Ofrece varios tamaños y deja que el navegador elija, como se describe en MDN:

<img
  src="/img/boots-800.jpg"
  srcset="/img/boots-480.jpg 480w, /img/boots-800.jpg 800w, /img/boots-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="Botas de montaña de cuero marrón sobre una roca mojada"
  width="800" height="600">

srcset enumera los archivos y sus anchos; sizes le dice al navegador qué ancho tendrá la imagen en pantalla. Para imágenes de tamaño fijo como logotipos, usa descriptores x (logo.png, logo@2x.png 2x). WordPress añade srcset automáticamente a las imágenes insertadas desde el editor; la mayoría de las CDN de imágenes pueden generar los tamaños por ti. Añade también width y height, para que el navegador reserve espacio y el diseño no salte.

"No favicon was found."

1. Crea un icono cuadrado. Google exige una proporción 1:1, de al menos 8 × 8 px, y recomienda más de 48 × 48 px (directrices de favicon).
2. Añádelo al head de la página de inicio:

<link rel="icon" href="/favicon.ico" sizes="48x48">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

1. Mantén la URL estable y asegúrate de que robots.txt no bloquee el archivo; Google necesita rastrear tanto la página de inicio como el icono. Google admite un favicon por nombre de host.

"The page does not declare its language."

Define el idioma en el elemento raíz:

<html lang="es">

Usa un código BCP 47 válido como en, en-GB, pt-BR o tr. El atributo lang permite que los lectores de pantalla pronuncien bien el texto y es obligatorio para el criterio "Language of Page" de WCAG (MDN). Una aclaración: Google dice que detecta el idioma de una página a partir del propio texto, no de lang, así que esto es más una corrección de accesibilidad y de navegador que de posicionamiento.

Más allá de las cuatro comprobaciones

Cuando lo básico pase, trabaja en las partes que ningún verificador automático cubre del todo:

• Paridad de contenido. Compara móvil y escritorio para la misma URL: texto principal, encabezados, imágenes con el mismo texto alternativo, datos estructurados, título, meta descripción y metaetiquetas robots. Google las enumera todas en sus buenas prácticas de mobile-first.
• Carga diferida (lazy loading). Google advierte: "Don't lazy-load primary content upon user interaction." Googlebot no toca "Leer más" ni desliza carruseles.
• Áreas táctiles. Botones y enlaces de unos 48 × 48 px con espacio entre ellos. Lighthouse marca los elementos menores de 48 × 48 px cuando se solapan con los vecinos.
• Tamaño del texto. Texto del cuerpo legible sin zoom. Lighthouse ya no audita el tamaño de fuente, así que compruébalo en un teléfono real.
• Pop-ups. Los banners de cookies y formularios de newsletter que tapan el contenido en una pantalla pequeña entran en la cuestión de Google sobre los interstitials intrusivos.
• Velocidad en teléfonos. Las CPU y las redes de los teléfonos son más lentas; revisa los datos de campo de móvil por separado de los de escritorio.

Si tienes un sitio móvil independiente

Algunos sitios antiguos sirven a los teléfonos desde otra dirección, como m.example.com, o envían HTML distinto a los teléfonos desde la misma URL (servicio dinámico, o dynamic serving). Google sigue admitiendo ambos, pero dificultan la paridad, y sus buenas prácticas añaden reglas extra para las URL independientes:

• El estado de error debe ser el mismo en ambas versiones: una página que devuelve 404 en escritorio no debe devolver 200 en móvil, y viceversa.
• La versión móvil no debe usar fragmentos de URL (#) para el contenido.
• Las reglas de robots.txt deben coincidir, para que Googlebot pueda rastrear las mismas secciones en ambos hosts.
• Las páginas de escritorio apuntan a sus versiones móviles con rel="alternate", y las páginas móviles apuntan de vuelta con rel="canonical".
• hreflang debe configurarse por separado para cada versión.

Si de todos modos estás planificando un rediseño, pasar a un diseño responsive en una sola URL elimina toda esta categoría de problemas. Nuestro verificador gratuito lee la versión que tu servidor envía a su propio rastreador, así que en un sitio con servicio dinámico, prueba la versión para teléfonos por separado con Lighthouse o la Inspección de URL.

Ejemplo práctico (hipotético)

El siguiente es un ejemplo hipotético, no datos reales. Cobble & Crumb, una panadería inventada con un sitio programado a mano en 2016, recibe la mayoría de las visitas desde teléfonos y le siguen pocos pedidos. La prueba de optimización para móviles informa:

• Viewport móvil, fallo: no hay etiqueta viewport.
• Imágenes adaptables: 1 de 14 imágenes usa srcset.
• Favicon: correcto.
• Idioma de la página, aviso: no hay atributo lang.

El dueño añade la etiqueta viewport y lang="en", y luego abre el sitio en un teléfono: el texto ya tiene tamaño normal, pero el contenedor de ancho fijo de 960 px obliga a desplazarse hacia los lados. Un desarrollador sustituye el ancho fijo por max-width: 960px; width: 100%, añade max-width: 100% a las imágenes, apila el menú de tres columnas en una sola por debajo de 600 px y aumenta los botones de pedido a 48 px de alto. Las fotos de producto reciben srcset con versiones de 480, 800 y 1600 px. En una segunda ejecución pasan el viewport y el idioma, las imágenes adaptables ya pasan con 13 de 14, y el insight de viewport de Lighthouse está limpio. El trabajo restante es de contenido: el diseño móvil había ocultado el horario de apertura, que vuelve a la página.

Una lista de verificación móvil de 30 minutos

1. Ejecuta la prueba de optimización para móviles y corrige primero una etiqueta viewport ausente.
2. Abre tus cinco páginas principales en un teléfono real. Busca desplazamiento lateral, texto diminuto y botones difíciles de pulsar.
3. Ejecuta Lighthouse en modo móvil sobre las mismas páginas.
4. Compara el contenido móvil y de escritorio de cada plantilla de página.
5. Añade srcset a las imágenes grandes, un favicon y el atributo lang.
6. Revisa los Core Web Vitals en teléfono y corrige la plantilla más lenta.

Cómo te ayuda Searvia a mantenerte listo para móviles

La prueba de optimización para móviles gratuita comprueba lo básico en tu página de inicio, o en cualquier página que introduzcas, en unos 20 segundos y sin registro, junto con otras 34 comprobaciones sobre apariencia en búsqueda, rastreo, preparación para la búsqueda con IA, velocidad y seguridad.

Para un seguimiento continuo, una cuenta gratuita de Searvia añade el seguimiento de velocidad de página: puntuaciones de laboratorio y datos reales de usuarios de Chrome de tus páginas más visitadas, revisados cada semana, con las correcciones ordenadas por tiempo estimado ahorrado. La auditoría del sitio rastrea todas las páginas en busca de los problemas que perjudican tanto a móvil como a escritorio, como títulos ausentes, enlaces rotos y contenido escaso. Para el resto de la lista técnica, consulta nuestra guía de auditoría SEO técnica.