¿Cómo adaptar técnicamente tu web a los requisitos del Mobile-First Indexing de manera definitiva?

Cómo adaptar técnicamente tu web a los requisitos del Mobile-First Indexing de manera definitiva

Durante años muchos sitios trataron la versión móvil como una habitación de invitados: limpia, pequeña, suficiente para salir del paso, pero no exactamente la casa principal. Google, con esa cortesía suya tan burocrática como implacable, decidió hace tiempo entrar por esa puerta. Y ahora la pregunta ya no es si tu web “se ve bien en móvil”, sino si tu sitio existe de verdad cuando lo visita Googlebot Smartphone.

El Mobile-First Indexing no es una moda, ni una recomendación estética, ni una de esas frases que aparecen en auditorías SEO para justificar una tabla de colores. Es el sistema por el cual Google utiliza principalmente la versión móvil de una página para rastrear, indexar y evaluar su contenido. Dicho sin terciopelo: si tu web móvil es pobre, incompleta, lenta o técnicamente torpe, Google verá una web pobre, incompleta, lenta o torpe. Aunque en escritorio parezca un palacio renacentista.

La paradoja es hermosa, casi cruel: la web nació grande, horizontal, de escritorio; pero ahora se juzga desde una pantalla que cabe en la palma de una mano. Como un transatlántico obligado a demostrar su elegancia dentro de una botella.

Mapa de ruta de esta guía

1. Qué significa realmente Mobile-First Indexing
2. Cómo diagnosticar si tu web está preparada
3. Arquitectura móvil: responsive, dinámico o URLs separadas
4. Paridad de contenido, metadatos y enlaces internos
5. JavaScript, renderizado y recursos bloqueados
6. Core Web Vitals, velocidad y experiencia móvil
7. Imágenes, vídeos, fuentes y elementos multimedia
8. Datos estructurados, canonical, hreflang y SEO técnico
9. Adaptación específica en WordPress
10. Checklist técnico definitivo

Qué es Mobile-First Indexing, sin humo y sin solemnidad innecesaria

Mobile-First Indexing significa que Google toma como referencia principal la versión móvil de tu página para incorporarla a su índice y valorar su relevancia. No existe un “índice móvil” separado como si fuera un barrio periférico del buscador. Hay un índice, y la versión móvil es, por regla general, la fuente prioritaria de análisis.

Google empezó a experimentar con este enfoque en 2016. En julio de 2019 activó por defecto el Mobile-First Indexing para sitios nuevos. Y en octubre de 2023 comunicó que el proceso de migración al rastreo mobile-first se consideraba completado. La era en la que podías esconder una versión móvil empobrecida bajo la alfombra terminó. La alfombra también la rastrea Google.

Idea clave: Googlebot Smartphone no evalúa tu web como tú la ves en un monitor de 27 pulgadas, con fibra óptica, sesión iniciada y caché caliente. La evalúa como un usuario móvil, con recursos limitados, una ventana pequeña y una paciencia comparable a la de un gato mojado. 🐈‍⬛

Esto tiene consecuencias técnicas profundas. No basta con que el diseño “encaje”. Deben coincidir el contenido importante, las etiquetas SEO, los datos estructurados, las imágenes, los enlaces internos, las directivas de rastreo, los encabezados HTTP, la arquitectura de información y el rendimiento. La versión móvil no puede ser una maqueta ornamental: debe ser la versión canónica de la experiencia.

Antes de tocar nada: cómo saber si tu web está realmente preparada

He visto sitios con presupuestos generosos fallar por detalles minúsculos. Un menú móvil que no renderiza enlaces. Un bloque de texto oculto por CSS. Un robots.txt demasiado entusiasta. Un plugin de optimización que, en su afán heroico, rompe medio JavaScript. El SEO técnico se parece a revisar una vieja casa: no siempre cruje donde está la grieta.

Antes de rediseñar, comprimir, migrar o sacrificar velas a PageSpeed Insights, conviene medir.

Herramientas imprescindibles para auditar Mobile-First Indexing

