- Con la indexación mobile-first, Google usa la versión móvil del contenido, rastreada con el agente smartphone, para indexar y posicionar. Lo que solo existe en escritorio no cuenta.
- Google recomienda el diseño responsive porque es el patrón más fácil de implementar y mantener. Servicio dinámico y URLs separadas funcionan, pero exigen más disciplina.
- Debe coincidir entre móvil y escritorio: contenido principal, títulos, meta descripciones, datos estructurados, imágenes con su alt y la directiva robots.
- La Prueba de optimización para móviles y el informe de usabilidad móvil se retiraron en diciembre de 2023. Hoy se verifica con Inspección de URL, Lighthouse y el informe de Core Web Vitals.
- Los Core Web Vitals se miden por separado en móvil y escritorio, y la nota que importa es la de campo, no la de laboratorio.
- Una web puede estar bien en móvil y fallar en detalles medibles: yo mismo tengo enlaces de pie de página de 32 px de alto. Más abajo van las mediciones reales de mi sitio.
Desde hace años el «SEO móvil» no es una especialidad aparte: es el SEO, porque lo que Google indexa es lo que ve un smartphone. El problema real aparece cuando la versión móvil tiene menos texto, otros títulos o un menú que esconde enlaces, y nadie lo nota porque todos revisan la web desde un portátil.
Voy a separar lo que Google documenta de lo que se repite sin fuente, explicar qué debe ser idéntico entre móvil y escritorio y qué mido yo cuando reviso una web en móvil. Incluyo una sección con lo que he medido en cristofercruz.net, con sus límites, porque las mediciones salen de un emulador y no de usuarios reales.
Qué es la indexación mobile-first y qué significa en la práctica
La documentación de Google lo dice sin adornos: Google usa la versión móvil del contenido de un sitio, rastreada con el agente smartphone, para indexar y posicionar. Tener versión móvil no es obligatorio, pero la propia guía la califica de «muy recomendable».
El calendario ya es historia. Según la cobertura del anuncio de junio de 2024, Google fijó el 5 de julio de 2024 como fecha de cierre de la migración y avisó de que los sitios totalmente inaccesibles desde un móvil probablemente saldrían del índice. Hoy no hay una «opción móvil» que activar: todos los sitios se rigen por este modelo.
Las consecuencias prácticas son tres:
- Si un texto, un enlace o un dato estructurado solo está en la versión de escritorio, para Google no existe.
- Si la versión móvil tiene otro
noindex, otra etiqueta canonical o bloquea recursos que escritorio sí carga, es la móvil la que manda. - Los datos de rastreo en Search Console y los logs deben leerse con el agente smartphone como referencia, no con el de escritorio.
Hay un matiz que conviene no inflar: la documentación habla de «contenido» que se indexa. No concreta cómo se reparte hoy el trabajo entre el rastreador smartphone y el de escritorio, y no voy a inventarlo.
Responsive, servicio dinámico o URLs separadas
Google describe tres formas de ofrecer una web móvil y recomienda una: el diseño web responsive, porque es el patrón más fácil de implementar y mantener. Es la única de las tres para la que la guía expresa una recomendación.
| Configuración | URL | HTML | Qué hay que cuidar |
|---|---|---|---|
| Responsive | La misma para todos | El mismo para todos; el CSS adapta la vista | Viewport, breakpoints y rendimiento en móvil |
| Servicio dinámico | La misma para todos | Distinto según el user-agent | Cabecera Vary: User-Agent y paridad entre versiones |
| URLs separadas | Una para móvil y otra para escritorio | Distinto, en URLs distintas | Canonical en escritorio, alternate en móvil, redirecciones por dispositivo, hreflang coherente |
En proyectos con URLs separadas (el clásico m.) los fallos se acumulan en los enlaces entre versiones. La guía de Google indica que la URL de escritorio es la canonical y la móvil su alternate, que los hreflang deben apuntar de móvil a móvil y de escritorio a escritorio, y que las reglas de robots.txt tienen que ser coherentes en ambas. Con servicio dinámico, el riesgo es que el servidor detecte mal el dispositivo y Googlebot reciba una versión incompleta.
Mi criterio es simple: si el sitio se rehace o se construye de cero, responsive. Migrar de URLs separadas a responsive es un proyecto con redirecciones 301 y se trata como cualquier otra migración.
Paridad entre móvil y escritorio: qué debe coincidir
Este es el apartado donde más problemas reales encuentro. No hace falta que las dos versiones se vean igual; hace falta que el contenido principal y las señales sean equivalentes. La guía de Google lo desglosa así:
| Elemento | Qué pide Google | Fallo típico |
|---|---|---|
| Contenido principal | El de móvil debe equivaler al de escritorio. Acordeones y pestañas son aceptables por diseño | Recortar texto en móvil «para que pese menos» |
| Títulos (headings) | Usar los mismos títulos claros y significativos | H1 distinto o ausente en la plantilla móvil |
| Title y meta description | Equivalentes en ambas versiones | Plantilla móvil con metadatos genéricos |
| Datos estructurados | Los mismos en ambas versiones, con las URLs de la versión móvil | Schema solo en la plantilla de escritorio |
| Imágenes | Mismas URLs y mismo alt text | Imágenes distintas o sin alt en móvil |
| Robots | Metaetiquetas robots iguales; un noindex o nofollow distinto frena la indexación | Plantilla móvil con noindex heredado de pruebas |
| Carga diferida | No cargar el contenido principal solo tras una interacción del usuario | Texto que aparece únicamente al pulsar «ver más» |
| Recursos | Dejar que Google rastree CSS, JavaScript e imágenes | Bloqueos en robots.txt que solo afectan al render móvil |
Acordeones y pestañas no son un problema
Un error de planteamiento muy extendido es quitar los acordeones «por si Google no lo lee». La guía de Google los acepta como recurso de diseño en móvil. Lo que sí rompe la paridad es el contenido que no está en el HTML renderizado hasta que el usuario interactúa. Si tu web depende de JavaScript para pintarlo, lo que revisar está en mi artículo sobre JavaScript SEO.
Viewport y diseño adaptable
Sin la metaetiqueta viewport, los navegadores móviles pintan la página con un ancho de escritorio (en torno a 980 px, según web.dev) y la reducen. El texto se vuelve ilegible y cada enlace es diminuto. La declaración estándar es esta:
<meta name="viewport" content="width=device-width, initial-scale=1">width=device-width hace que la página use el ancho de la pantalla en píxeles independientes del dispositivo, e initial-scale=1 fija la relación 1:1 entre píxeles CSS y del dispositivo. web.dev desaconseja minimum-scale, maximum-scale y user-scalable, porque pueden impedir el zoom y crean un problema de accesibilidad. Me lo encuentro a menudo en temas que añaden user-scalable=no «por estética».
Más allá del viewport, el diseño adaptable se comprueba con tres señales: que no haya scroll horizontal de la página, que las imágenes (con srcset y tamaños adaptados al móvil) y las tablas no se salgan del contenedor y que los menús se plieguen sin ocultar enlaces en el HTML.
Usabilidad: tamaño de fuente y tap targets
Con el informe de usabilidad móvil retirado, ya no hay un veredicto automático de Search Console. Eso no quita que haya referencias útiles:
- Tap targets: web.dev recomienda un tamaño mínimo de unos 48 píxeles independientes del dispositivo y una separación de unos 8 píxeles entre objetivos, en horizontal y en vertical. Es una recomendación de usabilidad, no un umbral de Google Search.
- Tamaño de fuente: no he encontrado en la documentación de Google un tamaño mínimo oficial. Yo trabajo con 16 px para el cuerpo de texto, y lo trato como criterio propio, no como una regla de Google.
- Espaciado: enlaces en línea dentro de un párrafo y botones aislados no se juzgan igual. Lo que más me preocupa son los listados de enlaces apilados (pie de página, migas de pan, etiquetas) donde un dedo puede pulsar el vecino.
Interstitials intrusivos y banners de cookies
La guía de Google sobre interstitials pide evitar tres cosas: tapar la página entera, redirigir al usuario a otra página para pedirle consentimiento o datos, y redirigir todas las URL a una única página de consentimiento (eso deja solo esa página elegible para aparecer en resultados). Sí admite banners que ocupen una pequeña fracción de la pantalla, banners de instalación de app nativos del navegador, un contenedor pequeño reutilizable para avisos como la suscripción, y las verificaciones de edad exigidas por ley si el contenido queda superpuesto para que se pueda indexar parte de él.
Un detalle de la documentación de experiencia de página: ni la compatibilidad móvil ni los interstitials aparecen allí como factores de posicionamiento con nombre propio. Aparecen como preguntas de autoevaluación («¿se muestra bien tu contenido en dispositivos móviles?», «¿evitan tus páginas los interstitials intrusivos?»). Lo que sí dice la misma página es que los Core Web Vitals los usan los sistemas de posicionamiento, sin que una buena puntuación garantice los primeros puestos.
De la guía que he leído no puedo sacar una regla específica para banners de cookies, así que no afirmo ni que estén exentos ni que penalicen. Lo que sí hago es medir cuánta pantalla tapan; más abajo va el dato del mío.
Recursos bloqueados y renderizado móvil
Googlebot necesita CSS, JavaScript e imágenes para renderizar la versión móvil. Si robots.txt bloquea la carpeta de temas o de scripts, Google ve una página rota o sin contenido. La guía de mejores prácticas pide expresamente dejar que Google rastree los recursos.
Para comprobarlo, lo habitual es ir a la Inspección de URL, ejecutar una prueba en vivo y comparar la captura con lo que ve un usuario. La ayuda de Google indica que la captura de pantalla de la página renderizada solo está disponible en la prueba en vivo, y que las diferencias entre lo rastreado y lo que ves pueden deberse a recursos bloqueados para Google-InspectionTool. Esa documentación no describe una lista dedicada de recursos bloqueados, así que miro la lista de recursos cargados en «Más información» y cruzo con el robots.txt (el artículo sobre robots.txt explica cómo leerlo).
Core Web Vitals: móvil y escritorio por separado
Los umbrales de «bueno» son LCP de 2,5 s o menos, INP de 200 ms o menos y CLS de 0,1 o menos, medidos en el percentil 75 de las cargas de página y segmentados entre móvil y escritorio. Search Console tiene un informe de Core Web Vitals dividido por dispositivo, basado en datos de campo y con las URL agrupadas por experiencia similar.
Por eso una web puede aprobar en escritorio y suspender en móvil: el procesador es más lento, la red peor y el diseño es otro. Cuando reviso una cuenta empiezo por el informe de móvil, porque es el segmento con el que Google indexa. Cómo arreglar cada métrica lo desarrollo en el artículo sobre Core Web Vitals; aquí lo relevante es que la nota de laboratorio de Lighthouse orienta, pero la que cuenta es la de campo.
Herramientas: qué se retiró y qué usar hoy
Según Search Engine Land, Google retiró el 4 de diciembre de 2023 el informe de Usabilidad móvil de Search Console, la Prueba de optimización para móviles y su API (la fecha prevista era el 1 de diciembre). La herramienta redirige ahora a Lighthouse, y Google señaló que mobile usability sigue formando parte de su guía de experiencia de página. Quien todavía cita esa prueba en 2026 está copiando contenido antiguo.
| Herramienta | Para qué la uso en móvil |
|---|---|
| Inspección de URL (Search Console) | Ver con qué tipo de agente (móvil o escritorio) se rastreó, el HTML y, en prueba en vivo, la captura renderizada |
| Informe de Core Web Vitals | Datos de campo de móvil y escritorio por separado, con URLs agrupadas |
| Lighthouse (Chrome DevTools) | Auditoría de laboratorio: viewport, tamaño de objetivos táctiles, rendimiento |
| DevTools en modo dispositivo | Emular 360 y 390 px, buscar scroll horizontal y elementos que se salen |
| Un móvil real | Teclado virtual, menús, banners y comportamiento táctil que el emulador no reproduce |
Errores típicos de SEO móvil
- Plantilla móvil con menos contenido, o con el texto largo recortado.
- Datos estructurados, canonical o hreflang distintos entre versiones.
noindexheredado de un entorno de pruebas en la plantilla móvil.- Viewport ausente o con
user-scalable=no. - Contenido principal que solo se carga al pulsar o desplazarse (con iframes, mira cómo aplicar lazy loading en iframes sin romper el SEO).
- CSS o JavaScript bloqueados en robots.txt.
- Ventanas emergentes que tapan la pantalla entera al entrar desde Google.
- Imágenes distintas en móvil, o con otro alt, que provocan pérdidas temporales de tráfico de imágenes.
- Enlaces del menú de escritorio que no existen en el menú móvil.
- Mirar solo la nota de laboratorio y no el informe de campo por dispositivo.
Cómo lo tengo en mi web
Todo lo que sigue sale de leer el código de cristofercruz.net y de medir con Chromium en modo móvil (Playwright) contra una copia local del sitio, con 390 × 844 y 360 × 740 px. No son datos de usuarios reales ni una auditoría de Lighthouse; no he medido LCP, INP ni CLS de campo para este artículo.
| Comprobación | Resultado medido |
|---|---|
| Configuración | Responsive: una URL y el mismo HTML para todos. No hay subdominio móvil ni detección de user-agent en el código del sitio. Una petición con el user-agent de Googlebot Smartphone y otra con el de Googlebot de escritorio devolvieron exactamente el mismo HTML (misma suma de comprobación) |
| Viewport | width=device-width, initial-scale=1, sin límites de zoom |
| Scroll horizontal | Ninguno a 390 y 360 px en la portada, la página de auditoría SEO, el índice del blog y un artículo, y tampoco a 320 px en ese artículo: el ancho del documento es igual al de la pantalla. Las tablas y los bloques de código tienen su propio scroll interno |
| Menú | La navegación de escritorio se oculta por debajo de 1180 px y aparece un botón de menú de 48 × 44 px |
| Texto | Cuerpo de 16 px calculado. En el artículo de caché, en torno al 80 % de los caracteres de texto visible está en 16 px o más; el mínimo es 12 px, en etiquetas en mayúsculas y en el banner de cookies |
| Imágenes | Todas las imágenes de las cuatro páginas medidas llevan width y height; la portada usa srcset |
| robots.txt | No bloquea CSS, JavaScript, fuentes ni imágenes. Solo cierra carpetas internas, herramientas y el procesamiento del formulario |
Lo que no cumple
Medí también los enlaces y botones de esas páginas, y no aprueban todos con la referencia de 48 px de web.dev:
- Los enlaces del pie de página miden unos 32 px de alto.
- Las migas de pan miden unos 19-20 px de alto (son enlaces en línea).
- El enlace «Reservar consultoría» del aviso superior mide 24 px de alto.
- El enlace «Política de cookies y proveedores» del banner mide 22 px de alto.
En cambio, los botones del banner de cookies miden 44-46 px de alto y los desplegables de las preguntas frecuentes de los artículos tienen entre 59 y 82 px. Los botones principales cumplen; los listados de enlaces, no.
El banner de cookies, en una primera visita sin consentimiento guardado, ocupa 360 px de alto: el 43 % de la pantalla a 390 × 844 y el 49 % a 360 × 740. No cubre la página entera, está anclado abajo y permite «Seguir sin decidir», pero es mucha pantalla en móvil y es de lo primero que iría a recortar.
Mide siempre en primera visita, sin consentimiento guardado: es lo que ven Google y los usuarios nuevos, y es cuando banners y avisos tapan más.
Cómo auditar el SEO móvil paso a paso
- Abre la Inspección de URL con una URL importante y mira con qué agente se rastreó y qué HTML recibió.
- Lanza una prueba en vivo y compara la captura con lo que ves en un móvil real.
- Compara el código fuente de móvil y escritorio: title, meta description, robots, canonical, H1, datos estructurados en JSON-LD y número de enlaces.
- Revisa
robots.txty confirma que no bloquea CSS, JavaScript ni imágenes. - Abre DevTools a 360 y 390 px: busca scroll horizontal, texto que se corta y elementos pegados.
- Pasa Lighthouse en modo móvil y anota viewport y objetivos táctiles.
- Revisa el informe de Core Web Vitals de móvil y las URL agrupadas con peor nota.
- Entra desde un resultado de Google en primera visita y mide cuánta pantalla tapan banners e interstitials.
Si prefieres que lo haga alguien con el contexto de tu sitio, forma parte de lo que reviso en una auditoría SEO. Y si tu negocio vive de clientes que te buscan desde el móvil en tu zona, lo complemento con SEO local.
Preguntas frecuentes
¿Qué es la indexación mobile-first?
Es el modelo en el que Google usa la versión móvil del contenido, rastreada con el agente smartphone, para indexar y posicionar. Según la cobertura del anuncio de junio de 2024, la transición se cerró el 5 de julio de 2024.
¿Necesito una versión móvil para posicionar?
Google la considera «muy recomendable», pero no obligatoria. Si el contenido es completamente inaccesible desde un móvil, la misma cobertura indica que probablemente se retire del índice.
¿Es mejor responsive o una web móvil aparte?
Google recomienda responsive porque es el más fácil de implementar y mantener. Las URLs separadas y el servicio dinámico son válidos, pero exigen mantener la paridad y las señales entre versiones.
¿Sigue existiendo la Prueba de optimización para móviles?
No. Se retiró el 4 de diciembre de 2023 junto con el informe de Usabilidad móvil y su API. Hoy se usa Lighthouse, la Inspección de URL y el informe de Core Web Vitals.
¿El contenido en acordeones o pestañas cuenta para Google?
La guía de Google lo acepta como recurso de diseño en móvil. Lo que debes evitar es que el contenido principal solo se cargue después de una interacción del usuario.
¿Los interstitials penalizan el posicionamiento?
La guía de Google pide evitar los que tapan toda la página o redirigen a otra para pedir consentimiento. En la documentación de experiencia de página aparecen como pregunta de autoevaluación, no como factor de posicionamiento con nombre propio.
¿Se miden igual los Core Web Vitals en móvil y escritorio?
Los umbrales son los mismos (LCP 2,5 s, INP 200 ms, CLS 0,1 en el percentil 75), pero se evalúan en segmentos separados. Search Console los muestra en informes distintos por dispositivo.
Referencias
- Mobile-first indexing Google Search Central
- Avoid intrusive interstitials Google Search Central
- Understanding page experience in Google Search results Google Search Central
- URL Inspection tool Ayuda de Search Console
- Core Web Vitals report Ayuda de Search Console
- Web Vitals web.dev · Google
- Accessible tap targets web.dev · Google
- Responsive web design basics web.dev · Google
- Google officially drops Mobile Usability report, Mobile-Friendly Test tool and API Search Engine Land
- Google Search completes transition to Mobile-First Indexing by July 5, 2024 PPC Land
