Canonical: https://www.strataigize.com/es/insights/check-mobile-friendliness-website/
Description: Google retiró su test mobile-friendly. Las herramientas gratis que lo reemplazaron, un ejemplo de API PageSpeed Insights y los umbrales para pasar.
Published: 2025-12-15T00:00:00.000Z
Modified: 2026-09-06T00:00:00.000Z

[← Blog](https://www.strataigize.com/es/insights/)

![](https://www.strataigize.com/blog/real/cover-check-mobile-friendliness-website.webp)

# Test mobile 2026: herramientas gratis y PageSpeed

Por [**Ian McGavin**](https://www.strataigize.com/es/about/team/ian/), Co-Founder & CMO · Publicado 15 de diciembre de 2025 · Actualizado 6 de septiembre de 2026 · 17 min de lectura

Para chequear si un sitio es mobile-friendly en 2026, corra su URL por Google PageSpeed Insights, audítela con Lighthouse en Chrome DevTools, previsualice breakpoints en el modo dispositivo de DevTools, revise el reporte de Core Web Vitals en Search Console, y después confirme todo en un teléfono real. Google retiró su test standalone Mobile-Friendly en diciembre de 2023, así que estas son las herramientas que lo reemplazaron.

En este artículo

1.  [Qué checkers mobile-friendly todavía funcionan en 2026](https://www.strataigize.com/es/insights/check-mobile-friendliness-website/#qu%C3%A9-checkers-mobile-friendly-todav%C3%ADa-funcionan-en-2026)
2.  [Corra una auditoría móvil con PageSpeed Insights y Lighthouse](https://www.strataigize.com/es/insights/check-mobile-friendliness-website/#corra-una-auditor%C3%ADa-m%C3%B3vil-con-pagespeed-insights-y-lighthouse)
3.  [¿Hay un reemplazo para la API Mobile-Friendly Test?](https://www.strataigize.com/es/insights/check-mobile-friendliness-website/#hay-un-reemplazo-para-la-api-mobile-friendly-test)
4.  [Correr Lighthouse en local](https://www.strataigize.com/es/insights/check-mobile-friendliness-website/#correr-lighthouse-en-local)
5.  [Walkthrough de emulación de dispositivo de Chrome DevTools](https://www.strataigize.com/es/insights/check-mobile-friendliness-website/#walkthrough-de-emulaci%C3%B3n-de-dispositivo-de-chrome-devtools)
6.  [Leer datos móviles de Core Web Vitals en Search Console](https://www.strataigize.com/es/insights/check-mobile-friendliness-website/#leer-datos-m%C3%B3viles-de-core-web-vitals-en-search-console)
7.  [Fallas móviles más comunes y fixes](https://www.strataigize.com/es/insights/check-mobile-friendliness-website/#fallas-m%C3%B3viles-m%C3%A1s-comunes-y-fixes)
8.  [La auditoría que corremos, paso a paso](https://www.strataigize.com/es/insights/check-mobile-friendliness-website/#la-auditor%C3%ADa-que-corremos-paso-a-paso)
9.  [Qué pasa si usa WordPress o Shopify](https://www.strataigize.com/es/insights/check-mobile-friendliness-website/#qu%C3%A9-pasa-si-usa-wordpress-o-shopify)
10.  [Preguntas frecuentes](https://www.strataigize.com/es/insights/check-mobile-friendliness-website/#preguntas-frecuentes)
11.  [Cuatro herramientas reemplazaron el badge único](https://www.strataigize.com/es/insights/check-mobile-friendliness-website/#cuatro-herramientas-reemplazaron-el-badge-%C3%BAnico)

[Add us as a preferred source on Google](https://www.google.com/preferences/source?q=strataigize.com)

A free Google setting. It puts our work higher in your own results, changes nothing for anyone else, and you can undo it any time.

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](https://www.strataigize.com/tools/mobile-friendly-test/) 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.

![Reporte móvil de PageSpeed Insights mostrando la evaluación de campo de Core Web Vitals y un puntaje de desempeño de Lighthouse, el chequeo que reemplazó el test Mobile-Friendly retirado de Google](https://www.strataigize.com/blog/real/pagespeed-result.webp)

## 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](https://developers.google.com/search/blog/2023/04/page-experience-in-search), y el sunset se confirmó en cobertura pública el [4 de diciembre de 2023](https://searchengineland.com/google-officially-drops-mobile-usability-report-mobile-friendly-test-tool-and-mobile-friendly-test-api-435377). 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](https://www.seroundtable.com/google-search-consoles-mobile-usability-report-mobile-friendly-tests-are-gone-36497.html) y redirigió las URLs de usabilidad móvil de Search Console al overview de la property. En el [anuncio de abril de 2023](https://developers.google.com/search/blog/2023/04/page-experience-in-search), Google apunta a la gente a [Lighthouse](https://developer.chrome.com/docs/lighthouse/overview) 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](https://www.bing.com/webmaster/tools/mobile-friendliness). 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.

| Herramienta | Costo | Qué mide | Límites |
| --- | --- | --- | --- |
| PageSpeed Insights | Gratis | Corrida lab de Lighthouse móvil más Core Web Vitals de usuarios reales | Los datos de campo necesitan volumen de tráfico; los links de reportes compartibles persisten como snapshots por [hasta 30 días](https://developers.google.com/speed/docs/insights/release_notes) |
| Lighthouse en Chrome DevTools | Gratis | Desempeño emulado en móvil, accesibilidad, best practices, SEO, tap targets | Solo lab; los resultados varían con la carga de su máquina |
| Modo dispositivo de Chrome DevTools | Gratis | Layout, overflow y elementos fijos en tamaños reales de viewport | Emulación, no hardware real ni touch real |
| Core Web Vitals de Search Console | Gratis | Datos de campo móviles de todo el sitio, agrupados por grupo de URL | Ventana rodante de 28 días; sin chequeos de tap-target ni viewport |
| Bing Mobile Friendliness Test | Gratis | Viewport, ancho de contenido, legibilidad, espacio de tap, plug-ins | El veredicto de Bing, no un input de ranking de Google |
| Dispositivos reales o BrowserStack | Tier gratis, planes pagos | Touch verdadero, gestos, rarezas de render de browser | La amplitud de dispositivos cuesta dinero y tiempo |
| Google Mobile-Friendly Test | Ido | Nada | Retirado el 1 de diciembre de 2023 |

### 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](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-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](https://www.strataigize.com/services/website-optimization/).

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

Empiece con [PageSpeed Insights](https://pagespeed.web.dev/). 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](https://developer.chrome.com/docs/crux/methodology/tools). 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](https://web.dev/articles/vitals). 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.

| Métrica | Bueno | Pobre |
| --- | --- | --- |
| Largest Contentful Paint (LCP) | 2.5s o menos | más de 4.0s |
| Interaction to Next Paint (INP) | 200ms o menos | más de 500ms |
| Cumulative Layout Shift (CLS) | 0.1 o menos | más de 0.25 |

Fuente: [umbrales de Core Web Vitals de web.dev](https://web.dev/articles/defining-core-web-vitals-thresholds), actuales al 2026. INP [reemplazó a First Input Delay (FID) como Core Web Vital el 12 de marzo de 2024](https://web.dev/blog/inp-cwv-march-12), 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)](https://developers.google.com/speed/docs/insights/release_notes), 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](https://developers.google.com/speed/docs/insights/release_notes). 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](https://developers.google.com/speed/docs/insights/v5/get-started): 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](https://developers.google.com/speed/docs/insights/v5/get-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](https://developers.google.com/speed/docs/insights/v5/reference/pagespeedapi/runpagespeed) 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](https://developer.chrome.com/docs/crux/api) o la [API CrUX History](https://developer.chrome.com/docs/crux/history-api). 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](https://github.com/GoogleChrome/lighthouse), 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](https://github.com/GoogleChrome/lighthouse/blob/main/docs/throttling.md) 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](https://github.com/GoogleChrome/lighthouse/blob/main/core/config/constants.js), 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](https://developer.chrome.com/blog/lighthouse-13-0), 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](https://developer.chrome.com/docs/lighthouse/seo/tap-targets)
-   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](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) 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](https://search.google.com/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](https://support.google.com/webmasters/answer/9205520). 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](https://support.google.com/webmasters/answer/9205520).

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](https://support.google.com/webmasters/answer/9205520), 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](https://web.dev/articles/lab-and-field-data-differences) con más profundidad. Las mismas métricas se sientan adentro de cómo abordamos la [optimización de sitios](https://www.strataigize.com/services/website-optimization/).

## 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.

| Falla | Detectada por | Umbral o regla | Fix |
| --- | --- | --- | --- |
| Meta tag viewport faltante o mal configurada | Emulación de DevTools, test de Bing | Layout de desktop forzado a un teléfono | Agregue `<meta name="viewport" content="width=device-width, initial-scale=1">` |
| Imagen hero LCP lenta | Campo y lab de PSI, Search Console | LCP debe ser 2.5s o menos en p75 | Comprima, sirva formatos modernos, precargue el elemento LCP, quite lazy loading de él |
| Imágenes y embeds sin dimensiones | Diagnóstico `unsized-images` de Lighthouse | CLS debe ser 0.1 o menos en p75 | Configure width y height o aspect-ratio en cada elemento de media |
| JavaScript de terceros pesado | Lighthouse para trabajo que bloquea; CrUX o monitoreo de usuarios reales para INP | Un INP de campo bueno es 200ms o menos en p75 | Parta tareas largas; revise scripts preservando consentimiento y funcionalidad requerida |
| Tap targets demasiado chicos o demasiado cerca | Auditoría tap-targets de Lighthouse y chequeos en teléfono real | Importan el tamaño y el overlap con targets cercanos | Agrande controles y agregue spacing; 48px es un target cómodo |
| Contenido más ancho que la pantalla | Modo dispositivo de DevTools, test de Bing | Sin scroll horizontal en un viewport de 360px | Tablas fluidas, `max-width: 100%` en media, sin contenedores de píxeles fijos |
| Interstitials intrusivos | Chequeo manual en un teléfono real | Contenido bloqueado al cargar | Retrase, encoja o quite popups de pantalla completa |
| Fonts que cargan tarde y banners inyectados | Grupo CLS de Search Console | CLS en p75 | Precargue fonts, reserve espacio para banners y anuncios |

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](https://support.google.com/webmasters/answer/9205520). 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](https://web.dev/articles/lab-and-field-data-differences) 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](https://web.dev/articles/optimize-lcp). Comprima el hero, sirva un formato moderno, precargue el elemento LCP y no le aplique lazy-load.
-   INP alto: [optimize Interaction to Next Paint](https://web.dev/articles/optimize-inp). Parta tareas largas y difiera o quite JavaScript de terceros que bloquea el main thread.
-   CLS alto: [optimize Cumulative Layout Shift](https://web.dev/articles/optimize-cls). 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](https://support.google.com/webmasters/answer/9205520). 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](https://web.dev/articles/optimize-inp), 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](https://www.strataigize.com/services/website-optimization/search-engine-optimization/).

## 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](https://www.strataigize.com/services/development-services/website-development/).

## 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](https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing), 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](https://www.strataigize.com/insights/what-is-generative-engine-optimization/).

### ¿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](https://developers.google.com/search/docs/appearance/page-experience). 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](https://support.google.com/webmasters/answer/9205520) y [el artículo lab versus campo de web.dev](https://web.dev/articles/lab-and-field-data-differences) 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](https://www.strataigize.com/services/website-optimization/). Si el desempeño móvil le está costando rankings o conversiones, una [auditoría de growth](https://www.strataigize.com/audit/) es el lugar para empezar.

Autor

**Ian McGavin**, Co-founded Strataigize in 2022. AI operations, business strategy, and AI-search visibility.

Siguiente paso

¿Cuánto se le fuga el embudo? La calculadora de crecimiento muestra su CAC real, su ROAS y lo que un alza realista recupera este año.

[Correr la calculadora →](https://www.strataigize.com/es/tools/growth-calculator/)

Hable con nosotros

### Hable con el equipo que lo operaría

Díganos dónde mirar y respondemos en menos de 24 horas con el punto de partida. No hay propuesta hasta que vea el valor.

[Add us as a preferred source on Google](https://www.google.com/preferences/source?q=strataigize.com)

A free Google setting. It puts our work higher in your own results, changes nothing for anyone else, and you can undo it any time.

[Todos los artículos de Sitio y CRO →](https://www.strataigize.com/es/insights/topics/cro-lifecycle/)

## Su sitio puede convertir más de lo que convierte.

Encontramos la fuga, la corregimos y demostramos el alza, con el ingreso como marcador.

[Reservar una auditoría de crecimiento →](https://www.strataigize.com/es/audit/) [Calificación **5.0** en Clutch](https://clutch.co/profile/strataigize-marketing)

[Ver optimización de sitios →](https://www.strataigize.com/es/services/website-optimization/)