• Google Search Console: inspecciona URLs concretas y comprueba cómo Google rastrea, renderiza e indexa la página.
• Prueba de resultados enriquecidos: permite validar datos estructurados renderizados en móvil.
• PageSpeed Insights: muestra datos de laboratorio y, si existen, datos reales de usuarios mediante CrUX.
• Lighthouse en Chrome DevTools: útil para rendimiento, accesibilidad, buenas prácticas y SEO técnico básico.
• Screaming Frog SEO Spider: permite rastrear como Googlebot Smartphone y comparar móvil contra escritorio.
• Logs del servidor: la verdad desnuda. Quién entra, cuándo entra, qué rastrea y qué códigos recibe.
• WebPageTest: excelente para analizar carga en condiciones móviles, waterfall, bloqueo de recursos y tiempos reales.

Qué debes comprobar en la inspección de URL

En Google Search Console, usa la herramienta de inspección de URL y revisa:

• Si la URL está indexada.
• Si el rastreador utilizado es Googlebot Smartphone.
• Si Google puede acceder a la página sin errores.
• Si la página renderizada conserva el contenido principal.
• Si los recursos CSS, JS e imágenes importantes no están bloqueados.
• Si la URL canónica elegida por Google coincide con la declarada.
• Si existen problemas de usabilidad móvil.

Pequeña ironía técnica: muchas empresas invierten meses en discutir el color del botón principal, pero nunca miran una captura renderizada por Google. Es como elegir cortinas para una casa cuya puerta está tapiada. 🚪

Elige una arquitectura móvil que no te persiga de noche

Hay tres formas principales de ofrecer una experiencia móvil: diseño responsive, publicación dinámica y URLs separadas. Las tres pueden funcionar. Pero no todas te complican la vida con la misma elegancia.

Responsive design: la opción más limpia, si se hace bien

El diseño responsive no consiste en encoger una web de escritorio hasta que todo parezca escrito para hormigas con gafas. Consiste en reorganizar el contenido de forma inteligente según el tamaño de pantalla, manteniendo la misma intención, jerarquía y accesibilidad.

En el <head> debe existir siempre esta etiqueta:

<meta name="viewport" content="width=device-width, initial-scale=1">

Sin ella, los navegadores móviles intentan interpretar la página como si fuera un lienzo de escritorio reducido. El resultado suele ser ese museo del horror donde el usuario pellizca, arrastra, suspira y se marcha.

Si usas publicación dinámica

Si tu servidor entrega HTML distinto según el dispositivo, debes enviar el encabezado:

Vary: User-Agent

Este encabezado ayuda a Google y a los sistemas de caché a entender que la respuesta puede cambiar según el agente de usuario. Sin él, podrías mostrar a Googlebot una versión incorrecta, o servir a usuarios móviles una página pensada para escritorio. Técnica moderna, resultado medieval.

Si tienes URLs móviles separadas

En sitios heredados con m.dominio.com, la relación entre versiones debe estar perfectamente declarada:

<!-- En la versión de escritorio -->
<link rel="alternate" media="only screen and (max-width: 640px)" href="https://m.ejemplo.com/pagina/">

<!-- En la versión móvil -->
<link rel="canonical" href="https://www.ejemplo.com/pagina/">

Además, cada URL de escritorio debe redirigir a su equivalente móvil exacto, no a la home móvil. Redirigir todo a la portada es como enviar a todos los pacientes de un hospital a recepción “porque más o menos es el mismo edificio”. No, no lo es.

Paridad de contenido: lo que desaparece en móvil también desaparece para Google

Este es el corazón del asunto. Si la versión móvil tiene menos contenido que la de escritorio, Google puede indexar y valorar menos contenido. Así de simple. Así de incómodo.

Durante años se creyó que “en móvil hay que quitar cosas”. Quitar texto, quitar enlaces, quitar módulos, quitar contexto. La pantalla pequeña se confundió con una mente pequeña, que es una de esas ideas aparentemente prácticas que envejecen como leche al sol.

Debe coincidir el contenido principal

Asegúrate de que en móvil estén presentes:

• El título visible principal de la página.
• El texto relevante del cuerpo.
• Las descripciones de productos o servicios.
• Las opiniones, FAQs, especificaciones y tablas importantes.
• Los enlaces internos estratégicos.
• Las imágenes y vídeos esenciales.
• Los datos de contacto, precios, disponibilidad y condiciones, si aplican.

