Robots.txt: errores que bloquean a Googlebot sin que lo sepas | Ighenatt

El robots.txt más peligroso no es el que tiene errores obvios. Es el que parece correcto, que nadie ha revisado en meses, y que está bloqueando silenciosamente páginas clave que Googlebot nunca llega a ver. En auditorías sistemáticas con Screaming Frog, una proporción significativa de los sitios que analizan presentan alguna directiva problemática en su robots.txt que afecta páginas que deberían estar indexadas.

El archivo robots.txt lleva ahí desde los primeros días del SEO. Lo generó alguien, en algún momento, y después nadie lo volvió a tocar. Ese es precisamente el problema.

A diferencia de la configuración de un sitemap o una etiqueta canonical, el robots.txt opera en una capa previa a cualquier otra señal SEO: si bloqueas una URL aquí, Googlebot no llega a leer ni el título, ni las etiquetas meta, ni el schema markup. Todo el trabajo de optimización on-page queda irrelevante antes de empezar.

Qué es el robots.txt y cómo lo interpreta Googlebot realmente

El robots.txt es un archivo de texto plano que vive en la raíz de tu dominio (https://tudominio.com/robots.txt). Su función es comunicar a los robots de búsqueda qué partes del sitio pueden y no pueden rastrear. La especificación es sencilla en teoría. En la práctica, hay suficientes matices de interpretación para que los errores sean frecuentes y costosos.

Lo primero que hay que entender: el robots.txt no es un mecanismo de seguridad. Google lo sigue por convención, no por obligación. Un robot malicioso ignorará el archivo sin consecuencias técnicas. El robots.txt solo sirve para gestionar el rastreo de bots que respetan la especificación, principalmente los motores de búsqueda.

Lo segundo: Google cachea el robots.txt. No lo lee en cada visita. Lo descarga periódicamente (cada pocos días en sitios activos) y usa esa versión en caché para todas sus decisiones de rastreo hasta la siguiente actualización. Un cambio urgente en el robots.txt puede tardar 24-48 horas en reflejarse en el comportamiento real de Googlebot.

La estructura básica de una directiva es simple:

User-agent: [nombre del bot]
Disallow: [ruta bloqueada]
Allow: [ruta permitida]

Google acepta * como comodín universal para User-agent (todos los robots) y como wildcard en rutas. También acepta $ para indicar el final de una URL. Lo que Google no acepta son algunos patrones avanzados de expresiones regulares que otros bots sí interpretan — un punto de confusión frecuente cuando se copian configuraciones de otras fuentes.

John Mueller, Senior Search Analyst en Google, ha reiterado en múltiples sesiones de preguntas y respuestas que el robots.txt no garantiza privacidad y que bloquear una URL aquí no la elimina del índice. Si la URL ya está indexada cuando se añade la directiva Disallow, Google puede mantenerla en los resultados durante meses porque no puede visitarla para verificar si debe desindexarla.

Error #1 — Disallow: / (bloquear todo el sitio por accidente)

Este es el error más grave y, sorprendentemente, ocurre con frecuencia suficiente como para que Google lo mencione específicamente en su documentación. El resultado: Googlebot no puede rastrear ninguna página del sitio.

# INCORRECTO — bloquea todo el sitio a todos los bots
User-agent: *
Disallow: /

La causa más común no es malicia ni ignorancia: es copiar el robots.txt del entorno de staging al de producción. Los entornos de desarrollo y preproducción suelen bloquear todo el rastreo para evitar que aparezcan en los resultados de búsqueda. Cuando se hace el despliegue a producción y alguien copia el archivo de configuración completo, el bloqueo viaja con él.

La versión correcta para un sitio que quiere permitir el rastreo general es:

# CORRECTO — permite el rastreo de todo el sitio
User-agent: *
Disallow:

# Si hay secciones específicas que bloquear:
User-agent: *
Disallow: /admin/
Disallow: /wp-admin/
Disallow: /carrito/

Una línea Disallow: vacía es la forma estándar de decirle a Googlebot que puede rastrear cualquier ruta. No necesitas escribir Allow: / (aunque también funciona).

La señal de alerta más clara de este error: Google Search Console empieza a mostrar una caída drástica en las páginas rastreadas, y el informe de Cobertura muestra decenas o cientos de páginas en estado “Excluida: bloqueada por robots.txt”. Si ves esa combinación, revisa el robots.txt inmediatamente.

Error #2 — Bloquear recursos CSS y JavaScript críticos para el renderizado

Este error no bloquea páginas completas. Bloquea los recursos que Googlebot necesita para renderizar esas páginas correctamente. El efecto es más sutil pero igualmente dañino.

Cuando Googlebot visita una URL, no se limita a leer el HTML. Descarga los archivos CSS y JavaScript referenciados para renderizar la página tal como la vería un usuario real. Si el robots.txt bloquea esos recursos, Googlebot ve una versión degradada del contenido — y esa versión degradada es la que evalúa para el ranking.

Los patrones de bloqueo que causan este problema con más frecuencia:

# INCORRECTO — bloquea recursos necesarios para el renderizado
User-agent: *
Disallow: /wp-content/uploads/
Disallow: /wp-content/plugins/
Disallow: /assets/
Disallow: /static/
Disallow: /css/
Disallow: /js/

La intención detrás de estos bloqueos suele ser razonable: evitar que Google indexe archivos individuales que no aportan valor como páginas. El problema es que “no indexar” y “no rastrear” son cosas diferentes. Google no va a indexar un archivo /assets/main.css como si fuera una página de resultados, pero sí necesita descargarlo para renderizar cualquier página que lo use.

# CORRECTO — permite el rastreo de recursos, bloquea solo lo necesario
User-agent: *
Disallow: /wp-admin/
Disallow: /wp-login.php
Disallow: /carrito/
Disallow: /checkout/
Disallow: /mi-cuenta/

# Los recursos CSS, JS e imágenes NO se bloquean

Google Search Central documenta explícitamente esta recomendación: permitir el acceso a todos los archivos que el navegador necesita para renderizar la página es fundamental para que Googlebot pueda evaluar correctamente el contenido.

Para verificar si Googlebot puede acceder a los recursos de una página, usa la herramienta de Inspección de URLs en Google Search Console. El informe muestra si hubo recursos bloqueados durante el último rastreo y cuáles fueron. Si aparece la sección “Recursos de página bloqueados”, tienes este problema.

Error #3 — Sintaxis incorrecta: case-sensitivity y espacios que cuestan indexación

El robots.txt es más estricto de lo que parece en su sintaxis. Dos errores específicos de formato causan problemas que son difíciles de detectar sin herramientas:

Case-sensitivity en rutas: Las rutas en las directivas Disallow y Allow son case-sensitive en la especificación de Google. Esto significa que:

# INCORRECTO si tu URL real es /admin/ (minúsculas)
User-agent: *
Disallow: /Admin/

# CORRECTO — la capitalización debe coincidir exactamente con la URL real
User-agent: *
Disallow: /admin/

Si tu sitio tiene URLs con mayúsculas (algo que debería evitarse, pero existe en muchos CMS), necesitas bloquear las versiones exactas. Un bloqueo de /Admin/ no afecta a /admin/ ni a /ADMIN/.

Espacios en la directiva User-agent: RFC 9309 (Section 2.2) permite whitespace opcional (OWS — optional whitespace) alrededor del :, por lo que un espacio antes o después de los dos puntos no es técnicamente incorrecto. Sin embargo, como buena práctica se evitan los espacios extra por claridad y para garantizar la compatibilidad máxima con todos los parsers:

# No recomendado — espacios innecesarios alrededor del ':'
User-agent : *
Disallow: /admin/

# Recomendado
User-agent: *
Disallow: /admin/

Directivas sin User-agent: Cualquier directiva que no esté asociada a un bloque User-agent es ignorada. Si alguien añade una directiva Disallow fuera de un bloque, no tiene ningún efecto pero tampoco genera un error visible:

# INCORRECTO — la directiva Disallow sin User-agent previo es ignorada
Disallow: /area-privada/

User-agent: *
Disallow: /admin/

El orden importa para la agrupación: Según Google Search Central, cuando existen dos bloques separados para el mismo User-agent, Google combina las reglas de ambos bloques en un único grupo antes de procesarlas. Esto puede producir resultados inesperados si la intención era que un bloque prevaleciera sobre el otro:

# POTENCIALMENTE PROBLEMÁTICO — dos bloques separados para el mismo user-agent
User-agent: *
Disallow: /admin/

User-agent: *
Disallow: /login/
# Google combinará las reglas de ambos bloques en uno solo

La forma correcta es agrupar todas las directivas del mismo User-agent en un único bloque:

# CORRECTO — un solo bloque por User-agent
User-agent: *
Disallow: /admin/
Disallow: /login/
Disallow: /carrito/

Error #4 — Wildcard mal aplicado que bloquea páginas que quieres indexar

Los wildcards (* y $) son potentes pero requieren precisión. Un patrón mal escrito puede bloquear docenas o cientos de URLs que querías mantener accesibles para Googlebot.

El wildcard * en una ruta coincide con cualquier secuencia de caracteres en esa posición. El problema surge cuando el patrón es demasiado genérico:

# INCORRECTO — bloquea TODAS las URLs que contengan "?", incluyendo páginas de producto válidas
User-agent: *
Disallow: /*?

# Esto bloquea:
# /producto/camisa-azul?color=azul
# /blog/articulo?utm_source=newsletter
# /servicios?tab=precios   ← página importante que querías indexar

Si el objetivo es bloquear páginas de filtros dinámicos pero permitir las URLs base de producto, la directiva necesita ser más específica:

# MEJOR — bloquea solo parámetros de filtro específicos
User-agent: *
Disallow: /*?orderby=
Disallow: /*?filter_color=
Disallow: /*?paged=

El wildcard $ indica el final de la URL. Útil para bloquear archivos con extensiones específicas sin bloquear rutas que empiecen igual:

# CORRECTO — bloquea archivos .pdf pero no la sección /documentos/
User-agent: *
Disallow: /*.pdf$

Sin el $, Disallow: /*.pdf bloquearía también una URL hipotética como /documentos/pdf-guides/ si el crawler la interpreta literalmente. Con el $, solo bloquea URLs que terminan exactamente en .pdf.

Un error especialmente costoso en ecommerce: bloquear páginas de paginación con un patrón demasiado amplio:

# INCORRECTO — bloquea páginas de categoría con paginación (/categoria/page/2/)
User-agent: *
Disallow: /*/page/

# Si tu sitio tiene URLs como /servicios/page/2/, /blog/page/3/,
# estas también quedan bloqueadas aunque quieras indexarlas

Antes de añadir cualquier directiva con wildcard, usa la Inspección de URLs en Google Search Console para probar el patrón contra URLs reales de tu sitio. La herramienta muestra exactamente qué URLs quedan bloqueadas y cuáles siguen accesibles.

Error #5 — Conflicto entre robots.txt y meta robots: ¿quién gana?

Este es el error conceptual más común: asumir que robots.txt y la etiqueta meta robots funcionan de la misma manera o que se complementan de forma intuitiva. La realidad es más compleja y puede producir resultados inesperados.

Regla fundamental: si una URL está bloqueada en robots.txt, Google no puede rastrearla. Si no puede rastrearla, no puede leer las etiquetas meta que contiene. Esto incluye la etiqueta <meta name="robots" content="noindex">.

El escenario más problemático:

# En robots.txt:
User-agent: *
Disallow: /landing-pages/

# En /landing-pages/oferta-especial/:
<meta name="robots" content="noindex, follow">

El objetivo visible es desindexar la landing page. El resultado real: Google no puede acceder a la página para leer el noindex, así que puede mantenerla en el índice indefinidamente si tenía enlaces entrantes que la habían indexado previamente.

La regla de precedencia es la opuesta a lo que muchos esperan:

• Para impedir el rastreo: usa robots.txt Disallow. El noindex en la página es irrelevante si Google no puede rastrear la URL.
• Para impedir la indexación de una página rastreable: usa <meta name="robots" content="noindex"> (o el encabezado HTTP X-Robots-Tag: noindex). El robots.txt debe permitir el acceso para que Google pueda leer esta directiva.
• Para eliminar del índice una página que ya está indexada: quita el bloqueo del robots.txt, añade noindex en la página, y espera a que Google la rastree y procese la directiva.

Gary Illyes de Google resumió este conflicto con claridad en una conferencia de Google Search Central: “Una página bloqueada por robots.txt no es lo mismo que una página noindexada. Si quieres asegurarte de que algo no aparezca en los resultados, no confundas ambos mecanismos.”

La combinación correcta depende del objetivo:

Cómo auditar tu robots.txt con Google Search Console

Google Search Console incluye dos herramientas para verificar el robots.txt:

1. Informe de robots.txt (Configuración → Robots.txt): muestra el robots.txt en caché que Googlebot utiliza actualmente, cuándo se rastreó por última vez y si hubo errores de fetch.

2. Inspección de URLs: permite probar una URL concreta y verificar si está bloqueada por robots.txt, qué regla aplica y el estado de indexación.

Para una auditoría más completa del robots.txt, Screaming Frog SEO Spider tiene una función específica que rastrea el sitio simulando el comportamiento de Googlebot y muestra qué páginas quedan fuera del rastreo por las directivas actuales. El informe “Blocked by Robots.txt” en la pestaña de Respuesta muestra todas las URLs afectadas.

Pasos para una auditoría básica:

1. Abre https://tudominio.com/robots.txt directamente en el navegador y revisa las directivas una por una.
2. En Google Search Console, usa la Inspección de URLs para verificar que las 10-20 páginas más importantes de tu sitio no están bloqueadas por robots.txt.
3. Revisa el informe de Cobertura en Search Console y filtra por “Excluida: bloqueada por robots.txt” para ver si hay URLs que no deberían estar bloqueadas.
4. Si usas Screaming Frog, rastrea el sitio y revisa el informe “Blocked by Robots.txt”.

Un robots.txt bien configurado es uno de los fundamentos del crawl budget y de la indexación correcta del sitio. Si las páginas críticas no llegan a Googlebot, ninguna otra optimización SEO tiene oportunidad de funcionar.

Para profundizar en la relación entre el robots.txt, los sitemaps y la estrategia de indexación, el artículo sobre sitemaps XML y guía de indexación desarrolla cómo coordinar ambos mecanismos para maximizar la visibilidad en Google.