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

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

15 Jul 2020 in

Tabla de contenido

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

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

Se nos da información muy directa y fácil de asimilar. La redacción de estos archivos es muy sencilla si bien 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 caso eso provocará que sigan visitando URLs en las que no querríamos que perdieran 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 suficientemente en serio, y ahí esta el problema: la documentación de Google está bien aunque no cubre todas las pecularidades sobre como se marcha a interpretar dicho fichero y si nos quedamos solo ahí podemos cometer fallos que lamentaremos en el futuro.

Así puesto que, os dejo diez conceptos sobre estos ficheros que hay que tomar en consideración 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 vamos a poder aplicar.

Back to top

1) 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 rastreando el site) al que queremos afectar y tras esta indicaremos los accesos tolerados y prohibidos.
- En muchas ocasiones declararemos un accceso a todos (usuario-agent:*) y en ocsaiones nos referiremos a algún robot o crawler particularmente (user-agent:googlebot).

2. Después utilizamos 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:*") mas si bien esto es ya así desde el comienzo mucha gente decide dejarlo declarado de forma explicita y proseguir prohibiendo a partir de ahí. Por eso aun siendo innecesario no debe parecernos extraño 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 relevancia si administramos adecuadamente Google Search Console, aunque puede ayudar a otros robots a leerlo así que mal no va a hacernos declararlo.

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

Así un caso que cubra todo cuanto 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 mundo tiene tan dominados...

Back to top

2) 1. Donde pones tu fichero 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 anteriormente (de hecho cuando escribi este blog post mismo lo detallé mal) El archivo robots.txt siempre se busca en la senda "/robots.txt" de tu dominio. El robots.txt afecta al host donde está alojado mas 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 emplean ficheros diferentes. ¿Por qué etonces vemos sitios donde una configuración bloquea a otra? Lo veremos más adelante mas es sobretodo por temas de hosts redirigidos completamente con un 301. Es decir, cuando vemos que el robots.txt de afecta también a midominio.com generalmente es pues hay una redirección de "midominio.com/robots.txt" a "/robots.txt" y por lo tanto se lee el mimso fichero para los dos 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 y a blog.midominio.com
  • dev.midominio/robots.txt>>Afecta a dev.midominio.com mas no a weblog.dev.midominio.com
  • /robots.txt>>Afecta a mas no a weblog. y solo afectará a midominio.com si hay un redirect de midominio.com/robots.txt a /robots.txt

Además también hay que eliminar la creencia de que el robots.txt actúa como muchos piensan sobre carpetitas 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 procurar leerlo ni tiene porque hacerle caso. Algunos Content Management System se empeñan en añadirlo mas esto no forma parte de la definición oficial del archivo robots.txt.

Back to top

3) 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. Mas la verdad es que los archivos de texto pueden tener múltiples codificaciones y si por ejemplo creas el fichero desde tu bloc de notas de windows probablemente su formato sea otro. Es conveniente utilizar editores de texto plano más profesionales (como por ejemplo, por daros una opción fácil y pontente notepad++ ) donde entre otras muchas cosas se os deje escoger la codificación del fichero.

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 producirlo 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 fichero no funcione o bien no se lea de forma adecuada.

Aun en los ficheros UTF-ocho hay una cosa en estos archivos que tiene por nombre. Lo ideal es que los ficheros simples no tengan BOM mas Google es capaz de leer el robots.txt con un BOM inicial (y solo uno y solo al comienzo) así que si vuestro fichero 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 ahorrar estos ficheros y ya no solo por no acercanos a los 500MB sino más bien pues son ficheros muy consultados por los robots y a mayor tamaño más desgaste de proceso y red en el servidor.

Back to top

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

Un aviso: No es exactamente lo mismo un <meta name="robots" content="noindex" /> que un disallow en el robots. Significan cosas plenamente diferentes.

  • 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 suprimimos 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 dirigido 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 mas prohíbe que su resultado salga en Google. Es el efecto contrario: las arañas siguen perdiendo el tiempo con esa página mas los resultados desaparecen antes del buscador

Todo esto como es lógico con matices... A la larga un Disallow provocará la desindexación si no hay enlaces externos hacia esa página y al 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 diferentes.

  • 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 suprimimos 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 dirigido 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 prosiguen perdiendo el tiempo con esa página mas los resultados desaparecen ya antes del buscador