Google ha indicado que el contenido en pestañas, acordeones o secciones desplegables puede ser tratado correctamente si está presente en el HTML y es accesible para el usuario. Es decir: no pasa nada por usar acordeones en móvil para mejorar la experiencia, siempre que no estés escondiendo contenido como quien oculta facturas en un cajón.

Metadatos equivalentes

Comprueba que la versión móvil conserva:

• <title>
• <meta name="description">
• Etiquetas robots
• Canonical
• Hreflang en sitios internacionales
• Open Graph y Twitter Cards si son relevantes para distribución social

Un error frecuente en configuraciones dinámicas es servir metadatos distintos a móvil y escritorio. El usuario no lo nota. Google sí. Y Google, cuando nota cosas raras, rara vez aplaude.

Enlaces internos: el esqueleto invisible

La navegación móvil suele reducirse a menús hamburguesa, carruseles, filtros plegados y bloques que aparecen al tocar. Eso no es malo. Pero si al adaptar la web eliminas enlaces importantes, modificas la arquitectura interna.

Revisa especialmente:

• Menú principal móvil.
• Migas de pan.
• Enlaces a categorías y subcategorías.
• Productos relacionados.
• Artículos relacionados.
• Bloques de “servicios relacionados”.
• Enlaces desde la home hacia páginas estratégicas.

Una web sin enlaces internos consistentes es como una ciudad sin calles: puede tener edificios magníficos, pero nadie llega a ellos.

JavaScript, renderizado y recursos bloqueados: donde muchas webs se vuelven fantasmas

Google puede renderizar JavaScript, sí. Pero “puede” no significa “conviene obligarle a hacerlo todo”. También puedes mudarte cargando los muebles en bicicleta; admirable, quizá, pero no eficiente.

El rastreo moderno tiene varias fases: descubrimiento, descarga del HTML, procesamiento de recursos, renderizado e indexación. Si el contenido crítico depende por completo de JavaScript pesado, peticiones tardías o APIs bloqueadas, puedes provocar retrasos o fallos en la indexación.

Problemas comunes de renderizado móvil

• Contenido principal inyectado por JavaScript después de varios segundos.
• Menús que no existen en HTML inicial.
• Enlaces renderizados como botones sin atributo href.
• Recursos JS o CSS bloqueados por robots.txt.
• Errores de hidratación en frameworks modernos.
• Lazy loading mal implementado que impide cargar imágenes o contenido.
• APIs que devuelven errores a Googlebot por geolocalización, cookies o cabeceras.

No bloquees recursos críticos en robots.txt

Google necesita acceder a CSS, JavaScript e imágenes para entender la página correctamente. Un robots.txt demasiado restrictivo puede sabotear el renderizado.

Evita patrones como este si bloquean recursos necesarios:

User-agent: *
Disallow: /wp-content/
Disallow: /assets/
Disallow: /js/
Disallow: /css/

En WordPress, bloquear /wp-content/ puede impedir el acceso a temas, plugins, imágenes y estilos. Una pequeña línea en un archivo olvidado, y la web queda ante Google como un escenario sin luces.

Enlaces rastreables

Para que Google descubra URLs, usa enlaces HTML reales:

<a href="https://www.ejemplo.com/categoria/producto/">Ver producto</a>

Evita depender solo de eventos JavaScript:

<button onclick="location.href='/categoria/producto/'">Ver producto</button>

Puede funcionar para el usuario, pero no es la forma más robusta de construir una arquitectura rastreable. En SEO técnico, lo robusto suele vencer a lo ingenioso. La historia de la web está llena de soluciones “brillantes” que terminaron siendo pequeñas trampas con animaciones bonitas.

Rendimiento móvil y Core Web Vitals: la velocidad también es contenido

Una página lenta no solo irrita. También erosiona la confianza. En móvil, cada segundo pesa más, como si el tiempo viajara mojado. El usuario no piensa “esta web tiene un problema de render-blocking resources”; piensa “me voy”.

