Cómo resolver problemas de Google Search Console

Publicado el22 septiembre, 2022/última actualización31 diciembre, 2022/enSearch Console, google

Este artículo está orientado a explicarte y entender todos los apartados de Search Console de Google donde se te mencionan problemas encontrados por Google en tu web y la mejor manera de solucionarlos. He volcado en él mi experiencia profesional de algo más de trece años. Es un artículo de casi 7000 palabras. Te aconsejo el uso de la tabla de contenidos para ir a la sección que sea de tu interés. Te aconsejo también la lectura de mi guía SEO de cómo realizar un SEO de calidad.

Nos centraremos en los siguientes problemas:

Indexación.
Experiencia de usuario
Microformatos
Seguridad y acciones manuales

Recuerda acceder a la sección de mensajes de tu Search Console. Ahí se te mostrará información adicional de los errores observados entre otro tipo de mensajes.

Una vez que resuelvas los problemas Google los irá procesando y eliminando del informe sin que tu hagas nada más. Puedes acelerar el proceso solicitando validación (si los has resuelto previamente).

El proceso de validación puede tardar 28 días (a veces más). También puedes acelerar la validación de resultados individuales inspeccionando la url, si la url está indexada significa que pronto desaparecerá del informe. Si no lo está, debes probar la url publicada, si sale que no presenta problemas (todo en verde) o pequeños problemas que no impiden la indexación entonces es cuando puedes solicitar la indexación, Google la añadirá a una cola de rastreo prioritaria. Tienes hasta un máximo de 10 solicitudes por día. De esta manera aceleras el proceso.

Contrasta la información

Contrasta mis contenidos y todo lo que leas en internet.

Comparte en redes sociales

Trato de aportar calidad si te gusta lo que lees por favor comparte en tus redes.

¿Dudas o preguntas?

Deja un comentario con tu duda o pregunta y la contestaré

Problemas de indexación

En este apartado se suelen relacionar los siguientes problemas ordenados por el número de páginas afectadas, el problema que afecte a más páginas lo encontrarás en el primer lugar. Google sólo te mostrará hasta mil errores por tipo de problema aunque sean mucho más. Veamos los tipos de errores más habituales y como has de proceder.

Página con redirección
Error de redirección
Error de servidor (5xx)
No se ha encontrado (4o4)
Errores Soft 404
Página alternativa con etiqueta canónica adecuada
Bloqueada por robots.txt
Excluida por una etiqueta «noindex»
Duplicada: el usuario no ha indicado ninguna versión canónica.
Rastreada: actualmente sin indexar
Descubierta: actualmente sin indexar
Duplicada: Google ha elegido una versión canónica diferente del usuario
Se ha bloqueado debido a otro problema de tipo 4xx
Se ha bloqueado debido a que el acceso o está permitido (403)

Los problemas de indexación de páginas con vídeos (reciente novedad en Search Console de Google) se analizan mucho y bien en la siguiente publicación. Nuevo informe de indexación de vídeos de Search Console.

Cómo usar Google Search Console y resolver errores

¿Sabías que?

El número total de webs en el mundo se acerca a los dos billones.

¿Cuantas webs hay ahora mismo?

Error de redirección

Cuando establecemos redirecciones porque hemos cambiado las urls es necesario que detectes todos los enlaces tanto internos como externos que apuntan a urls que a su vez redireccionan a otras y cambiar el destino del enlace por el destino final al que redireccionan. Siempre tenemos que pensar en la experiencia de usuario incluso cuando salen de nuestro sitio.

