Test mobile 2026: herramientas gratis y PageSpeed

Google retiró su test standalone Mobile-Friendly en diciembre de 2023, pero todavía puede chequear la usabilidad móvil gratis. Use PageSpeed Insights y Lighthouse para diagnósticos de desempeño, Chrome DevTools para chequeos de layout, y un teléfono real para navegación y formularios. Estos chequeos responden preguntas distintas. Una página rápida todavía puede tener botones a los que no llega, y una página usable todavía puede cargar lento.

¿Quiere el veredicto en 20 segundos? Corra nuestro test mobile-friendly gratis: pegue una URL y obtenga los chequeos de viewport, ancho fijo, texto chico, peso y rastreo puntuados, con el fix de cada uno. Sin email.

Qué checkers mobile-friendly todavía funcionan en 2026

El consejo de «corra el Mobile-Friendly Test de Google» está muerto. Google anunció que estaba sunseteando el reporte de Mobile Usability de Search Console, la herramienta Mobile-Friendly Test y la API Mobile-Friendly Test a partir del 1 de diciembre de 2023, y el sunset se confirmó en cobertura pública el 4 de diciembre de 2023. La razón declarada de Google en ese anuncio: la usabilidad móvil sigue siendo parte de su guía de page experience, pero han surgido otros recursos desde 2015, «incluido Lighthouse de Chrome.»

Google también borró cada mención de la herramienta de los docs de ayuda de Search el 1 de diciembre de 2023 y redirigió las URLs de usabilidad móvil de Search Console al overview de la property. En el anuncio de abril de 2023, Google apunta a la gente a Lighthouse como el reemplazo. Una guía que todavía ofrece la herramienta retirada como una opción live está desactualizada.

Un checker separado sigue disponible: la herramienta Mobile Friendliness Test de Bing. Chequea cómo Bing ve la página en móvil, incluida la configuración de viewport, el ancho del contenido, la legibilidad y el espacio de tap. Su veredicto no establece cómo Google o un asistente de IA van a rankear o citar la página.

La usabilidad móvil y el mobile-first indexing son chequeos distintos

Google usa la versión móvil del contenido de una página para indexar y rankear. Su guía de mobile-first indexing soporta diseño responsive, serving dinámico y URLs móviles separadas. El diseño responsive es la opción recomendada porque es más fácil de implementar y mantener.

Chequee que Googlebot pueda acceder al contenido, las imágenes y los metadatos en móvil. Después chequee qué tan fácil puede usarlos una persona. Una página móvil bloqueada es un problema de rastreo; un botón apretado es un problema de usabilidad. Ni un puntaje de Lighthouse ni una medición de tap-target sola le dice si una página va a ser indexada.

¿Quiere ojos expertos en su sitio en vez de otra pestaña de auditoría? Vea nuestros servicios de optimización de sitios.

Corra una auditoría móvil con PageSpeed Insights y Lighthouse

Empiece con PageSpeed Insights. Pegue una URL, córrela, y lea el tab Mobile antes del tab Desktop.

El reporte se parte en dos mitades que la gente confunde todo el tiempo:

• Datos de campo arriba: mediciones reales de usuarios de Chrome del Chrome UX Report, actualizadas a diario en una ventana rodante de 28 días. Esto es lo que de verdad usan las señales de page experience de Google.
• Datos de lab abajo: una sola corrida simulada de Lighthouse en los servers de Google. Útil para diagnósticos, no un veredicto sobre usuarios reales.

Para pasar una evaluación completa de tres métricas de Core Web Vitals (las tres medidas de velocidad y estabilidad que Google usa para juzgar la experiencia de una página), una página necesita el umbral bueno en el percentil 75 de las tres métricas. Que falten datos de campo significa que el reporte no puede dar esa evaluación completa; no es evidencia de que la página falló. Lighthouse no puede medir INP de campo a partir de una sola corrida de navegación.

Fuente: umbrales de Core Web Vitals de web.dev, actuales al 2026. INP reemplazó a First Input Delay (FID) como Core Web Vital el 12 de marzo de 2024, así que ignore cualquier checklist que todavía le diga que optimice FID.

Dos cambios de PageSpeed Insights que movieron los postes

El 5 de diciembre de 2024, PageSpeed Insights ajustó qué tan fuerte throttlea la CPU (el procesador), lo que en general subió el Total Blocking Time en las corridas lab móviles. Los resultados de campo y desktop no se afectaron. Si su puntaje lab móvil cayó y no se envió nada, esa es una causa plausible.

PageSpeed Insights (PSI) y su API pasaron a Lighthouse 13.0 el 20 de octubre de 2025. Las versiones pueden cambiar qué diagnósticos ve, así que registre la versión de Lighthouse con cada resultado. Para monitoreo continuo de usuarios reales, Google recomienda la API CrUX o la API CrUX History: planea dejar de incluir datos de campo CrUX en la API de PSI.

