¿Qué es Googlebot? Rastreo, renderizado e indexación explicados

TL;DR. Googlebot no es un solo bot, sino una familia de rastreadores, y Googlebot Smartphone es el que mueve casi todo desde que la indexación mobile-first pasó a ser el valor por defecto en 2023. Su trabajo ocurre en tres fases (crawl, render, index) que pueden espaciarse horas o días, y la fase de renderizado es donde vive la mayoría de las quejas de «Googlebot no puede ver mi página». De los tickets de soporte que triageamos en SEOJuice entre mediados de 2024 y principios de 2026, unas 6 de cada 10 escalaciones de indexación resultaron ser problemas en la fase de renderizado; solo 2 de cada 10 eran fallos reales de crawl (el resto eran etiquetas noindex o robots.txt mal configurados). Esta guía cubre la familia de bots, el pipeline de tres fases, cómo verificar un acceso auténtico de Googlebot, las preguntas sobre robots y crawl-budget que todos hacen y cómo se compara Googlebot con Bingbot, GPTBot, PerplexityBot y ClaudeBot en 2026.

Actualizado mayo de 2026. Añadidos datos propietarios del mix de tickets de SEOJuice, una anécdota con nombre propio sobre una caída por bot-fight en Cloudflare y un callback en la sección de rastreadores de IA que enlaza con los modos de fallo de renderizado JS tratados antes en el artículo.

Escribí esto porque envío la misma explicación por Intercom tres o cuatro veces a la semana. El cliente dice: «Googlebot está bloqueado en mi sitio». Abrimos Search Console. La fase de crawl está bien. La fase de renderizado se rompió hace una semana cuando un desarrollador refactorizó un panel de pestañas y no notó que el cuerpo del artículo ahora se monta tras un clic. Quería una URL que pudiera pegar en el ticket en lugar de teclear el mismo párrafo cada vez. Esta es esa URL.

¿Qué es realmente Googlebot? (En castellano llano)

Googlebot es el programa que utiliza Google para obtener páginas web y añadirlas a su índice. Cuando publicas un nuevo post y acaba apareciendo en los resultados de búsqueda, ese viaje empieza con Googlebot solicitando la URL, descargando el HTML, ejecutando el JavaScript y enviando el resultado al sistema de indexación de Google. Sin Googlebot, ninguna de tus páginas existe para la búsqueda de Google.

Dos matices que conviene dejar claros desde el principio. «Googlebot» se usa a veces de forma laxa para referirse a «cualquier rastreador de Google». Estrictamente, Googlebot es el rastreador que obtiene páginas para el índice principal de búsqueda de Google. Existen otros rastreadores (AdsBot para revisar landings de Ads, Storebot para listados de Shopping, Google-Extended para exclusiones de entrenamiento de IA) y cada uno tiene reglas y agendas distintas. Sé específico cuando depures.

Googlebot también se diferencia de un scraper. Lee tu archivo robots.txt antes de cada rastreo, respeta las etiquetas meta noindex, se autolimita cuando tu servidor se ralentiza e incluye su identificación en las cabeceras para que verifiques que la petición proviene realmente de Google. Si ves un «Googlebot» en tus logs machacando tu origen sin aflojar, casi seguro no es Googlebot real. Verifícalo antes de aplicar rate-limiting.

Googlebot es en realidad una familia de rastreadores

El bot que más debes tener en mente es Googlebot Smartphone, que rastrea la versión móvil de tu sitio por defecto desde que Google concluyó la indexación mobile-first a mediados de 2023. El rastreo de escritorio sigue existiendo, pero ahora es secundario. Aquí tienes el árbol familiar con las cadenas de agente de usuario exactas que publica Google:

