Hace ya tiempo que el nuevo Google Search Console nos acompaña, afortunadamente, porque trajo no sólo una nueva interfaz que a mi personalmente me gusta mucho, sino también nuevas funciones e informes más completos para analizar el SEO de una web.

Creo, y muchos estaréis de acuerdo, que Search Console podría ofrecer mucho más de lo que ofrece, en algunas funcionalidades se queda corta, pero por suerte parece que Google sigue mejorando poco a poco la herramienta y de vez en cuando nos sorprende con alguna novedad.

Dentro de todas las novedades que nos trajo la nueva versión, una de las que más utilizo y que creo que más ayuda ofrece es el Informe de Rendimiento. Una funcionalidad que como otras, fue mejorando y ahora considero que es muy útil. Por ello hago este post para contarte cómo le puedes sacar partido, qué información puedes sacar, qué datos deberían interesarte y ayudarte a interpretar todos ellos, incluso con ejemplos reales, para que puedas echar mano de Search Console para mejorar ciertos aspectos de tus proyectos SEO.

¿Qué es y para qué sirve el Informe de Cobertura de Search Console?

Si todavía no sabes lo que es o para qué sirve, pero has llegado a este post atraído por el título, te cuento todo sobre este informe.

El informe de cobertura de Search Console te da datos del estado de rastreo e indexación de las páginas de una propiedad, algo realmente útil para tener controlado lo que ocurre, cómo Google está indexando o no ciertas partes de tu web y en base a los datos que te ofrezca actuar en consecuencia.

Es un informe útil para todo tipo de webs, pero sobre todo para aquellas de mayor tamaño, dinámicas, en las que continuamente hay movimiento, nuevas páginas, desindexaciones, eliminación de páginas, redirecciones, etc.

De un vistazo puedes tener el estado de indexación de tu web, si hay URLs que se han indexado que no debería, si existe algún problema de indexación, rastreo, qué está ocurriendo con lo que envías al sitemap… Pero bueno, ahora lo veremos con más detenimiento.

informe cobertura search console - qué es

¿En qué situaciones puedes necesitar el informe de cobertura?

Esta herramienta de Google Search Console no es algo que ni mucho menos tengas que utilizar a diario. Dependiendo del proyecto puede que necesites echarle un ojo con más frecuencia, pero te cuento las situaciones más típicas en las que te lo recomiendo, porque puede serte de mucha utilidad:

Análisis periódicos

Como te acabo de decir, no es necesario mirar este informe a diario, pero sí convendría acudir a él de forma periódica para controlar posibles problemas, advertencias nuevas o cualquier novedad en cuanto a indexación… Google suele avisar de problemas o advertencias mediante correo electrónico, pero por si acaso, es recomendable planificar análisis periódicos.

¿Cuándo? Dependerá del tamaño de tu web, de lo «dinámica» que sea esa web. No es lo mismo una web sobre la que no se aplican cambios, mejoras, ni ninguna novedad que una web que está continuamente actualizándose, aplicándole mejoras, creando contenido nuevo o eliminando páginas.

Problemas de indexación (por exceso y por defecto)

Cuando estás encima de un proyecto a nivel de SEO puede ocurrir que detectes comportamientos extraños, ciertas anomalías en el posicionamiento, la visibilidad de tu web… Hablo de problemas de indexación tanto por defecto, es decir, que hay páginas que se deberían estar indexando que no lo hacen o por exceso, páginas que no deberían indexarse y sí lo hacen.

Este es un momento en el que este informe te va a ayudar. Entre otras cosas podrás saber por qué se indexan ciertas páginas o por qué no se indexan.

Comprobaciones sobre el Sitemap.xml

Una de las características de este informe es que extrae información de tu Sitemap.xml y los datos que te da de indexación y rastreo los combina con lo que hay en ese mapa del sitio. Esto te ayuda cuando quieres saber si el contenido de un sitemap, si las URLs que contiene son las que tienen que ser, faltan o si en cambio, hay URLs que no deberían estar.

