Por qué Google sigue fallando al rastrear tu sitemap detrás de Cloudflare (y cómo lo solucionamos)

Google Search Console se quedó ahí, semana tras semana, negándose a leer nuestro sitemap. El estado decía “No se pudo obtener” — o a veces “No se pudo leer el sitemap”. Bing no tenía ningún problema para procesar exactamente los mismos archivos. Volvimos a enviarlo. Actualizamos las fechas lastmod. Incluso consideramos cambiarle el nombre al archivo. Nada cambió.

Si llegaste hasta este artículo, probablemente estés atrapado en el mismo bucle. Y esta es la verdad incómoda que tuvimos que aprender por las malas: el archivo casi con certeza estaba bien — el problema era el CDN que estaba delante de él.

El primer diagnóstico apuntó al archivo equivocado

Nuestra primera pista real llegó de una auditoría de segunda opinión. Reportó algo que sonaba completamente plausible:

Tu sitemap-index.xml es válido, pero uno de los sitemaps hijos que referencia — sitemap-1.xml — no es XML en absoluto. Es texto plano. Google es estricto con esto y falla todo el sitemap en el momento en que cualquier archivo hijo está mal formado.

Esa explicación parecía correcta y nos mandó a revisar el generador, la lógica de división y el formato de salida. Solo había un problema: cuando nosotros mismos descargamos sitemap-1.xml, era XML perfectamente válido.

Esa contradicción era todo el rompecabezas, escondido a plena vista.

La misma URL, dos respuestas distintas — esa es la pista real

Esto fue lo que vimos al mirar las cabeceras crudas de la respuesta con curl:

curl -s -o NUL -D - "https://www.gotokit.cc/sitemap-1.xml"

HTTP/1.1 200 OK
Content-Type: text/xml
Server: cloudflare
last-modified: Mon, 17 Aug 2026 13:59:36 GMT
cf-cache-status: HIT
Age: 334

Cuatro líneas cuentan toda la historia:

• Server: cloudflare — cada petición se sirve a través del edge de Cloudflare, no directamente desde nuestro origen.
• cf-cache-status: HIT — la respuesta vino de la caché local del edge de Cloudflare.
• Age: 334 — esa copia en caché llevaba allí minutos; con el Cache-Control adecuado puede quedarse días.
• last-modified — la marca de tiempo del contenido en el origen, que era más antigua que la versión que acabábamos de desplegar.

Cloudflare — y cualquier CDN similar — guarda copias de tus archivos en cientos de nodos edge por todo el mundo. Un visitante en Nueva York, un rastreador en Frankfurt y tu portátil en Shanghái pueden acabar en nodos distintos. Si un nodo todavía guarda una copia obsoleta de un despliegue antiguo, servirá felizmente esa copia vieja a quien la pida — incluido Googlebot.

Eso es exactamente lo que pasó. La versión en “texto plano” era una salida vieja y defectuosa de una versión anterior de nuestro script de sitemap. La versión “plana y mínima” era el sitemap por defecto del framework que precedió al nuestro. Ninguna existía ya en el origen — eran fantasmas viviendo solo en cachés edge obsoletas.

Los dos errores reales (solo uno estaba en nuestro código)

Una vez que dejamos de confiar en un único punto de descarga, el panorama se aclaró. Había dos problemas distintos:

1. Caché edge obsoleta de Cloudflare — el culpable principal. Nuestro origen llevaba días sirviendo XML correcto, pero algunos nodos edge seguían entregando archivos anteriores a la corrección. El rastreador de Google, repartido en muchas regiones, seguía muestreando esos nodos malos, y por eso reportaba “No se pudo obtener” aunque el archivo se viera bien desde nuestro lado.

2. URLs duplicadas en sitemap-0.xml — nuestro propio código. Al revisar el generador hallamos un error de copiar y pegar: el bucle que emite las páginas de tema (como /ai-tools/ y /pdf-tools/) estaba escrito dos veces. Es un defecto real — infla el sitemap y ralentiza el procesamiento — pero no era lo que rompía a Google. Era ruido encima del problema de caché.

