Submit & index · XML sitemaps
XML Sitemap Checker and Validator: Submit Your Sitemap and See Which URLs Google Indexed
Almost every site has a sitemap. Almost nobody looks at it again. The plugin generates it, Search Console says Success, and from that point the file quietly drifts: deleted pages stay listed, new pages arrive late, noindexed URLs sneak back in, and every page gets today's date in lastmod whether or not anything changed. Google keeps fetching it, trusts less of it each time, and the sitemap stops doing the one job it has.
Submit · monitor coverage · official methods only
Ready to check coverage
Paste a sitemap to sweep every URL for index status, then submit the missing ones through the official Google Indexing API and Bing IndexNow.
Coverage
indexed
Avg time to index
URLs submitted
Now eligible
Live, interactive · sample data · official methods only
Official Google Indexing API · Bing IndexNow · verified sitemaps · no spam, no PBNs
In short
An XML sitemap is a UTF-8 encoded file that lists the canonical URLs you want search engines to crawl, using a urlset wrapper with one loc element per page. Google limits a single sitemap to 50,000 URLs or 50MB uncompressed, reads lastmod only when your dates are consistently accurate, and ignores priority and changefreq entirely. Submitting one helps Google discover pages, but it never guarantees indexing: a sitemap is a hint about what exists, not an instruction to index. The only way to know it worked is to check the index status of the URLs inside it.
Last updated July 2026
Indexing treats the sitemap as a starting list, not a finish line. It reads the URLs inside your sitemaps, checks each one against Google and Bing, and tells you which are indexed, which were crawled and skipped, and which were never fetched at all, with a plain-English reason for each gap. Pages that should be in the index get resubmitted through the official Google Indexing API, Bing IndexNow and your sitemaps, then watched until the status changes. No forced indexing, because that does not exist, just an honest answer about whether the file you submitted is actually working.
Official methods only
White hat · no spam, no PBNs
Why it works
What your team gets with xml sitemaps
Validate what Google will actually accept
The size limits, encoding, absolute URLs and tag rules Google enforces, checked against the sitemap you are really serving, not the one you think you are.
Per-URL index status, not a green checkmark
Search Console tells you the file was read. This tells you how many of the URLs inside it are in the index, and names the ones that are not.
Resubmit the gaps automatically
Pages listed in your sitemap but missing from the index are pushed back through official channels and monitored until they land.
What it handles
Submitted, monitored and fixed, automatically
Indexing submits your URLs through the official Google Indexing API, Bing IndexNow and clean XML sitemaps, watches coverage across both engines, and flags any page that drops out with a plain-English reason so you can resubmit and get it back.
- Checks every URL in your sitemaps for Google and Bing index status
- Flags sitemap URLs that are noindexed, redirected, canonicalized away or dead
- Catches stale sitemaps that list pages you removed months ago
- Resubmits missing pages through the official Indexing API and IndexNow
- Tracks time to index so you know whether the sitemap is doing anything
Not indexed yet
/blog/seo-guide-2026 is discovered but not indexed
thin content signal, queued for re-crawl via the Indexing API
Why Indexing
One place to submit, monitor and fix coverage
Not a black-hat indexer that risks your site, not a free checker that only tells you the bad news. Indexing unifies official submission and live coverage monitoring, the white-hat way, across Google and Bing.
Submits the official way
Bulk-submit through the Google Indexing API, Bing IndexNow and clean XML sitemaps. We speed discovery and re-crawl using methods the engines support, never spam, PBNs or black-hat tricks.
Monitors coverage live
You do not refresh a search bar one URL at a time. Indexing watches which pages are in Google and Bing, catches anything that drops out, and tracks time-to-index across your whole site.
Diagnoses and resubmits
Every non-indexed page comes with a plain-English reason, then auto-resubmits through the official API so it gets another shot. Google still decides, but nothing waits in the dark.
At a glance
The sitemap errors Google reports, what causes them, and the fix
These are the statuses from the Sitemaps report in Search Console. Most of them are silent: the file still exists, the pages still load, and nothing tells you the sitemap stopped working.
| Google reports | What it actually means | The fix |
|---|---|---|
| Couldn't fetch / General HTTP error | Google could not retrieve the file at all. Usually a 404 after a CMS change, a 5xx while the server was busy, a robots.txt rule blocking the path, or a firewall answering Googlebot differently than it answers your browser. | Request the sitemap URL as a bot, not just in a browser, and confirm it returns 200. Check robots.txt is not disallowing the path and that no security layer is challenging Googlebot. |
| URL not allowed | The sitemap lists URLs outside its own directory or host. A sitemap at /blog/sitemap.xml cannot vouch for URLs at the site root unless you submitted it in Search Console. | Put the sitemap at the site root, which Google recommends, so it can cover every URL on the host. |
| Parsing error / Invalid XML: too many tags | The XML is malformed: an unescaped ampersand in a URL, a duplicated tag inside one url entry, or HTML served where XML was expected. | Entity escape every tag value, ship exactly one loc and one lastmod per entry, and confirm the response content type is XML. |
| Invalid date | A lastmod value that is not valid W3C Datetime format, so Google throws the date away. | Use full W3C Datetime, for example 2026-07-25 or 2026-07-25T09:12:00+00:00. If your dates are not trustworthy, remove lastmod entirely. |
| Sitemap file size error | The uncompressed file is over 50MB, or the entry count is over 50,000 URLs. | Split into multiple sitemaps and reference them from a sitemap index file. Grouping by content type also makes coverage far easier to read. |
| Empty sitemap | The file parsed but contains no URLs, which usually means a generator ran before content existed or a filter excluded everything. | Regenerate after publishing, and add a check that fails your build when the sitemap drops below an expected URL count. |
| Compression error | Google could not decompress a .gz sitemap, often because it was gzipped twice or served with the wrong encoding header. | Serve the compressed file once, with the correct content encoding, and verify it downloads and expands cleanly. |
What Google reads in an XML sitemap, and what it throws away
The spec is smaller than most people assume. A sitemap needs a urlset wrapper, a url element per page, and a loc element holding a fully qualified absolute URL. That is it. Google explicitly asks for absolute URLs, so /pricing is not acceptable where https://example.com/pricing is. The file must be UTF-8 encoded and every tag value entity escaped, which is why a single raw ampersand in a query string can break an otherwise perfect file. One sitemap is capped at 50,000 URLs or 50MB uncompressed, and past either limit you split the list and point a sitemap index at the parts.
The optional tags are where the myths live. Google ignores priority and changefreq completely, so tuning them is wasted effort. It does use lastmod, but only when your dates are consistently and verifiably accurate, meaning they reflect a real change to the main content or structured data rather than a nightly regeneration stamp. Google has been blunt about the consequence: a site whose lastmod values cannot be trusted is better off with no lastmod at all, because the tag is judged sitewide rather than page by page. If your CMS stamps every URL with today's date, you have not given Google a freshness signal, you have taught it to ignore one.
- Required: urlset, url, loc. Everything else is optional.
- 50,000 URLs or 50MB uncompressed per file, then use a sitemap index.
- Absolute URLs only, UTF-8 encoding, all tag values entity escaped.
- priority and changefreq are ignored by Google. Do not spend time on them.
- lastmod is used only if accurate. Unreliable dates get the tag ignored for the whole site.
- A sitemap at the site root can cover every URL on the host, which is why Google recommends putting it there.
Submitted is not indexed, and the gap is where traffic dies
A sitemap is a discovery aid. It tells Google which URLs exist and roughly when they changed, and that is the whole of its power. It does not push pages into the index, it does not raise rankings, and Google ranks simple inclusion in a sitemap below redirects and rel=canonical as a canonicalization signal. Search Console reporting Success means the file was fetched and parsed cleanly. It says nothing at all about whether the 12,000 URLs inside it are in the index, and the discovered-versus-indexed count in the Sitemaps report is a summary, not a list you can act on.
That gap is the entire reason this tool exists. Read the sitemap, take every URL in it, and get an actual per-URL answer: indexed, crawled and not indexed, discovered and not crawled, blocked, redirected, canonicalized to a different address, or gone. On a 300-page site you could do that by hand in an afternoon. On a 40,000-URL catalog you cannot, and that is exactly where sitemaps rot unnoticed. Once the missing pages are identified and fixed, they go back out through the official Indexing API and IndexNow and stay under watch until the status flips, so you see the fix land rather than assuming it did.
- Sitemap accepted does not mean sitemap URLs indexed.
- Sitemap inclusion is a weaker canonical signal than a redirect or rel=canonical.
- The Sitemaps report gives counts. Fixing anything needs the URL list behind those counts.
- Check index status per URL, then resubmit only the pages that are genuinely missing.
Sitemap hygiene rules that hold up on a large site
The rule that removes most problems is simple: a sitemap should contain only canonical URLs you want indexed, returning 200. No redirects, no noindexed pages, no URLs blocked in robots.txt, no parameter variants, no pagination duplicates, no thin tag archives that you would not want ranking anyway. Every URL that fails that test is a mixed signal, and enough of them make the file less useful to Google as a whole.
On big sites, split the list by content type rather than shipping one giant file: products, categories, articles, and so on, all referenced from a sitemap index. The limits are not the only reason. Splitting turns the Sitemaps report into a diagnostic, because a coverage collapse in one segment is visible immediately instead of being averaged away across everything else. Add the Sitemap line to robots.txt so any crawler that reads the file finds your sitemap without needing a Search Console submission, and regenerate the file as part of publishing rather than on a nightly job that can silently fail.
- Only canonical, indexable, 200-status URLs belong in a sitemap.
- Split by content type behind a sitemap index so coverage problems stay visible.
- Add a Sitemap line to robots.txt: any crawler reading it will find the file.
- Regenerate on publish, and alert when the URL count moves unexpectedly.
- Remove deleted pages promptly instead of leaving them to 404 for months.
Good questions
Questions about xml sitemaps
Explore more
More ways teams get every page indexed
URL indexing tool
Submit URLs the white-hat way and watch them get discovered faster.
Learn moreFast indexing for new pages
Cut the wait between publishing a page and getting it discovered.
Learn moreGoogle Indexing API made simple
All the power of the official API, none of the setup headache.
Learn moreStop guessing. Get every page indexed and keep it that way.
Bulk-submit your URLs through the official Google and Bing channels, monitor coverage, and resubmit anything that drops out, automatically. White hat only, so we speed discovery without ever guaranteeing what Google chooses to index.
Google Indexing API · Bing IndexNow · sitemaps · coverage monitoring · official methods only