El marcador W.X.Y.Z en los user-agents de Smartphone y Desktop no es literal. Google sustituye la versión real de Chromium en cada petición y esa versión evoluciona con la rama estable de Chrome. Hoy, el motor de renderizado de Googlebot va solo unas semanas por detrás del Chrome público. (Durante años dije a los clientes que trataran el renderizador de Googlebot como si fuese Chrome 41, que fue cierto hasta la actualización evergreen de 2019. Siguió en mis consejos —ya obsoletos— hasta 2021, hasta que una charla de Martin Splitt en Search Off the Record me obligó a leer la documentación actual). Si tu sitio necesita una característica JS que requiera Chrome 130 +, Googlebot probablemente la soporte. Si precisa algo aún no lanzado, Googlebot no lo hará.

El pipeline de tres fases: Crawl, Render y Index

El trabajo de Googlebot se divide en tres fases distintas. No ocurren a la vez y un retraso o fallo en cualquiera de ellas puede dejar tu página fuera de los resultados. Google lo describe así de claro: «Google procesa las aplicaciones web JavaScript en tres fases principales: 1. Crawling 2. Rendering 3. Indexing.» Si no sabes en qué fase está el problema, estás adivinando la solución. Esa distinción sostiene todo este artículo.

Phase 1: Crawling

Googlebot toma una URL de su cola, envía una petición HTTP y recibe el HTML en bruto. Nada de JavaScript todavía, ningún contenido renderizado. Lee el código de estado, las cabeceras (caché, X-Robots-Tag, redirecciones) y el cuerpo HTML. Las URLs provienen de sitemaps XML, enlaces internos, enlaces externos y envíos directos a través de la herramienta de Inspección de URLs.

Si ese HTML ya incluye todo lo indexable (renderizado SSR clásico), Googlebot puede seguir adelante. Si el HTML está casi vacío y el contenido se inyecta por JS, la página pasa a la fase de renderizado. Aquí también lee robots.txt; si la URL está prohibida, ni siquiera la solicita.

Phase 2: Rendering

Si la página necesita ejecutar JavaScript para mostrar su contenido, Googlebot la pasa al Web Rendering Service (WRS). El WRS es un Chromium sin cabeza que carga la página, ejecuta los scripts y genera el HTML final. Lo dice la doc: «Cuando los recursos de Google lo permiten, un Chromium sin cabeza renderiza la página y ejecuta el JavaScript.»

La frase «cuando los recursos de Google lo permiten» se carga de significado. Renderizar es caro, así que Google lo pone en cola. Las páginas pueden estar en esa cola segundos, horas o días. (Tengo una captura de 96 h entre crawl y render en un Next.js e-commerce de 2024 y la tengo fijada en Slack para zanjar discusiones sobre si «Googlebot ya rastreó» basta). La guía oficial es vaga: «Puede tardar más que eso.» Lo que no está claro es cómo prioriza la cola. He visto sitios casi idénticos renderizarse en 5 min vs 36 h sin descubrir la causa.

Ese retraso es el problema recurrente en sitios renderizados por JS. Tu post se rastrea en minutos pero no se renderiza hasta 24 h después, así que no aparece hasta el día siguiente aunque Google «vio» la URL. Las páginas SSR se saltan esta cola.

Phase 3: Indexing

Cuando Googlebot tiene el HTML final (del crawl o del WRS), el sistema de indexación lo analiza, extrae texto, clasifica, evalúa señales de ranking y lo guarda en el índice. Desde ahí la página puede aparecer en los resultados. La indexación tampoco es instantánea y puede tardar minutos u horas, pero el trabajo de Googlebot para esa URL termina aquí; lo demás es ranking.

Qué rompe el renderizado de JavaScript (y cómo detectarlo)

El renderizado es donde falla. El crawl casi siempre va bien; la página simplemente no se renderiza como esperaba el desarrollador. Estos seis modos de fallo son los que más veo en clientes de SEOJuice, en orden descendente de frecuencia —los dos primeros suman más de la mitad de las escalaciones de renderizado según la muestra citada en el TL;DR.

1. Contenido que requiere interacción del usuario para cargarse

Si hay que hacer clic en «Mostrar más» para revelar una sección, Googlebot no la verá. El WRS ejecuta JS pero no hace clic ni scroll. Todo lo importante debe estar en el DOM al cargar, aunque se oculte con CSS. Es el fallo más común y suele aparecer en librerías que montan perezosamente pestañas, acordeones y feeds de «cargar más».

2. Lazy-loading sin señales adecuadas

Las imágenes y bloques lazy-loaded necesitan el atributo nativo loading="lazy" o un Intersection Observer que el WRS pueda resolver. Las librerías que esperan scroll fallan porque no hay scroll. Usa loading="lazy" para imágenes; para componentes, asegúrate de que se rendericen en el servidor o usen un framework con SSR/hidratación.

3. Errores de JavaScript durante la ejecución

Si un script alto en la página lanza una excepción sin capturar, los scripts siguientes quizá no corran y el resto quede vacío. El WRS ve lo que se renderizó antes del error. Usa «Ver página probada» de la Inspección de URL para comprobar el HTML renderizado y la captura.

4. Reglas de WAF y protección anti-bot

CAPTCHAs, el bot-fight mode de Cloudflare demasiado agresivo y bloqueos geográficos ingenuos pueden devolver 403 o un challenge a las IP de Googlebot. (El modo bot-fight por defecto de Cloudflare ha provocado más incidentes que cualquier otro ajuste: un SaaS B2B perdió dos tercios de sus páginas indexadas en un fin de semana de 2024 cuando un becario lo activó; tardaron tres semanas en recuperarse). Lista blanca las IP de Google (googlebot.json) antes de activar «block bots». Verifica con la Inspección de URL cada vez que cambies el WAF.

5. Recursos bloqueados en robots.txt

Si tu robots.txt bloquea /static/ o /assets/, el WRS no puede cargar los bundles JS y CSS y tu página saldrá sin estilos o con JS roto. Permite rastrear los assets estáticos aunque bloquees otras rutas.

6. Contenido tras autenticación o cookies

Googlebot no se autentica, no acepta cookies de forma útil y no mantiene sesión. Cualquier cosa tras login no se indexará. Usa la API de indexación o datos estructurados para contenido de pago si necesitas que se descubra y deja claro qué está restringido.

La comunidad SEO debatió 2017-2020 si el renderizador de Googlebot alcanzaría a Chrome moderno. El debate terminó: se igualó con el cambio evergreen de 2019 y desde entonces sigue la rama estable, pero mucho consejo aún circulante es previo, razón por la que los puntos 1 y 2 siguen apareciendo.

Cómo verificar que una petición es realmente Googlebot

La cadena UA de Googlebot se falsifica fácil. Cualquiera puede enviar una petición que diga ser Googlebot. Las peticiones reales vienen de rangos de IP de Google. La forma fiable de verificarlas es resolver DNS inversa y luego directa:

1. Toma la IP de los logs.
2. Haz DNS inversa: el hostname debe acabar en .googlebot.com o .google.com.
3. Haz DNS directa sobre ese hostname: debe volver a la misma IP.
4. Si ambos pasos pasan, es Googlebot real; si falla uno, es spoof.

En consola: host 66.249.66.1 y luego host crawl-66-249-66-1.googlebot.com. En sitios de alto tráfico, automatízalo; verás cuántos «picos de Googlebot» son scrapers con ese UA. Ahrefs tiene un buen tutorial del mismo proceso con ejemplos curl.

robots.txt y crawl budget: las preguntas tácticas que todo el mundo hace

¿Cuánto va a rastrear Googlebot mi sitio?

Google lo llama crawl budget. Para sitios de menos de ≈10 000 URLs casi nunca limita. Googlebot rastreará todo lo importante en un plazo razonable. Se vuelve crítico solo en sitios con millones de URLs, e-commerce facetados o donde Googlebot desperdicia rastreos en duplicados. Google publica dos factores: velocidad de rastreo (qué tan rápido responde tu servidor sin errores) y demanda (popularidad y frecuencia de cambios). El post de Semrush desglosa bien las señales de velocidad.

¿Debo bloquear a Googlebot en URLs de bajo valor?

Sí, si consumen crawl budget en un sitio grande. Patrón típico: bloquear URLs de búsqueda facetada, resultados de búsqueda interna, paginaciones más allá de la 5, variantes con ID de sesión y endpoints de admin. Usa robots.txt para bloquear el rastreo y noindex para bloquear la indexación. Robots impide el rastreo; noindex permite el rastreo pero no indexa.

¿Cómo acelero la indexación de una página nueva?

Envíala con la Inspección de URL en Search Console. Dispara un rastreo fuera de banda (Google-InspectionTool) y es más rápido que esperar la cola normal. Además enlaza la página nueva desde una ya indexada y de autoridad para que el siguiente rastreo regular la encuentre.

¿Por qué Googlebot está rastreando mi entorno de desarrollo?

Porque alguna URL de tu dominio de staging/dev se filtró (enlace accidental, issue tracker, resultado de búsqueda) y Googlebot sigue el grafo de enlaces. Bloquea todo el staging en robots.txt con Disallow: / y añade auth básica si el contenido es sensible.

Depuración de problemas «Googlebot no puede ver esta página»

La versión sistemática hace cuatro comprobaciones en orden hasta encontrar respuesta.

Comprobación 1, Inspección de URL en Search Console. Pega la URL. La herramienta indica si Google la ha rastreado e indexado, cuándo lo hizo y permite «Ver página probada» para ver el HTML renderizado y la captura. Si falta contenido en el HTML renderizado, el problema está en renderizado. Si la página devuelve un estado ≠ 200, el problema está en el crawl. Suele resolver dos tercios de los tickets sin pasar al paso 2.

Comprobación 2, curl con el UA de Googlebot. Ejecuta curl -A "Mozilla/5.0 ... Googlebot/2.1 ..." https://tusitio.com/ruta. Si tu servidor da contenido distinto a Googlebot que a un navegador normal, lo verás. El cloaking (intencional o no) es causa frecuente de misterios de indexación.

Comprobación 3, auditoría de robots.txt y metaetiquetas. Visita https://tusitio.com/robots.txt. Confirma que la URL no esté bloqueada. Luego busca noindex en el código fuente. Sorprende cuántas veces un noindex sobrante de staging causa el problema.

Comprobación 4, análisis de logs del servidor. Filtra los accesos de Googlebot verificado de los últimos 30 días. Si la URL nunca aparece, es problema de descubribilidad: Googlebot no sabe que existe. Añádela al sitemap y enlázala. Si aparece pero devuelve siempre 4xx o 5xx, arregla eso antes de reintentar. SEOJuice ejecuta este análisis en cada sitio conectado y alerta la primera vez que una URL clave deja de recibir tráfico de Googlebot real.

Googlebot vs Bingbot vs los rastreadores de IA

Antes solo se pensaba en Googlebot; eso cambió. Así se comparan los principales rastreadores web en 2026:

Observa cómo los fallos 1, 2 y 5 de la lista de JS — gating por interacción, señales de lazy-load y assets bloqueados — golpean más a los rastreadores de IA que a Googlebot porque sus renderizadores son más débiles. La misma checklist sirve para un problema de citaciones en Perplexity; por ahora el riesgo es menor que en Google Search. (Asumí demasiado tiempo que PerplexityBot se comportaba como Googlebot; lo comprobé cuando un sitio SSR de un cliente superó 4× a su competidor CSR en citaciones y tuve que admitir mi error).

Dos implicaciones prácticas: 1) los rastreadores de IA renderizan peor JS que Googlebot; si dependes de CSR, puedes posicionar en Google pero ser invisible para ChatGPT, Perplexity y Claude. La solución es la misma: SSR o prerender. Nuestra herramienta gratuita de visibilidad en IA te muestra en menos de un minuto qué rastreador ve tu página vacía. 2) cada rastreador de IA tiene su propia directiva robots.txt. User-agent: GPTBot bloquea OpenAI, User-agent: Google-Extended bloquea Gemini, User-agent: Googlebot sigue controlando la búsqueda clásica. Configura reglas separadas si quieres estar en Google Search pero fuera del entrenamiento IA.

