¿Qué es Mobile First Indexing?

Mobile first indexing es la estrategia de Google para decidir qué versión de una página usa como fuente principal al rastrearla, guardarla en su índice y calcular su posición: la que ve un teléfono, no la que ve un ordenador. Da igual desde qué dispositivo busque el usuario final. Si tu web tiene contenido distinto en móvil y en escritorio, lo que Google conoce y evalúa es, casi siempre, la versión móvil.

El proceso no fue un cambio de un día para otro. Google empezó a probarlo en noviembre de 2016 y lo fue aplicando web por web desde marzo de 2018, priorizando sitios que ya seguían las buenas prácticas. El 1 de julio de 2019 pasó a ser el sistema por defecto para cualquier dominio nuevo que Google no conociera todavía. Para el resto de la web, la migración se alargó bastante más de lo previsto: Google apuntaba a septiembre de 2020, retrasó esa fecha a marzo de 2021 y en noviembre de ese año reconoció que ya no manejaba una fecha fija, porque algunos sitios tenían dificultades técnicas que no esperaba.

El cierre oficial llegó el 31 de octubre de 2023, con la entrada de blog «Mobile-first indexing has landed». Ahí Google confirmó que, salvo casos residuales, todo el índice se rastrea y evalúa ya con Googlebot Smartphone. Cualquier artículo o guía que hable de mobile first como algo «implementado desde 2020» describe una fase intermedia del proceso, no el punto en el que Google dio la migración por terminada.

Aquí se mezclan tres conceptos que resuelven problemas distintos, y confundirlos lleva a diagnósticos equivocados. Uno es la estrategia de indexación de Google. Otro es una técnica de desarrollo. El tercero es un conjunto de métricas de rendimiento.

Tener una web responsive facilita mucho cumplir con mobile first, porque el HTML es el mismo en ambas versiones y no hay contenido que se pierda al pasar de una a otra. Pero no es lo mismo: una web puede ser responsive y aun así fallar en mobile first si, por ejemplo, oculta con CSS un bloque de texto en pantallas pequeñas y ese bloque nunca llega a formar parte de lo que Google indexa. Y al revés, una web con URLs separadas para móvil y escritorio (el viejo esquema m.midominio.com) puede funcionar bien con mobile first si esa versión móvil incluye todo el contenido relevante, aunque hoy Google recomiende responsive por ser mucho más fácil de mantener sin errores de paridad.

Los Core Web Vitals son otra cosa distinta: miden qué tan rápido carga y qué tan estable es la página, no qué versión indexa Google. Una web puede pasar mobile first sin problema y aun así tener un LCP malo en móvil, porque son dos evaluaciones independientes entre sí.

La mayoría de los problemas de mobile first no vienen de no tener web adaptada a móvil, sino de tener versiones móvil y escritorio que no dicen lo mismo. Los más comunes:

Texto recortado en móvil. Es habitual acortar párrafos largos o quitar secciones enteras en la versión móvil para no saturar la pantalla. Google indexa esa versión recortada, así que cualquier palabra clave o dato que solo esté en el párrafo eliminado deja de contar para el posicionamiento.

Elementos ocultos que Google tampoco ve. Pestañas, acordeones o menús desplegables no son un problema en sí: Google sí lee contenido oculto tras un clic si está presente en el HTML. El problema aparece cuando ese contenido solo se carga tras una interacción del usuario, un scroll, un swipe, un clic que dispara una llamada a un servidor, porque Googlebot no interactúa con la página como lo haría una persona.

Datos estructurados incompletos. Es frecuente que el marcado schema.org se añada solo en la plantilla de escritorio y se olvide en la de móvil, sobre todo si son plantillas independientes. Si Google solo indexa la versión móvil, un rich snippet que depende de ese marcado deja de aparecer aunque la versión de escritorio esté perfecta.

Metadatos distintos. Un title o una meta description que cambian entre versiones, a veces recortados a la fuerza para que quepan en una plantilla móvil más estrecha, hacen que lo que aparece en el buscador no sea el que el equipo de escritorio revisó y aprobó.

