Consolidación de urls canónicas en Google Search Console
Publicado el 27 de febrero del 2019 por Lino Uruñuela
En el año 2018 Google parece haber apretado el acelerador en el desarrollo y mejora de Google Search Console con nuevos diseños y nuevas funcionalidades, pero también desaparecen, al menos de momento, otras funcionalidades.
No voy a entrar en cada novedad o cada funcionalidad no implementada en el nuevo Google Search Console, hoy quiero tratar el tema que anunció hace poco y que tiene que ver con la consolidación de tráfico en URLs canónicas.
Hasta ahora, podíamos consultar los datos del informe de rendimiento para cada URL de nuestro site siempre que estuviese entre las 1000 con más datos/clicks. Esto ocurría fuese cual fuese y estuviese en la propiedad que estuviese (www, sin www, http, https), siempre y cuándo hubiese datos a mostrar, podías ver los datos del informe de rendimiento que estuviesen bajo la propiedad seleccionada.
Como he dicho antes, Google Search Console está cambiando la manera en que que muestra la información, y a partir de ahora (concretamente el día 10 de abril) comenzará a agrupar los datos bajo las URLs que Google entiende como canónica (no necesariamente serán las que configures tú como canonicals).
Desparecerán los datos de las URL que Google identifica como "secundarias", que son aquellas que tienen un meta canonical hacia otra URL, ya sea que lo hayamos implementado nosotros (algunas se pueden ver en el informe de cobertura "Página alternativa con etiqueta canónica adecuada" de Search Console), o aquellas que Google cree que debería tener el meta canonical (aparecen en el informe de cobertura como "Duplicada: Google ha elegido una versión canónica diferente a la del usuario").
Esto afecta tanto a urls bajo una misma propiedad como en otras propiedades, voy a poner un ejemplo, si tenemos la versión móvil de nuestro site está bajo un subdominio m.dominio.com, las urls bajo "m.dominio.com" llevarán un canonical (o deberían) a la url de la versión desktop, por lo que también dejaremos de ver los datos de estas urls aunque tengamos la versión móvil en una propiedad diferente en GSC.
Vamos a poner algún ejemplo.
Imaginemos que tenemos nuestro dominio diminio.com y que tenmos la web desktop bajo www.dominio.com y la versión móvil bajo m.dominio.com antes desde Google Search Console podíamos ver los siguientes datos.
Versión bajo www.dominio.com
Versión bajo m.dominio.com
Hasta aquí todo correcto, ahora vamos a ver el mismo informe pero con la nueva vista de Google Search Console... empieza el juego!
Nueva versión en GSC para www.dominio.com
Si miramos desde la nueva versión los datos de las urls para desktop, bajo www.dominio.com veremos que los datos no son iguales.
Si hacemos lo mismo con la versión para móviles, bajo m.dominio.com nos podemos da un buen susto al ver que no aparecen las urls que más tráfico orgánico traían al site (en este caso la versión móvil es mucho más usada que la desktop)
Nueva versión en GSC para m.dominio.com
Pero no, lo que ha ocurrido es que ahora están todos agrupados en sus urls equivalentes (a las que apuntan los canonicals).
Esto nos hace perder la visión real de cuántos clicks llegan a cada una de las versiones! perdemos información, puede que en algunos casos simplifique una mirada en diagonal del site, pero para los que nos gusta conocer los datos reales esto es un paso atrás....
Habrá casos en los que este cambio puede ser algo crítico desde el punto de vista SEO, enumero algunos;
- Webs con versiones móviles diferentes
Este escenario podría ser el más perjudicado, dado que todas las URL de sitio móvil desaparecerán del informe. Posiblemente alguna quede, aquellas que no tienen versión alternativa desktop y por lo tanto tampoco tenga meta canonical hacia otra url.
Si podrás filtrar por dispositivo con los filtros del informe de rendimiento, pero cómo verás los números no coincidirán. El porqué podría estar en que bajo la url www.dominio.com/url1-html podrían estar agregándose datos de otras urls y no solo los datos de la versión móvil. - Datos de AMP
De la misma manera que en las versiones móviles con urls separadas se debe poner un meta canonical a sus homólogas de la versión desktop, con AMP sucede lo mismo, además en AMP es obligatorio hacerlo por lo que será imposible evitarlo.
Cuando apliquemos el filtro desde GSC para ver los datos AMP nos pasará lo mismo que en el ejemplo anterior. - Sites multipaís en un mismo idioma
Es muy común en empresas grandes con presencia en otros mercados,tener una misma versión idiomática para diferentes países sin alterar prácticamente el contenido.
Es una práctica que no deberíamos realizar, pero a veces bien por necesidades de negocio, o por una mentalidad offline o por simple capricho del dueño nos vemos obligados a lidiar con este tipo de escenarios.
Quienes nos hemos enfrentado a esto sabemos que muchas veces Google toma una de las versiones como la canónica, esto se puede comprobar si al ver la caché en Google de esa URL te muestra la caché de otra ur diferente.
A la hora de mostrar los resultados en el buscador Google normalmente sabe qué versión idiomática debe mostrar dependiendo del país y lo hace correctamente, aunque también es cierto que a veces no lo hace y muestra la versión de otro país. Particularmente he visto que ocurre mucho en las homes.
En estos escenarios el cambio de Google Search Console también será crítico porque muchísimas de las urls con versiones iguales para diferentes países dejarán de arrojar datos en el informe de cobertura.
De la misma manera que antes he dicho se podría aplicar un filtro por país, pero tampoco coincidirán los datos. - URLs con parámetros
Hoy en día se intenta no usar parámetros en las URLs, sobretodo para que Google no vea dos urls diferentes con prácticamente el mismo contenido, pero hay veces que sí diferencian el contenido, o sin hacerlo demasiado, que se posicione por encima de la url sin parámetros debido a diversas causas como un enlazado sin querer desde algún site importante.
Lo más seguro es que en la mayoría de los casos no podrás identificar en GSC si esas urls reciben clicks. - Thin content
Cuando tenemos urls con poco contenido o contenido poco diferenciado Google suele asignarlas como duplicadas de otra url. En muchos casos el contenido no es idéntico y aunque en la mayoría de los casos Google muestre en sus resultados la URL canónica, a veces muestra la url duplicada si contiene algo que ha buscado el usuario y no existe en la url canónica.
Esto ocurre muchísimo, y si bien ahora somos conscientes de lo que ocurre en esas urls para decidir si existe o no un problema ya no podremos ver los datos en el informe de cobertura, por lo que tendemos a olvidarlas.
Cómo hemos visto existen multitud de casos en los que esta implementación es un paso atrás para los SEO y Webmasters, perdemos información y eso NO MOLA. En el mundo SEO reina la incertidumbre y los datos son nuestra única luz, debemos trabajar con datos para tomar decisiones con argumentos y ahora nos será un poco más difícil.
Para algunos usuarios con pocos conocimientos puede ser una manera de intentar simplificarle las cosas, pero no por ocultarle la realidad dejará de ser realidad, es más, si no lo ve difícilmente podrá corregirlo.
¿Qué significado tienen las URLs que desaparecerán de los informes?
Hemos visto que en muchos casos esto será malo para nosotros, pero intentemos sacar algo positivo de este cambio. Las urls que desaparecerán de los informes son aquellas que Google identifica como copias o duplicadas de otras urls, y esto es muy importante para nosotros porque nos indican qué urls tienen poca relevancia para Google.
Con esta información podríamos saber si es un problema y qué hacer con esas URLs.
- Diferenciando su contenido en el caso de que queramos trabajar ese tema.
- Hacer una redirección 301 si creemos que es un error de duplicado y podemos corregirlo.
- Comprobar si está teniendo en cuenta el contenido con ciertos parámetros en la URL.
- Saber si dos fichas de producto las toma como duplicadas si solo cambias el color.
- etc etc
Para saber qué urls desaparecerán podemos ver las URLs que se muestran en la vieja vista de Search Console y compararlas con las URLs que aparecen en la nueva vista.
Aquellas URLs que no están en la nueva vista pero sí en la vieja serán las URL que Google identifica como duplicadas.
Aquellas URLs que no están en la nueva vista pero sí en la vieja serán las URL que Google identifica como duplicadas.
Hacer esto a mano puede ser tedioso, pero gracias a Google Docs o similar y la fórmula VLOOKUP podemos hacer una sencilla comprobación de que URLs están en la vieja vista y que no lo están en la nueva.
Aquí dejo una plantilla para facilitar la labor, seguid estos pasos:
- Hacer una copia del documento.
- Ir al informe de rendimiento en Google Search Console.
- Click en la pestaña de "páginas" para que muestre las urls en vez de las consultas.
- Descargar las urls o exportarlas a Google Docs.
- Ir a la pestaña "Nueva vista" del documento que os he compartido.
- Copiar las urls y pegarlas a partir de la fila 3.
- Hacer click en el mensaje "Cambiar a la vista antigua" en Search Console.
- Descargar la lista de URLs como en el punto 4.
- Ir a la pestaña "Vista antigua" y pegar ahí las urls.
- En la pestaña "Urls que desaparecen" se mostrarán aquellas urls que están en la vista antigua pero no en la nueva!!
Espero que os sirva, si encontráis algún problema o mejora no dudéis en decirlo en los comentarios de este post.
Felipe (@felipeabsalonds)hace Hace más de 4 años y 102 días
Cada vez que pongo una etiqueta canónica en wordpress, me la desaparece automáticamente, la pongo en html, ya que de otra forma no me permite acceder a la configuración, ya que la página no es mía, sin embargo, tengo acceso para escribir entradas a mi nombre, quiero poner la etiqueta canónica, porque tengo un blog propio que es para mí la principal.
Lino (@errioxa)hace Hace más de 4 años y 98 días
@Felipe quizás si puedes añadir javacript podrías añadirla, pero si no creo que no podrás ya que el meta canonical va a nivel de cabecera por lo que aunque lo metas en medio del HTML de la página (del contenido que puedes escribir), a priori, no lo tendrá en cuenta.