Estos enlaces puedes detectarlos con screamming frog (ver imagen) u otras herramientas (ahrefs, SemRush. En el caso de WordPress puedes usar plugins como broken link checker (hay otros claro está).

En el caso de screamming frog tendrás un informe extenso, ten en cuenta que todo enlace que esté en la cabecera, menús, pie o cualquier otra zona de la página común todas las páginas del sitio web aparecerá en todas las urls. Los enlaces en el contenido no obstante sólo aparecerán en la url donde estén.

Puedes editar los enlaces a mano, pero imagina que tienes el mismo enlace repartido en el contenido de varias páginas. Considera reemplazarlos directamente desde la base de datos (se aconseja hacer una copia), en el caso de wodpress lo puedes hacer fácilmente con el plugin broken link checker que te he comentado antes. Pero puedes usar el plugin Better Search and Replace para reemplazar las urls viejas por las nuevas, esto hará que cada referencia en el contenido sea actualizada, inclusive el valor del href de cada enlace.

Por último evita las redirecciones en cadena, si A va a b y B va a C entonces modifica la primera redirección de manera que A vaya a C y elimina la segunda. Si tienes una redirección circular, producirás un bucle de redireccionamiento, A a B y B a A. O bien A a B, B a C y C de nuevo a A. Elimina la redirección que cierre el bucle.

Error de Servidor 5XX

Mi experiencia en gestión de proyectos me hace advertirte que la mayoría de las veces aquí solo encuentras falsos positivos, a veces los servidores tienen microcaídas o no están disponibles por tareas de mantenimiento. Si ves errores aquí, lo primero que debes hacer es ver las estadísticas de uso de tu servidor. Considera ampliar recursos.

No obstante siempre es adecuado que comprobemos que en efectos son falsos positivos. Para ver esto puedes usar de nuevo screamming frog en modo list. Verás como logras rastrear todas las urls con estados diferentes a 500. Además si obtienes el listado de errores 500 estoy seguro de que te saldrá vacío. No obstante si algún error 500 permanece. Realiza todas estas tareas:

Borra la caché del navegador
Elimina las cookies del dominio que estés visitando en tu navegador
Mira los logs de registro del servidor, todos los errores se listan aquí.
Repasa la configuración del htaccess, aunque un error aquí afectaría a todo tu sitio.
Aumenta el tiempo de ejecución de scripts. En ocasiones un proceso queda incompleto dejando tu sitio inconsistente. Aumenta el tiempo de espera de PHP.
Repasa la configuración de todo tu CMS.
Si estás accediendo a un recurso protegido del servidor o directorio, también puedes recibir este error, en este caso es un error legítimo.

Una vez terminado todo este trabajo solicita validar corrección. Ya sabes puede tardar 28 días.

Error no se ha encontrado (404)

Este error es siempre por la presencia de enlaces rotos o redirecciones a páginas de error que no existen. Tu misión es detectarlos. Puedes usar cualquier herramienta para su detección. La imagen muestra su detección mediante screamming frog.

En el caso de WordPress Igualmente puedes usar el plugin broken link checker que hemos comentado anteriormente para eliminar todos los enlaces rotos fácilmente. Lo ideal es que reemplaces la url del atributo href del enlace por una url válida. En WordPress nuevamente puedes recurrir a Better Search and Replace.

Solucionado los errores. Solicita validación. Ya sabes. ¡28 días!

Error soft 404

Un error soft 404 (error 404 blando) es casi siempre una página válida pero sin contenido. Es decir la página devuelve un estado 200 pero a la hora de visualizarla no hay contenido o este es muy escaso. Por ejemplo categorías vacías.

También he encontrado que Google lista este error cuando una página web redirige a otra que tampoco presenta información. Esto también sucede cuando se redirige al usuario a una página de error personalizada. No estoy en contra de esto ni mucho menos. Una página personalizada da al usuario la opción de seguir navegando en el sitio web.

La solución óptima es evitar la usuario que alcance páginas de escaso valor. Debes redireccionar estas páginas a contenido equivalente. Evita tener páginas sin contenido. Una página de categoría que no muestre artículos por falta de stock o cualquier razón, si ha de permanecer en tu proyecto web, puedes dotarla de contenido, sugerir productos alternativos, etc. Tienes muchas estrategias. Una vez que cada url del informe esté solucionado. Solicita validación.

Página alternativa con etiqueta canónica adecuada

Es normal que aparezcan urls en este apartado. De hecho yo no los tildaría de errores. Páginas que pueden aparecer aquí y que por tanto no te tienen que producir preocupación o acción alguna.

AMP. Cada url de una versión AMP (Accelerate Mobile Pages) declara como canonical la url del sitio principal del cual es precisamente versión. Esto forma parte del estándar de implementación de AMP. Lo normal es que todas las Urls de tu sitio en AMP aparezca aquí.
Paginaciones. Lo ideal es que cada página paginada tenga como url canónica la de la página sin paginación, pero realmente lo único necesario es que cada página paginada declare los microformatos prev y next, para indicar al buscador que se trata parte de una serie y que por tanto no se trata de una duplicidad. Google gracias a estos microformatos entiende que esto forma parte de una serie. Hay soluciones para obviar la paginación y mostrar todo el contenido mediante acciones de scroll o bien incluyendo los botones de «cargar más», ambas soluciones tienen el inconveniente de que se realizan mediante eventos de Javascript. Google no va pulsando botones, sólo sigue enlaces, esta información no sería analizada en el momento del rastreo del sitio. Muchos cms’s bloquean los resultados paginados, también es algo que se puede hacer en robots.txt. Google recomienda que no se bloqueen, pero todos sabemos que se aumenta la relevancia si se bloquean, además recordemos que hay un nuevo algoritmo de contenido útil lanzado hace poco.
Parámetros. Muchos cms’s bloquean los parámetros a nivel de metadato robots (no confundas con robots.txt), ciertamente la mejor solución es declarar la url canonical hacia la página sin parámetros. Incluso si el parámetro no es de ordenación y su presencia cambia significativamente el contenido de la página igualmente se sigue aconsejando la declaración de la url canónica, el motivo es que probablemente el título de la página seguirá siendo el mismo junto a la descripción seo. Bloquear parámetros a nivel de metadatos robots está bien, pero si además bloqueas en robots. txt mejorarás el presupuesto de rastreo de Google en tu sitio web evitando «hits» innecesarios. Si los parámetros además presentan paginación considera la información del párrafo anterior.
Url de productos. Este es un caso muy frecuente. Si te encuentras urls de productos en esta sección la razón más probable es que el producto tenga diferentes urls porque se encuentra en varias categorías, en la página de producto debes establecer como canónica la categoría principal que consideres más importante para ese producto. De esa manera indicas al buscador que URL es la que prefieres, si no lo haces Google puede determinar como url cualquier ruta que conduzca hacia el mismo, sólo va a indexar una (salvo error). Si tienes un producto llamado estuche-709 y está presente en la categoría estuche-vinos y en la categoría estuche, probablemente te interese mas la categoría estuche-vinos, si el producto es un estuche de botellas de vinos, o prefieres solo estuches si la url de producto ya contiene la palabra vinos, eso ya bajo tu consideración.
Url canónica hacia un sitio web externo. Este es un caso muy infrecuente pero yo me lo he encontrado. Te encuentras con que tienes una url listada aquí que no es ninguno de los casos anteriores, y cuando la exploras con la herramienta de inspección de urls, te encuentra con que Google encuentra como url canónica una url que pertenece a otro sitio web. Esto es una desgracia, Google entiende que ese contenido coincide con el tuyo y ese sitio web es mucho más relevante por tanto no indexará el tuyo. La solución pasa por presentar una solicitud basada en la ley estadounidense de protección de datos de autor (DMCA –Digital Millennium Copyright Act), aquí te puedes meter en problemas judiciales. En Europa puedes optar por la equivalente de propiedad intelectual. Quizás sea más rápido tratar de solucionar el problema por las buenas o cambiar tu contenido. Es muy mala idea copiar todo el contenido de un fabricante de un producto que a su vez vas a vender en tu web, trata de reescribirlo, plantea preguntas de interés sobre para que se puede usar el producto, cómo hacerlo, etc. Estas son las reglas del juego.
Categorías o etiquetas. Puede ocurrir que en el caso de que tengas una etiqueta o categoría que lista un sólo artículo, Google este tomando como referencia la categoría o etiqueta padre (o viceversa), la solución pasa por bloquear etiquetas y/o categorías vacías o con un sólo artículo. Yo sólo indexo categorías relevantes o aquellas que lo fueron en su momento y siguen teniendo mucho tráfico. A medida que vayas incorporando contenido, considera abrir la indexación a categorías que en su momento pueden ser relevantes.
Contenido similar. Esto sucede más de lo que se piensa, imagina que todos los años publicas tu artículo sobre San Valentin, quizás te acuerdes de lo que publicaste el año pasado, pero te aseguro que en unos años habrás perdido la perspectiva histórica, pero Google no, es posible que Google detecte contenido sobre la misma temática, y que tome como contenido de referencia esa publicación de San Valentin que triunfó hace unos años, que consiguió mucha autoridad y que provoque que tu nuevo artículo de San valentin no funcione. Yo en estos casos suelo tomar todo el contenido útil de ediciones pasadas siempre que no estén obsoletas, refundirla con el nuevo artículo, y establecer redirecciones de todos los artículos sobre esta temática al nuevo artículo (a esto se le llama auditoría de contenidos, ya hablaremos de un plan de marketing de contenidos en este blog más adelante). Recuerda actualizar todos los enlaces hacía el contenido que finalmente permanezca.
Falsos positivos. Esto también puede ocurrir en este apartado, a veces por ejemplo porque el cifrado deje de funcionar en el servidor o que falle temporalmente la redirección www. En este caso te aconsejo pedir validación y una vez que Google lo procese y elimine los falsos positivos, te concentres en solucionar los problemas de los casos anteriores.

Yo en este apartado no suelo pedir validación de todo, salvo el caso de presencia con muchos falsos positivos como te he indicado, bloqueo parámetros, paginaciones, paso de AMP y me concentro en la resolución caso por caso de todo lo demás. Recuerda que solo puedes enviar 10 solicitudes de indexación al día.

Rastreadores como Screamming frog pueden ayudarte a tener claro la declaración canónica de cada url de tu sitio web.

Bloqueada por robots.txt

En este apartado suele ser fruto de tus decisiones. Aquí debe aparecer bloqueado todo aquello que hayas considerado no relevante para tu proyecto. Es decir.

Paginación.
Parámetros. Ejemplo el parámetro de búsqueda de WordPress, parámetros de ordenación, filtros (precio, color, etc.), etc.
Contenido pobre. Categorías y/o etiquetas con un sólo artículos o vacías. Considera abrir la indexación si en un futuro este tipo de categorías son relevantes porque incrementas la publicación que relacionan. Páginas de gracias, página con escaso contenido y en general irrelevantes.
Contenido con temática diferente. Por ejemplo la página de aviso legal puede tener mucho contenido, pero… ¿Es útil que Google la indexe? Ojo es útil que la enlaces para que tus usuarios sepan en que condiciones pueden usar tu sitio web, pero quizás el contenido no esté acorde con lo que sueles publicar.

En cualquier caso siempre puedes comprobar el contenido con el probador de robots.txt de Search Console de Google. Verás un enlace a la derecha (ver la siguiente imagen), si estás bloqueando algo por error, a veces ocurre, pensamos que algo no está bloqueado y lo está porque no hemos gestionado bien robots.txt (usa allow para indicar que algo expresamente no puede bloquearse y hazlo a final de tu documento de robots.txt).

Excluida por una etiqueta «noindex»

En este apartado vas a encontrar todas las urls que estén bloqueadas a nivel de metadato robots. No confundas con robots.txt. Tu trabajo se limitará a comprobar que no haya alguna url erróneamente declarada como no index.

Es habitual que en esta sección encuentres urls con paginación, parámetros, páginas con poco contenido o contenido pobre que hayas bloqueado intencionadamente. Por contenido pobre puedes entender categorías que no listan ningún artículo, páginas de contenido legal, cookies, páginas de gracias, con contenido promocional de escaso interés para el proyecto, pruebas, páginas de archivo por fechas, etc.

Puedes confrontar lo que Google te ofrece este apartado contra un rastreo sobre tu sitio web, por ejemplo en el caso de que uses screamming frog (Ver siguiente imagen), fíjate en el apartado directivas (columna meta robots).

Si alguna url no merece estar aquí, elimina el bloqueo, inspecciona la url, si no está indexada, prueba la url pública y si todo bien, solicita indexación.

Duplicada: el usuario no ha indicado ninguna versión canónica.

Aquí vas a encontrar aquellas páginas que no declaran una versión canónica de la página, en este caso decidirá Google con que versión se queda. Es útil fijarse en las páginas de referencia que encuentra para tener una pista de lo que está sucediendo.

En el caso de WordPress aquí suele encontrarse las urls de adjuntos, lo solucionas activando la redirección de cada adjunto a la página padre que lo contiene, esto lo solucionas con plugins de seo como Yoast, Rank Math, etc.

Pero también puedes encontrar aquí urls paginadas y/o parametrizadas. Si consideras que Google no lo ha gestionado bien (suele hacerlo bien la mayoría de las veces) declara la url canónica, si quieres acelerar las cosas, inspecciona la url, prueba la url publicada y finalmente solicita indexación. Suele ayudar que bloquees parámetros y paginación, pero lo realmente útil es la declaración de la url canónica en la url que deba importar.

De nuevo suele ser interesante el uso de screamming frog para dar con todas las urls que no presenten una url canónica.

Rastreada: actualmente sin indexar

Debes comprender que la indexación de tu página es todo un proceso. En primer lugar Google debe descubrir tu página, esto no quiere decir que la haya rastreado aún, esto lo veremos en el apartado siguiente.

Si Google ha descubierto tu página, la meterá en una cola de rastreo para su procesamiento, repito procesamiento. Google rastreará tu página, comprobará el grado de relevancia frente al contenido de tu web y de terceros, su implementación técnica (seguridad, usabilidad, rendimiento es decir tiempo de carga), grado de autoridad, etc. El resultado de este proceso será la indexación de tu página y posicionamiento ante una serie de consultas. No lo dudes hay un factor de competencia también.

En este apartado suele aparecer_

Feed: Google suele tomar como referencia para su indexación la versión html, no el feed en xm.
AMP: Esto es un caso especial, Google ya no presenta ese «rayito» en la parte superior para distinguir una versión acelerada móvil, lo cual no quiere decir que no la presente a un usuario que accede desde un dispositivo móvil. Si haces bien las cosas probablemente no necesites una versión AMP, pero si tienes un sitio web con problemas de tiempos de carga, implementar una versión AMP no producirá problemas de contenido duplicado y puede ser una solución. Si implementas AMP, Google puede presentarlo ante un usuario que navega con un dispositivo, pero no será una página indexada en el directorio aunque Google la conozca, para google es una versión alternativa de tu página normal. No obstante algunas páginas AMP pueden acabar indexadas, puedes ver si hay alguna indexada en tu sitio con esta consulta avanzada: site:tudominio.extension AMP.
Urls modulares. Es interesante que bloquees todas las urls que no correspondan con el proyecto, a veces el software presenta urls alcanzables por el protocolo https, por ejemplo la piel (skin) de layer slider (un plugin de diapositivas), portfolios, o taxonomías de un constructor visual que no estés usando, ejemplos hay muchos. Bloquea mucho y bien, no necesitas hacer nada más.
Urls duplicadas. Las urls duplicadas también pueden aparecer aquí, si no puedes eliminar la url duplicada, cambia el contenido o bloquea.

El resto de urls que puedan aparecer aquí y te parezcan que merecen indexación, ya sabes, inspecciona, prueba la url pública, y si no hay problemas solicita indexación.

Descubierta: actualmente sin indexar

El primer paso para que Google indexe páginas de tu sitio web es que las descubra y que las anote en su cola de rastreo.

En ocasiones, Google aplaza el rastreo de tu sitio web, puede ser que por sobrecarga de tu sitio web, o sobrecarga del mismo rastreador, o que se haya agotado el presupuesto de rastreo asignado a tu sitio web, en cualquier caso, aquí encontrarás el contenido recién publicado.

Si la página no presenta problemas, acabará siendo rastreada. Puedes acelerar el proceso solicitando validación si todo el conjunto es apto, en el caso de que observes que no todas las urls merecen ser indexadas, puedes hacerlo igualmente a nivel individual.

Inspeccionas la Url, si no está en Google, pruebas la url publicada y si no hay problemas, solicita indexación.

Duplicada: Google ha elegido una versión canónica diferente del usuario

De nuevo te puedes encontrar el problema por presencia de parámetros y paginación, pero como ya hemos hablado mucho de esto, me centro en un problema que los que hemos dirigido proyectos de seo internacional a veces nos hemos encontrado y es el siguiente.

Traducciones incompletas

Imagina un sitio web con urls en castellano en su sitio principal y un directorio con contenido en portugués (llamado /pt).

A veces ocurre que las urls en este directorio no se han traducido aún al castellano, y estan en el directorio en portugués con su hreflang correctamente declarado, etc. Aquí puede pasar que aunque la página declare su propio canonical (ejemplo.com/pt/producto-x), Google seleccione como canónica la versión en español (ejemplo.com/producto-x).

Este es sólo un ejemplo, pueden acontecer más situaciones, pero siempre es la misma solución, dota a tu página en este caso la versión en portugués de contenido en portugués, si todas las urls son de este tipo solicita validación, en caso contrario inspecciona url por url, si no está indexado, pruebas la url publicada, y en caso de ausencia de problema, solicita indexación.

Me anticipo a tu observación, en este caso redirigir a la página en español no va a impedir que salga en esta apartado porque seguramente tu CMS contenga enlaces hacia esta página de producto, si bien es un mal menor. ¿Qué sentido tiene tener publicados productos en un directorio idiomático con un idioma que no es el esperado?. ¡Evita esto!

Se ha bloqueado debido a que el acceso no está permitido (403)

Bueno a veces Google no tiene porque meter la nariz en todas partes. Un sitio web puede tener contenido privado que para poder acceder al mismo es necesario alguna acción, lo más habitual es estar registrado como usuario y autenticar tu acceso, es decir hacer login. El rastreador Google no tiene la capacidad de acceder a sitio protegidos con usuario y contraseña.

¿Te preguntas entonces como Google puede detectar esto? Google sigue enlaces. Si un enlace apunta a un recurso con algún tipo de restricción, Google lo detectará por el estado que devuelve el servidor al servir el recurso.

Problemas que afectan la experiencia de usuario

Google suele ya presentar informes separados de la experiencia del usuario según el tipo de dispositivo sea móvil o un ordenador de escritorio. En ambos casos se examina el rendimiento (Web core vitals) y cifrado HTTPS, pero sólo en el primero se examina además la usabilidad móvil.

Todavía quedan sitios que tienen versiones separadas para ordenadores y escritorios, pero un gran porcentaje de sitios webs usan ya diseños responsivos (responsive design). Esto significa que el contenido se adapta a la pantalla del usuario.

Los problemas de cifrado son comunes a ambos. Pero en lo tocante a tiempos de carga, las métricas de rendimiento (Web core vitals) son más exigentes para dispositivos móviles que para escritorio. Si solucionas el problema en la versión móvil, seguro que no lo tienes en la versión de escritorio. En este ya extenso artículo, vamos a considerar pues la resolución de problemas en la versión móvil. Analizaremos pues:

Core web vitals
Usabilidad móvil
Cifrado HTTPS

search console de google - Experiencia de usuario

Tiempos de carga. Core Web Vitals

Hay que estar atento a las Core Web Vitals que son las nuevas métricas con las que Google mide el rendimiento de tu web. Estás métricas no dejan de evolucionar y hay un completo historial de ellas.

Por ejemplo no hace mucho también prestábamos atención al FID. Actualmente esta métrica ya no la consideran por tanto no la veremos. Por ahora no me la encuentro en los informes de problemas. Actualmente las métricas que más me salen cuando analizo este problema en search console son LCP y CLS. No obstante cuando usas Page Speed también verás otras dos, TBT y FCP. En algún proyecto he tenido alguna incidencia, pero al realizar acciones básicas de rendimiento se ha solucionado (ver imagen a continuación).

Por cierto Google evalúa estás métricas no a nivel individual de página, si no por grupos de urls que ofrecen una experiencia de usuario similar, por ejemplo urls de producto, urls de artículos del blog, urls de una versión en AMP, etc.

Core web vitals search console de google

Puntuación global de rendimiento

Fíjate en cómo se calcula ahora mismo y se pondera cada apartado SI, LCP, TTI, TBT y CLS. No sólo importa lograr una nota entre 90-100 a nivel global, sino que además es muy interesante lograr buenas notas en las métricas FCP, TBT, CLP y CLS.

Un suspenso en una sola de estas cuatro métricas motivará que tu página no sea adecuada a pesar de que el rendimiento global sea óptimo.

Rendimiento global

0-49 .Rendimiento Pobre. Tu página puede clasificar para móviles pero seguramente clasificaría mejor si tu rendimiento fuera mejor.
50-89 .Rendimiento medio o a mejorar.
90-100 .Buen rendimiento.

CLS – Cumulative Layout Shift – Cambio acumulativo del diseño

Esta métrica juzga los cambios de diseño en el contenido. Capas que se mueven y producen desplazamientos durante la carga de la página y estos desplazamientos pueden ocasionar que interacciones con elementos que no deseas, hacer clic en el botón equivocado, etc. Es complejo de analizar porque puede suceder que en un dispositivo no se muestre y en otro sí.

Necesitas herramientas como PapeSpeed Insights que analizan muchos dispositivos. Si no encuentras información de usuarios reales, empieza el problema, google insights te lo evaluará para google moto 4, con condiciones de red media (4G).

Puedes intentar usar emuladores, el más adecuado es usar ligthhouse sobre google chrome. Puedes habilitar el informe de capas y ver donde está el problema. Hay un complemento llamado CLS que es muy interesante para google crhome. Desarrollaré un artículo entero para CLS, más adelante.

En móviles deberás probar varios anchos de pantalla, google te informa en la auditoría CLS que capas son las que manifiesta este problema.

Cuando logras solucionar un problema de CLS y dentro de search console solicitas su evaluación. Google puede tardar hasta 28 días para evaluarlo pero vale mucho la pena cuando finamente ves esto.

Cosas que puedes hacer para solucionar esto

Crea una página en blanco. Bloquea esta página al buscador antes de publicarla. Pásala por PageSpeed Insights. Así podrás discriminar con claridad si hay problemas que no dependen del contenido. Me refiero a la cabecera, pie o barra lateral si la usas.
Usa la Api de Google Insights (page speed) en todo tu sitio web. Es una buena idea pasar todo tu sitio por la api de Google Insights. Esto lo puedes hacer con herramientas como screaming frog.
Páginas con un CLS superior a 0,1. Centra atención en todo elemento que produzca animaciones o que tarden en cargar: capas con movimiento (carrousel de productos, títulos animados etc.).
Activa la carga diferida de imágenes, mejorarás puntuación.
Cambia el orden de los elementos. Si tienes elementos que pueden producir cambios de diseño no es buena idea que estén al principio, puedes moverlos de manera que donde los coloques no produzcan desplazamientos de contenidos inferiores.
Considera fraccionar la página web en otras (yo puede que acabe fraccionando esta publicación porque comienza a ser muy extensa).

No te puedo ofrecer ejemplos de problemas CLS, graves, los he conseguido solucionar todos, pero en algún proyecto aún me queda solucionar problemas moderados. El aspecto que verás en search console es algo como esto.

Cómo puedes observar en la siguiente imagen, en efecto Google identifica grupos y establece un promedio, en este caso indica que necesita una mejora, pero debes empezar por los errores de ClS graves o muy deficientes. He omitido información del dominio, disculpa pero la privacidad de mis clientes es importante.

LCP- Largest Contentful Paint – Despliegue del contenido más extenso

Esta métrica a diferencia de la anterior si que está centrada en disminuir la carga. Se trata de analizar el despliegue del contenido más extenso. Es decir hasta que el contenido es visible e interactivo, hasta que se ha cargado todo el contenido.

Cómo puedes solucionar esto

Algunas cosas que puedes hacer aquí son:

Optimiza el peso de imágenes. Codifícalas en webp, hay todo tipo de herramientas en línea, apps, plugins que te pueden ayudar en esto.
Optimiza el tamaño. La imagen se debe almacenar al tamáño máximo que se vaya a mostrar.
Unifica y minimiza archivos css y javascript. En wordpress puedes usar autoptimize para esto.
Activa la carga diferida en imágenes.
Texto visible mientras se carga la web. Si es necesario no uses fuentes de google, mejora mucho si se activa Swapp en los estilos CSS. Si es necesario usa solo fuentes predeterminadas.

Cómo puedes observar en la anterior imagen, en efecto Google indentifica grupos y establece un promedio, en este caso indica que que la experiencia del usario es deficiente, este grupo de páginas no será clasificado como apto para dispositivos móviles.

Esto no quiere decir que google no indexe las páginas, pero su visibilidad será mucho menor en dispositivos móviles. Tener buena experiencia de usuario es vital y hay que tener en cuenta que el tráfico movil ya es el predominante en la mayoría de los nichos. Seguro que el tuyo no es una excepción. He omitido información del dominio, disculpa pero la privacidad de mis clientes es importante.

FCP- First Contentful Paint – Primer despliegue de contenido

Se mide aquí el tiempo transcurrido desde que comienza la carga de la página hasta que todo el contenido es visible.

Cómo solucionar estos problemas

Algunas cosas que puedes hacer aquí son:

Sólo cargar el CSS que se vaya a usar.
Preconecta los recursos. Usa rel=»preconect» en el tag link a la hora de solicitar un recurso a un tercero. La imagen se debe almacenar al tamaño máximo que se vaya a mostrar.
Reduce el tiempo de respuesta del servidor. Vale te cuento algunas cosas. Usa un buen Hosting. Cachea en memoria Ram. Optimiza tus bases de datos.
Evita redireccionamientos. Limpia tu web de todos los enlaces o funcionalidades que produzcan redireccionamientos. Evita especialmente los redireccionamientos en cadena.
Precarga los recursos clave. Se trata de que declares los enlaces de precarga a recursos importantes, sencillamente añade el atributo rel=»preload» a tu tag link dentro de la sección de cabecera de tu web.
Caché. Usa una buena caché si es posible en memoria RAM. Acelerara mucho tu página almacenando el html directamente.
Procurar que el texto se mantenga visible. Lo hemos visto ya en puntos anteriores. Mismo problema y solución.
Texto visible mientras se carga la web. Si es necesario no uses fuentes de google, mejora mucho si se activa Swapp en los estilos CSS. Si es necesario usa solo fuentes predeterminadas.
Reduce las solicitudes HTTP. Activa la expiración de js y css. Usa css sprites en tus estilos. etc.

Observación. Gestiono muchas propiedades en Search Console de Google y por ahora no he topado con este error en ninguna de ellas. También es verdad que intento solucionar los problemas antes de que acaben rastreados por Google.

TBT- Total Blocking Time – Tiempo de bloqueo total

Esta métrica mide la diferencia de tiempo entre el FCP y el tiempo para interactuar TTI (Time to Interactive). Esta métrica es de las más complejas de solucionar. A veces lo más sencillo es pensarse mucho y bien que necesitas usar, a veces no es necesario tener un plugin activado si solo lo vas a usar para momentos puntuales.

Si en la auditoria TBT te salen problemas, mira bien las urls eso te da la pista de que plugin está causando el problema. A veces actualizar el plugin o usar otro equivalente lo soluciona.

Igualmente trata de disminuir peticiones http para mejorar este apartado. Sobre todo vigila la carga de javascript de tu proyecto web. Minifica el código y trata de comprimirlo. Remueve todo el código que no uses.

0-200 .Milisegundos. Buen rendimiento.
200-600 .Milisegundos. Rendimiento medio o a mejorar.
Mas de 600 .Milisegundos. Rendimiento Pobre. Tu página puede clasificar para móviles pero seguramente clasificaría mejor si tu rendimiento fuera mejor.

Usabilidad móvil

El informe de usabilidad móvil de Google suele ser muy exacto en los tipos de errores. El primer paso es siempre el mismo, debes probar la url publicada, esto hará que seas redirigido al test de usabilidad móvil de Google. En ocasiones se tratan de falsos positivos provocados por el bloqueo de rastreo a archivos CSS. Este test te indicará con exactitud el tipo de problema a corregir. Habitualmente suelen ser los siguientes:

El contenido es más ancho que la pantalla. En la mayoría de los casos son elementos con una mala programación de estilos. El diseño responsivo de un sitio web ha de contemplar todos los casos y no siempre es así, por ejemplo inserción de tablas html. También he de decir que a veces se incorporan contenidos con copia y pega y se trasladan estilos con la declaración «Important!» y esto provoca que se sobreescriban los estilos del tema de tu CMS. Pueden haber muchas causas, pero estas son las más comunes.
Los elementos en los que se puede hacer clic están demasiado cerca unos de otros. Este es un error muy común, la mayoría de las veces es porque en el menú hamburguesa hay algún elemento que en su desplegado tapa un elemento inferior en lugar de desplazarlo. Suelen ser errores que se pasan porque no se examina todos los eventos, sólo se contempla el diseño. También debes vigilar la capa de cookies y la zona de enlaces del pie inferior.
El texto es demasiado pequeño para leerlo. Verifica los tamaños de fuente en tu CSS. Al menos 12 px en al menos el 60% del texto de la página.

Para cada tipo de error suele ser de utilidad mirar los apartados siguientes de dicho test de usabilidad:

HTML: Te remarca en negrita las zonas de código donde se rastrea el problema.
Captura de pantalla: Da mucha información de la zona donde ocurre el error.
Más información: Aquí puedes comprobar si el problema es el bloqueo de algún script al rastreador, o bien porque hay recursos que no se cargan.

Si deseas información de todos los tipos de errores de usabilidad que se pueden encontrar entonces te recomiendo la lectura de esta página del soporte de Google.

Usabilidad móvil Search Console de Google

Nuevo informe HTPPS de Search Console de Google

Google ha lanzado recientemente un nuevo informe sobre el cifrado HTTPS. En realidad los errores son los mismos. Lo que ha cambiado es la presentación del informe, ahora resulta mucho más claro.

Este informe se ha presentado el 14 de Septiembre de 2022 y todavía esta en fase de implementación, el tipo de errores a mostrar todavía está en fase de implementación no obstante te voy a mostrar los que ya aparecen y como solucionarlos a continuación. Para ello te remito al siguiente artículo:

Cómo solucionar los errores en el nuevo informe HTPP de Search Console.

Nuevo informe HTPPS de Search Console de Google

Microformatos J-son

Google ha indicado su preferencia por la implementación de microformatos con scripts J-son. El resto de mejoras, compras que puedes observar en Search console. Suelen estar implementados de esta manera. Con independencia del CMS que uses es fácil incorporarlo, no has de pelearte con el código, puedes usar generadores de microformatos. De este modo puedes implementar Preguntas frecuentes, Instrucciones, fragmentos de producto, fichas de anunciantes, logotipos, etc.

Si no completas todos los campos puede pasar dos cosas:

Advertencias. Se tratan de campos no obligatorios, el fragmento enriquecido generado en las SERPS podría ser mucho mejor y con más visibilidad si los cumplimentas.
Errores. Hay campos obligatorios que no se han atendido.

Datos estructurados que no se pueden analizar

En este apartado Google te presentará todas las urls que incorporan declaraciones de microformatos que no se entienden, usualmente son errores de implementación, faltan caracteres de separación como la «;», o caracteres de cierre como «}», en definitiva problemas de este tipo.

