Hace unos meses revisaba la web de un cliente que llevaba semanas optimizando resource hints: dns-prefetch para cada dominio externo, preconnect para Google Fonts, preload para los assets críticos del above the fold. Todo según el manual, con Lighthouse dándole puntuación verde en cada auditoría. El problema es que sus páginas clave seguían sin indexarse, y cuando inspeccioné el HTML crudo encontré el verdadero fallo: un plugin de consentimiento de cookies inyectaba el canonical 300 milisegundos después de la carga inicial, vía JavaScript, de modo que Googlebot procesaba el HTML y seguía adelante sin verlo nunca. Todo el trabajo en resource hints era invisible para el rastreador; el canónico también.
Esa confusión entre lo que mejora la experiencia de usuario y lo que realmente importa para el rastreo es el origen del 80 % de los problemas de indexación que encuentro en auditorías. Por eso merece la pena separar estas dos categorías con claridad antes de poner a alguien a optimizar.
Por qué los resource hints no ayudan al rastreo
Los resource hints (preload, prefetch, dns-prefetch, preconnect) son directivas para el navegador, no para el rastreador. Le dicen al browser que prepare recursos antes de necesitarlos para acelerar la percepción de carga. Googlebot no ejecuta esas optimizaciones porque descarga el contenido de golpe sin necesitar precargar nada; el concepto de «percepción de velocidad» no aplica a un programa que no tiene pantalla.
Eso no significa que los resource hints sean inútiles. Impactan en Core Web Vitals, concretamente en LCP (Largest Contentful Paint) y en INP (Interaction to Next Paint), que reemplazó a FID como métrica de interactividad en marzo de 2024. Y esas métricas sí influyen en el ranking desde la actualización Page Experience. Pero su papel es mejorar la experiencia del usuario real, no facilitar el rastreo; si tu problema es de indexación, buscar la solución en los resource hints es perder el tiempo.
He visto equipos dedicar semanas a perfeccionar estas directivas convencidos de que estaban ayudando al SEO técnico, cuando el verdadero problema era una directiva crítica mal ubicada en el HTML.
Dónde deben estar las directivas críticas y dónde las encuentro mal
Google es estricto con la ubicación de canonical, hreflang, robots y alternate: todas deben estar en el <head> del HTML inicial, antes de que se cierre la etiqueta, y deben estar ahí en el HTML crudo, sin depender de JavaScript para aparecer. Parece básico, pero es el error que más veo.
El caso del e-commerce con 12.000 productos es el más extremo que recuerdo: el HTML renderizado en el navegador mostraba el canonical correcto, apuntando a la URL limpia. Pero cuando inspeccioné el código fuente directamente (lo que ve Googlebot), el canonical no estaba. Un script de terceros lo inyectaba de forma dinámica, después de que el rastreador ya había procesado el head y seguido adelante. Resultado: Google trataba cada variante de filtro como una página única e independiente, y el catálogo de 12.000 productos se convirtió en 50.000 URLs indexadas. Mover el canonical al servidor resolvió el problema en dos semanas.
Un patrón parecido lo veo con plugins de WordPress o Shopify mal configurados. En un caso concreto, Yoast estaba bien configurado, pero un tema custom ejecutaba un script que cerraba el </head> de forma prematura; las meta descriptions de Yoast quedaban técnicamente en el body y Google las ignoraba. Para detectar esto, el truco más rápido es inspeccionar el HTML crudo con curl -s https://tuweb.com | grep -A 50 "<head>", que muestra exactamente lo que ve el rastreador, sin el procesamiento del navegador.
Si quieres entender mejor cómo funciona la diferencia entre HTML inicial y HTML renderizado en el contexto del SEO, hay un artículo específico donde desarrollo ese diagnóstico paso a paso.
Lo que sí marca diferencia para Googlebot
Después de años auditando webs con problemas de rastreo, hay cuatro elementos técnicos que aparecen sistemáticamente en los casos resueltos.
El primero es el head procesable de forma lineal: Google lo lee de arriba a abajo y se detiene en el primer </head> que encuentra; todo lo que esté después de ese cierre, por correcto que sea semánticamente, se ignora. He visto casos donde un script de analytics mal ubicado cerraba implícitamente el head porque el navegador intentaba autocorregir el markup, empujando el canonical al body sin que nadie se diera cuenta.
El segundo es la consistencia de canonicals. Si tienes un canonical en el HTML y otro diferente en el HTTP header, Google elige uno de forma arbitraria (generalmente el del HTML, pero no siempre). Si además ese canonical apunta a una URL que devuelve un 301 hacia otra, añades otra capa de ambigüedad. Un canonical ligeramente subóptimo pero consistente en todas las capas funciona mejor que canonicals "perfectos" que se contradicen entre sí. Sobre cómo establecer URLs canónicas de forma correcta hay más detalle en otro artículo, pero la regla general es una sola fuente de verdad, sin discrepancias entre HTML, headers y sitemaps.
 (1).jpg)
