Horario de atención de SEO: 8 de octubre de 2021

Este es un resumen de las preguntas y respuestas más interesantes del Google SEO Office Hours con John Mueller el 8 de octubre de 2021.

El número de páginas indexadas frente a la autoridad del sitio

03:52 “Así que has recomendado varias veces en el pasado que los sitios grandes […] se centren en un conjunto más pequeño de páginas […]. El sitio en el que estoy trabajando en este momento, tenemos […] como 1,000 páginas que no reciben tráfico, que son antiguas, por lo que he estado recomendando eliminarlas. Pero hay una pregunta que tiene nuestro equipo de desarrollo de que tenían la impresión de que cuantas más páginas haya indexado Google de su sitio, mayor autoridad le atribuye al sitio, y son reticentes a eliminar cualquier página. ¿Podría arrojar algo de luz sobre eso?”

Como dijo John, “Definitivamente no es el caso de que si tiene más páginas indexadas, pensemos que su sitio web es mejor. […] A veces, tiene sentido tener muchas páginas indexadas. A veces, son páginas útiles para indexar de esa manera. Pero no es un signo de calidad con respecto a la cantidad de páginas indexadas. Y especialmente si estás hablando de […] 1000, 2000, 5000 páginas, es un número bastante bajo para nuestros sistemas en general. Y no es que diríamos que 5000 páginas son mejores que 1000 páginas. Para nosotros, es como, bueno, es un sitio web pequeño, y nos las arreglamos con lo que podemos sacar allí. Y, por supuesto, el sitio web pequeño es relativo. No es como decir que es un sitio web irrelevante. Puede ser pequeño, pero aún así puede ser muy útil […]”.

Evaluación del propósito principal de un sitio web

10:03 “La última vez hablamos sobre algunos problemas con el sitio web […] – es un sitio web de comercio electrónico donde tenemos información y cosas transaccionales. […] Su consejo fue separar un poco este contenido en páginas orientadas a la transacción y orientadas a la información. Así que tengo otra pregunta con respecto a esto. Si tiene, digamos, un sitio web de comercio electrónico, y tiene un gran blog, o una revista, o algo así donde tiene mucha información, pero es una sección antigua. Y por otro lado, tienes todas estas páginas de productos, categorías, etc. Entonces, ¿este enorme bloque con material puramente informativo le daría a todo el sitio web un toque o carácter informativo para que Google diga, oh, no estamos seguros si esto es […] algo donde las personas pueden obtener información en lugar de comprar cosas, o es ¿Esta evaluación se hizo por página?

John dijo: “[…] Tengo entendido que esto es más una cosa a nivel de página. […] Muchos sitios web solo tienen una combinación de diferentes tipos de contenido. Y luego intenta averiguar cuáles de estas páginas coinciden con la intención del buscador e intenta clasificarlas de manera adecuada. […]

Quiero decir, eso se ve con frecuencia en los sitios web de noticias. […] Tienen los eventos recientes, pero también tienen secciones para eventos más antiguos que tuvieron lugar, o […] para otros grandes eventos, tienen una sección de archivo aislada. Y esas son intenciones muy diferentes, si quieres algo realmente ahora que está sucediendo o si quieres algún tipo de investigación informativa, contenido de tipo perenne.

[…] Tenemos que mirarlo página por página , y no decir, oh, este es un sitio web de investigación porque hay algo de contenido de investigación aquí”.

Redirección de enlaces

13:21 “Estamos viendo que la gente está enlazando a […] nuestra, digamos, subcategoría de páginas. Y el problema es que […] nuestro contenido va y viene, lo que significa que a veces aparece más contenido en algunas categorías. A veces, el contenido se elimina. Y así se pueden crear subcategorías y también pueden desaparecer. Y estamos viendo un montón de referencias de backlinks porque están enlazando a subcategorías que ya no existen. Mi pregunta aquí es: ¿está bien redirigir […] estos enlaces a la categoría principal? Y si lo hacemos, ¿cómo lo hacemos, con 302, por ejemplo? Como una redirección temporal, porque en el futuro, esta subcategoría podría volver a llenarse con contenido, […] no es una redirección permanente”.

John respondió: “Entonces, si vemos que esto sucede a una escala más grande que redirige al nivel principal, probablemente lo veríamos como un 404 suave. […] Y en lugar de un código 404, estás redirigiendo, y tal vez eso es mejor para los usuarios, pero lo vemos como un 404. […] Si tiene sentido desde el punto de vista del usuario redirigir, entonces simplemente lo haría.

[…] Con respecto a 301 o 302, no creo que importe allí, porque lo veríamos como un 404 suave o lo veríamos como una pregunta de canonicalización. Si es un 404 suave, entonces el código no importa. Si se trata de una pregunta de canonicalización, todo se reduce a qué URL mostramos en los resultados de búsqueda. Y, por lo general, el de mayor nivel tendrá señales más fuertes de todos modos, y nos centraremos en el de mayor nivel. Así que no importa si es un 301 o un 302 en ese caso.

[…] Si lo vemos como un 404 suave, […] ralentizaríamos el rastreo de esa URL en particular porque no hay nada aquí […]. Si lo vemos como una redirección […], no necesitamos rastrear esto todos los días, porque nos enfocamos en la URL principal. Así que creo que en ambos casos, ralentizaríamos el rastreo de esa URL hasta que obtengamos nuevas señales que nos digan, en realidad, esto es quizás algo nuevo nuevamente. […] Eso sería como un enlace interno, o un archivo de mapa del sitio […]. Y esa sería la señal más fuerte para que volviéramos a gatear. Pero creo que la desaceleración del gateo sería similar en todos estos casos.

[…] Creo que [actualizar] los mapas del sitio por sí solos probablemente no sea suficiente. Realmente me aseguraría de que la vinculación interna también sea clara ”.

Recuperación de actualizaciones principales

18:34 “Entonces, hace aproximadamente un año, vimos una disminución significativa en el tráfico. Después de la auditoría, […] todas las señales apuntaban a que el sitio tenía problemas de calidad. Pudimos abordar esos problemas en febrero de este año. Y para la actualización principal de junio, vimos algunos aumentos. Pero todavía no está al nivel en el que solíamos estar antes de la disminución hace aproximadamente un año. Entonces, mi pregunta son los problemas de calidad del sitio, si ese ha sido el caso, ¿es esta la recuperación que podemos esperar, o podemos esperar más recuperación si creemos que hemos abordado todos los problemas identificados […]?

John dijo: “[…] No es tanto que lo consideremos como una situación en la que tienes que arreglar algo. Pero más bien […] si trabajas para mejorar la relevancia de tu sitio web, entonces […] tienes un mejor sitio web. Así que no es que […] vamos a cambiarlo de nuevo al estado anterior. […] No es igual o comparable a antes, por lo que sería un poco complicado esperar que cambie al estado en que estaba antes […].

[…] Con las actualizaciones principales, no nos enfocamos tanto en problemas individuales, sino en la relevancia del sitio web en general . Y eso puede incluir cosas como la facilidad de uso y los anuncios en una página, pero es esencialmente el sitio web en general. Y, por lo general, eso también significa el enfoque del contenido, la forma en que presenta las cosas, la forma en que deja en claro a los usuarios qué hay detrás del contenido, como cuáles son las fuentes […]. Si realmente desea que Google vea su sitio web como algo significativamente mejor, probablemente también deba trabajar en el lado del contenido .

[…] Piensa dónde podría haber contenido de baja calidad, dónde podrían confundirse los usuarios cuando visitan mi sitio web. ¿Y esa confusión es algo que podemos abordar con problemas técnicos, con cambios de UX? ¿O realmente tenemos que cambiar parte del contenido que presentamos?”

Enlaces en publicaciones de invitados

28:24 “[…] Si [un sitio web tiene] una publicación de invitado, y Google no sabe si es paga o no, ¿cómo determinará Google que [debería] tomar este enlace o quemarlo? ¿Cuál es la respuesta para que estemos a salvo desde todos los ángulos?

Según John, “[…] Nuestra guía para enlaces y publicaciones de invitados es que no deben seguirse . […] Realmente me aseguraría de que los enlaces no sean de seguimiento para que genere conciencia, hable sobre lo que está haciendo, lo esté haciendo para que los usuarios puedan ir a su página. Pero esencialmente, es un anuncio para su negocio. Entonces, desde ese punto de vista, simplemente los haría no-follow”.

