Horario de oficina de SEO, 1 de julio de 2022

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

PageSpeed ​​Insights o Google Search Console: ¿cuál es más preciso?

0:44 “Cuando reviso mi puntaje de PageSpeed ​​Insights en mi sitio web, veo un número simple. ¿Por qué esto no coincide con lo que veo en Search Console y el informe Core Web Vitals? ¿Cuál de estos números es correcto?”

Según John: “[…] No hay un número correcto cuando se trata de velocidad, cuando se trata de comprender el rendimiento de su sitio web para sus usuarios. En PageSpeed ​​Insights, de manera predeterminada, creo que mostramos un solo número que es una puntuación de 0 a 100, que se basa en una serie de suposiciones en las que asumimos que diferentes cosas son un poco más rápidas o más lentas para los usuarios. Y en base a eso, calculamos una puntuación.

En Search Console, tenemos la información Core Web Vitals , que se basa en tres números de velocidad, capacidad de respuesta e interactividad. Y estos números son ligeramente diferentes, por supuesto, porque son tres números, no solo uno. Pero, también, hay una gran diferencia en la forma en que se determinan estos números. Es decir, hay una diferencia entre los llamados datos de campo y los datos de laboratorio.

Los datos de campo son lo que los usuarios han visto cuando visitan su sitio web. Y esto es lo que usamos en Search Console. Eso es lo que usamos para la búsqueda también. Mientras que los datos de laboratorio son una vista teórica de su sitio web, donde nuestros sistemas tienen ciertas suposiciones en las que piensan, bueno, el usuario promedio probablemente sea así, usando este tipo de dispositivo y quizás con este tipo de conexión. Y en base a esas suposiciones, estimaremos cuáles podrían ser esos números para un usuario promedio. Puede imaginar que esas estimaciones nunca serán 100% correctas.

Del mismo modo, los datos que los usuarios han visto, también cambiarán con el tiempo, donde algunos usuarios pueden tener una conexión realmente rápida o un dispositivo rápido, y todo va rápido en su sitio web o cuando visitan su sitio web, y otros pueden no tengo eso. Y por eso, esta variación siempre puede resultar en números diferentes.

Nuestra recomendación generalmente es usar los datos de campo, los datos que vería en Search Console, como una forma de comprender cuál es la situación actual de nuestro sitio web, y luego usar los datos de laboratorio, es decir, las pruebas individuales que puede ejecutar. directamente usted mismo, para optimizar su sitio web e intentar mejorar las cosas. Y cuando esté bastante satisfecho con los datos de laboratorio que obtiene con su nueva versión de su sitio web, con el tiempo, puede recopilar los datos de campo, lo que sucede automáticamente, y verificar que los usuarios lo vean como más rápido o más receptivo, también.

Entonces, en resumen, nuevamente, no hay un número correcto cuando se trata de ninguna de estas métricas. […] Pero, más bien, hay diferentes suposiciones y diferentes formas de recopilar datos, y cada una de ellas es sutilmente diferente”.

¿Por qué Googlebot tiene problemas para indexar páginas basadas en JavaScript?

4:19 “Tenemos algunas páginas de clientes que usan Next.js sin robots.txt o un archivo de mapa del sitio. Teóricamente, Googlebot puede llegar a todas estas páginas, pero ¿por qué solo se indexa la página de inicio? No hay errores ni advertencias en Search Console. ¿Por qué Googlebot no encuentra las otras páginas?

John dijo: “[…] Next.js es un marco de JavaScript, lo que significa que toda la página se genera con JavaScript. Pero una respuesta general, también, para todas estas preguntas como, ¿por qué Google no indexa todo? Es importante decir primero que Googlebot nunca indexará todo en un sitio web. No creo que le suceda a ningún sitio web de tamaño no trivial que Google salga e indexe completamente todo. Desde un punto de vista práctico, no es posible indexar todo en toda la web. Entonces, esa suposición de que la situación ideal es que todo esté indexado, dejaría eso de lado y diría que desea que Googlebot se concentre en las páginas importantes.

Sin embargo, la otra cosa, que quedó un poco más clara cuando, creo, la persona me contactó en Twitter y me dio un poco más de información sobre su sitio web, fue que la forma en que el sitio web generaba enlaces a las otras páginas era de una manera que Google no fue capaz de recoger. Entonces, en particular, con JavaScript, puede tomar cualquier elemento en una página HTML y decir, si alguien hace clic en esto, ejecute esta pieza de JavaScript. Y esa pieza de JavaScript puede ser para navegar a una página diferente, por ejemplo. Y Googlebot no hace clic en todos los elementos para ver qué sucede, sino que vamos y buscamos enlaces HTML normales, que es la forma tradicional y normal en la que se vincularía a páginas individuales en un sitio web.

