Boloop-made explanatory illustration: public access, a Google fetch, sitemap processing, and page indexing are separate checkpoints.
Boloop’s sitemap went through a state that made repeated configuration changes tempting: it opened in a browser, HTTP checks retrieved complete XML, yet Search Console still said it could not fetch it. A later Google live test also succeeded, while the submitted sitemap’s record still had no successful download time.
As of the morning of October 22, 2026, we could not call this fully resolved. At the same time, several directory pages that had been waiting were already indexed by Google. Those simultaneous results were a reminder not to summarize the entire search pipeline with one green or red indicator.
One sitemap has at least four separate outcomes
The first outcome is that the public endpoint works: the original URL returns a successful status, an XML MIME type, and a complete body. The second is that a particular Google request can retrieve the file, such as a live test. The third is the processing status of the submitted sitemap in Search Console. The fourth is the index status of each page listed in it.
These outcomes are related, but they cannot substitute for one another. A 200 from your own client does not prove Google received a 200 on its last attempt. A successful live test does not prove the submitted sitemap has been processed. Successful sitemap processing does not guarantee that every listed page is indexed.
Google’s Sitemaps API defines isPending as not yet processed, while lastDownloaded records the most recent download time. Those fields help distinguish states more clearly than an old error message in the interface alone. Google Sitemaps API fields
Rule out faults you can demonstrate on your side
Our early investigation checked GET and HEAD separately, confirmed there was no unexpected redirect and the response type was correct, then used an XML parser to read the complete body. We checked namespaces, escaping, duplicate URLs, and whether the URLs belonged to the same production origin. The robots.txt rules also needed to permit access to the sitemap and the intended public pages.
We also changed the User-Agent to Googlebot. The response was byte-identical to an ordinary request, which helped rule out some forms of application behavior that depend on that header. It was still a request from our own client, not proof of a genuine fetch from Google’s network.
We reviewed the publication conditions in the sitemap generator and its failure responses as well. One successful read does not establish that a database or transient edge failure never occurred. Equally, a failure we have not observed is not grounds for speculative security changes.
A comparison needs stable conditions
During the investigation, we also prepared a static sitemap with the same content to help distinguish the dynamic generation path from the sitemap contents. Such a comparison requires identical files and records of deployment, submission, and retrieval times.
If one file has changed and the other has not, or other production changes occur during the comparison, the difference in their reported states cannot be attributed directly to static versus dynamic generation. Even with matching conditions, an experiment usually narrows the possibilities rather than identifying a unique cause for Google’s processing failure.
After retiring test endpoints, obsolete submission records also need to be distinguished from the real sitemap. Continuing to discuss an old test file’s 404 can mix a now-absent resource into a later investigation.
The directories were indexed while the sitemap remained pending
On the morning of October 22, the English Skills and Articles directories showed as indexed. The index inspections for Projects and About also had explicit passing results. The submitted sitemap’s API record, meanwhile, still showed isPending: true and lastDownloaded: null.
At that point, 0 errors and 0 warnings did not establish successful parsing: evidence of successful processing was still absent. Conversely, the pending sitemap could not invalidate the pages’ observed indexed status.
Index requests also need quota awareness and deduplication. Boloop retains a record when Google accepts a request; later checks track it instead of submitting it again on every inspection. Google explicitly says repeated requests for the same URL do not speed crawling, and a request itself does not guarantee indexing. Google recrawl guidance
When to investigate further and when to observe
If the exact sitemap URL now returns 404, redirects to a sign-in page, serves broken XML, or produces an explicit fetch failure in Google’s live test, follow that demonstrated failure. If the public response is normal, the live test succeeds, and the submitted record remains pending, retain the submission time, last download time, and page index results, then watch for a change on the planned schedule.
For Boloop, the defensible conclusion at this checkpoint was that the checks had not reproduced a site-side obstacle to reading the sitemap, while formal processing remained incomplete and its cause was unknown. The next useful evidence would be a new download or processing result, not another sitemap URL submitted each day.
This account does not offer a button that makes pages indexed immediately after a change. It offers an investigation order: establish what the site returns, check what Google actually retrieved, and then assess the sitemap and page outcomes separately. Even while an issue is waiting, that makes it clear what has been established and what has not.