El precio del producto como factor de clasificación

32:25 “Si hay dos sitios de comercio electrónico de la competencia que venden exactamente el mismo producto: un sitio web ofrece el producto a $500 y el otro a $100, todas las señales de SEO son iguales. ¿El sitio web menos costoso tendría una mejor oportunidad de clasificar porque hay una gran diferencia de precio para exactamente el mismo producto?”.

John dijo: “Entonces, puramente desde el punto de vista de la búsqueda en la web, no. No es el caso de que intentemos reconocer un precio en una página y lo usemos como un factor de clasificación. Así que no es el caso que diríamos que tomaremos el más barato y lo clasificaremos más alto […].

Sin embargo, muchos de estos productos también terminan en los resultados de búsqueda de productos, lo que podría deberse a que usted envía un feed o a que reconocemos la información del producto en estas páginas. Y los resultados de la búsqueda de productos, no sé cómo están ordenados. Puede ser que tengan en cuenta el precio o cosas como la disponibilidad […].

Entonces, desde el punto de vista de la búsqueda web, no tomamos en cuenta el precio. Desde el punto de vista de la búsqueda de productos, es posible . Y creo que la parte complicada, como SEO, es que estos diferentes aspectos de la búsqueda a menudo se combinan en una página de resultados de búsqueda, donde verá resultados web normales, y tal vez verá algunos resultados de productos al lado, o tal vez verás alguna mezcla de eso […]”.

Mover URL entre mapas de sitio

34:04 “Si tenemos 200 archivos de mapa de sitio y del 20 % al 30 % de las URL saltan de un archivo a otro cada semana, ¿qué tan malo puede ser? ¿O deberíamos mantener estrictamente nuestras URL en el mismo archivo para siempre?”

“[…] Nuestra recomendación suele ser mantener la misma URL en el mismo archivo de mapa del sitio . La razón principal de esto es que procesamos los archivos del mapa del sitio a diferentes velocidades. Entonces, si mueve una URL de un archivo de mapa de sitio a otro, es posible que tengamos la misma URL en nuestros sistemas desde varios archivos de mapa de sitio. Y si tiene información diferente para esta URL, como diferentes fechas de cambio, por ejemplo, entonces no sabríamos qué atributo usar realmente.

Entonces, desde ese punto de vista, si lo tiene siempre en el mismo archivo de mapa del sitio, entonces es mucho más fácil para nosotros decir, oh, tenemos la información para esta URL aquí, y podemos confiar en esa información porque solo está allí. Así que eso es algo en lo que trato de evitar […] que estas URL se mezclen aleatoriamente. Pero al mismo tiempo, por lo general no interrumpirá el procesamiento de su archivo de mapa del sitio. Y definitivamente no va a tener un efecto de clasificación en su sitio web. Así que no hay nada en nuestro sistema de mapas del sitio que se asemeje a la calidad de un sitio web ”.

Contenido multirregional

38:13 “Yo trabajo en la vertical de noticias. Mi equipo busca expandir nuestra presencia internacional y ha trabajado para establecer subdirectorios multirregionales. En su mayor parte, las páginas de las diferentes ediciones multirregionales tendrán el mismo aspecto. La página de inicio y las páginas de secciones, como política o estilo de vida, tendrán contenido similar menos algunas piezas exclusivas de la región.

Los artículos son engañosos. No hay mucho que podamos diferenciar entre subdirectorios multirregionales fuera de los módulos con enlaces relacionados, lo que nos deja preocupados por los problemas de contenido duplicado. ¿Cómo maneja Google el contenido duplicado en el espacio de noticias? […] El contenido sigue siendo el mismo, pero los elementos de la plantilla son diferentes. ¿Debería haber solo una canónica en todos los sitios web multirregionales?

La respuesta de John fue: “[…] Parece que estas son diferentes regiones dentro del mismo país, y es el mismo contenido de idioma. […] Si se trata de países diferentes, entonces tienes el aspecto de la orientación geográfica, que juega un papel importante si se trata de idiomas diferentes. Entonces, si está trabajando, digamos, en Europa, y está cubriendo Alemania, Francia e Italia, o algo así, entonces también tiene diferentes idiomas.

