With the bare domain we look in /sitemap.xml and in robots.txt. Up to 10 sub-sitemaps of an index.
The sitemap and the sampled URLs are read from our server, with an agent identified as EinscubeBot. Nothing is stored.
The sitemap summary, the review and the sample of checked URLs will appear here.
Summary
- Type
- —
- URLs declared
- —
- Sub-sitemaps
- —
- Newest date
- —
- Oldest date
- —
- Read from
- —
Review
Real status sample
URLs spread across the whole sitemap, requested one by one. In a healthy sitemap they all respond 200 with no hops.
| Status | Hops | URL |
|---|
Next step
Shall we fix it for you?
Send us this result and we reply within one business day with what we would fix first, how much work it is and what you can leave as it is.
Opens the form with the diagnosis already written. You can edit it before sending.
How to use it
01
Type the domain
Or the exact sitemap URL if it lives elsewhere. If it is an index, its sub-sitemaps are read and added up.
02
Read the review
Valid XML, absolute URLs on the same domain, real dates. Each finding says what Google does with it.
03
Look at the sample
A selection of URLs spread across the file, actually requested. A 404 or a redirect in the sitemap is the classic symptom of a half-done migration.
What does Google look at in a sitemap?
- <loc>
- The URL, absolute and canonical. It is the only essential part: what you declare here is what Google understands you want indexed.
- <lastmod>
- When the content really changed. Google uses it to decide what to recrawl; if the date lies, it stops trusting the whole file.
- <priority>
- Ignored since 2023. Google said so in its documentation: it influences nothing.
- <changefreq>
- Ignored as well. The real frequency is inferred from the change history, not from what you declare.
- 50,000 · 50 MB
- Maximum URLs and size per file. Beyond that, split it into several and join them with a <sitemapindex>.
- 200 and canonical
- Every URL should respond 200 and be the canonical version. One that redirects, returns 404 or carries noindex is noise that Google ends up punishing with less crawling.
The sitemap is the first place a broken migration shows
When a site changes platform or structure, the new sitemap usually comes out fine. What fails is what remains inside: old URLs that now redirect, pages left without an equivalent that return 404, http versions nobody cleaned up. Google reads it all, compares it with what it finds and lowers its trust in the whole file.
On the sites we build, the sitemap comes from the same inventory as the pages and is verified on every build: every declared URL exists, responds 200 and is canonical, or the deployment does not go out. This tool is the way to check the same on a site we did not build.
Frequently asked questions
Where is my sitemap?
Almost always at /sitemap.xml at the root of the domain, which is where Google looks by default. If your platform generates it elsewhere — WordPress with certain plugins uses /sitemap_index.xml, others /sitemap-index.xml — the usual thing is to declare it with a "Sitemap:" line in robots.txt. This tool tries those three paths and reads robots.txt; if it is in none of them, type its full URL.
URL sitemap or sitemap index?
A URL sitemap (<urlset>) lists pages; an index (<sitemapindex>) lists other sitemaps. The index is mandatory past 50,000 URLs or 50 MB, and convenient long before: one per content type lets you see in Search Console which section has indexing problems. Here up to ten sub-sitemaps are read and their URLs added up.
Do I need lastmod?
Yes, if the date is real. Google uses it to decide what to recrawl, and on large sites that is the difference between a change being seen in hours or in weeks. If the date is fake — all the same, all today, or in the future — Google detects it and stops considering it for the whole file. Better no lastmod than an invented one.
Does Google use priority and changefreq?
No. It confirmed it in 2023: both fields are ignored. They do no harm, but any effort spent tuning them is wasted. If the generator writes them by default, leave it; if you would have to write them by hand, do not.
How many URLs fit in a sitemap?
50,000 per file and 50 MB uncompressed, and indexes can point at up to 50,000 sitemaps. Those are protocol limits and Google applies them as is. In practice, files beyond 10,000 URLs are worth splitting already: when Search Console flags a problem, a small sitemap tells you which section it is in.
Why does Search Console say "couldn’t fetch"?
One of four things: the URL responds something other than 200 (a redirect counts), the XML has a syntax error, robots.txt blocks the sitemap path, or the server is so slow that Google gives up. This tool reproduces the first three: it requests the URL, validates the XML and, if you use the bare domain, reads robots.txt.
Should noindex pages be included?
No. The sitemap is the list of what you want indexed; adding a noindex page tells Google "index this" and "do not index this" at the same time, and Search Console flags it as an error. The same goes for pages that redirect, non-canonical ones and those returning 404: out of the sitemap.
Is anything I check stored?
No. The sitemap and the sampled URLs are requested from our server on Cloudflare because a browser cannot read files from another domain; the analysis happens in your browser and we log neither the domain nor the results. Responses are cached for ten minutes so repeating the check does not download the same thing again.
Does the sitemap declare pages that no longer exist?
It is usually the tip of a migration without a redirect matrix. We review the whole thing: sitemap, redirects, canonicals and whatever Search Console has been flagging for months.
We reply within one business dayBogotá · UTC−5