¿Hay un reemplazo para la API Mobile-Friendly Test?

La vieja API Mobile-Friendly Test se retiró con la herramienta. La API de PageSpeed Insights puede automatizar una corrida móvil de Lighthouse, pero no reproduce el viejo resultado pass/fail mobile-friendly. Todavía necesita chequeos de layout e interacción.

Este request pide diagnósticos móviles de desempeño, accesibilidad y SEO. Reemplace la URL de ejemplo con una página pública que quiera testear:

curl --get \
  'https://www.googleapis.com/pagespeedonline/v5/runPagespeed' \
  --data-urlencode 'url=https://example.com/' \
  --data-urlencode 'strategy=mobile' \
  --data-urlencode 'category=performance' \
  --data-urlencode 'category=accessibility' \
  --data-urlencode 'category=seo'

La guía de getting-started de Google permite probar la API sin una key y recomienda una key para requests automatizados frecuentes. Chequee la cuota actual de su proyecto antes de programar un batch. Si la respuesta es HTTP 429, investigue la cuota en vez de tratarla como un resultado de la página testeada. La referencia de la API documenta los parámetros y los campos de respuesta.

Lea lighthouseResult.categories para los puntajes de categoría y lighthouseResult.audits para los resultados individuales. Los puntajes usan una escala de cero a uno; 0.92 corresponde a 92 de 100. Guarde fetchTime y lighthouseVersion con la URL testeada para que las comparaciones posteriores usen una corrida conocida. Maneje errores HTTP y runtimeError antes de tratar una respuesta como una auditoría.

Para desempeño de campo, use la API CrUX o la API CrUX History. Una URL puede tener datos insuficientes de usuarios reales. Mantenga ese estado separado de un resultado pobre, y no reporte un puntaje lab como un pass de Core Web Vitals de campo.

Correr Lighthouse en local

Lighthouse viene adentro de Chrome DevTools. Abra su página, click derecho, elija Inspect, abra el panel Lighthouse, seleccione Mobile, y después click en Generate report. Corre contra su Chrome instalado y nunca envía resultados a un server remoto, así que puede auditar builds de staging y protegidos por contraseña a los que PSI no llega.

El preset móvil no es una adivinanza. Lighthouse aplica un multiplicador de 4x de slowdown de CPU para arrastrar una CPU de desktop al rango móvil mid-tier, más un preset de red «Slow 4G» que representa el cuarto de abajo de las conexiones 4G. La emulación de dispositivo usa un perfil Moto G Power en un viewport de 412 por 823 con un factor de escala de dispositivo de 1.75, móvil y touch habilitados, según el propio constants.js de Lighthouse (una versión anterior de este artículo citó 2.625, el factor de escala del perfil más viejo de Moto G4 que Lighthouse retiró, no el valor actual).

Lighthouse 13 reemplazó muchas auditorías de desempeño con insights alineados a DevTools, y mantuvo unsized-images y non-composited-animations como diagnósticos. También quitó la vieja auditoría de font-size. Un diagnóstico quitado no vuelve aceptable el texto ilegible; chequee el texto real de la página en un teléfono.

Walkthrough de emulación de dispositivo de Chrome DevTools

Los puntajes le dicen velocidad. La emulación le dice si la página es usable. Corra ambos.

1. Abra la página en Chrome y presione el atajo de Inspect, y después active la Device Toolbar.
2. Elija primero un viewport estrecho. Testee a 360 por 800 y 390 por 844, y después suba a través de anchos de tablet.
3. Configure el throttling a Mid-tier mobile o aplique Slow 4G más 4x CPU a mano para calzar el perfil de Lighthouse.
4. Pase a orientación horizontal. Abra su navegación principal, un formulario y un paso de checkout o contacto en cada orientación.
5. Mire el panel Elements mientras redimensiona para hallar qué contenedor hace overflow.

Lo que la emulación atrapa y un puntaje nunca va a atrapar:

• Tap targets chicos apretados contra un vecino, incluidos casos cubiertos por la auditoría tap-targets de Lighthouse
• Overflow horizontal de una tabla de ancho fijo, un embed o una imagen sobredimensionada
• Headers sticky y banners de cookies que se comen la mitad del viewport en una pantalla corta
• Modals con un botón de cerrar empujado fuera del canvas
• Inputs que disparan el teclado equivocado o zoom al foco

Para controles táctiles cómodos, apunte a 48 por 48 píxeles CSS donde el layout lo permita. La regla documentada de Lighthouse considera tanto el tamaño del target como el overlap con targets cercanos; no falla cada control más chico. El criterio separado de target-size de WCAG 2.2 AA usa 24 por 24 píxeles CSS con spacing y otras excepciones. Ninguno es un umbral universal de ranking de Google.

Conozca el techo. La emulación redimensiona un browser de desktop y finge una CPU lenta. No reproduce latencia real de touch, rarezas de iOS Safari, el alcance del pulgar, ni la forma en que un Android mid-range maneja un script pesado bajo thermal throttling. Termine cada auditoría en un teléfono real.

Leer datos móviles de Core Web Vitals en Search Console

El viejo reporte de Mobile Usability se fue. Use el reporte de Core Web Vitals de Search Console para el desempeño de usuarios reales, y después inspeccione layout e interacciones por separado.

Abra Search Console, vaya a Core Web Vitals y trabaje el reporte Mobile. Google parte el overview por dispositivo, agrupa URLs que entregan experiencias similares y asigna a cada grupo el status de su métrica de peor desempeño. Así que una métrica mala en un template arrastra cada URL de ese template a Poor.

Cómo lo leemos:

• Click Open report al lado del chart móvil, y después alterne los tabs Poor, Needs improvement y Good.
• Lea la tabla «Why URLs aren’t considered good». Nombra la métrica que falla y el umbral que se rompió.
• Arregle el template, no la URL. El status a nivel de grupo significa que un fix de template mueve muchas páginas.
• Use Start Tracking después de deployar. Google corre una sesión de monitoreo de 28 días y marca el issue como fijo solo si se mantiene ausente durante la ventana completa.

Dos caveats. Los datos son un agregado rodante de 28 días, así que un fix enviado el martes no se va a ver el miércoles. Y Google dice con claridad que los datos de PageSpeed Insights pueden variar del reporte de Core Web Vitals, porque uno es una corrida lab en un perfil de dispositivo y el otro son miles de sesiones reales. Cuando no coinciden, confíe en los datos de campo y use la corrida lab para hallar la causa. web.dev explica el split lab versus campo con más profundidad. Las mismas métricas se sientan adentro de cómo abordamos la optimización de sitios.

Fallas móviles más comunes y fixes

Estas son las fallas que las herramientas de arriba están construidas para atrapar, con el umbral o la regla que usa cada una.

Note qué herramienta detecta qué. Ningún checker solo cubre la lista, que es exactamente por qué el viejo badge único de pass o fail nunca alcanzó.

La auditoría que corremos, paso a paso

Aquí está la secuencia que usamos en nuestro propio sitio y en sitios de clientes, en orden.

1. Elija tres URLs, no una. Homepage, una página top de servicio o producto, y un post de blog. Los templates fallan de forma distinta.
2. Search Console primero. Core Web Vitals, vista Mobile. Note qué grupos de URL se sientan en Poor o Needs improvement y qué métrica se nombra. Estos son usuarios reales, así que fija la prioridad.
3. PSI en una URL de cada grupo que falla. Compare datos de campo con datos de lab. Si el campo dice Poor y el lab dice bien, busque scripts de terceros, estados logged-in u orígenes lentos que una corrida lab limpia nunca ve.
4. Lighthouse en local en las mismas tres URLs. Preset Mobile. Lea los diagnósticos tap-targets y unsized-images, y el panel Accessibility para fallas de contraste.
5. Modo dispositivo de DevTools a 360 por 800. Abra el nav, un formulario y el paso primario de conversión. Rote. Busque overflow y contenido bloqueado.
6. El Mobile Friendliness Test de Bing en las mismas URLs para el veredicto de un segundo crawler sobre viewport, ancho, legibilidad y espacio de tap.
7. Un teléfono real, Android mid-range si tiene uno. Cargue por celular, no por el wifi de la oficina. Complete la acción de conversión de punta a punta.
8. Envíe fixes de template, y después Start Tracking en Search Console y espere 28 días antes de que la validación limpie.

Por qué no coinciden los datos de campo y los de lab

Google es explícito en que los datos de PageSpeed Insights pueden variar del reporte de Core Web Vitals. Los datos de lab son una corrida simulada en un perfil de dispositivo. Los datos de campo son un agregado rodante de 28 días de usuarios reales de Chrome. La guía de web.dev sobre datos lab versus campo nombra las causas usuales: los dispositivos y redes reales varían más que el lab, los scripts de terceros se comportan distinto para usuarios reales, el cache y el back-forward cache cambian las visitas de retorno, y CrUX solo reporta URLs con tráfico suficiente. Cuando no coinciden, trate los datos de campo como el veredicto y la corrida lab como el diagnóstico.

Cuando revisamos un sitio miramos primero los datos de campo de Search Console, y después usamos PSI y Lighthouse para nombrar el elemento o el script. Las propias guías de optimize de Google son los playbooks:

