free tool · no login
Sitemap Health Check
A sitemap is a list of promises: every URL in it says "index me". This sitemap checker fetches each one and reports the promises the site cannot keep, with the guide that explains each defect. No Search Console, no login.
- Reads any public sitemap or sitemap index, up to 300 URLs per run.
- Seven defect kinds, each linked to the guide that explains it.
- Nothing stored: the sitemap, the pages and the report live in this tab and two stateless readers on this domain.
Run a health check
Paste the sitemap URL
A sitemap or a sitemap index. Nothing to connect.
Press Check sitemap health
Each URL is fetched once and read.
Read the defect list and follow the guide for the biggest one
Every defect kind links to the guide that explains it.
01 Paste the sitemap URL
A sitemap or a sitemap index. Indexes are read child by child, up to 30 children.
Browsers cannot read another site's sitemap or pages, so both are fetched by two small readers on this domain that keep no copy and write no log. The first 300 URLs are checked; larger sitemaps get a note saying so.
02 Run it
Each URL is fetched once, following redirects, and its status, robots directives and canonical are read. robots.txt is matched with Google's precedence rules. lastmod comes from the sitemap itself.
no sitemap loaded
Health report
0
0 of 0 checked URLs carry at least one defect
This sitemap has more than 300 URLs. The first 300 in sitemap order were checked.
Every URL carries the same lastmod. Google treats a lastmod that never varies as noise, so this sitemap is not helping Google decide what to recrawl.
No readable robots.txt was found at the sitemap's origin, so robots.txt blocks were not checked.
| URL | Status | Defects |
|---|
No defects on any checked URL. That is a clean sitemap.
This sitemap is in good shape.
Under 5% of checked URLs carry a defect. If pages from it are still not indexing, the sitemap is not the reason; read what Search Console is actually reporting next.
There are real defects here, and each has a name.
The list above says which kind leads and links to the guide for it. If you would rather have someone read the export first, send it to me and I will tell you what the pattern is, free.
Almost a third or more of this sitemap is asking Google to index pages it cannot or should not.
At this share it is usually one generator setting or one template repeated, not hundreds of separate mistakes. See how the indexing work runs Or send me the export first
What it checks
Seven defect kinds. Each row below is exactly what the report says when it finds one, and the guide it links to.
| Defect | What it means | Guide |
|---|---|---|
| Broken | The URL answered 4xx or 5xx, or did not answer at all. A sitemap should list only pages that return 200. | Read the guide |
| Redirects | The URL redirects somewhere else. List the destination instead; Google indexes the destination and treats the listed URL as a redirect page. | Read the guide |
| Noindex | The page carries a noindex meta tag or X-Robots-Tag header while the sitemap asks Google to index it. One of the two is wrong. | Read the guide |
| Canonical elsewhere | The page declares a different URL as canonical. Google will index that URL, not this one, so list the canonical in the sitemap. | Read the guide |
| Blocked by robots.txt | robots.txt disallows Googlebot from fetching this URL, so it can never be crawled from the sitemap. | Read the guide |
| Stale lastmod | lastmod is more than 365 days old. Google uses lastmod to decide what to recrawl and ignores it once it stops matching real changes. | Read the guide |
| Future lastmod | lastmod is a date that has not happened yet, which Google treats as an untrustworthy signal. | Read the guide |
Where your data actually goes
Browsers are not allowed to read another site's sitemap or pages, so two small readers on this domain do it: /api/sitemap reads the sitemap and robots.txt, and/api/sitemap-health fetches each page once, following redirects, and returns only the status, the robots directives and the canonical.
Neither reader writes a log line or stores anything. They hold a response only long enough to return it to your tab, and the report is built in the page, so reloading destroys it. Nothing is written to any server, mine included, and no Google token is involved because there is none.
The pages are fetched with the User-Agent shahidali.co sitemap health check, so a site owner can see the run in their own logs and knows exactly what touched their pages. Full detail on the privacy page.
The limits, stated plainly
- 300 URLs per run, the first 300 in sitemap order. A larger sitemap gets a note saying so; run a child sitemap on its own for the rest.
- 30 child sitemaps for a sitemap index, read in the order the index lists them.
- Eight seconds per page. A page that takes longer is reported as broken with a timeout, which is worth knowing in itself.
- Only the
<head>is read, up to 256 KB. Body content is never fetched past that point. - robots.txt is matched for Googlebot with Google's precedence rules: the most specific matching group, longest rule wins, allow beats disallow on a tie. It is read from the sitemap's host and applied only to URLs on that host; a sitemap listing another host gets no robots verdict for those URLs.
- lastmod older than 365 days is called stale. A date that has not happened yet is called future.
- It reads what the page serves to this reader. A site that serves Googlebot something different, through cloaking or bot rules, will differ from what Google sees.
Straight answers
Does this need Search Console access?
No. Everything this tool reads is public: the sitemap, robots.txt, and the pages themselves. There is no Google sign-in, no property to pick and no quota spent. That also means it can check any site's sitemap, not just your own, which is useful when you are looking at a prospect or a competitor.
Is a redirect in a sitemap really a defect?
Yes. Google indexes the destination of a redirect, not the URL that sends it there, and Search Console reports the listed URL as "Page with redirect". Listing redirecting URLs wastes crawl on hops and makes the sitemap disagree with the site. List the destination instead. The one exception is a redirect that is about to be removed, and even then the sitemap should follow, not lead.
Why is my page marked noindex when I never added a tag?
A noindex can arrive as an X-Robots-Tag HTTP header rather than a meta tag, so it does
not show in the page source. SEO plugins, staging or "discourage search engines" settings, and CDN
or hosting rules are the usual sources. The tool reads both the header and the tag, and reports
noindex when either says so. Open the response headers in your browser's network panel to see which.
Why does robots.txt show as blocked when I can open the page?
Your browser is not Googlebot. robots.txt does not stop a page from loading; it tells crawlers which paths they may fetch. This tool matches each URL against the group of rules that applies to Googlebot, using Google's precedence rules, so a URL your browser opens fine can still be one Google is not allowed to fetch. If a listed URL is blocked, Google cannot crawl it from the sitemap.
What should I fix first?
Broken and robots-blocked first: those URLs cannot be indexed at all. Then noindex, because the sitemap and the page disagree and one of them is lying. Then canonical elsewhere, so the sitemap lists what Google will actually keep. Then redirects, which are housekeeping. lastmod comes last: it does not stop indexing, but a stale or identical lastmod on every URL stops it helping.
Send me the CSV and I will tell you which one cause is behind most of it, free.Send it on WhatsApp.