Google podria no querer el HTML de una URL

Publicado por Lino Uruñuela el 10 de diciembre del 2019

Llevaba tiempo preparando un post, pero me cuesta, porque quiero redactarlo bien, explicadito y al final o no lo comienzo por la pereza que me da eso de currármelo en vez de soltarlo así según viene, o directamente no lo termino jamás....

Pero hoy vuelvo a mis orígenes, de carrerilla y sin mirar, mejor aquí que dejar mi contenido en Twitter ya que creo que no es buen canal para transmitir conocimiento, al menos el que requiere una mínima explicación, además, se pierde el cronológicamente y se diluye entre forks de cada uno, y así voy a comenzar el año, escribiendo en este blog y con la única pretensión de compartir ideas y conocimiento,

Después de esta chapa vamos al lío, hoy Gaston Riera reflexionaba en Twittter sobre si Google valorará un meta canonical en páginas de error 404, ya que no sabía si Google cargaría el HTML o no al ser una página con error 404.

Así que se me ha ocurrido echar un vistazo a los logs para intentar comprobar de una manera sencilla si Google descargaba más Bytes por cada url 200 que por cada URL 404 y ya de paso el resto de códigos de estado.

Esta tabla está ordenada por los bytes medios descargados por Googlebot para cada código de estado. Y he visto que claramente el tamaño medio es mucho menor que los estados 200. Yo casi me había quedado tranquilo, pero ha llegado José Antonio Gil haciéndose preguntas y cuestionando si quizás no era tan sencillo como a priori a mí me parecía... me encantan este tipo de personas, gente que piensa y se cuestiona las cosas por si lo dicho no fuera cierto o no fuese del todo cierto, esto es algo que hay que hacer siempre, por muy convencido que estés de tu punto de vista...

Ahora desde aquí quiero profundizar un poquito más en si Google descargará o no el contenido de una URL (que no sos recursos como imágenes, css o js) sino el código fuente o HTML cuando accede a una URL 404.

Como he dicho José Antonio ha probado y ha intentado comprender si el dato que yo he mostrado quizás sea el peso del código de las urls 40 y por ello fuese tan bajo, una sospecha muy bien pensada, pero también lo había pensado yo antes de sacar los datos, y no, no se corresponde con el tamaño de la típica página en blanco de "Error página no encontrada".

Ha seguido probando ideas y ha hecho sus pruebas con Screaming, bien hecho también, aunque claro, el crawler de Google no será igual ni se regirá por las mismas normas que el de Screaming!! pero está bien pensado, al menos intentar mirar en lo más cercano que tengas, en este caso Screaming.

Pero luego ha comentado

"Y por último, y prometo que ya os dejo tranquilos, una reflexión en voz alta: a) el servidor sirve el fichero íntegramente, da igual el código de estado del mismo. Ojo con la compresión por Gzip que haga Apache en caso de que la tengas activada".

Iba intentar explicarle por qué yo creo que no es así, entonces me decidí a escribir esto.

Habitualmente uso la línea de comandos (sí la línea de comandos) para ver rápidamente algunas cosas, por ejemplo las cabeceras devueltas por una url o grupo de urls. Para ello uso el comando curl, siempre un gran aliado!, y vamos a ver las diferentes maneras que yo he usado o conozco para acceder a una URL.

Por ejemplo podéis probar desde vuestro terminal (en Windows creo que también existe igual) a poner

"curl -I https://www.mecagoenlos.com"
Para obtener solamente las cabeceras

"curl https://www.mecagoenlos.com"
Para obtener el código fuente (HTML)

Pero también se puede usar para obtener solamente las cabeceras, muy útil para ver cosas como la etiqueta "X-Robots-Tag" y todo el resto de cabeceras de una petición http. En el caso que nos encumbe aquí, vemos cómo se puede hacer una solicitud https y no esperar (ni pedir) el message body o cuerpo del mensaje.

Y es aquí dónde difiero con Jose Antonio y la causa de este post. Hay mucha formas, y es muy habitual realizar este tipo de peticiones http dónde no llega el cuerpo del mensaje o en nuestro caso el HTML. Recordemos que el protocolo HTTP tiene diferentes partes métodos (GET, POS. HEAD, etc) que recibe diferentes códigos de estado (200, 301. 404, etc) y puede recibir un mensaje...

Si lo pensamos bien tiene toda su lógica que Google no quisiera descargar el HTML de urls 404, ya que tiene pocas probabilidades de obtener algo útil de ellas, y con la enorme cantidad de urls erróneas que hay en internet (URLs erróneas en Internet = Todas las URLs posibles - Todas las que sí existen que no son erróneas) es normal que Google evite hacer ese trabajo, gana tiempo y dinero ya que los costes de estos números a la escala que lo hace Google no es moco de pavo.

Vamos a ver unas pequeñas diferencias al usar el comando curl, para ello voy a hacer peticiones a unas urls de mi dominio y vamos a guardar los resultados devueltos en diferentes ficheros para ver cuánto pesan esas respuestas, esto se hace añadiendo al comando esto al final que indica dónde guardar los resultados "> nombrefichero.txt"

Petición de cabeceras a una URL correcta (200)

Peso: :	164 bytes
*Respuesta*	HTTP/1.1 200 OK Date: Tue, 10 Dec 2019 19:11:33 GMT Server: Apache/2.4.18 (Ubuntu) Cache-Control: max-age=0, no-cache Content-Type: text/html; charset=utf-8

Petición de cabeceras + HTML a una URL correcta (200)

Peso:
:

210 Kbytes

Respuesta
Todo el código HTML de la home de mi blog

Petición de cabeceras a una URL con redirección 301

Peso: :	258 bytes
*Respuesta*	HTTP/1.1 301 Moved Permanently Date: Tue, 10 Dec 2019 19:10:29 GMT Server: Apache/2.4.18 (Ubuntu) Location: https://www.mecagoenlos.com/ Cache-Control: max-age=86400 Expires: Wed, 11 Dec 2019 19:10:29 GMT Content-Type: text/html; charset=iso-8859-1

Petición de cabeceras + HTML a una URL con redirección 301

Peso: :	318 bytes
*Respuesta*	HTTP/1.1 301 Moved Permanently Date: Tue, 10 Dec 2019 19:10:29 GMT Server: Apache/2.4.18 (Ubuntu) Location: https://www.mecagoenlos.com/ Cache-Control: max-age=86400 Expires: Wed, 11 Dec 2019 19:10:29 GMT Content-Type: text/html; charset=iso-8859-1

Petición de cabeceras a una URL de error 404

Peso: :	140 bytes
*Respuesta*	HTTP/1.1 404 Not Found Date: Tue, 10 Dec 2019 19:12:40 GMT Server: Apache/2.4.18 (Ubuntu) Content-Type: text/html; charset=iso-8859-1

Petición de cabeceras + HTML a una URL de error 404

Peso: :	282 bytes
*Respuesta*	<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>404 Not Found</title> </head><body> <h1>Not Found</h1> <p>The requested URL was not found on this server.</p> <hr> <address>Apache/2.4.18 (Ubuntu) Server at www.mecagoenlos.com Port 443</address> </body></html>

Como vemos las respuestas son diferentes y dependiendo de qué quieras hacer será más útil o eficiente una que otra.

Aquí dejo por ejemplo la diferencia entre lo que devuelve una petición de cabeceras y lo que devuelve si pedimos el cuerpo del mensaje

diferencia entre respuestas de header y de cuerpo del mensake

Volviendo al SEO, estos diferentes tipos de peticiones también las hará Google, y las exprimirá al máximo, ya que las personas que desarrollan el crawler son puros matemáticos.

Igual nos da que leernos unas patentes dónde menciona no sé qué.. (yo también lo hago y lo seguiré haciendo) o que directamente nos expliquen realmente cómo funciona en toda su complejidad,... total, pocos SEOs llegarán a comprenderlo matemáticamente.

Y aunque algo podamos intuir jamás podremos llegar a ese nivel sin antes haber pasado 5 años estudiando matemáticas.,Dicho esto, esa gente sabe lo que hace y depuran hasta el límite cada proceso que montan, ya que deben escalarse a nivel planetario y es ahí dónde los pequeños números como el tiempo de descarga o el tamaño de la misma hacen que sean desafíos enormes!