«Lo que la gente suele pasar por alto sobre Googlebot es que el crawl y el render no son el mismo paso. Una URL puede ser rastreada y aun así no tener una versión renderizada del contenido durante horas». — Martin Splitt, Google Search Relations, parafraseado de su punto recurrente en Search Off the Record.

Preguntas frecuentes

¿Qué es Googlebot?

Googlebot es el rastreador web que usa Google para descubrir y descargar páginas para indexarlas y mostrarlas en los resultados. Es una familia de rastreadores (Smartphone, Desktop, Image, Video, News) con distintos UA y propósitos, pero casi siempre «Googlebot» se refiere a Googlebot Smartphone, rastreador principal desde que se completó la indexación mobile-first en 2023.

¿Googlebot ejecuta JavaScript?

Sí. El WRS es un Chromium sin cabeza que ejecuta JS en las páginas que lo requieren. Sigue las versiones estables recientes de Chrome, así que el JS moderno suele funcionar. El problema es la cola de renderizado: puede pasar segundos, horas o días tras el crawl inicial. Las páginas SSR se saltan la cola.

¿Cómo compruebo si una petición es realmente de Googlebot?

Haz una DNS inversa a la IP: debe terminar en .googlebot.com o .google.com. Luego una DNS directa al hostname: debe resolver a la misma IP. Si falla, es un spoof. El header UA no basta; cualquiera puede enviarlo.

¿Puedo bloquear Googlebot?

Sí. Añade User-agent: Googlebot y Disallow: / en robots.txt. Bloquearás el rastreo y, por tanto, la indexación. Para control granular usa noindex en páginas concretas o bloquea rutas específicas en robots.txt. No bloquees a Googlebot tus bundles CSS/JS; los necesita para renderizar.

¿Es Googlebot lo mismo que GPTBot o PerplexityBot?

No. Son rastreadores distintos de empresas distintas con objetivos distintos. Googlebot indexa para Google Search. GPTBot recopila datos para ChatGPT. PerplexityBot recupera contenido para el motor de respuestas de Perplexity. Cada uno tiene su propia UA y reglas robots. Puedes permitir uno y bloquear otro.

¿Por qué Googlebot aún no ha indexado mi página nueva?

Causas más comunes: la página no está enlazada desde ninguna URL indexada; devuelve un código ≠ 200; tiene noindex; está bloqueada por robots.txt; depende de JS y aún no se ha renderizado. Usa la Inspección de URL para ver cuál; «Ver página probada» muestra exactamente lo que vio Googlebot. Las páginas nuevas suelen tardar de horas a días, más si tu frecuencia de rastreo es baja.

Lo que esto significa realmente para tu sitio

En la práctica: si tu contenido depende de JS y solo compruebas «¿rankeo en Google?», optimizas para el renderizador más fuerte e ignoras el resto. Los rastreadores de IA son más débiles y su tráfico referencial crece cada trimestre. El SSR ya no es una optimización para Google; es un requisito de visibilidad en IA. Quédate con ese cambio de enfoque.

Si quieres saber rápido qué rastreadores realmente ven tu sitio, nuestra herramienta gratuita de visibilidad en IA renderiza tu URL bajo las mismas limitaciones de Googlebot, GPTBot, PerplexityBot y ClaudeBot y te muestra cuál ve una página en blanco. En la mayoría de auditorías encontramos al menos una plantilla crítica (producto o blog) que Google ve bien y Perplexity ve vacía.

Lo que aún intento descifrar: la lógica de priorización de la cola de renderizado. La doc dice que depende de recursos, pero la variación entre sitios casi idénticos sugiere algo más. Si tienes datos limpios antes/después, compártelos.

Lecturas relacionadas:

• SEO para Single Page Applications
• Answer Engine Optimization (AEO)
• Herramienta gratuita de auditoría SEO
• Comprobador gratuito de visibilidad en IA