para que no sirve la cache de google

Un artículo para desmitificar clásicos inamovibles en las auditorías SEO, que normalmente no se tienen en consideración.

Lo más normal es que un SEO tome la caché de Google cómo una realidad inamovible del contenido que está obteniendo Google sobre nuestra web para algunas preguntas:

  • Google ha crawleado ya mi dominio? 
  • Google es capaz de renderizar mi contenido en JS?
  • Este es el contenido que Google lee sobre mi URL?

cache google SEO

 

Todo esto tiene su fundamento, de hecho en las Search Help de Google, podemos encontrar:

search help cache google

Sin embargo, mi objetivo con este post, es demostraros “por qué” esto no es cierto . Muy poco de lo que nos aparece en una captura de la caché de Google, es confiable o suficientemente útil cómo para auditar en base a ello.

Permitidme que antes de desmontar los puntos de la caché de Google, nos tomemos un breve momento para identificar estos elementos:

captura de caché de Google

 

 

URL consultada en la caché de Google

Es muy habitual no darse cuenta de esto, pero a la vez suele ocurrir que Google no nos devuelva la URL que hemos consultado en su caché cómo resultado.

Google cachea únicamente las URLs “indexables”. ¿Qué URLs no cachea Google?:

  • URLs con la tag robots en “noindex”
  • Redirecciones a otra URL
  • URLs con Canonicals hacia otras URLs
  • URLs Soft 404
  • Contenidos duplicados

cache google URL

 

Loleando con Screaming frog a Vodafone (yo en mi caso, pero vosotros podéis probar cualquier web), he encontrado varias URLs con un canonical no auto-referido. La URL era:

  • https://www.vodafone.es/conocenos/es/test-velocidad-adsl-fibra/

que cuenta con un canonical hacia:

  • https://www.vodafone.es/conocenos/es/test-velocidad-adsl/

 

De haber usado para la demostración una URL que Google considerara cómo soft 404 el resultado habría encontrarme con una URL que no devuelve resultado, lo cual se podría interpretar cómo consecuencia de que Google aún no ha indexado ese contenido, y sería un error:

soft 404 cache

El snapshot de la Caché de Google

 

cache google angular

Google sólo cachea el código HTML de una página, no el DOM resultante al finalizar todos los User events y terminar de ejecutarse todo el Javascript. Sólo en el difícil caso de que la URL se ejecute completamente con HTML, veremos un reflejo entero de la URL tal cual la leería Google. Sin embargo, si estás trabajando bajo una web construida en Angular u otro Framework basado en Javascript, lo que encontrarás en este Snapshot no tiene nada que ver con la realidad. De ser así, te recomiendo que te leas mi guía de SEO para Angular para aportarte algo de luz :)El resumen de por qué pasa esto es simple:

 

El sistema de enrutado de Angular JS en HTML5 (pushState), se basa en que la URL realice la petición en AJAX para servir el contenido de cada URL.

