Cómo revisar tu robots.txt (y la línea que desindexa un sitio)

Para revisar tu robots.txt, abre https://tusitio.com/robots.txt en el navegador, lee cada grupo User-agent y busca cualquier regla Disallow que cubra páginas que quieres en el buscador, empezando por un Disallow: / a secas. En un sitio pequeño es cosa de un minuto. Después confirma en el informe de robots.txt de Search Console qué archivo descargó Google realmente, porque el que ves tú y el que recibió Googlebot no siempre coinciden.

La mayoría de los archivos robots.txt tienen unas pocas líneas, y por eso casi nadie los lee. Además se aplican a todo el host, así que una sola línea equivocada afecta a todas sus URLs.

Rastreo, no indexación

El robots.txt indica a los rastreadores qué URLs pueden solicitar. No decide qué aparece en los resultados de búsqueda. Una URL bloqueada en robots.txt puede indexarse igualmente si otras páginas la enlazan; Google la muestra sin descripción y Search Console la clasifica como "Indexada, aunque bloqueada por robots.txt".

Esto importa cuando se usa el robots.txt para esconder páginas. Si bloqueas una página y además le pones noindex, Google no puede rastrearla, nunca ve el noindex y la URL puede seguir en el índice. Para sacar una página de los resultados, déjala rastreable y sirve un noindex. En la etiqueta noindex, explicada tienes esa otra parte.

Dónde encontrar el archivo

El robots.txt siempre está en la raíz del host, por ejemplo https://example.com/robots.txt. Sus reglas solo se aplican al protocolo, host y puerto desde los que se sirve, así que https://shop.example.com necesita su propio archivo.

En muchas plataformas no hay un archivo físico que abrir. WordPress genera un robots.txt virtual salvo que subas uno real a la raíz de la web, y plugins SEO como Yoast y Rank Math permiten editarlo desde el panel de administración. Shopify sirve un archivo por defecto que puedes personalizar añadiendo una plantilla robots.txt.liquid al tema. Si entras por FTP y no encuentras el archivo, casi siempre es por esto.

Cómo leer el robots.txt línea a línea

Un robots.txt se compone de grupos. Cada grupo empieza con una o varias líneas User-agent seguidas de sus reglas:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /*?s=
Disallow: /cart/

User-agent: GPTBot
Disallow: /

Sitemap: https://example.com/sitemap_index.xml

Leído de arriba abajo, este ejemplo impide a todos los rastreadores entrar en /wp-admin/, salvo en admin-ajax.php, y también en los resultados de la búsqueda interna (?s=) y en el carrito. GPTBot tiene su propio grupo y está bloqueado en todo el sitio. La línea Sitemap no pertenece a ningún grupo y vale para todo el archivo.

Unas cuantas reglas de interpretación explican la mayoría de las sorpresas. Un rastreador solo obedece el grupo más específico que coincide con su nombre. Aquí Googlebot no encuentra un grupo User-agent: Googlebot, así que usa el de *; si existiera un grupo para Googlebot, ignoraría por completo las reglas de * en lugar de combinarlas. Las rutas distinguen mayúsculas y minúsculas, de modo que /Blog/ y /blog/ son reglas distintas. El * equivale a cualquier secuencia de caracteres y el $ marca el final de la URL, por lo que Disallow: /*.pdf$ bloquea los PDF y nada más. Cuando un Allow y un Disallow coinciden con la misma URL, Google sigue el más largo, es decir, el más específico. Un Disallow: vacío no bloquea nada.

Google ignora las líneas Crawl-delay y Noindex del robots.txt. Bing sí respeta Crawl-delay.

Las dos líneas que bloquean un sitio entero

User-agent: *
Disallow: /

Esto pide a todos los rastreadores que no accedan a ninguna URL. Es la configuración normal de un entorno de staging o desarrollo, y justo por eso acaba en sitios en producción: un despliegue copia el archivo de staging o una migración se trae toda la configuración. WordPress tiene una trampa parecida. Si marcas "Disuadir a los motores de búsqueda de indexar este sitio" en Ajustes > Lectura, las versiones actuales añaden una meta etiqueta robots noindex a todas las páginas, así que después de un lanzamiento conviene revisar tanto el archivo como el código fuente de la página.

Los visitantes no notan nada cuando pasa. Las páginas cargan, los formularios se envían y los controles de uptime siguen en verde. El rastreo se frena y, en las semanas siguientes, las páginas van cayendo de los resultados.

Comprobaciones para revisar tu robots.txt

1. Abre /robots.txt directamente y mira el código de estado HTTP además del contenido. La pestaña Network de Chrome DevTools lo muestra. Lo que quieres ver es un 200 y las reglas que esperas.
2. Busca en el archivo un Disallow: / solo, y reglas sobre carpetas que contienen páginas que quieres posicionar, como /blog/, /products/ o /category/.
3. Comprueba que la línea Sitemap: apunta a un sitemap que carga y que es el actual, no un resto de un plugin anterior.
4. En Search Console, abre Ajustes > robots.txt. El informe muestra los archivos robots.txt que Google ha encontrado para los hosts principales de la propiedad, cuándo se rastreó cada uno por última vez, el estado de la descarga y las líneas que no pudo interpretar. Si has corregido un problema urgente, desde ahí puedes solicitar un nuevo rastreo.
5. Para una URL concreta, usa la Inspección de URLs. Si está bloqueada, la sección de indexación de la página indica "Bloqueada por robots.txt".
6. En un sitio más grande, pasa un rastreador como Screaming Frog en su modo por defecto, que respeta el robots.txt, y revisa las URLs que marca como bloqueadas.

Google retiró el antiguo Probador de robots.txt en 2023, así que las guías que te mandan allí están desactualizadas.

El código de estado importa tanto como las reglas. Google trata un 404, o cualquier otro 4xx salvo el 429, como si no existiera robots.txt, es decir, todo puede rastrearse. Un 5xx se gestiona de otra manera: Google deja de rastrear durante un tiempo y después recurre a una copia en caché mientras sigue reintentando. Google además guarda el archivo en caché hasta 24 horas y solo lee los primeros 500 KiB, así que en un archivo inusualmente largo se ignoran las reglas que queden más allá.

Saber cuándo cambia el archivo

Todas las comprobaciones anteriores te dicen lo que pone el robots.txt hoy. Ninguna te dice que un plugin lo reescribió el martes o que un cambio de hosting restauró una versión antigua. En un solo sitio puedes volver a abrirlo después de cada publicación. En una cartera de clientes donde los desarrolladores despliegan sin avisar, no lo harás, y la primera señal de una edición mala suele ser una caída del rastreo en Search Console semanas después. La guía sobre alertas de cambios en robots.txt repasa qué ediciones merecen una alerta.

Deltio descarga el robots.txt de cada sitio de cliente dentro de su revisión diaria, lo compara con la versión anterior y envía una alerta por Slack o email para ese sitio cuando ha cambiado. En la misma pasada revisa el noindex, los canonical y las URLs del sitemap, porque un despliegue de staging suele romper varias de esas cosas a la vez. Funciona una vez al día, así que una edición se notifica ese mismo día o el siguiente, no a los pocos minutos. En alertas de cambios SEO se explica el alcance de esas alertas, y hay una prueba gratuita de 14 días si quieres añadir un sitio.