Sitemap no se ha podido obtener en Search Console: qué lo causaba y cómo lo resolví al restaurar mi web
Estoy reconstruyendo kenrusselclaveria.com después de un hackeo. Parte del proceso es reconectar todo lo que quedó huérfano: Site Kit, Search Console, GA4, Tag Manager. Ayer le tocó al sitemap, y ahí apareció el error que da pie a este post.
Search Console no tenía ningún sitemap registrado: la lista aparecía vacía, sin nada enviado. Normal: el backup restauró el contenido, no la configuración de Search Console. Fui a Indexación → Sitemaps y añadí sitemap_index.xml, que es el que genera Rank Math.
Hasta aquí, todo como se espera. El problema apareció al entrar al detalle del sitemap.
El sitemap índice se procesó bien, pero un sitemap hijo dio error
Rank Math no genera un único sitemap: genera un índice (sitemap_index.xml) que apunta a sitemaps más pequeños por tipo de contenido (page-sitemap.xml, post-sitemap.xml, etc.). Search Console confirmó que el índice se había procesado correctamente, pero uno de esos sitemaps hijos, page-sitemap.xml, aparecía con el estado «No se ha podido obtener»: Google no podía leer ese sitemap en concreto, aunque el índice general estuviera bien.
Es un matiz que se pierde fácil si solo miras el estado general del índice: puede figurar como «Correcto» y aun así tener uno o varios sitemaps hijos inaccesibles por debajo, invisibles hasta que entras al detalle.
Por qué un sitemap sale como "no se ha podido obtener"
Antes de tocar nada, repasé las causas más habituales de que Google no pueda leer un sitemap en Search Console, de más a menos probable en un caso post-restauración como el mío:
| Causa posible | Cómo se comprueba | ¿Aplicaba en mi caso? |
|---|---|---|
| Caché (plugin o servidor) sirviendo una versión antigua o de error en esa URL | Abrir la URL del sitemap directamente en incógnito y mirar la respuesta | Sí — era esta |
robots.txt bloqueando la URL del sitemap o al user-agent de Googlebot | Revisar robots.txt y probar la URL en la herramienta de inspección | No, sin restricciones ahí |
| La URL devuelve un código distinto de 200 (403, 404, 500) de forma intermitente | Comprobar cabeceras de respuesta (curl -I) | No, devolvía 200 una vez purgada la caché |
| Plugin de seguridad/firewall bloqueando las peticiones de Googlebot | Revisar logs del firewall (Wordfence, Kadence Security) por ese user-agent | No detectado, pero es lo primero que miraría tras un endurecimiento de seguridad post-incidente |
| El sitemap referenciado ya no existe o cambió de ruta tras la restauración del backup | Comparar la ruta del índice con la estructura real de archivos/rewrite rules | No, la ruta era correcta |
| Timeout del servidor si el sitemap se genera de forma pesada en cada petición | Medir tiempo de respuesta de la URL | No, la web no tiene volumen para eso |
La caché era la sospechosa número uno por un motivo concreto: LiteSpeed Cache ya me había dado un problema similar en esta misma reconstrucción, sirviendo estilos antiguos de Elementor después de aplicar cambios de diseño. No era la primera vez que este plugin se quedaba sirviendo algo que ya no correspondía al estado real de la web.
Cómo resolví el sitemap inaccesible: purgar LiteSpeed Cache
Purgué la caché completa desde el plugin LiteSpeed Cache (no caché de servidor, ni CDN externo). A los pocos minutos, page-sitemap.xml dejó de estar inaccesible y volvió a servir el XML real generado por Rank Math, en lugar de lo que fuera que LiteSpeed Cache tenía guardado de antes.
No profundicé en si lo que servía antes era una versión previa a la restauración del backup o un error cacheado del propio proceso de restauración. Lo que sí puedo decir con certeza es la secuencia: sitemap hijo inaccesible → purgar LiteSpeed Cache → sitemap hijo accesible, sin tocar nada más.
La lección: revisar la caché antes que nada
Con LiteSpeed Cache van ya dos veces en esta reconstrucción: primero con los estilos de Elementor, ahora con un sitemap. No es casualidad, es un patrón: en este stack (WordPress + LiteSpeed Cache + Rank Math + Elementor sobre Hostinger), cualquier cosa que «no se actualiza» después de un cambio, lo primero que reviso ahora es la caché antes de asumir algo más complejo. Barato de comprobar, y en mi caso ha sido la causa las dos veces.
No profundicé en si lo que servía antes era una versión previa a la restauración del backup o un error cacheado del propio proceso de restauración. Lo que sí puedo decir con certeza es la secuencia: sitemap hijo inaccesible → purgar LiteSpeed Cache → sitemap hijo accesible, sin tocar nada más.
Preguntas frecuentes
¿Qué significa "No se ha podido obtener" en un sitemap de Search Console?
Google intentó descargar esa URL de sitemap y no obtuvo una respuesta válida: puede ser un error de servidor, un bloqueo, o una versión en caché que no corresponde al contenido real.
¿El estado "Correcto" del sitemap índice garantiza que todos los sitemaps hijos estén bien?
No. El índice puede procesarse correctamente aunque uno o varios de los sitemaps que referencia fallen. Hay que revisar el detalle, no solo el estado general.
¿Purgar la caché puede arreglar errores de sitemap en Search Console?
Si la causa es que un plugin de caché está sirviendo una versión antigua o rota de la URL del sitemap, sí. Es la primera comprobación más barata antes de mirar robots.txt, firewall o la generación del sitemap en sí.