Google puede ignorar el sitemap de un sitio que considera de baja calidad, y confirma que llms.txt no lo reemplaza

Google publicó el 1 de octubre de 2026 el episodio 114 de su podcast Search Off the Record, titulado «Do sitemaps still matter?», en el que John Mueller y Martin Splitt del equipo de Search Relations explicaron por qué un sitemap XML perfectamente válido puede aparecer con el error «couldn't fetch» en Search Console. La respuesta no es técnica: en muchos casos es una señal de calidad.

Mueller fue directo sobre las dos causas: «Lo vemos mucho en los foros. Y hay principalmente dos razones para eso». La primera es carga del servidor, cuando Google no alcanza a rastrear el archivo porque está ocupado en otras cosas. La segunda es la que importa a cualquier equipo de marketing: «la demanda de rastreo muy a menudo se basa en la calidad percibida de un sitio web. Y eso puede tener un impacto realmente grande en cuánto rastreamos e indexamos».

¿Por qué Google muestra «couldn't fetch» en un sitemap válido?

Porque enviar el archivo no obliga a Google a leerlo. Si la demanda de rastreo del dominio es baja, el sitemap entra en una fila que puede no procesarse. Dicho de otra forma: el sitemap no es una palanca para forzar indexación, es un insumo que se atiende en proporción al interés que el sitio ya genera. Un sitio con contenido delgado, duplicado o generado en volumen sin revisión no se arregla publicando un sitemap más completo.

Mueller añadió un matiz práctico sobre el tamaño del sitio: «creo que los sitios web más pequeños probablemente no necesitan un sitemap porque podemos simplemente rastrearlos», aunque recomendó dejar activada la generación automática porque «no hay daño» en tenerla.

¿Qué campos del sitemap siguen sirviendo y cuáles no?

• priority: descartado. Mueller explicó que los equipos de SEO marcaban todo con prioridad máxima, lo que lo volvió «no muy útil».
• change frequency: descartado. Splitt observó que por defecto todo queda declarado como siempre fresco, lo que es correcto en teoría e inservible en la práctica.
• lastmod: sigue en juego. Mueller habló de una «relación extraña de amor y odio» con este campo: Google lo usa cuando las fechas son confiables y lo ignora cuando están infladas o manipuladas, sin que eso implique una penalización por spam.
• Límites: 50.000 URL y 50 megabytes sin comprimir, según lo que Mueller recordaba en el episodio. Comprimir el archivo no sube ese techo.
• Índices de sitemap: «solo se pueden anidar una vez, pero puedes enviar tantos archivos de índice de sitemap como quieras».
• Nombre del archivo: flexible. Mueller sugirió que incluso «martinscat.xml serviría» y que la extensión .xml probablemente no es obligatoria.

¿Sirve llms.txt como sitemap para los buscadores y los agentes de IA?

No, y esta es la parte del episodio con más consecuencias para los equipos que están invirtiendo en visibilidad dentro de respuestas de IA. Consultado sobre si llms.txt puede reemplazar al sitemap XML, Mueller respondió «No»: lo describió como un archivo basado en Markdown, funcionalmente más cercano a un sitemap HTML que a uno XML, y aclaró que los sistemas de Google no lo procesan: «actualmente nada de esto ocurre». Su recomendación fue explícita: «yo no me apoyaría en eso».

Sobre los sitemaps HTML dijo algo parecido: son «básicamente casi como un mapa de tu sitio para los usuarios. No es algo que reemplace a un archivo sitemap XML». En cambio, un feed RSS sí funciona: Mueller lo calificó de «muy similar» a un sitemap y confirmó que «un archivo RSS puede usarse como archivo sitemap». Y agregó un dato útil para quien piensa en rastreadores de IA: esos sistemas normalmente no tienen una opción de envío manual, por lo que dependen de «un nombre de archivo genérico o de los feeds», y los registros de servidor muestran que acceden a ambos formatos.

¿Qué significa para las empresas en Chile y Latinoamérica?

Para equipos de marketing B2B en Chile y Latinoamérica, el mensaje operativo es incómodo pero útil: si las páginas nuevas no entran al índice, el problema casi nunca está en el sitemap. Está en la calidad agregada del sitio, que es exactamente lo que se deteriora cuando se publica contenido en volumen con asistencia de IA y sin revisión editorial. El segundo mensaje es financiero: quien estaba a punto de pagar horas de desarrollo para instalar llms.txt como atajo hacia la visibilidad en buscadores con IA acaba de recibir la respuesta del propio Google, y puede redirigir ese presupuesto a contenido y a feeds que sí se leen.

Análisis de Revenue Hub

Este episodio cierra una discusión que vemos seguido en comités de marketing: la idea de que la indexación es un problema técnico que se resuelve con un archivo. No lo es. Google acaba de decir que la cantidad de rastreo que recibe un dominio depende de la calidad percibida, es decir, de una decisión editorial acumulada, no de una configuración. Para una operación comercial eso cambia dónde conviene poner la plata: menos en trucos de descubrimiento y más en menos páginas, mejor hechas, con fechas de actualización que digan la verdad.

La recomendación concreta para esta semana son tres revisiones. Primero, auditar cuántas URL del sitio aportan demanda real y despublicar o consolidar las que no, en vez de seguir sumando. Segundo, confirmar que el campo lastmod refleje cambios reales de contenido y no la fecha del último deploy, porque fechas infladas hacen que Google deje de confiar en todas. Tercero, dejar un feed RSS válido y enlazado en el encabezado de las páginas, que es hoy la vía más directa para que los rastreadores de IA encuentren contenido nuevo sin envío manual.

Hay un cuarto punto que casi nadie conecta con esto y que define si el esfuerzo se puede defender ante la gerencia: la medición. Si el tráfico orgánico y el que llega desde asistentes de IA no quedan correctamente atribuidos en el CRM, cualquier mejora de indexación se vuelve invisible en el reporte y el presupuesto se discute a ciegas. Para ordenar ese punto conviene definir primero cómo se registra el origen de cada contacto, algo que explicamos en la guía sobre cuando usar fuente original o fuente más reciente en HubSpot, y recién después discutir volúmenes de páginas.