Templates / Sitemap health
Checking your sitemap is still there
A sitemap that starts returning a 404, or an error page with a 200 status, is invisible until rankings move weeks later. One request a day closes that gap.
The recipe
- Request
- GET https://{{domain}}/sitemap.xml
- Schedule
- At 06:00 AM (0 6 * * *)
- Timeout
- 30s
- Attempts
- 3
- Counts as success
- 2xx and body contains <urlset
You supply
- Your domain
- example.com
Host only — no https:// and no trailing slash.
Why this job exists
Sitemaps break quietly. A framework upgrade changes the route, a redirect rule swallows the path, a CDN caches an error, a generator runs out of memory and writes a truncated file. None of these produce a visible symptom on the site itself — every page still loads — and search engines simply fetch less often and say nothing.
The discovery path without monitoring is: rankings drift, someone eventually opens Search Console, and the coverage report shows the sitemap has been failing for a month. By then the recovery takes as long as the damage did.
It is also worth being clear about what is no longer useful here. Both Google and Bing retired their sitemap ping endpoints — submitting a sitemap by pinging a URL does nothing now. Checking that the file is served correctly is the part that still matters.
Setting it up
Nothing to build: the check fetches the sitemap and asserts the response contains <urlset. That single body check is what separates this from a plain uptime ping, because the common failure is a 200 response whose body is an HTML error page rather than XML.
If your sitemap is an index that points at other sitemaps, change the body check to <sitemapindex. If it is gzipped, check the status code alone and rely on the size — a compressed body will not match a text assertion.
Checking it actually works
- Open the URL yourself and confirm the first bytes are XML rather than a rendered page.
- Cross-check the URL count in Search Console against what your generator thinks it produced; a large gap usually means truncation.
- Confirm the sitemap is listed in robots.txt, which is now the main way crawlers discover it.
Where it goes wrong
A soft 404
Many frameworks answer unknown paths with a 200 and a styled error page. A status-only check passes happily. The body assertion is the entire value of this recipe — do not remove it.
Checking a stale CDN copy
If the sitemap is cached at the edge, this check can pass for hours after the origin broke. Add a cache-busting query parameter if your CDN honours one, or check the origin hostname directly.
Expecting the ping to do something
Google retired its /ping endpoint and Bing did the same. If you have a scheduled job hitting one, it has been a no-op for a while. Use IndexNow for change notification instead.
Questions
How do I tell search engines about changes now?
IndexNow, which Bing, Yandex and Seznam support and which is a plain GET request. Google discovers changes by crawling; there is no supported push.
Daily is enough?
For a file that changes when your content does, yes. Hourly would find a breakage sooner but a sitemap outage measured in hours costs nothing — search engines re-fetch on their own schedule, which is far slower than daily.
What about checking the URLs inside it?
Worth doing, but not with this. It needs a crawler rather than a single request; this job answers whether the file is being served at all.
Running it here
This is a preset in the product, not an illustration. Pick it in the dashboard, fill in the one value above, and the job is created, scheduled and enabled — with retries, a record of every run showing status, latency and response, and an alert the first time one fails. Secret values are encrypted at rest and never rendered back.
The free plan runs 3 jobs hourly and needs no card. Where a recipe wants a finer cadence than your plan allows, it is slowed to the fastest schedule you are permitted rather than rejected.