• LCP lento: optimize Largest Contentful Paint. Comprima el hero, sirva un formato moderno, precargue el elemento LCP y no le aplique lazy-load.
• INP alto: optimize Interaction to Next Paint. Parta tareas largas y difiera o quite JavaScript de terceros que bloquea el main thread.
• CLS alto: optimize Cumulative Layout Shift. Configure width, height o aspect-ratio en imágenes y embeds para que el layout no salte cuando cargan.

Search Console agrupa URLs que entregan experiencias similares y asigna a cada grupo el status de su métrica de peor desempeño. Un fix de template, como dimensiones de imagen en un componente compartido de card, puede mover muchas URLs de una vez. Después de enviar, use Start Tracking y espere la ventana completa de 28 días antes de que Google marque el issue como fijo.

Repita la secuencia de ocho pasos después de cambios de theme, instalaciones de plugins o apps, y cualquier deployment de tag manager, más un pass trimestral programado. Los scripts de terceros son un riesgo documentado de INP en la guía de INP de Google, que es por qué el paso 3 compara datos de campo con una corrida lab limpia. Para rastreo, indexación y trabajo on-page alrededor de este chequeo móvil, vea nuestro servicio de optimización para motores de búsqueda.

Qué pasa si usa WordPress o Shopify

Ambas plataformas lo llevan la mayor parte del camino con configuración más que con código:

• Un theme responsive, testeado a 360px antes de comprometerse con él
• Lazy loading nativo en todas partes excepto la imagen LCP
• Formatos modernos de imagen servidos en las dimensiones correctas, no archivos de desktop encogidos con CSS (cascading style sheets, las hojas de estilo que controlan el look de una página)
• Templates Shopify Online Store 2.0 y sizing de imagen a nivel de sección
• Una auditoría de apps y plugins instalados, porque cada uno suele agregar JavaScript que bloquea el render

Vuelva a correr Lighthouse después de cada cambio de theme o app. Ahí es donde los puntajes móviles se resbalan en silencio. Si el theme mismo es el techo, el fix es un rebuild en un framework moderno con desempeño y SEO diseñados desde el principio, que es lo que entrega nuestro servicio de desarrollo de sitios.

Preguntas frecuentes

¿Cómo chequeo si un sitio es mobile-friendly ahora que el test de Google se fue?

Corra Lighthouse en Chrome DevTools en el preset Mobile, chequee el tab Mobile en PageSpeed Insights, lea el reporte móvil de Core Web Vitals en Search Console, y después confirme en un teléfono real. El Mobile Friendliness Test de Bing todavía da un veredicto de pass o fail si quiere uno.

¿Cuál es la diferencia entre mobile-friendly y responsive?

Mobile-friendly significa que la página es usable en un teléfono. El diseño responsive adapta la misma página a distintos viewports con layouts fluidos y media queries de CSS. Google recomienda el diseño responsive para un mantenimiento más fácil, pero también soporta serving dinámico y URLs móviles separadas.

¿Necesito un sitio móvil separado?

No. Una sola URL responsive es más simple de mantener, evita el manejo de contenido duplicado, y da un solo set de señales para SEO y optimización para motores generativos.

¿Google penaliza los sitios que no son mobile-friendly?

Chequee el acceso al contenido y la experiencia de usuario por separado. Google necesita acceder y renderizar su contenido móvil para indexar. Los Core Web Vitals se usan en ranking, pero Google sigue buscando contenido relevante incluso cuando la page experience es sub-par. Un puntaje móvil pobre no prueba por sí solo deindexación, una penalización ni una pérdida particular de rankings.

¿Por qué no coinciden PageSpeed Insights y Search Console?

Google afirma que los dos pueden diferir. Los datos lab de PSI son una corrida simulada en un perfil de dispositivo. Search Console reporta un agregado rodante de 28 días de usuarios reales de Chrome a través de un grupo de URL. La documentación del reporte de Core Web Vitals de Google y el artículo lab versus campo de web.dev le dicen que trate los datos de campo como el veredicto y los datos de lab como el diagnóstico.

Cuatro herramientas reemplazaron el badge único

El badge único de pass o fail se fue y no va a volver. Lo que lo reemplazó es mejor: medición de campo de usuarios reales, una auditoría lab que puede correr en staging, emulación de viewport para layout, y el veredicto de un segundo crawler de Bing. Construya su proceso alrededor de esas cuatro, priorice por lo que Search Console dice que experimentan los usuarios reales, y arregle templates más que URLs individuales.

Manejamos esto desde Vancouver como optimización de sitios. Si el desempeño móvil le está costando rankings o conversiones, una auditoría de growth es el lugar para empezar.