The old ping endpoints are gone, and that is the whole story
For years the ritual was the same: publish, then hit the ping URL and watch for a 200. Google deprecated it because it had stopped being a useful signal. Sitemaps get discovered through robots.txt and Search Console, and the ping endpoint was mostly receiving automated traffic from tools rather than meaningful notifications from site owners. Bing had already moved on, pushing publishers toward Bing Webmaster Tools and IndexNow.
So the honest version of a sitemap ping tool is a checker plus 2 links. There is no third route hiding somewhere. If a product is charging you for sitemap pinging in 2026, it is charging you to call a URL that returns a deprecation notice.
What the sitemap checker actually runs
You paste one URL into the single field, and the tool fetches it server-side, the way a crawler would rather than the way your logged-in browser would. Then it runs a short list of checks and shows you which passed:
- Reachable - did the fetch return anything, and how many bytes.
- HTTPS - served over HTTPS, or flagged if it is still on HTTP.
- Valid XML - does it parse cleanly, or did something else come back.
- URL set or sitemap index - whether the file is a
<urlset>of pages or a<sitemapindex>of child sitemaps, and how many entries are in it. - Within the 50,000 limit - the per-file URL cap.
- Within the 50 MB limit - the uncompressed size cap.
The header shows a passed-checks count, the entry count and the file size. That is the useful information: not whether a ping was accepted, but whether the file a crawler fetches is one it can use.
The robots.txt line, and where it goes
This is the passive route, it costs nothing, and every major crawler reads it. One line, anywhere in the file, absolute URL:
Sitemap: https://example.com/sitemap.xml
The tool builds that line from the URL you checked and gives you a copy button, because the 2 mistakes people make with it are both avoidable. The first is using a relative path; the directive requires a full absolute URL. The second is putting it inside a User-agent block as though it were scoped to one crawler. It is not group-specific. Put it on its own line, typically at the top or bottom of the file.
If you have multiple sitemaps, list each one on its own Sitemap: line, or list one sitemap index and let it point at the rest.
Search Console is the only route that reports back
Adding the sitemap in Google Search Console is the only submission method that tells you anything afterward. You get the last-read date, the discovered-URL count and any parse errors, and those 3 facts are worth more than a ping ever was.
The comparison worth internalizing: robots.txt makes a sitemap discoverable, Search Console makes it observable. If a sitemap has been submitted and shows a last-read date from 3 months ago, that is information. A ping endpoint never told you anything of the kind, even when it worked.
Submit it once. Resubmitting after every content update does nothing, because a submitted sitemap is refetched on its own schedule.
When the 50,000-URL cap bites
The spec limits a single sitemap file to 50,000 URLs and 50 MB uncompressed. Past either limit, the file is rejected and the URLs in it are not read.
The fix is a sitemap index: one file listing your child sitemaps, each child under the cap. An index can itself hold 50,000 entries, so the ceiling is high enough for essentially any site.
<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<sitemap>
<loc>https://example.com/sitemap-products-1.xml</loc>
<lastmod>2026-08-21</lastmod>
</sitemap>
<sitemap>
<loc>https://example.com/sitemap-blog.xml</loc>
<lastmod>2026-08-27</lastmod>
</sitemap>
</sitemapindex>
The checker tells you which of the two shapes you gave it. If you paste an index, the entry count is the number of child sitemaps, not the number of pages, which catches the common mistake of thinking a site has 12 URLs when it has 12 sitemaps.
Split by content type rather than arbitrarily. A products sitemap and a blog sitemap that change at different rates are easier to diagnose than 4 sitemaps of 12,500 mixed URLs each.
The errors this catches
Most broken sitemaps are broken in a small number of ways, and the parse check surfaces all of them.
- An HTML page returned with a 200. Your framework serves a soft 404 or a login page at the sitemap path. It parses as HTML, not XML, and the check fails. This is the single most common cause of a sitemap that has been "submitted" for months with zero discovered URLs.
- A byte order mark. An editor saved the file as UTF-8 with BOM and the invisible bytes before the XML declaration break parsing.
- Unescaped ampersands in URLs. A raw
&in a query string invalidates the document. It has to be&. - A gzipped file. Crawlers accept
.xml.gz, but point this checker at the uncompressed.xmlif you have one, since a gzipped body fetched as text will not parse and shows up as a failed XML check rather than a real problem. - HTTP instead of HTTPS. Flagged separately. It usually means the sitemap was generated with a stale base URL, which often means the
<loc>entries inside are wrong too. - Cross-domain entries. URLs in a sitemap should be on the same host as the sitemap itself. This checker does not verify that, so it is worth a manual look.
Getting crawled faster without a sitemap ping
There was never much speed in the ping endpoint anyway. What actually moves discovery:
- Keep the
Sitemap:line in robots.txt correct and the file reachable. - Submit once in Search Console and check the last-read date when something looks stuck.
- Use the URL Inspection tool for individual urgent pages. It is the closest thing to a real-time signal Google offers.
- Link the new page internally from something that already gets crawled. This is still the fastest reliable route.
- For Bing and Yandex, IndexNow is the current mechanism. It is a separate protocol with its own key file, and this tool does not submit to it for you.
None of these are instant. A sitemap is a discovery aid, not an indexing guarantee, and a discovered page can still sit unindexed if there is nothing there worth indexing. BlazeHive automates SEO content end to end if that is the part you are short on.