Google utiliza señales de experiencia de página, entre ellas los Core Web Vitals, como parte de sus sistemas de ranking. No son el único factor ni sustituyen la relevancia del contenido, pero ignorarlos es mala estrategia. Desde marzo de 2024, INP reemplazó a FID como métrica principal de interacción.

Optimización de LCP

El LCP suele depender del elemento hero: una imagen grande, un bloque de texto, un banner o un vídeo. Para mejorarlo:

• Usa formatos modernos como WebP o AVIF.
• Define dimensiones explícitas en imágenes.
• Preload de la imagen principal si es realmente crítica.
• Evita sliders pesados en la parte superior.
• Reduce el tiempo de respuesta del servidor.
• Implementa caché de página y CDN si el tráfico o la geografía lo justifican.

<link rel="preload" as="image" href="/imagenes/hero-mobile.webp" fetchpriority="high">

<img src="/imagenes/hero-mobile.webp"
     width="1200"
     height="700"
     alt="Panel de administración web optimizado para móvil"
     fetchpriority="high">

Ojo: no conviertas el preload en confeti técnico. Precargar demasiados recursos degrada el rendimiento. La optimización no consiste en gritar “prioritario” a todo; eso lo hacen algunos jefes en lunes, y ya sabemos cómo acaba.

Optimización de INP

INP mide cómo responde la página a interacciones reales: toques, clics, entradas de teclado. Una web puede cargar rápido y aun así sentirse torpe, como un camarero elegantísimo que tarda cinco minutos en traer agua.

Para mejorar INP:

• Reduce JavaScript innecesario.
• Elimina librerías duplicadas.
• Divide tareas largas del hilo principal.
• Carga scripts de terceros solo cuando sean necesarios.
• Evita constructores visuales excesivamente pesados en páginas críticas.
• Usa defer en scripts no críticos.
• Revisa listeners de eventos en scroll, resize y touch.

<script src="/js/app.js" defer></script>

Optimización de CLS

El CLS empeora cuando la página se mueve después de empezar a cargarse. El usuario va a tocar un botón y, de repente, aparece un banner, el botón huye y termina pulsando otra cosa. La web se comporta como una mesa coja.

Soluciones:

• Define width y height en imágenes y vídeos.
• Reserva espacio para anuncios, iframes y embeds.
• Evita insertar banners superiores sin espacio previsto.
• Usa font-display: swap con cuidado para fuentes web.
• No inyectes contenido por encima del contenido ya visible salvo que sea imprescindible.

TTFB y hosting: el sótano que nadie presume en Instagram

El tiempo de respuesta del servidor influye en toda la cadena. Puedes optimizar imágenes, minificar archivos y recitar Lighthouse de memoria, pero si el servidor tarda demasiado en responder, empiezas la carrera con una piedra en el zapato.

Revisa:

• Versión de PHP en WordPress, idealmente una versión moderna y soportada.
• Uso de caché a nivel servidor.
• Compresión Brotli o Gzip.
• HTTP/2 o HTTP/3.
• Base de datos limpia y consultas lentas.
• CDN para recursos estáticos.
• Ubicación del servidor respecto al público objetivo.

Imágenes, vídeos y fuentes: belleza sí, lastre no

La web contemporánea ama las imágenes gigantes. A veces demasiado. Hay páginas que intentan vender una asesoría fiscal cargando una fotografía de 6 MB de una persona mirando un portátil junto a una planta. La planta, desde luego, no tiene culpa.

Imágenes responsive bien implementadas

Usa srcset y sizes para entregar imágenes adecuadas al ancho de pantalla:

<img
  src="/img/servicio-800.webp"
  srcset="/img/servicio-480.webp 480w,
          /img/servicio-800.webp 800w,
          /img/servicio-1200.webp 1200w"
  sizes="(max-width: 600px) 92vw, (max-width: 1200px) 50vw, 600px"
  width="800"
  height="520"
  alt="Equipo técnico revisando métricas de rendimiento móvil"
  loading="lazy">

No uses loading="lazy" en la imagen LCP principal si está en la parte superior. Cargar perezosamente lo que debe verse primero es una contradicción digna de comité.

