SEO móvil: guía técnica de indexación mobile-first

Si tu web tiene una versión de escritorio con más contenido, más enlaces internos o más datos estructurados que la versión móvil, Google prácticamente no ve esa diferencia: ve la versión móvil, y punto. Desde que la indexación mobile-first pasó a ser el comportamiento por defecto, el rastreador que decide qué sabe Google de una página es el mismo que la renderiza en una pantalla de teléfono, no en un monitor de escritorio.

Eso cambia una premisa que muchos equipos siguen dando por sentada: la versión "completa" del sitio ya no es la que cuenta. Si un bloque de contenido, un enlace o un dato estructurado existe solo en desktop, a efectos prácticos no existe. Este artículo se queda en ese terreno: qué arquitectura mobile elegir, cómo mantener la paridad entre versiones, cómo se comportan de verdad las Core Web Vitals en un teléfono, qué elementos táctiles molestan a un usuario real y cómo probarlo todo en condiciones que se parezcan a las de alguien con una mano ocupada.

Indexación mobile-first: qué significa exactamente

Mobile-first no es un eslogan de diseño responsive: describe cómo funciona el rastreo. El renderizado y la extracción de señales para indexar una URL se hacen predominantemente con un user-agent de smartphone, así que el HTML que ese rastreador recibe determina cómo se entiende la página, no lo que ve alguien desde un portátil.

Conviene distinguir contenido oculto de contenido ausente. Un bloque dentro de un acordeón que el usuario debe tocar para desplegar sigue en el HTML servido al móvil, así que cuenta igual que si estuviera visible. El problema aparece cuando, para "simplificar" el móvil, una plantilla elimina ese contenido del marcado en lugar de colapsarlo. Eso no es una versión reducida: es una página distinta, más pobre, y es la única que Google conoce.

Lo mismo aplica a los datos estructurados: es habitual encontrar sitios donde el schema de producto, artículo o FAQ se inyecta solo en la plantilla de escritorio, porque fue la primera que se construyó, y nadie lo replicó en la móvil. Ese marcado, a efectos prácticos, no existe.

• Colapsado en acordeones o pestañas: cuenta, si vive en el HTML servido al móvil.
• Eliminado del móvil (no solo oculto): no cuenta, aunque siga intacto en desktop.
• Datos estructurados: deben repetirse en la plantilla móvil, no solo en desktop.

Responsive, URLs separadas o contenido dinámico: por qué ganó el responsive

Durante años convivieron tres formas de servir una web a móvil, y todavía se encuentran las tres en producción. El diseño responsive usa una sola URL y un solo HTML, y es el CSS mediante media queries el que reorganiza el layout. Las URLs separadas para móvil, típicamente bajo un subdominio como m.dominio.com, sirven contenido desde plantillas distintas. Y el contenido dinámico mantiene una misma URL, pero el servidor detecta el user-agent y devuelve un HTML diferente según si quien pide la página es un escritorio o un teléfono.

El responsive se convirtió en la recomendación por defecto porque elimina de raíz la mayoría de los problemas de las otras dos opciones. Con una sola URL no hay que gestionar canonicalización entre versiones, no hay riesgo de que móvil y escritorio acumulen señales de enlaces por separado, y no hace falta mantener redirecciones hacia la versión "correcta" según el dispositivo, con el riesgo de bucles que eso conlleva.

Las URLs separadas exigen una anotación bidireccional constante: la móvil necesita un rel="canonical" hacia la de escritorio, y esta un rel="alternate" hacia la móvil, en cada par. El contenido dinámico arrastra otro riesgo: si la detección de user-agent falla, el servidor puede terminar sirviendo al rastreador una versión distinta de la que ve un usuario real, el patrón que se asocia con cloaking, intencionado o no.

• Responsive: una URL, un HTML; el CSS adapta el layout con media queries.
• URLs separadas (m.dominio.com): canonical desde la móvil hacia la de escritorio, alternate en sentido inverso, en cada par.
• Contenido dinámico: mismo URL, HTML distinto según user-agent; requiere la cabecera Vary: User-Agent.

