Mobile-First Indexing y Page Experience: cómo Google mira tu sitio en 2026

El cambio que ya pasó y muchos no asumen

Mobile-First Indexing no es novedad. Google empezó a migrar sitios al esquema mobile-first en 2018 y completó la migración total para todos los sitios en octubre 2023. Hoy no existe “indexación desktop” para nuevos sitios — todo se evalúa con Googlebot Smartphone como crawler primario. Si tu versión mobile es inferior a la desktop, tu SEO entero es inferior.

Lo que sigo viendo en proyectos heredados: contenido visible solo en desktop (esconder secciones con display:none en mobile), navegación principal incompleta en mobile, schema markup que solo se inyecta en la versión desktop, internal linking sustancialmente distinto entre versiones. Cualquiera de estos invisibiliza secciones enteras del sitio para Google.

Mobile-First Indexing: qué cambia en la práctica

Mobile-First Indexing significa que Googlebot Smartphone es el crawler primario. Lo que Googlebot Smartphone ve en tu sitio es lo que Google indexa, evalúa de calidad, y rankea. La versión desktop puede ser distinta — no se penaliza por ser distinta — pero solo la mobile cuenta para indexación.

Lo que esto implica concretamente: contenido principal debe estar presente en mobile (mismo H1, mismos párrafos clave, misma estructura), schema markup debe inyectarse en mobile (no condicional al user-agent desktop), internal links principales deben aparecer en mobile (no escondidos detrás de un menú hamburger sin links indexables), e imágenes con alt text deben cargarse en mobile (no esconderlas con CSS para “performance”).

El error frecuente en migraciones: el equipo de desarrollo decide “simplificar” mobile sacando contenido secundario. Si ese contenido es lo que Google está usando para entender la página, simplificar mobile baja ranking — el sitio que pierde tráfico post-rediseño no es el que tiene peor diseño visual, es el que tiene menos contenido en mobile.

Page Experience: el conjunto de señales de UX

Page Experience es el nombre paraguas que Google le da al conjunto de señales de experiencia de usuario que afectan ranking. No es un factor único — es una agregación de múltiples métricas que Google evalúa juntas: Core Web Vitals, HTTPS, mobile-friendliness, y ausencia de intersticiales agresivos.

Page Experience por sí solo no es decisivo — Google priorizó siempre la relevancia y calidad del contenido sobre las señales de UX. Pero entre dos páginas con relevancia y autoridad similar, la que tiene mejor Page Experience rankea más alto. Y en SERPs muy competidas, esa diferencia es la que mueve clicks reales.

El detalle importante de 2024-2026: Google sacó el “Page Experience report” de Search Console en 2024, pero las señales subyacentes siguen activas. Ahora se monitorean directamente vía Core Web Vitals report y mobile usability report.

HTTPS / SSL: la base mínima no negociable

HTTPS (HyperText Transfer Protocol Secure) es la versión cifrada de HTTP, implementada con certificado SSL/TLS. Desde 2014 Google lo confirmó como factor de ranking, y desde 2018 Chrome marca explícitamente como “no seguro” cualquier sitio en HTTP plano. En 2026, no tener HTTPS no es opción — es bloqueante.

Implementación correcta: certificado SSL emitido por una Certificate Authority confiable (Let’s Encrypt es gratuito y funciona perfectamente para la mayoría de los sitios), redirect 301 de TODO el tráfico HTTP a HTTPS, HSTS header configurado para forzar HTTPS en navegadores, y no contenido mixto (HTTPS página principal cargando assets HTTP — rompe el padlock).

Verificación rápida: cargar el sitio en Chrome con DevTools abierto. Tab Security debe mostrar “Connection is secure” sin warnings. Si hay mixed content warnings, son URLs HTTP cargándose desde HTTPS — usualmente imágenes legacy o scripts de terceros antiguos.

Responsive design: la implementación recomendada por Google

Responsive design es la técnica de tener UN solo HTML que se adapta visualmente al ancho del viewport via CSS. Es la implementación recomendada por Google para mobile-first desde hace años — superior a tener URLs separadas (m.example.com) o sites dinámicos que sirven HTML distinto según user-agent.

Por qué responsive es mejor: una sola URL canónica para cada contenido (sin canonical/alternate complications), un solo set de schema markup, internal links idénticos en todas las versiones, y simplicidad de mantenimiento. Las únicas razones para no usar responsive son casos legacy con limitaciones de plataforma — y en esos casos, la prioridad debería ser migrar a responsive en lugar de mantener arquitecturas duales.

El test rápido: Mobile-Friendly Test de Google (search.google.com/test/mobile-friendly) sigue funcional aunque ya no genere reporte público. Carga la URL, ejecutalo, validá que no haya issues con tap targets, viewport configuration, o text legibility. Si pasa, Googlebot Smartphone va a poder procesar la página correctamente.

Cómo se aplica en la práctica

El stack de auditoría mobile-first en proyectos enterprise: validación de paridad mobile-desktop con crawl comparativo (Screaming Frog en modo Smartphone vs Desktop), monitoreo de Core Web Vitals separados por device en Search Console, validación de HTTPS y mixed content, y test continuo de Page Experience signals con Lighthouse + PageSpeed Insights. La metodología completa de auditoría técnica está en /servicios/seo-tecnico/.