Saltar al contenido principal

Guías / Cómo verificar un sitio web: las guías prácticas

Cómo comprobar robots.txt para páginas bloqueadas

Abre https://tudominio.com/robots.txt en un navegador: lo que se sirva ahí es tu robots.txt, y controla qué se les permite obtener a los rastreadores. No controla qué se indexa, que es lo más importante de entender sobre el archivo antes de editarlo.

Dónde tiene que vivir robots.txt

Tiene que estar en la raíz del host, como /robots.txt, en texto UTF-8 plano. Se aplica a exactamente un esquema, host y puerto, así que https://example.com/robots.txt no gobierna nada en https://shop.example.com ni nada en la versión http del mismo host. Cada subdominio que quieras controlar necesita su propio archivo.

El código de estado que devuelve el archivo importa tanto como su contenido. Un 404 se lee como "sin restricciones, rastrea todo", que es un estado perfectamente válido. Un 5xx repetido se lee como un fallo temporal y Google puede pausar el rastreo del host en lugar de asumir que puede seguir. Un 403 se comporta como un error de servidor a estos efectos. Si robots.txt no es fiable, el rastreo se vuelve poco fiable con él.

La sintaxis, en cinco líneas

User-agent: *
Disallow: /admin/
Allow: /admin/public-page.html
Disallow: /*?sessionid=
Sitemap: https://example.com/sitemap.xml

User-agent abre un grupo. Disallow bloquea un prefijo de ruta, Allow talla una excepción dentro de un bloqueo, * coincide con cualquier tramo de caracteres y $ ancla el final de una URL. Sitemap es independiente de cualquier grupo y lleva una URL absoluta. El formato está estandarizado como RFC 9309, así que el comportamiento descrito aquí no es específico de ningún proveedor.

Dos reglas de resolución deciden qué pasa realmente. Un rastreador usa solo el grupo más específico que lo nombra, e ignora por completo el grupo * en cuanto un grupo lo nombra directamente. Dentro de ese grupo, gana la regla coincidente más larga, y un empate se decide a favor de Allow.

Los errores que bloquean un sitio entero

  • Un Disallow: / que sobró de un despliegue de staging. Un carácter, todo el sitio bloqueado. Se cuela exactamente de la misma forma que se cuela un noindex de staging: un archivo de configuración que viajó con una publicación.
  • Bloquear CSS y JavaScript. Google renderiza las páginas, así que un directorio de recursos bloqueado puede hacer que una página se vea rota para el rastreador aunque a ti te parezca bien.
  • Esperar que robots.txt elimine una página de la búsqueda. No puede. Una URL bloqueada todavía se puede listar a partir de enlaces externos, normalmente sin fragmento de texto, y como el rastreador no puede obtenerla, un noindex en esa página nunca se ve. Para eliminar una página, permite el rastreo y sirve noindex.
  • Usar noindex: como directiva dentro de robots.txt. Nunca formó parte del estándar y Google dejó de respetarlo el 1 de septiembre de 2019. Hoy se ignora en silencio.
  • Añadir un grupo para un bot con nombre y esperar que las reglas del comodín se sigan aplicando. No lo hacen. En cuanto existe User-agent: Googlebot, Googlebot lee ese grupo y nada más, así que cada regla compartida tiene que repetirse ahí.
  • Una línea en blanco dentro de un grupo. Una línea en blanco termina el grupo, así que las reglas después de ella no pertenecen a nada hasta la siguiente línea User-agent.
  • Listar rutas privadas. El archivo es público. Nombrar /internal-admin/ en él publica la ubicación de lo que estás intentando esconder.

Cómo probar una sola ruta

Obtén el archivo y lee primero el grupo que se te aplica:

curl -s https://example.com/robots.txt

Luego aplica a mano la regla de coincidencia más larga a la ruta en cuestión. Con Disallow: /blog/ y Allow: /blog/public/, la URL /blog/public/post está permitida porque la regla Allow que coincide es más larga. Para una propiedad que sea tuya, el informe de robots.txt en Search Console muestra el archivo obtenido, cuándo se recuperó por última vez y cualquier error de análisis, que es la forma más rápida de confirmar que el rastreador está leyendo lo que crees que está leyendo.

Confirma que es accesible desde todas partes

Un robots.txt que carga desde tu escritorio todavía puede fallarle a un rastreador. Las reglas de protección contra bots, los límites de tasa y los bloqueos geográficos devuelven rutinariamente 403 a rangos de direcciones de centros de datos mientras sirven con normalidad a los visitantes residenciales, y el resultado es un host al que Google ralentiza o deja de rastrear por motivos que nada en tus registros llama un error.

La forma de verlo es pedir el archivo desde algún sitio que no sea tu oficina. Apunta la herramienta gratuita de comprobación HTTP a https://example.com/robots.txt y lee el código de estado devuelto desde puntos de control en distintos países. Un 200 en todas partes es la respuesta sana; un 200 en casa y un 403 desde tres regiones es el hallazgo. Para comprobar si las reglas bloquean una página concreta, el probador gratuito de robots.txt comprueba una URL frente al grupo de todos los rastreadores e informa de si aparece listada en el sitemap. El robots.txt vive fuera de la página, así que la opción Indexability de un monitor HTTP de HostTracker no lo lee: vigila las etiquetas noindex y canónica de la propia página, mientras que el rastreo programado, en beta, verifica cada página rastreada frente al robots.txt. La monitorización SEO explica qué cubre cada una.

Compruébalo ahora

Ejecuta la comprobación gratuita en tu propio sitio, sin necesidad de cuenta.

Robots.txt tester

Monitoriza esto de forma permanente

Recibe un aviso en cuanto algo falle: HostTracker comprueba desde más de 300 ubicaciones y te avisa por correo, SMS, Slack, Telegram y más.

Funciones de HostTracker

Más en esta sección: Cómo verificar un sitio web: las guías prácticas