Google dice que no restrinjas ficheros css o javascript mediante robots.txt

Publicado por Lino Uruñuela el 28 de octubre del 2014

Google ha anunciado en su blog que había una actualización de las directrices para Webmasters y hay una novedad muy relevante

WMT directrices



Podemos leer en las nuevas directrices cómo claramente hace referencia al hecho de que no debemos restringir por robots.txt ficheros que se usen para el diseño o funcionamiento del site como por ejemplo los ficheros javascript css ya que no podría entender bien el contenido y bla bla bla.

     ANTES                                
             AHORA
   diferencias diferencias


Pero si nos fijamos bien vemos que no lo hace por mejorar su algoritmo de ordenación, es un esfuerzo más para ser capaz de distinguir los sites que más probablemente satisfagan a sus usuarios, y esto pasa por tener en cuenta el dispositivo desde donde el usuario de Google realiza la búsqueda.


En el anterior post que publicaron, donde dan a entender que si detectan elementos flash o algo que no podrá ser reproducido por los usuarios desde dispositivos móviles, les avisarán desde las serps de que el contenido no es compatible con su dispositivo para que no pierda el tiempo y se frustre.

Google antiflash


El contenido que no se pueda reproducir en el móvil o en la tablet donde acaba de realizar la búsqueda el usuario, es difícil que resuelva la necesidad del mismo y posiblemente sea mejor advertírle antes de que entre en valde desde un dispositivo móvil.

¿Por qué no quiere que restrinjamos esos ficheros?

Yo siempre he sido de la opinión de que cuanto menos sepa Google lo que hago para adecuar las necesidades SEO a los distintos escenarios, y es que muchas veces la usabilidad y funcionalidades visuales que introducimos en algunos elementos del site no son conmpatibles con el SEO, o mejor dicho, no son los idóneos pero seguro que le buscaremos las vueltas para que satisfaga nuestras necesidades.


Pongamos por ejemplo el último artículo escrito en este blog, donde mostraba una manera de optimizar determinados listados con un diseño en contra de los requisitos SEO, recordemos;

  • El problema venía de que el texto de los enlaces hacia las fichas de producto eran inútiles para SEO, ya que el texto de enlace no es nada relevante para búsquedas que hagan los clientes potenciales en Google. Las opciones que teníamos eran o bien le pegábamos una patada a la usabilidad y satisfacción de nuestro usuario si pusiéramos  enlaces con un texto que fuese mediánamente útil para SEO (un link de texto "gana" al alt de la imagen aunque ésta esté enlazada, si hay enlace de texto a esa misma URL y otro enlace de imagen, el alt de la imagen lo ignorará para ese link).

  • Para solucionarlo nos inventamos un método donde "camuflamos" los enlaces de texto al crawler para que tenga en cuenta el alt de las imágenes como texto del enlace, de esta forma sí podemos poner nuestras keywords potenciales en los enlaces sin pegarle una patada al manual de primer curso de usabilidad y que además, los enlaces, sean con el texto que nosotros como SEOs queremos, es decir, KW potenciales.

  • Una de las cosas que dijimos es que era bueno camuflar las URLS para que Google no se ponga a rastrear por si mismo y valore eso como un enlace, sino que fuésemos nosotros quienes lo "guiaramos".

  • El otro punto que comentamos fue el restringir ell fichero que ejecutaba la función de encriptación de url para que Googe no tuviese acceso y no comience a rastrear cosas que no queremos, o mal optimizadas, a parte de que puede volverse loco en mis funciones.

Es verdad que hacemos cosas para despistar a Google en según que cosas, pero creo que por ejemplo el ejemplo que pusimos el otro día no es una técnica black hat SEO, y ni mucho menos agresiva. Lo único que hacemos es darle a Google los enlaces internos lo mejor optimizados posible, y a la vez darle al usuario una experiencia de navegación digna del 2014.... era fácil hacer las dos cosas a la vez.



Pero parece ser que a Google no le gusta esto, y como vemos, ha modificado sus directrices para persuadirnos a que no restinjamos este tipo de ficheros. La verdad es que tiene sentido y no creo que sea un movimiento contra los SEOs. Creo que simplemente  está renderizando cada url para ver cómo se vería por los usuarios.

 