Vídeos sin hundir la página

Para vídeos:

• Evita autoplay con sonido.
• Usa poster optimizado.
• No cargues iframes de YouTube o Vimeo hasta que el usuario interactúe, si no son esenciales.
• Incluye transcripciones cuando aporten valor SEO y accesibilidad.
• Usa datos estructurados VideoObject si el vídeo es contenido principal.

Fuentes web

Las fuentes personalizadas aportan identidad, pero también pueden bloquear renderizado o generar saltos visuales. Recomendaciones:

• Limita familias y pesos.
• Usa font-display: swap o optional según el caso.
• Sirve fuentes en formato woff2.
• Preload solo de fuentes críticas.
• Considera fuentes del sistema para interfaces de alto rendimiento.

@font-face {
  font-family: "Marca";
  src: url("/fonts/marca.woff2") format("woff2");
  font-display: swap;
}

Datos estructurados, canonical, hreflang y señales SEO que deben sobrevivir al móvil

La adaptación móvil no se limita al CSS. Hay señales semánticas que deben estar presentes y ser coherentes. Si tu versión móvil pierde datos estructurados, canonical o hreflang, pierdes precisión. Y en SEO técnico la precisión es una forma de cortesía hacia los buscadores. Una cortesía interesada, claro.

Datos estructurados

Los datos estructurados deben existir en la versión móvil igual que en escritorio. Si usas JSON-LD, verifica que se renderiza correctamente y que no depende de scripts bloqueados.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Cómo adaptar técnicamente tu web al Mobile-First Indexing",
  "description": "Guía técnica sobre SEO móvil, rendimiento, datos estructurados y rastreo.",
  "mainEntityOfPage": "https://www.ejemplo.com/mobile-first-indexing/"
}
</script>

Tipos habituales según proyecto:

• Article o BlogPosting para contenidos editoriales.
• Product para ecommerce.
• FAQPage cuando haya preguntas frecuentes visibles en la página.
• LocalBusiness para negocios locales.
• BreadcrumbList para migas de pan.
• VideoObject para vídeos principales.

Canonical

El canonical debe apuntar a la URL preferida indexable. En diseño responsive, normalmente se referencia a sí misma:

<link rel="canonical" href="https://www.ejemplo.com/servicios/seo-tecnico/">

Errores frecuentes:

• Canonical móvil apuntando a una URL equivocada.
• Canonical a una página no indexable.
• Canonical distinto entre móvil y escritorio sin motivo.
• Canonical generado por plugins con reglas contradictorias.

Hreflang

En sitios multidioma o multirregión, las etiquetas hreflang deben ser equivalentes en móvil y escritorio. Cada versión lingüística debe apuntar a sus alternativas correctas, incluida ella misma.

<link rel="alternate" hreflang="es" href="https://www.ejemplo.com/es/servicios/">
<link rel="alternate" hreflang="en" href="https://www.ejemplo.com/en/services/">
<link rel="alternate" hreflang="x-default" href="https://www.ejemplo.com/">

Meta robots y cabeceras X-Robots-Tag

Comprueba que no haya directivas contradictorias. Una página puede parecer perfecta y tener, silenciosamente, una etiqueta como esta:

<meta name="robots" content="noindex, nofollow">

O una cabecera HTTP:

X-Robots-Tag: noindex

Esto pasa más de lo que debería en entornos migrados, plantillas móviles antiguas o staging mal cerrado. La tragedia SEO rara vez entra tocando trompetas; suele venir en una línea pequeña.

Usabilidad móvil: no todo lo técnico vive en el servidor

La usabilidad móvil no es decoración. Es parte de la capacidad real de una página para cumplir su propósito. Google puede detectar problemas como texto demasiado pequeño, elementos clicables demasiado juntos o contenido más ancho que la pantalla.

Requisitos prácticos de experiencia móvil

• Texto legible sin zoom.
• Botones y enlaces con área táctil suficiente.
• Evitar scroll horizontal.
• Formularios sencillos y compatibles con autocompletado.
• Menús accesibles con teclado y lector de pantalla.
• Contraste suficiente.
• Pop-ups no intrusivos.
• Contenido principal visible sin obstáculos.