Y, con este marco, no generó estos enlaces HTML normales. Entonces no pudimos reconocer que hay más para rastrear, más páginas para mirar. Y esto es algo que puede corregir en la forma en que implementa su sitio de JavaScript. Tenemos un montón de información en el sitio de Documentación para desarrolladores de búsqueda sobre JavaScript y SEO, en particular, sobre el tema de los enlaces porque surge de vez en cuando. Hay muchas formas creativas de crear enlaces, y Googlebot necesita encontrar esos enlaces HTML para que funcione. […]”

Y excepto la documentación oficial de Google, consulte la Guía definitiva para JavaScript SEO en nuestro blog. “

¿La vinculación a páginas HTTP influye en el SEO de su sitio web?

7:35 "¿Afecta negativamente mi puntaje de SEO si mi página está vinculada a un sitio web externo inseguro? Así que en HTTP, no en HTTPS”.

John dijo: “En primer lugar, no tenemos noción de una puntuación de SEO, por lo que no tiene que preocuparse por la puntuación de SEO.

Pero, independientemente, entiendo que la pregunta es: ¿es malo si enlazo a una página HTTP en lugar de una página HTTPS? Y, desde nuestro punto de vista, está perfectamente bien. Si estas páginas están en HTTP, entonces eso es a lo que se vincularía. Eso es lo que los usuarios esperarían encontrar. No hay nada en contra de enlazar a sitios como ese. No hay inconveniente para que su sitio web evite enlazar a páginas HTTP porque son viejas o están mal hechas y no son tan buenas como en HTTPS. Yo no me preocuparía por eso.”

¿Debería eliminar su archivo de desautorización?

10:16 “Durante los últimos 15 años, he desautorizado más de 11 000 enlaces en total. […] Los enlaces que rechacé pueden haber sido de sitios pirateados o de contenido sin sentido generado automáticamente. Dado que Google ahora afirma que tiene mejores herramientas para no tener en cuenta este tipo de enlaces pirateados o spam en sus algoritmos, ¿debería eliminar mi archivo de desautorización? ¿Hay algún riesgo o inconveniente en simplemente eliminarlo?

John respondió: “[…] Desautorizar enlaces siempre es uno de esos temas complicados porque parece que Google probablemente no te está dando la información completa.

Pero, desde nuestro punto de vista, […] sí nos esforzamos por evitar tener en cuenta estos enlaces. Y lo hacemos porque sabemos que la herramienta Disavow links es una herramienta de nicho, y los SEO lo saben, pero la persona promedio que administra un sitio web no tiene idea al respecto. Y todos esos enlaces que mencionaste son el tipo de enlaces que cualquier sitio web obtiene a lo largo de los años. Y nuestros sistemas entienden que estas no son cosas que intentas hacer para jugar con nuestros algoritmos.

Entonces, desde ese punto de vista, si está seguro de que no hay nada en torno a una acción manual que haya tenido que resolver con respecto a estos enlaces, eliminaría el archivo de desautorización y […] dejaría todo eso a un lado. Una cosa que personalmente haría es descargarlo y hacer una copia para que tenga un registro de lo que eliminó. Pero, de lo contrario, si está seguro de que estas son solo las cosas normales y crujientes de Internet, lo eliminaría y seguiría adelante. Hay mucho más en lo que dedicar su tiempo cuando se trata de sitios web que simplemente rechazar estas cosas aleatorias que le suceden a cualquier sitio web en la web”.

¿Es mejor bloquear el rastreo con robots.txt o la metaetiqueta de robots?

14:19 “¿Qué es mejor: bloquear con robots.txt o usar la metaetiqueta de robots en la página? ¿Cuál es la mejor manera de prevenir el gateo?

John: “[…] También hicimos un episodio de podcast recientemente sobre esto . Así que yo comprobaría eso. […]

En la práctica, hay una diferencia sutil aquí donde, si estás en SEO y has trabajado con motores de búsqueda, entonces probablemente ya lo entiendas. Pero para las personas que son nuevas en el área, a veces no está claro exactamente dónde están todas estas líneas.

Con robots.txt, que es el primero que mencionaste en la pregunta, puedes bloquear el rastreo. Por lo tanto, puede evitar que Googlebot incluso mire sus páginas. Y con la metaetiqueta de robots, cuando Googlebot mira sus páginas y ve esa metaetiqueta de robots, puede hacer cosas como bloquear la indexación. En la práctica, ambos dan como resultado que sus páginas no aparezcan en los resultados de búsqueda, pero son sutilmente diferentes.