Google no dice que dejará de mostrar esos resultados, tampoco se podría arriesgar a que aunque haya un elemento en flash no haya información muy relevante para el uysuario y es mejor , simplemente, avisarle antes de no mostrarle ese resultado.


Entonces, ¿que hacemos con los ficheros de javascript o css que tenemos restringidos por robots.txt? ¿abrimos su indexación? ¿lo dejamos como lo tenemos?

Mi recomendación es que mientras no sepamos más información y no estemos seguros de si va a repercutir, cuánto y de que manera, hagamos lo que nuestro DiosGoogle nos comenta no vaya a ser que el impacto sea mayor del previsto.


Ahora es tiempo de estrujarse un poco el coco y pensar en maneras de analizar cuánto impacto tiene este tipo de acciones, y con que tipo de contenido. Habrá que darle una vueltita más de tuerca a nuestro código para volver a "camuflar" esos links de una una u otra manera. Creo que en muchos casos realmente hay que hacerlo (poniendo el ejemplo del anterior post) y se ha de conseguir que las fichas de producto (en este caso camsetas) estén enlazadas con un texto potencial, a los diseñadores no les va a hacer ninguna gracia, y es que detallitos como este que hemos comentado para listados con imágenes te pueden hacer subir posiciones por muchas KW, medium tail y long tail. Si una buena parte de los ingresos de un site basado el cual está basado en listados mandará a tomar por saco la usabilidad y hará lo necesario para optmizar su site


¿Hay algo que joda más a un SEO saber cómo optimizar bien el linking interno y ver que no puede hacer sin cargarse la usabilidad, conversión e ingresos del negocio por una noticia así?

Ya tenemos reto, y nos toca pensar en otras alternativas, seguro que pronto nos vienen a la cabeza y comenzamos a testar.


 

 


@abiertogmhace Hace más de 5 años y 127 días

Un mes después, creo que la peor consecuencia son los errores. Las páginas con plugins o funciones más o menos sencillas que cambiaban la información de la pantalla con javascript y Ajax se han convertido en errores de rastreo cuando Google ha intentado interpretarlos. Es cierto que depende de cómo esté programado, pero no dejará de afectar a una gran cantidad de páginas.
Por no hablar de la cantidad de páginas cuyo primer contenido visible ha pasado a ser el mensaje de Cookies jeje


Últimos posts

Últimos comentarios


Lino

@errioxa probando desde comentarios del site :)
Post: El valor de los logs para el SEO

Lino

@Santy Jordi y Sergio muchas gracias! Irá mejorando, pero poco a poco :)
Post: Informes y gráficas usando la API de Google Search Console

sergio

Bravo! Gracias por compartir.
Post: Informes y gráficas usando la API de Google Search Console

Santy

Gracias Lino, muy útil para el día a día
Post: Informes y gráficas usando la API de Google Search Console

Jordi

Buenas tardes Lino, Felicidades por la herramienta, me parece algo espectacular y rápido de utilizar. Espero con muchas ganas ver las nue
Post: Informes y gráficas usando la API de Google Search Console

Joan marc

Muchísimas gracias @Lino!! Para acabar, sabes si con Varnish tendríamos problemas? Entiendo que al no hacerse siempre consultas al servid
Post: Monitorizar GoogleBot con Google Analytics

Lino

@Joan marc sí!, pero has de configurar el server para que cualquier URL que de 301 sea tratada por una única url del site (como la url de
Post: Monitorizar GoogleBot con Google Analytics

Joan marc

Excelento post Lino! Has podido trackear los 301 y 302?
Post: Monitorizar GoogleBot con Google Analytics

German

Hola amigo, lo cierto es que no me he enterado pajolera idea de lo que cuentas, aunque te felicito por aparecer en el Discovery de Google. M
Post: Google podria no querer el HTML de una URL

Lino

Una manera súper sencilla para comprobarlo: 1- Una URL, mirar un log de Googlrbot de esa UR cuando da 200 2- Comparar con otro log
Post: Google podria no querer el HTML de una URL