Especial cuidado con interstitials invasivos: pop-ups de newsletter, banners de app, selectores de país, avisos de cookies mal diseñados. Un aviso legal que ocupa toda la pantalla puede cumplir una norma y destruir la experiencia. La legalidad, a veces, también necesita CSS.

WordPress y Mobile-First Indexing: donde los plugins prometen milagros y cobran en milisegundos

WordPress puede ser excelente para Mobile-First Indexing. También puede convertirse en una cómoda colección de lastres: temas multipropósito, constructores visuales, sliders, scripts duplicados, fuentes remotas, píxeles de seguimiento, plugins abandonados. Todo muy democrático: cada plugin trae su pequeña contribución al caos.

El tema importa más de lo que parece

Elige un tema:

• Responsive de verdad, no solo “adaptable”.
• Ligero en CSS y JavaScript.
• Compatible con bloques nativos si usas Gutenberg.
• Actualizado con frecuencia.
• Sin dependencias excesivas.
• Con buena accesibilidad básica.

Temas visualmente espectaculares pueden cargar cientos de KB innecesarios en cada página. En escritorio quizá se disimula; en móvil se siente como llevar un piano por una escalera de caracol.

Plugins de caché y optimización

Herramientas como WP Rocket, LiteSpeed Cache, W3 Total Cache, Autoptimize o Perfmatters pueden ayudar, siempre que se configuren con criterio. No hay una receta universal. Minificar, combinar o diferir archivos puede mejorar una página y romper otra.

Buenas prácticas:

• Activa caché de página.
• Usa caché de navegador para recursos estáticos.
• Optimiza CSS crítico con pruebas reales.
• Difiere JavaScript no esencial.
• Retrasa scripts de terceros si no afectan a la primera interacción.
• Prueba formularios, menús, filtros y carritos después de optimizar.
• No combines archivos a ciegas si usas HTTP/2 o HTTP/3.

Imágenes en WordPress

Desde hace años WordPress genera tamaños de imagen y soporta srcset automáticamente en muchos casos. Pero si subes imágenes enormes sin control, ningún sistema hará magia perfecta.

• Sube imágenes dimensionadas razonablemente.
• Convierte a WebP o AVIF si tu flujo lo permite.
• Usa plugins como ShortPixel, Imagify, EWWW Image Optimizer o similares con pruebas de calidad.
• Define imágenes destacadas optimizadas.
• No uses sliders pesados como cabecera principal salvo que aporten valor real.

WooCommerce en móvil

En ecommerce, la versión móvil es todavía más crítica. No basta con indexar: hay que comprar. Revisa:

• Filtros rastreables y controlados para evitar facetas infinitas.
• Descripciones completas de producto en móvil.
• Datos estructurados Product, precio, disponibilidad y reseñas.
• Botón de añadir al carrito visible y funcional.
• Checkout rápido, sin campos innecesarios.
• Métodos de pago adaptados a móvil.
• Imágenes de producto optimizadas y ampliables.
• Evitar pop-ups que tapen variaciones, precios o CTA.

Un checkout móvil torpe es una máquina de perder dinero con interfaz gráfica. Y lo peor es que a veces parece funcionar: hay visitas, hay interés, hay carritos. Luego nada. Como una tienda preciosa con la caja registradora al fondo de un laberinto.

Seguridad y rastreo móvil: HTTPS, errores y confianza técnica 🔐

La seguridad también forma parte del ecosistema técnico. Google recomienda HTTPS desde hace años, los navegadores marcan sitios inseguros y los usuarios desconfían, con razón, de formularios sin cifrado.

Comprueba:

• Certificado SSL válido y renovado.
• Redirección consistente de HTTP a HTTPS.
• Sin contenido mixto en móvil.
• Sin cadenas de redirecciones innecesarias.
• Códigos HTTP correctos: 200 para páginas válidas, 301 para redirecciones permanentes, 404 o 410 para contenido eliminado.
• Sin errores 5xx intermitentes en recursos críticos.

Cadenas de redirección

Evita rutas como esta:

http://ejemplo.com
→ http://www.ejemplo.com
→ https://www.ejemplo.com
→ https://www.ejemplo.com/
→ https://www.ejemplo.com/es/

