Crawl Stats en Safecont
Como muchos sabréis, en los últimos días @Safecont ha estrenado su nueva funcionalidad «Crawl Stats». Esta nueva funcionalidad ofrece un crawler y por tanto datos de crawleo, información sobre errores, URLs, etc. Pues bien, como no podía ser de otra forma, llevamos un par de semanas dándole caña a la herramienta y lanzando nuevos tests para analizar nuestros sitios webs. La información obtenida es muy interesante, pero nos hemos encontrado con un par de casos que nos han llamado la atención.
Cuando entramos en la pestaña «Crawl Stats» nos encontramos con un bloque que da información sobre las URLs crawleadas:
El caso que vamos analizar apareció cuando entramos a ver el detalle de las redirecciones 301. En varios sitios webs nos encontramos lo siguiente:
¿Qué son y de dónde salen estas redirecciones?
Lo primero que vimos es que todos los sitios web en los que aparecían eran WordPress. En segundo lugar, eran redirecciones que no estaban introducidas en el .htacces, en la definición del ‘virtual host’ ni en cualquier archivo donde podamos introducir redirecciones de manera manual.
Analizando el código de estas URLs los enlaces aparecían de la siguiente manera:
<link rel=’shortlink‘ href=’http://www.midominio.es/?p=2585′ />
¿Qué es el rel=’shortlink’?
El rel=’shortlink’ permite especificar un link acortado sin necesidad de utilizar una herramienta de terceros. Podéis encontrar la especificación del shortlink aquí.
La cuestión es que, a día de hoy, como ya explicó John Muller (@JohnMu) en octubre del año pasado, Google ignora este shortlink:
Pero, claro, que ignore el shortlink no quiere decir que no detecte ese enlace y lo rastree.
Ante este escenario, nos encontramos que Google esta invirtiendo tiempo de rastreo en enlaces que muchas ocasiones no controlamos y que además generan una redirección 301 a la propia página. ¿Es esto necesario? No.
Pensaba que esto iba a ser un caso aislado, pero la realidad es que no sólo lo hemos encontrado en varios de los sitios web analizados, sino que tras indagar en otros sitios, bastante más grandes e importantes, también lo hemos encontrado.
¿Cómo lo solucionamos?
Este shortlink, en ocasiones, es incluido por el propio tema utilizado en WordPress. Eliminar este shortlink es muy sencillo, sólo necesitamos incluir este pequeño fragmento de código en el archivo functions.php:
add_filter('after_setup_theme', 'gtk_remove_redundant_shortlink');
function gtk_remove_redundant_shortlink() {
remove_action('wp_head', 'wp_shortlink_wp_head', 10);
}
Resultados
Actualmente lo hemos implementado en dos sitios web no muy grandes y en un tercero de mayor tamaño. Tenemos que esperar un poco para ver qué efectos tiene, pero si nos fijamos en el Crawl Health Score de Safecont, el resultado es el siguiente:
Sitio 1
Sitio web bastante pequeño, unas 50 URLs con WordPress.
Sitio 2
Comercio electrónico desarrollado con Prestashop y un blog con WordPress en dominio.com/blog
Sitio 3
Sitio web con unas 4000 URLs en dos idiomas sobre WordPress. En este caso tiene un sistema de caché implementado que no tuvimos en cuenta al hacer la primera prueba de forma que no se habían aplicado los cambios en todas las páginas (solo las no cacheadas), por lo que tuvimos que hacer un par de veces los análisis con Safecont y los resultados se ven en dos tramos.
En algunos de los análisis aun queda trabajo por hacer, pero con estos tests vemos como podemos optimizar el crawleo de nuestros sitios webs en WordPress de una manera sencilla, evitando que los robots pierdan el tiempo en enlaces que no aportan nada con redirecciones innecesarias. Por supuesto, este caso no en todos los WordPress se da este caso, pero es facil comprobarlo mirando el código de una página.
Muchas gracias por el post, me ha ayudado mucho. Justo estaba buscando cómo eliminar todas esas redirecciones 🙂
Un placer ayudar!