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

Nueva visa GSC




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

Nueva visa GSC Mobile



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.

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:

  1. Hacer una copia del documento.

  2. Ir al informe de rendimiento en Google Search Console.

  3. Click en la pestaña de "páginas" para que muestre las urls en vez de las consultas.

  4. Descargar las urls o exportarlas a Google Docs.

  5. Ir a la pestaña "Nueva vista" del documento que os he compartido.

  6. Copiar las urls y pegarlas a partir de la fila 3.

  7. Hacer click en el mensaje "Cambiar a la vista antigua" en Search Console.
    cambiar a la antigua vista

  8. Descargar la lista de URLs como en el punto 4.

  9. Ir a la pestaña "Vista antigua" y pegar ahí las urls.

  10. 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.


 




Lea otros artículos de Google Search Console

Contacta

Lánzate y pregunta!


He leído y acepto la política de privacidad

Mecagoenlos.com te informa que los datos de carácter personal que nos proporciones rellenando el presente formulario serán tratados por Lino Uruñuela. como responsable de esta web.

La finalidad de la recogida y tratamiento de los datos personales que te solicitamos es para enviar un correo con los datos que introduzcas, sin guardarse en ninguna base de datos.

Legitimación: Al marcar la casilla de aceptación, estás dando tu legítimo consentimiento para que tus datos sean tratados conforme a las finalidades de este formulario descritas en la política de privacidad.

Como usuario e interesado te informamos que los datos que nos facilitas estarán ubicados en los servidores de Linode.com (proveedor de hosting de Mecagoenlos.com) cumpliendo la ley de protección de datos. Ver política de privacidad de Linode.com.

Podrás ejercer tus derechos de acceso, rectificación, limitación y suprimir los datos en info@mecagoenlos.com, así como el derecho a presentar una reclamación ante una autoridad de control. Más información aquí.

Últimos posts

Últimos comentarios


Lino Urnuela

@Emirodgar gracias! Pero parece que en tema de imágenes las pilla lo hagas cómo lo hagas parece, eso sí, siempre que no tengas un fall
Post: Indexar imágenes en Google usando Lazy Load

Emirodgar

Muy interesante el experimento. Yo estaba probando con los nuevos formatos webp y pero al final, como eran pocas imágenes y usaba Masonry,
Post: Indexar imágenes en Google usando Lazy Load

Lino Uruñuela

Completamente de acuerdo :) Pero en este experimento solo quería comprobar el método usado para hacer lazy load, en este caso con xmlht
Post: Indexar imágenes en Google usando Lazy Load

Francisco Morales

Lino muy interesante las distintas formas de cargar la imagen. Pero no crees que lo realmente interesante de aplicar Lazy Loading es cargar
Post: Indexar imágenes en Google usando Lazy Load

javier

Buenas , esto del onclik ha cambiado actuamente en algunas web que tengo las lee y sigue enlaces
Post: ¿Cómo ejecuta, interpreta e indexa Google el contenido cargado mediante javascript?

David Girona

Antes de Nada muchas gracias por la aportación. Estoy probando de poner en marcha este procedimiento y me surgen un par de dudas. En
Post: Cómo añadir el valor del meta Robots a Google Analytics via Google Tag Manager

Javier Espinoza

Gracias por la informacion!! Este tipo de blogs me parecen muy importantes, esto lo estudio en la universidad. gracias por la informacion. h
Post: Atacados por los .cn .cz .pl

juan

Hola Lino Uruñuela, una duda ¿aun funciona? porque no lo logro. Mira, en un index.php tengo este codigo: Camuflados
Post: Ofuscando enlaces para mejorar Link Juice

DUQUEredes

Google pasa del canonical bastante :-(
Post: Comprobando comportamiento de Google con meta canonical

Marinette

Gracias por la información!
Post: Nuevo Google Search Console ¿qué información nos ofrecerá?