Validate a sitemap
A sitemap is the one file that's supposed to be a trustworthy inventory of a site, and yet most of them accumulate malformed and relative URLs and formatting slips that quietly erode how much a crawler trusts the rest of the file.
Run — free
This endpoint reads the XML, checks that every listed URL is a well-formed absolute address, and reports whether the file carries lastmod dates.
Why trust in the file matters
A sitemap doesn't force a search engine to crawl anything; it's a submission, and crawlers weigh how reliable that submission has historically been. A file that a crawler can't parse, or that lists addresses it can't resolve, teaches it to treat the whole file with more skepticism, which can slow discovery of the legitimate new URLs sitting right alongside the broken ones.
What gets checked
The task reads the sitemap, extracts every URL listed in a loc entry, and checks that each one is a syntactically valid absolute URL — the single most common structural fault a generator introduces. It reports how many URLs the file lists, which of them are malformed, and whether the file carries lastmod dates at all. It checks the syntax of what's declared; it does not fetch the URLs, so their live HTTP status is a separate, page-by-page matter.
Absolute URLs, not relative
The sitemap protocol requires every location to be a full absolute URL, scheme and host included — a relative path like /products/42 is invalid in a sitemap even though it works fine as a link in a page. This is exactly the fault an export or a hand-edit slips in most often, and it's the one this check is built to surface: a relative or otherwise unparseable address is listed back to you individually rather than hidden inside one opaque failure.
A format built for a different era
The sitemap protocol was designed when sites were smaller and updates were infrequent enough that a hand-maintained file made sense; today's sitemaps are almost universally auto-generated, and the errors that creep in are correspondingly systemic rather than one-off typos — a template bug affects every URL of a given type at once, which is exactly the kind of pattern-level issue a syntax pass is built to surface quickly.
Keeping it clean over time
Because sitemaps regenerate on every content change for most sites, validating them once and assuming they stay correct is a losing strategy; the practical approach is to submit the sitemap URL after each deploy or on a recurring schedule, receive a task_id immediately, and get the list of any malformed URLs and whether lastmod is present on your webhook once the fetch completes. At $0.002 per request, checking a large sitemap regularly costs far less than losing crawl budget to a file the crawler can't read.
What you can do with it
Post-deploy sitemap health check
Read the regenerated sitemap right after a release to catch a template bug that's suddenly emitting malformed or relative URLs.
Relative-URL sweep
Run a full sitemap through the check to catch relative paths a generator slipped in where absolute URLs are required, the fault Search Console reports most vaguely.
Lastmod presence audit
Confirm the regenerated sitemap still carries lastmod dates at all, a field generators sometimes drop entirely between releases.
Pre-submission syntax gate
Before submitting to Search Console, confirm every URL parses as a valid absolute address so the file isn't rejected on the first try.
FAQ
What does the sitemap check do?
It reads the XML, extracts the URLs listed in loc entries, reports how many there are and which are not valid absolute URLs, and indicates whether the file carries lastmod dates.
Will it catch broken links inside the sitemap?
It catches URLs that are malformed or relative. It does not fetch the URLs, so a live 404 or a redirect is a separate check, done page by page against the actual server response.
Does it check hreflang in sitemaps as well as HTML?
No. It reads the loc URLs and whether lastmod is present; it does not inspect xhtml:link hreflang annotations inside the sitemap.
Does it enforce the sitemap size limit?
The sitemap protocol itself caps a file at 50,000 URLs and 50MB uncompressed. This check reads the URLs and their syntax and reports the count; it does not flag or block a file that exceeds the limit for you.
How much does one check cost?
$0.002 per request, charged only when the fetch completes successfully; failures retry up to three times before returning an error at no charge.
Is there a free tier?
The tool above runs free in your browser. The API is paid — each call draws from your prepaid ForHosting KIT balance: top up from $10.00 (it never expires), pay each request's published price, and a call with no balance returns HTTP 402. No subscription, no tokens, and a failed task is never charged.
How do I get the report?
By signed webhook, recommended for automated pipelines, or a signed link valid for 24 hours.
Can I validate a sitemap index that references multiple child sitemaps?
It reads the URLs a file lists. For a sitemap index, that means the child-sitemap URLs are checked for valid syntax; it does not fetch and validate each child file in turn.
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/seo/sitemap-validate \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://example.com/sitemap.xml"}'const res = await fetch("https://api.kit.forhosting.com/seo/sitemap-validate", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"url": "https://example.com/sitemap.xml"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/seo/sitemap-validate",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"url": "https://example.com/sitemap.xml"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/seo/sitemap-validate", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"url":"https://example.com/sitemap.xml"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://example.com/sitemap.xml"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/seo/sitemap-validate", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"url": "https://example.com/sitemap.xml"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "seo.sitemap_validate",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |