Robots.txt en SEO técnico: reglas, riesgos y patrones seguros

Qué es robots.txt y qué controla (y qué no)

robots.txt es un archivo de texto que se publica en la raíz del host y que comunica a los rastreadores qué rutas pueden rastrear y cuáles deberían evitar. Su función principal es gestionar el rastreo (crawl), no la indexación.

• Sí hace: sugerir a los bots qué URLs no rastrear, reducir carga en endpoints, evitar rastreo de parámetros irrelevantes, separar entornos (staging), y declarar sitemaps.
• No hace por sí solo: impedir que una URL se indexe. Una URL bloqueada puede aparecer en resultados si se descubre por enlaces externos; en ese caso, el buscador puede mostrarla sin contenido/snippet.
• Implicación práctica: si necesitas evitar indexación, usa mecanismos de indexación (p. ej., noindex en HTML/headers) y asegúrate de que el bot pueda rastrear la URL para ver esa señal. Bloquear con robots.txt puede impedir que el bot vea el noindex.

Ubicación, alcance y reglas de coincidencia

Ubicación correcta

Debe estar en: https://tudominio.com/robots.txt. Cada subdominio necesita su propio archivo (p. ej., https://blog.tudominio.com/robots.txt es independiente).

Alcance por host y protocolo

Las reglas aplican al host donde se sirve el archivo. Si tienes http y https, en la práctica hoy se trabaja sobre https, pero asegúrate de que el host canónico sirva el archivo correctamente.

Cómo se evalúan las rutas

Las reglas se aplican sobre la parte de la URL que empieza en /. Muchos rastreadores soportan comodines como * y el final de cadena $. Cuando hay varias reglas aplicables, suele prevalecer la más específica (la de ruta más larga). Para evitar ambigüedades, escribe reglas explícitas y prueba con un validador.

Sintaxis práctica: directivas esenciales

User-agent

Define a qué rastreador aplican las reglas siguientes. Puedes usar * para todos.

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

User-agent: *
Disallow: /admin/

Disallow

Indica rutas que no deberían rastrearse.

User-agent: *
Disallow: /checkout/
Disallow: /api/

Un Disallow: vacío significa “no bloqueo nada” para ese grupo.

User-agent: *
Disallow:

Allow

Permite excepciones dentro de un bloqueo más amplio. Útil cuando bloqueas una carpeta pero necesitas permitir un archivo o subruta concreta.

User-agent: *
Disallow: /assets/
Allow: /assets/public/

Sitemap

Declara la ubicación del sitemap. Puede aparecer una o varias veces y no depende del User-agent.

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

Limitaciones y riesgos típicos

robots.txt no es una “barrera” de seguridad

No protege contenido sensible: solo indica a bots “bien educados” que no rastreen. Si hay información privada, debe protegerse con autenticación/autorización, controles de acceso y/o restricciones a nivel servidor.

Bloquear CSS/JS puede romper el renderizado

Si impides el rastreo de recursos críticos (CSS/JS), el buscador puede renderizar la página de forma incompleta y evaluar mal el contenido o la experiencia. Evita bloquear rutas como /static/, /assets/ o bundles de JS si son necesarios para el render.

Bloquear páginas con noindex impide que se procese el noindex

Si una URL está bloqueada en robots.txt, el bot puede no acceder al HTML/headers y no ver el noindex. Resultado: la URL puede permanecer indexada o aparecer como “URL bloqueada por robots.txt”.

Reglas demasiado amplias

Errores frecuentes: Disallow: / en producción, bloquear / por accidente en un deploy, o bloquear rutas compartidas por el sitio (p. ej., /wp-content/ o /assets/).

Patrones comunes y seguros (con ejemplos)

1) Bloquear parámetros irrelevantes (sin romper URLs útiles)

Si tu sitio genera combinaciones infinitas por parámetros (tracking, ordenaciones, filtros no indexables), puedes reducir rastreo. Hazlo con cuidado: si hay parámetros que sí generan páginas valiosas, no los bloquees aquí.

User-agent: *
Disallow: /*?utm_*
Disallow: /*&utm_*
Disallow: /*?gclid=*
Disallow: /*?fbclid=*
Disallow: /*?sessionid=*
Disallow: /*?sort=*
Disallow: /*?order=*

Nota: el soporte de patrones con * y combinaciones de ?/& depende del bot. Mantén reglas simples y valida con herramientas de prueba.

2) Bloquear carpetas privadas o de backoffice

User-agent: *
Disallow: /admin/
Disallow: /private/
Disallow: /account/
Disallow: /checkout/
Disallow: /cart/

Si estas rutas contienen datos sensibles, no confíes en robots.txt: exige login y controla permisos.

3) Bloquear endpoints técnicos (APIs, healthchecks, debug)

User-agent: *
Disallow: /api/
Disallow: /graphql
Disallow: /health
Disallow: /metrics
Disallow: /debug/

Si algunos endpoints devuelven HTML público (p. ej., documentación), sepáralos en rutas distintas para no bloquearlos por accidente.

4) Bloquear entornos de staging (mejor con autenticación)

Para staging, lo más seguro es restringir acceso (basic auth, allowlist IP, VPN). Como capa adicional, puedes usar robots.txt.

User-agent: *
Disallow: /

Úsalo solo en staging. En producción, esta regla es catastrófica.

5) Evitar bloquear recursos críticos (patrón de “permitir assets”)

Si necesitas bloquear una carpeta amplia pero dentro hay recursos necesarios para renderizado, crea excepciones con Allow.

User-agent: *
Disallow: /tmp/
Disallow: /internal/
Allow: /internal/assets/
Allow: /internal/js/
Allow: /internal/css/

Idealmente, no mezcles rutas internas con assets públicos: separa por diseño de rutas.

Plantilla comentada de robots.txt (lista para adaptar)

# robots.txt para producción
# Objetivo: controlar rastreo sin bloquear recursos críticos

User-agent: *

# 1) Zonas no públicas / flujos transaccionales
Disallow: /admin/
Disallow: /account/
Disallow: /checkout/
Disallow: /cart/

# 2) Endpoints técnicos
Disallow: /api/
Disallow: /graphql
Disallow: /health
Disallow: /metrics

# 3) Parámetros irrelevantes (tracking / sesiones)
# Ajusta según tu plataforma; evita bloquear parámetros que generen landings valiosas
Disallow: /*?utm_*
Disallow: /*&utm_*
Disallow: /*?gclid=*
Disallow: /*?fbclid=*
Disallow: /*?sessionid=*

# 4) Si bloqueas una carpeta amplia, permite explícitamente recursos necesarios
# (mejor: no bloquear /assets/ si es público)
# Disallow: /assets/
# Allow: /assets/app.css
# Allow: /assets/app.js

# 5) Sitemaps
Sitemap: https://tudominio.com/sitemap.xml

Guía práctica paso a paso para crear y desplegar robots.txt sin riesgos

Paso 1: Inventaria qué quieres controlar

• Rutas privadas (backoffice, cuentas, checkout).
• Rutas técnicas (API, healthchecks, debug).
• Patrones de parámetros que generan duplicados o rastreo infinito (tracking, sesiones, ordenaciones).
• Recursos necesarios para renderizado (CSS/JS/imagenes críticas) que no debes bloquear.

Paso 2: Escribe reglas mínimas y específicas

• Empieza por User-agent: * y añade Disallow por carpetas claras.
• Introduce patrones con comodines solo cuando sea necesario.
• Si hay excepciones, usa Allow para rutas concretas.

Paso 3: Añade y verifica la(s) línea(s) Sitemap

• Incluye la URL absoluta del sitemap.
• Si tienes varios sitemaps, decláralos todos.

Paso 4: Despliega en la raíz y comprueba respuesta del servidor

• Debe responder 200 OK (evita 3xx encadenados, 4xx o 5xx).
• Contenido text/plain recomendado.
• Evita que el CDN sirva una versión antigua tras cambios (purga caché si aplica).

Paso 5: Valida reglas con URLs reales

• Prueba URLs críticas: home, categorías, fichas, CSS/JS principales.
• Prueba URLs que quieres bloquear: endpoints, parámetros, carpetas privadas.
• Comprueba que no bloqueas recursos necesarios para renderizado.

Lista de comprobaciones (checklist) antes y después de cambios

Ubicación y accesibilidad

• Ruta: existe en /robots.txt del host correcto.
• HTTP: responde 200 y el contenido es el esperado (sin HTML de error).
• Caché: CDN/proxy no sirve una versión antigua tras el deploy.

Coherencia con señales de indexación

• Noindex: no bloquees con robots.txt páginas donde dependes de noindex para desindexar; el bot debe poder rastrearlas para ver la señal.
• Canonicals: si usas canonical para consolidar duplicados, evita bloquear masivamente las variantes si necesitas que el bot lea el canonical (en muchos casos conviene permitir rastreo limitado y controlar duplicidad por canonical/parametrización).
• Parámetros: confirma que los parámetros bloqueados no generan páginas que sí deberían posicionar.

Riesgos de renderizado

• No bloquear rutas de CSS/JS necesarias para el render.
• Verificar que los bundles principales (p. ej., /assets/app.js, /static/main.css) están permitidos.

Validación tras cambios

• Reprueba el archivo con un validador de robots y casos de URL representativos.
• Monitoriza logs del servidor/CDN para ver si bots intentan rutas bloqueadas y si hay picos de 403/404 inesperados.
• Revisa que no haya bloqueos accidentales por reglas demasiado generales (p. ej., Disallow: /*? puede ser excesivo si tu sitio depende de parámetros).