10+1 cosas que deberías saber sobre los archivos robots.txt e indexación SEO


Hace tiempo que no comentamos muchas cosas de SEO por aquí. Así que para que no se diga hoy he sacado de borradores una serie de apuntes sobre uno de los básicos del SEO del que la mayoría de gente desconoce detalles muy importantes: El archivo robots.txt, uno de los básicos de la indexación SEO. Robots.txt es un archivo destinado a indicar a los buscadores que URLs tiene derecho a visitar y de cuales debería abstenerse. El funcionamiento es simple: antes de visitar una URL del site un robot debería mirar en este archivo para determinar si tiene que ir ahi a recoger información o si por el contrario el dueño del site prefiere que no entre. En definitiva son solo indicaciones que cualquier robot puede saltarse si quiere, pero a las que el robot de google hace bastante caso (que tampoco al 100%).

El archivo robots.txt es uno de esos temas técnicos del que todo SEO debe saber lo suficiente como para manipularlo con éxito. Por ello el mismo Google en su soporte nos indica como podemos crear el nuestro: Información sobre los archivos Robots.txt.

Se nos da información muy directa y fácil de asimilar. La redacción de estos archivos es muy sencilla aunque cualquier fallo, por mínimo que sea, podría provocar que las arañas no entrasen en las páginas que nosotros deseamos. En el mejor de los casos eso provocará que sigan visitando URLs en las que no querríamos que perdiesen el tiempo en el peor será todo lo contrario: no indexarán contenidos que en realidad si que queremos que aparezcan en el buscador. Es el tipíco aspecto importante que de fácil que es la gente no se toma lo suficientemente en serio, y ahí esta el problema: la documentación de Google está bien aunque no cubre todas las pecularidades sobre como se va a interpretar dicho archivo y si nos quedamos solo ahí podemos cometer errores que lamentaremos en el futuro.

Así pues, os dejo 10 conceptos sobre estos archivos que hay que tener en cuenta y asimilar. Desde lo más básico hasta consejos que solo en webs complejas o con mucho detalle de optimización del crawl budget podremos aplicar.

Previo: El formato general del robots.txt

Un Robots.txt es sencillo…

1. Empezamos declarando en una línea el user-agent (nombre del sistema que está navegando o rastreando el site) al que queremos afectar y tras esta indicaremos los accesos permitidos y prohibidos.
– Muchas veces declararemos un accceso a todos (user-agent:*) y en ocsaiones nos referiremos a algun robot o crawler en particular (user-agent:googlebot).

user-agent: *
---- Reglas para todos los robots ----

user-agent: googlebot
---- Reglas que solo aplican a Google Bot----

user-agent: majestic
---- Reglas que solo aplican majestic----

2. Después usamos directivas «Allow: {expresion}» y «Disallow: {expresion}» para indicar si damos acceso o lo eliminamos. Por defecto podríamos decir que un robot tiene acceso a todas las URLs del site («Allow:*») pero aunque esto ya es así desde el principio mucha gente decide dejarlo declarado de forma explicita y continuar prohibiendo a partir de ahí. Por eso aun siendo innecesario no debe parecernos raro ver un robots que empieza por «Allow: *».

3. Por ultimo, podemos indicar nuestro sitemap.xml si lo deseamos (sitemap: sitemap.xml). Esto para Google carece de importancia si gestionamos adecuadamente Google Search Console, aunque puede ayudar a otros robots a leerlo así que mal no va a hacernos declararlo.

sitemap: /miarchivositemap.xml

Una cosa curisosa de este archivo sitemap es que puede estar alojado incluso en otros dominios distintos al nuestro (esto puede ser útil si por ejemplo necesitamos hacer subidas con cambios del archivo cada cierto tiempo y en la web que trabajamos no nos lo permiten ir actualizando de forma tan ágil).

Así un ejemplo que cubra todo lo que acabamos de mencionar sería el siguiente:

user-agent: *
allow: *