Hay casos en los que debes optimizar el Sitemap y este informe te puede ayudar a entender cuánto y qué debes optimizar.

Sobre todo el informe de cobertura será más útil en Sitemaps con cientos de miles de URLs, donde hacer un análisis más «manual» se vuelve imposible.

Cambios en directivas, canonicals y desindexación de páginas

Cuando aplicas cambios en proyectos tales como modificar la meta etiqueta robots para desindexar, indicar URLs canónicas o desindexar de forma masiva o una gran cantidad de URLs, es recomendable acudir a este informe.

Podrás controlar los efectos de esas acciones, cómo está actuando Google tras darle esas nuevas indicaciones, si has hecho alguna implementación mal… Como sabrás cuando por ejemplo marcamos como «noindex» una URL puede tardar días o semanas en desindexarse. Esto lo podrás comprobar desde el Informe de Cobertura de GSC. Además de esto, te recomendaría que le dieses un buen uso a las Anotaciones de Google Analytics.

Cambios en URLs y redirecciones

¿Has hecho cambios en URLs y redirecciones 301/302? Te conviene ir mirando de vez en cuando días después de esos cambios cómo se comportan esas páginas afectadas por los cambios. ¿Se desindexa la página que ha sido redireccionada? ¿Hay algún aviso de que tienes URLs en el Sitemap.xml con una redirección 301?

Cambios en el sitemap.xml o subida de nuevo sitemap.xml

El informe de Cobertura de Search Console tiene un apartado (abajo lo vemos) que te deja ver el análisis del Sitemap enviado. Si haces cambios importantes en el sitemap (o lo hacen tus plugins SEO al desindexar (Yoast, Rank Math, All in One…), eliminar páginas, etc) conviene que pasados unos días compruebes cómo está Google actuando con las paginas incluidas en el Sitemap.

También es recomendable cuando añades un nuevo Sitemap, lo sustituyes o lo envías por primera vez.

Auditorías

Por supuesto, es un informe que te puede ayudar mucho cuando estás haciendo la auditoría SEO de una web para identificar problemas de indexación, problemas de rastreo, qué se está indexando, cómo está el Sitemap y si hay incongruencias o errores en él. Todo lo que te ayude a obtener información para optimizar el apartado de rastreo e indexación de una web en plena auditoría, debes quererlo en tu equipo.

Y si combinas los datos del informe de cobertura de Search Console con toda la info que te da Screaming Frog tendrás mucha más información.

Estados de las URLs: ¿qué quiere decir cada uno de los estados?

Dentro del informe de cobertura hay 4 grandes grupos de estado en el que se encuentra una URL, pero a su vez, dentro de los 4 estados hay digamos subtipos.

estados urls search console

Error

Las URLs que se indican con este estado tienen algún problema que hace que no puedan indexarse. Esto puede ser grave en el caso de que las páginas que aparezcan aquí sean importantes para tu web y para el SEO. Si las páginas que aparecen no son relevantes, échales un ojo igualmente para tener todo lo que tiene que ver con rastreo e indexación controlado.

errores search console

Los motivos por los que aparecen URLs con errores son:

🚫Error de servidor (5xx): esto ocurre porque en el momento de rastreo, esa URL ha devuelto un error 500 y por lo tanto no se puede indexar. Vigila estos errores, porque aunque suelen ser momentáneos en ocasiones pueden ser perjudiciales.

🚫Error de redirección: este error ocurre cuando en el rastreo Google ha tenido un problema con las redirecciones, como por ejemplo cadenas de redirecciones demasiado largas, bucles de redirecciones, URL incorrecta en la cadena, etc.

🚫El archivo robots.txt ha bloqueado la URL enviada: esto ocurre cuando tienes una URL bloqueada mediante Disallow en Robots.txt, pero a su vez la has enviado al Sitemap.xml. Vamos, que no es coherente, ya que si envías una URL al Sitemap es para que sea rastreada e indexada, por lo que no tiene sentido que la bloquees también en Robots.

🚫La URL enviada contiene la etiqueta «noindex»: igual que el caso anterior, pero en lugar de bloquear por Robots.txt marcas la página enviada en el Sitemap con un «noindex». Revisa las diferencias entre el noindex y el robots.txt.

🚫La URL enviada devuelve un soft 404: : se trata de que una URL enviada al Sitemap devuelve un estado 200, es decir, todo normal, pero es una página que se utiliza para informar de que el contenido al que el usuario quería llegar no existe. No tiene sentido tener esta página en el Sitemap. Además Google recomienda mostrar al usuario en estos casos páginas 404 (personalizadas) o con estado 410.

🚫La URL enviada devuelve una solicitud no autorizada (401): una página enviada al Sitemap que devuelve un código 401 cuando el robot intenta acceder. Esto quiere decir que es una página que requiere autorización para entrar. No tiene sentido que este tipo de páginas estén en el Sitemap, pero si quieres tenerla y quieres que Google puede acceder, aquí puedes leer cómo se hace.

🚫No se ha podido encontrar la URL enviada (404): un página enviada al Sitemap devuelve un error 404, por lo tanto no podrá indexarse porque no existe. Aquí te cuento cómo hacer redirecciones 301/302.

🚫La URL enviada tiene un problema de rastreo: Google no ha podido indexar la página porque hay un problema de rastreo que no es ninguno de los anteriores. Cuando ocurra esto, te recomiendo que entres en el error en cuestión, hagas click en la fila de la URL y uses la función de Inspeccionar URL. Seguramente encuentres dónde está el problema.

Válidas con Advertencias

⚠️ Se ha indexado aunque un archivo robots.txt la ha bloqueado: este aviso puede parecerse a uno comentado algún párrafo más arriba, pero tiene diferencias. En este caso nos está avisando de a que a pesar de que una página está bloqueada por Robots.txt se ha indexado, independientemente de si se ha enviado o no.

A veces se piensa que Google no lo hace bien aquí, pero piensa que el robots.txt mediante un Disallow bloquea el acceso, pero no evita la indexación, por lo que si esa página bloqueada es encontrada por otro sitio en el rastreo, como puede ser el Sitemap o un enlace interno puede ser indexada. Si no quieres que sea indexada, márcala con «noindex».

Válidas

Enviada e indexada: este estado te dice que esas URLs están actualmente indexadas y además están enviadas al Sitemap. Aquí debes comprobar que todo lo que tienes enviado al Sitemap es correcto y no hay nada que no deba estar.

Indexada, no enviada en Sitemap: esto ocurre cuando una URL se ha indexado a pesar de que no la has incluido en el Sitemap, por lo que puede ocurrir:

  • Que no esté en el Sitemap porque para ti no es relevante, pero que no has tomado las precauciones para que no se indexe.
  • Que no esté en el Sitemap a pesar de que es relevante para ti porque se te ha olvidado incluirla al generar el Sitemap.xml o bien porque tu plugin encargado del Sitemap lo esté haciendo mal. Esto último es raro, porque una página con «index» suele incluirse en el Sitemap.xml de forma predefinida, a no ser que indiquemos lo contrario en la configuración del plugin de turno como Rank Math o Yoast.

Excluidas

Entre los motivos para que una página esté como excluida encontramos muchos y variados. Aquí deberían estar aquellas URLs que no quieres que se indexen, que has redireccionado, que has eliminado, etc. Si entre estas páginas encuentras URLs que son importantes para el SEO y para ti, investiga el por qué de esa exclusión, y según el motivo tendrás que optar por diferentes soluciones con el objetivo de que se terminen indexando.

✖️Excluida por una etiqueta «noindex»: sencillo, Google al rastrear esa página ha encontrado un «noindex» en la meta etiqueta robots, por lo tanto, Google hace caso y no la indexa.

✖️Bloqueada por una herramienta para eliminar páginas: son aquellas URLs que se han eliminado desde la herramienta de eliminación de URLs del propio Search Console. Si utilizas esta herramienta, es bueno que a través del informe de cobertura vayas monitorizando cuándo se eliminan del índice o si vuelven a él tras estar eliminadas.

✖️Bloqueada por robots.txt: en este caso Google no ha podido indexar porque no ha podido acceder al haber un bloqueo por Robots.txt. En el caso de que encontrara esa URL por otro medio, podría indexarla si fuera indexable.

✖️Bloqueada por una solicitud no autorizada (401): no hay indexación porque los bots no han podido acceder.

✖️Anomalía en el rastreo: se da cuando no se ha podido rastrear, pero no se especifica alguno de los motivos anteriores. Pude ser por un error 4xx o 5xx. Para saber el motivo puedes utilizar la herramienta de Inspección de URL e investigar qué ha podido ocurrir.

✖️Rastreada: actualmente sin indexar. Una página ha podido ser rastreada por los crawlers pero no ha sido indexada todavía. Puedes, o bien esperar o enviar la URL a la cola de indexación, aunque Google te dice que no es necesario (hazlo por si acaso 😜).

✖️Descubierta: actualmente sin indexar. Google sabe de la existencia de esta URL porque la ha encontrado por algún medio, pero no ha podido rastrearla en el momento de dar con ella por algún motivo.

✖️Página alternativa con etiqueta canónica adecuada: páginas cuya etiqueta canonical apunta hacia otra página valida, por lo tanto la URL canonicalizada no es indexada.

✖️Duplicada: el usuario no ha indicado ninguna versión canónica. Ocurre cuando Google determina que una URL es duplicada de otra de la misma web pero no se ha marcado cuál es la canónica, la importante, mediante una etiqueta rel=canonical. En este caso no la indexa y lo que deberías hacer es indicar la canónica u otros métodos.

✖️Duplicada: Google ha elegido una versión canónica diferente a la del usuario.

✖️No se ha encontrado (404). Cuando Google encuentra una URL mediante algún enlace (interno/entrante) pero la página devuelve un error 404 y por lo tanto no se puede indexar.

✖️Se ha retirado la página por una reclamación legal. La página en cuestión se ha eliminado del índice por alguna reclamación legal.

✖️Página con redirección. La página que se ha excluido redirecciona a otra, y por lo tanto no es posible indexarla. Google rastreará e indexará si se da el caso, la URL de destino de la redirección.

✖️Soft 404. Ya comenté lo que es un Soft 404. En este caso Google no indexa la página porque tiene este código de estado.

✖️Duplicada: la URL enviada no se ha seleccionado como canónica.


Interpretación de errores y advertencias

Una vez repasados todos los estados posibles que pueden aparecer en el informe de cobertura de Search Console voy a hacer un repaso de los errores y advertencias más comunes. Son aquellos que deberían preocuparnos algunos más, otros menos, pero que es sencillo de solventar.

Mi intención con este post es que sepas qué ocurre y qué debes hacer cuando aparecen estos avisos o cuando Search Console te envía a ti o a uno de tus clientes uno de esos correos, que en la mayoría de veces preocupan más de la cuenta.


¿Son tan graves este tipo de avisos, errores o advertencias?

¿Cómo los puedes interpretar correctamente?

¿Cómo solucionarlos?

¿Cómo saber si los has solucionado?


Errores más comunes en el informe de cobertura: interpretación y solución

Robots.txt ha bloqueado la URL enviada

robots.txt ha bloqueado la url enviada

En este caso lo que ocurre es que hay una URL que has bloqueado mediante Robotst.txt, seguramente porque no quieres que sea rastreada ni indexada. Ahora bien, si aparece este aviso es porque esa misma URL está en el Sitemap.xml que has enviado a Google Search Console.

Esto es incoherente, ¿verdad? Por un lado le dices a Google que está bloqueada pero por otro la pones en el Sitemap para que la analice.

Esto no es un error grave realmente, no es una catástrofe ni va a hacer que tu SEO se vea perjudicado, al menos si ocurre forma puntual, claro. Estás haciendo que Google rastree una URL que seguramente no quieres, porque por algo la has bloqueado por Robots, no?

¿Qué hacer para solventar este error?

Lo normal es que esa URL no sea relevante para ti, por lo que querrás desindexarla y a ser posible que Google no la rastree.

Lo primero sería quitarla del Sitemap, y esto depende cómo lo hayas creado. Si lo haces con Yoast por ejemplo, con marcar esa página como «noindex» la quitarás del Sitemap, y además estarás diciendo que no quieres que se indexe, dos pájaros de un tiro. Si haces esto mismo con Rank Math, pasará lo mismo, pero con Rank Math podrás quitar la URL del Sitemap mediante el ID, sin tener que ponerle «noindex».



Te recomiendo que si quieres desindexarla, incluso la quites del robots.txt y le pongas «noindex». De esta forma te asegurarás que los bots verán la etiqueta «noindex». Una vez desindexada por completo, puedes optar por ponerla en el robots.txt.


Digo esto porque si bloqueas una URL por robots.txt que a su vez tiene «noindex» puede que se indexe. Cuando esto ocurre, aparece un aviso en el informe de cobertura «Se ha indexado aunque el archivo Robots.txt la ha bloqueado».


Una vez hayas hecho lo que tienes que hacer, en el mismo informe de cobertura donde te aparece ese error, puedes pedir que te validen la corrección y en unos días quitarán el error si realmente se ha subsanado.

validad correccion

La URL enviada contiene «noindex»

url enviada contiene noindex

Este error es similar en todos los aspectos al anterior.

Has incluido en el Sitemap.xml enviado a Search Console una URL que está marcada con un «noindex» en la etiqueta meta name robots. Esto es incoherente, salvo que lo hayas echo a propósito. ¿A propósito? Sí, una forma de que los bots vean antes un «noindex» en una página es poner esa URL en el Sitemap y una vez desindexada, excluirla. No es necesario hacer esto pero en ocasiones acelera el proceso de desindexación de una página.

Para solucionar este error, que tampoco es que sea demasiado grave, bastaría con quitar el Sitemap esa página, siempre y cuando sea una página marcada correctamente con «noindex» porque quieres desindexarla.

Una vez hecho esto, puedes validar la corrección y esperar a que desaparezca el error.

Se ha indexado aunque un archivo robots.txt la ha bloqueado

indexado aunque robots.txt la ha bloqueado

Esto ya no se considera un error en el informe cobertura de Search Console, es una Advertencia.

Esta en concreto, que es bastante común, puede ocurrir por dos motivos:

  1. Has bloqueado una URL por robots.txt pero no está marcada con «noindex». El bloqueo con un Disallow en robots.txt no tiene por qué evitar la indexación, lo digo una vez más. Un bot se puede encontrar esa URL por otro medio, como un enlace interno, y si esa página a la que llega es indexable, a indexará.
  2. Has marcado una URL con «noindex» y la has bloqueado en robots.txt. Lo que ocurre lo he mencionado unos párrafos más arriba. El bot puede no acceder a una URL al estar bloqueada y por lo tanto no podrá ver que tiene un «noindex». Si esa URL venía de estar en el índice, puede que no se llegue a desindexar.

En cualquier caso, debes investigar por qué ocurre esto.

En el propio informe de cobertura, si haces click en cada URL aparecerá a la derecha un panel con estas dos opciones:

inspeccionar url search console

Al entrar en la primera, Google te da la información que tiene sobre esa URL:

Aquí vemos como en el apartado de «Detección» parece que en el Sitemap no la ha encontrado, tampoco la ha encontrado a través de una página de referencia concreta.

En el apartado de rastreo vemos la fecha del último rastreo, el user-agent y dice que no se permite el rastreo porque hay bloqueo por robots.txt y por lo tanto tampoco puede obtenerse la página. Al no poder hacer esto último, el bot no puede entrar a la página y descubrir que realmente (esta página que estoy analizando) tiene un «noindex».

Por ello en el apartado «Indexación» tampoco hay datos.

inspección urls search console