Informe de mejoras – Compras

A medida que vayas incorporando microformatos en tu sitio web, estos irán apareciendo en este informe de mejoras o compras de Search Console de Google. El estado ideal es la ausencia de errores.

Aquí encontrarás pues tres estados. Elementos válidos, elementos válidos pero con aspectos a mejorar y elementos no válidos. Si además has implementado una versión AMP de tu página, también la encontrarás en este apartado.

No es el objetivo de este artículo examinar todos los problemas a resolver de todos los microformatos que puedes implementar porque actualmente son muchos y google sigue añadiendo funcionalidades a su colección de datos enriquecidos o galería de búsqueda que es como ellos la llaman.

Centraremos la atención en:

AMP
Rutas de exploración
Preguntas frecuentes
Recetas guiadas
Instrucciones
Recetas
Fragmentos de reseñas
Fragmentos de productos
Fichas de comerciantes
Cuadro de búsqueda de enlaces de sitios

No obstante si necesitas que incorpore algo más. ¡Me lo puedes pedir!

Rutas de exploración – Breadcrumbs

Normalmente los problemas que suelen aparecer aquí son errores en la implementación del microformato breadcrumbs, este microformato suele implementarse con microdata en lugar de scripts j-son. Te será de utilidad pasar la url con el problema por el validador de Schema.

También puedes usar la prueba de resultados enriquecidos de Google (Ver siguiente imagen) en muchas ocasiones son falsos positivos, recuerda que es un elemento programado con microdata, si falla, fallaría en todo el sitio. Aquí si que te aconsejo validación en bloque si no has observado problemas.

Errores AMP (Accelerate Mobile Pages)

A continuación vamos a examinar los errores más habituales que te puedes encontrar en este apartado y como solucionarlos.

Hay un atributo o un valor de atributo no permitidos en la etiqueta HTML. Este es muy sencillo de corregir. Cuando exploras el ejemplo proporcionado por Google te indica el error o errores de código que detecta. Por ejemplo un atributo Width dentro de una etiqueta HR.
Error de servidor (5xx). La mayoría de las veces son falsos positivos, procede igual que en el apartado de errores 5xx que hemos explicado anteriormente.
La secuencia de comandos insertada es demasiado larga. El límite es de 100000 bytes. Esto sucede cuando hay presentes scripts dentro de la página de AMP que superan estos valores, la única solución es no insertarlos directamente en el código, puedes usarlos declarando el script en la sección head de la página no en el contenido.
Problema de rastreo. Se soluciona inspeccionando la url, si no está la url en Google, prueba la url publicada y si no hay problemas, solicita validación.

