La respuesta corta
La indexación mobile-first ha concluido. Desde julio de 2024, Google solo utiliza la versión móvil de tu sitio para indexar y posicionar. Si el contenido, los datos estructurados o los enlaces internos existen en la versión de escritorio pero no en la móvil, Google no los ve. En 2026, esto tiene tres consecuencias nuevas que la mayoría de los propietarios de sitios aún no han abordado: INP reemplazó a FID como Core Web Vital, las AI Overviews extraen información del contenido renderizado en móvil, y la actualización principal de marzo de 2026 (March 2026 Core Update) aumentó el peso de clasificación de la experiencia de página en móvil.
A continuación, encontrarás un flujo de trabajo de auditoría completo, junto con un skill de Codex listo para copiar y pegar que ejecuta la mayoría de las comprobaciones por ti.
Lo que "solo móvil" realmente significa en 2026
Google comenzó a migrar sitios a la indexación mobile-first en 2018. La transición tomó más de seis años. A partir de julio de 2024, todo sitio que aún tuviera contenido accesible en escritorio sin equivalente en móvil perdió ese contenido del índice de Google. No hay forma de excluirse ni alternativa solo para escritorio.
Pero la historia no terminó ahí. Tres cambios en 2025–2026 transformaron lo que "mobile-first" exige de tu sitio:
Cambio 1: INP reemplazó a FID, y la mayoría de los sitios móviles no lo superan
En marzo de 2024, Google reemplazó First Input Delay (FID) por Interaction to Next Paint (INP) como Core Web Vital. INP mide qué tan rápido responde tu página a toques, clics y pulsaciones de teclas durante toda la sesión en la página, no solo la primera interacción.
El dato contundente: aproximadamente el 40% de los sitios que cumplían con FID no cumplen con INP. En móvil, solo alrededor del 65% de los sitios alcanzan el umbral "bueno" de 200 milisegundos o menos. La actualización principal de marzo de 2026 aumentó aún más el peso de los Core Web Vitals en el ranking. Los sitios que no superan INP en móvil están perdiendo posiciones frente a competidores más rápidos.
Cambio 2: Las AI Overviews y los rastreadores de IA leen tu contenido móvil
Las AI Overviews de Google aparecen en aproximadamente el 47% de las búsquedas a mediados de 2026. Cuando los sistemas de IA de Google generan respuestas, extraen información del mismo contenido indexado en móvil que utiliza la búsqueda tradicional. Los rastreadores de IA de terceros (GPTBot, ClaudeBot, PerplexityBot) también acceden a tus páginas renderizadas en móvil.
Si tu versión móvil carece de datos estructurados, encabezados claros o texto crítico, los sistemas de IA no pueden citarte, incluso si la versión de escritorio tiene ese contenido.
Cambio 3: Las brechas de paridad de contenido ahora tienen un impacto medible en el ranking
En 2026, los sitios con contenido inconsistente entre móvil y escritorio muestran una exposición de búsqueda orgánica un 31.2% menor en promedio en comparación con los sitios que tienen paridad total de contenido. Los elementos que más comúnmente faltan en móvil son: contenido oculto en pestañas, enlaces de barra lateral, marcado de datos estructurados, texto alternativo de imágenes y enlaces de navegación interna.
Elemento de contenido | % de sitios que lo omiten en móvil |
|---|---|
Datos estructurados (JSON-LD) | 23% |
Enlaces internos (menús, breadcrumbs) | 18% |
Texto alternativo de imágenes | 27% |
Texto completo en pestañas/acordeones | 15% |
Etiquetas meta robots | 9% |
Cómo verificar si tu sitio cumple (versión de 2 minutos)
Antes de ejecutar una auditoría completa, revisa estas tres señales. Cada una toma menos de un minuto y te indica si necesitas profundizar.
Señal 1: Estado de indexación en Google Search Console
Abre Google Search Console → haz clic en Configuración (ícono de engranaje, abajo a la izquierda) → busca la sección "Acerca de". Si dice "Googlebot smartphone" en "Rastreador de indexación", tu sitio está en indexación mobile-first. Esto aplica a prácticamente todos los sitios en 2026, pero verifícalo.
También revisa: Herramienta de inspección de URL → ingresa cualquier página importante → expande "Rastreo" → confirma "Rastreado como: Googlebot smartphone". Mira la captura de pantalla que Google proporciona: esto es exactamente lo que Google ve. Si falta contenido clave en esa captura, falta en el índice.
Señal 2: PageSpeed Insights con datos reales de móvil
Ve a PageSpeed Insights, ingresa tu URL y observa la sección "Descubre lo que experimentan tus usuarios reales". Estos son datos de campo del Chrome User Experience Report (CrUX), los mismos datos que Google utiliza para el ranking.
Si el informe móvil muestra naranja o rojo para INP (Interaction to Next Paint), tienes una desventaja activa en el ranking. El umbral es menos de 200 milisegundos para verde.
Señal 3: Verificación rápida de viewport móvil en Chrome DevTools
Abre Chrome DevTools (F12 o Cmd+Option+I), haz clic en el ícono de barra de dispositivos (Ctrl+Shift+M) y selecciona un preset de dispositivo móvil como "Pixel 7". Recarga la página. Busca:
- Texto que requiere desplazamiento horizontal
- Botones o enlaces demasiado pequeños para tocar (menos de 48×48 píxeles CSS)
- Contenido oculto detrás de botones "leer más" que no está en el código fuente HTML
- Ventanas emergentes que cubren la mayor parte de la pantalla
Cada uno de estos es un problema de indexación mobile-first si el contenido o los enlaces detrás de ellos difieren de lo que ven los usuarios de escritorio.
La auditoría mobile-first de 30 minutos (con Codex)
La forma más rápida de ejecutar una auditoría mobile-first completa hoy es darle a un agente de codificación con IA — Claude Code o Codex — una tarea estructurada. El agente lee el código fuente de tu sitio, verifica las reglas y produce una lista priorizada de correcciones.
A continuación encontrarás un archivo de skill completo. Cópialo en tu proyecto y luego pídele a tu agente que lo ejecute.
Paso 1: Crear el archivo del skill
Crea un archivo en .claude/skills/mobile-first-audit/SKILL.md (para Claude Code) o .codex/skills/mobile-first-audit/SKILL.md (para Codex):
name: mobile-first-audit
description: Audit a URL or list of URLs for mobile-first indexing readiness. Checks content parity, Core Web Vitals, structured data, mobile UX, and AI crawler access.
# Mobile-First Indexing Audit
Run a structured mobile-first indexing audit on one or more URLs. The agent must report findings, not make edits, unless the user explicitly approves a fix plan.
## Input
The user provides one or more page URLs. If they provide a sitemap URL or a list of more than 5 URLs, sample 5 URLs that represent different page types (homepage, product page, article, category page, landing page).
## Audit Checklist
For each URL, check and report on all eleven items below. Mark each item as `PASS`, `WARN`, or `FAIL`. Include the evidence for every WARN and FAIL.
### 1. Viewport Meta Tag
Check that `<meta name="viewport" content="width=device-width, initial-scale=1">` is present in the HTML `<head>`. If missing or if it sets a fixed width or disables user-scaling without a valid accessibility reason, mark FAIL.
### 2. Content Parity (Text)
Fetch the page with a desktop user-agent and a mobile user-agent (Googlebot Smartphone). Compare the visible text content. If any text block over 50 words exists on desktop but not in the mobile HTML source, mark WARN. If important body text, headings, or product descriptions are missing, mark FAIL.
### 3. Structured Data Parity
Extract all JSON-LD blocks from both desktop and mobile fetches. If any schema type present on desktop is missing from mobile, mark FAIL. If schema content differs between versions, mark WARN.
### 4. Meta Tags Parity
Compare title, meta description, canonical, robots, and hreflang tags between desktop and mobile versions. Any difference is a WARN. A missing canonical or conflicting robots tag is FAIL.
### 5. Internal Links and Navigation
Count the number of internal `<a href>` links in the desktop and mobile HTML. If the mobile version has 20%+ fewer internal links, mark WARN. If breadcrumb links, category navigation, or footer links present on desktop are missing from mobile, mark FAIL.
### 6. Image Alt Text
Count images in the mobile HTML. Report the number and percentage missing alt attributes. If more than 10% of images lack alt text, mark WARN. If hero images or product images lack alt text, mark FAIL.
### 7. Core Web Vitals (Field Data)
Look up the URL's Chrome UX Report (CrUX) field data. If accessible via PageSpeed Insights API or a direct CrUX lookup, report LCP, INP, and CLS for mobile. Mark thresholds: LCP > 2.5s = WARN, > 4.0s = FAIL. INP > 200ms = WARN, > 500ms = FAIL. CLS > 0.1 = WARN, > 0.25 = FAIL.
If CrUX data is unavailable (insufficient traffic), note this and use lab data from Lighthouse as a fallback with the caveat that lab data is not used for ranking.
### 8. Tap Target Sizing
Inspect CSS for buttons, links, and interactive elements. Flag any element whose computed height or width is under 48 CSS pixels. Flag adjacent interactive elements with less than 8px spacing. Mark WARN for 1-3 violations, FAIL for 4+.
### 9. Font Sizing
Check that body text uses a computed font-size of at least 16px. Flag any text below 12px. Mark WARN if body text is 14-15px, FAIL if below 12px.
### 10. Interstitials and Pop-ups
Visually inspect the mobile viewport. If a pop-up, banner, or interstitial covers more than 30% of the initial viewport and is not legally required (cookie consent, age verification), mark WARN. If the pop-up prevents scrolling or reading content, mark FAIL.
### 11. AI Crawler Access
Check robots.txt for rules blocking GPTBot, ClaudeBot, PerplexityBot, Google-Extended, or OAI-SearchBot. If any AI crawler is blocked, note that as a deliberate choice. If AI crawlers are allowed but the page has no structured data, mark WARN (AI systems rely on structured data for citations).
## Output Format
Produce a Markdown report:
```markdown
# Mobile-First Audit Report
**Date:** YYYY-MM-DD
**URLs audited:** N
**Overall score:** X/11 PASS items per URL average
## Summary
| Check | URL 1 | URL 2 | URL 3 | URL 4 | URL 5 |
|-------|-------|-------|-------|-------|-------|
| 1. Viewport | PASS | PASS | ... | ... | ... |
| ... | ... | ... | ... | ... | ... |
## Detailed Findings
### URL 1: [url]
**FAIL items (must fix):**
- [Item name]: [evidence and fix instructions]
**WARN items (should fix):**
- [Item name]: [evidence and fix instructions]
**PASS items:** [list]
### Priority Fix Queue
1. [Highest priority fix] — affects indexing directly
2. [Next fix] — affects ranking
3. ...Rules
- Do not make any changes to the site without explicit user approval of a fix plan.
- If you cannot check an item because the page requires authentication, note it as "NOT CHECKED — authentication required."
- For CrUX data, use the official Chrome UX Report API or PageSpeed Insights API if available. If neither is accessible, use Lighthouse mobile audit as a fallback.
- Never fabricate metrics, scores, or check results. If data is unavailable, say so.
- Do not access or expose API keys, cookies, tokens, or credentials.
### Paso 2: Ejecutar la auditoría
Pídele a tu agente: **"Ejecuta el skill de auditoría mobile-first en [TU URL]"** y pega la URL que deseas revisar. El agente producirá un informe con PASS/WARN/FAIL para cada una de las 11 comprobaciones, además de una cola de correcciones priorizadas.
Si quieres revisar varias páginas a la vez, proporciona una lista: **"Ejecuta la auditoría mobile-first en estas 5 URLs: [URL1, URL2, URL3, URL4, URL5]"**.
## Corrección #1: Paridad de contenido — qué revisar primero
La paridad de contenido es la corrección de mayor impacto porque determina directamente lo que Google puede indexar. Esto es lo que falla con más frecuencia y cómo solucionar cada caso.
### Contenido oculto en pestañas y acordeones
Muchos sitios en móvil colapsan contenido extenso en pestañas, acordeones o botones "leer más". Esto es aceptable **siempre que el contenido esté en el código fuente HTML**: Google ya no penaliza el contenido oculto por razones de UX. Pero si tus pestañas cargan contenido mediante JavaScript después de que el usuario toca, Googlebot no activa ese toque. El contenido es invisible.
**Cómo verificar:** En Chrome DevTools, haz clic derecho sobre el contenido oculto y selecciona "Inspeccionar". Si ves el texto en el panel Elements, está en el DOM y Google puede verlo. Si el panel Elements muestra un contenedor vacío hasta que haces clic en la pestaña, el contenido se carga dinámicamente y Google no lo detecta.
**Cómo corregir:** Renderiza el contenido oculto en el HTML del lado del servidor. Usa CSS (`display: none` o alternancia de visibilidad) para el comportamiento de mostrar/ocultar en lugar de inyección de contenido con JavaScript.
### Datos estructurados faltantes en móvil
Los datos estructurados (JSON-LD) deben estar presentes en el HTML móvil. Esto es fácil de pasar por alto si tu tema móvil o versión AMP utiliza una plantilla diferente.
**Cómo verificar:** Abre la página móvil, ve al código fuente (`Cmd+Option+U`) y busca `application/ld+json`. Luego haz lo mismo en escritorio. Los mismos bloques JSON-LD deben aparecer en ambas versiones.
**Cómo corregir:** Asegúrate de que tus datos estructurados se rendericen del lado del servidor y se incluyan en la misma respuesta HTML tanto para móvil como para escritorio. Si usas un CMS, verifica que tu plugin de schema o tema no esté cargando scripts condicionalmente según la detección de dispositivo.
### Enlaces de navegación eliminados de los menús móviles
Los menús móviles a menudo simplifican o eliminan enlaces que existen en la navegación de escritorio: breadcrumbs, enlaces de categorías, columnas del footer, enlaces de barra lateral. Google utiliza los enlaces internos para entender la estructura del sitio y distribuir el PageRank. Los enlaces que faltan en móvil faltan en el grafo de Google.
**Cómo verificar:** Cuenta las etiquetas `<a href>` en el código fuente de escritorio versus el móvil. Un diseño responsive debería tener cantidades aproximadamente iguales. Si el conteo móvil es un 30%+ menor, investiga qué enlaces desaparecieron.
**Cómo corregir:** Agrega los enlaces de navegación faltantes al menú móvil, menú hamburguesa o footer. Prioriza los enlaces a páginas de categorías importantes, artículos clave y páginas principales.
## Corrección #2: INP — la métrica de velocidad móvil que la mayoría de los sitios ignora
Interaction to Next Paint (INP) mide cuánto tarda la página en responder visualmente después de que un usuario toca, hace clic o presiona una tecla. El umbral es **200 milisegundos o menos**.
A diferencia de FID, que solo medía el retraso de entrada de la primera interacción, INP mide cada interacción y reporta la **peor**. Esto lo convierte en una prueba mucho más estricta.
### Qué afecta negativamente el INP en móvil
Las causas más comunes, en orden:
1. **JavaScript pesado ejecutándose en el hilo principal.** Bundles grandes, componentes React/Vue no optimizados y scripts de seguimiento bloquean al navegador para que no responda a los toques.
2. **Manejadores de clic que hacen demasiado trabajo antes de actualizar la UI.** Si un toque desencadena una llamada API, actualización de estado y cambio en el DOM antes de mostrar alguna retroalimentación visual, el INP se ve afectado.
3. **Etiquetas de terceros.** Analytics, widgets de chat, redes publicitarias y scripts de personalización, especialmente cuando múltiples etiquetas compiten por el hilo principal.
### Cómo diagnosticar INP
1. Abre [PageSpeed Insights](https://pagespeed.google.com/), ingresa tu URL, desplázate hasta "Descubre lo que experimentan tus usuarios reales". El valor de INP en "Móvil" es el que Google utiliza.
2. En Chrome DevTools, abre el panel **Performance**, haz clic en grabar, interactúa con la página (toca botones, abre menús, escribe en campos) y luego detén la grabación. Busca tareas largas (marcadas en rojo, 200ms+). Estos son tus problemas de INP.
3. También puedes preguntarle a tu agente de IA: **"Revisa los Core Web Vitals de [URL] y dime específicamente qué está perjudicando el INP en móvil. Dame las 3 principales correcciones en orden de prioridad."**
### Cómo corregir INP (orden de prioridad)
```text
Prioridad 1: Diferir o retrasar scripts de terceros no críticos.
→ Carga widgets de chat, analytics y etiquetas publicitarias después de que la página sea interactiva.
→ Usa <script defer> o cárgalos 3-5 segundos después de la carga de la página.
Prioridad 2: Dividir las tareas largas de JavaScript.
→ Divide el código por ruta. Carga de forma diferida los componentes bajo el pliegue.
→ Mueve la computación pesada a requestIdleCallback() o un Web Worker.
Prioridad 3: Haz que los manejadores de clic actualicen la UI de inmediato.
→ Muestra un estado de carga, spinner o botón deshabilitado en los primeros 50ms.
→ Ejecuta el trabajo real (llamada API, actualización de estado) después de la respuesta visual.Corrección #3: Preparación para rastreadores de IA (la capa 2026)
La indexación mobile-first ahora tiene una capa de IA. Cuando las AI Overviews de Google o los sistemas de IA de terceros responden una pregunta, extraen información del mismo contenido indexado en móvil. Si tus páginas móviles carecen de las señales que los sistemas de IA buscan, pierdes citas.
Lo que los sistemas de IA necesitan de tus páginas móviles
Señal | Por qué importa | Verificación rápida |
|---|---|---|
Datos estructurados (JSON-LD) | Ayuda a los sistemas de IA a entender entidades, productos, artículos, FAQs | Ver código fuente → buscar |
Jerarquía clara de encabezados | Los extractores de IA usan H1-H4 para analizar la estructura de la página | Revisa tu página: ¿cada sección tiene un encabezado descriptivo? |
Bloques de respuesta concisos | Las AI Overviews prefieren respuestas de 2-4 oraciones cerca de la parte superior | ¿Tu página responde la pregunta principal en las primeras 200 palabras? |
Acceso en robots.txt para rastreadores de IA | Si están bloqueados, los sistemas de IA no pueden obtener tu contenido | Revisa robots.txt para |
Archivo llms.txt | Ayuda a los sistemas de IA a descubrir tu contenido clave eficientemente | Verifica |
Prompt rápido de preparación para IA para tu agente
"Revisa [URL] para preparación en búsqueda con IA. Dime: (1) ¿los datos estructurados JSON-LD están presentes y son válidos? (2) ¿hay una respuesta clara a la pregunta principal de la página en las primeras 200 palabras? (3) ¿los rastreadores de IA están permitidos en robots.txt? (4) ¿existe llms.txt en la raíz? Dame un PASS/FAIL para cada uno e indica qué corregir primero."
Prompts completos de auditoría mobile-first para principiantes
Aquí tienes un conjunto de prompts que puedes copiar en Claude Code o Codex ahora mismo. Cada prompt hace un trabajo específico, sin necesidad de configuración adicional más allá de tener el agente abierto y apuntando a tu proyecto o una URL.
Prompt 1: Auditoría móvil de una sola página
Ejecuta una auditoría de indexación mobile-first en [TU URL AQUÍ].
Revisa estas 8 cosas e informa PASS o FAIL para cada una con la evidencia:
1. La meta etiqueta viewport es correcta
2. Todo el texto del cuerpo visible en escritorio también está en el código fuente HTML móvil
3. Los datos estructurados JSON-LD son iguales en escritorio y móvil
4. La etiqueta title, meta description y canonical son idénticas en escritorio y móvil
5. El conteo de enlaces internos es aproximadamente igual (no un 20%+ menos en móvil)
6. Las imágenes tienen texto alternativo
7. Core Web Vitals en móvil (LCP, INP, CLS) según datos de campo de CrUX si están disponibles
8. Los rastreadores de IA (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) no están bloqueados en robots.txt
Para cada FAIL, dame la corrección exacta en una sola oración.Prompt 2: Auditoría masiva por tipo de página
Necesito auditar la preparación mobile-first en diferentes tipos de página de mi sitio. Aquí hay 5 URLs, cada una representando una plantilla diferente:
1. [URL DE INICIO]
2. [URL DE PÁGINA DE PRODUCTO O SERVICIO]
3. [URL DE ARTÍCULO DE BLOG]
4. [URL DE PÁGINA DE CATEGORÍA O COLECCIÓN]
5. [URL DE PÁGINA DE ACERCA DE O CONTACTO]
Para cada URL, verifica: meta etiqueta viewport, paridad de contenido (texto + datos estructurados), consistencia de meta etiquetas, enlaces internos, cobertura de texto alternativo en imágenes y dimensionamiento de fuente/objetivos táctiles en móvil.
Luego produce una sola tabla con las 5 URLs como columnas y cada verificación como fila. Codifica con colores PASS verde, WARN amarillo, FAIL rojo (usa emoji 🟢 🟡 🔴 si los colores no son compatibles). Debajo de la tabla, enumera las 3 principales correcciones en todas las páginas en orden de prioridad.Prompt 3: Análisis profundo de paridad de contenido
Obtén [URL] tanto con un user-agent de escritorio como con el user-agent de Googlebot Smartphone (Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)).
Compara las dos versiones e informa cualquier diferencia en:
- Contenido de texto visible (resalta los bloques que faltan en móvil)
- Datos estructurados (bloques JSON-LD)
- Meta etiquetas (title, description, canonical, robots, hreflang)
- Conteo de enlaces internos y qué secciones perdieron enlaces
- Atributos alt de imágenes
No hagas ninguna edición. Solo produce un informe de diferencias.Prompt 4: Diagnóstico de INP y plan de corrección
Analiza [URL] para problemas de Interaction to Next Paint (INP) en móvil.
1. Verifica si hay datos de campo de CrUX disponibles e informa el valor actual de INP en móvil.
2. Si los datos de CrUX no están disponibles, ejecuta una auditoría Lighthouse en móvil e informa el Total Blocking Time (TBT) como indicador proxy.
3. Identifica las 3 principales tareas de JavaScript que bloquean el hilo principal durante la carga de la página y después de la interacción del usuario.
4. Para cada problema, indícame: el archivo o script específico que lo causa, el impacto en INP y la corrección en una línea.
Formatea la salida como una tabla: Problema | Origen | Impacto | Corrección.Prompt 5: Auditoría de rastreadores de IA + datos estructurados
Revisa [URL] para preparación en búsqueda con IA y rastreadores de IA:
1. Rastrea robots.txt en la raíz del dominio. Enumera todas las reglas que mencionen estos user-agents: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, OAI-SearchBot, Amazonbot, Bytespider. Si alguno está bloqueado, márcalo.
2. Extrae todos los bloques JSON-LD de la página. Valida cada uno contra los tipos de Schema.org. Informa qué tipos están presentes y si están completos (todas las propiedades requeridas completadas).
3. Verifica si /llms.txt existe en la raíz del dominio. Si existe, informa un resumen de su contenido. Si no existe, señálalo como un activo de descubrimiento de IA faltante.
4. Verifica si la página tiene una respuesta clara y autónoma (2-4 oraciones) a su tema principal dentro de las primeras 200 palabras del cuerpo del texto.
5. Califica la página en preparación para IA: 0-100. Resta puntos por: datos estructurados faltantes (-30), rastreadores de IA bloqueados (-20 por rastreador), sin llms.txt (-15), sin bloque de respuesta claro (-20), encabezados no descriptivos (-15).Preguntas frecuentes
P: ¿Todavía puedo usar un sitio móvil separado (m.example.com)? Técnicamente sí, pero Google recomienda el diseño responsive. Las URLs móviles separadas añaden complejidad: debes mantener contenido idéntico, etiquetas canonical y hreflang en dos conjuntos de URLs. Si algo se desincroniza, Google indexa la versión que rastreó más recientemente. El diseño responsive elimina este riesgo por completo.
P: ¿Qué pasa si mi sitio es solo de escritorio, sin versión móvil? Si Googlebot Smartphone no puede acceder y renderizar tu contenido, ese contenido no será indexado. Punto. Un sitio solo de escritorio en 2026 es efectivamente invisible para Google. Si te encuentras en esta situación, migrar a un tema responsive es tu tarea de mayor prioridad.
P: ¿Necesito preocuparme por los tamaños de tablet? Googlebot rastrea como smartphone, no como tablet. Enfócate en el viewport de smartphone. Dicho esto, los usuarios de tablet son usuarios reales: asegúrate de que tu diseño responsive no se rompa en anchos intermedios (768-1024px).
P: ¿Cómo sé si mi sitio ya superó la transición a mobile-first? Abre Google Search Console → Configuración → revisa la sección "Acerca de" para "Rastreador de indexación: Googlebot smartphone". Si dice eso, estás en indexación mobile-first. Casi todos los sitios lo están ahora.
P: ¿Google todavía rastrea mi sitio con un user-agent de escritorio para algo? Sí. Google ocasionalmente rastrea con un user-agent de escritorio para verificaciones específicas (verificación de relaciones, reprocesamiento de algunos datos estructurados). No te alarmes si ves Googlebot de escritorio en tus registros. Esas visitas no significan que tu sitio esté en indexación desktop-first.
P: ¿Corregir los problemas de mobile-first mejorará mi visibilidad en AI Overviews? Las correcciones de indexación mobile-first mejoran la base. Si tu contenido móvil, datos estructurados y velocidad de página son sólidos, tu contenido es elegible para ser citado, pero los sistemas de IA de Google aún eligen qué citar según la relevancia, autoridad y calidad de la respuesta. Corregir los problemas de mobile-first elimina un obstáculo; no garantiza la inclusión en IA.
Autor: Julian Mercer, profesional de SEO técnico con 14 años de experiencia en Auspia. Julian escribe sobre rastreabilidad, renderizado, schema, arquitectura de sitios y los fundamentos técnicos que hacen que el contenido sea descubrible por motores de búsqueda y sistemas de IA.
