Do not speak Spanish?.

Hace tiempo que no comentamos muchas cosas de posicionamiento SEO por aquí. Así que a fin de que no se diga el día de hoy he sacado de borradores una serie de apuntes sobre uno de los básicos del posicionamiento web en buscadores del que la mayoría de gente ignora detalles muy importantes: El fichero robots.txt, uno de los básicos de la indexación posicionamiento SEO. Robots.txt es un archivo destinado a apuntar a los buscadores web 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 debe ir ahí a recoger información o si al contrario el dueño del site prefiere que no entre. En definitiva son solo indicaciones que cualquier robot puede saltarse si quiere, mas a las que el robot de google hace bastante caso (que tampoco al cien por ciento ).

El fichero robots.txt es uno de esos temas técnicos del que todo posicionamiento web en buscadores ha de saber lo suficiente como para manipularlo con éxito. Por esta razón el mismo Google en su soporte nos indica como podemos crear el nuestro:.

Se nos da información muy directa y fácil de digerir. La redacción de estos ficheros es muy sencilla aunque cualquier fallo, por mínimo que sea, podría provocar que las arañas no entraran en las páginas que nosotros queremos. 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 deseamos que aparezcan en el buscador. Es el tipíco aspecto esencial que de fácil que es la gente no se toma suficientemente de verdad, y ahí esta el problema: la documentación de Google está bien si bien no cubre todas y cada una de las pecularidades sobre como se marcha a interpretar dicho archivo y si nos quedamos solo ahí podemos cometer errores que lamentaremos en el futuro.

Así puesto que, os dejo diez conceptos sobre estos archivos que hay que tener en consideración y asimilar. Desde lo más básico hasta consejos que solo en webs complejas o bien con mucho detalle de optimización del crawl budget vamos a poder aplicar.

Previo: El formato general del robots.txt

Un Robots.txt es sencillo...

1. Empezamos declarando en una línea el usuario-agent (nombre del sistema que está navegando o bien rastreando el site) al que queremos afectar y tras esta indicaremos los accesos permitidos y prohibidos.

- En muchas ocasiones declararemos un accceso a todos (usuario-agent:*) y en ocsaiones nos referiremos a algún robot o bien crawler particularmente (user-agent:googlebot).

2. Después usamos directivas "Allow: expresion" y "Disallow: expresion" para apuntar si damos acceso o bien lo eliminamos. Por defecto podríamos decir que un robot tiene acceso a todas las URLs del site ("Allow:*") pero si bien esto es ya así desde el principio mucha gente decide dejarlo declarado de forma explicita y continuar prohibiendo a partir de ahí. De ahí que incluso siendo superfluo no debe semejarnos raro ver un robots que empieza por "Allow: *".

3. Por ultimo, podemos apuntar nuestro sitemap.xml si lo queremos (sitemap: sitemap.xml). Esto para Google carece de importancia si administramos adecuadamente Google Search Console, si bien puede asistir a otros robots a leerlo así que mal no va a hacernos declararlo.

Una cosa curisosa de este fichero sitemap es que puede estar alojado aun en otros dominios distintos al nuestro (esto puede ser útil si por poner un 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 caso que cubra todo lo que terminamos de mencionar sería el siguiente:

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

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

Existe mucha confusión con este punto, en parte por el hecho de que la documentación en el pasado (en verdad cuando escribi este post mismo lo detallé mal) El archivo robots.txt siempre y en toda circunstancia 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 utilizan ficheros diferentes. ¿Por qué etonces vemos sitios donde una configuración bloquea a otra? Lo vamos a ver más adelante mas es sobretodo por temas de hosts redirigidos absolutamente con un trescientos uno. O sea, cuando vemos que el robots.txt de afecta también a midominio.com generalmente es por el hecho de que existe una redirección de "midominio.com/robots.txt" a "/robots.txt" y por consiguiente se lee el mimso archivo para ambos hosts. Lo mismo pasa con http y https, si uno esta redirigido al otro se aplica exactamente el mismo archivo a los dos.

Pero en definiva vendría a ser esto:

Así pues:

• midominio.com/robots.txt>>NO afecta a y a weblog.midominio.com


• dev.midominio/robots.txt>>Afecta a dev.midominio.com pero no a weblog.dev.midominio.com


• /robots.txt>>Afecta a mas no a blog. y solo afectará a midominio.com si hay un redirect de midominio.com/robots.txt a /robots.txt

Además también hay que quitar la creencia de que el robots.txt actúa como muchos piensan sobre carpetas específicas 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 por el hecho de que hacerle caso. Algunos CMS se empeñan en añadirlo mas esto no es parte de la definición oficial del fichero robots.txt.

2. El tipo y tamaño del 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 inconvenientes de lectura. Pero la verdad 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 poner un ejemplo, por daros una opción sencilla y pontente notepad++ ) donde entre otras muchas cosas se os deje elegir la codificación del fichero.

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