Todo esto por supuesto con matices... A la larga un Disallow provocará la desindexación si no hay enlaces 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.

Back to top

5) 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 bien disallow+rel-next/prev o un disallow+loquesea-en-el-html. Google no va a contemplar este HTML pues le hemos prohibido acceder a el así que ahórrate su etiquetado.

Lo mismo pasa si bien en menor medida con las redirecciones. Si 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 (pues no debería acceder a la URL con 301) así que el traspaso de autoridad no se realizará de forma eficaz. En la práctica a veces si se da cuenta de la redirección pero generalmente 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 poner un ejemplo un noindex y un canonical a la vez, se puede pero es un poco singular y realmente su interpretación es muy ambigua. Y ante estos casos ambiguos sabemos que Google decide ignorar todas y cada una de las señales del HTML (por no fiarse de ellas) por 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, de manera cuidadosa (puesto que un noindex se rastrea poco, así que ponerle un follow termina siendo un poco contradictorio).

Back to top

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

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

Cada línea debe iniciar 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 marchan porque falta el principio de la URL. De echo entenderá que la url a prohibir es urls que empiecen por "/.doc".

    Esto tiene múltiples implicaciones:

    • La solución cuando lo que queremos es delimitar partes del final o bien fragmentos de las URLs es redactarlas como sigue: "/*-producto" o bien "/*.doc" señalando que empieza por cualquier cosa y luego si contiene ese rastro que queremos detectar.
    • Si pensamos en declarar carpetitas de la página 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 carpetas. Es decir, al indicar "/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, mas las URLs que se definen en ellas si lo son. Es decir yo puedo escribir "disallow:" o "Disallow:" o bien "DISALLOW:" y es lo mismo pero "/mi-pagina" y "/MI-PAGINA" no son exactamente la misma URL.
  • Se nos deja emplear los comodines * y dólares americanos para llenar las URLs:
    • "*" equivale a cualquier conjunto de caracteres. (el equivalente en expresiones regulares a ".*")
      • "disallow: /blog*" bloqueará la carpeta /blog/ mas tambien cualquier fichero o carpetita cuya url comience por "/blog", por servirnos de un ejemplo "/blogueria.html"
      • "disallow: /*.doc" si que funciona pues contemplamos cualquier cáracter al principio y aguardamos que acabe por .doc
    • " dólares americanos " 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 ficheros internos como "/categorias/post"
      • "disallow: /blog$ " solo bloqueará el fichero "/blog" pero no la carpetita "/blog/"
    • Se nos permite sobrescribir reglas por poner un ejemplo permitir el rastreo de una parte de una regla ya prohibida o bien prohibirlo entonces nuevamente 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 porque todo el resto de URLs siguen prohibidas

  • Por último, las reglas no se aplican por orden de lecturasino por lo detallas que son.
    La regla 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 puesto 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 múltiples implicaciones:

  • La solución cuando lo que queremos es acotar unas partes del final o bien fragmentos de las URLs es redactarlas como sigue: "/*-producto" o bien "/*.doc" señalando que empieza por cualquier cosa y luego si contiene ese indicio que queremos detectar.
  • Si pensamos en declarar carpetas 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 indicar "/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 carpetita /blog/ pero también cualquier archivo o carpeta cuya url comience por "/blog", por servirnos de un ejemplo "/blogueria.html"
    • "disallow: /*.doc" si que funciona puesto que contemplamos cualquier cáracter al comienzo y aguardamos que acabe por .doc
  • "$ " Nos deja 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/" mas no a ficheros internos como "/categorias/post"
    • "disallow: /blog dólares americanos " solo bloqueará el archivo "/blog" mas no la carpetita "/blog/"
  • Se nos permite sobrescribir reglas por servirnos de un 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/$  allow: /blog/categoria-1
  • Si rastreará tanto la home como la categoria-1 del blog, pero no el resto pues todo el resto de URLs prosiguen prohibidas

  • "disallow: /blog*" bloqueará la carpeta /blog/ mas también cualquier fichero o bien carpetita cuya url comience por "/blog", por poner un ejemplo "/blogueria.html"
  • "disallow: /*.doc" si que funciona pues contemplamos cualquier cáracter al comienzo y esperamos que acabe por .doc
  • "disallow: /categoria/$ " solo bloqueará el acceso a la página de categoría "/categoria/" mas no a archivos internos como "/categorias/post"
  • "disallow: /blog dólares americanos " solo bloqueará el fichero "/blog" mas no la carpetita "/blog/"

