# Prueba tu robots.txt contra Googlebot antes de bloquearlo todo
Una sola regla mala de robots.txt puede hundir tu visibilidad en búsqueda de un día para otro. Escribes una línea Disallow:, te olvidas seis meses y Google deja de indexar el 40% del sitio porque bloqueaste sin querer un directorio crítico. No vas a ver la caída de tráfico de inmediato: el crawl budget se gasta en páginas que nunca aparecen en los resultados.
El problema real es que la mayoría escribe las reglas de robots.txt en un editor de texto, las sube y nunca prueba de verdad qué va a ver Googlebot. Dan por hecho que la sintaxis está bien. La mitad de las veces, no.
¿Qué es un tester de robots.txt?
El Tester de robots.txt de Google es una herramienta gratis en el navegador que simula cómo Googlebot interpreta tus directivas de robots.txt en URLs concretas. Pegas el archivo robots.txt o apuntas al dominio, escribes la ruta que quieres revisar y te dice si esa ruta se rastrearía o se bloquearía. Sin login. Sin instalación. Obtienes un sí o un no al instante, con la regla exacta que disparó el resultado.
Piénsalo como un ensayo antes de subir un cambio de robots.txt a producción. Estás probando la regla contra la lógica real de parseo de Googlebot, no adivinando según lo que recuerdas de un post viejo.
Por qué importa para el SEO
Los bloqueos de robots.txt son permanentes hasta que los corriges. Google vuelve a rastrear la mayoría de los sitios cada 3 a 7 días, así que si bloqueas /products/ por accidente, esa sección se queda invisible al menos una semana. Si tu sitio tiene 100,000 páginas y el 20% está bloqueado por un typo en robots.txt, acabas de sacar 20,000 URLs de la visibilidad en búsqueda.
El segundo problema es el desperdicio de crawl budget. Googlebot asigna un ancho de banda fijo para rastrear tu sitio cada día. Si robots.txt le dice que se salte la mitad de las páginas, Googlebot rastrea la otra mitad con más detalle, pero tú pagas esa ineficiencia al no mostrarle al motor el contenido que sí debería encontrar.
Tercero, los conflictos de reglas de robots.txt fallan en silencio. Puedes tener un Disallow: / global y después un Allow: /public/ que crees que lo anula. Googlebot lee de arriba hacia abajo y se detiene en la primera coincidencia. La regla Allow no hace nada. El sitio desaparece de la búsqueda.
Cómo usarlo
- Entra al [Tester de robots.txt de Google](https://scrawl.tools/tools/robots-txt-tester). Pega el contenido de tu robots.txt en el campo o escribe la URL del dominio para que lo traiga solo. No hace falta cuenta.
- Escribe la ruta que quieres probar. Pon
/blog/my-article,/products/shoeso cualquier otra ruta de tu dominio. La herramienta acepta rutas relativas (por ejemplo,/admin) o URLs completas. - Haz clic en “Probar” y lee el resultado. Vas a ver si esa ruta está permitida o bloqueada, qué regla la disparó y la lógica de coincidencia exacta que aplicó Googlebot.
Repite esto en cada sección crítica del sitio —el blog, las fichas de producto, los filtros de categoría, el checkout— antes de publicar cualquier cambio de robots.txt en producción.
Qué te dicen los resultados
Cuando pruebas una URL obtienes cuatro datos: la ruta que probaste, si está permitida o bloqueada, qué regla coincidió y el contexto del user-agent. Si el resultado dice “Bloqueado por: Disallow: *.pdf$”, sabes que Googlebot se va a saltar todos los PDF del sitio. Si no quieres eso, borras o modificas esa regla.
El Tester de robots.txt de Google también te muestra la prioridad de las reglas. Se evalúan de arriba hacia abajo, y Googlebot se detiene en la primera coincidencia. Si tienes Allow: /public/ arriba de Disallow: /, el Allow gana para todo lo que esté en /public/. La herramienta lo deja explícito para que no tengas que seguir la lógica a mano.
También vas a ver resultados vacíos si tu robots.txt no coincide con la ruta probada. Eso significa que la ruta se puede rastrear por defecto.
3 errores que comete casi todo el mundo
Error 1: olvidar probar la especificidad del user-agent. Tu robots.txt puede tener reglas para Googlebot, Bingbot y un * comodín (todos los crawlers). Pruebas contra Googlebot y pasa, pero Bingbot queda bloqueado porque coincide con la regla * en su lugar. Mucha gente no ve que la herramienta te deja probar crawlers distintos por separado.
Error 2: bloquear directorios enteros porque “no son relevantes para SEO”. Quienes desarrollan bloquean /admin/, /api/, /temp/ porque asumen que Googlebot no debería verlos. Pero después /api/v1/public-data/ sí sirve para datos estructurados y debería poder rastrearse. O pones reglas granulares (permitir subrutas concretas) o aceptas que Googlebot lo va a rastrear y dejas que las meta robots manejen la indexación página por página.
Error 3: no volver a probar después de los cambios. Pruebas el robots.txt una vez, pasa, y te olvidas dos años. Luego cambias de hosting, migras a un subdominio o reorganizas la estructura de URLs. Las reglas viejas ahora bloquean las rutas equivocadas. Prueba otra vez antes de cada deploy, no solo una vez.
Cuándo probar tu robots.txt
Prueba antes de subir cualquier cambio de robots.txt a producción. Prueba justo después de migrar el sitio a un dominio o un hosting nuevo: las rutas relativas pueden haber cambiado. Prueba si agregas secciones nuevas, como un subdirectorio de blog o un endpoint de API. Prueba si estás peleando con el crawl budget y estás pensando en reglas Disallow amplias para bajar solicitudes que no hacen falta.
También deberías probar si heredaste un sitio de otro equipo o de una agencia. Los robots.txt viejos suelen traer reglas de hace cinco años que nadie recuerda por qué existen. Un sitio que audité tenía Disallow: /index.html, escrito en 2014 para “evitar indexación duplicada”. Google se había estado saltando la homepage durante tres años. La regla no servía.
Probar toma 90 segundos por URL. No probar te cuesta miles en tráfico de búsqueda perdido.
---
Deja de adivinar si tu robots.txt funciona de verdad. Entra al Tester de robots.txt de Google, pasa tus URLs y confirma que Google va a ver lo que tú quieres que vea. Es gratis y no pide configuración.