El tercero es el hreflang sin roturas. Tiene que ser bidireccional: si la versión ES apunta a EN, la versión EN tiene que apuntar de vuelta a ES; cada URL incluye la referencia a sí misma dentro del cluster; y todas las URLs referenciadas deben ser las canónicas. He visto implementaciones donde hreflang apuntaba a URLs con parámetros que a su vez canonicalizaban a otra versión, y Google simplemente ignoraba el cluster entero. Search Console reporta esos errores directamente en el informe de hreflang, así que si tienes sitio multiidioma, ese es el primer lugar donde mirar.
El cuarto son los scripts que modifican el head. Tag managers, consent banners y scripts de terceros en el head pueden desplazar metas críticas si inyectan contenido antes del cierre. La regla que aplico: scripts de terceros siempre al final del body, o con defer/async si necesitan estar en head. La única excepción son scripts que el rendering inicial requiere de verdad y que no pueden cargarse más tarde.
Checklist para auditar lo que Googlebot realmente ve
Cuando llego a una web con problemas de indexación, esta es la secuencia que sigo antes de mirar cualquier otra cosa:
HTML crudo vs renderizado. Compara el HTML inicial (via curl) con el renderizado (inspector del navegador). Cualquier directiva crítica que solo aparezca en el renderizado es un problema activo.
Posición de metas en el crudo. Busca canonical, robots y hreflang directamente en el HTML sin procesar. Si alguno aparece después de </head>, Googlebot no lo está viendo.
Consistencia del canonical en todas las capas. HTML, HTTP headers y sitemaps deben apuntar a la misma URL. Si hay discrepancias, consolida antes de hacer cualquier otra optimización.
Cadenas de redirección en canonicals. Un canonical que apunta a una URL que devuelve 301 hacia otra obliga a Googlebot a seguir varios saltos; en la práctica he visto que termina eligiendo su propia versión preferida, que no siempre es la que quieres. Revisa que el canonical apunte directamente a la URL final.
Canonical apuntando a 404. Ocurre más de lo que parece, sobre todo después de migraciones donde se actualizan las páginas pero no los canonicals. Google ignora esos canonicals eventualmente, pero se pierden semanas o meses de consolidación de señales mientras tanto.
Noindex con canonical. Si una página tiene noindex y canonical apuntando a otra URL, Google desindexiza directamente e ignora el canonical; eso rompe cualquier estrategia de consolidación donde quieras que páginas con parámetros pasen autoridad a la versión limpia.
JSON-LD bien formado. Los errores de sintaxis en datos estructurados sí pueden hacer que Google ignore completamente el marcado; un <p> sin cerrar en el footer no va a hacer daño, pero un JSON-LD roto sí. Valídalo con el Rich Results Test o con Schema.org validator.
Versión mobile con las mismas directivas. Googlebot usa el agente mobile por defecto. Si sirves HTML diferente a mobile y desktop, asegúrate de que canonical, hreflang y robots estén en ambas versiones.
Cómo priorizar si tienes recursos limitados
Algunas optimizaciones mejoran la experiencia del usuario (resource hints, lazy loading, code splitting); otras facilitan el trabajo de Googlebot (directivas correctas en el head, HTML sin ambigüedades, crawl budget limpio). Lo ideal es cubrir las dos a la vez, pero cuando hay conflicto de prioridades el orden importa.
Si tu problema es de indexación, el SEO técnico orientado al rastreador va primero. He visto e-commerces con Core Web Vitals impecables que no indexaban páginas de producto porque el canonical lo inyectaba un script que cargaba después del HTML inicial; arreglar eso tuvo más impacto en visibilidad que cualquier trabajo de velocidad. Y también he visto lo contrario: webs con markup perfecto y tiempos de carga de ocho segundos que perdían usuarios antes de que vieran el contenido; ahí la prioridad era distinta, pero el problema de partida también lo era.
Mi enfoque en auditorías técnicas siempre empieza por lo mismo: ¿qué ve Googlebot en el HTML inicial que envías? No el renderizado, no el inspector del navegador, sino el HTML crudo. Ahí es donde aparece el 80 % de los problemas que afectan a la indexación, y suelen ser más fáciles de corregir de lo que parece una vez que sabes dónde mirar. Si quieres que revise lo que ocurre en tu caso concreto, puedo hacer una auditoría técnica enfocada en exactamente estos puntos.
Preguntas frecuentes
¿Googlebot procesa los resource hints como preload y dns-prefetch?
No, Googlebot ignora completamente los resource hints. Estas directivas solo ayudan a navegadores de usuarios reales a acelerar la carga percibida. No afectan cómo Google rastrea o indexa tu contenido.
¿Dónde deben estar ubicadas las meta tags críticas para SEO?
Las meta tags críticas (canonical, hreflang, robots) deben estar dentro del <head> en el HTML inicial, antes del cierre de la etiqueta. Si se inyectan vía JavaScript después, Googlebot puede no procesarlas correctamente.
¿Afecta al SEO tener errores de validación HTML del W3C?
No, Google no penaliza por HTML inválido siempre que sea parseable. Etiquetas sin cerrar o atributos duplicados generalmente no afectan el ranking. Lo importante es que las directivas SEO críticas y el structured data estén bien formados.