A 404 URL in an XML sitemap is usually a stale entry. The sitemap tells search engines that the URL is part of the preferred set you want discovered, while the server says the resource does not exist.
Use the Sitemap URL Checker to sample live sitemap URLs and surface HTTP failures alongside redirects, noindex directives, and canonical conflicts.
Should a sitemap contain 404 URLs?
Normally, no.
Google's sitemap guidance says to include the canonical URLs you want to see in search results. A true 404 is not an indexable page, so there is no benefit in deliberately keeping it in the sitemap.
Google's Search Console documentation also lists an incorrect sitemap URL returning 404 as one possible reason a sitemap itself cannot be fetched. At the page-entry level, inaccessible URLs are reported as sitemap problems because Google cannot crawl the listed resource successfully.
The practical rule is:
If a URL is permanently gone, remove it from the sitemap. If it moved, fix the redirect and list the final preferred destination instead.
First decide whether the 404 is correct
Not every 404 should be redirected.
If a page was deleted and there is no meaningful replacement, returning 404 or 410 can be the correct server behavior. The sitemap is what needs fixing.
If a page moved to a clear replacement, a permanent redirect may be appropriate. In that case:
- redirect the old URL to the best matching replacement;
- update internal links;
- remove the old URL from the sitemap;
- add the final destination if it belongs in the sitemap.
Avoid redirecting every missing URL to the homepage. That creates a poor user experience and can hide broken information architecture instead of fixing it.
Why do 404 URLs remain in sitemaps?
Deleted CMS records are still included by a plugin
A sitemap plugin may query an outdated content status, cache, or taxonomy relationship and continue emitting URLs after the page is removed.
Static sitemap files are stale
A manually generated sitemap.xml can remain unchanged for months while the site evolves.
A migration changed URL patterns
After a platform migration, old category, product, article, or media URLs may still be generated from legacy data.
Deployment and sitemap generation are out of sync
A build process can publish a sitemap before the corresponding pages are deployed, or leave old sitemap artifacts after pages disappear.
The application returns soft 404s inconsistently
Some missing pages return HTTP 200 with a “not found” message, while others return a real 404. A simple status checker only catches the real HTTP failures. Search Console and a full crawler may reveal additional soft-404 cases.
How to find broken URLs in a sitemap
Start with the sitemap itself
Make sure the XML is valid and identify whether you are dealing with a single URL sitemap or a sitemap index with many child files.
For large sites, errors can be isolated to one child sitemap such as products, categories, posts, or images.
Live-check page URLs
A page-level audit requests listed URLs and records their final status.
Useful buckets include:
- 2xx successful responses;
- 3xx redirects;
- 404 or 410 missing pages;
- 5xx server errors;
- fetch timeouts or connection failures.
SitemapChecker.tools intentionally checks a bounded sample rather than crawling every URL on a very large site. If the sample finds several 404s, run a full crawl or export from your CMS to measure the complete problem.
404 vs 410 in a sitemap
Both mean the URL is unavailable for normal indexing purposes.
A 404 means the requested resource was not found. A 410 means it is gone. Whichever status you intentionally use, the URL generally should not remain in the active sitemap unless the response is temporary and the page is about to return.
The sitemap should describe the current preferred URL set, not serve as an archive of deleted pages.
What about temporary 5xx errors?
A 5xx response is different from a deliberate 404. It usually indicates a server problem rather than a permanently missing page.
Do not immediately remove valuable pages from the sitemap because of a brief outage. Instead:
- confirm whether the 5xx is repeatable;
- check application and hosting logs;
- review deployment health and origin capacity;
- fix the server problem;
- re-run the sitemap audit.
Persistent 5xx responses are still serious because search engines cannot reliably fetch the listed pages.
How to fix stale 404 entries properly
A durable fix happens at the source that generates the sitemap.
CMS-generated sitemaps
Check whether deleted, draft, private, expired, or unpublished records are incorrectly included. Review SEO plugin settings and clear stale caches when necessary.
Custom sitemap generators
Make the sitemap query the same source of truth used by your production routes. Filter out records that cannot produce a live canonical page.
Static-site builds
Generate sitemap entries from the actual route manifest after content generation, not from an older content inventory that can drift away from deployed pages.
Ecommerce sites
Pay special attention to discontinued products, empty categories, removed variants, and locale-specific URLs. Decide which should redirect, which should disappear, and which should remain live with an appropriate replacement message.
Recheck redirects and canonicals after fixing a 404
A common “fix” changes a 404 into a redirect without updating the sitemap. That improves the user outcome but still leaves a redirecting sitemap entry.
The cleaner final state is:
- sitemap lists the final preferred URL;
- final URL returns a successful response;
- no accidental noindex is present;
- canonical signals are consistent;
- old URL redirects only if a meaningful replacement exists.
Use Search Console for Google-specific follow-up
After cleaning the sitemap, Search Console can help you understand whether Google is crawling and indexing the corrected URLs. The Sitemaps report shows parsing and fetch issues, while URL Inspection can test an individual URL from Google's perspective.
A third-party checker cannot guarantee that Google will index a page. Its role is to remove obvious technical contradictions before you investigate Google-specific indexing decisions.
Final checklist
For every 404 found in a sitemap:
- confirm the HTTP status is real and repeatable;
- decide whether the page is permanently gone or moved;
- remove permanently gone URLs from the sitemap;
- redirect moved URLs to the best matching destination;
- list the final destination rather than the redirecting source;
- fix the sitemap generator so the stale URL does not return on the next rebuild;
- re-run the sitemap checker.
A good sitemap is not the biggest possible list. It is a clean, current list of preferred URLs that actually resolve the way your site intends.