How this tool works, step by step
Enter one public website or sitemap URL. The checker follows a bounded route from discovery to XML parsing and, for an index, a small sample of its child files. The ten steps below describe the sequence and the exact evidence you receive.
Start with the website or a precise XML address
Paste a bare domain such as example.com and the checker adds HTTPS. In website mode it requests the root robots.txt, reads same-site Sitemap declarations, and tries a small set of conventional root paths. If a usable sitemap appears, it displays the exact address and HTTP response. A site can publish its map elsewhere, especially under a custom framework or a plugin-specific path. When discovery misses it, paste the full sitemap URL to request that exact resource. The entered path is treated as a sitemap when it ends with .xml or .xml.gz.
The tool checks one website at a time. It does not crawl the entire domain to find undocumented files or try every plausible naming scheme. Its discovery probes stop after a bounded list and stop early after finding a valid XML sitemap. That limit keeps a free public check predictable for both the website being tested and the service running the check. If a robots.txt file lists multiple sitemap documents, inspect the ones most relevant to your goal separately. A declared path is useful evidence, but its presence in robots.txt alone does not prove the referenced resource works.
Step 1: interpret robots.txt declarations
A Sitemap directive in robots.txt provides a direct clue about where the publisher keeps XML sitemap files. Unlike crawl rules under a particular User-agent group, sitemap declarations act as document-level discovery pointers. The checker reads lines beginning with Sitemap:, extracts their URLs, and retains same-site candidates. It shows the response status of robots.txt and a limited list of valid same-site declarations, so you can compare the published hint against the file that was actually examined.
A missing robots.txt is not automatically a sitemap problem. Some websites place a sitemap at a standard path without advertising it in robots.txt; others submit a sitemap directly through a search engine tool. A broken declaration is worth fixing because it sends a crawler or a human toward an unhelpful address. Check capitalization, scheme, hostname, path, and redirects. If the declaration points across domains, this focused tool will not fetch that external domain as part of a single-site request. Paste the intended sitemap address separately when you control or want to investigate that other property.
Step 2: probe common sitemap paths
For a domain entry, the checker considers up to two same-site declarations and familiar paths including /sitemap.xml, /sitemap_index.xml, and /wp-sitemap.xml. It removes duplicate candidate URLs and tries at most four candidates in order. The report exposes those attempts with an HTTP status or a concise error. It stops when it finds the first parseable XML sitemap. This is a discovery strategy, not a standard requiring every website to use any particular filename.
A 404 on one common path may be harmless when another path returns a valid sitemap. A redirect can also be ordinary, provided it stays on the same website and ultimately reaches the file. Read the discovered final URL alongside the candidate list. If the wrong map wins because several independent maps are published, provide the exact XML address for the map you actually want to inspect. A page that answers with HTML instead of sitemap XML will fail the XML parse and will not be silently counted as a usable sitemap.
Step 3: read a bounded response
The checker requests sitemap resources with a 2 MB read limit per file and a shared time budget. It refuses a response that advertises more than 2 MB through Content-Length, and it stops reading if the streamed body grows beyond the same threshold. A .xml.gz resource can be decompressed, but the expanded XML is also capped at 2 MB. This avoids unbounded work from huge downloads or compressed files with unexpectedly large output.
The sitemap protocol permits larger files than this free checker reads. Therefore an oversized response does not mean that your sitemap violates a search engine limit; it means this public diagnostic did not inspect that file. Split very large inventories into sensible child files and use a sitemap index if the publishing system supports it. For a file near the limit, remember that a sitemap can change between checks as pages are added. The byte count in the report describes the decoded XML that this request successfully read, and a partial or failed download is never represented as a complete parsed count.
Step 4: validate XML and identify the root
Before counting entries, the checker validates the XML syntax. It accepts an XML urlset or sitemapindex root after normalizing namespace prefixes and rejects other document roots. This catches several easy mistakes: an HTML error document saved with an .xml extension, truncated XML, mismatched tags, or a response from an endpoint that does not serve a sitemap. DTD and entity declarations are excluded from this check to keep public XML parsing bounded.
A technically valid XML document may still be a poor sitemap. Syntax validation establishes that the structure can be parsed; subsequent checks inspect the entries within it. Conversely, a one-line XML validation error does not identify the publishing system that introduced the fault. Open the file and inspect the relevant tag, especially if a caching layer, proxy, plugin, or deployment pipeline transforms responses. Character escaping matters too: an ampersand inside a URL must be represented correctly in XML. Fix the generating template or feed rather than patching a generated file that will be overwritten.
Step 5: separate URL sets from indexes
A urlset lists page URLs directly. A sitemapindex lists sitemap documents, each of which may contain page URLs. The report labels the root type and counts its direct entries. It does not add index entries to page URL counts as though they were the same thing. For an index, the checker attempts up to three eligible same-site child sitemaps and displays a separate result for each requested child.
If an index lists 28 children and only three are fetched, the counts from those three describe a sample of the index, not the complete website inventory. The report shows both the number of child references found and the number actually requested. Children outside the same website, malformed locations, and files exceeding the limits cannot be treated as verified. Use the exact URL of a remaining child to check it individually. This approach gives a useful first look without turning one anonymous public request into dozens of outbound requests.
Step 6: count entries without guessing
Every successfully parsed file contributes its own entry count. In a urlset, an entry is a url node; in an index it is a sitemap node. The headline 'entries read' adds entries across parsed files, so it can include index references as well as page locations. Inspect the per-file type if you need a pure page URL count. The checker also displays a handful of sample locations from each parsed file so you can see what the published XML actually contains.
Counts are evidence about the XML at the moment of the request. They are not a comparison with your content management system, your internal URL database, all public URLs, or search engine coverage. A count of zero can be legitimate for an intentionally empty staging sitemap, but on a production property it is a prompt to investigate the generator and its filters. If several children share the same page URL, a duplicate count calculated within each file does not reveal duplicates across all unchecked children. For a complete inventory, run an audit with wider coverage.
Step 7: inspect loc values
Each url or sitemap entry should contain a usable absolute location. The checker examines loc as a URL, flags values it cannot parse safely, and recognizes when an entry points outside the requested website. It removes fragment identifiers for comparison and reports duplicate locations within each file. These signals help you spot empty loc nodes, relative paths, repeated page addresses, and references that unexpectedly change domain.
Different subdomains may represent deliberate site architecture, but a focused same-site check cannot safely assume they are controlled as one property. An external entry deserves a human review against the site's intended sitemap scope. Check migrations carefully: old hostnames, test domains, and preview links can linger in generated XML after a release. When duplicates are found, investigate feed assembly and normalization, including trailing slashes, query parameters, case, and locale paths. Two URLs that look related can still be distinct addresses; this checker does not merge them into a guessed canonical.
Step 8: review lastmod signals
An optional lastmod value indicates when the corresponding page or child sitemap was last materially modified. This checker counts entries that supply it and flags values that do not fit an accepted date or timestamp shape. The report shows sample dates next to sample locations. Each requested XML file card also shows the HTTP Last-Modified header when supplied. For an index child, a separate field shows the parent sitemap index's lastmod for that child; these two dates may differ and neither proves when every page inside the file changed. A missing lastmod is informational; there is no reason to invent a date for every entry merely to increase a metric.
Correctness matters more than coverage. If a publishing system rewrites every lastmod on every build while the pages themselves are unchanged, that timestamp can become less useful to a crawler. Align it with meaningful page updates and make sure timezone offsets and calendar dates are valid. This tool checks the format and parseability of a value, not whether an article really changed on that date. Confirm the generating system's update semantics when a whole sitemap appears freshly modified after an unrelated deployment.
Step 9: explain skipped child files
When the root document is a sitemap index, child inspection is intentionally narrow: at most three same-site child files, within the remaining shared time budget. A child can report an HTTP error, XML parse error, excessive size, a blocked or failed network request, or a redirect that leaves the site. That error appears on the child card. The root index remains a separately parsed resource; a failing child should not erase the evidence that the index itself loaded.
'Listed' and 'checked' must remain separate. If the index advertises twelve children and three were requested, nine are beyond this pass even if all three checked children look healthy. The interface states this limitation near the numbers and in the coverage note. To investigate a particular section, copy that child's URL into the form for a direct check. A recurring failed child should be fixed at its generating endpoint, because a crawler following the index would encounter the same published reference.
How to read the results
Begin with the status and the primary XML file. Compare direct entries in that file with the number of child files actually parsed. A successful count applies only to files fully read and parsed within this check's limits.
How to read the four headline numbers
The report emphasizes parsed files, entries read, duplicates, and review signals. Parsed files counts only XML documents that returned a supported root and passed validation. Entries read totals direct nodes in those successfully parsed files. Duplicates are repeated normalized loc values within a file. Review signals collect invalid URLs, entries outside the website, and malformed lastmod values, with the categories broken out in evidence cards.
A pleasant row of zeroes can mean a healthy small sitemap, but it can also mean no valid file was found. Always read the status banner and file cards first. A zero for duplicates on a file that could not be loaded proves nothing about its actual contents. Likewise a result containing an index with 50 references and one parsed child does not prove the other 49 children are sound. The number cards are designed to make the current inspection legible; the detailed scope makes their denominator and meaning honest.
What a successful check means
A successful parsed result means the checker reached a sitemap resource, read the full body within the tool limit, validated XML, identified the expected root, and inspected the entries shown in the report. If it also checks index children, each child gets its own success or error state. This is strong evidence about those specific files at that specific moment, subject to the website's response to this checker.
It is not a guarantee that Google has fetched the same content, accepted every location, or indexed any particular page. Search systems make independent choices about crawling and indexing. They may encounter different responses by geography, user agent, time, or access control. Use your search engine's webmaster reports and server logs to compare what it discovered with what your website intended to publish. If a search engine reports a sitemap fetch problem that this check cannot reproduce, compare the exact sitemap URL, response status, redirects, access rules, and observation time.
Common issue: sitemap missing
A missing result can arise from a genuinely absent sitemap, a custom path outside the small probe list, robots.txt pointing to an outdated address, a temporary origin failure, or a site that blocks automated fetches. The report retains attempted paths to help you distinguish these situations. First open your expected XML address directly. Then paste that exact URL into the checker. Finally compare robots.txt declarations with the address that actually works.
A website is not automatically broken because it lacks an XML sitemap. For a modest, well-linked site, crawlers can discover URLs through navigation. Nevertheless a reliable sitemap becomes especially helpful when a site has many pages, newly published content, or URLs that are difficult to find by following links. If your generator is disabled, inspect the setting in the CMS or deployment configuration. If a reverse proxy serves a branded HTML 200 error page at the XML address, fix the upstream response and its HTTP status rather than merely renaming the URL.
Common issue: invalid XML
Invalid XML often follows a small template mistake: unescaped special characters, a closing tag in the wrong place, duplicated root declarations, or an injected error message ahead of the XML declaration. The checker reports the parser's short error message when possible. Visit the reported file URL and look at its source response, not only its formatted browser rendering. A browser can hide the raw bytes and encoding clues that explain a validation failure.
Many sitemap files are generated automatically, so the permanent fix usually belongs in the generator. If the problem appeared immediately after a plugin update or a deployment, compare the output before and after that change. Ensure the endpoint serves XML rather than a login page or a security challenge to anonymous visitors. After updating the generator, run this check again and compare the exact final URL, byte count, root type, and entry totals. A syntax fix that accidentally drops most URLs still needs attention.
Common issue: a valid index and failed children
An index is a directory of sitemap files, not proof that its children work. A child path may become stale after a URL migration, produce 404 during cache regeneration, or return an oversized response. The checker displays child results separately, allowing you to identify the file to inspect directly. A child redirect within the website can be acceptable, but a redirect to another host is not followed by this public check.
Repair the source that writes the index reference, then verify the child URL. If a child is generated only on demand, evaluate whether its first request is reliably fast enough for crawlers. For large sites, split content by a stable category or by a predictable range so each generated file remains manageable. Avoid leaving empty or deleted child entries in the index after a content type is retired. The tool's three-child sampling limit means you should check a suspicious child directly even when the sampled cards look fine.
Common issue: duplicate locations
A repeated loc within one parsed file may be caused by two content feeds contributing the same page, overlapping pagination windows, a category and a global feed both being appended, or an inconsistent migration rule. The duplicate number measures repeated normalized URL strings within that file. It does not say whether two distinct addresses share equivalent content, nor does it compare every child file in a large index.
When investigating, collect concrete examples from the sitemap XML. Follow the generator's inputs to find where the second copy was introduced. Set a clear rule for trailing slash and canonical query variants before publishing, and avoid using this checker's duplicate number as a substitute for canonical inspection. If the same page appears in two different child sitemaps, a per-file duplicate counter can remain zero. A larger site audit or an exported inventory comparison can catch such cross-file overlap.
Common issue: unexpected external URLs
A sitemap can expose a forgotten staging hostname, a prior production domain, or a third-party URL that was accidentally inserted during import. The checker flags loc values whose hostname differs from the checked website after allowing the common www form. The exact treatment of hosts should be reviewed against your architecture: an intentional separate property may need its own dedicated sitemap and its own check.
If the external address is accidental, correct the content source or sitemap generator and republish. If a migration is in progress, verify that redirects, canonical declarations, and submitted properties align with the new domain; this focused XML inspection does not test those destinations. For a sitemap index, external child references are not fetched in this single-site pass. This boundary protects other hosts from surprise requests and makes the child sampling budget predictable. Enter the external URL separately only when you have a reason to inspect that property.
Sitemap best practices
include canonical, useful URLs
Choose sitemap locations that represent the pages you actually want discovered. Usually that means stable, absolute URLs for useful pages on the intended host. Avoid filling a sitemap with internal search results, temporary test addresses, session identifiers, or duplicate parameter combinations unless they serve a deliberate indexing purpose. A sitemap can be an efficient inventory only when its contents reflect the site's public information architecture.
This checker cannot decide whether each listed page has a self-referencing canonical, a noindex directive, a 200 response, or a useful body. It reads the sitemap file itself. Pair its XML findings with a crawl or URL inspection where those destination signals matter. When a page is deleted or permanently moved, update the generator so future XML points to the preferred destination. Do not assume that merely listing a URL overrules conflicting instructions on the page or guarantees appearance in search results.
design an index you can maintain
An index is helpful when a site's inventory is naturally split into several files, such as products, articles, languages, or date ranges. Keep the references stable and make the division intelligible to the team maintaining them. If generation is asynchronous, publish the child files before publishing an index that references them. When a segment disappears, remove its index entry promptly. These operational details reduce intermittent crawler errors.
The sitemap protocol sets upper bounds for entries and file sizes, while this free diagnostic has a smaller reading limit. Plan your split to keep generated resources comfortably below protocol limits and appropriate for routine monitoring. Prefer a predictable generator over a manually edited collection that can drift after each release. Periodically check an index and representative child files, including newly added segments. When the checker reports more listed children than it fetched, record that as sampling, then inspect any critical or recently changed child separately.
keep update dates honest
lastmod should reflect a real, meaningful modification to the content represented by the location. A date that changes every night because the sitemap file was rebuilt can mislead a reader of the feed. Set the value from a reliable content update field when your publishing system offers one. Ensure values are valid dates or valid timestamps with the intended timezone.
A missing lastmod field does not make an otherwise valid sitemap unusable. It may be better to omit unreliable data than to publish fabricated precision. If the value is present on a sitemap index child, make sure it tracks changes in that child file's content rather than an unrelated deployment timestamp. This checker reports presence and syntactic validity only. To establish that a date is truthful, compare it with the content record and actual page changes. Regularly spot-check a few entries after publishing pipeline changes.
connect publishing and monitoring
Treat the sitemap as a generated release artifact with observable behavior. After a deployment, confirm the XML endpoint responds publicly, the root type is correct, and its entry count remains plausible compared with the previous version. If your site has a sitemap index, check the specific new or changed child directly. Keep a documented owner for the generator and a way to notice unexpected drops or surges in the inventory.
The checker gives a quick manual snapshot, so record the checked URL and time when passing a report to a teammate. An overnight count change can be entirely expected after a content migration; the explanation depends on the publishing context. Combine this snapshot with search engine submission reports and your site's own release checks. Monitoring the sitemap endpoint itself is different from monitoring the pages it lists. Both matter, and they answer different operational questions. Investigate a missing index before diagnosing why an individual page has not been indexed.
A practical review routine
Begin with the site domain, then check the discovery attempts and the selected primary sitemap. Look for a supported XML root and read the parsed file count. If the root is an index, compare listed child count with checked child count. Scan the child cards for HTTP and XML errors. Then review duplicates, invalid locations, external locations, and invalid lastmod values. Finally open a few sampled loc values and compare them against the intended sections of the site.
When anything looks unusual, write down the exact resource URL, its status, the relevant sample, and whether the result came from a parsed file or a skipped file. Fix the source that generates the sitemap and run the same request again. For a large index, check selected child URLs one by one rather than assuming the first three represent the rest. Use a full site crawl and search engine reports when you need page-level behavior or complete coverage. The goal of this free check is a dependable first diagnosis that makes the next action obvious.
FAQ
Does a valid sitemap guarantee indexing?
No. A passing XML check means the examined sitemap documents were available and parseable within the stated limits. Search engines still decide whether and when to crawl a listed address, and whether it belongs in an index. An individual page may return an error, redirect, noindex instruction, a canonical pointing elsewhere, or other signals outside this tool's inspection. Use URL inspection and a deeper crawl for a particular page.
Why are there fewer URLs than pages on my site?
Your generator may include only selected canonical, indexable pages, and this report may cover just three children of a much larger index. Some sections may be deliberately omitted. Compare per-file counts with the number of index children listed and checked. Website-mode discovery can find a different file from the one you expected. Paste the exact XML URL to remove that uncertainty.
Why does the report show zero issues?
Zero review signals means none was found among the specific checks of successfully parsed files. It does not mean every index child was fetched, every destination page works, or your entire website passes an audit. If no valid sitemap was parsed, read the discovery and status cards first. A server may answer with HTML at an XML path, or the response may exceed this tool's limit.
Can I check another subdomain?
Yes. Paste that subdomain's exact public sitemap URL to check it as its own website. A check begun on the main domain does not automatically follow unrelated subdomain references. The same-site restriction also applies to redirects and index child requests, so another host is not contacted without a separate check.
What does a redirect mean?
A same-site redirect may lead to a current sitemap file; its final URL and redirect count appear on the file card. Redirects leaving the requested website are stopped. Compare the final URL with the published robots.txt declaration and update stale references if your generator moved.
Is robots.txt required?
No. A missing robots.txt does not invalidate an otherwise valid sitemap. The checker tries a few conventional root paths after the robots.txt attempt. If your sitemap lives elsewhere, enter its exact address. If robots.txt lists a file that no longer exists, correct its Sitemap declaration to point to the current file.
Are compressed XML sitemaps supported?
A .xml.gz resource can be read when the transfer and decompressed XML stay within the tool's 2 MB per-file limits. An oversized file may still comply with the sitemap protocol; this small public check cannot inspect it completely. Consider splitting a large feed into child files referenced from an index.
Does the checker verify every listed page?
No. It requests sitemap XML files and a bounded set of same-site index children. It does not request the page URLs listed inside a urlset, inspect their HTTP status, run JavaScript, or read their canonical or noindex signals. An entry count is a count of published XML nodes, not verified live pages.
Does it prove that lastmod is truthful?
No. The report checks presence and date shape, not whether the page really changed on that date. Compare sample timestamps with editorial records when accuracy matters. A missing lastmod value is informational; fabricated timestamps are less useful than an omitted field.
Can I inspect the entire index?
The free checker requests up to three eligible children within a shared time budget. It always separates the count of children listed from children actually requested. Paste a specific child URL to inspect another section. For complete inventory and destination analysis, use a broader audit.
Protocol and search guidance
For format and size rules, consult the Sitemaps.org protocol. For search engine interpretation, see Google Search Central’s sitemap construction guide and its sitemap index guidance. The checker’s 2 MB and three-child limits are tool limits, separate from protocol limits.