Si rastreará tanto la home como la categoría-1 del weblog, mas no el resto porque todo el resto de URLs siguen prohibidas

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

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

Back to top

7) 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. Mas 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 pero no para suprimir URLs que van a continuar ahí.
  • En Google Search Console puedes emplear la herramienta de parámetros de URL para indicar si un contenido aporta cambios en la url o no pero esto no es líder, 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 apuntar que no indexe URLs de campañas y asistir un poco con los listados. Lo que seguro que no evitará esta función es que los robots entren en tal URL
Back to top

8) 7. Todas y cada una de las directivas no contempladas en la deficnición del robots se ignoran.

Por ejemplo el conocido "Crawl-delay" se ignora. En teoría debería apuntar tiempo entre peticiones de robots mas no le hace caso así que podemos olvidarnos de esta sentencia cuando 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 líneas que comienzan por "#" también se ignoran al comprenderse como comentarios. Sin embargo si que cuentan en el tamaño del archivo máximo así que es mejor no pasarse con su uso. Una recomendacion para comentarios: Cuando trabajamos con varios proyectos o bien muchos sites es mejor incluir notas de la version subida como comentario.:

Back to top

9) 8. ¿Que pasa cuando Google no puede acceder o encuentra cosas extrañas al acceder a tu archivo robots?

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

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

  • Código "200". Quiere decir que el fichero SI existe. Entonces lo leerá y aplicará sus reglas. Si está vacío o bien googlebot no tiene indicaciones "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... Significa que el fichero no existe o no está abierto al público. En un caso así google lo entenderá como un fichero 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 en todos los sentidos que el contenido de esta URL a la que redirige robots.txt es el propio robots.txt, incluso si hay un cambio de carpeta, la URL está en otro dominio o bien 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 administramos nuestro fichero robots.txt.

    Sin embargo también puede suponer un inconveniente en migraciones mal realizadas 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 cascada de detección de fallos y pérdida de tiempos de rastreo. Por general la recomendación debería ser que todos y cada uno de los sites tengan su /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 entiende que el dominio está caído y para no molestar para el rastreo del site y solo consultará el fichero quinientos tres hasta el momento en que su error cambie. Parar el rastreo no supone desindexar, salvo que sostengamos así el servidor tanto 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 precisamente mas 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 día, es preferible obligar al archivo robots.txt a que devuelva error 503 y así parar la indexación completa del site hasta el momento en 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 503 es totalmetne temporal.

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

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

Sin embargo también puede suponer un problema en migraciones mal efectuadas de un dominio a otro o de http a https. En estos casos podemos encontrarnos con que al migrar un site devolvemos un 301 cara 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 y cada uno de los sites tengan su /robots.txt y que nunca se redirija mas esto en la mayoría de los casos no se hace así.

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

Back to top

10) 9. El bloqueo de ficheros JS y CSS puede causar inconvenientes e incluso está mal visto por el buscador

Google recomeinda no Bloquear ficheros CSS y JS. Antigüamente eran ficheros que se solían bloquear por el hecho de que 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 bien pequeño, el color de fondo o que sitio 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 ficheros es cuando empieza a enviarnos notificaciones y en la práctica la autoridad/calidad que percibe de nuestra web reduce.

Esto no quiere decir que no podamos nunca bloquearle un archivo JS (todos sabemos para qué &#x1F608;) pero si que hay que evitar este bloqueo a nivel general.

Back to top

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

Los contenidos cuatrocientos (páginas no encontradas, o cuatrocientos uno que suelen estar bajo login, etc.) si que son accedidos por las arañas. Google lo intenta y se halla al visitar las páginas con que estas no responden y por 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 de manera 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. Independientemente de si este acceso existe o bien no, marquemolas con con disallow en el robots
Back to top

12) Bonus. Es posible mandar un noindex desde tu servidor creando una especie de robots.txt mas para noindex y nofollow

No cuento este punto entre los diez conceptos pues realmente 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 fácil no está recomendado y no sabemos verdaderamente si marcha).

Hablamos de localizar 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 ya 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 indicación viene a decirnos que nosotros podemos crear sentencias noindex en el archivo robots con exactamente la misma nomenclatura.

