robots.txt: qué controla de verdad y el error que garantiza lo contrario

Es el archivo más pequeño del SEO técnico y el que más daño hace mal configurado, porque casi todo el mundo cree que sirve para lo que no sirve. robots.txt no saca páginas de Google: impide que se lean. Y una página que no se puede leer tampoco puede mostrar la etiqueta que pediría su retirada, así que bloquear una URL para que desaparezca es la forma más eficaz de dejarla dentro, listada y sin descripción, indefinidamente.

Respuesta rápida

• Controla el rastreo, no la indexación. Son dos cosas distintas y la confusión cuesta cara.
• Bloquear más noindex se anulan entre sí, y gana el bloqueo: la página se queda.
• Un Disallow: / heredado del montaje es la causa número uno de que un sitio nuevo no aparezca.
• Los rastreadores de IA son otra decisión, y hoy es la parte que falta en casi todas las guías.

¿Para qué sirve el archivo robots.txt?

Sirve para indicar a los rastreadores qué partes del sitio no deben recorrer, y solo eso. No retira páginas del índice ni protege contenido privado: una URL bloqueada puede seguir apareciendo en los resultados, sin descripción, porque Google sabe que existe aunque no haya podido leerla.

Qué tipo de archivo es esto

El modelo mental equivocado es pensarlo como una lista de permisos, tipo control de acceso. Bajo esa idea, poner algo en robots.txt lo esconde.

No esconde nada. Es un archivo público, cualquiera puede leer el tuyo escribiendo la ruta en el navegador, y lo que contiene es una petición que los rastreadores serios respetan y los que no lo son ignoran. Bloquear una carpeta ahí es, además, publicar que esa carpeta existe.

De ahí las dos consecuencias que ordenan todo lo demás. Para lo privado hace falta autenticación, no una línea en un archivo. Y para lo que no debe salir en Google hace falta una etiqueta que Google pueda leer, lo que exige justo lo contrario de bloquear.

El error que se comete con mejor intención

Alguien quiere que una página deje de salir en Google. Le pone noindex y, para reforzar, la bloquea también en robots.txt.

El resultado es el opuesto al buscado. El bloqueo impide el rastreo, el rastreo era la única forma de ver el noindex, y la etiqueta nunca se aplica. La URL se queda en el índice, ahora además sin descripción porque no se puede leer su contenido, y en ese estado puede permanecer mucho tiempo.

El orden correcto es al revés: para retirar una página se permite el rastreo y se sirve noindex, o se devuelve un 404 o un 410. Cuando ya desapareció, entonces se puede bloquear si molesta que se rastree.

Es el mismo mecanismo que explica varios estados confusos del informe de páginas de Search Console, desarrollados en por qué Google no indexa tu página.

Lo mínimo que debe tener, y lo que sobra

Un robots.txt correcto de un sitio pequeño cabe en cuatro líneas:

User-agent: *
Allow: /

Sitemap: https://tudominio.com/sitemap.xml

El sitemap declarado ahí ayuda al descubrimiento y cuesta una línea.

Lo que sí conviene bloquear: zonas que generan URLs infinitas, como buscadores internos con parámetros, o áreas de administración que no aportan nada al rastreo.

Lo que no hay que bloquear nunca: el CSS y el JavaScript que la página necesita para renderizarse. Google necesita renderizar para entender el contenido, y bloquearle los recursos le deja una versión rota del sitio. Era una práctica común hace diez años y sigue viva en plantillas antiguas.

Y lo que casi nadie revisa: que el archivo del entorno de pruebas no viajó a producción. Un Disallow: / es una línea, se pone para que no se indexe el staging y se despliega con todo lo demás.

Esa comprobación es el punto cero de cualquier revisión y por eso encabeza la checklist de SEO: todo lo que va debajo es nulo si la respuesta es que Google no puede leer el sitio.

Los rastreadores de IA, que es lo que falta en las guías viejas

Aquí hay una decisión nueva y son tres, no una, porque los bots hacen cosas distintas.

Rastreadores de citas. OAI-SearchBot de OpenAI indexa páginas para poder citarlas en las respuestas. Bloquearlo te saca del conjunto del que salen las citas.

Rastreadores de entrenamiento. GPTBot recoge datos para entrenar modelos. Bloquearlo no afecta a las citas.

Rastreadores a petición del usuario. ChatGPT-User va a buscar una página que alguien pegó expresamente. Bloquearlo hace que tu enlace no se pueda leer cuando un usuario lo comparte.

Confundirlos es lo habitual, y la consecuencia cara es bloquear los tres en la oleada de 2023 y no volver a mirarlo, quedándose fuera de las citas sin haberlo decidido. Cuál es cuál y qué implica cada uno está en cómo aparecer en las respuestas de ChatGPT.

Cuándo no tocar este archivo

Cuando no sabes qué hace una línea que ya está. Un robots.txt heredado se audita antes de editarse, porque quitar un bloqueo puede exponer zonas que se bloquearon por un motivo.

Cuando el objetivo es privacidad. Ahí la herramienta es la autenticación, y el archivo solo publicaría dónde mirar.

