Robots.txt: qué es, cómo se escribe y qué errores evitar

El robots.txt es un archivo de texto que vive en la raíz de tu web y les dice a los robots de los buscadores por dónde pueden pasar y por dónde no. Sirve para ordenar el rastreo, no para esconder páginas: si quieres que una página no salga en Google, el robots.txt es la herramienta equivocada. Esta guía explica cómo se escribe bien, los errores más habituales y cómo comprobar el tuyo.

01Qué es el robots.txt y para qué sirve

El robots.txt es la lista de normas de paso que lee un rastreador antes de recorrer tu web. Google lo resume así: se usa sobre todo para no saturar tu sitio con peticiones y para que los robots no pierdan el tiempo en páginas sin importancia o casi duplicadas.

Funciona por acuerdo, no por fuerza. El estándar que lo regula, el RFC 9309 (publicado por el IETF en septiembre de 2022), dice expresamente que sus reglas no son una forma de autorizar el acceso y que no sustituyen a las medidas de seguridad. Googlebot y Bingbot lo respetan; un robot malicioso, no.

Para una pyme, el uso sensato es corto:

• Evitar que los robots se pierdan en búsquedas internas, filtros, carritos o parámetros que generan miles de direcciones inútiles.
• Señalar dónde está tu sitemap.
• Decidir qué robots de IA pueden leer tu web, si te importa ese tema (lo tratamos aparte en ClaudeBot, Claude-SearchBot y Claude-User: qué bloquear).

02Qué no hace el robots.txt

El robots.txt no saca páginas de Google. Si bloqueas una dirección, Google no la lee, pero su URL puede seguir apareciendo en los resultados, sin descripción, si otras webs la enlazan.

Es el error de concepto que más caro sale. Con imágenes, vídeos y audio el caso cambia: ahí Google sí admite el robots.txt para que no aparezcan en sus resultados, pero no con páginas. Para que una página no salga en el buscador hay que usar la etiqueta o la cabecera noindex, una contraseña o borrarla. Y ojo con mezclar las dos cosas: si bloqueas en el robots.txt una página que lleva noindex, el rastreador nunca verá el noindex y la página puede seguir apareciendo.

Tampoco es un escudo para zonas privadas. El archivo es público: cualquiera puede abrir tudominio.com/robots.txt y leer la lista de carpetas que prefieres que no se vean. Si pones ahí /panel-clientes-2026/, acabas de anunciarlo.

03Cómo se escribe un robots.txt correcto

Un robots.txt correcto tiene grupos: cada grupo empieza por una o varias líneas User-agent (a qué robot se dirige) y sigue con reglas Disallow (no pases) y Allow (sí puedes pasar). Al final, fuera de los grupos, conviene poner la dirección completa del sitemap.

Un ejemplo razonable para una tienda online:

User-agent: *
Disallow: /carrito/
Disallow: /mi-cuenta/
Disallow: /*?orderby=
Disallow: /*&orderby=
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-admin/

Sitemap: https://www.ejemplo.es/sitemap.xml

Las dos reglas de orderby cubren el parámetro tanto si va el primero (?orderby=) como si va detrás de otro (&orderby=). Lo que conviene saber de la sintaxis, según la especificación de Google:

El punto de los grupos es el que más sorprende. Si escribes reglas generales en User-agent: * y luego abres un grupo aparte para Googlebot con una sola línea, Googlebot solo obedece esa línea. Tienes que repetir en su grupo todo lo que quieras que cumpla.

04Errores típicos, con ejemplo

Los errores que hacen daño de verdad son pocos y se repiten. Estos son los que más conviene revisar.

1. El Disallow: / que se quedó de la fase de desarrollo. Es el clásico tras estrenar web: el entorno de pruebas bloqueaba todo y el archivo pasó tal cual a producción.

User-agent: *
Disallow: /

Esas dos líneas piden a todos los robots que no rastreen nada. Si tu web nueva no aparece en Google semanas después del lanzamiento, mira esto lo primero.

2. Bloquear CSS, JavaScript o imágenes que la página necesita. Google necesita esos archivos para entender cómo se ve la página. Si no puede descargarlos, no podrá analizar bien las páginas que dependen de ellos. Reglas como Disallow: /assets/ o Disallow: /*.js$ suelen sobrar.

3. Usar el robots.txt para desindexar. Ya lo hemos visto: si la página está en Google y la bloqueas, no desaparece; solo pierde la descripción. Primero noindex, esperar a que Google la vuelva a leer y la retire, y solo después, si quieres, bloquearla.

4. Una barra de menos. Disallow: /blog bloquea también /blog-antiguo/ y /blogueros.html, porque compara el principio de la ruta. Si solo quieres la carpeta, escribe Disallow: /blog/.

5. Directivas que Google no entiende. Crawl-delay y Noindex dentro del robots.txt no los admite Google: solo reconoce user-agent, allow, disallow y sitemap. Bing sí ha documentado su soporte de Crawl-delay, así que esa línea solo afecta a quien la entiende.

6. Un servidor que responde con error. Esto es menos conocido y más grave. Si el archivo devuelve un 404 u otro error 4xx (salvo el 429), Google actúa como si no hubiera restricciones. Pero si devuelve un error 5xx o no responde (los fallos de DNS y los tiempos de espera cuentan igual), durante las primeras 12 horas deja de rastrear tu web; después usa la última copia buena durante un máximo de 30 días o, si no tiene copia, asume que no hay restricciones. Pasados esos 30 días, si el resto del sitio responde, actúa como si no hubiera robots.txt; si no responde, deja de rastrearlo. Un cortafuegos o un plugin de seguridad que bloquea la petición del robots.txt puede frenar el rastreo de todo el sitio.

05Cuánto tarda Google en ver un cambio

Google suele guardar en caché el archivo hasta 24 horas, así que un cambio no tiene efecto inmediato. Puede tardar más si el servidor falla al servirlo, y Google puede alargar o acortar ese plazo según la cabecera Cache-Control: max-age.

Si has arreglado algo urgente, por ejemplo quitar un Disallow: / olvidado, el informe de robots.txt de Search Console te enseña la última vez que Google lo leyó, el estado de la descarga y los problemas que encontró al interpretarlo. Desde ahí puedes pedir que lo vuelva a leer. Google avisa de que esa petición no garantiza que las páginas desbloqueadas se rastreen enseguida.

06Cómo comprobar tu robots.txt

Comprobar un robots.txt es leer qué responde el servidor y probar direcciones concretas contra sus reglas. Leerlo a ojo no basta: las reglas de grupos y de ruta más larga engañan, y el código de respuesta del servidor no se ve abriendo el archivo en el navegador.

Nuestra recomendación es revisarlo en tres pasos:

1. Que responda con un 200 y texto plano en la raíz de cada host que uses (con y sin www, y cada subdominio que deba salir en Google).
2. Que no bloquee nada que quieras ver en Google: portada, categorías, fichas de producto, artículos y los archivos CSS y JavaScript que los pintan.
3. Que cada dirección que sí quieres bloquear quede bloqueada para el robot que toca.

En Seotres, el Comprobador de robots.txt descarga el archivo como lo haría un robot, te dice qué código ha devuelto el servidor y explica cada línea. Su límite: lee el archivo y sus reglas, pero no sabe qué páginas son importantes para tu negocio; esa decisión es tuya. Para el tercer paso, el Probador de robots.txt te dice si un robot concreto, o todos los de la lista, puede entrar en una dirección según las reglas escritas; no garantiza que ese robot las cumpla ni que Google ya haya leído tu versión nueva.

07Comprobar arreglos

Después de corregir el robots.txt, vuelve a pasar la comprobación para confirmar que lo que salía ya no sale. Es un paso corto que evita sustos: una caché del servidor, un plugin que reescribe el archivo o un despliegue que vuelve a subir la versión antigua pueden deshacer tu cambio sin que te enteres.

Con Comprobar arreglos, Seotres vuelve a mirar las páginas donde tenías tareas pendientes y marca como arreglado lo que ya no aparece. Mira tu web, no el índice de Google: que el arreglo esté bien no significa que Google lo haya recogido ya.