Part of the SiteMap Series
Your sitemap is built, hosted at the right location, declared in robots.txt, served over HTTPS, and verified accessible. Crawlers can find it. The work from the last six lessons has put a clean, discoverable sitemap on your site.
The next step is telling Google directly. Robots.txt is a passive declaration that crawlers happen to read when they visit. Google Search Console is an active channel where you submit the sitemap, watch Google process it, and get told immediately if something is wrong. Both matter. They serve different jobs.
This lesson covers why submission matters even when robots.txt already does the work, how to verify your Search Console property if it is not verified already, the actual submission process, how to read the Sitemaps report afterwards, when resubmission is worth doing, and the common submission errors that show up most often.
Why submission matters even when robots.txt declares your sitemap
Crawlers will eventually find your sitemap through robots.txt. Google honours the Sitemap directive in the protocol, and the sitemap will be processed when Google’s next routine robots.txt fetch picks it up. So why bother with Search Console at all?
Three reasons.
- Speed: direct submission gets the sitemap in front of Google’s crawler the moment you submit, rather than waiting for the next robots.txt fetch, which can be hours or days away.
- Error reporting: robots.txt is silent, so if something is wrong, you do not know. Search Console tells you immediately if the sitemap could not be fetched, if URLs failed validation, or if there are protocol errors.
- Monitoring over time: Search Console keeps a record of every fetch attempt, every URL discovered, and every error. You can see when the sitemap was last read, how many URLs Google has registered from it, and whether those numbers match what you expect.
Do both. Declare in robots.txt for crawlers that find your site without prior knowledge, and submit through Search Console for the visibility and feedback the dashboard provides.
How to Verify ownership of your Search Console property
If not, you have two property types to choose between, and each one has its own verification methods.
1. Domain property
A Domain property covers all protocols (http, https) and all subdomains (www, blog, shop, and so on) automatically. One property, one verification, everything under your domain in scope.
Verification is by DNS only. Search Console gives you a TXT record to add to your domain’s DNS settings. Add the record, wait for propagation (usually a few minutes, sometimes longer), and click Verify.
2. URL prefix property
A URL prefix property only covers the exact URL prefix you specify, which means https://example.com/ is treated as a different property from https://www.example.com/.
It supports four verification methods.
- HTML file upload: Download a file from Search Console and upload it to your domain root.
- HTML meta tag: Add a single line to your homepage’s HTML head.
- Google Analytics: Works automatically if you already have GA installed on the site.
- Google Tag Manager: Works automatically if you already have GTM installed on the site.
Domain properties are usually the right choice for new setups. They cover everything in one go and avoid the need to manage multiple properties for different subdomains. URL prefix properties are useful when you do not have DNS access or when you genuinely need to verify just a section of a site.
Once verified, you have full access to the property’s Search Console features.
Submitting your sitemap to Search Console
Once your property is verified, the submission itself takes about thirty seconds.
Open Search Console, select your property from the property selector at the top left, and click Sitemaps in the left sidebar under the Indexing section. You will see a page with an Add a new sitemap field at the top.
The URL field expects only the path after your domain. If your sitemap is at https://example.com/sitemap.xml, type sitemap.xml. The domain prefix is shown next to the field automatically. This catches many people the first time they submit, particularly those who paste the full URL and end up with a malformed submission.
For sitemap index files, submit the index URL itself (sitemap_index.xml for Yoast and Rank Math sites). Google will follow the references inside the index to the child sitemaps automatically. You do not need to submit each child sitemap separately.
You can submit multiple top-level sitemaps if you have them. A site might submit a regular XML sitemap and a separate news sitemap, or a sitemap and a video sitemap. Each is submitted individually through the same field.
After submission, the sitemap appears in the list below the form with a status indicator. You will usually see “Pending” briefly while Google fetches the file, then “Success” once it has processed it. If something is wrong, the status will show an error type instead, and the next section covers how to read those.
Understanding the Sitemaps report
The Sitemaps report becomes your monitoring dashboard for sitemap health over time. After submission, you can come back to this page at any point to see how Google is processing the sitemap.
The report shows each submitted sitemap as a row with several columns.
Type distinguishes between a sitemap and a sitemap index.
Submitted is when you first submitted it.
Last read is when Google last fetched the file.
Status is the most recent processing result (Success, Has errors, Could not fetch, and similar).
Discovered URLs is the count of URLs Google has registered from the sitemap.
The discovered URL count is the field worth paying closest attention to. If your sitemap contains 500 URLs but Google shows 480 discovered, something is keeping 20 URLs out. Maybe they have noindex set, maybe robots.txt is blocking them, maybe they return errors when crawled. Click into the sitemap row to see the breakdown of which URLs were processed and which were excluded.
The last read date tells you how often Google is checking the sitemap. For active sites with regular content changes, you should see fetches every few days or weeks. For static sites with infrequent changes, the gap between reads will be longer. Google adjusts its fetch frequency based on how often the file actually changes, which is part of why the lastmod accuracy from earlier lessons matters.
If the status changes from Success to an error state, investigate immediately. A sitemap that was working and is now broken signals either a recent site change that introduced the problem or an external issue affecting accessibility.
When to resubmit your sitemap
Most of the time, you do not need to resubmit. Google checks the sitemap periodically on its own, and once it is in the queue, it stays there.
Resubmission is worth doing when the sitemap structure or URL has changed (for example, switching from /sitemap.xml to /sitemap_index.xml after installing an SEO plugin), when you have fixed an error that was previously preventing the sitemap from being processed, or when you have added a large batch of new pages and want them indexed quickly rather than waiting for the next routine fetch.
Resubmission is not worth doing when you have added a single new page (the next routine fetch will catch it), when content on existing pages has changed (lastmod handles this if your plugin is set up correctly), or simply because a few weeks have passed without changes.
For individual pages that need urgent indexing rather than the whole sitemap, the URL Inspection tool in the left sidebar is the right path. You enter the URL, click “Request indexing”, and Google adds it to a faster indexing queue. This is the page-level equivalent of sitemap submission, and it is the correct tool when one specific page matters rather than the whole sitemap.
Common submission errors and what they mean
Five errors show up repeatedly in the Sitemaps report. Each has a specific cause and a specific fix.
1. “Couldn’t fetch”
Search Console could not retrieve the sitemap file at all. This is the most common error and almost always means the sitemap URL is wrong, the file does not exist at that URL, or something is blocking Google from reaching it. Check the URL in an incognito browser tab first. If you cannot load it either, the file is missing or the path is wrong. If it loads for you but Search Console cannot reach it, check robots.txt for any Disallow rule that might be blocking the sitemap path, and check whether your firewall, CDN, or hosting provider is blocking Googlebot’s IP range.
2. HTTP errors (4xx and 5xx)
The server returned an error status when Google tried to fetch the sitemap. A 404 means the file is not at the URL you submitted. A 403 means access is forbidden, usually a permissions issue or basic authentication wall. A 500 means your server crashed while trying to serve the file. Check the file exists at the URL, check server logs for the error, and confirm the file has the right permissions to be read by the web server’s user.
3. XML parsing errors
The file was fetched successfully, but it is not valid XML. The most common cause is an unescaped ampersand in a URL (covered in Lesson 5: How to Build a Website Sitemap Manually with XML under encoding), but missing closing tags, mismatched element names, or stray characters can produce the same result. Use an XML validator or paste the file into a parser to find the exact line that breaks. Fix it, then resubmit.
4. URLs blocked by robots.txt
Some URLs in the sitemap are blocked by your own robots.txt file. This is a warning rather than a hard error, and the sitemap is still processed, but the blocked URLs will not be crawled. Having URLs in the sitemap that robots.txt blocks is contradictory and sends mixed signals. The fix is either to remove the blocked URLs from the sitemap, or to update robots.txt to allow them. One or the other, not both at the same time.
5. Submitted URLs not indexed
The sitemap was processed correctly, but Google chose not to index some of the URLs. This usually appears in the Pages report under Indexing rather than the Sitemaps report directly, and the reasons can be: the pages have noindex set, the pages are too thin or duplicative to merit indexing, or Google decided the canonical version is elsewhere. This is not a sitemap problem. The sitemap did its job by surfacing the URLs. The unindexed status is a page-quality or canonical issue that needs investigating separately from the sitemap itself.
Where this leaves us
You now have a sitemap submitted to Google Search Console with the Sitemaps report monitoring its health. Google knows about your sitemap directly. You will see fetch dates, discovered URL counts, and any errors right inside the dashboard.
Google is not the only search engine that matters. Bing has its own Webmaster Tools and its own crawler, and Microsoft’s Copilot pulls from Bing’s index. The other AI Search era crawlers vary in how they discover sitemaps, but Bing’s index feeds many of them, which makes Bing Webmaster Tools more important than its standalone traffic share might suggest.
The next lesson covers submission to Bing Webmaster Tools and the engines that draw from its index, including Copilot, ChatGPT search, and DuckDuckGo. The lesson after that covers IndexNow, the push protocol that lets you notify several engines about URL changes the moment they happen.
Up next: Submitting Your Sitemap to Bing Webmaster Tools →
This is Module 2: Lesson 7 of The Sitemap Series, a Technical SEO series on sitemaps from first principles, built for the AI Search era.