Una auditoría web móvil es una revisión ordenada de cómo funciona tu sitio en un celular real: si carga rápido con datos móviles, si se lee sin hacer zoom, si los botones se pueden tocar con el pulgar, si el formulario se completa sin frustración y si Google ve lo mismo que ve tu cliente. Para una web WordPress, se resuelve en diez pasos que puedes hacer en una tarde, con herramientas gratuitas y tu propio teléfono.
La razón para hacerla no es teórica. Según el INEI, en el primer trimestre de 2026 el 90.7 % de los usuarios de internet de 6 años a más se conectaba por celular. Si tu web falla en el teléfono, falla para casi todos tus visitantes. Abajo tienes el checklist completo que usamos como referencia, con qué medir en cada paso, qué resultado buscar y cómo corregirlo en WordPress.
Actualizado: octubre de 2026
Lo esencial
- Google indexa y evalúa tu web a partir de su versión móvil: lo que no está en el celular, para Google casi no existe.
- La prueba de «compatibilidad con móviles» de Google ya no existe. Hoy se audita con PageSpeed Insights, Lighthouse, Search Console y un teléfono de gama media.
- Los tres números a vigilar son los Core Web Vitals: LCP de 2.5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0.1 o menos.
- La mayoría de problemas móviles en WordPress vienen de tres fuentes: imágenes pesadas, plugins que cargan scripts en todas las páginas y diseños pensados primero para escritorio.
- Haz la auditoría completa una vez al año y una versión corta (pasos 1, 2 y 7) después de cada cambio grande en la web.
Por qué la versión móvil es la que Google evalúa
Desde octubre de 2023, Google da por terminado su cambio a la indexación basada en móvil. Lo anunció en su blog oficial para desarrolladores: el rastreo e indexación mobile-first ya cubre prácticamente todos los sitios. En la práctica, Googlebot visita tu web como si fuera un smartphone. Si en la versión móvil escondiste un bloque de texto, quitaste una tabla de precios o reemplazaste el menú por algo que no enlaza bien, Google trabaja con esa versión recortada.
El segundo motivo es comercial. El estudio de IAB Perú y PwC sobre inversión publicitaria 2025, reportado por RPP, indica que el 82 % de la inversión digital en el país se destinó a móvil. Si pagas anuncios en Google o en Meta, la mayoría de los clics que compras aterrizan en un celular. Una web lenta o incómoda en el teléfono convierte ese presupuesto en visitas que rebotan.
Si todavía estás decidiendo si conviene rehacer la web con otra lógica, en nuestra guía sobre rediseño móvil-first explicamos cuándo vale la pena empezar de cero. Esta auditoría sirve justamente para saber si llegaste a ese punto o si basta con corregir.
Antes de empezar: herramientas y preparación
Un detalle que confunde a muchos: Google retiró en diciembre de 2023 la «Prueba de optimización para móviles» y el informe de usabilidad móvil de Search Console. Si alguien te manda capturas de esa herramienta, son antiguas. Hoy el trabajo se hace con estas herramientas, todas gratuitas:
- PageSpeed Insights (pagespeed.web.dev): muestra datos reales de usuarios de Chrome de los últimos 28 días, si tu web tiene suficiente tráfico, y un análisis de laboratorio con Lighthouse.
- Google Search Console: el informe de Core Web Vitals agrupa las URL con problemas, y la inspección de URL te deja ver la página tal como la renderiza Googlebot para smartphone.
- Chrome DevTools: el modo de dispositivo (Ctrl + Shift + M) simula pantallas y conexiones lentas.
- Un celular real de gama media, con datos móviles y no con el wifi de la oficina. Es la prueba que más revela y la que casi nadie hace.
Prepara también una lista de las 5 a 10 páginas que más importan: inicio, servicios o categorías con más visitas móviles según Google Analytics 4, contacto y, si tienes tienda, una ficha de producto y el checkout. En WordPress muchas páginas comparten plantilla, así que audita plantillas, no cada página.
El checklist de 10 pasos en una tabla
Esta es la vista general. Cada paso se explica después con más detalle.
| Paso | Qué revisas | Herramienta | Resultado aceptable |
|---|---|---|---|
| 1 | Velocidad de carga real (LCP) | PageSpeed Insights | 2.5 s o menos |
| 2 | Respuesta al tocar (INP) | PageSpeed Insights / Search Console | 200 ms o menos |
| 3 | Estabilidad visual (CLS) | PageSpeed Insights | 0.1 o menos |
| 4 | Viewport y ancho de contenido | DevTools y celular | Sin desplazamiento horizontal |
| 5 | Tipografía y legibilidad | Celular real | Texto base de 16 px o más |
| 6 | Botones y zonas táctiles | Lighthouse y celular | Objetivos de 48 × 48 px aprox. |
| 7 | Formularios y contacto | Celular real | Se completa en menos de un minuto |
| 8 | Ventanas emergentes y banners | Celular real | No tapan el contenido principal |
| 9 | Paridad de contenido con escritorio | Inspección de URL en Search Console | Mismo texto, datos estructurados y enlaces |
| 10 | Medición por dispositivo | Google Analytics 4 | Conversiones móviles registradas |
Pasos 1 a 3: los Core Web Vitals en el celular
Los Core Web Vitals son las tres métricas con las que Google resume la experiencia de carga, respuesta y estabilidad de una página. Los umbrales de «bueno» que publica Google en web.dev son los de la tabla. Mira siempre la pestaña Móvil de PageSpeed Insights, porque es la más exigente y la que te representa.
Paso 1: LCP, cuánto tarda en aparecer lo principal
El LCP (Largest Contentful Paint) mide cuándo se pinta el elemento más grande visible: casi siempre la imagen de cabecera o un slider. En webs WordPress peruanas, el culpable típico es un banner de 2 o 3 MB subido tal cual salió de la cámara o de Canva. Qué hacer:
- Sirve la imagen principal en WebP o AVIF y con el ancho que realmente se muestra en el celular (rara vez necesitas más de 1,080 px).
- No apliques lazy loading a la imagen de cabecera: debe cargar primero, no al final.
- Quita sliders de cinco imágenes en la portada. En móvil casi nadie pasa de la primera.
- Revisa el tiempo de respuesta del servidor (TTFB). Si pasa de un segundo, el problema empieza en el hosting.
Paso 2: INP, cuánto tarda en reaccionar cuando tocas
El INP (Interaction to Next Paint) reemplazó al antiguo FID en marzo de 2024 y mide la demora entre que el usuario toca algo (un menú, un botón, un filtro) y la pantalla responde. Un INP alto se siente como una web «pegada». En WordPress suele venir del JavaScript de terceros: chats, píxeles, mapas, widgets de reseñas y constructores visuales con demasiadas animaciones. Si quieres profundizar, tenemos una guía específica sobre cómo mejorar el INP.
Paso 3: CLS, si la página «salta» mientras carga
El CLS (Cumulative Layout Shift) mide cuánto se mueven los elementos mientras la página termina de cargar. Es ese momento en que vas a tocar «Cotizar» y el botón baja porque apareció un banner arriba. Se corrige declarando ancho y alto en imágenes y videos, reservando espacio para anuncios o banners de cookies y cargando las fuentes tipográficas con font-display: swap.
Si tu web tiene poco tráfico, PageSpeed Insights solo mostrará el análisis de laboratorio; confírmalo con tu propio celular. Para el detalle técnico de cada métrica puedes revisar la guía de Core Web Vitals 2026.
Pasos 4 y 5: que se vea completo y se lea sin zoom
Paso 4: viewport y ancho del contenido
Abre cada página de tu lista en el celular y desliza con el dedo hacia los lados. Si la página se mueve horizontalmente, algo se sale del ancho de pantalla: una tabla, una imagen con ancho fijo, un iframe de mapa o un bloque de Elementor con márgenes negativos. Revisa también que el tema incluya la etiqueta <meta name="viewport" content="width=device-width, initial-scale=1">; casi todos los temas modernos la traen, pero algunos temas antiguos o páginas hechas a mano no.
Las tablas son un caso frecuente. En móvil conviene envolverlas en un contenedor con desplazamiento horizontal propio o convertirlas en tarjetas. Si usas Elementor, cada sección tiene ajustes separados para móvil, y muchas webs «responsive» en realidad nunca los configuraron. Lo explicamos paso a paso en cómo hacer tu web responsive con Elementor.
Paso 5: tipografía y contraste
El texto de párrafo debe tener al menos 16 px en móvil, con un interlineado cómodo (alrededor de 1.5) y líneas que no pasen de 70 u 80 caracteres. Hay un motivo técnico adicional: en iPhone, si un campo de formulario tiene una fuente menor a 16 px, Safari hace zoom automático al tocarlo y descuadra toda la página.
Prueba la lectura a pleno sol, como muchos clientes revisan tu web: un gris claro sobre blanco que en el monitor se ve elegante, en el celular se vuelve ilegible. Apunta al nivel AA de contraste de las pautas WCAG.
Pasos 6 y 7: tocar, escribir y contactar
Paso 6: botones y zonas táctiles
El dedo no es un cursor. Lighthouse recomienda objetivos táctiles de unos 48 × 48 píxeles y espacio suficiente entre ellos; las pautas WCAG 2.2 fijan un mínimo de 24 × 24 píxeles en su criterio 2.5.8. Revisa sobre todo:
- Enlaces del menú y del pie de página muy juntos (teléfono, correo y dirección pegados).
- Iconos de redes sociales diminutos.
- Botones de «Agregar al carrito», «Cotizar» o «WhatsApp» que quedan debajo del pliegue y obligan a hacer scroll para encontrarlos.
- El botón flotante de WhatsApp tapando el botón de compra o el de aceptar cookies.
Paso 7: formularios y canales de contacto
Este es el paso con más impacto en ventas. Completa tú mismo cada formulario desde el celular con datos móviles y cronométralo. Revisa que:
- Cada campo use el tipo correcto:
type="tel"para teléfono ytype="email"para correo, así el teclado adecuado aparece solo. - No pidas más campos de los que tu equipo de ventas realmente usa.
- Los mensajes de error digan qué corregir y no borren lo ya escrito.
- El captcha no sea un rompecabezas imposible en pantalla chica.
- El teléfono sea un enlace
tel:que marca con un toque, y el WhatsApp abra la conversación con un mensaje prellenado. - Llegue de verdad el correo o la notificación. Parece obvio, pero es una de las fallas silenciosas más comunes.
Para el diseño de los campos en sí, revisa cómo diseñar formularios que la gente sí complete.
Pasos 8 y 9: lo que Google penaliza y lo que no ve
Paso 8: ventanas emergentes y banners
Google advierte en su documentación sobre experiencia en la página que los intersticiales intrusivos dificultan el acceso al contenido en móvil. Un pop-up de suscripción que ocupa toda la pantalla apenas entras, sin un botón de cerrar visible, es el ejemplo clásico. Los banners de cookies y los avisos legales obligatorios están permitidos, pero deben ocupar una franja razonable y no la pantalla entera.
Revisa también la suma de elementos fijos: barra superior de promociones, menú fijo, botón de WhatsApp, banner de cookies y chat. Juntos pueden dejar menos de la mitad de la pantalla para el contenido. En móvil, elige como máximo uno o dos elementos fijos.
Paso 9: paridad de contenido con la versión de escritorio
Muchos constructores visuales permiten ocultar bloques solo en móvil. Es útil para simplificar, pero peligroso si escondes texto importante, tablas de precios, preguntas frecuentes o enlaces internos. Como Google indexa la versión móvil, ese contenido deja de contar.
Usa la herramienta de inspección de URL de Search Console, pide «Probar URL publicada» y revisa la captura y el HTML renderizado. Confirma que estén el título, los encabezados, el texto principal, los datos estructurados (Schema) y los enlaces del menú. Si tu menú móvil solo se arma con JavaScript al tocarlo, verifica que los enlaces existan en el HTML.
Paso 10: medir el móvil por separado en Google Analytics 4
Una auditoría sin medición se queda en opinión. En Google Analytics 4, entra a Informes, abre el de páginas y pantallas y agrega una comparación por categoría de dispositivo (móvil frente a escritorio). Mira tres cosas:
- Tasa de interacción por dispositivo: si en móvil es mucho menor que en escritorio en la misma página, hay un problema de experiencia y no de contenido.
- Eventos clave por dispositivo: envíos de formulario, clics en WhatsApp, clics en el teléfono o compras. Si en móvil tienes el 85 % de las visitas y el 40 % de las conversiones, ahí está tu prioridad.
- Páginas de entrada móviles con más rebote: son las primeras candidatas a corrección.
Si los clics en WhatsApp y teléfono no se registran como eventos, configúralos primero con Google Tag Manager. Sin eso, la versión móvil siempre parecerá que «no convierte», cuando en realidad convierte por un canal que no estás contando.
Cómo priorizar lo que encontraste
Al terminar tendrás una lista larga. No intentes arreglar todo a la vez. Ordena los hallazgos con este criterio simple:
- Lo que impide contactar o comprar: formularios rotos, botones tapados, checkout que falla. Se corrige esta semana.
- Lo que afecta a las páginas que reciben anuncios o tráfico orgánico: velocidad y estabilidad de esas plantillas.
- Lo que afecta la lectura: tipografía, contraste, tablas desbordadas.
- Lo cosmético: espaciados, alineaciones, animaciones.
Un ejemplo ilustrativo para dimensionar: si tu web recibe 3,000 visitas móviles al mes y el formulario convierte al 1 %, obtienes 30 contactos. Si al corregir el formulario y el botón de WhatsApp la conversión sube a 1.5 %, pasas a 45 contactos con el mismo tráfico: 15 oportunidades más al mes sin pagar un sol adicional en anuncios. Las cifras son supuestas; lo útil es hacer la misma cuenta con tus datos de GA4.
Errores frecuentes al auditar la web en el celular
- Probar solo con wifi y un iPhone nuevo. Tu cliente promedio no usa ese equipo. La velocidad mediana de internet móvil en Perú en 2025 fue de 34.71 Mbps según datos de Ookla recopilados por DataReportal, y en muchas zonas la señal es bastante peor.
- Obsesionarse con la puntuación de 100. La puntuación de Lighthouse es una guía de laboratorio. Lo que importa es que los datos reales estén en verde y que la gente convierta.
- Apilar plugins de optimización. Dos plugins de caché juntos suelen romper más de lo que arreglan.
- No volver a medir. Cada corrección debe compararse con el dato inicial. Anota la fecha de cada cambio para leer bien GA4 después.
Cuándo la auditoría te dice que toca rediseñar
A veces la conclusión honesta es que corregir no alcanza. Estas señales lo indican:
- El tema o el constructor está desactualizado y cada arreglo de velocidad rompe otra cosa.
- La web se hizo para escritorio y la versión móvil es una adaptación con decenas de bloques ocultos.
- Tienes más de 30 plugins activos y nadie sabe para qué sirve la mitad.
- Las plantillas principales no aprueban los Core Web Vitals ni después de optimizar imágenes y hosting.
En esos casos, el costo de seguir parchando suele superar el de una web nueva pensada desde el celular. Para comparar con números, revisa cuánto cuesta un rediseño web en Perú. Como referencia, en KOM los planes de diseño web publicados van desde S/ 1,250 + IGV (Plan Profesional) hasta S/ 2,250 + IGV (Plan Corporativo), con hosting, dominio y SSL incluidos el primer año.
¿Quieres que revisemos tu web contigo?
Puedes seguir este checklist por tu cuenta y resolver buena parte de los problemas sin ayuda. Si al terminar descubres que el problema está en la base del sitio (tema, constructor, hosting) o prefieres que un equipo lo resuelva por ti, en KOM diseñamos webs WordPress pensadas primero para el celular. Revisa los planes y el proceso en nuestra página de diseño web.
Preguntas frecuentes
¿Cada cuánto debo hacer una auditoría móvil de mi web?
Lo recomendable es una auditoría completa una vez al año y una revisión corta después de cada cambio importante: instalar un plugin nuevo, cambiar de tema, lanzar una campaña de anuncios o agregar un chat. La versión corta incluye velocidad en PageSpeed Insights, una prueba del formulario desde el celular y la revisión de los eventos de contacto en Google Analytics 4.
¿Puedo hacer la auditoría sin saber programar?
Sí. Ocho de los diez pasos se hacen con un celular, PageSpeed Insights y Search Console, sin tocar código. Lo que sí puede requerir ayuda técnica es la corrección: optimizar scripts de terceros, ajustar la caché del servidor o reconstruir una plantilla. Puedes detectar tú los problemas y luego pasarle la lista priorizada a tu desarrollador o agencia.
¿Qué celular conviene usar para probar mi web?
Uno de gama media o de hace dos o tres años, con Android, porque se parece más al equipo de la mayoría de tus clientes que un teléfono de alta gama. Prueba con datos móviles y no con wifi. Si puedes, revisa también en un iPhone, ya que Safari muestra algunos fallos propios, como el zoom automático en formularios con letra pequeña.
¿Una web lenta en móvil pierde posiciones en Google?
La experiencia en la página, que incluye los Core Web Vitals, es una de las señales que Google considera, pero no la principal: el contenido relevante pesa más. El efecto más fuerte de una web lenta suele ser comercial, porque la gente abandona antes de leer o contactar. Mejorar la velocidad ayuda en ambos frentes, sobre todo en búsquedas donde los competidores tienen contenido parecido.
¿Sirve una app o una versión AMP en lugar de arreglar la web móvil?
Para la mayoría de negocios, no. Una app solo tiene sentido si tus clientes la usan con frecuencia, como en un delivery o un banco. AMP ya no es requisito para aparecer en las noticias destacadas de Google y suma mantenimiento. Lo más rentable es tener una sola web WordPress responsive, rápida y bien medida.