Ese segundo error es también un buen recordatorio de por qué conviene que tu sitemap esté demostrablemente limpio antes de publicarlo. Si lo armas a mano, pásalo por un validador; si necesitas crear o reparar uno rápido, el Generador de Sitemap XML gratuito de Gotokit analiza tus URLs, marca las entradas inválidas y genera un sitemap-index.xml conforme al estándar con archivos hijos divididos — todo localmente en tu navegador.

La solución, en orden

No hay un único paso mágico; el orden importa.

1. Corrige el error de origen. Eliminamos el bucle duplicado para que sitemap-0.xml dejara de emitir cada página de tema dos veces.
2. Regenera los archivos. Fechas lastmod nuevas, XML correcto, sin duplicados.
3. Purga toda la caché de Cloudflare. Este es el paso que la mayoría omite. Purgar solo la URL del sitemap no basta cuando hay copias obsoletas en nodos que no conoces. Usamos purge_everything.
4. Vuelve a desplegar. Reemplaza los archivos en producción.
5. Verifica desde el edge, no solo desde el origen. Tras purgar, el mismo curl -D - mostró un last-modified nuevo y un cf-cache-status: HIT que ahora contenía el contenido correcto.

Si tu sitio corre en Cloudflare, puedes lanzar una purga completa desde el panel (Caché → Configuración → Purgar todo) o mediante la API:

curl -X POST "https://api.cloudflare.com/client/v4/zones/{ZONE_ID}/purge_cache" \
  -H "Authorization: Bearer {API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything":true}'

Solo después de que la caché esté limpia tiene sentido pedirle a Google que mire de nuevo.

Cómo saber si TU problema es en realidad la caché del CDN

Ejecuta este mismo diagnóstico antes de seguir editando archivos de sitemap:

Verificación	Qué buscar
curl -s -o NUL -D - https://tudominio.com/sitemap.xml	¿Es Content-Type application/xml o text/xml? ¿Es Server un CDN?
Cabecera cf-cache-status / x-cache	HIT significa que se sirvió una copia en caché
Cabecera Age	Cuánto tiempo lleva cacheada esa copia
last-modified	¿Es la marca de tiempo que de verdad desplegaste?

Si la respuesta cambia según desde dónde hagas la prueba, ya lo detectaste: tu origen está bien, tu caché edge está obsoleta.

Por qué Google sigue mostrando el error después de que lo arreglas

Esta es la parte que lleva a la gente a reenviar tres veces seguidas. Entiéndelo hoy: incluso con el CDN arreglado, Google tiene sus propias dos capas de retraso.

1. La propia caché de Googlebot. No vuelve a buscar tu sitemap al instante en que purgas el CDN. Vuelve según su propio calendario.
2. El panel de estado de Search Console. El aviso “No se pudo obtener” refleja una búsqueda pasada y no se actualiza en tiempo real.

Así que después de purgar y redesplegar:

• En Google Search Console, elimina el envío antiguo del sitemap y vuelve a enviar https://tudominio.com/sitemap-index.xml.
• Usa Inspección de URL → Solicitar indexación / Prueba en vivo sobre el índice y cada sitemap hijo para forzar una descarga nueva y confirmar que “La página se obtuvo correctamente”.

Luego espera. Google trata un sitemap como una sugerencia, no como una orden — pero una vez que el formato está limpio y la caché despejada, normalmente cambia a “Correcto” en cuestión de días.

La versión corta para recordar

• Si Bing lee tu sitemap pero Google no puede, no culpes solo a los archivos.
• Un CDN puede servir contenido distinto a visitantes distintos — incluidos motores de búsqueda distintos.
• El síntoma clásico es el que tuvimos nosotros: XML válido desde tu máquina, “no es XML” desde la comprobación de otro.
• Corrige el archivo, luego purga todo, luego vuelve a verificar desde el edge, luego reenvía.
• Un sitemap es una ayuda de descubrimiento, no un factor de ranking — pero uno roto esconde páginas de Google en silencio.

Nada de esto requirió reescribir nuestro enrutamiento, nuestro robots.txt ni nuestro archivo índice. Requirió mirar más allá del archivo y observar la red que tiene delante.