Submitting a sitemap looks like a one-click action, and most of the time it is. The errors that do show up tend to repeat the same handful of causes, and knowing them ahead of time saves a frustrating loop of resubmitting the same file expecting a different result each time nothing actually changed about the underlying problem.
Why Submission Errors Are Usually the Same Few Causes
Search Console does not generate a huge variety of error types for sitemap submissions, which is actually good news once you know the short list. Nearly every error traces back to one of: the file being unreachable, the XML being malformed, the URL count exceeding the format limit, or the file pointing at something that is not actually a sitemap. Knowing this list before debugging saves time that would otherwise go into guessing.
Step 1: Verify the Sitemap Is Reachable and Returns a Clean 200
Before touching Search Console, load the sitemap URL directly in a browser or with a command-line request. It needs to return a 200 status with content-type: application/xml or text/xml, not a redirect, not a login wall, and not a 404 dressed up as a normal-looking page. A sitemap sitting behind a redirect chain, even a single hop, is a common source of "couldn't fetch" errors that otherwise look mysterious to anyone reading the error message without this context.
Step 2: Confirm It Validates Against the Sitemap Schema
A single malformed URL entry, an unescaped ampersand in a query string, or a missing closing tag can cause Google to reject the entire file rather than just skipping the bad line silently. Run the file through an XML validator before submitting anything to Search Console. This step alone catches the majority of "sitemap could not be read" errors that otherwise require guessing which of several thousand URLs is the actual culprit hiding in the file.
<url>
<loc>[your-domain]/page?id=1&category=2</loc>
</url>
That ampersand needs to be escaped as & inside a valid sitemap file. Plenty of hand-rolled or script-generated sitemaps break on exactly this, since it looks fine in a browser address bar but is invalid inside XML, and the validator will flag it even though nothing looks wrong to the naked eye.
Step 3: Check the URL Count Against the Format Limit
A single sitemap file is capped at 50,000 URLs and 50MB uncompressed. Sites that exceed either limit need a sitemap index file that references multiple child sitemaps instead of one giant file. Submitting a file that silently exceeds the limit does not always produce a clear error message, it sometimes just results in a subset of URLs getting processed with no obvious explanation for which ones got dropped from the count.
Step 4: Submit Through the Sitemaps Report, Not Just robots.txt
Listing the sitemap location inside robots.txt via a Sitemap: directive is good practice, but it is not the same as submitting it through the Sitemaps report in Search Console. The report gives you actual processing status, submission date, and a count of discovered versus indexed URLs, none of which you get from the robots.txt reference alone, since that reference is a passive hint rather than an active submission.
Step 5: Read the Specific Error, Not Just the Red Icon
Search Console differentiates between "Couldn't fetch," "Sitemap is HTML," "General HTTP error," and several other specific error types, each with a different fix. "Sitemap is HTML" almost always means the URL submitted points at a webpage rather than the actual XML file, a mistake that happens more than you would expect when a CMS's sitemap URL setting gets typed slightly wrong during initial configuration.
Photo by Brett Sayles on Pexels
Step 6: Wait for Actual Processing, Not Just Submission Confirmation
A sitemap showing "Success" immediately after submission only confirms Google could fetch and parse the file, not that every URL inside it has been crawled or indexed yet. Processing and subsequent crawling happen on Google's own schedule, and checking the coverage numbers a day after submission expecting a fully updated index count is a common source of false alarms about a sitemap "not working" when nothing is actually wrong.
Step 7: Resubmit Only After a Meaningful Change
Resubmitting the same unchanged sitemap repeatedly does not speed anything up and can make the report harder to read by resetting the submission timestamp without any new information for Google to act on. Resubmit when the URL list has meaningfully changed, not on a fixed schedule just to see a fresh status appear in the dashboard.
Step 8: Handle Multiple Sitemaps Through an Index File Correctly
Once a site outgrows a single sitemap file, the index file itself needs to validate too, and it is easy to forget this since attention naturally shifts to the child sitemaps. The index file follows its own schema with <sitemapindex> and <sitemap> tags rather than <urlset> and <url>, and submitting a malformed index file produces an error that looks similar to a malformed regular sitemap but requires checking a completely different file to actually fix.
Step 9: Check for Duplicate or Conflicting Sitemap Submissions
Sites migrating CMS platforms sometimes end up with two sitemap submissions active in Search Console at once, an old one the previous system still generates and a new one from the current setup, both listing overlapping URLs with potentially different metadata. Remove the stale submission entirely rather than leaving it alongside the current one, since the two can produce a confusing coverage report where the same URL shows up under both a healthy and an errored parent sitemap.
Step 9b: Watch for Discrepancies Between Discovered and Indexed Counts
Search Console reports both a "discovered" count and an "indexed" count for a submitted sitemap, and a large persistent gap between the two is worth investigating rather than assuming it will close on its own over time. A small gap right after submission is normal since indexing takes time, but a gap that stays wide for weeks usually points to one of the issues covered in a separate indexing audit rather than anything a resubmission can fix.
Step 10: Automate Regeneration So Errors Don't Recur
Manually maintained sitemaps drift out of sync with a site's actual URL structure the moment someone adds or removes pages without updating the file by hand. The XML Sitemap Generator validates URL syntax automatically and splits large lists into a proper sitemap index once the URL count approaches the format limit, which removes steps 2, 3, and 8 above as ongoing manual maintenance tasks every time your site's page count changes.
"A sitemap submission error almost never means the concept of a sitemap is broken, it means one specific line in the file or one specific setting on the server is wrong. Treat every error message as a pointer to that one thing, not a reason to rebuild the whole file from scratch." - Dennis Traina, founder of 137Foundry
Once a sitemap submits cleanly and the coverage report shows the count you expect, the harder problem usually starts: pages that are technically indexed as part of the sitemap process but still don't show up in search results for reasons that have nothing to do with the sitemap file itself. This guide on why sitemap pages sometimes still aren't indexed picks up exactly where a clean submission leaves off, covering noindex conflicts, canonical mismatches, and thin content as the next layer to check once submission errors are no longer the bottleneck.
For the full technical specification behind the file format itself, Sitemaps.org documents every supported tag, and Google Search Central covers how Google specifically interprets the parts of the spec that leave room for implementation differences between search engines, which matters more than it seems once you are also submitting the same sitemap to Bing Webmaster Tools and comparing how the two engines report on identical data.
Top comments (0)