How to Submit a Sitemap to Google Search Console and Troubleshoot Errors
Published:
Last Updated:
Category: SEO & Content
Authors: Shusaku Yosa
Submitting a sitemap tells Google where to find a published list of URLs. A successful submission does not mean that every listed article has been crawled or indexed. Separate the file’s fetch status, its current contents, and the state of an individual URL so that you investigate the right problem.
What sitemap submission does—and what it does not guarantee
A sitemap lists URLs and, where appropriate, information about important updates. Search Console submission does not upload the file to Google. Your CMS or server publishes the file, and you submit its location.
Google’s sitemap creation and submission guide treats a sitemap as a discovery hint, not a guarantee of crawling or indexing. A larger submitted URL count is also not evidence of additional search impressions or clicks. Decide whether you are checking file retrieval or a specific page’s search status before making a change.
Before submission: property, owner access and the actual sitemap URL
Select the Search Console property for the intended site. With a URL-prefix property, check the protocol, hostname, and relevant path. A domain property has a different scope. A familiar site label alone is not enough to establish that the selected property covers the URL you intend to submit.
Confirm the required owner access using the Sitemaps report documentation. If access is insufficient, ask the responsible owner. There is no reason to alter unrelated permissions or verification settings simply to diagnose a submission.
- Obtain the actual sitemap URL from the CMS or generator.
- Check whether it is publicly retrievable without a login.
- Identify whether it is a sitemap or a sitemap index.
- Record the exact URL, selected property, and check time.
If your browser cannot display the file, identify where that failure occurs. A browser extension or local client error does not prove that Google cannot fetch it. Conversely, seeing a document in your authenticated browser does not prove that it is publicly available.
Check sitemap files, sitemap indexes and URL inclusion
A regular XML sitemap has a urlset containing url entries, with each loc giving an absolute page URL. A sitemap index has a sitemapindex containing sitemap entries, with each loc giving the absolute URL of a child file. This is a structural illustration, not a complete XML file to paste into production.
Illustrative file | Simplified structure | Content |
|---|---|---|
Regular sitemap | urlset → url → loc | Absolute URLs for article A and article B |
Index with two children | sitemapindex → sitemap → loc, twice | Absolute URLs for the article sitemap and page sitemap |
For example, an entry has the relationship “<url><loc>absolute URL of article A</loc></url>”. Real XML also needs the correct namespace and valid structure. Compare the generator’s output with the official documentation.
The creation guide specifies UTF-8, absolute URLs, and the canonical URLs you want considered. A file is limited to 50MB uncompressed and 50,000 URLs. Larger lists can be split using a sitemap index. If lastmod is provided, it should reflect an actual significant update rather than a date refreshed mechanically every day.
Submit the URL and read status, last read and discovered pages
Open the property’s Sitemaps report and inspect the new-submission field. Enter the URL in the form the interface expects, considering any part already supplied by that property. Do not assume every screen requires only the final relative path. Submit, then inspect the entry and its details.
Report field | What it establishes | What it does not establish |
|---|---|---|
Submitted URL and date | What location was submitted and when | Subsequent retrieval or indexing |
Last read | When Google last read the file | That it matches today’s contents |
Success | The file was fetched and read successfully | Indexing or search visibility of every page |
Fetch or parsing error | A retrieval or reading problem | That article quality caused the issue |
Discovered pages | Pages identified from the file | Indexed URL count or clicks |
Google can fetch a submitted sitemap again, but that does not promise an immediate fetch every time content changes. Inspect substantial changes or persistent retrieval failures before deciding to resubmit. Repeatedly submitting an unchanged file is not an indexing guarantee.
Diagnose fetch, HTTP and parsing errors
When a fetch fails, retain the precise URL and error details before changing the CMS. A failure involving an index, a child sitemap, or a listed article may have a different cause.
Observed evidence | Possible explanation | Next check |
|---|---|---|
404 or another HTTP response | Wrong location, missing generation, moved file | Compare the generator and published URL |
Login or denied access | Authentication or server restrictions | Review public access and Google’s fetch evidence |
XML parsing message | Invalid structure, characters, or mixed output | Inspect the reported location and generated file |
Failure in one local browser | Extension or client environment | Keep the local error separate from Google’s status |
Successful file, unindexed article | Individual page or discovery conditions | Inspect the URL separately |
A query parameter is not, by itself, proof that a sitemap URL is invalid. Reinstalling a plugin without evidence can also introduce additional uncertainty. Work through responses, redirects, access conditions, and syntax. Record who checked each item and the result of the follow-up.
Track URL inclusion, canonical selection and indexing separately
Choose an important article and keep a separate record of its current inclusion and search status. A successful sitemap report or a historical sitemap reference in URL Inspection does not directly prove that the URL is present in the current XML.
Record field | Hypothetical entry |
|---|---|
Article | Canonical candidate for article A |
Current XML inclusion | Directly checked on October 11, 2026: present |
Sitemap last read | October 10, 2026: Success |
URL Inspection status | Discovered, currently not indexed |
Last crawl and canonical | Record the displayed values; do not fill gaps by inference |
Next check | Inspect fetchability and discovery paths, then track changes |
This fictional record shows that sitemap success and an unindexed URL can coexist. Follow the URL Inspection documentation to distinguish stored indexing information from a live URL test. A successful live fetch is not a promise of indexing.
Keep unknown, discovered but unindexed, crawled but unindexed, and indexed states separate. The file, the page, and the search system provide different evidence. Use that evidence to choose the next check rather than assuming that every unindexed article needs a rewrite.
Continue with these related practical guides:
