What sticks when you submit a sitemap URL to Search Console
The submission itself can be undone. The saved address is the part that keeps acting on its own, because it is re-submitted every time you publish.
Submitting a sitemap URL to Search Console is reversible. The Search Console API has a delete for sitemaps, and Market4 exposes it, so an address submitted by mistake can be removed. What does not undo itself is the saved address: once a sitemap URL is stored against an app, it is re-submitted automatically every time content is published. A wrong address is therefore not one bad request; it is a bad request repeated on a schedule until somebody changes it.
Yes. Deleting a sitemap is a supported operation, and Market4 treats it as the reason submitting one does not need an approval gate: the action spends no money, sends nothing on anyone's behalf, and can be taken back. The two sides are guarded differently on purpose. Submitting requires the MEMBER role, because it only tells Google where a file lives. Deleting requires ADMIN, because removing a sitemap changes what Google is being told about a site that other people also work on.
Deleting also cleans up after itself in one specific way. If the sitemap being deleted is the one saved for automatic re-submission, the saved address is cleared at the same time, so the publish chain stops re-submitting a file that no longer exists in Search Console. Removing the whole property clears both the property and the saved sitemap, for the same reason: a saved sitemap address means nothing without a property to submit it to.
The saved sitemap address turns one manual submission into a standing instruction. In Market4 it is stored on the app's analytics configuration, and the publish chain re-submits it after content is published or archived, so the file Google fetches reflects the state of the site rather than the state it was in on the day somebody first pasted the URL. Every submission and every deletion is written to the audit trail as sc.sitemap_submit and sc.sitemap_delete, which is what makes an unexpected sitemap in Search Console traceable to a person and a moment.
| State | On submit | On delete | On removing the property |
|---|---|---|---|
| The sitemap in Search Console | Added to the property's list | Removed from the list | Goes with the property |
| The saved address on the app | Set to the submitted URL | Cleared when it matches the deleted URL | Cleared |
| Automatic re-submission after publish | Starts | Stops for that address | Stops |
| Audit trail | sc.sitemap_submit recorded | sc.sitemap_delete recorded | sc.remove_property recorded |
Fetch it first and read the file the way a crawler receives it. Market4's sitemap audit takes an optional sitemap_url and checks that address instead of the app's own, saving nothing, which is the one moment a wrong address is cheap to fix. It spends no Google quota because every fact comes from a single HTTP request to the site itself. A 404, a redirect loop,
Publishing a post sends two independent announcements. One IndexNow request reaches Bing, Yandex, Seznam, Naver and Yep. Google takes no part in IndexNow, so it is told by re-submitting the sitemap.
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.
Two fields in that report are worth reading before saving anything. The healthy flag is true only when nothing of severity ERROR was found anywhere, including inside the children of a sitemap index, so an index that parses cleanly can still be unhealthy because of a child file. The coverage section compares the URLs in the file against the posts actually published, which is what turns "the file parses" into "the file lists the pages you wrote".
An absolute http or https URL, and nothing else: a relative path is refused before the request reaches Google with the message "sitemapUrl must be an absolute http(s) URL". Sitemaps are submitted by absolute URL and the property only has to contain that URL, which has a consequence people get wrong about domain properties. A domain property in Search Console can hold sitemaps, including sitemaps on different subdomains, because the domain property covers exactly that span.
Removing a sitemap from Search Console removes a report and a discovery route. It is not a request to forget the URLs the file listed, and pages already in the index stay in the index. Removal of a specific page is a separate action with its own tool and its own timing, and treating a sitemap deletion as a takedown is how a page nobody wants to see stays visible for weeks.
It removes a discovery route and a report, not the pages. URLs Google has already crawled stay in the index, and Google can still find pages through links. What you lose is the per-sitemap coverage reporting and the explicit hint about which URLs matter, which is worth keeping unless the file is wrong. Delete a sitemap when the address is wrong or the file is gone, and submit the correct address in its place.
Yes. A Search Console property can list several sitemaps, and a domain property can list sitemaps that sit on different subdomains, since submission is by absolute URL and the property only has to contain that URL. What a single Market4 app stores is one saved address for automatic re-submission after publishing; submitting other sitemaps by hand does not disturb it.
Because submitting an address and Google fetching the file are two separate events. The API call registers the address; the fetch, the parse and the reporting happen on Google's schedule afterwards. That is why checking the file with your own HTTP request before saving the address is worth doing: it tells you now what Search Console will tell you later, and it costs no quota.
The audit reports it as a finding rather than following it silently, which is the behaviour you want, because a redirect at the sitemap address usually means the address you saved is not the address serving the file. Fix the saved address to the location that answers with the XML directly. A redirect chain at a sitemap URL is one of the states that looks fine in a browser and reads as an error to a crawler.
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.
A sitemap and an IndexNow submission answer the same question about a site. Building them from two pieces of code guarantees they will disagree. Here are the three rules both have to share, and the four places that read the shared list.