10+1 cosas que deberías saber sobre los archivos robots.txt e indexación SEO |
Do not speak Spanish?.
Hace tiempo que no comentamos muchas cosas de posicionamiento web en buscadores por aquí. Así que a fin de que no se diga hoy he sacado de borradores una serie de apuntes sobre uno de los básicos del posicionamiento SEO del que la mayoría de gente desconoce detalles muy importantes: El fichero robots.txt, uno de los básicos de la indexación posicionamiento SEO. Robots.txt es un fichero destinado a señalar a los motores de búsqueda 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 ahi a recoger información o bien 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 por cien ).
El fichero robots.txt es uno de esos temas técnicos del que todo posicionamiento web ha de saber lo bastante para manipularlo con éxito. Por esta razón exactamente 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 archivos 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 queremos. En el mejor de los casos eso provocará que prosigan visitando URLs en las que no querríamos que perdiesen el tiempo en el peor será todo lo contrario: no indexarán contenidos que realmente 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 y cada una de 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í pues, os dejo 10 conceptos sobre estos archivos que hay que tomar 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.
Un Robots.txt es sencillo...
1. Comenzamos declarando en una línea el usuario-agent (nombre del sistema que está navegando o bien rastreando el site) al que deseamos afectar y tras esta indicaremos los accesos tolerados y prohibidos.
- Muy frecuentemente declararemos un accceso a todos (usuario-agent:*) y en ocsaiones nos referiremos a algún robot o bien crawler particularmente (usuario-agent:googlebot).
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 y cada una de las URLs del site ("Allow:*") pero si bien esto es ya así desde el comienzo bastante gente decide dejarlo declarado de forma explicita y seguir prohibiendo desde ahí. De ahí que incluso siendo superfluo no debe semejarnos raro ver un robots que empieza por "Allow: *".
3. Por ultimo, podemos señalar nuestro sitemap.xml si lo queremos (sitemap: sitemap.xml). Esto para Google carece de importancia si administramos adecuadamente Google Search Console, aunque puede asistir 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 diferentes al nuestro (esto puede ser útil si por ejemplo necesitamos hacer subidas con cambios del fichero cada cierto tiempo y en la web que trabajamos contenido de pagina web de forma tan ágil).
Así un ejemplo que cubra todo lo que acabamos de mentar 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...
Existe mucha confusión con este punto, en parte por el hecho de que la documentación anteriormente (de hecho cuando escribi este artículo yo mismo lo detallé mal) El archivo robots.txt siempre y en todo momento se busca en la ruta "/robots.txt" de tu dominio. El robots.txt afecta al host donde está alojado mas solo a este host preciso. Esto supone que un subdominio no hará caso al robots.txt de su host superior y que http y https utilizan archivos distintos. ¿Por qué etonces vemos sitios donde una configuración bloquea a otra? Lo vamos a ver más adelante pero es sobretodo por temas de hosts redirigidos absolutamente con un 301. O sea, cuando vemos que el robots.txt de afecta también a midominio.com por norma general es pues existe una redirección de "midominio.com/robots.txt" a "/robots.txt" y por ende se lee el mimso archivo 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:
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 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.
Lo ideal es que un robots.txt esté codificado en UTF-8 para no tener problemas de lectura. Mas la verdad es que los archivos de texto pueden tener múltiples codificaciones y si por servirnos de un ejemplo creas el fichero desde tu bloc de notas de windows probablemente su formato sea otro. Es recomendable emplear editores de texto plano más profesionales (como por ejemplo, por daros una opción sencilla y pontente notepad++ ) donde entre otras muchas cosas se os deje elegir la codificación del archivo.
Aun así Google nos dice que puede leer otras codificaciones, lo que ocurre en estos casos no es tanto que el pueda o bien no, sino 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 acaban en que el fichero no funcione o no se lea de forma conveniente.
Aun dentro de los archivos UTF-8 hay una cosa en estos ficheros 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 archivos y ya no solo por no acercanos a los 500MB sino más bien porque son ficheros muy consultados por los robots y a mayor tamaño más desgaste de proceso y red en el servidor.
Un aviso: No es exactamente lo mismo un <meta name="robots" content="noindex" /> que un disallow en el robots. Significan cosas plenamente diferentes.
Todo esto como es lógico con matices... Con el tiempo un Disallow provocará la desindexación si no hay links externos hacia esa página y por contra un meta-robots a noindex terminará provocando menor rastreo de esa url que total Google no puede trabajar.
Un aviso: No es exactamente lo mismo un <meta name="robots" content="noindex" /> que un disallow en el robots. Significan cosas plenamente distintas.
Todo esto como es lógico con matices... A la larga un Disallow provocará la desindexación si no hay enlaces 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.
No tiene sentido un disallow+noindex o un disallow+canonical o bien disallow+rel-next/prev o bien 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 trescientos uno) 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 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 poner un ejemplo un noindex y un canonical al unísono, se puede mas es un tanto singular y realmente su interpretación es muy ambigua. Y dados estos casos equívocos sabemos que Google decide ignorar todas y cada una de las señales del HTML (por no fiarse de ellas) con lo que si bien en teoría si se puedan hacer estas cosas no os recomendaría ninguna salvo la de "noindex,follow" e inclusive esa, de manera cuidadosa (puesto que un noindex se rastrea poco, así que ponerle un follow acaba siendo un poco contradictorio).
La vamos a repasar porque 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.
Esto tiene múltiples implicaciones:
disallow: /blog/ allow: /blog/ dólares americanos allow: /blog/categoria-1
Si rastreará tanto la home como la categoria-1 del weblog, mas no el resto por el hecho de que todo el resto de URLs siguen prohibidas
disallow: /blog-corporativo/ allow: /*.html
No conseguirá que se rastreen los archivos ".html" en /blog-corporativo puesto que es más larga la expresión de blog-corporativo y por ende 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.
Esto tiene múltiples implicaciones:
disallow: /blog/ allow: /blog/$ allow: /blog/categoria-1
Si rastreará tanto la home como la categoría-1 del blog, mas no el resto pues todo el resto de URLs prosiguen prohibidas
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" dentro de /blog-corporativo dado que es más larga la expresión de blog-corporativo y por 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.
Y esto es así... No hay nada más potente y duradero que una sentencia de robots.txt...
Por ejemplo el conocido "Crawl-delay" se ignora. En teoría debería indicar 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 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 múltiples proyectos o muchos sites es mejor incluir notas de la version subida como comentario.:
Ya hemos dicho que el fichero robots.txt siempre se busca en la senda "/robots.txt" de tu dominio. Y que si no lo encuentra, podrá ir a procurarlo a un nivel superior de dominio (si existe). Por ejemplo si no lo halla en /robots.txt irá a buscarlo a dominio.com/robots.txt
Pero veamos ahora que pasa cuando lo pide. Un servidor lo que hará cuando reciba la petición del archivo robots.txt es devolver un código de contestación diciéndole a las arañas si lo está encontrando o bien no.
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 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 cascada 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 nunca se redirija mas esto en la mayor parte de los casos no se hace así.
El cómo actúa Google si este fallo 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 este motivo, 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 error quinientos tres y así parar la indexación completa del site hasta 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.
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 verdaderamente administramos nuestro fichero 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 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 fallos 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í.
El cómo actúa Google si este fallo 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 página web. Por esta razón, cuando hay fallos técnicos en una web, y se están solucionando en ese día, es preferible obligar al fichero robots.txt a que devuelva error quinientos tres y así parar la indexación completa del site hasta 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 quinientos tres es totalmetne temporal.
Google recomeinda no Bloquear archivos 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. 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 bien que lugar ocupan en el diseño y lo visibles que son los contenidos para los usuarios. Así que Google nos solicita que le dejemos acceder a esto y así valorar la web al completo.
Si no les damos acceso a estos archivos es cuando comienza a diseño de paginas web para negocios madrid y en la práctica la autoridad/calidad que percibe de nuestra web reduce.
Esto no quiere decir que no podamos jamás bloquearle un archivo JS (todos sabemos para qué 😈) pero si que hay que eludir este bloqueo a nivel general.
Los contenidos 400 (páginas no encontradas, o cuatrocientos uno que acostumbran a 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 consiguiente 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, incluso las de destino de los formularios de Google y una vez las tengamos presentes:
No cuento este punto entre los diez conceptos puesto que 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 incorporar para todos ( y en su versión más fácil no está recomendado y no sabemos realmente si marcha).
gestion de redes sociales precios españa de hallar 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 charlen de la directiva "noindex:" dentro del archivo robots.txt
Esta indicación viene a decirnos que podemos crear sentencias noindex en el archivo robots con la misma nomenclatura.
Por ejemplo:
Vendria a decirle al robot que puede navegar 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 excelente que nos dejasen hacer esto puesto que como comentaba 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 yo creo que carece de sentido hacerlo. Así que no disfrutamos de esta posibilidad...
En su sitio tenemos otra forma más difícil mas efectiva a nivel de servidor que podemos emplear. Google tiene documentado el uso de directivas robots (index/noindex,follow/nofollow) con el uso de "x-robots-tag" en las cabeceras.tan solo debemos 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 fichero que gestione estas cabeceras en nuestro servidor. Podemos hacer esto con el lenguaje de programación de nuestro CMS (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 fichero 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:
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 amigables y redirecciones:
Pero no quiero estenderme demasaido con este sistema, si deseas leer más sobre como ponerlo en práctica te recomiendo que visites otro post de este mismo weblog donde detallo otras. En la última de ellas se explica al detalle este sistema.
No se si os habrá pasado como a mi conforme he ido descubriendo con los años todo lo que os he expuesto en este blog post, pero lo cierto es que como todo en el posicionamiento en buscadores, te percatas de que nunca sabes lo bastante de todo. Me pareció interesante compilar todo esto pues prosigo 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 ciertos y a otros haberles descubierto algún detalle que ignorasen.
Como siempre y en todo momento os espero en los comentarios o bien por twitter.
¿Te gustó este blog post? Puedes proseguir sus comentarios a través de, o bien realizardesde tu weblog.
Комментировать | « Пред. запись — К дневнику — След. запись » | Страницы: [1] [Новые] |