Horario de oficina de SEO, 4 de marzo de 2022

Publicado: 2022-03-22

Este es un resumen de las preguntas y respuestas más interesantes del Google SEO Office Hours con John Mueller el 4 de marzo de 2022.

ocultar contenido
1 Probar el marcado de esquema en el validador de schema.org frente a Google Search Console
2 razones por las que una página puede ser rastreada pero no indexada
3 ¿Eliminar listados de productos en un sitio de comercio electrónico puede ponerlo en desventaja?
4 La importancia de la estructura de enlace interna
5 Múltiples esquemas de productos en la página de listado de productos
6 ¿Su clasificación puede verse afectada si crea páginas en idiomas mixtos?
7 diferencias en el contenido entre las versiones móvil y de escritorio
8 ¿Puedes alojar tu mapa del sitio en una nube?
9 ¿El historial de un dominio puede afectar a tu sitio web?

Probar el marcado de esquema en el validador de schema.org frente a Google Search Console

7:41 “John, entonces mi primera pregunta es, Google Search Console arroja un error […] en el elemento de datos estructurados requerido. Pero cuando compruebo lo mismo en validator.schema.org, no muestra ninguna advertencia ni ningún error. Entonces, la primera pregunta es, ¿es el sitio adecuado para verificar la implementación de AMP de una página web? […]“

John respondió: “ Sí, entonces estas herramientas de prueba tienen propósitos ligeramente diferentes. Probablemente es por eso que estás viendo esa diferencia. La herramienta de prueba en schema.org se trata más de comprender el marcado de schema.org en general, en general, según los requisitos que tiene schema.org. Y la herramienta de prueba en Search Console se enfoca únicamente en lo que podemos extraer de los datos estructurados y usar para mostrar en la función de búsqueda. Así que realmente se enfoca en la parte de búsqueda de esa historia. Y dentro de la Búsqueda, solo usamos una pequeña parte del marcado de schema.org. Y a veces, tenemos requisitos ligeramente diferentes que tal vez requieran un elemento específico más de lo que requeriría el marcado base de schema.org. Y esa es a menudo la razón por la que ves esa diferencia. Y el validador de schema.org es para el marcado teórico, y el validador de Google es realmente para el lado práctico de la Búsqueda de Google.

9:20 “[…] Básicamente, no es un error. Es una advertencia en Search Console. Y cuando reviso los detalles en Search Console, simplemente dice que no lo estás haciendo bien. Entonces, ¿habrá una forma posible [de solucionar el problema], o mi equipo de desarrollo debería resolverlo?

John explicó: “Sí, si es una advertencia, entonces no me preocuparía. Básicamente es solo decir que podrías haber hecho algo diferente. […]. Lo que yo haría si desea averiguar cuál es exactamente la diferencia es verificar dos veces la documentación en developer.google.com para la búsqueda, donde tenemos todos los datos estructurados documentados y todos los campos obligatorios y recomendados. Y probablemente uno de los campos recomendados u opcionales es lo que activa esta advertencia”.

Motivos por los que una página puede rastrearse pero no indexarse

14:11 ¿Cuál es la posible razón por la que […] ciertas páginas no se indexaron, aunque se rastrearon varias veces?

John respondió: Puede suceder. Supongo que no es tan frecuente porque, por lo general, cuando decidimos rastrear algo, también estamos muy contentos de salir e indexarlo. Pero puede suceder que rastreemos una página y luego, al final, decidamos que, en realidad, no necesitamos indexarla.

[…] algunas situaciones comunes en las que eso puede suceder, que quizás no se apliquen en su caso, es si hay un código de error en la página. Primero tenemos que rastrearlo y luego vemos el código de error. Si hay un noindex en la página, también tenemos que rastrearlo primero y luego vemos el noindex. Si la página es un duplicado completo de otra cosa que ya hemos visto, la rastreamos, vemos que es un duplicado, pero nos enfocamos en la página principal nuevamente. Esas son situaciones normales en las que rastrearíamos algo y no lo indexaríamos. Pero también puede suceder que rastreemos algo y luego, cuando lleguemos a la indexación, decidamos, bueno, en realidad, queremos obtener algo más del sitio web.

15:41 "[...] ¿Qué otros factores [además de los ya mencionados] pueden hacer que Googlebot decida, oh, no queremos indexarlo al final?"

John dijo: “No lo sé de improviso. Creo que la calidad general del sitio web definitivamente juega un papel allí, pero por lo general, si no estamos convencidos de la calidad del sitio web, probablemente no rastrearíamos la página en primer lugar. Creo que esa es una situación un poco complicada. Y si miras en Search Console, creo que, en casi todos los sitios, tendrás la agrupación de descubierto pero no indexado y también rastreado y no indexado. Eso es, creo, bastante común en todos los sitios”.

La persona que hizo la pregunta quería saber si hay algo más que debería investigar, excepto la calidad de la página y los problemas técnicos. John recomendó que no se centren demasiado en una página: “ También creo que es importante no centrarse demasiado en esa página específica. Entonces, si está seguro de que, desde un punto de vista técnico, todo está bien, no asumiría que la calidad de esa página específica es un problema, sino más bien la calidad percibida de esa parte del sitio web o el todo el sitio web en sí. Ese es el lugar donde trataría de ver qué se puede hacer para mejorar las cosas, no solo esa página individual que no se indexó, sino cuál es el panorama general de esa página.

¿Eliminar listados de productos en un sitio de comercio electrónico puede ponerlo en desventaja?

21:48 Tenemos un sitio web de comercio electrónico y ahora estamos en una etapa en la que queremos realizar actualizaciones importantes en nuestras páginas de categorías. […] en un borrador, queremos deshacernos de las listas de productos. Así que tienes los listados de productos con la búsqueda por facetas, donde puedes filtrar por los productos que buscas. […] cuando eliminamos toda la lista de productos de las páginas de categorías, ¿tendríamos una desventaja en las clasificaciones porque, en primer lugar, todos los demás competidores tienen este tipo de listas de productos? Y segundo, supongo que este es un elemento tan establecido para las páginas de comercio electrónico que los usuarios esperan […] tener algún tipo de visión general de todos los productos y los filtros les permiten buscar los productos que desean.

John respondió: “ Yo no vería ningún problema desde el punto de vista de SEO. Creo que hay diferentes cosas que le gustaría tener en cuenta, […] para que aún podamos encontrar todos los productos individuales que tenemos enlaces limpios allí. Pero si solo está rediseñando esta página de categoría y haciendo que se vea más como una página informativa, no esperaría ningún problema con eso. Tampoco creo que hagamos nada especial con ese tipo de páginas de categoría en la Búsqueda de todos modos, así que desde ese punto de vista, básicamente solo estás cambiando el diseño.  

Creo que sería diferente si fuera una página de producto y la cambiaras por completo porque tratamos de reconocer las páginas de producto y averiguar dónde está el precio, dónde está la disponibilidad , ese tipo de cosas. Y si hizo que se viera completamente diferente […], entonces me imagino que eso afecta la forma en que seleccionamos las páginas de productos y si podemos mostrarlo en los resultados de Búsqueda de productos o no. Pero las páginas de categorías, que yo sepa, no hacemos nada especial con ellas. Entonces, si los oculta, esencialmente, y se asegura de que aún podamos encontrar los enlaces a los productos […] podría hacerlo. Pero si quieres que sean más útiles proporcionando más información sobre ellos, creo que es una buena idea”.

Al final de la pregunta, John agregó que es importante verificar los cambios desde la perspectiva del usuario : “[…] usted mencionó 'los usuarios se confundirían'. Lo comprobaría dos veces. Entonces, desde el lado del SEO, creo que está perfectamente bien, pero desde el lado del usuario, probablemente sea algo que quieras probar primero".

La importancia de la estructura de enlace interna

25:18 " Si tienes datos estructurados para la configuración de migas de pan, ¿los enlaces internos siguen siendo importantes para el SEO?"

John respondió: “Sí, absolutamente. Es algo en lo que la vinculación interna es supercrítica para el SEO. Creo que es una de las cosas más importantes que puede hacer en un sitio web para guiar a Google y guiar a los visitantes a las páginas que cree que son importantes. Y lo que creas que es importante depende totalmente de ti. Puede decidir hacer que las cosas sean importantes donde gane más dinero, o puede hacer que las cosas sean importantes donde sea el competidor más fuerte, o quizás sea el competidor más débil. Con los enlaces internos, realmente puedes enfocar las cosas en esas direcciones y esas partes de tu sitio. Y eso no es algo que simplemente pueda reemplazar con datos estructurados.

Entonces, solo porque hay datos estructurados en una página en algún lugar, no los vería como un reemplazo para los enlaces internos normales. Incluso si en los datos estructurados también proporciona URL, no usamos esas URL de la misma manera que usaríamos enlaces internos normales en una página. Así que definitivamente no es el caso que las anotaciones hreflang reemplacen enlaces entre versiones de países, o las anotaciones de ruta de navegación reemplacen enlaces entre diferentes niveles de un sitio web. Realmente debería tener enlaces HTML normales entre las diferentes partes de su sitio web. E, idealmente, no solo debe tener un conjunto básico de enlaces, sino que debe mirarlo de manera estratégica y pensar qué es lo que más le importa y cómo puede resaltar eso con su enlace interno.

Múltiples esquemas de productos en la página de listado de productos

29:50 Para una página de listado de productos, ¿podemos implementar múltiples esquemas de productos en la página de listado de productos?

John dijo: " Desde el punto de vista de nuestra política, no creo que debas hacer eso, al menos la última vez que verifiqué las políticas sobre datos estructurados, porque para los datos estructurados de productos, realmente queremos que se aplique a la primaria". elemento de la página. Y si tiene varios productos en una página, no es que uno de ellos sea el elemento principal de la página. Entonces, desde ese punto de vista, no debe usar elementos de datos estructurados de múltiples productos en una página de categoría […].

¿Su clasificación puede verse afectada si crea páginas en idiomas mixtos?

30:30 ¿Existe una mejor práctica para páginas con lenguaje mixto utilizado? Por ejemplo, nuestra escuela internacional en Japón atiende a familias japonesas y no japonesas, pero mantenemos la mayor parte de la información en nuestra página de inicio en inglés. También agregamos soporte en la página en japonés. […] Dado que nuestra comunicación en la vida real es un lenguaje mixto, hacer que la página de inicio refleje eso se sintió más natural. ¿Somos castigados en la búsqueda si una página es un idioma mezclado intencionalmente?”

John respondió: “No necesariamente diría que una página es castigada en un caso como ese. Pero tratamos de comprender cuál es el idioma principal de una página, y eso nos ayuda a comprender para qué tipo de consultas podríamos mostrar esta página. Creo que eso es un poco complicado en un caso como este.

También podemos entender cuando hay varios idiomas en una página. Simplemente hace que sea mucho más fácil para nosotros tener claro que, si alguien está buscando en inglés, esta es la página correcta para mostrarle. Así que podría imaginar algo como una página de inicio, tal vez tenga sentido tener esa combinación o una ligera combinación. Si tiene una página de inicio como inglés principal, tal vez incluya algunos elementos en japonés. Si tiene otra versión que es principalmente japonesa, con algunos elementos en inglés, está bien. Pero nos ayuda a comprender realmente que, en su mayor parte, esta es una página en inglés. Y si alguien está buscando en inglés un tipo específico de escuela internacional en Japón, entonces tiene sentido que digamos, bueno, aquí hay un contenido en inglés que sabemos que se ajusta a sus necesidades y que coincide con las consultas que nos dio. Entonces, desde ese punto de vista, no diría necesariamente que la página está castigada, pero hace que sea mucho más difícil para nuestros sistemas descubrir cómo clasificar esa página correctamente.

Una de las cosas en las que puede pensar aquí es buscar en Search Console qué consultas van a su sitio web o a su página de inicio. Y piense en cuál de estas consultas podría verse afectada si Google no entendiera el idioma correctamente. Y bien podría ser que si la mayoría de la gente está buscando su nombre o la marca de su escuela, esencialmente, entonces probablemente eso no se vea afectado en absoluto. Por otro lado, si la mayoría de las personas buscan consultas más amplias, consultas más genéricas, casi como una oración que coincidiría con algo en su página de inicio, entonces me imagino que sería un poco más difícil para usted aparecer en los resultados de búsqueda de , solo porque no estamos seguros de si su página de inicio está realmente en el idioma de esa consulta […].

Una cosa que también podría hacer, […] es hacer que su página de inicio sea una especie de versión bilingüe […] pero crear páginas separadas adicionalmente para el idioma individual de modo que si alguien está buscando información de formato largo sobre una escuela internacional como esto, todavía pueden encontrar esas páginas en inglés puro o en su mayoría en inglés y luego, desde allí, hacer la transición al resto de su sitio web […].

Diferencias en el contenido entre las versiones móvil y de escritorio

34:20 Si hay una diferencia entre el contenido de la versión móvil y la versión de escritorio, ¿significa que Google castigará al sitio web y afectará la clasificación del sitio web, o simplemente significa que Googlebot puede encontrarlo en la versión móvil, pero ganó? no ser capaz de clasificar?

John dijo: “ Entonces, en su mayor parte, cambiamos la mayor parte de nuestra indexación a la indexación móvil primero, lo que significa que solo miraríamos la versión móvil de un sitio web en un caso como ese. Entonces, esencialmente, si hay algo que es ligeramente diferente en la versión de escritorio de un sitio web, en su mayor parte, ni siquiera lo usaríamos para la Búsqueda. Entonces, no es que castiguemos un sitio web debido a una diferencia, sino que es como si solo miramos una versión del sitio web y ni siquiera sabemos qué hay en la otra versión para tratarlo de manera diferente. .  

Y para el puñado de sitios que todavía están en la indexación de escritorio, eso se aplica al revés. Por supuesto, si hay […] algo en la versión móvil que no está en la versión de escritorio, y el rastreador de escritorio lo está indexando, entonces realmente no lo veríamos. Rastreamos la versión alternativa de vez en cuando, pero no la rastreamos para recopilar más información, sino solo para confirmar que existe esta conexión entre la URL de escritorio y la URL móvil.

¿Puedes alojar tu mapa del sitio en una nube?

46:20 Tenemos una página realmente enorme con millones de URL y […] los mapas de sitio se están renovando actualmente. Y nuestro equipo de TI está considerando almacenar […] los nuevos archivos del mapa del sitio en nuestro servicio en la nube. Eso significa de example.com/sitemaps a cloud.com/sitemaps. Y nos preguntamos, ¿es eso un problema si almacenamos los mapas del sitio en la nube? Y si eso no es un problema, ¿deberíamos crear también una redirección permanente para la URL anterior para este ejemplo.com/sitemap, o cómo deberíamos planificar el movimiento?

John dijo: “ Definitivamente es posible alojar el archivo del mapa del sitio en otro lugar. Hay dos formas de hacerlo. Una es si tiene ambos dominios verificados en Search Console, entonces eso funciona. La otra forma es si lo envía con el archivo robots.txt, donde especifica "mapa del sitio:" y luego la URL del mapa del sitio. Eso también puede ir a un dominio diferente. […] También redirigiría el archivo del mapa del sitio anterior a la nueva ubicación solo para estar limpio, pero probablemente incluso si solo elimina la URL del mapa del sitio anterior y se asegura de enviar el nuevo correctamente, eso debería funcionar.  

Lo que podría ser un poco complicado es que no sé cómo Search Console mostraría eso directamente en la interfaz de usuario, en particular, si el archivo del mapa del sitio está en una ubicación diferente, si Search Console mostraría la información del mapa del sitio en el informe de indexación, por ejemplo. Pero eso es un problema de informes. Eso no es algo que dependa de la funcionalidad del archivo del mapa del sitio. En realidad, Search Console no lo muestra correctamente. Y, de nuevo, tal vez lo haga. Simplemente no estoy 100% seguro.

¿Puede el historial de un dominio afectar a tu sitio web?

49:40 “[…] Entonces [durante el anterior horario de oficina de SEO ] planteamos esa pregunta sobre el dominio con un historial como proveedor de servicios de acompañantes. […] el dominio tiene una larga historia porque la primera instantánea de ese sitio web es de 1997. […] relanzamos nuestro sitio web en junio del año pasado […]. Y el principal problema que tenemos es […] que todavía nos marcan [como contenido para adultos]. Y además, tenemos este problema […]: rastreado, actualmente no indexado. Y estamos tratando de entender si el historial del dominio realmente puede afectar que tengamos problemas con la indexación. […] creemos que el contenido que estamos publicando es de buena calidad. Está enlazado internamente y tratamos de construir un sitio de calidad. Donde luchamos en este momento es el rendimiento de la página, por lo que está en progreso en este momento optimizar para eso. Pero usamos prerender.io , por lo que lo que mostramos para Google ya es una versión prerenderizada. Entonces, cuando se trata de nuestra puntuación de Lighthouse, todo está bien. […] ¿Qué podemos mejorar o buscar para entender por qué no nos indexan? Estoy feliz de compartir la URL también.

John se ofreció a echar un vistazo a la URL más tarde y luego respondió: “ Por lo general, el lado de la indexación de las cosas no estaría relacionado si hubiera contenido para adultos en el sitio web antes.

El lado de la indexación podría verse afectado si el contenido que había antes era muy spam. Así que eso podría ser algo donde, desde el punto de vista de la indexación, solo toma un tiempo darse cuenta, oh, este nuevo sitio web en realidad no es spam en absoluto.

Pero si fuera simplemente porque antes había contenido para adultos, entonces podría imaginar que tal vez nuestros filtros de SafeSearch sean un poco lentos para reconocerlo. Sé que hemos tomado algunas medidas para hacerlo más rápido […], o tal vez hay algo más en SafeSearch que no funciona.

El lado de SafeSearch es algo que puede verificar si realiza una consulta en el sitio y luego activa y desactiva SafeSearch. Debería poder ver si algo de SafeSearch está sucediendo o no. Sin embargo, no ve eso con respecto a la indexación. Pero puedo echarle un vistazo a esto después, y podemos ver si hay algo muy obvio que pueda informarles.