[…] Pero si está hablando dentro del mismo país, el mismo contenido de idioma, entonces […] es un poco más fácil porque no tiene que preocuparse por todas estas conexiones técnicas. Pero, por otro lado, los problemas de contenido duplicado son mucho más visibles. Y cuando se trata de contenido duplicado, el aspecto complicado de sitios como estos es que básicamente terminas compitiendo contigo mismo. Y si tiene un artículo de noticias que publica en […] cinco o seis sitios web regionales diferentes, entonces todos estos sitios web regionales diferentes intentan clasificar exactamente para el mismo artículo. Y eso podría resultar en que ese artículo simplemente no se clasifique tan bien como podría.

Entonces, por eso, recomendaría tratar de encontrar URL canónicas para estos artículos individuales para que realmente pueda decir 'bueno, tengo este artículo en mis cinco sitios web regionales, pero esta es mi versión preferida que quiero haber visto en búsqueda'. Y luego podemos concentrar toda nuestra energía, todas nuestras señales, en esa versión preferida, y podemos tratar de clasificarla un poco mejor. No tiene que ser la misma versión todo el tiempo. Entonces, definitivamente puede ser el caso de que tenga un artículo de noticias que esté dentro de una región y que sea canónico, un artículo de noticias diferente es más canónico para otra región. La forma en que elige qué región elige como canónica depende totalmente de usted. […] Por lo general, intentaría averiguar dónde es más relevante y elegiría esa como la versión canónica. Así que eso es para los artículos individuales en sí.

Para las categorías, las secciones y las páginas de inicio, parece que sería algo donde el contenido es más único y más específico para las regiones individuales. Y debido a eso, trataría de mantener separados esos niveles de índice. Entonces, si tiene cinco sitios web regionales diferentes, su página de inicio, sus secciones de categoría, todos estarán indexados individualmente. Y los propios artículos de noticias se asignarían a una de estas diferentes regiones. Así que ese es el tipo de enfoque que recomendamos allí […].

Y este enfoque también […] funciona en diferentes nombres de dominio. Entonces, si tiene diferentes dominios para regiones individuales, pero todo es parte del mismo grupo de noticias, aún puede hacer este cambio canónico entre las diferentes versiones. Si lo estás haciendo dentro del mismo dominio con subdirectorios, también está bien”.

Redirección en un movimiento de sitio

44:34 "¿Cuál es el mejor curso de acción a seguir cuando tienes que redirigir 301 todas las URL a un nuevo conjunto de URL? ¿El número de páginas superará el millón y desea minimizar el efecto de espacio aislado? Si hay un efecto de caja de arena, ¿cuánto tiempo podría ser? ¿Perderíamos un ranking que quizás nunca recuperemos? Planeamos hacer una redirección uno a uno, y habíamos solicitado redirecciones por lotes, pero esa no es una posibilidad, por lo que las páginas, imágenes, URL, etc. tendrían que cambiar al mismo tiempo”.

Como dijo John: “Para mí, esto suena como una situación de movimiento de sitio tradicional. Te mueves de un dominio a otro y redireccionas todas las URL de tu sitio anterior a uno nuevo, y tenemos que lidiar con eso […]. Definitivamente no hay nada definido como un efecto de caja de arena de nuestro lado cuando se trata de mover el sitio . Entonces, si tiene que hacer un cambio de sitio, haga un cambio de sitio y redirija todas sus páginas. A menudo, el enfoque más fácil es redirigir todas las páginas a la vez. Nuestros sistemas también están un poco sintonizados con eso para tratar de reconocerlo. Entonces , cuando vemos que un sitio web comienza a redirigir todas las páginas a un sitio web diferente, intentaremos reprocesarlo un poco más rápido para que podamos procesar el movimiento del sitio lo más rápido posible. Y definitivamente no es el caso que diríamos, oh, están haciendo un cambio de sitio, por lo tanto, reduciremos las cosas […]”.

API y presupuesto de rastreo

46:13 “Tengo un sitio web que se conecta a las API en el lado del cliente para obtener datos. ¿Se incluyen esas URL en el presupuesto de rastreo? Si no permite esas URL, […] ¿eso crearía algún problema?”

“[…] Si estas API se incluyen cuando se procesa una página, entonces sí, se incluirían en el rastreo y contarían para su presupuesto de rastreo esencialmente porque tenemos que rastrear esas URL para procesar la página. Puede bloquearlos mediante robots.txt si prefiere que no se rastreen o no se utilicen durante el renderizado. Depende totalmente de usted si prefiere hacer eso. Especialmente si tiene una API que es un poco costosa de mantener o requiere muchos recursos, entonces, a veces, eso tiene sentido.

La parte complicada, supongo, es que si no permite el rastreo de su punto final de API, no podremos usar ningún dato sobre las devoluciones de API para la indexación. Entonces, si el contenido de su página proviene únicamente de la API y no permite el rastreo de la API, no tendremos ese contacto. […] Si la API solo hace algo complementario a la página, como dibujar un mapa o […] un gráfico de una tabla numérica que tiene en una página, […] entonces tal vez no importe si ese contenido es No incluido en la indexación. La otra cosa es que, a veces, no es trivial cómo funciona una página cuando la API está bloqueada. En particular, si usa JavaScript y las llamadas API están bloqueadas debido a robots.txt, entonces debe manejar esa excepción de alguna manera. Y dependiendo de cómo incruste el JavaScript en la página, lo que haga con la API, debe asegurarse de que aún funcione. Entonces, si esa llamada API no funciona, y luego el resto de la representación de la página se interrumpe por completo, entonces no podemos indexar mucho porque no queda nada para representar.

Sin embargo, si la llamada a la API se interrumpe y aún podemos indexar el resto de su página, entonces podría estar perfectamente bien. […] Creo que es más complicado si ejecuta una API para otras personas, porque si no permite el rastreo entonces, tiene este efecto de segundo orden de que el sitio web de otra persona podría depender de su API. Y dependiendo de lo que haga su API, de repente, su sitio web no tiene contenido indexable. Y es posible que ni siquiera se den cuenta porque no se dieron cuenta de que, de repente, agregó un rechazo allí. Y eso podría causar efectos indirectos similares […]”.

JavaScript y caché de Google

49:36 “Así que hay dos páginas que se originan en el mismo dominio. La URL es un poco diferente, que es parte de la misma estructura de directorios. Y […] son ​​generados por NextJS. Entonces, NextJS es un marco de reacción renderizado del lado del servidor. Y se están indexando, pero veo una página en el caché de Google y la segunda página no está en el caché de Google. Y veo el mismo patrón independientemente de cómo genere la página […]. La mayoría de mis páginas están en el caché de Google, pero ahora estoy preocupado porque actualmente me estoy mudando de mi pila de tecnología basada en Java, que genera todas estas páginas, a Google NextJS. […] Cuando estaba depurando, descubrí que esto también es un problema con la pila de Java más antigua que estábamos usando.

Así que la pregunta tiene dos partes. Básicamente, ¿por qué este comportamiento? Y en segundo lugar, ¿este comportamiento afectará mi clasificación? Veo esas páginas que aparecen en los resultados de búsqueda que no están en el caché de Google”.

John respondió: “[…] Las páginas del caché están completamente separadas de lo que indexamos. Entonces , si hay una página de caché o no, no importa en absoluto para la clasificación, no importa en absoluto para la indexación . A veces, existen razones técnicas por las que no tenemos una página de caché. A veces, simplemente no tenemos una página de caché para URL individuales. La otra cosa es que si la página está utilizando un marco de JavaScript, entonces si ese JavaScript se ejecuta o no en una página de caché a veces es complicado, porque la página de caché está alojada en un dominio de Google. Dependiendo del tipo de JavaScript que tenga, de dónde extrae los archivos JavaScript, a veces, el JavaScript no se puede ejecutar en el dominio de Google.

[…] La página de caché no es la página renderizada. Es esencialmente solo el archivo HTML que solicitamos, y una copia de eso. Y si el archivo HTML muestra algo, está bien. Si usa JavaScript y JavaScript no se ejecuta porque es una página de caché, está igualmente bien. Simplemente no lo ves en la página de caché. Entonces, si la página de caché no se muestra, no me preocuparía por eso. Eso no es un signo de ningún problema. Y a menudo, […] no puedes controlar si hay una página de caché o no. Simplemente ignoraría eso”.

https://www.youtube.com/watch?v=Vd0rEQrwHDc