Si Google Search Console muestra tu índice de sitemap como Success mientras las páginas descubiertas permanecen en cero, y los sitemaps secundarios siguen en "Couldn't fetch" sin importar cuántas veces los reenvíes, probablemente no estés mirando un problema del servidor. Estás mirando un backoff por URL dentro del planificador de sitemaps de Google. La forma más rápida de probarlo es reenviar el archivo idéntico bajo una URL ligeramente diferente y ver qué sucede.
Ese diagnóstico me tomó seis meses, cinco auditorías separadas y cuatro modelos de IA diferentes. La prueba que finalmente lo aclaró tomó 14 segundos.
Punto clave: un índice de sitemap puede reportar Success mientras cada sitemap secundario en él es invisible para Google. Si tus logs de edge no muestran ninguna solicitud de Googlebot para un hijo en "Couldn't fetch", la falla está del lado de Google, no del tuyo. Reenviar el mismo archivo en una URL versionada como /sitemap/0.xml?v=20260815 evita el backoff y se procesa en segundos.
Lo que "Success" en realidad estaba reportando
El sitio es Deluxe Astrology, la plataforma de astrología védica de mis padres y lo más grande que ejecuto: aproximadamente 240,000 URLs en 30 idiomas, publicadas desde Supabase y servidas como un índice de sitemap con 63 sitemaps secundarios debajo. Escribo sobre la arquitectura detrás de esto en la página del proyecto Deluxe Astrology.
Las páginas indexadas habían estado bajando durante semanas. Las impresiones se desplomaron a fines de junio. Y el único sistema cuyo trabajo es entregar a Google una lista de URLs nuevas estaba mostrando una marca verde.
Abre el índice de sitemap en Search Console y dice "Sitemap index processed successfully". Haz clic en él y la tabla Sitemaps muestra 0-0 de 0. Google había buscado el índice tres veces separadas en tres semanas, lo analizó correctamente como un índice, y no registró ninguno de sus hijos. Ni un solo sitemap secundario fue jamás buscado. Cuando envié tres de ellos directamente, permanecieron en "Couldn't fetch" durante horas.
Esta es la trampa. El estado en un índice de sitemap es una declaración solo sobre el archivo de índice. Te dice que el XML se analizó y las URLs secundarias se veían bien formadas. No te dice nada sobre si Google alguna vez fue y las leyó. Esa distinción está enterrada en una tabla que la mayoría de la gente nunca desplaza, y es todo el juego en cualquier sitio lo suficientemente grande como para necesitar un índice de sitemap en primer lugar.
Todo en el servidor funcionaba correctamente, cinco veces separadas
Si has visto "Couldn't fetch" sabes cómo transcurre la siguiente hora. Haces curl a la URL. Verificas robots.txt. Verificas el firewall. Verificas la caché del CDN. Ejecutas la prueba en vivo en URL Inspection. Todo vuelve limpio. Así que te dices la mentira clásica de Search Console: simplemente necesita tiempo, vuelve a revisar en 24 a 72 horas.
Durante los meses esto se convirtió en una investigación genuinamente exhaustiva, y no solo por mí. Pasé el problema a través de varios modelos de frontera como auditores independientes: Claude, Kimi, GLM y un par de agentes personalizados, cada uno con acceso al codebase, los datos de Search Console y los logs de edge. He escrito antes sobre cuántos modelos de IA en realidad vale la pena ejecutar a la vez, y este fue el caso que lo probó más duramente.
Estuvieron de acuerdo en casi todo, y tenían razón en casi todo:
- El índice de sitemap en vivo sirvió un
<sitemapindex>válido con los 63 secundarios, tipo de contenido correcto, sin marca de orden de bytes, sin URLs entre dominios. - Cada secundario sirvió un
<urlset>válido con los recuentos de URL esperados. - El fetch en vivo de Googlebot del índice y de un hijo, a través de URL Inspection, devolvió el XML real. "URL disponible para Google."
- Los edge logs mostraron solicitudes reales de Googlebot al índice siendo permitidas y servidas con 200 desde caché.
- Nada en robots.txt, middleware, redirects o config de CDN tocó las rutas del sitemap.
Un error anterior fue real y ya había sido corregido. Un límite de tasa por IP en el WAF, agregado meses antes para combatir una granja de bots que estaba quemando mi factura de hosting, había estado desafiando el tráfico de rastreadores durante un tiempo. Esa regla fue corregida. Después de la corrección, cada auditoría llegó a la misma conclusión: el servidor está limpio, Google necesita tiempo, revisa en 24 a 72 horas.
Cinco auditorías. Mismo veredicto. Misma recomendación. Los números nunca cambiaron.
La pista fue una ausencia, no un error
El hecho incómodo estaba escondido en los edge logs, en lo que no estaba ahí. Después de enviar tres sitemaps hijo, no había solicitud de Googlebot para ninguno de ellos. No una permitida, no una desafiada, no una denegada. Google no estaba fallando al obtener los hijos. Google estaba eligiendo no intentarlo.
No puedes diagnosticar eso desde el servidor, por construcción. Nada llega para inspeccionar. Cada herramienta en el kit estándar está construida para explicar una solicitud que salió mal, y no hubo solicitud. Esta es la única clase de problema que el análisis de archivos de log resuelve por omisión en lugar de por evidencia: vas buscando los hits, y la respuesta es el conjunto de resultados vacío.
La prueba en vivo de Search Console lo empeora, porque evita el planificador que está tomando esa decisión. Obtiene bajo demanda, desde una ruta de código diferente, e informa alegremente "disponible" para una URL que el subsistema de sitemap nunca pondrá en cola. Una prueba en vivo verde no es prueba de que el pipeline del sitemap jamás toque el archivo.
La API dijo la verdad que la UI no diría
La Search Console Sitemaps API dio la primera señal honesta. La UI dice "No se pudo obtener", lo que se lee como un error con una causa. La API devuelve isPending: true con errors: 0 y sin timestamp lastDownloaded en absoluto.
Son afirmaciones diferentes. "No se pudo obtener" implica un intento que falló. isPending con cero errores significa que nunca se hizo un intento. Seis meses de debugging habían estado dirigidos a un error que no existía.
Si ejecutas algo a escala, conecta la API antes de necesitarla. Es un alcance OAuth y unas pocas líneas de código, y es la diferencia entre una cadena de estado diseñada para tranquilidad y el estado real del registro. Me apoyo mucho en ella en mi Claude Code SEO audit workflow exactamente por esta razón.
El experimento controlado
En lugar de ejecutar una sexta auditoría, ejecuté un control.
Primero, una línea base. Envié un sitemap que Google nunca había visto antes, uno pequeño para una sección lateral del sitio. Fue descargado y procesado 34 segundos después del envío. Así que el pipeline estaba saludable, el host era alcanzable, y Google estaba dispuesto a obtener sitemaps de este dominio en ese momento.
Luego la prueba real. Reenvié uno de los hijos atrapados, byte por byte idéntico, servido por la misma ruta en el mismo servidor, con exactamente una diferencia: una query string al final. /sitemap/0.xml?v=20260815.
| Envío | Estado de Google | Tiempo de procesamiento |
|---|---|---|
| `/sitemap/0.xml` (original) | Pendiente después de 2h 30m | Nunca |
| Nuevo mapa del sitio, nunca enviado antes | Procesado | 34 segundos |
| `/sitemap/0.xml?v=20260815` (archivo idéntico) | Procesado, 2,187 URLs | 14 segundos |
Mismo archivo. Mismo servidor. Mismos bytes. Cadena diferente. Uno fue invisible durante dos horas y media y contando, el otro se leyó en 14 segundos.
Ese es el diagnóstico completo, y es la razón por la que sigo argumentando que una prueba controlada vence a otra ronda de verificación. Cada auditoría había confirmado hechos sobre el servidor. Ninguna había variado la única entrada que resultó importar.
Qué estaba sucediendo realmente
El sistema de mapas del sitio de Google mantenía esas 63 URLs exactas en un retroceso de falla por URL.
Meses antes, cada lectura del índice había generado una ráfaga de 63 búsquedas secundarias desde una sola IP de Google en cuestión de segundos. Ese es el comportamiento normal de Googlebot para un índice: lee el padre y luego obtiene los hijos más o menos de una vez. El límite de velocidad por IP en el WAF, dimensionado para tráfico humano promedio, vio una ráfaga de 63 solicitudes desde una dirección e hizo lo que estaba configurado para hacer. Las desafió. Cada ciclo. Durante semanas.
La única solicitud del índice en sí siempre pasó, porque una solicitud no es una ráfaga. Por eso el índice siguió leyendo "Éxito" mientras sus hijos nunca llegaban a existir. La regla estaba perfectamente configurada para romper exactamente las URLs que más necesitaba que Google leyera, mientras dejaba intacta la única URL que informa sobre ellas.
Reparar el firewall no eliminó la memoria de Google sobre las URLs que habían fallado. Solo dejó de crear nuevas fallas. El retroceso en esas 63 cadenas específicas sobrevivió a la reparación, y nada sobre esperar iba a expirar en una escala de tiempo que pudiera observar.
La solución: 63 envíos, cero implementaciones
A través de la API de Search Console reenviré los 63 hijos con la cadena de consulta de versión. Dentro de aproximadamente dos minutos cada uno había sido buscado y procesado: 155,545 URLs registradas con Google, cero errores, cero advertencias. Las páginas descubiertas, que habían leído cero durante medio año, se llenaron mientras observaba.
La solución duradera es un cambio de dos líneas en la próxima versión: hacer que el índice del mapa del sitio emita las URLs secundarias versionadas, para que el índice y robots.txt apunten a URLs que Google está dispuesto a leer. Aumenta el token de versión siempre que cambie la lógica de generación y obtienes un mecanismo de invalidación de caché gratuito.
Una salvedad honesta. La indexación no es descubrimiento. Google está rastreando este host lentamente después de meses de desconfianza, y 155,000 URLs no se barren en una semana. Que el descubrimiento funcione de nuevo es la precondición, no el resultado. Si tu presupuesto de rastreo ya es escaso, reparar el mapa del sitio es donde comienza el trabajo.
Por qué cinco auditorías convergieron en la respuesta equivocada
Esta es la parte a la que sigo volviendo.
Los modelos eran excelentes en verificación. Dada una afirmación sobre tipo de contenido, encabezados de caché, directivas de robots o middleware, la verificaban con precisión e informaban honestamente. Lo que ninguno de ellos hizo, por sí solo, fue proponer enviar el mismo archivo con un nombre diferente para ver qué pasaba.
La convergencia en un punto ciego compartido se parece exactamente al consenso. Cinco auditores leyendo la misma evidencia con la misma suposición, que un fallo de búsqueda implica un intento de búsqueda, producirán cinco acuerdos confiados y cero progreso. El acuerdo se siente como confirmación. Es en realidad correlación entre los auditores, no entre los auditores y la realidad.
Lo que rompió el punto muerto no fue otra auditoría. Fue decidir que seis meses de "espera 72 horas" era una hipótesis en lugar de un plan, y diseñar una prueba donde la única variable era la cadena de URL. Ese es un trabajo humano, y no creo que deje de serlo pronto.
Las cinco lecciones que me llevé
- El éxito en un índice de sitemap depende del archivo índice, no de los hijos. Desplázate a "Sitemaps read". Si dice cero, el tick verde es solo decorativo.
- "Couldn't fetch" en la UI significa "aún no procesado" en la API. Lee la API.
isPendingylastDownloadedson lo que realmente necesitas saber, y la UI no te muestra ninguno de los dos. - Google recuerda tus errores de infraestructura más tiempo que tú. Un límite de velocidad que desafió al rastreador durante algunas semanas puede dejar URLs específicas en backoff mucho después de que la regla desaparezca. Esperar no lo limpia de forma confiable. Versionizar la URL sí lo hace.
- Dimensiona los límites de velocidad para ráfagas del rastreador, no para el tráfico promedio. Una lectura de índice desencadena N descargas de hijos desde una IP en segundos. Cualquier límite por IP por debajo de N desafiará exactamente las URLs que más necesitas que Google lea, mientras el índice en sí pasa e informa éxito.
- Cuando varios modelos coinciden en que el servidor está limpio y deberías esperar, probablemente tengan razón sobre el servidor e incorrección sobre la espera. Ejecuta una prueba de control en lugar de una sexta auditoría.
Si crees que tienes el mismo problema
Recorre esto en orden. Toma unos quince minutos y separa limpiamente un problema de servidor de un backoff del lado de Google.
- Abre el índice de sitemap en Search Console y lee el conteo de Sitemaps read, no el estado. Cero hijos leídos en un índice saludable es la firma característica.
- Obtén los mismos sitemaps a través de la API de Search Console. Anota
isPending,errorsylastDownloadedpara cada uno. - Busca en tus logs de edge o CDN solicitudes de Googlebot a las rutas de hijo específicas en los últimos 30 días. Ninguna solicitud en absoluto, de ningún estado, significa que el problema no está en tu servidor.
- Envía una URL de sitemap completamente nueva que Google nunca ha visto. Si se procesa en menos de un minuto, tu host y tu pipeline están bien.
- Reenvía un hijo atascado con una cadena de consulta de versión. Si eso se procesa y la URL simple no, tienes tu respuesta y el remedio en el mismo paso.
- Audita tus límites de velocidad de WAF contra comportamiento de ráfagas, no promedios, para que el backoff no se reconstruya. Luego verifica el resto de tus fundamentos de indexación en sitios grandes.
Para el material de referencia detrás de todo esto, la propia guía de Google para construir y enviar un sitemap y el protocolo sitemaps.org siguen siendo los únicos dos documentos que importan. Ninguno menciona backoff por URL, que es parte de la razón por la que esto tomó tanto tiempo.
Si ejecutas un sitio con más de 100,000 URLs y estás atascado en el mismo síntoma, este es el tipo de trabajo que hago para vivir: SEO técnico en sitios grandes, incluyendo construcciones de SEO programático donde los sitemaps dejan de ser una formalidad y se convierten en todo el canal de distribución. Tengo los scripts de API, la secuencia de diagnóstico y el tejido cicatricial.
FAQ
¿Por qué mi índice de sitemap dice Éxito pero muestra cero páginas descubiertas?
Porque el estado se refiere solo al archivo índice. Google analizó tu <sitemapindex> y encontró URLs de hijo bien formadas, que es todo lo que "Éxito" afirma. Si luego descargó esos hijos se reporta por separado en la tabla Sitemaps read. Cero leídos en un índice válido significa que los hijos nunca fueron procesados, y el tick verde no te está diciendo nada útil.
¿Qué significa realmente "Couldn't fetch" en Search Console?
Menos de lo que suena. En la API de Search Console el mismo sitemap generalmente retorna isPending: true con errors: 0 y sin valor lastDownloaded, lo que significa que Google no ha intentado la descarga aún en lugar de intentar y fallar. Revisa la API antes de pasar tiempo depurando un fallo que quizás nunca ocurrió.
¿Cuánto tiempo debo esperar antes de asumir que un sitemap está genuinamente atascado?
Un sitemap que Google está dispuesto a leer típicamente se procesa en segundos o minutos, no en días. Si un sitemap secundario ha estado pendiente durante más de aproximadamente 24 horas mientras que una URL de sitemap completamente nueva en el mismo host se procesa inmediatamente, esperar más no es una estrategia. En su lugar, ejecuta la prueba de reenvío versionado.
¿Añadir una cadena de consulta a una URL de sitemap causa contenido duplicado u otros problemas de SEO?
No. Un sitemap es un archivo de descubrimiento, no una página indexable, y las URLs dentro de él no cambian. Google trata /sitemap/0.xml y /sitemap/0.xml?v=20260815 como dos recursos de sitemap distintos, que es precisamente la propiedad que estás explotando. Apunta tu índice y robots.txt a las URLs versionadas para que haya un único conjunto canónico en juego.
¿Puede un WAF que limite la velocidad romper el descubrimiento de sitemaps sin romper nada más?
Sí, y eso es lo que lo hace tan difícil de detectar. Leer un índice de sitemap desencadena una ráfaga de descargas secundarias desde una única IP de Google en cuestión de segundos, por lo que un límite por IP diseñado para tráfico humano desafiará a los secundarios mientras que la solicitud de índice individual pasa. Todo lo demás en el sitio, incluyendo pruebas de Inspección de URL en vivo, sigue funcionando perfectamente.
¿Arreglar el sitemap restaurará inmediatamente las impresiones perdidas?
No. El descubrimiento e indexación son etapas separadas. Conseguir que 155,000 URLs se registren restaura la entrada al pipeline, pero la velocidad de rastreo en un host que ha estado fallando durante meses se recupera gradualmente, y las decisiones de indexación siguen al rastreo. Espera semanas, y usa ese tiempo para asegurarte de que las páginas siendo descubiertas merecen ser indexadas.