Así que cuando accedemos a la URL de la caché de Google (http://webcache.googleusercontent.com/search?q=cache%3Aohlibro.com&oq=cache%3Aohli&aqs=chrome.2.69i57j69i58j69i59j69i60.3247j0j1&sourceid=chrome&ie=UTF-8) la URL no es la misma y no es capaz de ejecutar la llamada en AJAX. Sin embargo esto no significa que Google no sea capaz de renderizar y leer el contenido de la URL.

 

Este sería el resultado real que obtendríamos a través de la herramienta de Fetch & Render de Google:

fetch and render

Cómo podemos ver, Google es capaz de renderizar y leer completamente el contenido de esta URL.

Para verificar si realmente Google puede comprender el contenido de nuestra URL, deberemos utilizar la herramienta de Fetch&Render de Google para asegurarnos de que no obtenemos falsos positivos.

 

Fecha de la captura

timestamp cache

El dato de cuando ha sido la última vez que Google ha crawleado nuestra URL sin duda es crítico para descartar incidencias cuando vemos que una URL por ejemplo no ha indexado o no se posiciona, pero… ya lo siento, no podemos saber la última fecha de crawleo de una URL con la caché: la fecha de inclusión en la caché puede ser diferente de la última vez que se crawleo esa URL. 

Además, por ejemplo, si quisiéramos obtener datos de cuando Google ha encontrado una Redirección o una regla de canonicals, no podríamos obtenerlo mediante este medio.

Para obtener esta información, debemos utilizar los Logs del servidor; este dato sí que nos servirá para saber cuando ha crawleado exactamente Google nuestras páginas. El procedimiento para analyzar los logs no es demasiado complejo y podemos utilizar nuestro amado Screaming Frog para ello; os dejo por aquí un tutorial en vídeo!

 

 

Espero que os haya servido para aprender algo 🙂 La verdad es que últimamente he tenido bastantes encontronazos con las cachés de Google, la madre de las renderizaciones y amigos de Angular… así que sin más, aprovechaba para compartiros conclusiones que he encontrado y pruebas que he ido haciendo!

Bueno, imagino que si estás aquí es por que has recibido el email de Google (Search Console) notificando que Googlebot no puede acceder a los archivos CSS y JS;

No te preocupes; todo esto forma parte de un release que soltó Google en su blog; comentando que:

Disallowing crawling of Javascript or CSS files in your site’s robots.txt directly harms how well our algorithms render and index your content and can result in suboptimal rankings.

-No prermitir el rastreo de Javascript o archivos CCS mediante el robots.txt, perjudica directamente lo bien que nuestros algoritmos hacen indexar tu contenido, y puede conllevar unos resultados de posicionamiento jodidos.

No me voy a entretener mucho en ese punto, así es la comunicación de Google, y si quieres saber más puedes echarle un ojo a este link  del blog de webmastercentral; yo personalmente creo que hasta que no enviaron el mail, tampoco era algo “diferencial”; puesto que nadie lo debía hacer explícitamente, por lo que en igualdad de condiciones, los tuertos eran los reyes.

La cosa es que la fiesta ha cambiado, y tenemos que ponernos el vestido bonito; así que para resolver esta incidencia aquí tienes unos sencillos pasos:

 

Añade las siguientes líneas a tu archivo robots.txt:

Allow: /*.js$
Allow: /*.css$

-De esta forma estaremos permitiendo específicamente la indexación de archivos CSS y Javascript; con lo que problema resuelto.

Si no tienes un archivo robots.txt en tu dominio, deberás crear un archivo txt (bloc de notas), llamarlo “robots” y subirlo a tu FTP a nivel de raíz del dominio, con el siguiente contenido:

User-agent: *
Allow: /*.js$
Allow: /*.css$

 

Otra de las líneas que nos van a causar problemas, especialmente en las instalaciones de WordPress es la típica línea automatizada de cualquier plugin de robots.txt de WordPress, que incluye:

Disallow: /wp-includes

Disallow: /wp-content

Estas dos carpetas, contienen archivos CSS y Javascript; y es todo un cliché ponerlas siempre en disallow dentro del archivo robots.txt; pero the shit is going down para “lo que siempre se ha echo”; y otra vez toca cambiar de parecer; para el tema del disallow en “wp-content”, os recomendaría desindexar únicamente la carpeta de plugins, tal que así:

Disallow: /wp-content/plugins/

La cosa es que si tenéis un theme añadido en vuestro wordpress, que sea responsive; los archivos CSS y Js del responsive muy probablemente se alojen dentro de esa carpeta, con lo que si tenemos un Disallow: /wp-content puesto en nuestro archivo robots.txt, nos vamos a encontrar con esto, al pasar nuestro test de “mobile friendly” de Google

robotstxt de wp content

 

 

 

Y sin más, aquí os dejo el tutorial para Googlebot pueda acceder a los archivos CSS y JS

 

¡Hasta la próxima!