Si quieres una relación completa de errores AMP te aconsejo que consultes la siguiente página de soporte de Google. No es complicado solucionar cada tipo de error porque suelen estar muy bien descritos. Si necesitas ayuda con algo, me puedes contactar y lo solucionamos.

Seguridad y acciones manuales

Acciones manuales

Es ya una rareza encontrar acciones manuales en un sitio web, Google trata de automatizar a fondo el trabajo. No obstante si recibieras una penalización manual, se detallaría la naturaleza de la misma y tendrías que enviar una solicitud de reconsideración. Actualmente las penalizaciones son automáticas, tu sitio dejará de estar penalizado en cuanto corrijas lo que te produzca dicha penalización, esto no lo encontrarás en search console. Lo mejor es realizar una completa auditoria de tu sitio web para ver qué es lo que te está ocurriendo.

Problemas de seguridad

Los problemas de seguridad que se te pueden comunicar pueden ser muy diferentes. Ten en cuenta que algunos de ellos pueden producir que tu sitio web sea incluso hasta desindexado. Si Google encuentra código malicioso en tu sitio web aparecerá en este informe, sobre todo aquel código que pueda hacer que desde tu sitio web se haga una redirección a otro sitio.

Si necesitas ayuda no obstante con alguno de estos apartados, ponte en contacto conmigo y lo valoramos.

Fuentes

A continuación cito las fuentes que me han permitido redactar este artículo. Es un largo artículo y la redacción de esta guía de resolución de problemas de Search Console de Google se ha basado en mi experiencia profesional de más de 13 años en este sector y la siguiente documentación.

https://developers.google.com/search/docs/advanced/structured-data
https://developers.google.com/search/docs/advanced/ecommerce/pagination-and-incremental-page-loading?hl=es
https://developers.google.com/search/docs/advanced/crawling/consolidate-duplicate-urls?hl=es
https://support.google.com/webmasters/answer/7440203
https://support.google.com/webmasters/answer/9205520#page_groups
https://developers.google.com/search/docs/advanced/structured-data/search-gallery?hl=es-419
https://support.google.com/webmasters/answer/7478053#amp_crawl_issue
https://support.google.com/webmasters/answer/9063469
https://web.dev/font-size/
https://developers.google.com/speed/docs/insights/v5/about#score
https://web.dev/lighthouse-total-blocking-time/#how-lighthouse-determines-your-tbt-score

0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir!

Cookie	Duración	Descripción
cookielawinfo-checbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-advertisement	1 year	Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-non-necessary	1 year	Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Non-necessary" category .
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
cookielawinfo-checkbox-preferences	1 year	This cookie is set by the GDPR Cookie Consent plugin to check if the user has given consent to use cookies under the "Preferences" category.
cookielawinfo-checkbox-uncategorized	1 year	The cookie is set by the GDPR Cookie Consent plugin to record the user consent for cookies in the category "Uncategorized".
CookieLawInfoConsent	1 year	Records the default button state of the corresponding category & the status of CCPA. It works only in coordination with the primary cookie.
PHPSESSID		This cookie is native to PHP applications. The cookie is used to store and identify a users' unique session ID for the purpose of managing user session on the website. The cookie is a session cookies and is deleted when all the browser windows are closed.
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.

