Gary Illyes y Martin Splitt de Google utilizaron un episodio del podcast Search Off the Record para explicar cómo el rastreador de Google maneja HTML. La conversación reveló diferencias entre cómo los navegadores y el robot de Google procesan la misma página.
La discusión cubrió sugerencias de recursos, ubicación de metadatos y validación de HTML. Varias de las explicaciones de Illyes desafían las suposiciones sobre qué cambios técnicos ayudan con la búsqueda.
Por qué las sugerencias de recursos no ayudan al robot de Google
Funciones de rendimiento del navegador como dns-prefetch, preload, prefetchy preconnect solucionar problemas de latencia que la infraestructura de Google no tiene.
Illyes dijo que la resolución DNS de Google no necesita la ayuda que la mayoría de los sitios intentan brindar.
Él afirmó:
«Es muy útil si tienes una mala conexión a Internet para realizar la captación previa de DNS, por ejemplo. En nuestro caso, no lo necesitamos porque podemos hablar muy rápido con todos los servidores DNS en cascada».
Añadió que Google almacena en caché los recursos de la página por separado y no los recupera en tiempo real como lo hace un navegador. Illyes dijo que Google hace esto para reducir el ancho de banda y la carga del servidor en los sitios que rastrea.
Illyes dijo:
«Lo mismo ocurre con la precarga. Si no somos sincrónicos, entonces no necesitamos escuchar ni mirar la precarga».
Google utiliza la API de reglas de especulación para acelerar los clics en los resultados de búsqueda para los usuarios de Chrome. Ese sistema funciona porque opera a nivel del navegador, donde la latencia entre un usuario y un servidor es importante. El robot de Google opera desde dentro de la propia infraestructura de Google, donde esos cuellos de botella no existen.
Tanto Illyes como Splitt dejaron claro que estos consejos siguen ayudando a los usuarios. Las cargas de páginas más rápidas mejoran la retención y la conversión. La diferencia es que estos cambios afectan la experiencia del navegador, no el rastreo ni la indexación.
Los metadatos pertenecen a la cabeza
Splitt compartió un caso en el que una etiqueta de script compatible con las especificaciones en el encabezado inyectó un iframe, lo que desencadenó el comportamiento de cierre del encabezado del navegador. Eso empujó las etiquetas de enlace hreflang al cuerpo, donde Splitt dijo que los sistemas de Google las ignoraron correctamente.
Illyes explicó por qué Google es estricto al respecto. A meta name="robots" La etiqueta, según el estándar de vida HTML, solo puede aparecer en el encabezado. Lo mismo se aplica a rel=canonical elementos de enlace.
Él dijo:
«Yo diría que es realmente bastante peligroso tener elementos de enlace que contengan metadatos en el cuerpo».
Su razonamiento es que si Google aceptara etiquetas canónicas en el cuerpo, sería posible secuestrar las etiquetas canónicas de esa página y eliminarlas de los resultados de búsqueda mediante la inyección de marcado.
Illyes anteriormente ofreció orientación sobre el análisis de HTML y la implementación rel-canonical, aconsejando deletrear la ruta URL completa en las etiquetas canónicas para evitar la ambigüedad del analizador. Es la misma idea que escuchas, una ubicación clara en la cabeza elimina las conjeturas.
La validez de HTML no equivale a una ventaja de clasificación
Illyes fue directo sobre por qué el HTML válido no puede ser una señal de clasificación. La validez es binaria, lo que significa que es válida o no, sin espacio intermedio. Illyes dijo que es difícil hacer algo significativo con una métrica de aprobado/reprobado.
«Es muy difícil decir que algo está cerca de ser válido. Y luego, ¿qué se hace cuando algo está cerca de ser válido?».
Dio un ejemplo de que la falta de una etiqueta de intervalo de cierre hace que el HTML de una página sea técnicamente inválido, pero como dijo Illyes, «no cambiará nada para el usuario».
Splitt estuvo de acuerdo y señaló que el marcado semántico, como la jerarquía de encabezados adecuada y los elementos estructurales HTML5, tampoco tiene un peso significativo para los motores de búsqueda, aunque es útil para la accesibilidad y la experiencia del usuario.
Por qué esto importa
Las auditorías técnicas pueden señalar oportunidades de sugerencias de recursos y errores de validación de HTML. Saber cuáles afectan al rastreador de Google y cuáles a los navegadores puede ayudarle a priorizar qué corregir.
Cuando las etiquetas hreflang, los enlaces canónicos o las directivas de meta robots no funcionan como se esperaba, el primer lugar para verificar es si terminan en el cuerpo después de que el navegador analiza la página. Una etiqueta que parece correcta en su código HTML de origen puede terminar en la ubicación incorrecta si un script o iframe activa el cierre anticipado del encabezado.
Roger Montti cubrió la guía actualizada de almacenamiento en caché del rastreador de Google, que recomienda encabezados ETag para reducir el rastreo innecesario. Esa guía es consistente con lo que Illyes describió en este episodio.
Mirando hacia el futuro
Splitt mencionó que las sugerencias de los clientes eran el tema original que quería cubrir y que la discusión sobre el análisis de HTML era la base para un episodio futuro. Si ese episodio sucede, podría cubrir cómo el robot de Google maneja la versión más nueva. Accept-CH y Sec-CH-UA encabezados que reemplazan las cadenas de agentes de usuario tradicionales.
La conversación completa está disponible en YouTube y Apple Podcasts.
