A sitemap can open successfully and still list yesterday's broken pages. That is why “sitemap found” is not the end of the check.
Think of it as a list of public addresses you want search engines to discover. The useful question is whether those addresses lead to the right pages—not how many entries the file contains.
This guide walks through finding the file, checking the list and fixing the most common contradictions. You can do the public checks without connecting a Google account.
Find the sitemap your website actually uses
Try opening /robots.txt on your live domain. Look for a line beginning with Sitemap: and open the full address after it. Your website platform's SEO settings may also show the location.
If neither gives you an address, try /sitemap.xml. It is a common location, not a requirement. The file might instead be called /sitemap_index.xml, or your site may publish several files.
You may find one of two things:
- A URL sitemap lists page addresses.
- A sitemap index lists other sitemap files, such as separate lists for articles and products.
An index is not empty just because it does not contain your article URLs directly. Open a child sitemap before deciding pages are missing.
If the supposed sitemap shows a login screen or a normal error page, record that. A browser displaying something does not establish that the server sent a readable sitemap.
Check the file, then the pages it lists
Open SEO Dispatcher's sitemap checker. Enter the website address, or the exact XML sitemap address when you know it.
The report checks the XML, duplicate entries, domain consistency and declared dates. It also inspects up to eight eligible page URLs for responses, redirects, indexing instructions and canonicals. Larger indexes are sampled, not exhaustively crawled.
Read the file findings first. Then expand the sampled-page evidence. “Readable XML” and “these URLs lead to the intended public pages” are separate conclusions.
If a result is Not checked, do not assume that URL is fine. If the file contains 500 URLs and eight were inspected, the other 492 have not passed a page-level test.
Keep the addresses you actually want in search
Imagine a small business has one service page, a useful article and a customer account area. Its sitemap should help search engines discover the public service and article, not advertise every route the application has.
For an ordinary single-site sitemap, review these conditions:
- Use complete addresses, including the protocol and domain.
- List the preferred version of each public page, rather than every tracking or duplicate variant.
- Prefer the final live URL over an old address that redirects to it.
- Remove deleted pages and routes that intentionally require a login or carry
noindex. - Confirm each important new page appears in the relevant sitemap after publishing.
These are consistency checks. A listed URL does not override a page's exclusion or force Google to select it. A different domain can also be legitimate in a deliberately configured cross-site setup; investigate that arrangement before treating every domain warning as an error.
Google's sitemap guide explains supported formats and submission. Its canonical guidance explains how preferred page addresses should agree with other signals.
Turn a warning into the right fix
Here are hypothetical entries and the decisions they call for:
| Entry or finding | What to check | Likely action when confirmed |
|---|---|---|
/old-service redirects to /services/bookkeeping | Has the move been completed? | List the final service URL and keep the old redirect for existing visitors. |
| An article returns 404 | Was it deleted, renamed or never published? | Remove a deleted entry, or repair an article that should still exist. |
A public guide carries noindex | Was exclusion intentional? | Correct the page instruction if it should be searchable; otherwise remove it from the sitemap. |
| The guide's canonical points to another article | Are the two pages genuinely equivalent? | Keep the intended preferred version in the sitemap, or correct an accidental canonical. |
| A new article is absent | Did the live website actually publish it? | Check deployment and the generator's inclusion rules before adding a manual entry. |
A canonical mismatch deserves a decision, not an automatic replacement. And a URL returning HTTP 200 can still be an error message disguised as a normal page. Read the page as well as its response code.
Fix the generator when the file is generated
Most website platforms generate their sitemap. If yours does, change the source settings or inclusion rules, not a downloaded copy of the XML. Otherwise, the next deployment can bring the problem back.
For a GitHub-backed blog, the generator should discover published article files and exclude drafts. Publishing an MDX file is only one part of that process: its public route must exist, and the live sitemap must include the intended address.
SEO Dispatcher can prepare and publish reviewed articles through your repository. Its free sitemap checker reads the resulting public file; it does not create or rewrite your sitemap for you. If the issue is in a custom generator, give the exact finding to whoever maintains that code.
If there is no sitemap yet, first check whether your platform already offers one. Avoid installing a second generator until you know what the existing setup does. Google's sitemap introduction also explains when a sitemap is useful; a small, well-linked site may still be discovered without one.
Treat modification dates as facts
An optional lastmod value says when a page was meaningfully updated. It should not change to today just because the sitemap was rebuilt, and it should not be a future publication date for a page that is already live.
If your platform cannot produce a trustworthy date, leaving the optional field out is better than inventing freshness. priority and changefreq are not knobs for making Google rank a page higher; Google ignores those sitemap fields. This is documented in its XML sitemap notes.
Submit separately, then verify what Google reports
After the repair is deployed, reopen the actual sitemap and a few affected pages. Check that the corrected addresses and instructions are live.
The website owner can then submit the sitemap's address in Google Search Console's Sitemaps report, using the property that covers the site. This owner-side step is separate from using SEO Dispatcher's free tool, which needs no Search Console or Analytics connection.
Read Google's processing result. A successful submission does not mean every listed page was indexed. For an important individual page, use URL Inspection to see Google's evidence. The Sitemaps report help explains processing messages; our indexing guide helps you choose a next step for a page.
Do not spend your allowance checking the same unchanged file repeatedly. SEO Dispatcher permits three accepted runs total per user and domain across all free tools, permanently. Sign-in does not reset it, and accepted failed checks count. Saved reports are available to reopen for 24 hours without another run; anonymous visitors on shared networks may share an allowance.
A useful finish looks like this: the list reflects the live website, sampled problems have been fixed, and the owner knows which Google report to check next. That is more valuable than a bigger sitemap.