robots.txt y sitemap.xml: qué hace cada uno de verdad

robots.txt controla el rastreo y sitemap.xml sugiere qué URLs merece la pena rastrear: ninguno de los dos controla la indexación. Esa frase resuelve el 90% de las dudas sobre ambos archivos. El primero dice a los bots por dónde no pasar; el segundo les entrega una lista de direcciones que existen. Lo que aparece o desaparece del índice de Google lo deciden otras señales —principalmente la etiqueta noindex y el canonical—. Puedes generar y revisar tu robots.txt y crear un sitemap.xml válido con las herramientas de Docuboxer, que trabajan en tu navegador sin subir nada a ningún servidor.

Qué hace robots.txt exactamente

Es un archivo de texto plano que vive obligatoriamente en la raíz del host (https://ejemplo.com/robots.txt) y aplica a ese esquema, dominio y puerto concretos: el de ejemplo.com no gobierna a blog.ejemplo.com ni a la versión http://. Su gramática es mínima: bloques User-agent con reglas Disallow y Allow, que admiten el comodín * y el ancla de final de URL $.

Un ejemplo funcional y bastante típico:

• User-agent: * — la regla aplica a todos los bots.
• Disallow: /carrito/ — no rastrees nada bajo esa ruta.
• Allow: /carrito/ayuda — salvo esta página concreta; la regla más específica gana.
• Sitemap: https://ejemplo.com/sitemap.xml — la URL absoluta del sitemap, que puede ir en cualquier línea del archivo.

Y ahora lo importante: robots.txt no es seguridad. Es un acuerdo voluntario que los bots serios respetan y los maliciosos ignoran. Además, es un archivo público: si listas Disallow: /panel-admin-secreto/, acabas de publicar la ruta que querías esconder. Para proteger algo de verdad hacen falta autenticación o restricciones de red, no una línea de texto.

Qué hace sitemap.xml exactamente

Un sitemap es una lista en XML de las URLs que consideras dignas de rastreo. Su valor real es el descubrimiento: ayuda a que Google encuentre páginas nuevas, páginas mal enlazadas desde la navegación interna y sitios muy grandes donde el rastreo por enlaces tardaría demasiado. En un sitio de veinte páginas bien enlazadas entre sí, el sitemap aporta poco; en un catálogo de cincuenta mil fichas, es infraestructura básica.

Reglas técnicas que sí importan: máximo 50.000 URLs y 50 MB sin comprimir por archivo (por encima de eso, varios sitemaps agrupados en un índice), URLs absolutas y del mismo host, y solo direcciones que devuelvan 200 y sean la versión canónica. Meter en el sitemap URLs con noindex, redirecciones o duplicados no es neutro: envía señales contradictorias y te ensucia los informes de Search Console.

De los campos opcionales, solo lastmod tiene uso declarado por Google, y únicamente si es honesto: si tu CMS estampa la fecha de hoy en cada URL cada noche, el campo deja de significar nada y se ignora. changefreq y priority están muertos desde hace años. El priority: 1.0 de tu home no te posiciona mejor; solo ocupa bytes.

El malentendido central: rastrear no es indexar

Rastrear es descargar la página. Indexar es guardarla en el índice para poder mostrarla en resultados. Son dos fases distintas, y confundirlas produce el error más caro de esta pareja de archivos.

Si bloqueas una URL en robots.txt, Google no la descarga — pero puede indexarla igualmente a partir de los enlaces que apuntan a ella. El resultado es esa entrada fantasma en la SERP: tu URL, sin título decente ni descripción, con un aviso de que no hay información disponible sobre la página. Has conseguido lo peor de ambos mundos: sigue apareciendo y encima se ve mal.

Peor aún: si esa página lleva un noindex en el HTML y además la bloqueas en robots.txt, Google nunca leerá el noindex, porque para leerlo tendría que rastrear la página. El orden correcto es: deja rastrear, pon noindex (en la meta robots del HTML o en la cabecera X-Robots-Tag si es un PDF u otro archivo no HTML), espera a que salga del índice y solo entonces, si quieres ahorrar rastreo, añade el bloqueo.

• Quiero que no se rastree (ahorro de presupuesto de rastreo) → robots.txt.
• Quiero que no aparezca en Google → noindex, con la URL rastreable.
• Quiero consolidar duplicados → rel=canonical, no robots.txt.
• Quiero que nadie ajeno lo vea → autenticación. Ninguno de los tres anteriores sirve.

Tres casos prácticos donde se decide todo

Staging y entornos de pruebas. El clásico Disallow: / en el robots.txt del subdominio de pruebas es mejor que nada, pero no evita que la URL se filtre por un enlace despistado. La solución correcta es autenticación HTTP en todo el entorno: sin credenciales no hay respuesta, y sin respuesta no hay índice. Y el riesgo simétrico es aún más común: desplegar a producción el robots.txt de staging con Disallow: /. Verifícalo el día del lanzamiento.

Facetas de e-commerce. Los filtros combinables (color, talla, precio, orden) generan URLs casi infinitas que consumen rastreo sin aportar nada. Bloquear los patrones de parámetros en robots.txt es la respuesta razonable, con un matiz: si esas URLs ya están indexadas, bloquearlas las congela en el índice. Primero noindex con rastreo permitido, y el bloqueo después.

Crawlers de IA. Rastreadores como GPTBot, ClaudeBot, CCBot o Google-Extended se declaran con su propio user-agent y respetan robots.txt. Bloquearlos es una decisión legítima del dueño del sitio —igual que no bloquearlos— y conviene saber qué implica cada opción: Google-Extended afecta al uso de tu contenido en los productos de IA de Google, no a tu posicionamiento en la búsqueda clásica; bloquear a los demás reduce tu presencia en las respuestas de esos asistentes. El generador de robots.txt incluye un preset con estos user-agents para que no dependas de copiar listas de foros. Recuerda el límite conocido: quien decida ignorar el archivo, lo ignorará.

Checklist rápida antes de dar por bueno tu setup

• El robots.txt responde 200 en la raíz del dominio y no contiene Disallow: / por accidente.
• Ningún recurso necesario para renderizar (CSS, JS) está bloqueado: Google necesita verlos para entender la página.
• Ninguna URL con noindex está bloqueada al mismo tiempo en robots.txt.
• El sitemap solo lista URLs canónicas que devuelven 200, y está referenciado con Sitemap: en el robots.txt además de enviado en Search Console.
• Nada de changefreq ni priority; lastmod solo si refleja cambios reales.

Bien montados, estos dos archivos son aburridos: se escriben una vez, se revisan tras cada despliegue grande y se olvidan. Los problemas siempre vienen de pedirles lo que no pueden hacer.

Preguntas frecuentes

Herramientas relacionadas

• Generador de robots.txt — Reglas por user-agent, presets de bots de IA y línea de sitemap.
• Generador de sitemap.xml — XML válido, con límites de tamaño respetados.
• Meta tags — Donde vive de verdad el noindex y el resto de señales de la página.
• Generador de slugs — URLs limpias antes de que lleguen al sitemap.

También te puede interesar: herramientas SEO gratuitas que no te piden registro y qué es un slug de URL y cómo construirlo bien.