Enlazado interno reducido. Las versiones móviles suelen simplificar menús y footers para ganar espacio. Si eso elimina enlaces internos que existen en escritorio, esas páginas de destino pierden parte de la señal que reciben a través del enlazado interno, aunque nadie haya tocado su propio contenido.

Bloqueos técnicos distintos. Menos habitual, pero ocurre: reglas de robots.txt o directivas noindex que se aplican a la plantilla móvil y no a la de escritorio, o al revés, normalmente por un error de configuración en el CDN o en el servidor que sirve una u otra versión.

El primer paso sigue siendo la Search Console, con una salvedad importante: el informe dedicado de «Usabilidad móvil» que existía desde 2016 dejó de estar disponible a partir del 1 de diciembre de 2023, junto con la herramienta Mobile-Friendly Test y su API. Google lo justificó porque, con mobile first ya aplicado a todo el índice, esa comprobación específica perdió sentido como informe aparte, y porque ahora hay herramientas más completas para lo mismo, empezando por Lighthouse.

Para comprobar qué ve Google de una URL concreta, la herramienta correcta hoy es la Inspección de URLs dentro de Search Console: muestra el HTML ya renderizado tal y como lo procesó Googlebot, con el user agent de smartphone. Compara ese resultado con lo que ves al abrir la misma URL en un navegador de escritorio; si falta un bloque de texto, un dato estructurado o un enlace, ya sabes que ese contenido no está llegando al índice.

Un segundo chequeo, más manual pero igual de fiable, es abrir la misma URL en modo responsive del navegador (las herramientas de desarrollador de Chrome lo hacen bien) y comparar contra la versión de escritorio, sección por sección. Presta atención especial a lo que se oculta tras un acordeón o una pestaña: si aparece en el HTML fuente aunque esté visualmente oculto, no hay problema; si solo se genera tras una interacción, sí lo hay.

Para los datos estructurados, la Prueba de resultados enriquecidos de Google valida el marcado tal y como lo ve el rastreador móvil, no el de escritorio, así que conviene pasarla siempre sobre la URL real y no sobre una plantilla de referencia.

• Usa diseño responsive con la misma URL y el mismo HTML para ambas versiones: es la opción que Google recomienda desde 2018 precisamente porque elimina el riesgo de que móvil y escritorio digan cosas distintas.
• Incluye el marcado de datos estructurados completo en la plantilla móvil, no solo en la de escritorio, aunque sean plantillas técnicamente distintas.
• Mantén el mismo title, la misma meta description y las mismas etiquetas hreflang en ambas versiones, aunque el espacio disponible en pantalla sea menor.
• Si necesitas ocultar contenido secundario en móvil por espacio, hazlo con acordeones o pestañas que sigan presentes en el HTML, no eliminándolo del marcado ni cargándolo solo tras una interacción del usuario.
• Revisa que el enlazado interno de menús y footer no se reduzca en la versión móvil hasta el punto de dejar páginas huérfanas o con menos rutas de acceso.
• Comprueba con la Inspección de URLs de Search Console, no solo con una vista en el navegador, porque es la única forma de ver el HTML exacto que procesó Googlebot Smartphone.

• Ocultar contenido con CSS (display: none o similar) pensando que solo afecta a la vista móvil: si ese contenido nunca llega al HTML que rastrea Googlebot, tampoco cuenta para el posicionamiento en escritorio, porque Google ya no distingue entre ambos casos.
• Dar por hecho que tener web responsive ya garantiza cumplir mobile first, sin comprobar nunca qué versión concreta está indexando Google para las páginas más importantes.
• Cargar los datos estructurados solo mediante JavaScript que se ejecuta tras una interacción del usuario, en vez de tenerlos presentes en el HTML inicial o en el DOM que Google renderiza.
• Seguir revisando la usabilidad móvil solo con criterios de 2020, sin tener en cuenta que el informe dedicado de Search Console ya no existe y que ahora conviene apoyarse en Lighthouse o en la Inspección de URLs.
• Bloquear con robots.txt recursos como CSS o imágenes que Google necesita para renderizar correctamente la versión móvil, lo que puede hacer que la página parezca peor optimizada de lo que realmente está.