Resumen, la página se está indexando porque a pesar de tener un «noindex» Google no puede acceder a ella para ver ese «noindex».

Podemos saber rápidamente si esa página tiene «noindex» o no visitándola y recurriendo a una extensión de Chrome llamada «See Robots».

Como esta página tiene «noindex,follow» la extensión dice esto:


Actualización: SeeRobots ha dejado de funcionar. Ahora puedes utilizar Robots Exclusion Checker. Funciona genial y cumple la misma función.

Ya sabemos el motivo y ahora toca solucionarlo.

Otra cosa que podemos hacer, y que puede ser útil en alguna ocasión es recurrir a la opción «Probar Bloqueo de Robots.txt»

inspeccionar url search console

Esto te va a decir qué línea del robots.txt está bloqueando la URL que estás analizando (no te asustes, te llevará la webmaster tools antiguo).

Todas las conocidas Vs todas las enviadas

Al principio de este interesantísimo post (😎) he comentado que podemos utilizar el informe de cobertura para analizar el estado del sitemap.xml que enviamos a Search Console.

Dentro del informe de cobertura verás a la izquierda dos pestañas «Todas las enviadas» y «Todas las conocidas».

  • Todas las enviadas: hace el análisis sólo sobre las URLs que están en el Sitemap.
  • Todas las conocidas: hace el análisis tanto de las URLs enviadas en el Sitemap como las descubiertas por otros medios (enlaces internos, externos, redirecciones, etc).

¿Qué interpretaciones y lecturas podemos sacar de esta comparativa de las dos pestañas?

He aquí un caso real, de un ecommerce con Prestashop, más bien pequeño.

Si nos fijamos en las enviadas, desde el 21 de abril hay una bajada, se desindexaron casi todas las fichas de producto y se eliminaron del Sitemap.xml.

En en las conocidas, vemos como días después del 21 de abril hay un descenso de Válidas, es decir, de páginas que son indexables. Habría que analizar dentro de las Válidas los diferentes estados.

todas las conocidas - todas las enviadas search console

Vamos a hacer la lectura:

  1. Analizando las enviadas y por lo tanto el Sitemap.xml enviado, vemos como no hay ni advertencias ni errores, de las 56 URLs enviadas, 55 son válidas y una está excluida (Rastreada sin indexar).
  2. El 21 de abril se quitan del Sitemap cerca de 200 URLs y además se marcan con «noindex» y vemos como tres semanas después, en las Conocidas > Válidas, empiezan a disminuir. Google está empezando a quitar del índice las URLs que queríamos desindexar.
  3. Todavía hay un «gap» entre las Enviadas > Válidas y las Conocidas > Válidas. Todavía quedan por desindexar algunas de las 200 URLs que se marcaron como no indexables y se quitaron de sitemap.
  4. Esto anterior hace que dentro de Conocidas > Válidas, tengamos esto (mira las gráficas).

informe cobertura search console

De las 152 Válidas, hay 97 que no están en el Sitemap pero que todavía están indexadas. Aunque si vemos la gráfica inferior, vemos como poco a poco van desindexándose.

indexadas-no-enviadas-sitemap

De las 152 Válidas, 55 están enviadas e indexadas, es decir, son las que están en «Todas las conocidas > Enviadas», las enviadas a conciencia al Sitemap.

indexada enviada

Esto nos sirve para hacer un seguimiento de acciones como quitar 200 URLs del Sitemap y marcarlas con «noindex» para comprobar si se están desindexando, si la limpieza del Sitemap está bien hecha, si Google va cogiendo los cambios, si hemos cometido errores en el proceso, dejado algún cabo suelto, etc.

Esto es solo un ejemplo del uso que podemos darle al informe de cobertura, pero ahora que te he explicado todo lo que se puede hacer con él y cómo interpretar los mensajes y gráficas que tiene, es tu turno. Analiza, saca conclusiones y revisa los cambios que haces para que el rastreo e indexación de las páginas de tus proyectos esté perfecto.

2 Comments

Leave a Reply

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies