Submitting a sitemap through the Search Console API is a PUT to the site's sitemaps collection with the sitemap address as the path, and it returns an empty response body. That is the whole result: no fetch status, no parse result, no URL count. Everything you actually want to know — whether Google downloaded the file, whether it had errors, how many URLs it holds — comes back from a separate list call, on Google's schedule rather than on yours.
The Search Console sitemaps surface has four methods — submit, list, get and delete — and the useful split is between the one that writes and the ones that report. Submit is fire-and-forget. List and get return a sitemap resource carrying the path, when it was last submitted, when it was last downloaded, whether it is still pending, whether it is a sitemap index, the error and warning counts, and the contents broken down by type. That resource is where an automation should read its answers from.
| What you want to know | Which call answers it | How soon |
|---|---|---|
| Did the request reach Google? | sitemaps.submit returning success | Immediately |
| Has Google fetched the file? | lastDownloaded on the sitemap resource | Not immediately |
| Is it still waiting to be processed? | isPending on the sitemap resource | Until it is processed |
| Did it parse cleanly? | errors and warnings counts | After the fetch |
| How many URLs does it hold? | contents[].submitted, per content type | After the fetch |
| How many of them are indexed? | Nothing here — contents[].indexed is deprecated | Never, from this API |
The deprecated field in that last row is worth dwelling on. The sitemap resource used to carry an indexed count per content type, and Google's own reference now marks it deprecated and says not to use it. An automation that reports how many of your sitemap URLs are indexed by reading that field is reporting a number that Google stopped standing behind, and the answer has to come from index coverage or from URL inspection instead.
Pinging a URL to tell Google about a sitemap no longer works. The unauthenticated ping endpoint was announced as going away in 2023, which leaves the authenticated Search Console API as the supported way to submit one — and that is a fair trade, because the ping never told you anything either. A submission that returns an empty body but is authenticated and recorded against a property is more useful than one that returned a page and was tied to nothing.
Inspecting a URL costs quota. Explaining what the inspection meant does not. The two are separate calls so that the expensive one happens when somebody asked for it.
Google's five words say the page was fetched and left out of the index. They say nothing about why. Here is what the string reports, how it differs from "discovered", and the evidence that narrows it to a cause.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
A submitted sitemap address is not permanent and a wrong one is not a disaster. Search Console has a delete method that removes a sitemap from the property, so the repair for a typo is to delete the wrong address and submit the right one. What is worth being careful about is anything your own system stores alongside the submission: if the address is saved so that later publishes re-submit it automatically, deleting the sitemap at Google without clearing the saved copy leaves an automation cheerfully re-submitting a sitemap that no longer exists.
In this product the two halves are kept in step deliberately. Submitting saves the address on the app so the publish chain can re-submit it, and deleting a sitemap clears that saved address when it is the one being deleted. The permissions are asymmetric on purpose too: submitting is available to any member, while deleting a sitemap from the property requires an admin, because removing something from a customer's Search Console is the more consequential half.
A product that publishes on a customer's behalf usually ends up with two sitemap addresses rather than one: the sitemap it generates from the posts it holds, and the sitemap the customer told it about, which lists the pages the product does not own. They are different documents at different addresses, so a submission job that treated them as one would silently stop announcing whichever it dropped. Keeping them as separate kinds costs one field and removes a whole class of quiet failure.
Repeated submissions are worth debouncing rather than sending. Importing ten posts in one script produced ten identical submissions of the same URL to an endpoint that gains nothing from the ninth, so the work now goes onto a queue under a deterministic job id with a sixty-second delay: every further publish inside that window is absorbed by the job already waiting. A minute is short against Google's own crawl latency and long enough to swallow a bulk import.
An empty response body. It is a PUT to the site's sitemaps collection with the sitemap URL as the path parameter, authorised with the webmasters scope, and a successful call means the request was accepted — not that the file was fetched, parsed or accepted as valid. To learn any of that, call the list or get method afterwards and read the sitemap resource it returns.
Read the sitemap resource from sitemaps.list or sitemaps.get and look at three fields. lastDownloaded is when Google last fetched the file, which is different from lastSubmitted. isPending tells you it has not been processed yet. The errors and warnings counts tell you what it made of the file once it did process it. A sitemap with a recent lastSubmitted and no lastDownloaded has been announced and not yet read.
No. The sitemap resource carries a contents array with a submitted count per content type, which is how many URLs the sitemap holds, and an indexed count that Google's reference marks as deprecated with an instruction not to use it. Indexation has to be read from the index coverage reporting or from the URL Inspection API, one URL at a time, and that call is rate limited per property.
Call the delete method with the same property and the same sitemap path, then submit the correct address. Nothing about a submission is irreversible. If your own tooling stored the submitted address in order to re-announce it after each publish, clear that stored copy at the same time, or the next publish will re-submit the sitemap you just removed.
Publishing writes to a database and tells search engines about an address. Preflighting is the step that asks the server answering that address whether it serves a page. What to check, which findings block an announcement, and why the check must never fail a publish.
