How to Check a Sitemap for Broken Links

An XML sitemap is meant to provide search engines with a clean list of important URLs. Over time, that list can become outdated. Deleted pages may remain in the sitemap, old URLs may redirect, server errors can appear and generated sitemap files can continue publishing pages that should no longer be included.

When you need to check a sitemap for broken links, the useful part is not simply opening the XML file. You need to extract every listed page URL, request each one, follow any redirects and review the final HTTP result.

URL Verifier Pro can check URLs from XML sitemaps by discovering page URLs from sitemap files, sitemap indexes and nested sitemap structures. The discovered URLs are added to the normal URL list, where you can scan them for status codes, final URLs, redirect chains, response times and request errors.

What checking a sitemap actually covers

A sitemap check starts with the URLs published inside the sitemap files. It can help you find:

• URLs returning 404 Not Found or 410 Gone.

• Pages ending in 5xx server errors.

• Sitemap URLs that redirect instead of loading directly.

• Redirect chains, loops or missing redirect destinations.

• Requests that time out or fail before receiving a response.

• URLs blocked by robots.txt when robots handling is enabled.

• Pages that load but contain unexpected noindex or canonical signals.

• Old-domain, staging or malformed URLs published by mistake.

A sitemap audit is not the same as a full website crawl. It checks the URLs already listed in the sitemap, but it does not follow links between pages to discover every internal broken link on the site.

Why check a sitemap for broken links?

A sitemap should normally contain the current, indexable URLs you want search engines to discover. Broken or outdated entries create a poor-quality URL inventory and can hide wider publishing or migration problems.

Common causes include:

• A page was deleted without being removed from the sitemap.

• A CMS generated a URL before the page was fully published.

• A website migration changed paths or domains.

• Redirect rules were added, but the sitemap still contains the old URLs.

• A product, category or article was removed from the site.

• A deployment introduced temporary or persistent server errors.

• A sitemap generator is using stale database records.

• Nested child sitemaps have not been reviewed for a long time.

The aim is not only to find individual errors. Repeated failures in one folder, content type or child sitemap often point to a template, routing or sitemap-generation issue that can be fixed at its source.

Before you start

Decide which sitemap source represents the audit you need to run. URL Verifier Pro can begin with:

• A root domain.

• A website URL.

• A direct XML sitemap URL.

• A sitemap index URL.

• A robots.txt URL containing Sitemap: declarations.

When you enter a domain or website URL, URL Verifier Pro can check robots.txt and the common /sitemap.xml location. When you already know the exact sitemap address, enter it directly to avoid discovering unrelated sitemap files.

For a large site, review the configured maximum URL count and sitemap depth before discovery. Limits that are too low may stop the process before every nested sitemap has been reached.

Recommended workflow

1. Open URL Verifier Pro and add the root domain, website, robots.txt or direct sitemap URL.

2. Let the app discover sitemap files, sitemap indexes and nested child sitemaps.

3. Check the discovery summary for URL or depth limits.

4. Add the deduplicated page URLs to the main URL list.

5. Start the normal URL scan.

6. Filter 4xx, 5xx, failed, blocked and redirecting rows.

7. Review each original URL beside its final URL and final status.

8. Add notes or tags to group issues by cause and required action.

9. Rescan selected rows after fixes are deployed.

10. Export the remaining issues as a focused CSV report.

Sitemap discovery and URL scanning are separate stages. Discovery builds the list; the normal scanner requests the extracted page URLs and records their live results.

Discover the complete sitemap structure

A small site may use one XML file containing page URLs. Larger sites often use a sitemap index that points to separate child sitemaps for products, categories, posts, pages, languages or other content types.

URL Verifier Pro can follow child and nested sitemap indexes up to the limits configured in Settings. It removes duplicate page URLs before appending them to the URL list, which keeps the scan cleaner when the same URL appears in more than one sitemap.

During discovery, look for signs that the inventory may be incomplete:

• The maximum sitemap depth was reached.

• The maximum URL count was reached.

• A child sitemap could not be retrieved.

• A sitemap URL redirected unexpectedly.

• A sitemap belongs to an old or different domain.

• A section expected to be present was not found.

For more detail on complex structures, see How to Audit Sitemap Indexes and Nested Sitemaps.

Scan every discovered page URL

Once discovery is complete, add the page URLs to the main list and start a scan. URL Verifier Pro records the submitted URL, initial status, final destination, final status, redirect count, redirect sequence, response time and any request error.

This distinction matters. A sitemap can be valid XML while many of the page URLs inside it are broken. Validating the sitemap structure alone does not confirm that its listed pages still work.

For large lists, use sensible concurrency, per-host limits and request delays. If a server begins returning 429 Too Many Requests, 403 Forbidden or visible block responses, reduce the request rate and investigate before classifying the URLs as genuinely broken.

Understand the results

Do not treat every non-200 result as the same problem. A permanent redirect, missing page, temporary server fault and blocked request require different fixes.

Review redirecting sitemap URLs

Redirects are not automatically broken, but they often indicate that the sitemap is publishing an outdated address. A clean sitemap should generally point directly to the intended final URLs rather than making search engines pass through unnecessary redirects.

For each 3xx row, review:

