# Sitemap Errors in Search Console: Every Common Error and How to Fix It > Decode every common Search Console sitemap error, from Couldn't fetch to Invalid date and URL not allowed, with causes, fixes and a checklist to resubmit safely. URL: https://seoconsultantlondon.online/guides/sitemap-errors-search-console/ Updated: 2026-10-24 ## Quick answer Search Console reports three sitemap statuses: Success, Has errors and Couldn't fetch. Fetch failures usually mean a robots.txt block, a wrong URL or a server problem. Parsing errors come from invalid XML, bad dates, off-domain URLs or size limits. Fix the cause, then resubmit the sitemap. ## Key takeaways - The Sitemaps report shows three statuses: Success, Has errors and Couldn't fetch, and each points to a different layer of the problem. - "Couldn't fetch" means nothing in the file was read, so it is more urgent than "Has errors", where valid URLs are still queued. - Most parsing errors come from a short list: unescaped characters, off-domain URLs, wrong www prefixes, size limits and invalid dates. - Google retries failed fetches for a few days and then stops, so fix and resubmit promptly. - A clean sitemap lists only canonical, indexable URLs. Many "errors" are really symptoms of a messy site. ## What is the Sitemaps report telling you? Open Search Console, click Sitemaps, and you'll see a short table: the sitemap URL, its type, when you submitted it, when Google last read it, a status and the number of pages and videos discovered. It's one of the quietest reports in the tool, and it's easy to glance at and move on. That's a mistake, because the report is Google's direct feedback on a file you wrote for Google. A sitemap with errors isn't a disaster, but it's a sign. Either the file is malformed, or it's telling Google about pages that shouldn't be there, or something on the server is getting in the way. Reading the message properly usually takes five minutes and can reveal a wider site problem. > Why it matters: a sitemap Google can't read is a missed chance to speed up discovery, and a sitemap full of errors teaches Google to trust the file less. ### What are the three statuses? Google's help page for the [Sitemaps report](https://support.google.com/webmasters/answer/7451001) defines three. "Success" means the sitemap was fetched and read with no errors, and all its URLs are queued for crawling. "Has errors" means the sitemap was fetched but some entries failed; valid URLs are still queued, and you can open the sitemap to see the specific errors. "Couldn't fetch" means Google couldn't retrieve the file at all, so nothing in it is read. Success is the aim, but success doesn't mean every URL will be indexed. It means Google could read the list. What it does with the list is a separate matter, as the guide to [XML sitemap best practices](/guides/xml-sitemap-best-practices/) explains. #### What the other columns tell you "Last read" appears only when the fetch succeeded. "Discovered pages" counts page URLs parsed from the file, with duplicates counted once. For a sitemap index, the count covers URLs across all child sitemaps. ### Why do errors deserve quick attention? Google's help page notes that it retries failed fetches for a few days and then stops. If a sitemap goes unreadable and you don't notice, Google can give up on it, and recovery means resubmitting. On a site that publishes regularly, that delay slows discovery of new pages. On a new site, where the sitemap may be one of the few ways Google finds your content, it matters even more. So treat a red status as a same-week job, not a someday job. ## How do you diagnose a sitemap problem quickly? Before looking up specific errors, follow a short routine. It narrows the cause in minutes and prevents you from fixing the wrong thing. Start outside Search Console, then use its tools. ### What should you check first? Open the sitemap URL in a browser. Does it load? Does it show XML, not an error page or a login prompt? Is it the file you expect, with the right domain? Then check robots.txt for rules that block the sitemap path. Then check the server response: a 200 status, the right content type and no redirects that Google won't follow. Google's help page notes that redirects aren't followed for the submitted sitemap URL, so submit the final address. These checks alone resolve a large share of cases, because most errors come from something simple: a typo, a moved file or a blocked path. #### Use the exact submitted address If you submitted https://www.example.com/sitemap.xml and the file now lives at a different address, Search Console reports a 404, not a helpful pointer. ### How do you use Search Console's own tools? Open the sitemap's details page and click the error name for an explanation and sample entries. Then run a live test in the URL Inspection tool on the sitemap URL and confirm that "Crawl allowed?" is Yes and "Page fetch" is Successful, which is exactly the debugging route Google's documentation suggests. If the live test succeeds but Search Console still reports a failure, wait and resubmit. Transient errors happen, and Google retries. #### Record what you see Note the exact message, the date and the sample entries. If you contact a developer or hosting provider, that detail speeds up their work. ## Why does a sitemap say "Couldn't fetch"? "Couldn't fetch" is the status that means nothing in the file was read. It's the most urgent of the three, and it has a short list of causes. Google's documentation names them directly. ### What are the common fetch errors? | Cause | What it means | What to do | |---|---|---| | Blocked by robots.txt | A rule prevents Googlebot from fetching the sitemap path | Remove or narrow the rule | | Manual action on the site | A penalty may stop sitemap processing | Check the Manual actions report, fix, then resubmit | | 404, sitemap not found | The URL submitted doesn't exist | Confirm the address in a browser and resubmit the right one | | Server unavailable or transient error | Temporary problem on your server | Wait and check whether later attempts succeed | | Low crawl demand | Google isn't prioritising the site | Improve content quality; not a technical fix | Of these, robots.txt blocks and wrong URLs are the most common and the easiest to fix. Our explanation of [pages blocked by robots.txt](/guides/blocked-by-robots-txt-search-console/) shows how to spot a rule that's catching more than you intended. #### The low-demand case The last row surprises people. If Google doesn't see enough reason to spend crawl effort on your site, it may not fetch the sitemap promptly. No amount of XML tweaking fixes that. It's a signal to improve the site itself. ### How do you handle server errors and timeouts? If the sitemap is large or generated on the fly, slow generation can cause timeouts. Cache the file, serve it as a static document where possible and check server logs for requests from Googlebot that returned 5xx errors. Hosting limits and security tools can also throttle crawlers, so make sure legitimate Google traffic isn't being challenged. If the problem is occasional, a transient error that clears, you don't need to act. If it persists after several hours, resubmit, and if it keeps happening, investigate hosting capacity. #### Static beats dynamic for reliability A pre-generated file on fast storage is less likely to time out than one built by a database query on every request. ## What do the "Has errors" messages mean? When Google fetches the file but some entries fail, you get "Has errors." The list of possible messages is longer, because there are many ways to break a sitemap. They fall into groups. Work through them by group. ### Which errors come from invalid or unescaped URLs? "Invalid URL" and "Parsing error" usually mean the URL contains characters that must be escaped in XML, such as an ampersand, quotation marks or spaces. Google's help page recommends escaping them and testing the URL in a browser. Generators sometimes produce unescaped ampersands in parameter URLs, which breaks the XML entirely. "Incomplete URL in sitemap index" means a child sitemap entry used a relative path. Sitemap index entries need full URLs, including the protocol and host. #### A quick way to find the culprit Open the file in a browser or an XML validator. A single bad character often shows up as a line number in the error. ### Which errors come from domain and path mismatches? "URL not allowed" means the listed URLs are on a different domain from the sitemap, such as using http when the sitemap uses https, or lie above or beside the sitemap's directory. Google's guidance is to keep every URL on the sitemap's domain and below its folder. A related message, "Path mismatch," appears when the www prefix in the listed URLs doesn't match the sitemap's own location. These errors often appear after a migration or a protocol change, when the sitemap generator still uses the old base URL. The fix is to correct the base URL in the generator and regenerate. #### The migration link If your sitemap errors began after a launch, compare the base URL in the generator settings with your live domain. It's a classic leftover. The sequence to avoid it is in the [website migration SEO checklist](/guides/website-migration-seo-checklist/). ### Which errors come from size and structure limits? "Too many URLs" means more than 50,000 URLs in one file. "File size error" means a file larger than 50 MB uncompressed. "Too many sitemaps" means a sitemap index lists more than 50,000 sitemaps. "Nested sitemap indexes" means an index lists another index, which isn't allowed. The fixes are to split large files and use a sitemap index, and to flatten any nesting. Splitting by section also makes monitoring easier, because Search Console shows discovered and indexed counts per file. #### Compression matters too A "Compression error" means the gzip file is damaged. Recompress it, upload it and resubmit. ### Which errors come from dates and XML? "Invalid date" means the lastmod value isn't in W3C format. Google's examples are 2005-02-21 or 2005-02-21T18:00:15+00:00, and if you include a time, you must include a time zone. "Incorrect namespace" or "Unsupported format" means the root element or namespace is wrong, for instance a missing sitemaps.org declaration or curly quotation marks instead of straight ones. "Invalid XML: too many tags" or "Missing XML tag or attribute" means duplicated or absent tags. "Empty sitemap" speaks for itself: add URLs. Each of these points to the generator or to hand-edited XML, and most disappear when you fix the template that builds the file. #### Watch for copy-and-paste damage Pasting XML from a word processor can swap straight quotes for curly ones and break the file silently. ## What if URLs in the sitemap are blocked by robots.txt? This message deserves its own section, because it's both common and revealing. It says that the sitemap lists URLs that robots.txt tells Googlebot not to fetch. You've invited Google to a page and then locked the door. The contradiction is usually accidental. ### Why does it happen? A broad robots.txt rule, often left over from development, blocks a folder that the sitemap includes. Or a plugin adds a section to the sitemap that a different plugin blocks. Or a migration changed paths in one place but not the other. Whatever the origin, Google receives mixed instructions, and the blocked URLs can't be crawled. Google's help page suggests using the URL Inspection tool to find the blocked file and then updating robots.txt to allow Googlebot. Decide which side is right: if the pages should be indexed, change the rule; if they shouldn't, remove them from the sitemap. #### A consistency rule Every URL in your sitemap should be crawlable. If you don't want Google fetching it, it shouldn't be listed. ### How do you resolve it without breaking something else? Make the smallest change that removes the conflict. Back up robots.txt, edit the rule, test several URLs against it and check the live file. If the sitemap is listing pages that you intended to block, fix the generator's settings so those page types are excluded. Then resubmit and confirm that the message clears. For the wider question of what to block and what to allow, the explanation under [blocked by robots.txt](/guides/blocked-by-robots-txt-search-console/) covers the trade-offs. ## Which errors look like sitemap problems but are really site problems? Not every sitemap message is about the file. Some come from what the file reveals about the site. Recognising the difference saves you from fiddling with XML when the fix lives elsewhere. The tell is that the file is valid, but Google doesn't like what's in it. ### Which statuses point to page-level issues? "Submitted URL marked noindex" means a page you asked Google to consider carries a noindex directive. "Submitted URL not found (404)" means the page no longer exists. "Submitted URL seems to be a soft 404" means the page returns success but looks empty. "Submitted URL has crawl issue" and "Redirect error" point to status-code and redirect problems. "Submitted URL not selected as canonical" means Google picked a different canonical. In each case the sitemap is doing its job by exposing a conflict. The fix is at page level: remove noindex, restore or redirect the page, add real content, correct the redirect or align the canonical. Guides on the [noindex tag](/guides/noindex-tag-when-to-use-it/), [soft 404 errors](/guides/soft-404-errors-seo/) and [duplicate pages without a declared canonical](/guides/duplicate-without-user-selected-canonical/) explain each. #### A sitemap is a mirror If the file shows problems, check what it's reflecting. The generator might be including pages it shouldn't. ### How do you clean a sitemap of problem URLs? Export the URLs flagged in the page indexing report with the sitemap filter, group by reason and decide for each group. Remove redirected, 404 and noindexed URLs from the sitemap by adjusting the generator's rules, not by editing the file by hand. Keep only canonical, indexable pages returning 200. After regenerating, crawl the sitemap's URLs with a tool and confirm every one resolves directly to a 200 status. It's the most reliable test that the file is clean. #### Aim for a boringly accurate file A small, accurate sitemap beats a large, messy one. Google trusts clean files and pays them more attention. ## How do you resubmit a sitemap correctly? Fixing the file is only part of the job. You need to tell Google, then check that it listened. The process is short, but the details matter. ### What are the steps? Confirm the file loads correctly in a browser and passes validation. Make sure the submitted URL is final, with no redirect. Open the Sitemaps report, enter the sitemap URL and submit. Google's guidance says to resubmit using a new request, then check the status. Wait a few days, since Google retries failed fetches for a limited time, then return to confirm the status and the discovered count. If you changed the sitemap's location, remove the old entry in the report so you aren't tracking a dead file. Also update the Sitemap line in robots.txt. #### Don't resubmit repeatedly Submitting the same file over and over doesn't speed anything up. Fix the cause, submit once and give Google time. ### What should you check afterwards? That the status reads Success, that the discovered count matches what you expect and that the page indexing report, filtered by sitemap, shows submitted pages moving into the index. Large gaps between submitted and indexed pages are worth investigating separately, because they reflect page-level issues such as quality, duplication or crawl scheduling, discussed in [crawled, currently not indexed](/guides/crawled-currently-not-indexed/). If the discovered count is lower than expected, the generator may be excluding pages. If it's higher, it may be including pages it shouldn't. Either way, the file and your intention should agree. ## How do you prevent sitemap errors from returning? Most errors come from changes: a migration, a plugin update, a new template or a hosting move. Building checks around those moments prevents most recurrences. A small routine does the job. ### What goes into a prevention checklist? After every significant release, open the sitemap in a browser, validate it, check the base URL and review the Sitemaps report. Keep a copy of the generator's settings. Make sure robots.txt references the sitemap and doesn't block it. Use a monitoring tool or scheduled job to fetch the file daily and alert you if the status code or content changes dramatically. For sites with many sections, keep separate sitemaps and watch each one. A sudden drop in one file's discovered count shows you where something changed. | Moment | Check | |---|---| | After a release | Open and validate the sitemap, check the base URL | | After a migration | Regenerate, compare with the redirect map, resubmit | | After a plugin update | Confirm settings haven't reset, scan for new URL types | | Monthly | Review the Sitemaps and page indexing reports | | Quarterly | Crawl the sitemap URLs and compare with the live site | #### Own the process Name a person responsible for the sitemap. Unowned files drift, and drift is where errors begin. ### When should you ask for help? If a persistent "Couldn't fetch" status survives every check, if errors return after each fix, or if a large site's sitemap logic is complex, an expert review pays for itself. A specialist can read server logs, trace the generator and verify the fix across environments. A [technical SEO consultant](/technical-seo-consultant/) covers this routinely, and a broader [SEO audit](/seo-audit/) shows whether the sitemap's symptoms point to deeper structural issues. For most business sites, though, a clean generator, a correct base URL and a quick check after each release keep the report green and the file trustworthy. ## What does a worked example look like? Walking through a case makes the logic concrete. This one is hypothetical, assembled from common patterns, with illustrative details. It shows how a single configuration mistake produces several different messages. ### What did the site owner see? A small shop relaunched on a new platform and found its sitemap status in Search Console showing "Has errors." The details listed "URL not allowed" on most entries, "Invalid date" on a few and, for the sitemap index, "Incomplete URL." Impressions had started to flatten, and new products were slow to appear in search. A look at the file showed the cause. The generator's base URL still pointed at the old staging domain, so every entry was off-domain. The index used relative paths for child sitemaps, and a custom field was outputting dates in a local format. #### The pattern Three symptoms, one root: a generator configured for the wrong environment. That's typical after a launch. ### How was it fixed? The developer corrected the base URL to the live HTTPS host, switched the index to absolute URLs and changed the date output to the W3C format. They regenerated the files, validated them in a browser, confirmed that robots.txt didn't block the path and resubmitted in Search Console. A few days later the status read Success, the discovered count matched the product catalogue and new items began to appear in the index faster. They added a sitemap check to the launch checklist and set a monthly review of the Sitemaps and page indexing reports. The lesson is that a red status is rarely mysterious. It's a message with a short list of possible causes, and the quickest route to the answer is to read it carefully and check the file against the live site. #### The one-line summary Fetch problems are about reachability, parsing problems are about the file, and "submitted URL" problems are about the pages. Identify which, and the fix follows. ## How do sitemap errors differ for small sites, shops and large publishers? The same error can mean different things depending on the site. A malformed date on a ten-page brochure site is a tidy-up. The same fault on a store with fifty thousand products can slow the discovery of new stock for weeks. Matching your response to your site's scale keeps the effort proportionate. ### What should small business sites focus on? Accuracy and simplicity. A small site usually has one sitemap, generated by the CMS or an SEO plugin, listing a few dozen to a few hundred URLs. The errors you're likely to meet are configuration ones: a wrong base URL after a launch, a plugin adding archive pages you don't want, or a robots.txt rule that blocks the file. Google's own advice for smaller, well-linked sites is that a sitemap helps but isn't essential, so don't over-invest. Fix the status, keep the list clean and move on. A short routine check after every release is enough. #### When a small site should worry When the status is "Couldn't fetch" and stays that way, or when the file lists pages you never intended to publish. Both are quick to resolve and worth doing the same day. ### What should ecommerce sites focus on? Segmentation and automation. Shops change constantly: products come and go, categories shift, stock levels move. Generate sitemaps automatically from live catalogue data, split them by type and watch each file's discovered count. A sudden jump in the number of URLs often means a filter or parameter pattern has started generating pages. Because large catalogues can exceed the 50,000-URL and 50 MB limits, plan for a sitemap index from the start. Watch for out-of-stock and discontinued items lingering in the file, since they produce soft 404 and redirect errors that clutter the report. The guide to [ecommerce category page SEO](/guides/ecommerce-category-page-seo/) explains which pages deserve a place in the first place. #### Monitor the ratio For each file, compare submitted with indexed counts. A product sitemap at a fraction of the category sitemap's rate points straight at where to look. ### What should large publishers focus on? Freshness and reliability. Sites that publish many articles daily depend on Google noticing new URLs quickly. Accurate lastmod values, fast and cache-friendly sitemap delivery and clean separation between recent and archive content all help. A sitemap that times out under load, or that lists stale content, undermines the very purpose. For these sites, server-side monitoring of sitemap fetches is worth having. A failure at 3am that goes unnoticed until the weekend can mean a day of slower discovery for time-sensitive content. ## How do you read the discovered counts and the indexed gap? Once the file is healthy, the interesting question changes from "can Google read it?" to "what does Google do with it?" The Sitemaps report and the page indexing report answer that together. The gap between the two is where the real SEO insight lives. ### How do you compare submitted and indexed pages? Open the page indexing report and set the filter to the specific sitemap. The report shows how many of its URLs are indexed and lists reasons for those that aren't. This is the single most informative view in Search Console for pages you've explicitly asked Google to consider, because it cuts out the noise of accidental URLs. A healthy sitemap on a healthy site shows most URLs indexed and a short list of understandable exclusions. A large gap deserves a closer look. Group the excluded URLs by reason, and decide which matter. | Gap pattern | Likely cause | Where to look | |---|---|---| | Many "Discovered, currently not indexed" | Crawl scheduling or URL clutter | Server health, internal links, junk URLs | | Many "Crawled, currently not indexed" | Page value or duplication | Content quality and signals | | Many "Duplicate" statuses | Missing or conflicting canonicals | Canonical tags and redirects | | Many "Excluded by noindex" | Directive conflicts | Templates, plugins, headers | | Many "Soft 404" | Empty or error-like pages | Templates and status codes | #### The statuses behind the gap The first two rows are explained in the guides to [discovered, currently not indexed](/guides/discovered-currently-not-indexed/) and [crawled, currently not indexed](/guides/crawled-currently-not-indexed/). ### Is a gap always a problem? No. If you listed pages that deliberately shouldn't be indexed, the gap is a symptom of a messy sitemap rather than a messy site. The cure is to remove those pages from the file. If the gap consists of pages you do want ranking, treat it as a priority and diagnose by reason. It also helps to remember that indexing takes time. A new sitemap, or a big batch of new pages, will show a gap that narrows over weeks as Google works through the list. Watch the trend, not a single snapshot. ## What tools and checks help you validate a sitemap? You don't have to rely on Search Console alone. A few free tools let you catch most errors before Google does. Prevention beats correction. ### How do you validate the file itself? Open it in a browser to confirm it renders as XML. Use an XML validator or a sitemap validation tool to check structure, namespace and date formats. Check the file size and the URL count. Make sure it's served with a sensible content type and that compression, if used, is valid. Run it through a crawler by feeding it the sitemap URL, and see whether every listed page returns a 200 status with no redirect. A good crawler will flag redirects, errors, noindexed pages and canonicals pointing elsewhere in one pass, which is the quickest way to find the pages that make the report messy. #### Test on staging first If you change the generator or move hosting, generate the sitemap on a staging site and test it there before going live. Make sure staging itself is protected from search engines. ### How do you monitor it over time? Schedule a daily fetch of the sitemap URL and alert on a non-200 status, a sudden change in size or an unexpected drop in URL count. Add the Sitemaps report to your monthly review. Note the dates of releases and plugin updates next to the numbers, so that changes have an explanation. Over a few months, these habits build a reliable picture of how your site behaves and make the odd error easy to spot. If you'd rather have an expert watch it, an ongoing [technical SEO consultant](/technical-seo-consultant/) arrangement can include monitoring and quick-turn fixes. ## Frequently asked questions ### What does "Couldn't fetch" mean in Search Console? It means Google could not retrieve the sitemap file, so none of its URLs were read. Common causes include a robots.txt block, a wrong or missing file at the submitted address, a manual action on the site, a temporary server problem or low crawl demand. Check the URL in a browser first. ### What's the difference between "Has errors" and "Couldn't fetch"? "Has errors" means Google fetched the file but some entries failed, and the valid URLs are still queued for crawling. "Couldn't fetch" means the file itself couldn't be retrieved, so nothing in it is read. The second is more urgent because the whole sitemap is effectively ignored. ### Why does my sitemap say "URL not allowed"? Because the listed URLs are on a different domain, use a different protocol or host version, or sit above or beside the sitemap's folder. For example, a sitemap on the www host listing non-www URLs triggers it. Keep every URL on the same host as the sitemap and below its directory. ### How many URLs can one sitemap contain? Google's sitemaps report treats more than 50,000 URLs, or a file larger than 50 MB uncompressed, as an error. Split bigger sites into several files and list them in a sitemap index, which itself can reference up to 50,000 sitemaps. Splitting by section also helps monitoring. ### Should I resubmit my sitemap after fixing errors? Yes. Google's guidance says to resubmit through a new request in the Sitemaps report and then check the status. Google retries failed fetches for a few days and then stops, so fix problems promptly. Remember that fixing the file doesn't guarantee that every listed URL will be indexed.