How to submit a sitemap in Google Search Console
Read the conclusion first
A sitemap supplies discovery hints, not an indexing command. Build a truthful list of intended canonical pages, verify the public file and its URLs, then track submission, Google processing and page indexing separately. Lastmod should describe a real significant change, not a daily freshness script.
Applicable conditions
Applies to maintaining a list of official indexable URLs. Do not submit an index sitemap for test sites.
Before you open the report
The exact sitemap URL, its parsed loc values, canonical targets and the intended public-page set.
Use one concrete URL or report first. Keep account credentials and private visitor data out of shared notes.
Steps and verification
Choose URLs from the intended public inventory
Include complete canonical addresses for useful pages you want searchable. Check representative products, articles and language routes against current redirects, noindex and authentication. Remove deleted pages and erroneous generator outputs. Keep the same canonical preference in internal navigation.
Use lastmod only when the underlying content or other meaningful page information actually changed. A template run time is not an editorial revision. For large inventories, split at the applicable limit: 50,000 URLs or 50 MB uncompressed per sitemap, and organize files with an index where useful.
Validate the file and destinations independently
Fetch the public sitemap without login and verify the actual XML, UTF-8 encoding, namespace and escaped URL values. A 200 challenge or HTML error is not a usable XML sitemap. For an index, test its child files too.
Sample listed destinations across templates and languages: they should deliver the intended content and index policy. A syntactically valid file can still list wrong hosts, redirect chains or private URLs. Preserve the validation result and the generation source that needs correction.
Follow the processing result without inflating it
Submit the actual file to the correct native GSC property and retain its reading status and errors. A submission receipt is not proof that it was read. A successful read is not proof every listed URL was crawled or indexed.
Inspect important listed pages independently and keep their dated outcomes. Correct confirmed generator or access faults, then follow the updated processing state. Maintain ordinary navigation to the same pages; XML should not be their only entry point. Do not rename and repeatedly resubmit an unchanged file to chase an immediate index result.
Common mistake: Let sitemap replace internal links
Important pages still need normal clickable entry points; they cannot exist only in XML.
How to decide when you encounter different situations
Match your actual observation to a row before changing the page. If it does not match, collect the missing evidence first.
| What you see | Next step | How to confirm |
|---|---|---|
| Submission accepted | Continue observing read and processing | Cannot claim full indexing |
| List contains redirects and noindex | Remove non-target canonical URLs | Spot-check representative pages one by one |
| lastmod changes every day | Only write real content update times | Record the actual change source |
The submitted list contains URLs you do not want indexed
Teaching scenario. Names, URLs and numbers illustrate the method; they are not customer or measured site results.
- What you observe
- Teaching example: a sitemap lists 100 URLs, including 15 redirects and 5 noindex pages. A successful submission does not make those 100 pages indexed.
- What it establishes
- The sitemap should communicate intended canonical URLs. Retrieval, parsing and indexing are separate states; their counts can differ.
- What to do next
- Remove unintended redirects and excluded pages from the list while preserving their actual site behavior. Check representative final URLs and use lastmod only for real content updates.
What counts as a checked result
Archive the submitted URL and receipt, then inspect the sitemap-detail result and sample page statuses later. Do not infer indexed totals from a “Success” label.
If a required check fails, keep the error and return to the matching decision branch. A blank record means unverified, not passed.
Leave with a checked result, not another vague instruction
- Your deliverable
- A canonical public URL inventory, a checked XML and independently recorded Google processing.
- Stop and resolve this first
- Do not update lastmod for unchanged content or use XML as the only navigation path.
Record missing evidence in the worksheet below. An unresolved test is useful information; a blank field is not a pass.
Checklist for this page
Fill in your own check results, then decide the next step. Blank means not yet verified, not normal. Content is saved only in the current local session and is not submitted to the server or AI.
Frequently asked questions
Will successful submission lead to immediate rankings?
No. Discovery, indexing, and ranking are different processes.
Does every edited page require a new sitemap name?
No. Maintain a stable sitemap and accurate entries. Rename only for a real structure change, not to repeat the same submission.
Official materials and usage boundaries
This page provides operational judgment and checking methods, and does not show customer success cases. Calculation examples and request samples are teaching materials, not actual website metrics. Google's reports, conditions, and interfaces may change; please refer to the current official documentation.
Read the corresponding Google official documentationContinue with the relevant tool
Paste the actual sitemap XML into AISEO Site to check duplicate entries and lastmod fields before submitting the file in GSC.
See how it works →