4XX Error URL in XML Sitemaps: How to Fix It

What a 4XX in a sitemap actually means

An XML sitemap is a curated list of the pages you want search engines to find and index. Every URL in it is, in effect, a recommendation. When one of those URLs returns a 4XX client-error response, you are recommending a page that no longer serves content. Google's guidance is direct: a sitemap should list the canonical URLs you prefer to show in search results, and a common mistake is including URLs of pages that do not exist. Screaming Frog echoes this in its defaults, where only HTML pages returning 200 are written to a generated sitemap, so 3XX, 4XX, and 5XX responses are excluded by design.

A 4XX URL in your sitemap is therefore a contradiction. You tell the crawler "this page matters, index it" while the server answers "this page is not available." That mixed signal is the entire problem.

404 vs 410 vs 403/401

Not all 4XX codes carry the same meaning, and the distinction changes how search engines react.

404 Not Found

A 404 means "not present right now." It does not inherently mean the page was deleted on purpose. Because of that ambiguity, Googlebot tends to keep the URL in its scheduler and returns to recrawl it several times over days or weeks to confirm the status before dropping it.

410 Gone

A 410 is more explicit: the content is gone intentionally and permanently. Search engines generally honour this faster, marking the URL as retired and removing it from the index sooner than they would a 404. If a page is genuinely never coming back, 410 is the cleaner signal.

403 Forbidden and 401 Unauthorized

A 403 tells the crawler it is not allowed to access the page, and a 401 demands authentication the crawler cannot provide. Neither page can be indexed, and Sitebulb warns that when search engines find this kind of "dirt" in a sitemap they may stop trusting the file for crawling and indexing signals. None of these codes belong in a sitemap.

Why it matters

There are two costs. The first is trust: when a sitemap is littered with errors, search engines may discount the file as a reliable source of crawl and indexing signals, which dilutes the value of every good URL listed alongside the broken ones. The second is wasted crawl activity. Every dead URL you submit invites the crawler to spend a request confirming the page is gone, and a 404 in particular can linger in the scheduler for weeks of repeated checks. On a large site that is a measurable drain on crawl budget that could have gone to real pages.

Common causes

The usual culprit is a stale sitemap. A page is deleted, unpublished, or its slug is changed, but the sitemap is cached or generated on a schedule, so it keeps listing the old URL until the next rebuild. CMS and plugin bugs are the next most frequent source: a generator that pulls from the wrong query, includes draft or trashed content, or fails to drop items when their status changes. Other causes include listings removed from a database without a sitemap update, hand-edited sitemaps that were never maintained, and incorrect URL construction (a trailing-slash or protocol mismatch that resolves to a 4XX).

How to diagnose

Crawl the sitemap directly rather than the live site. In Screaming Frog, point the crawler at the sitemap in list mode, then open the Response Codes tab and apply the Client Error (4xx) filter to strip out the 200 and 3XX clutter, leaving only the failing URLs. The dedicated sitemap reports flag a "Non-200 URLs In Sitemap" condition for exactly this. To build a fix list with sources, use Bulk Export.

Screaming Frog
  Mode > List > Download Sitemap
  enter: https://example.com/sitemap.xml
  Response Codes tab > Filter: Client Error (4xx)
  Bulk Export > Response Codes > Client Error (4xx) Inlinks

Quick curl check on a single URL:
  curl -o /dev/null -s -w "%{http_code}\n" https://example.com/old-page/

Google Search Console's Sitemaps report and URL Inspection tool will also surface URLs that were submitted but could not be fetched, which is a useful second confirmation.

How to fix it

Triage each broken URL into one of three buckets, then act.

Has a valid replacement? If the content moved, 301-redirect the old URL to its new home, then make sure the new URL (not the old one) is what appears in the sitemap.

Still valuable but accidentally broken? Restore the page so it returns a 200. Pages that earn traffic or links should be rendering 200, not erroring, so fix the underlying cause rather than just hiding the symptom.

Genuinely gone for good? Let it return 404 or, better, 410, and remove it from the sitemap entirely. The key step in every case is regenerating or cleaning the sitemap so the dead URL is no longer listed. For most CMS-driven sites that means forcing a fresh sitemap build (clear the cache or trigger a rebuild); for a hand-maintained file it means deleting the offending lines. Re-crawl to confirm zero 4XX URLs remain, then resubmit the clean sitemap in Search Console.

Best practice

Treat the sitemap as a strict allow-list: only canonical, indexable, self-referencing URLs that return 200. No redirects, no noindex pages, no error responses. Automate sitemap generation so it always reflects current content state, crawl the sitemap periodically, and watch the Search Console Sitemaps report for fetch failures. A clean sitemap keeps search engines trusting your signals and spending crawl on the pages that actually matter.

FAQ