Mejor una redirección directa y limpia. Cada salto añade latencia y riesgo. En móvil, las cadenas de redirección son como hacer escala para cruzar la calle.

Analítica y logs: mirar donde casi nadie mira

Una tarde, revisando logs de un sitio editorial, encontramos que Googlebot Smartphone recibía errores 403 en una carpeta de recursos generada por el CDN. Para los usuarios todo parecía normal. Para Google, media plantilla era niebla. Lo solucionamos en minutos. El problema llevaba meses allí, quieto, discreto, perfectamente dañino.

Los logs del servidor permiten verificar:

• Frecuencia de rastreo de Googlebot Smartphone.
• URLs más rastreadas.
• Códigos de estado entregados.
• Consumo de presupuesto de rastreo en URLs inútiles.
• Errores 404, 301 excesivos, 5xx o bloqueos.
• Recursos CSS/JS solicitados por bots.

Si tienes un sitio grande, especialmente ecommerce o medio digital, los logs no son un lujo. Son la linterna en el sótano.

Checklist técnico definitivo para Mobile-First Indexing ✅

Rastreo e indexación

• Googlebot Smartphone puede acceder a las páginas importantes.
• No hay bloqueos indebidos en robots.txt.
• CSS, JavaScript e imágenes críticas son rastreables.
• Las URLs importantes devuelven código 200.
• No existen noindex accidentales.
• El sitemap XML contiene URLs canónicas e indexables.
• Search Console no muestra errores relevantes de indexación.

Contenido y SEO on-page

• El contenido principal está presente en móvil.
• Los encabezados mantienen una jerarquía lógica.
• Los títulos y metadescripciones coinciden o son equivalentes.
• Los enlaces internos importantes existen en móvil.
• Las migas de pan son visibles o están correctamente implementadas.
• El contenido en acordeones está en el HTML y es accesible.

SEO técnico

• Canonical correcto en todas las plantillas.
• Hreflang coherente en sitios multidioma.
• Datos estructurados presentes y válidos en móvil.
• Paginación, filtros y facetas bajo control.
• Redirecciones móviles correctas si existen URLs separadas.
• Encabezado Vary: User-Agent si hay publicación dinámica.

Rendimiento

• LCP por debajo de 2,5 segundos en datos reales cuando sea posible.
• INP por debajo de 200 ms.
• CLS por debajo de 0,1.
• Imágenes optimizadas y responsive.
• JavaScript reducido y diferido cuando proceda.
• Fuentes optimizadas.
• Caché y compresión activas.
• Servidor con TTFB razonable.

Experiencia móvil

• Texto legible sin zoom.
• Botones táctiles cómodos.
• Sin scroll horizontal.
• Pop-ups no intrusivos.
• Formularios simples y funcionales.
• Menús accesibles y rastreables.
• Checkout móvil fluido en ecommerce.

Errores habituales que conviene corregir antes de que se vuelvan costumbre

Ocultar contenido “por diseño”

Reducir la versión móvil hasta dejarla sin contenido útil es una forma elegante de perder relevancia. El diseño debe ordenar, no amputar.

Menús sin enlaces HTML

Si la navegación depende de scripts frágiles o botones sin href, el rastreo interno puede resentirse.

Lazy loading agresivo

El lazy loading mal aplicado puede impedir que imágenes o bloques importantes aparezcan en el renderizado inicial.

Plugins sin gobierno

Cada plugin añade peso, consultas, estilos o scripts. No todos son culpables, pero todos deben declarar su inocencia.

Pop-ups invasivos

Si el usuario aterriza y lo primero que ve es un muro, quizá no tienes una estrategia de conversión: tienes una barricada.

No probar como Googlebot

Ver la web en tu móvil no basta. Hay que comprobar cómo la rastrea y renderiza Google.

Plan de implementación en 30 días para una adaptación seria

Una adaptación definitiva no se improvisa. Puede organizarse en fases, con prioridades claras. No hace falta incendiar la web un viernes por la tarde, esa vieja tradición corporativa.

Días 1 a 5: auditoría

