El robots.txt es uno de los archivos más pequeños de una web y uno de los que más daño hace cuando se toca sin cuidado: una sola línea mal puesta puede dejar la web entera de un despacho fuera del rastreo de Google. Pasa sobre todo al lanzar un sitio nuevo o al migrarlo de servidor, cuando el fichero de pruebas se cuela en producción sin que nadie lo revise. Quien gestiona el blog del despacho —o a quien se lo encarga— tiene que saber leer ese archivo y distinguirlo de otro mecanismo con el que se confunde constantemente: el noindex.
Si el robots.txt de una web incluye una línea «Disallow: /», Google deja de rastrear todas sus páginas, pero no necesariamente las retira del índice: si otra web enlaza a ellas, pueden seguir apareciendo en los resultados sin título ni descripción. La única forma fiable de sacar una página de Google es con una etiqueta noindex, que exige justo lo contrario: permitir el rastreo para que el robot la lea.
Qué controla realmente el robots.txt
El robots.txt es un archivo de texto plano que vive en la raíz del dominio, en tudominio.com/robots.txt, y que cualquiera puede abrir escribiendo esa dirección en el navegador. Indica qué rutas puede recorrer un rastreador y cuáles tiene prohibido visitar. Es una norma de tráfico, no una cerradura: la propia documentación de Google advierte que ese archivo sirve para gestionar la carga de los rastreadores, no para mantener una página fuera de los resultados de búsqueda.
Por eso sorprende a quien no lo ha visto antes: una página bloqueada en robots.txt puede seguir apareciendo en el buscador si otra web enlaza a ella, solo que sin título ni descripción debajo, porque el rastreador nunca llegó a leer su contenido para generarlos.
Disallow no saca páginas de Google
El caso que más despachos descubre tarde es el estado «indexada, aunque bloqueada por robots.txt» de Search Console: la URL figura en el índice con ese aviso, pero sin fragmento de texto debajo, porque Google la conoce por los enlaces que recibe y no por haberla rastreado. Pasa típicamente con páginas de aviso legal o de política de privacidad que el propio pie de la web enlaza, mientras el robots.txt las bloquea por error desde una limpieza de rutas antigua.
La solución no es añadir más líneas de Disallow: hay que retirar el bloqueo y, si conviene excluir la página, añadirle noindex en el HTML. Combinar las dos reglas sobre la misma URL la deja indexada para siempre, porque el rastreador nunca llega a leer la instrucción que la sacaría.
El noindex, la etiqueta que sí excluye
La etiqueta robots con el valor noindex va en el encabezado de cada página, no en el robots.txt del dominio, y hace justo lo que muchos despachos esperan del archivo equivocado: le dice a Google que, aunque rastree la página, no la guarde en su índice ni la muestre en resultados. La especificación de Google sobre las etiquetas robots es clara en el requisito que más se pasa por alto: para que el rastreador la vea, la página tiene que estar permitida en el robots.txt. Si está bloqueada, la etiqueta existe en el código pero nadie llega a leerla.
Google dejó además de admitir una vía que durante años circuló como atajo: escribir «noindex» directamente como regla dentro del robots.txt, igual que un Disallow. Nunca fue una directiva oficial del protocolo de exclusión de robots, y Google retiró el soporte para ese tipo de reglas no documentadas el 1 de septiembre de 2019. Cualquier plantilla o tutorial antiguo que todavía la recomiende describe un comportamiento que Google ya no ejecuta.
Migrar la web multiplica el riesgo de bloqueo
La mayoría de robots.txt problemáticos no los escribe nadie a propósito: los deja el propio proceso de trabajo. Las agencias construyen la web nueva en un dominio de pruebas y, para que Google no la indexe a medio terminar, le añaden un robots.txt con «Disallow: /». El problema llega cuando nadie borra esa línea al trasladar la web al dominio definitivo: sale a producción con el candado de pruebas puesto.
El fallo no da ningún error visible: la web funciona y se ve bien, y nadie revisa un archivo que casi no se toca. Se descubre semanas después, cuando el tráfico orgánico no arranca. Conviene revisar cómo hacer un rediseño sin perder posicionamiento antes de migrar, y tenerlo presente al renovar la web del despacho: el robots.txt de pruebas es de los descuidos más repetidos en ambos procesos.
La casilla de WordPress no es suficiente
WordPress tiene en Ajustes → Lectura una casilla que promete justo esto: «Pide a los motores de búsqueda que no indexen este sitio». Hasta la versión 5.3, activarla escribía un «Disallow: /» en el robots.txt virtual. Desde esa versión, el equipo de WordPress cambió el mecanismo: ahora añade la etiqueta noindex en cada página, en lugar de tocar el robots.txt.
La confusión práctica es la contraria a la que resolvía ese cambio: muchos despachos desmarcan la casilla pensando que con eso basta, sin comprobar si además existe un robots.txt físico —del hosting o de un plugin de seguridad— que sigue bloqueando el rastreo por su cuenta. Son dos mecanismos independientes y conviene revisar los dos.
Revisar el robots.txt antes de publicar cambios
Comprobar el robots.txt lleva menos de un minuto y evita semanas de tráfico perdido. Basta con escribir la dirección del dominio seguida de «/robots.txt» en el navegador, o ejecutar el comando curl sobre esa misma dirección desde una terminal, y leer el resultado línea a línea. Antes de dar por buena cualquier publicación o migración conviene mirar lo siguiente:
- Que no exista una línea «Disallow: /» suelta, que bloquea el dominio entero.
- Que no estén bloqueadas las carpetas de las que depende el diseño, como la de imágenes o los directorios de hojas de estilo y scripts: Google necesita leerlas para entender cómo se ve la página.
- Que la línea «Sitemap:» apunte al mapa del sitio real, no al de la web de pruebas.
- Que, si hay varias reglas para el mismo rastreador, no se contradigan entre sí, porque la más restrictiva suele imponerse.
La herramienta de inspección de URLs de Search Console confirma el diagnóstico sin dejarlo a la interpretación: muestra si Google pudo rastrear esa página en concreto y, si no pudo, señala el robots.txt como motivo exacto. Es el primer sitio al que mirar cuando una pieza nueva del blog tarda más de lo normal en aparecer en resultados.
Con páginas ya indexadas, el orden del arreglo importa
Si el robots.txt ya lleva tiempo bloqueando páginas que ahora aparecen en Google sin descripción, el orden de los pasos importa. Primero hay que quitar el bloqueo del robots.txt para permitir el rastreo; solo entonces tiene sentido añadir la etiqueta noindex en las páginas que de verdad no deben indexarse, porque es la única forma de que Google llegue a leerla. Hacerlo al revés deja la etiqueta escrita en el código sin que ningún rastreador pase nunca a leerla.
La retirada del índice no es instantánea: Google tiene que volver a rastrear cada URL para procesar la nueva etiqueta, y eso depende de la frecuencia con la que ya visita esa web. En un blog jurídico con publicación diaria, el propio ritmo de rastreo suele bastar en pocos días; en una web casi estática puede tardar semanas. El informe de indexación de páginas de Search Console ayuda a seguir el proceso sin esperar a comprobarlo artículo por artículo.
Preguntas frecuentes sobre robots.txt
¿Dónde está el robots.txt de mi web?
En la raíz del dominio, en la dirección tudominio.com/robots.txt. Si al escribirla aparece un error, es que no existe ningún archivo físico y WordPress está sirviendo uno virtual por defecto, que solo bloquea rutas internas como la del panel de administración.
¿Puedo editar el robots.txt sin tocar código?
Sí. Plugins de SEO como Yoast o Rank Math añaden un editor de robots.txt dentro del propio panel de WordPress, sin necesidad de acceder por FTP. Cualquier cambio conviene probarlo después con la herramienta de inspección de URLs de Search Console antes de darlo por bueno.
¿Un robots.txt mal hecho afecta al posicionamiento?
Sí, y de forma más grave que una simple bajada de posiciones: la página bloqueada no entra siquiera en la competencia por esa palabra clave. Por bien escrita que esté, si Google no puede rastrearla no la evalúa, así que el problema no es posicionar peor sino no posicionar mientras dure el bloqueo.