• The original URL listed in the sitemap.

• The first response status.

• The final destination URL.

• The final status code.

• The number of redirect hops.

• The complete status sequence.

• Whether the final destination matches the intended page.

A direct 301 followed by a successful final page may only require a sitemap update. A chain such as 301,302,301,200, a loop or a redirect ending in 404 needs closer investigation.

Check for errors that are not ordinary broken links

Some sitemap problems do not appear as a simple 404.

Server errors

A 500, 502, 503 or 504 response may be temporary, but repeated errors should be investigated. Rescan the affected rows to distinguish a short outage from a persistent application or hosting problem.

Timeouts and connection failures

A failed request may be caused by a timeout, DNS issue, TLS failure, proxy error or connection reset. Review the error details before deciding whether the page itself is missing.

Blocking and rate limits

403 and 429 responses can be real access rules, but they can also appear when a server, CDN or firewall reacts to automated requests. Slow the scan, adjust the User-Agent when appropriate and compare the result with a normal browser request.

Noindex and canonical differences

A page can return 200 OK and still be unsuitable for a sitemap. Review noindex flags and canonical URLs when the audit is intended to confirm that sitemap entries are indexable and self-consistent.

Useful columns for a sitemap broken-link report

Start with the columns that explain the HTTP outcome clearly:

• Original URL

• Final URL

• Scan status

• Status code

• Status text

• Final status code

• Redirect count

• Redirect chain

• Response time

• Content type

• Error details

• Robots status

• Notes

• Tags

For a wider technical SEO review, also include:

• Page title

• Canonical URL

• Noindex flag

• Nofollow flag

• Meta robots

• Content length

• Server header

Keep the report focused. Developers usually need the URL, status, final destination, redirect evidence and error details. SEO reviewers may also need canonicals, robots signals and page metadata.

Suggested tags

Tags help turn a long result table into an actionable fix list. Useful examples include:

• sitemap 404

• sitemap 410

• server error

• timeout

• blocked

• redirect in sitemap

• redirect chain

• wrong destination

• old domain

• remove from sitemap

• restore page

• needs redirect

• needs developer review

• fixed

Add a short note when the tag alone does not explain the intended action. For example, record the correct replacement URL beside a row tagged needs redirect.

Fix the cause, not only the exported list

The right action depends on why the URL is failing:

• Restore an important page that was removed accidentally.

• Add an appropriate redirect when a page has moved and a clear replacement exists.

• Remove permanently retired URLs that should no longer be published.

• Update sitemap entries that point to redirecting URLs.

• Correct old-domain or staging URLs in the sitemap generator.

• Repair templates or database queries that keep publishing deleted records.

• Investigate repeated 5xx responses with the development or hosting team.

• Adjust scan settings before reporting rate-limited requests as broken.

When many failures share the same path or originate from the same child sitemap, report the pattern as well as the individual rows. One sitemap-generation fix may resolve hundreds of URLs.

Rescan after changes

After fixes are deployed, select the affected rows and rescan them rather than starting the entire audit again. Confirm that:

• Former 4xx or 5xx URLs now return the intended result.

• Redirects reach the correct destination without unnecessary hops.

• Failed requests now complete successfully.

• Removed URLs no longer appear when the sitemap is rediscovered.

• Updated pages have the expected canonical and robots signals.

For CMS-generated sitemaps, run discovery again after the fix. A page can return correctly while an old URL remains inside the generated XML, so both the live response and the published sitemap inventory need verification.

Export a focused CSV report

Filter the results to the rows that still require action, show only the useful columns and export them to CSV. A practical report can be separated into groups such as:

• Broken sitemap URLs.

• Server and request failures.

• Redirecting sitemap URLs.

• Blocked or rate-limited checks requiring confirmation.

• Indexability or canonical issues.

Include notes and tags when they help the recipient understand the expected fix. Keep successful rows out of a repair report unless they are needed as evidence of overall coverage.

Important limitation

URL Verifier Pro verifies known URLs. It does not crawl links from page to page, render JavaScript or discover every URL that exists on a website. A sitemap audit therefore answers: “Do the URLs published in this sitemap work as expected?”

It does not answer: “Does every link on every page work?” For full coverage, combine the sitemap check with an internal-link crawl or another source of known URLs.

Final checklist

Before completing the audit, confirm that:

• The correct domain, sitemap or sitemap index was used.

• Discovery did not stop unexpectedly at a URL or depth limit.

• Discovered page URLs were added to the main list and scanned.

• 4xx, 5xx, failed and redirecting rows were reviewed separately.

• Redirect destinations and full status sequences were checked.

• Blocking and rate-limit results were verified before reporting.

• Repeated patterns were grouped by folder, template or child sitemap.

• Fixed rows were rescanned.

• Generated sitemaps were rediscovered after relevant changes.

• The exported CSV contains only the rows and columns needed for action.

A sitemap is a published URL inventory, not a guarantee that every listed page is healthy. The most reliable way to check a sitemap for broken links is to discover the complete sitemap structure, scan every extracted URL and review the final response rather than relying on the XML file alone.

Download URL Verifier Pro to discover sitemap URLs, check their live status and export a clean audit report from one Windows app.