Entonces, si no podemos gatear, entonces no sabemos lo que nos estamos perdiendo. Y puede ser que digamos, bueno, en realidad, hay muchas referencias a esta página. Tal vez sirva para algo. no lo sabemos Y luego esa URL podría aparecer en los resultados de búsqueda sin nada de su contenido porque no podemos mirarla. Mientras que con la metaetiqueta de robots, si podemos mirar la página, entonces podemos mirar la metaetiqueta y ver si hay un noindex allí, por ejemplo. Luego dejamos de indexar esa página y luego la eliminamos por completo de los resultados de búsqueda.

Entonces, si está tratando de bloquear el rastreo, definitivamente, robots.txt es el camino a seguir. Si no desea que la página aparezca en los resultados de búsqueda, elegiría la que le resulte más fácil de implementar. En algunos sitios, es más fácil configurar una casilla de verificación que diga que no quiero que esta página se encuentre en la Búsqueda y luego agrega una metaetiqueta sin índice. En otros, tal vez editar el archivo robots.txt sea más fácil. [Depende] de lo que tengas allí”.

¿Puedes colocar la misma URL en varios archivos de mapa del sitio?

16:40 “ ¿Hay alguna implicación negativa en tener URL duplicadas con diferentes atributos en tus mapas de sitio XML? Por ejemplo, una URL en un mapa del sitio con una anotación hreflang y la misma URL en otro mapa del sitio sin esa anotación”.

John dijo: “[…] Desde nuestro punto de vista, esto está perfectamente bien. […] Esto sucede de vez en cuando. Algunas personas tienen anotaciones hreflang en los archivos del mapa del sitio separados específicamente, y luego también tienen un archivo del mapa del sitio normal para todo. Y hay cierta superposición allí.

Desde nuestro punto de vista, procesamos estos archivos de mapa del sitio como podemos y tenemos en cuenta toda esa información. No hay inconveniente en tener la misma URL en varios archivos de mapa del sitio.  

Lo único que me gustaría tener en cuenta es que no tenga información contradictoria en estos archivos del mapa del sitio. Entonces, por ejemplo, si con las anotaciones hreflang, está diciendo, esta página es para Alemania, y luego en el otro archivo de mapa del sitio, está diciendo, bueno, en realidad esta página también es para Francia, […] entonces nuestro los sistemas pueden ser como, bueno, ¿qué está pasando aquí? No sabemos qué hacer con esta mezcla de anotaciones. Y luego puede ocurrir que elijamos uno u otro.

De manera similar, si dice que esta página se modificó por última vez hace 20 años […], y en el otro archivo del mapa del sitio, dice, bueno, en realidad, fue hace cinco minutos. Entonces nuestros sistemas podrían ver eso y decir, bueno, uno de ustedes está equivocado. No sabemos cuál. Tal vez sigamos uno u otro. Tal vez ignoremos por completo la última fecha de modificación. Así que eso es lo que hay que tener en cuenta.

Pero de lo contrario, si solo se mencionan varios archivos de mapa del sitio y la información es consistente o funciona en conjunto, en el sentido de que tal vez uno tenga la última fecha de modificación, el otro tiene las anotaciones hreflang, está perfectamente bien".

¿Cómo evitar que las páginas de video incrustadas se indexen?

19:00 “Estoy a cargo de una plataforma de reproducción de video y nuestras incrustaciones a veces se indexan individualmente. ¿Cómo podemos prevenir eso?”

John respondió: “[…] Miré el sitio web y estos son iframes que incluyen una página HTML simplificada con un reproductor de video incrustado.

Desde un punto de vista técnico, si una página tiene contenido iframe, vemos esas dos páginas HTML. Y es posible que nuestros sistemas hayan indexado ambas páginas HTML porque son páginas HTML separadas. Uno está incluido en el otro, por lo general, pero en teoría también podrían valerse por sí mismos.

Y hay una manera de evitar eso, que es una combinación bastante nueva con las metaetiquetas de robots que puede hacer, que es con la metaetiqueta de robots indexifembedded junto con una metaetiqueta de robots noindex .

Y en la versión incrustada, por lo que el archivo HTML con el video directamente en él, agregaría la combinación de etiquetas meta noindex más indexifembedded robots. Y eso significaría que si encontramos esa página individualmente, veríamos que hay una [etiqueta] sin índice. No tenemos que indexar esto.

Pero con indexifembedded, nos dice que […] si encontramos esta página con el video incrustado dentro del sitio web general, podemos indexar ese contenido de video, lo que significa que la página HTML individual no se indexaría. Pero la página HTML con la inserción, con la información del video, se indexaría normalmente. Así que esa es la configuración que yo usaría allí. Y esta es una metaetiqueta de robots bastante nueva, por lo que es algo que no todos necesitan. Porque esta combinación de contenido iframe o contenido incrustado es rara. Pero, para algunos sitios, tiene sentido hacerlo así”.