Por ejemplo:

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 ya 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, Google ya nos ha dicho quey mientras que 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 difícil mas efectiva a nivel de servidor que podemos usar. Google tiene documentado el empleo de directivas robots (index/noindex,follow/nofollow) con el uso de "x-robots-tag" en las cabeceras.tan solo debemos mandar 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 una 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 bien directametne en la configuración del servidor. En ella merced 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 página web a través del fichero .htconfig:

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

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

Pero no quiero 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 weblog donde detallo otras. En la última de ellas se explica al detalle este sistema.

Back to top

13) Conclusión

No se si os habrá pasado como a mi a medida que he ido descubriendo con los años todo cuanto os he expuesto en este blog post, mas lo cierto es que como todo en el posicionamiento web en buscadores, te das cuenta de que jamás sabes lo bastante de todo. Me pareció interesante recopilar todo esto pues prosigo viendo con el tiempo que los inconvenientes que existen en muchos sites debido a no entender bien los archivos robots.txt prosiguen 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 todo momento os espero en los comentarios o por twitter.

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

Back to top
Share icon

Solicita información sin compromiso

Políticas de privacidad

De conformidad con lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (LOPD) y su normativa de desarrollo, el responsable del sitio web, CITIFACE MANAGEMENT, S.L., en cumplimiento de lo dispuesto en el art. 5 y 6 de la LOPD, informa a todos los usuarios del sitio web www.citiface.com que faciliten, o vayan a facilitar sus datos personales, que estos serán incorporados a un fichero que se encuentra debidamente inscrito en la Agencia Española de Protección de Datos.

Consentimiento del usuario:
Mediante la marcación de las correspondientes casillas, en los formularios dispuestos en el sitio web para la recogida de datos, los usuarios aceptan expresamente y de forma libre e inequívoca que sus datos personales sean tratados con las finalidades y destinos que se detallarán a continuación.

Finalidad
Los datos que se faciliten a través del portal, se destinarán a la finalidad de responder a su solicitud de información, así como a remitirle información que consideremos que pueda ser de su interés. Incluyendo para ello medios electrónicos (email, sms, etc..). Asimismo, y si usted nos lo indica, le remitiremos a su correo electrónico nuestro boletín electrónico SEO/SEM en el que le trasladaremos recomendaciones y herramientas para la mejora de sus campañas de posicionamiento y pago por clic. Los envíos serán con carácter mensual y podrá dejar de recibirlos en cualquier momento a través del mecanismo establecido en el propio email.

Calidad de datos
Los datos marcados como obligatorios en el formulario que usted cumplimente, son necesarios para la prestación de un servicio óptimo al usuario y dar respuesta a sus requerimientos. En caso de que no sean facilitados todos los datos obligatorios, el prestador no garantiza la prestación de los servicios solicitados.
El usuario será el único responsable, respecto a la veracidad y actualización de los datos aportados a través de los distintos formularios del sitio web

Comunicación de datos a terceros
Sus datos personales no serán cedidos, en ningún caso, a terceras compañías, y que siempre que fuera a realizarse algún tipo de cesión de datos personales, de forma previa, se solicitaría el consentimiento expreso, informado, e inequívoco por parte de los titulares. Ejercicio de derechos ARCO
El prestador garantiza en todo caso al usuario el ejercicio de los derechos de acceso, rectificación, cancelación, información y oposición, en los términos dispuestos en la legislación vigente. Por ello, de conformidad con lo dispuesto en la LOPD, podrá ejercer sus derechos remitiendo una solicitud expresa, junto a una copia de su DNI, a través del correo electrónico: info[at]citiface.com o Calle Farell 3, 1-1. 08014 Barcelona .

Medidas de seguridad
Del mismo modo, el prestador, conforme a lo establecido en el Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la L.O. 15/1999, indica que ha adoptado todas las medidas técnicas y organizativas necesarias para garantizar la seguridad e integridad de los datos de carácter personal que trate, así como para evitar su pérdida, alteración y/o acceso por parte de terceros no autorizados.

Menores de edad
Se prohíbe, expresamente, a los menores de 14 años, facilitar ningún dato a través del presente sitio web, sin contar con el consentimiento y supervisión de sus padres o tutores legales.
Si el prestador tuviera noticia acerca de la infracción de la referida prohibición, procederá a la eliminación de cualquier dato asociado al usuario en cuestión.

