robots.txt: trampas que bloquean la indexacion en silencio
Un Disallow mal puesto puede borrar el 40% del trafico organico sin alertas. Errores comunes en robots.txt y como auditarlos antes de que duela.
En febrero de este ano atendi a un e-commerce de moda que habia perdido el 38% del trafico organico en seis semanas. Sin penalizacion manual, sin core update, sin cambios de contenido. El culpable: una linea en robots.txt, Disallow: /producto- agregada por un dev que queria bloquear una pagina de prueba llamada /producto-test. El wildcard implicito tumbo 12 mil URLs de PDP del indice en 19 dias. Search Console no grito, solo mostro un declive gradual en 'Descubierta - actualmente sin indexar'. Este caso resume el problema: robots.txt es el archivo mas subestimado y mas peligroso de un sitio. Indexacion parcial: por que las paginas desaparecen de Google
La trampa numero uno es confundir bloqueo de rastreo con bloqueo de indexacion. Robots.txt no quita paginas del indice, solo impide que Googlebot lea el contenido. Si la URL ya tenia backlinks o estaba en el sitemap, sigue apareciendo en la SERP, ahora como ese snippet feo: 'No hay informacion disponible sobre esta pagina'. He visto marcas grandes pagar a una agencia para 'desindexar' filtros facetados con Disallow y el resultado fue lo opuesto: las URLs quedaron atrapadas, sin titulo decente, canibalizando paginas principales. Canonical tags: errores comunes que sangran trafico organico explica por que canonical resuelve esto mejor.
Otro error recurrente: bloquear /wp-content/ o /assets/ enteros en sitios WordPress y Next.js. Google necesita renderizar CSS y JS para entender layout, mobile-friendliness y Core Web Vitals. Cuando bloqueas esos directorios, Googlebot ve una pagina sin estilo, la marca como no mobile-friendly y el LCP medido por CrUX diverge de tu PageSpeed. En un caso que audite via log file, el 23% de las peticiones de Googlebot devolvian 200 para HTML y 403 para los bundles, hundiendo la percepcion de calidad. JavaScript SEO: renderizado, hydration e indexacion Core Web Vitals: mas alla del LCP, lo que mueve la aguja
La tercera trampa vive en la sintaxis. Robots.txt no es regex, pero acepta dos comodines: asterisco para cualquier secuencia y signo de dolar para fin de URL. Casi nadie usa el dolar, y por eso Disallow: /*.pdf bloquea tanto /reporte.pdf como /reporte.pdf?utm=email, lo deseado. Pero Disallow: /search bloquea /search, /search-results, /searchengineland-comparacion y cualquier cosa que empiece por /search. Probar en el propio tester de Search Console con 20 URLs reales pegadas no es opcional. Usa Screaming Frog en modo 'Respect robots.txt' y compara con 'Ignore robots.txt' para ver la diferencia. Log file analysis: que esta haciendo realmente Googlebot
Esta tambien el error de orden y especificidad. Googlebot sigue la regla mas especifica para el user-agent mas especifico, no la primera que aparece. Si tienes User-agent: * con Disallow: /admin y debajo un User-agent: Googlebot vacio, Googlebot ignora el bloque anterior, asume Allow: /. Esto ya filtro paneles administrativos al indice mas de una vez. Otro detalle: el archivo debe servirse en UTF-8 y pesar como maximo 500 KiB. Por encima, Google trunca en silencio. El sitemap declarado en robots.txt debe ser URL absoluta con el mismo protocolo. Sitemap XML moderno: prioridad, lastmod y que ignorar Crawl budget: cuando preocuparse y como medirlo
Como auditar sin adivinanzas: descarga el robots.txt actual y corrigelo contra la lista de URLs de tu sitemap.xml usando el paquete python 'reppy' o el validador de Google en batch via API URL Inspection. Cruza con el reporte de Cobertura de Search Console filtrando por 'Bloqueada por robots.txt'. Si aparecen URLs comerciales ahi, tienes un incendio. Search Console: 7 informes infrautilizados y que extraer de ellos muestra como configurar esa alerta. Para sitios grandes, el log file analysis es la unica forma honesta: ves exactamente lo que Googlebot intento y se llevo 403 o 200. Como auditar SEO on-page sin caer en conjeturas
Takeaway practico: trata robots.txt como infraestructura critica, no como un archivo de texto. Ponlo bajo versionado Git, exige code review antes de cualquier Disallow nuevo, monta un test automatizado que corra contra tus 50 URLs mas importantes en cada deploy y avise por Slack si alguna pasa a Disallow. En 2026, con Googlebot rastreando menos por presupuesto de IA, cada URL bloqueada por error tarda mas en volver al indice cuando corriges, a veces 30 a 60 dias. El costo de un Disallow equivocado nunca fue tan alto.