Cookie	Duración	Descripción
YSC		This cookies is set by Youtube and is used to track the views of embedded videos.
__utma	2 years	This cookie is set by Google Analytics and is used to distinguish users and sessions. The cookie is created when the JavaScript library executes and there are no existing __utma cookies. The cookie is updated every time data is sent to Google Analytics.
__utmb	30 minutes	The cookie is set by Google Analytics. The cookie is used to determine new sessions/visits. The cookie is created when the JavaScript library executes and there are no existing __utma cookies. The cookie is updated every time data is sent to Google Analytics.
__utmc		The cookie is set by Google Analytics and is deleted when the user closes the browser. The cookie is not used by ga.js. The cookie is used to enable interoperability with urchin.js which is an older version of Google analytics and used in conjunction with the __utmb cookie to determine new sessions/visits.
__utmt	10 minutes	The cookie is set by Google Analytics and is used to throttle the request rate.
__utmz	5 months	This cookie is set by Google analytics and is used to store the traffic source or campaign through which the visitor reached your site.

Cookie	Duración	Descripción
CONSENT	2 years	YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
_ga	2 years	The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.
_gat_UA-20621967-1	1 minute	A variation of the _gat cookie set by Google Analytics and Google Tag Manager to allow website owners to track visitor behaviour and measure site performance. The pattern element in the name contains the unique identity number of the account or website it relates to.
_ga_EVMLSP7VGF	2 years	This cookie is installed by Google Analytics.
_gid	1 day	Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.

Cookie	Duración	Descripción
IDE	2 years	Used by Google DoubleClick and stores information about how the user uses the website and any other advertisement before visiting the website. This is used to present users with ads that are relevant to them according to the user profile.
NID	5 months	This cookie is used to a profile based on user's interest and display personalized ads to the users.
test_cookie	15 minutes	The test_cookie is set by doubleclick.net and is used to determine if the user's browser supports cookies.
uid	1 year	This cookie is used to measure the number and behavior of the visitors to the website anonymously. The data includes the number of visits, average duration of the visit on the website, pages visited, etc. for the purpose of better understanding user preferences for targeted advertisments.
VISITOR_INFO1_LIVE	5 months	This cookie is set by Youtube. Used to track the information of the embedded YouTube videos on a website.
yt-remote-connected-devices	never	YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id	never	YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId	never	This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests	never	This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.

Cookie	Duración	Descripción
DEVICE_INFO	5 months 27 days	No description
wevarnishpass	past	No description