Cuando quieres retirar una página. Es el caso del error de arriba y va al revés.

Cuando el sitio es pequeño y no tiene zonas problemáticas. Las cuatro líneas de la plantilla bastan, y cada regla añadida es una oportunidad de bloquear algo por accidente.

Las dos reglas de precedencia que ninguna de estas guías explica

Los primeros resultados en español para esta consulta enseñan lo mismo: User-agent, Disallow, Allow y los comodines * y $. Está bien y no alcanza, porque un archivo con dos reglas se entiende solo y ninguno explica qué pasa cuando son diez. Ahí gobiernan dos reglas de precedencia que Google documenta y que casi nadie conoce.

Un rastreador obedece a UN SOLO grupo, el más específico que le nombre. Si tu archivo tiene un bloque User-agent: * y añades otro User-agent: Googlebot con una sola línea dentro, Googlebot deja de leer el primero entero. No se suman. Todas tus reglas generales dejan de aplicarle en el momento en que le dedicas una.

Es el error más caro de este archivo y no produce ningún síntoma: nadie recibe un aviso, nada falla, ninguna auditoría de las que leen HTML puede verlo porque no está en el HTML, y meses después aparecen rastreadas las carpetas que creías bloqueadas. Quien añade una línea para Googlebot casi siempre quiere añadirla a lo que ya había, y para eso hay que repetir el bloque entero dentro del nuevo grupo.

Y dentro de un grupo no gana la primera regla, gana la más específica, medida por longitud de la ruta. Con Disallow: /blog/ y Allow: /blog/publico/, la segunda gana para esa carpeta porque es más larga, y da igual en qué orden estén escritas. Si dos reglas empatan en longitud, gana la menos restrictiva, que es Allow.

De ahí sale la comprobación que ahorra el susto y que no aparece en ninguna de esas guías: este archivo no se lee, se prueba. El probador de robots.txt de Search Console dice, para una URL concreta y un rastreador concreto, qué regla gana. Leer el archivo y creer que lo entiendes es justo lo que produce el fallo de arriba.

Conviene además saber lo que este archivo no puede hacer, porque varias de esas páginas se titulan cómo ocultar partes de tu web: ocultar no es una de sus funciones, y el desarrollo de por qué está más arriba. Un archivo público que enumera lo que no quieres que se vea es, además, un índice de lo interesante para quien vaya buscando.

Y hay una pieza que sí conviene declarar aquí y que la mitad de esas guías omite: la ruta del sitemap. Es la única línea del archivo que añade algo en vez de quitarlo, y es gratis.

Errores que se repiten

• Bloquear una página para que salga del índice. Garantiza que se quede.
• Disallow: / heredado del entorno de pruebas. Una línea, sitio entero fuera.
• Bloquear CSS y JavaScript. Google renderiza, y sin recursos ve una página rota.
• Usarlo como control de acceso. Es público y solo señala dónde está lo que escondes.
• Bloquear los tres bots de OpenAI a la vez. Entrenamiento y citas son decisiones distintas.
• Editarlo sin auditar lo que ya había. Quitar un bloqueo puede exponer lo que protegía.

Datos y transparencia

Que un rastreador obedece a un solo grupo de User-agent, el más específico que lo nombre, y que dentro de un grupo gana la regla de ruta más larga con el empate resuelto a favor de Allow, procede de la documentación de robots.txt de Google, comprobada el 12 de agosto de 2026. Que los primeros resultados en español para esta consulta explican User-agent, Disallow, Allow y los comodines sin mencionar ninguna de las dos reglas de precedencia, y que varios se titulan «cómo ocultar partes de tu web», es una observación del mismo día y se recoge como carencia, no como fuente.

Que robots.txt controla el rastreo y no la indexación, que una URL bloqueada puede aparecer en los resultados sin descripción, y que una página bloqueada no puede mostrar una directiva noindex porque esta no llega a leerse, procede de la documentación pública de Google sobre robots.txt y sobre bloqueo de indexación, vigente a agosto de 2026. Los nombres y la función declarada de OAI-SearchBot, GPTBot y ChatGPT-User están documentados públicamente por OpenAI. No aparece aquí ninguna cifra sobre cuántos sitios tienen el archivo mal configurado: no la he medido y las que circulan proceden de rastreos cuya muestra no se declara. El orden de frecuencia de los errores es juicio operativo de trabajo de auditoría sobre una cartera que registra más de 300 millones de impresiones anuales en Search Console. Verificado en agosto de 2026.

Lo que esto cambia

Este archivo concentra una cantidad de daño desproporcionada a su tamaño, y la razón es que su nombre promete otra cosa.

"Robots" y "disallow" suenan a permiso denegado, y lo que hacen es pedir que no se pase, en un cartel que además está a la vista de todos. Cada vez que alguien lo usa esperando que oculte, proteja o retire algo, obtiene lo contrario de lo que quería y no se entera durante meses, porque los efectos de este archivo son todos silenciosos. Cuatro líneas y una lectura anual son más rentables aquí que cualquier optimización que se pueda enseñar en una diapositiva.

Preguntas frecuentes