Submitting an XML sitemap and fixing sitemap errors in Search Console
You have a sitemap file, your developer says it works, and yet Google Search Console shows a red status next to it. Or it shows green, but only a fraction of your pages appear as discovered. Both situations are common, and both can usually be sorted out in an afternoon. This guide explains how to submit a sitemap in Search Console, how to read what the Sitemaps report tells you, and how to fix the error messages site owners run into most often.
It assumes you already have a verified Search Console property and a sitemap URL. Deciding which pages belong inside the file is a separate subject; here the focus is getting Google to read it.
Before you submit: three quick checks
A few minutes of checking saves days of waiting for Google to report a problem you could have spotted yourself.
- Open the sitemap in a private browser window. Paste the full URL, for example https://www.example.com/sitemap.xml. You should see XML text or a formatted list of URLs, not a login page, a 404 or your home page.
- Confirm the exact address. Many platforms use a sitemap index such as /sitemap_index.xml or /wp-sitemap.xml rather than /sitemap.xml. Submit the index if one exists; Google follows the child sitemaps listed inside it.
- Match the property. A URL-prefix property for https://www.example.com cannot accept a sitemap on http://example.com. A Domain property covers every protocol and subdomain, which avoids this mismatch.
How to submit a sitemap in Search Console step by step
The submission itself takes less than a minute.
- Sign in to Google Search Console and select the correct property from the drop-down at the top left.
- In the left menu, open Indexing and choose Sitemaps.
- Under "Add a new sitemap", type the path after your domain, for example sitemap_index.xml.
- Click Submit. A confirmation appears and the sitemap is added to the "Submitted sitemaps" table.
It is also worth adding a line to your robots.txt file, such as Sitemap: https://www.example.com/sitemap_index.xml. That helps other search engines find it too, and it keeps the location documented for whoever manages the site next.
Resubmitting the same sitemap every day does nothing useful. Once Google knows the address, it rechecks the file on its own schedule.
Reading the Submitted sitemaps table
Each row in the table has a few columns worth understanding.
- Type shows whether Google read it as a sitemap, a sitemap index, RSS or Atom feed.
- Submitted and Last read give dates. If last read is weeks old on a busy site, that is worth a look but not always a problem.
- Status is Success, Has errors or Couldn't fetch.
- Discovered pages is the number of URLs Google found in the file, not the number it indexed.
Click a row to open details. From there, the "See page indexing" link filters the page indexing report to just the URLs in that sitemap. That filtered view is the most honest answer to the question of how many of your listed pages are actually in Google.
Fixing "Couldn't fetch"
This is the error that worries people most, and it has several possible causes.
It may simply be pending
Newly submitted sitemaps sometimes show Couldn't fetch for a day or two before switching to Success. If the file opens fine in a browser, wait 48 hours before changing anything.
The server is refusing Googlebot
Security plugins, firewalls and bot-protection rules at the hosting or CDN level can block Google's crawler while allowing normal visitors. Use the URL Inspection tool on the sitemap URL and run a live test. If the live test fails, ask your host to check firewall logs for blocked Googlebot requests. Verify genuine Googlebot by its published IP ranges rather than trusting the user-agent alone.
Wrong status code or redirect
The sitemap must return a 200 status code. A redirect from http to https is usually followed, but chains of redirects, or a sitemap that redirects to the home page, cause failures. Submit the final address directly.
Fixing other common sitemap errors
Sitemap is HTML or invalid format
Google received a web page instead of XML. This often happens when a caching plugin or theme serves a pretty HTML version, or when a maintenance page intercepts the request. Check the response headers: the content type should be something like application/xml or text/xml. Also look for stray spaces or text before the opening XML declaration, which break parsing.
Invalid date or unsupported format
The lastmod value must use the W3C Datetime format, for example 2026-09-17 or 2026-09-17T10:30:00+05:30. Dates written as 17/09/2026 will be rejected.
URL not allowed
The sitemap contains addresses from another domain, a different protocol or a subdomain outside the property. Fix the generator so every URL uses the same host and protocol as the live site.
Sitemap too large
A single sitemap may hold up to 50,000 URLs and 50 MB uncompressed. Beyond that, split it into several files and submit an index that lists them.
"Blocked by robots.txt" and other URL-level warnings
Sometimes the sitemap itself reads fine but the URLs inside it cannot be crawled. The page indexing report may show a group called "Blocked by robots.txt" among your sitemap URLs.
That is a contradiction: the sitemap says "please index this", robots.txt says "do not fetch it". Decide which instruction is correct. If the pages should rank, remove or narrow the Disallow rule. If they should not, remove them from the sitemap. A frequent cause is a leftover Disallow: / from a staging site copied to production, so check that first.
Similar contradictions include sitemap URLs that redirect, return 404, carry a noindex tag or point their canonical elsewhere. Each should be fixed at the source, usually in the plugin or code that generates the sitemap.
After fixing: what to do and how long to wait
Once the underlying problem is solved, open the Sitemaps report, click the affected sitemap and resubmit it. For URL-level problems, open the page indexing report, click the issue and press Validate fix. Validation can take several days to a couple of weeks, depending on how many URLs are involved.
Keep a short log of what you changed and when. If the numbers move, you will know why. If a hosting move, theme change or plugin update breaks things again, you will know where to look. If sitemap errors keep returning after every update, a proper look at your hosting setup may help; our support team can check the server side, and reliable Linux hosting removes many firewall-related fetch problems.
Frequently asked questions
How long does Google take to read a new sitemap?
Often within a few hours to a couple of days, though there is no fixed timeline. Reading the file is also separate from crawling and indexing the pages listed in it, which can take longer.
Should I delete an old sitemap from Search Console?
If the file no longer exists, removing it from the report keeps things tidy and stops old errors appearing. Removing it from the report does not stop Google remembering URLs it already knows.
Why does discovered pages show a higher number than my site has?
Usually the sitemap includes tag archives, attachment pages, filtered URLs or old content you forgot about. Download the sitemap and compare it with the pages you actually want indexed.
Do I need to resubmit the sitemap every time I publish a post?
No. Google rechecks submitted sitemaps periodically. Just make sure the file updates automatically when you publish and that the lastmod values are accurate.
We can do this for you
See what a package covers and what it costs, or ask us about your own project.