• Rastrea el sitio como Googlebot Smartphone.
• Compara contenido móvil y escritorio en plantillas clave.
• Revisa Search Console, cobertura, experiencia móvil y Core Web Vitals.
• Analiza PageSpeed Insights en URLs representativas.
• Comprueba logs si tienes acceso.

Días 6 a 12: correcciones críticas

• Desbloquea recursos necesarios.
• Corrige noindex, canonical y hreflang problemáticos.
• Restaura contenido móvil faltante.
• Asegura enlaces internos esenciales.
• Soluciona errores 4xx/5xx relevantes.

Días 13 a 20: rendimiento

• Optimiza imágenes principales.
• Reduce JavaScript no crítico.
• Configura caché, compresión y CDN si procede.
• Mejora LCP, INP y CLS en plantillas prioritarias.
• Elimina scripts de terceros innecesarios.

Días 21 a 26: experiencia y conversión

• Prueba formularios en dispositivos reales.
• Evalúa navegación, filtros, buscador interno y checkout.
• Corrige problemas de accesibilidad básica.
• Reduce interstitials y elementos intrusivos.

Días 27 a 30: validación

• Reinspecciona URLs en Search Console.
• Valida datos estructurados.
• Repite rastreo móvil completo.
• Documenta cambios y métricas iniciales.
• Programa revisión mensual.

Métricas que debes vigilar después de implementar cambios 📊

La adaptación al Mobile-First Indexing no termina cuando se publica una versión corregida. Empieza ahí su parte más silenciosa: observar.

• Impresiones orgánicas móviles: para detectar mejoras o caídas por tipo de consulta.
• CTR móvil: influido por títulos, snippets y posicionamiento.
• Posición media por dispositivo: útil para comparar móvil frente a escritorio.
• URLs indexadas: especialmente tras migraciones o cambios de arquitectura.
• Core Web Vitals en datos de campo: más importantes que una puntuación aislada de laboratorio.
• Tasa de conversión móvil: porque el SEO que trae tráfico y no negocio es una lámpara preciosa sin bombilla.
• Errores de rastreo: 404, 5xx, redirecciones y recursos bloqueados.
• Logs de Googlebot Smartphone: frecuencia, profundidad y comportamiento de rastreo.

Ten paciencia con los datos. Google puede tardar en rastrear, procesar y reflejar cambios. Los informes de Core Web Vitals, además, se basan en datos reales agregados durante un periodo aproximado de 28 días. La web se mueve rápido; la estadística, no tanto. Es una tortuga con diploma.

Una web móvil no es una versión pequeña: es la versión decisiva

Adaptarse al Mobile-First Indexing no consiste en perseguir a Google como quien intenta complacer a un inspector caprichoso. Consiste en aceptar una realidad más amplia: la mayoría de usuarios navega, compara, compra, lee y decide desde dispositivos móviles. Google no inventó ese mundo; simplemente dejó de fingir que el escritorio seguía siendo el centro del mapa.

La buena noticia es que los requisitos técnicos del Mobile-First Indexing no son misteriosos. Son exigentes, sí. Piden coherencia. Piden velocidad. Piden que la versión móvil no sea una sombra desnutrida de la web principal. Piden, en definitiva, que el sitio sea honesto con el usuario y legible para los sistemas que lo interpretan.

Hay una antítesis que resume todo: antes diseñábamos para pantallas grandes y adaptábamos hacia abajo; ahora debemos pensar desde lo esencial y escalar hacia arriba. Menos escaparate, más estructura. Menos artificio, más claridad. Menos “en escritorio se ve bien”, más “en móvil funciona de verdad”.

La regla final

Si Googlebot Smartphone entra en tu web, debe encontrar la misma sustancia que encontraría un usuario: contenido completo, navegación clara, señales SEO coherentes, recursos accesibles y una experiencia rápida. Todo lo demás es maquillaje sobre una pared húmeda.

Una web técnicamente preparada para Mobile-First Indexing no solo posiciona mejor: envejece mejor, convierte mejor y resiste mejor los cambios de algoritmo. Y en Internet, donde todo parece provisional, resistir con elegancia ya es una forma de victoria. 🚀