Comentar

José (@)hace Hace más de 5 años y 13 días

Buenas Lino! Sólo comentar que el apellido de Gastón es RIERA (no Rivera). Saludos y gracias por compartir!

Lino (@)hace Hace más de 5 años y 13 días

Uppsss cierto, la culpa es de tantas elecciones consecutiva... hacen remarketing en mi cerebro

Jose Antonio Gil (@)hace Hace más de 5 años y 13 días

En primer lugar agradecerte tus palabras, he sido alumno tuyo este año en el Máster de Webpositer en Alicante por lo que algo de culpa tendrás de que me surjan estas dudas ;-)

Quiero matizar un poco el proceso que me ha llevado a mi reflexión, primero, porque como indicas, twitter no es el mejor sitio para ello, y de paso, enriquecer si se puede este post que te acabas de currar.

Cuando has publicado la imagen con las diferentes medias de peso según el código de estado, al rato he caído que me faltaba más información:
¿en la agrupación que haces de códigos de respuesta 200, estás excluyendo las imágenes? He supuesto que sí, de lo contrario esa media de Kb estaría siendo alterada. Luego he pensado, igual erróneamente, que la comparación no debería ser entre la diferencia de peso de las urls 200 vs 404, si no del peso real de una url con código de error 404 (o mejor dicho, del peso del código html devuelto) y lo que está sirviendo el servidor (el peso que indica el log a esa petición).

La única manera que tenía de comprobarlo era tirar de mis logs, aquí un apunte: no he usado ScreamingFrog, si no ScreamingLog. Nos enseñaste en clase a ver los logs en línea de comandos pero me has pillado en el curro y he tenido que tirar de algo más rápido ;-)

La primera sorpresa que me llevo es que el peso de las urls de código 200 difiere, en mucho, al peso del código HTML que me descargo. Eso no pasa con las imágenes cuyo peso sí coincide tanto del log como del fichero. Aquí he caído que apache puede comprimir con gzip lo que envía al cliente si así lo tienes configurado en el servidor (como era mi caso). Las capturas que he puesto en twitter hacía referencia a eso: si comprimía el html con código 200 que me había descargado, el peso, ahora sí, coincidía con lo que me daba el log. ¿por qué el peso de la imagen sí coincidía entonces? Porque Gzip apenas es capaz de bajar el peso de una imagen jpg (he hecho también la prueba y no ha variado el tamaño del archivo).

Por último, he cogido una url que daba código de error 404, (te aseguro que la página 404 del ecommerce en el que curro como desarrollador es bastante pesada ya que está incrustado todo el css), la he pasado por Gzip y…. tachán: el peso coincide con lo que me está mostrando el log (la captura está también subida en el hilo).

De ahí mi conclusión: si el tamaño del fichero coincide, supongo que será debido a que Google pide la url completa y no solo el encabezado. Si esto es así, he pensado que igual sí influye el peso de esas páginas 404 en el rastreo. Una prueba que haré es: ¿Qué pasa si pido una url y antes de acabar de cargar en el navegador paro la petición? ¿El peso registrado en el log coincide con la carga de esa misma url completa? Si coincide sí puedo creerme que Google tenga algún mecanismo para parar la petición una vez recibida la cabecera, pero si no coincide la conclusión sería otra. Mañana haré alguna prueba con esto último que indico, prometo usar curl ;-). Otra prueba que haré es ver si en el log se ve diferenciado si se hace la petición de la cabecera o de toda la página.

Lino (@errioxa)hace Hace más de 5 años y 13 días

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 de esa misma URL pero que de 404, mañana lo compruebo :)

Y fuera dudas! Habrá que. @errioxa probando

German (@)hace Hace más de 5 años y 12 días

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. Me hubiera gustado que hubiera tenido para insertar mi web en lugar de mi email. Me hubiera valido para ganar un link externo. Puede que lo tengas en no follow.
Por último hacerte una observación por si me la puedes resolver ¿Porqué de los resultados de Google, una o varias urls concretas, estas me las envía a urls distintas? Gracias por todo