Aun dentro de los archivos UTF-8 hay una cosa en estos ficheros que se llama. agencia seo sem barcelona idóneo es que los archivos simples no tengan BOM pero Google es capaz de leer el robots.txt con un BOM inicial (y solo uno y solo al comienzo) 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 debemos ahorrar estos ficheros y ya no solo por no acercanos a los 500MB sino pues son ficheros 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 absolutamente distintas.

• Disallow prohibe a las arañas leer el HTML de la página. Mas puede leer la URL y aparecer esta en búsquedas con información a partir de otras páginas y enlaces de internet. Además con un disallow no suprimimos lo que 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 sostiene un tiempo en el buscador. Claramente no es una forma rápida de desindexar, va más encaminado a temas de rastreo y a acciones a medio o bien 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 prosiguen perdiendo el tiempo con esa página mas los resultados desaparecen antes del buscador

Todo esto naturalmente con matices... A la larga un Disallow provocará la desindexación si no hay links externos cara 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.

Un aviso: No es lo mismo un <meta name="robots" content="noindex" /> que un disallow en el robots. Significan cosas completamente 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 enlaces 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 sostiene un tiempo en el buscador. Claramente 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 mas prohíbe que su resultado salga en Google. Es el efecto contrario: las arañas prosiguen perdiendo el tiempo con esa página mas los resultados desaparecen ya antes del buscador

Todo esto evidentemente con matices... Con el tiempo 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 bien 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 si bien en menor medida con las redirecciones. Si yo creo una redirección trescientos uno de una URL vieja a una nueva y al tiempo bloqueo la vieja por robots.txt Google no debería enterarse de que he creado un trescientos uno (porque no debería acceder a la URL con trescientos uno) así que el traspaso de autoridad no se realizará de forma eficiente. En la práctica en ocasiones si se da cuenta de la redirección pero en 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 al unísono, se puede pero es un tanto especial y realmente su interpretación es muy equívoca. Y dados estos casos equívocos sabemos que Google decide ignorar todas las señales del HTML (por no fiarse de ellas) con lo que aunque en teoría si se puedan hacer estas cosas no os recomendaría ninguna salvo la de "noindex,follow" e incluso esa, cuidadosamente (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 específica y sus reglas de lectura no son tan intuitivas como podría parecer.

La repasaremos por el hecho de que llegados al detalle tiene miga y la gente comete muchos fallos.

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

• Si las urls no empiezan 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. Reglas tipo "disallow: .doc" no marchan pues falta el principio de la URL. De echo entenderá que la url a prohibir es urls que comiencen por "/.doc".
  

  Esto tiene múltiples implicaciones:

  
  
  
  
  • La solución cuando lo que deseamos es definir unas partes del final o bien fragmentos de las URLs es redactarlas como sigue: "/*-producto" o "/*.doc" señalando que comienza por cualquier cosa y luego si contiene ese rastro que queremos advertir.
  
  
  • Si pensamos en declarar carpetitas de la web todo se vuelve más fáficl puesto que Google entenderá que se hace referencia a esa dirección y a todos y cada uno de los achivos internos que contengan esas carpetitas. Esto es, al apuntar "/mi-carpeta" como disallow, también prohíbo el acceso a "/mi-carpeta/mi-archivo".
  
  
  
  


• Las indicaciones allow/disallow no son sensibles a mayúsculas y minúsculas, pero las URLs que se definen en ellas si lo son. Esto es puedo escribir "disallow:" o bien "Disallow:" o bien "DISALLOW:" y es exactamente lo mismo mas "/mi-pagina" y "/MI-PAGINA" no son la misma URL.


• Se nos permite usar los comodines * y $ para llenar las URLs:
  
  
  
  • "*" equivale a cualquier conjunto de caracteres. (el equivalente en expresiones regulares a ".*")
    
    
    
    • "disallow: /blog*" bloqueará la carpeta /blog/ pero también cualquier archivo o carpetita cuya url empiece por "/blog", por poner un ejemplo "/blogueria.html"
    
    
    • "disallow: /*.doc" si que funciona pues contemplamos cualquier cáracter al principio y aguardamos que acabe por .doc
    
    
    
    
  
  
  • "$ " Nos deja 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" mas no la carpetita "/blog/"
    
    
    
    
  
  
  • Se nos permite sobreescribir reglas por ejemplo permitir el rastreo de una parte de una regla ya prohibida o bien prohibirlo luego de nuevo para una regla que lo permitía.
    

    disallow: /blog/ allow: /blog/ dólares americanos  allow: /blog/categoria-1

    
    
  
  

  Si rastreará tanto la home como la categoria-1 del weblog, pero no el resto pues todo el resto de URLs prosiguen prohibidas

  
  
  
  


• Por último, las reglas
  no se aplican por orden de lecturasino 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 ficheros ".html" dentro de /blog-corporativo dado que es más larga la expresión de blog-corporativo y por consiguiente 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, mas también así de ilógico.

  
  

Esto tiene varias implicaciones:

• La solución cuando lo que deseamos es acotar partes del final o bien fragmentos de las URLs es redactarlas como sigue: "/*-producto" o "/*.doc" indicando que empieza por cualquier cosa y luego si contiene ese rastro que deseamos detectar.


• Si pensamos en declarar carpetitas de la página 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 carpetitas. Es decir, al señalar "/mi-carpeta" como disallow, también prohíbo el acceso a "/mi-carpeta/mi-archivo".

• "*" equivale a cualquier conjunto de caracteres. (el equivalente en expresiones regulares a ".*")
  
  
  
  • "disallow: /blog*" bloqueará la carpeta /blog/ pero también cualquier fichero o carpeta cuya url comience por "/blog", por servirnos de un ejemplo "/blogueria.html"
  
  
  • "disallow: /*.doc" si que marcha puesto que contemplamos cualquier cáracter al principio y aguardamos que acabe por .doc
  
  
  
  


• "$ " Nos permite forzar que ese sea el final de la URL, sin permitir nada tras ella:
  
  
  
  • "disallow: /categoria/ dólares americanos " 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 fichero "/blog" pero no la carpetita "/blog/"
  
  
  
  


• Se nos permite sobrescribir reglas por servirnos de un ejemplo permitir el rastreo de parte de una regla ya prohibida o bien prohibirlo luego de nuevo para una regla que lo permitía.
  

  disallow: /blog/ allow: /blog/ dólares americanos  allow: /blog/categoria-1

  
  



Si rastreará tanto la home como la categoria-1 del blog, mas no el resto pues todo el resto de URLs siguen prohibidas

• "disallow: /blog*" bloqueará la carpetita /blog/ pero también cualquier archivo o carpetita cuya url empiece por "/blog", por poner un ejemplo "/blogueria.html"


• "disallow: /*.doc" si que marcha pues contemplamos cualquier cáracter al comienzo y aguardamos que acabe por .doc

• "disallow: /categoria/ dólares americanos " solo bloqueará el acceso a la página de categoría "/categoria/" mas no a ficheros internos como "/categorias/post"


• "disallow: /blog$ " solo bloqueará el archivo "/blog" mas no la carpetita "/blog/"

Si rastreará tanto la home como la categoría-1 del blog, pero no el resto pues todo el resto de URLs prosiguen prohibidas

No conseguirá que se rastreen los ficheros ".html" en /blog-corporativo puesto 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á:

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 igualmente pontentes.

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

• En Google Search Console puedes emplear la herramienta de borrar contenido y estas URLs se borrarán. Pero Google aproximadamente a los noventa días olvidará que le habías pedido borrar la URL y si con lo que sea vuelve a encontrarla la volverá a indexar. Con lo que sirve para eliminar errores puntuales mas no para suprimir URLs que van a proseguir ahí.


• En Google Search Console puedes emplear la herramienta de parámetros de URL para señalar 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 asistir un tanto con los listados. Lo que seguro que no evitará esta función es que los robots entren en tal URL

7. Todas y cada una de 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 apuntar tiempo entre solicitudes de robots pero no le hace caso así que podemos olvidarnos de esta sentencia por lo menos para Google (otros rastreadores si que le hacen caso).

Todas las directivas inventadas por terceros también se pasan por alto.

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

8. ¿Que pasa cuando Google no puede acceder o bien halla 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 halla, podrá ir a procurarlo a un nivel superior de dominio (si existe). Por servirnos de un ejemplo si no lo halla en /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". Quiere decir que el archivo SI existe. Entonces lo leerá y aplicará sus normas. Si está vacío o bien googlebot no tiene directrices "disallow" entenderá que tiene acceso a todo y entrará hasta la cocina de la web


• Códigos "4xx" (cuatrocientos cuatro, cuatrocientos uno, cuatrocientos tres, etc. Quiere decir que el archivo no existe o bien no está abierto al público. En un caso así google lo entenderá como un archivo vacío y dará acceso a todo tal y como si no contuviera 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, aun si hay un cambio de carpetita, la URL está en otro dominio o bien si la URL no tiene el nombre "robots.txt".
  

  Conocer este detalle puede ser útil para administrar robots.txt programados en ciertos sistemas. Podemos tratar la URL de /robots.txt solo como una redirección a donde verdaderamente gestionamos nuestro fichero robots.txt.

  
  

  Sin embargo también puede suponer un problema en migraciones mal efectuadas de un dominio a otro o bien de http a https. En estos casos podemos toparnos 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 jamás se redirija pero esto en la mayoría de los casos no se hace así.

  
  


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

  El cómo actúa Google si este fallo persiste en el tiempo no lo sabemos precisamente pero por el motivo que sea suele llevar a perdidas de autoridad y a que se intente reindexar la web. Por esta razón, cuando hay fallos técnicos en una web, y se están solventando 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 inconveniente. Esto es mucho mejor que bloquear el rastreo puesto que lo segundo tiene implicaciones más severas y un simple quinientos tres es totalmetne temporal.

  
  


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

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

Sin embargo también puede suponer un problema en migraciones mal efectuadas de un dominio a otro o bien 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 catarata de detección de fallos y pérdida de tiempos de rastreo. Por general la recomendación debería ser que todos los sites tengan su /robots.txt y que jamás se redirija mas esto en la mayor parte de los casos no se hace así.

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

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

Google recomeinda no Bloquear ficheros CSS y JS. Antigüamente eran archivos que se solían bloquear por el hecho de que no le servian a las arañas para nada. Mas 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 bien pequeño, el tono de fondo o bien que lugar ocupan en el diseño y lo perceptibles 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 mandarnos notificaciones y en la práctica la autoridad/calidad que percibe de nuestra web disminuye.

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

10. Google entra en contenidos cuatrocientos mas no si se le bloquea

Los contenidos cuatrocientos (páginas no encontradas, o 401 que suelen estar bajo login, etc.) si que son accedidos por las arañas. Google lo procura y se halla al visitar las páginas con que estas no responden y por ende 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 acostumbra a ser preferible bloquearles el acceso de forma directa. Pensemos en cualquier URL, aun las de destino de los formularios de Google y una vez las tengamos presentes:

• 1. Evitemos que el HTML muestre links hacia ellas


• 2. Con independencia de si este acceso existe o bien no, marquemolas con con disallow en el robots

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

No cuento este punto entre los diez 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 incorporar para todos ( y en su versión más sencilla no está recomendado y no sabemos realmente si marcha).

Hablamos de encontrar alguna forma no para prohibir el rastreo sino más bien 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 podemos crear sentencias noindex en el fichero robots con la misma nomenclatura.

Por ejemplo:

posicionar tienda online por la categoría-1 y rastrearla mas 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 ya antes bloquear una URL no implica desindexarla y así tendríamos un control total sobre todo esto. Sin embargo, y a pesar de que podréis ver como muchos SEOs lo mientan e inclusive, Google ya nos ha dicho quey mientras que lo prosigan diciendo creo que carece de sentido hacerlo. Así que no gozamos de esta posibilidad...

En su sitio tenemos otra forma más complicada pero eficaz a nivel de servidor que podemos utilizar. Google tiene documentado el empleo de directivas robots (index/noindex,follow/nofollow) con el empleo de "x-robots-tag" en las cabeceras.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 Content Management System (PHP, Java, .Net, etcétera) o directametne en la configuración del servidor. En ella gracias a los ficheros .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 fichero .htconfig:

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

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

Pero no deseo estenderme demasaido con este sistema, si deseas leer más sobre como ponerlo en práctica te invito a que visites otro artículo de este mismo weblog donde detallo otras. 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 artículo, mas la verdad es que como todo en el SEO, te percatas de que nunca sabes lo suficiente de todo. Me pareció interesante compilar todo esto por el hecho de que prosigo viendo con el tiempo que los inconvenientes que existen en muchos sites debido a no entender bien los archivos robots.txt siguen ahí año tras año y absolutamente nadie habla de ellos demasiado.

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

Como siempre y en toda circunstancia os espero en los comentarios o bien por twitter.

¿Te gustó este post? Puedes seguir sus comentarios mediante, o bien realizardesde tu blog.