Paridad de contenido, enlaces y metadatos entre versiones

Incluso con un responsive bien planteado, la paridad se rompe en detalles que nadie revisa tras el lanzamiento. El caso más común es la navegación: un menú de escritorio con veinte categorías se "limpia" en móvil dejando solo las cinco más visitadas, y las quince restantes pierden buena parte del enlazado interno que les llegaba desde la navegación global. La página sigue existiendo, pero recibe menos señal interna en la versión que cuenta.

Otro punto de fuga habitual son los metadatos. Algunas plantillas móviles generan un title o una meta description "resumida" para pantallas pequeñas, sin darse cuenta de que esa es la versión que se indexa. No hay ventaja alguna en acortarlos para el móvil, y sí una desventaja clara si el resumen recorta justo la palabra clave o el gancho que generaba clics.

El lazy loading merece mención aparte, porque es hoy la causa más frecuente de contenido que desaparece silenciosamente en móvil. Si las imágenes se cargan al detectar scroll mediante un intersection observer estándar, el rastreador simula ese comportamiento y no hay problema. El problema aparece cuando esa carga depende de un gesto táctil real —un swipe, un long-press— que nunca se dispara en un renderizado automatizado: el contenido queda técnicamente en la página, pero nunca llega a materializarse para quien la indexa.

• Enlaces internos: si el menú móvil oculta categorías completas, esas páginas reciben menos señal interna.
• Metadatos: title y meta description idénticos entre versiones, nunca una edición "resumida" para el móvil.
• Lazy loading: debe dispararse por scroll o intersection observer estándar, no por un gesto táctil exclusivo que el renderizado automatizado no genera.

Core Web Vitals en el móvil: por qué INP y CLS no se comportan igual

Las herramientas que reportan Core Web Vitals a partir de datos de campo segmentan los resultados por dispositivo, porque el comportamiento real difiere, y para la mayoría de sitios buena parte de ese tráfico es móvil. En la práctica, la puntuación que de verdad importa es, casi sin que nadie lo haya decidido, la puntuación móvil.

INP (Interaction to Next Paint) mide cuánto tarda la página en responder tras un toque, y ese retraso se nota mucho más en un teléfono de gama media que en un portátil potente. Un bloque de JavaScript que bloquea brevemente el hilo principal es casi imperceptible en un procesador de escritorio y se traduce en un retraso notable en un dispositivo con menos capacidad de cómputo.

CLS (Cumulative Layout Shift) tiene en móvil sus propios disparadores: un banner de cookies inyectado tras la carga inicial, una fuente web que llega tarde y provoca un reflow, o un hueco publicitario que reserva su espacio real solo cuando el anuncio termina de cargar. Los tres desplazan el contenido justo cuando el usuario, con el dedo ya cerca de la pantalla, intenta tocar otra cosa: no es solo una métrica peor, es un toque accidental sobre el elemento equivocado.

• INP: un mismo bloqueo del hilo principal por JavaScript penaliza más en gama media que en un portátil potente.
• CLS: banners de cookies, anuncios y fuentes web que cargan tarde desplazan el contenido justo cuando el usuario intenta tocarlo.
• Mitigación: reservar espacio con width/height o aspect-ratio en imágenes, y contenedores de tamaño fijo para huecos publicitarios.

Elementos táctiles: tap targets e interstitials que molestan de verdad

Un dedo no tiene la precisión de un puntero de ratón, así que un botón pensado para clic de escritorio puede resultar minúsculo o quedar demasiado pegado a su vecino en una pantalla táctil. Las guías de diseño de los principales sistemas operativos móviles llevan años recomendando un tamaño mínimo de contacto de aproximadamente 44 a 48 píxeles, con separación suficiente para evitar que un usuario acabe pulsando el de al lado. No es cosmético: quien toca sistemáticamente el elemento equivocado abandona antes de completar lo que venía a hacer.

El otro problema recurrente son los interstitials que aparecen al aterrizar desde una búsqueda: una capa a pantalla completa que tapa el titular, pidiendo un correo, empujando una app o promocionando otra cosa, antes de que el usuario lea una sola línea de lo que fue a buscar. Es distinto de un aviso de cookies, una comprobación de edad exigida por normativa o una barra discreta: esos casos no son el problema. El problema es la capa que sustituye por completo el contenido que el usuario esperaba encontrar.

A esa misma categoría pertenecen el vídeo que arranca con sonido, la barra fija que se come media pantalla, o el texto que obliga a hacer zoom porque la fuente se pensó para una pantalla mucho más grande. Ninguno es exclusivo del móvil, pero en seis pulgadas su efecto se multiplica: hay mucho menos espacio de sobra para absorberlos.

• Separación suficiente entre elementos tocables, para evitar toques accidentales sobre el vecino.
• Nada de interstitials a pantalla completa justo al aterrizar desde una búsqueda.
• Un aviso de cookies o una barra discreta de "app disponible" no es el problema; la capa que tapa el titular sí lo es.

Cómo probar tu SEO móvil en condiciones reales

Redimensionar la ventana del navegador de escritorio hasta que parezca un móvil es la forma más habitual de "comprobar" el SEO móvil, y también la menos fiable. Ese ejercicio cambia solo los puntos de ruptura del CSS: la página sigue ejecutándose sobre la CPU, la GPU y la conexión de un ordenador de escritorio. Y si el sitio usa contenido dinámico por user-agent en lugar de responsive, redimensionar la ventana ni siquiera activa la ruta de código móvil: se revisa, sin saberlo, la versión equivocada.

Una comprobación más honesta pasa por activar la limitación de CPU y de red de las herramientas de desarrollador, no solo el modo de emulación de viewport, y por revisar el DOM ya renderizado en lugar del código fuente estático: el lazy loading y el JavaScript cambian lo que realmente termina disponible para indexar. Conviene también probar sobre una conexión móvil real de vez en cuando, y en un teléfono de gama media en lugar de solo el más reciente que uno tenga a mano.

• Limitación de CPU y de red del navegador, no solo redimensionar la ventana, para simular un teléfono real.
• DOM ya renderizado, no código fuente estático: el lazy loading y el JavaScript cambian lo que llega a indexarse.
• Conexión móvil real de vez en cuando, no solo la wifi de la oficina, y en un teléfono de gama media.

Intención local y móvil: por qué no es un dato menor

Buena parte de las búsquedas con intención local —"cerca de mí", "abierto ahora", un negocio seguido de una calle— se hacen desde el teléfono y en movimiento, no sentado frente a un ordenador después. Para ese tipo de consulta, la experiencia móvil no es una versión secundaria: es, prácticamente, la única experiencia que ese usuario va a tener con la página.

La consecuencia técnica es que lo importante debe estar cerca de la parte superior en móvil, porque el espacio visible sin desplazarse en seis pulgadas es mucho más reducido que en un monitor. Dirección, horario y teléfono no pueden depender de que el usuario baje varias pantallas para encontrarlos, y el teléfono debería ser un enlace tel: real, para que tocarlo inicie la llamada en lugar de obligar a copiar el número a mano.

Un detalle que se pasa por alto es el mapa embebido: un iframe mal configurado puede capturar todos los gestos de scroll en cuanto el dedo lo toca, dejando al usuario atrapado dentro del mapa cuando quería seguir desplazándose por el resto de la página. Es un fallo pequeño con un efecto grande en móvil, porque ahí todo el desplazamiento se hace con el mismo dedo que manipula el mapa.

• Usa enlaces tel: reales, no solo texto con el número, para permitir la llamada con un toque.
• Coloca dirección, horario y teléfono cerca de la parte superior en móvil; el espacio visible sin scroll es mucho más pequeño que en desktop.
• Si insertas un mapa, evita que capture el scroll de toda la página cuando el usuario intenta desplazarse por el resto del contenido.