Uso de cookies y del fichero de actividad
El prestador por su propia cuenta o la de un tercero contratado para la prestación de servicios de medición, pueden utilizar cookies cuando un usuario navega por el sitio web. Las cookies son ficheros enviados al navegador por medio de un servidor web con la finalidad de registrar las actividades del usuario durante su tiempo de navegación.
Las cookies utilizadas por el sitio web se asocian únicamente con un usuario anónimo y su ordenador, y no proporcionan por sí mismas los datos personales del usuario.
Mediante el uso de las cookies resulta posible que el servidor donde se encuentra la web, reconozca el navegador web utilizado por el usuario con la finalidad de que la navegación sea más sencilla, permitiendo, por ejemplo, el acceso a los usuarios que se hayan registrado previamente, acceder a las áreas, servicios, promociones o concursos reservados exclusivamente a ellos sin tener que registrarse en cada visita. Se utilizan también para medir la audiencia y parámetros del tráfico, controlar el progreso y número de entradas.
Puede Usted rechazar el tratamiento de los datos o la información rechazando el uso de cookies mediante la selección de la configuración apropiada de su navegador, sin embargo, debe Usted saber que si lo hace puede ser que no pueda usar la plena funcionabilidad de este website.
Este sitio web utiliza Google Analytics, un servicio analítico de web prestado por Google, Inc., una compañía de Delaware cuya oficina principal está en 1600 Amphitheatre Parkway, Mountain View (California), CA 94043, Estados Unidos («Google»). Google Analytics utiliza «cookies», que son archivos de texto ubicados en su ordenador, para ayudar al website a analizar el uso que hacen los usuarios del sitio web. La información que genera la cookie acerca de su uso del website (incluyendo su dirección IP) será directamente transmitida y archivada por Google en los servidores de Estados Unidos. Google usará esta información, por cuenta nuestra, con el propósito de seguir la pista de su uso del website, recopilando informes de la actividad del website y prestando otros servicios relacionados con la actividad del website y el uso de Internet.
Google podrá transmitir dicha información a terceros cuando así se lo requiera la legislación, o cuando dichos terceros procesen la información por cuenta de Google. Google no asociará su dirección IP con ningún otro dato del que disponga Google.
Puede Usted rechazar el tratamiento de los datos o la información rechazando el uso de cookies mediante la selección de la configuración apropiada de su navegador, sin embargo, debe Usted saber que si lo hace puede ser que no pueda usar la plena funcionalidad de este website. Al utilizar este website Usted consiente el tratamiento de información acerca de Usted por Google en la forma y para los fines arriba indicados. En todo caso, le informamos que para instar a la cancelación de los posibles tratamientos de datos llevados a cabo por Google, deberá dirigirse a esa compañía, a tal efecto. El prestador no tiene la capacidad técnica ni legal, para proceder al cese en el tratamiento de datos fuera del ámbito delimitado por los ficheros y medios técnicos de su titularidad. Y no se le podrán exigir responsabilidades en este sentido. Para conocer más acerca de las cookies es.wikipedia.org/wiki/Cookie_(informática)

SEMrush

SEMrush

SEMrush

ESTOS EXCLUSIVOS INFORMES GRATUITO REVELAN

7 SECRETOS DE EXPERTOS SEO QUE TE LLEVÁN AL 1#
7 SECRETOS DE EXPERTOS SEO QUE TE LLEVÁN AL 1# EN GOOGLE PARA GANAR 10.000s DE TRÁFICO DE CALIDAD GRATUITO - EN SÓLO 2 MESES
 

Los 7 pasos más poderosos para disparar tu ranking orgánico para ALCANZAR Y MANTENER un impresionante tráfico orgánico es TUYO.

Consigue gratis lo que el 1% de los expertos en SEO venden por miles de euros... y el otro 99% ni siquiera sabe que existe.


OBTEN MI INFORME GRATUITO
5 errores que debes evitar en tu sitio web de Drupal
Ebook - 5 errores que debes evitar en tu sitio web de Drupal (¡podrían costarte miles de euros!)
 

Este Ebook cubre 5 terribles errores que probablemente estés cometiendo ahora mismo con tu sitio web de Drupal.

¡Nº3 TE SORPRENDERÁ! Esta lectura de 10 minutos te ahorrará miles de euros.



OBTEN MI INFORME GRATUITO