user-agent: googlebot
disallow: /no-rastrear-esto/
allow: /no-rastrear-esto/pero-esto-si/
disallow: /*/no-rastrear-esto/

sitemap: /sitemap.xml  

Visto esta base, que es lo más conocido del robots, vayamos a por los conceptos que no todo el mundo tiene tan dominados…

1. Donde colocas tu archivo es más importante de lo que creees.

Existe mucha confusión con este punto, en parte porque la documentación en el pasado (de hecho cuando escribi este post yo mismo lo detallé mal) El archivo robots.txt siempre se busca en la ruta «/robots.txt» de tu dominio. El robots.txt afecta al host donde está alojado pero solo a este host exacto. Esto supone que un subdominio no hará caso al robots.txt de su host superior y que http y https usan archivos distintos. ¿Por qué etonces vemos sitios donde una configuración bloquea a otra? Lo veremos más adelante pero es sobretodo por temas de hosts redirigidos totalmente con un 301. Es decir, cuando vemos que el robots.txt de www.midominio.com afecta también a midominio.com normalmente es porque existe una redirección de «midominio.com/robots.txt» a «www.dominio.com/robots.txt» y por lo tanto se lee el mimso archivo para ambos hosts. Lo mismo pasa con http y https, si uno esta redirigido al otro se aplica el mismo archivo a ambos.

Pero en definiva vendría a ser esto:

Así pues:

  • midominio.com/robots.txt >> NO afecta a www.midominio.com y a blog.midominio.com
  • dev.midominio/robots.txt >> Afecta a dev.midominio.com pero no a blog.dev.midominio.com
  • www.midominio/robots.txt >> Afecta a www.midominio.com pero no a blog.www.midominio.com y solo afectará a midominio.com si hay un redirect de midominio.com/robots.txt a www.midominio.com/robots.txt

Además también hay que eliminar la creencia de que el robots.txt actúa como muchos piensan sobre carpetas concretas del site. Esto no es cierto: Google solo lo lee si está en la raiz del documento:

«midominio.com/blog/robots.txt» no sirve para nada. Google no va a intentar leerlo ni tiene porque hacerle caso. Algunos CMS se empeñan en añadirlo pero esto no forma parte de la definición oficial del archivo robots.txt.

2. El tipo y tamaño de archivo puede afectar a que no se lea tu archivo robots.txt

Lo ideal es que un robots.txt esté codificado en UTF-8 para no tener problemas de lectura. Pero lo cierto es que los archivos de texto pueden tener varias codificaciones y si por ejemplo creas el archivo desde tu bloc de notas de windows es probable que su formato sea otro. Es recomendable usar editores de texto plano más profesionales (como por ejemplo, por daros una opción sencilla y pontente notepad++ ) donde entre otras cosas se os deje escoger la codificación del archivo.

Aun así Google nos dice que puede leer otras codificaciones, lo que pasa en estos casos no es tanto que el pueda o no, sino que al generarlo se escriba en una codificación y el servidor lo devuelva en otra. Eso puede provocar los típicos caracteres extraños que terminan en que el archivo no funcione o no se lea de forma adecuada.

Aun dentro de los archivos UTF-8 hay una cosa en estos archivos que se llama BOM (Marca de orden de bytes del archivo, que ocupa la primera linea) . Lo ideal es que los ficheros simples no tengan BOM pero Google es capaz de leer el robots.txt con un BOM inicial (y solo uno y solo al principio) así que si vuestro archivo tiene BOM no pasa nada.

Otra limitación la tenemos en el tamaño. Google nos limita a 500MB, (1/2 GB) si lo pasamos no leerá el archivo. Así que tenemos que economizar estos archivos y ya no solo por no acercanos a los 500MB sino porque son archivos muy consultados por los robots y a mayor tamaño más desgaste de proceso y red en el servidor.

3. Un disallow solo prohíbe leer el contenido no indexar (y de primeras no está focalizado a desindexar)

Un aviso: No es lo mismo un <meta name=»robots» content=»noindex» /> que un disallow en el robots. Significan cosas totalmente distintas.

  • Disallow prohibe a las arañas leer el HTML de la página. Pero puede leer la URL y aparecer esta en búsquedas con información a partir de otras páginas y links de internet. Además con un disallow no eliminamos lo que ya sabía Google de esas páginas y no es extraño que tras añadir una URL como disallow veamos como el resultado se mantiene un tiempo en el buscador. Definitivamente no es una forma rápida de desindexar, va más encaminado a temas de rastreo y a acciones a medio o largo plazo.
  • Por el contrario con un NoIndex en el meta-robots si deja a la araña rastrear el HTML pero prohíbe que su resultado salga en Google. Es el efecto contrario: las arañas siguen perdiendo el tiempo con esa página pero los resultados desaparecen antes del buscador

Todo esto por supuesto con matices… A la larga un Disallow provocará la desindexación si no hay links externos hacia esa página y por el contrario un meta-robots a noindex terminará provocando menor rastreo de esa url que total Google no puede trabajar.

4. Si el contenido no se lee, como es lógico, las directivas del HTML se ignoran

No tiene sentido un disallow+noindex o un disallow+canonical o disallow+rel-next/prev o un disallow+loquesea-en-el-html. Google no va a contemplar este HTML porque le hemos prohibido acceder a el así que ahórrate su etiquetado.

Lo mismo pasa aunque en menor medida con las redirecciones. Si yo creo una redirección 301 de una URL vieja a una nueva y al mismo tiempo bloqueo la vieja por robots.txt Google no debería enterarse de que he creado un 301 (porque no debería acceder a la URL con 301) así que el traspaso de autoridad no se realizará de forma eficiente. En la práctica a veces si se da cuenta de la redirección pero por lo general se pierde mucha autoridad al hacer estas cosas.

Otro caso es el de meta-robots=noindex unido a otras directivas. En teoría nada impide que no puedas poner por ejemplo un noindex y un canonical a la vez, se puede pero es un poco especial y en realidad su interpretación es muy ambigua. Y ante estos casos ambiguos sabemos que Google decide ignorar todas las señales del HTML (por no fiarse de ellas) por lo que aunque en teoría si se puedan hacer estas cosas yo no os recomendaría ninguna salvo la de «noindex,follow» e incluso esa, con cuidado (pues un noindex se rastrea poco, así que ponerle un follow termina siendo un poco contradictorio).

5. La redacción de las URLs es simple, pero muy concreta y sus reglas de lectura no son tan intuitivas como podría parecer.

La vamos a repasar porque llegados al detalle tiene miga y la gente comete muchos fallos.

Cada línea debe empezar con una orden (allow/disallow) y cada orden hay que escribirla con mucho cuidado.

  • Si las urls no comienzan con un slash («/») google lo añadirá. Es decir: «disallow: blog» google lo entenderá como «disallow: /blog» y «disallow: -producto» como «disallow: /-producto».
  • La regla que aplica Google no es un «contiene», nuestra declaración debe empear por el principio de la URL. Normas tipo «disallow: .doc» no funcionan porque falta el principio de la URL. De echo entenderá que la url a prohibir es urls que empiecen por «/.doc».

    Esto tiene varias implicaciones:

    • La solución cuando lo que queremos es definir partes del final o fragmentos de las URLs es redactarlas como sigue: «/*-producto» o «/*.doc» indicando que empieza por cualquier cosa y luego si contiene ese rastro que queremos detectar.
    • Si pensamos en declarar carpetas de la web todo se vuelve más fáficl pues Google entenderá que se hace referencia a esa dirección y a todos los achivos internos que contengan esas carpetas. Es decir, al indicar «/mi-carpeta» como disallow, también prohíbo el acceso a «/mi-carpeta/mi-archivo».
  • Las directrices allow/disallow no son sensibles a mayúsculas y minúsculas, pero las URLs que se definen en ellas si lo son. Es decir yo puedo escribir «disallow:» o «Disallow:» o «DISALLOW:» y es lo mismo pero «/mi-pagina» y «/MI-PAGINA» no son la misma URL.
  • Se nos permite usar los comodines * y $ para completar las URLs:
    • «*» equivale a cualquier conjunto de caracteres. (el equivalente en expresiones regulares a «.*»)
      • «disallow: /blog*» bloqueará la carpeta /blog/ pero tambien cualquier archivo o carpeta cuya url empiece por «/blog», por ejemplo «/blogueria.html»
      • «disallow: /*.doc» si que funciona pues contemplamos cualquier cáracter al principio y esperamos que acabe por .doc
    • «$» Nos permite forzar que ese sea el final de la URL, sin permitir nada tras ella:
      • «disallow: /categoria/$» solo bloqueará el acceso a la página de categoría «/categoria/» pero no a archivos internos como «/categorias/post»
      • «disallow: /blog$» solo bloqueará el archivo «/blog» pero no la carpeta «/blog/»
    • Se nos permite sobreescribir reglas por ejemplo permitir el rastreo de una parte de una regla ya prohibida o prohibirlo luego de nuevo para una regla que lo permitía.
      disallow: /blog/
      allow: /blog/$
      allow: /blog/categoria-1
    • Si rastreará tanto la home como la categoria-1 del blog, pero no el resto porque todo el resto de URLs siguen prohibidas

    • Por último, las reglas no se aplican por orden de lectura sino por lo especificas que son.
      La norma es que Las Reglas más largas pesan más que las más cortas.
      Así:

      disallow: /blog-corporativo/
      allow: /*.html
      

      No conseguirá que se rastreen los archivos «.html» dentro de /blog-corporativo dado que es más larga la expresión de blog-corporativo y por lo tanto pesa más.

      Pero esta otra composición si lo hará:

      disallow: /blog-corporativo/
      allow: /blog-corporativo/*.html
      

      Porque ahora «/blog-corporativo/*.html» es más largo que «/blog-corporativo/» … así de simple, pero también así de ilógico.

6. Las alternativas para evitar rastreo/indexación a robots.txt o meta-robots no son igual de pontentes.

Y esto es así… No hay nada más potente y duradero que una sentencia de robots.txt…

  • En Google Search Console puedes usar la herramienta de borrar contenido y estas URLs se borrarán. Pero Google aproximadamente a los 90 días olvidará que le habías pedido borrar la URL y si por lo que sea vuelve a encontrarla la volverá a indexar. Por lo que sirve para eliminar errores puntuales pero no para eliminar URLs que van a seguir ahí.
  • En Google Search Console puedes usar la herramienta de parámetros de URL para indicar si un contenido aporta cambios en la url o no pero esto no es mandatario, Es solo una ayuda como puede ser el sitemaps y si Google cree que los parámetros indicados son interesantes (cambian el contenido del HTML) la usará igual. Básicamente solo es útil para indicar que no indexe URLs de campañas y ayudar un poco con los listados. Lo que seguro que no evitará esta función es que los robots entren en dicha URL

7. Todas las directivas no contempladas en la deficnición del robots se ignoran.

Por ejemplo el famoso «Crawl-delay» se ignora. En teoría debería indicar tiempo entre peticiones de robots pero no le hace caso así que podemos olvidarnos de esta sentencia al menos para Google (otros rastreadores si que le hacen caso).

Todas las directivas inventadas por terceros tambien se pasan por alto.

Y por último las lineas que empiezan por «#» también se ignoran al entenderse como comentarios. Sin embargo si que cuentan en el tamaño de archivo máximo así que es mejor no pasarse con su uso. Una recomendacion para comentarios: Cuando trabajamos con varios proyectos o muchos sites es mejor incluir notas de la version subida como comentario.:

#robots.txt for www.midominio.com DD-MM-YYYY

user-agent: ...

8. ¿Que pasa cuando Google no puede acceder o encuentra cosas raras al acceder a tu archivo robots?

Ya hemos dicho que el archivo robots.txt siempre se busca en la ruta «/robots.txt» de tu dominio. Y que si no lo encuentra, podrá ir a buscarlo a un nivel superior de dominio (si existe). Por ejemplo si no lo encuentra en www.dominio.com/robots.txt irá a buscarlo a dominio.com/robots.txt

Pero veamos ahora que pasa cuando lo solicita. Un servidor lo que hará cuando reciba la petición del archivo robots.txt es devolver un código de respuesta diciéndole a las arañas si lo está encontrando o no.

  • Código «200». Significa que el archivo SI existe. Entonces lo leerá y aplicará sus normas. Si está vacío o googlebot no tiene directrices «disallow» entenderá que tiene acceso a todo y entrará hasta la cocina de la web
  • Códigos «4xx» (404, 401, 403, etc.). Significa que el archivo no existe o no está abierto al público. En ese caso google lo entenderá como un archivo vacío y dará acceso a todo como si no contuviese disallows.
  • Código «301». Significa «contenido movido permanentemente» y viene acompañado de una URL donde está el nuevo contenido. Google interpreta a todos los efectos que el contenido de esta URL a la que redirige robots.txt es el propio robots.txt, incluso si existe un cambio de carpeta, la URL está en otro dominio o si la URL no tiene el nombre «robots.txt».

    Conocer este detalle puede ser útil para gestionar robots.txt programados en algunos sistemas. Podemos tratar la URL de /robots.txt solo como una redirección a donde realmente gestionamos nuestro archivo robots.txt.

    Sin embargo también puede suponer un problema en migraciones mal realizadas de un dominio a otro o de http a https. En estos casos podemos encontrarnos con que al migrar un site devolvemos un 301 hacia el nuevo site con el robots.txt con lo que estaríamos aplicando el robots.txt nuevo al viejo dominio dejando de bloquear las urls viejas y pudiendo provocar una cascada de detección de errores y pérdida de tiempos de rastreo. Por general la recomendación debería ser que todos los sites tengan su propio /robots.txt y que nunca se redirija pero esto en la mayor parte de los casos no se hace así.

  • Otros códigos (sobretodo 503). Si hay un error en servir el archivo, Google entiende que el dominio está caído y para no molestar para el rastreo del site y solo consultará el archivo 503 hasta que su error cambie. Parar el rastreo no supone desindexar, salvo que mantengamos así el servidor tanto tiempo que empiecen a perder fuerza los enlaces y contenidos de la página, por lo general mejor no hacerlo más de unas horas.

    El cómo actúa Google si este error persiste en el tiempo no lo sabemos exactamente pero por el motivo que sea suele llevar a perdidas de autoridad y a que se intente reindexar la web. Por este motivo, cuando hay errores técnicos en una web, y se están solucionando en ese mismo día, es preferible obligar al archivo robots.txt a que devuelva error 503 y así parar la indexación completa del site hasta que se arregle el problema. Esto es mucho mejor que bloquear el rastreo ya que lo segundo tiene implicaciones más severas y un simple 503 es totalmetne temporal.

  • Sin respuesta. Otra posibilidad es que el servidor no devuelva nada o tarde demasiado tiempo en hacerlo (por problemas de configuración o porque la maquina está demasiado saturada). En esos casos Google tira de la caché que tiene de este archivo durante un tiempo. Es decir, interpreta el último archivo robots.txt al que pudo acceder y trabaja como si fuese este el que está subido.

9. El bloqueo de archivos JS y CSS puede ocasionar problemas e incluso está mal visto por el buscador

Google recomeinda no Bloquear archivos CSS y JS. Antigüamente eran archivos que se solían bloquear porque no le servian a las arañas para nada. Pero ahora los robots de google son capaces de interprertar el HTML y así situar los contenidos en su contexto (saben si un texto es grande o pequeño, el color de fondo o que sitio ocupan en el diseño y lo visibles que son los contenidos para los usuarios. Así que Google nos pide que le dejemos acceder a esto y así valorar la web al completo.

Si no les damos acceso a estos archivos es cuando empieza a enviarnos notificaciones y en la práctica la autoridad/calidad que percibe de nuestra web disminuye.

Esto no significa que no podamos nunca bloquearle un archivo JS (todos sabemos para qué 😈) pero si que hay que evitar este bloqueo a nivel general.

10. Google entra en contenidos 400 pero no si se le bloquea

Los contenidos 400 (páginas 404 – no encontradas, o 401 que suelen estar bajo login, etc…) si que son accedidos por las arañas. Google lo intenta y se encuentra al visitar las páginas con que estas no responden y por lo tanto no indexan.

Al final con esta situación lo que provocamos es perder tiempo de rastreo en URLs que nunca se van a indexar así que suele ser preferible bloquearles el acceso directamente. Pensemos en cualquier URL, incluso las de destino de los formularios de Google y una vez las tengamos presentes:

  • 1. Evitemos que el HTML muestre links hacia ellas
  • 2. Independientemente de si este acceso existe o no, marquemolas con con disallow en el robots

Bonus. Es posible enviar un noindex desde tu servidor creando una especie de robots.txt pero para noindex y nofollow

No cuento este punto entre los 10 conceptos pues en realidad habla más de directivas de indexación que de robots.txt y es más una posibildiad que no es fácil de implementar para todos ( y en su versión más sencilla no está recomendado y no sabemos realmente si funciona).

Hablamos de encontrar alguna forma no para prohibir el rastreo sino para prohibir la indexación: el equivalente a la metaetiqueta de robots marcada a «noindex» que comentabamos antes. Sobre este tema podréis leer de todo, lo más común es que os encontréis artículos que os hablen de la directiva «noindex:» dentro del archivo robots.txt

Esta directriz viene a decirnos que nosotros podemos crear sentencias noindex en el archivo robots con la misma nomenclatura.

Por ejemplo:

Allow: /categoria-1/
Noindex: /categoria-1/*-pag-*$

Vendria a decirle al robot que puede navegar por la categoría-1 y rastrearla pero que los contenidos de las páginaciones de esta categoría no deben aparecer en el índice de búsqueda.

Seria genial que nos dejasen hacer esto ya que como comentaba antes bloquear una URL no implica desindexarla y asi tendríamos un control total sobre todo esto. Sin embargo, y a pesar de que podréis ver como muchos SEOs lo mencionan e incluso Deepcrawl lo mide, Google ya nos ha dicho que no recomienda usarla y mientras lo sigan diciendo yo creo que carece de sentido hacerlo. Así que no disfrutamos de esta posibilidad…

En su lugar tenemos otra forma más complicada pero efectiva a nivel de servidor que podemos usar. Google tiene documentado el uso de directivas robots (index/noindex,follow/nofollow) con el uso de «x-robots-tag» en las cabeceras. Según esta definición tan solo tenemos que enviar una cabecera del tipo «x-robots-tag» con el mismo valor que pondríamos a la meta-etiqueta robots para para pasarlo desde servidor y no desde HTML.

A parte del propio sistema, esto nos abre la puerta a crear un archivo que gestione estas cabeceras en nuestro servidor. Podemos hacer esto con el lenguaje de programación de nuestro CMS (PHP, Java, .Net, etc.) o directametne en la configuración del servidor. En ella gracias a los archivos .htaccess y .htconfig podemos declarar el envio de cabeceras en un único archivo que definia qué puede y qué no puede indexar el robot.

Ejemplo para marcar un noindex,follow en paginaciones de tu web a través del archivo .htconfig:


  
    Header set X-Robots-Tag "noindex,follow"
  
  # Otras definiciones para crear cabeceras

Marcar no indexar incluir caché o descripción de los archivos PDF en el .htaccess…


Header set X-Robots-Tag "index, noarchive, nosnippet"

O no indexar paginaciones a través del módulo de modRewrite con el que gestionamos nuestras URLs amigables y redirecciones:

RewriteCond %{THE_REQUEST} "^(GET|POST) .*page/[0-9]+ HTTP"
RewriteRule .* - [ENV=NOINDEXFOLLOW:true]
Header set X-Robots-Tag "noindex,follow" env=NOINDEXFOLLOW

Pero no quiero estenderme demasaido con este sistema, si quieres leer más sobre como ponerlo en práctica te invito a que visites otro post de este mismo blog donde detallo otras 10 cosas que deberías saber sobre meta-robots. En la última de ellas se explica al detalle este sistema.

Conclusión

No se si os habrá pasado como a mi a medida que he ido descubriendo con los años todo lo que os he expuesto en este post, pero la verdad es que como todo en el SEO, te das cuenta de que nunca sabes lo suficiente de todo. Me pareció interesante recopilar todo esto porque sigo viendo con el tiempo que los problemas que existen en muchos sites debido a no entender bien los archivos robots.txt siguen ahí año tras año y nadie habla de ellos demasiado.

Asi que espero haber ayudado a algunos y a otros haberles descubierto algún detalle que desconociesen.

Como siempre os espero en los comentarios o por twitter.


8 respuestas a “10+1 cosas que deberías saber sobre los archivos robots.txt e indexación SEO”

  1. Pedazo de post. Como dicen más arriba, no había leído ningún artículo tan completo sobre el funcionamiento y los usos del robots.txt. A veces damos por hecho que basta con saber lo que significan los comandos Allow y Disallow, pero hay mucho más. Me lo guardo en favoritos.

    Gracias por el aporte, Iñaki.

  2. Hola Iñaki!

    Muy buen post, bien explicado y resumido uso de robots y todo lo que puede pasar con él. ¡Muchas gracias por compartirlo!

    Tengo una duda respecto al robots.txt que hasta ahora no he sabido resolver ni desde la experiencia, ni desde el support de google o su foro de webmaster.

    Teóricamente, Googlebot intenta acceder a robots.txt para ver qué indicamos en él y si lo tenemos en Search Console entiendo que le facilitamos el proceso, pero ¿esto lo hace cada vez que entra en nuestra web? Lo que quiero decir es que si cuando Googlebot entra en una web que tiene un robots subido a Search console ¿crees que visita primero el robots.txt antes de seguir por el resto de urls?

    Gracias de antemano por tu respuesta 🙂

    Saludos

    iván

    • Hola Iván.

      Lo primero, creo que al menos al exponerlo confundes conceptos. El robots no se sube a GSC, ese es el sitemap. El robots es mucho más estándar y dado que su URL siempre está clara no hay que indicarle nada a gsc para que Google lo encuentre.

      Luego respondiendo a tu pregunta: lo consulta siempre: si! Incluso cuando no lo tienes en tu site Google va provocando errores 404 en la URL /robots.txt en un intento constante de encontrarlo.

      Lo consulta antes de ver cada URL? No. No va así, el rastreo de Google no es organizado. El va generando y ejecutando una cola de peticiones al servidor. Su trabajo es constante, en un site grande puede hacerte varias peticiones por segundo. Y entre todas las que hace el robots es una de las más solicitadas: va mirándola para validar que no lo cambias o alteras.

      Cuanto la mira? Depende del site, pero mucho. No tiene porque ser la URL que más mira del site (la home suele mirarla más pero si suele estar entre las 10 o 20 que más mira)

      Espero haberte ayudado

      • Hola Iñaki 🙂

        Muchas gracias por tu respuesta! Me has ayudado mucho con tus opiniones.

        Tienes razón que al enviarte mi consulta confundí un concepto y me lié entre el «probador de robots» de GSC y subir el archivo robots a GSC, muchas gracias por aclararme el error 🙂

        Un abrazo,

  3. Me ha gustado mucho la verdad, sin duda otro post para enmarcar.

    Creo que solo añadiría una cosa por aportar algo y es el comportamiento especial que hace Adsbot-Google ignorando las directrices generales del robots.txt ya que presupone que están mal declaradas para él.

    Si no se le especifican unas directrices en concreto que entonces si que las sigue, no sigue las generales.

    Menuda fiesta sería el Quality Score de AdWords si siguiera las directrices generales del robots.txt

    Abrazos.

Responder a inaki Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *