El archivo robots.txt parece una de las partes más sencillas del SEO técnico.
Es un pequeño archivo de texto.
Puede contener solamente unas pocas líneas.
Y precisamente por eso es fácil pensar:
Aquí no puedo romper demasiadas cosas.
En realidad, una configuración incorrecta puede impedir que Google rastree partes importantes de nuestra web.
También existe el problema contrario: utilizar robots.txt intentando solucionar problemas para los que no fue diseñado.
En esta guía veremos qué es robots.txt, cómo funciona, cuándo utilizarlo y cuáles son los errores que evitaría.
¿Qué es robots.txt?
robots.txt es un archivo que proporciona instrucciones a los rastreadores sobre qué partes de un sitio pueden rastrear.
Normalmente podemos encontrarlo en la raíz del dominio:
dominio.com/robots.txt
Antes de rastrear el sitio, Googlebot puede consultar este archivo para conocer las reglas aplicables. Google explica que sus rastreadores automatizados son compatibles con el Robots Exclusion Protocol y procesan robots.txt antes del rastreo.
Esto lo convierte en una pieza importante dentro del SEO técnico, especialmente cuando gestionamos webs grandes, migraciones, filtros o secciones que no necesitamos que Google rastree.
¿Para qué sirve robots.txt?
Su función principal es controlar el rastreo.
Por ejemplo, podemos indicar:
Googlebot, no rastrees determinadas rutas.
Un archivo sencillo podría tener:
User-agent: *
Disallow: /zona-privada/
Esto indica que la regla se aplica a los rastreadores correspondientes y que no queremos que accedan a esa ruta.
Pero aquí aparece una diferencia fundamental:
rastreo e indexación no son lo mismo.
Robots.txt no es una herramienta para hacer noindex
Este probablemente sea el error conceptual más importante.
Bloquear una URL mediante robots.txt significa que estamos restringiendo su rastreo.
No significa necesariamente que estemos garantizando que esa URL nunca pueda aparecer en Google.
Google explica expresamente que una URL bloqueada mediante robots.txt podría llegar a indexarse sin que Google haya rastreado su contenido, por ejemplo si descubre la dirección mediante enlaces externos.
Por tanto:
Disallow ≠ noindex.
Si nuestro objetivo es evitar que una página aparezca en los resultados, debemos estudiar el mecanismo adecuado para controlar la indexación.
Entonces, ¿qué diferencia hay entre robots.txt y noindex?
Podemos simplificarlo así:
robots.txt
Controla principalmente:
si el crawler puede acceder a la URL.
noindex
Indica:
que esa página no debería aparecer en los resultados de búsqueda.
Esto tiene una consecuencia importante.
Si bloqueamos mediante robots.txt una página que contiene un noindex, podemos impedir que Google rastree la página y vea precisamente esa directiva.
No mezclaría ambas cosas sin comprender exactamente qué quiero conseguir.
¿Dónde debe estar robots.txt?
Debe estar en el nivel superior correspondiente al host.
Por ejemplo:
https://ejemplo.com/robots.txt
No:
https://ejemplo.com/carpeta/robots.txt
Google también especifica que las reglas se aplican al host, protocolo y puerto donde se encuentra el archivo.
Esto cobra importancia cuando tenemos:
-
Subdominios.
-
Diferentes protocolos.
-
Arquitecturas complejas.
No asumiría que un único robots.txt controla automáticamente cualquier variante imaginable de nuestro proyecto.
Las directivas básicas
Las que más veremos son:
User-agent
Define a qué crawler se aplican las reglas.
Ejemplo:
User-agent: *
El asterisco permite definir reglas generales para los rastreadores correspondientes.
Disallow
Indica una ruta que no queremos que sea rastreada.
Ejemplo:
Disallow: /privado/
Allow
Permite específicamente el acceso a una ruta en situaciones donde existen otras restricciones.
Sitemap
Podemos indicar la ubicación de nuestro sitemap.
Google admite en robots.txt los campos user-agent, allow, disallow y sitemap; además, advierte que campos no documentados como compatibles pueden no ser interpretados.
Ejemplo sencillo de robots.txt
Una configuración básica podría tener una estructura como:
User-agent: *
Disallow: /privado/
Sitemap: https://ejemplo.com/sitemap.xml
No copiaría esta configuración directamente para cualquier web.
Es solamente un ejemplo.
Nuestro robots.txt debe responder a nuestra arquitectura concreta.
No copies el robots.txt de otra web
Este error es más habitual de lo que parece.
Encontramos:
El robots.txt perfecto para SEO.
Lo copiamos.
Problema:
no existe un robots.txt universalmente perfecto.
Una tienda online puede necesitar controlar filtros.
Un foro tiene otra arquitectura.
Un WordPress tiene otra.
Un SaaS puede tener zonas privadas.
Una web con millones de URLs necesita plantearse el rastreo de forma muy diferente a un blog con 40 artículos.
Primero debemos entender nuestras URLs.
Después configuramos robots.txt.
¿Necesito robots.txt en una web pequeña?
No necesariamente necesitamos reglas complejas.
Si queremos que Google pueda rastrear todas las páginas públicas importantes, podemos mantener una configuración muy sencilla.
Añadir veinte reglas solamente porque parecen “SEO avanzado” puede introducir errores sin aportar ningún beneficio.
En SEO técnico, más configuración no significa mejor configuración.
Error 1: bloquear accidentalmente toda la web
Este es el clásico.
Durante el desarrollo configuramos:
User-agent: *
Disallow: /
Perfecto para impedir rastreo mientras trabajamos.
Lanzamos la web.
Nos olvidamos de eliminarlo.
Después pasan varias semanas y pensamos:
¿Por qué Google no rastrea correctamente la página?
Google advierte específicamente de este problema en sus recomendaciones para migraciones: los bloqueos temporales mediante robots.txt o noindex deben retirarse cuando la nueva web pasa a producción.
Si acabas de lanzar un proyecto, también conviene revisar nuestra guía sobre qué hacer después de comprar un dominio, donde precisamente incluimos las comprobaciones de indexación, sitemap, Search Console y bloqueos accidentales antes de dar por terminado el lanzamiento.
Error 2: utilizar robots.txt para eliminar una URL de Google
Supongamos que tenemos:
/pagina-antigua/
Está indexada.
Pensamos:
La bloqueo en robots.txt y desaparecerá.
No utilizaría esa estrategia.
Como hemos visto, bloquear el rastreo no equivale a solicitar la desindexación.
Necesitamos determinar qué debería ocurrir realmente con la URL.
Quizá:
-
Debe mantenerse.
-
Debe llevar
noindex. -
Debe redirigirse.
-
Debe devolver 404 o 410.
-
Debe consolidarse con otra página.
La solución depende del motivo por el que queremos retirarla.
Error 3: bloquear CSS y JavaScript importantes
Podemos pensar:
Google solamente necesita leer el texto.
Pero Google renderiza páginas y necesita acceder a recursos importantes para comprender correctamente su contenido y presentación.
Por eso no bloquearía carpetas de CSS o JavaScript simplemente porque:
No quiero que Google pierda tiempo con esos archivos.
Podríamos dificultar el renderizado de la propia página.
Error 4: bloquear parámetros sin estudiar qué hacen
En ecommerce podemos encontrarnos URLs como:
?color=negro
?precio=50-100
?orden=precio
?talla=42
Los filtros pueden generar enormes cantidades de combinaciones.
Aquí sí podemos tener un problema serio de rastreo.
Pero antes de añadir:
Disallow: /*?
necesitamos estudiar qué URLs existen y cuáles queremos que Google pueda descubrir.
Una regla demasiado amplia puede bloquear URLs que sí tenían valor.
Robots.txt y navegación facetada
Este es uno de los casos donde robots.txt puede convertirse en una herramienta estratégica.
Una tienda puede generar millones de combinaciones:
marca + color + talla + precio + orden
No todas necesitan ser rastreadas.
Google dispone incluso de documentación específica sobre el rastreo de URLs generadas por navegación facetada.
En proyectos grandes merece la pena estudiar:
-
Qué filtros tienen demanda.
-
Cuáles deberían indexarse.
-
Cuáles solamente ayudan al usuario.
-
Cuántas URLs generan.
-
Cómo las descubre Google.
No resolvería todo simplemente bloqueando parámetros.
Error 5: utilizar Crawl-delay esperando controlar Googlebot
Podemos encontrar ejemplos como:
Crawl-delay: 10
Pero Google indica actualmente que crawl-delay no es un campo compatible con su interpretación de robots.txt.
Este es otro motivo para evitar copiar configuraciones antiguas encontradas en blogs.
Las recomendaciones técnicas cambian.
Conviene comprobar documentación actual.
Error 6: pensar que Sitemap bloquea o permite URLs
La directiva:
Sitemap:
simplemente indica la ubicación del sitemap.
No significa:
Indexa todo esto.
Tampoco:
Solamente puedes rastrear estas URLs.
Un sitemap ayuda al descubrimiento.
No sustituye:
-
Enlazado interno.
-
Arquitectura.
-
Canonicals.
-
Indexabilidad.
-
Calidad.
Tener una URL dentro del sitemap tampoco garantiza que Google vaya a indexarla.
Robots.txt y sitemap trabajan en partes diferentes
Podemos verlo así:
robots.txt → qué rastreo queremos restringir.
sitemap → qué URLs queremos facilitar que sean descubiertas.
Por supuesto, sería bastante incoherente incluir masivamente en nuestro sitemap URLs importantes que después estamos bloqueando mediante robots.txt.
Si encontramos contradicciones así, revisaría la configuración.
Comprueba siempre el archivo después de una migración
Las migraciones son un momento especialmente delicado.
Podemos cambiar:
-
Dominio.
-
HTTPS.
-
Subdominio.
-
CMS.
-
Arquitectura.
Google recomienda comprobar robots.txt y eliminar bloqueos temporales cuando ponemos en marcha la nueva versión.
También revisaría:
-
Redirecciones.
-
Canonicals.
-
noindex. -
Sitemap.
-
Respuestas HTTP.
Un error de robots.txt durante una migración puede complicar innecesariamente el proceso.
¿Cómo comprobar si Google puede rastrear una URL?
Una de las herramientas que utilizaría es Inspección de URLs de Google Search Console.
Si una página importante no aparece en Google, no empezaría modificando robots.txt a ciegas.
Comprobaría:
-
Si Google conoce la URL.
-
Si puede rastrearla.
-
Si existe un
noindex. -
Qué canonical detecta.
-
Qué respuesta HTTP devuelve.
-
Si tenemos problemas de servidor.
De hecho, si el problema es que una URL no entra en el índice, merece más la pena diagnosticar primero la causa. Ya tenemos una guía específica sobre cuánto tarda Google en indexar una página web que complementa perfectamente este punto.
Robots.txt no mejora rankings directamente
Otro mito:
Voy a optimizar robots.txt para subir posiciones.
No lo plantearía así.
robots.txt puede ayudarnos a gestionar el rastreo y evitar que los crawlers dediquen recursos a determinadas zonas.
Eso puede ser muy importante en webs grandes.
Pero añadir:
Disallow: /algo/
no convierte automáticamente las páginas restantes en mejores resultados.
Seguimos necesitando:
-
Buen contenido.
-
Arquitectura.
-
Enlazado.
-
Rendimiento.
-
Autoridad.
-
Intención correcta.
¿Qué pasa si robots.txt devuelve un error?
Aquí encontramos un detalle técnico importante.
Google trata de manera diferente los códigos HTTP.
Por ejemplo, los errores 4xx, excepto determinados casos como 429, suelen interpretarse como si no existieran restricciones de rastreo.
Los errores de servidor 5xx pueden provocar que Google detenga temporalmente el rastreo mientras intenta recuperar el archivo y, en determinadas circunstancias, utilice una versión previamente almacenada.
Por tanto, también deberíamos asegurarnos de que:
robots.txt responde correctamente.
No basta con que el contenido esté bien escrito.
Mantén robots.txt sencillo
Si necesito 400 reglas para explicar a Google cómo rastrear una web pequeña, probablemente investigaría antes la arquitectura.
Una configuración compleja:
-
Es más difícil de mantener.
-
Facilita errores.
-
Puede quedar obsoleta.
-
Complica migraciones.
Intentaría utilizar solamente las reglas que tengan una función clara.
Mi checklist para revisar robots.txt
Cuando audito una web comprobaría:
1. ¿Existe robots.txt?
2. ¿Responde correctamente?
3. ¿Está en la ubicación adecuada?
4. ¿Estamos bloqueando páginas importantes?
5. ¿Estamos bloqueando recursos necesarios?
6. ¿Existen reglas antiguas?
7. ¿Tenemos Disallow: / accidentalmente?
8. ¿Las reglas coinciden con la arquitectura actual?
9. ¿El sitemap indicado es correcto?
10. ¿Estamos intentando solucionar indexación mediante robots.txt?
Con estas diez comprobaciones podemos detectar bastantes problemas.
La regla más importante
Antes de escribir cualquier Disallow, me preguntaría:
¿Qué URLs afectará exactamente esta regla?
No:
¿Qué quiero bloquear?
Sino:
¿Qué terminará bloqueando realmente?
La diferencia parece pequeña, pero evita muchos errores.
Especialmente cuando utilizamos comodines, parámetros y patrones complejos.
Conclusión
robots.txt es una herramienta sencilla pero potente para gestionar el rastreo.
Lo fundamental es recordar:
robots.txt controla rastreo, no es un sustituto de noindex.
A partir de ahí:
-
No bloquees URLs importantes.
-
No copies configuraciones sin entenderlas.
-
Revisa migraciones.
-
Ten cuidado con filtros y parámetros.
-
No bloquees recursos necesarios.
-
Mantén las reglas lo más sencillas posible.
-
Comprueba Search Console cuando aparezcan problemas.
Dentro de una estrategia de SEO técnico, robots.txt es solamente una pieza, pero una configuración equivocada puede afectar a muchas URLs de golpe.
Por eso prefiero un robots.txt sencillo que entiendo completamente antes que uno lleno de supuestas optimizaciones copiadas de otra web.
¿Habéis encontrado alguna vez un error de robots.txt que estuviera bloqueando una web o una sección importante sin que nadie se hubiera dado cuenta?
