XML Sitemaps: Create, Submit, and Verify URLs and Indexing

An XML sitemap lists URLs for search engines to discover; an HTML sitemap helps people navigate a website. An XML sitemap can also provide useful update information. Creating and submitting one does not guarantee that Google will crawl, index, or rank every listed page.

A reliable workflow is to choose the URLs, generate the file, verify that it can be retrieved, submit its location, and then inspect important URLs separately. For the product's broader role, read what Google Search Console does. Ownership and initial connection belong in the separate Search Console setup guide.

XML and HTML sitemaps serve different purposes

An XML file does not replace normal navigation. Keep articles reachable through useful categories and breadcrumb navigation. Conversely, publishing a human-readable directory does not mean an XML sitemap has been generated or submitted.

Google's sitemap creation guidance explains their value for large sites, new sites, and content that may be harder to discover through links. A sitemap is a discovery aid, not a replacement for accessible pages, helpful content, or consistent publication settings.

Choose public canonical URLs intentionally

Start with a publishing inventory rather than every address your system can generate. Suitable candidates are public pages that deliver their intended content successfully and that you want considered for indexing. Keep the selection consistent with canonical preferences, redirects, and indexing controls.

This is an operational rule, not a claim that one unsuitable URL triggers a site-wide penalty. Google can select a different canonical URL from the one you nominate. Use the canonical tag verification guide when those preferences disagree.

Generate valid XML and meaningful update dates

Observe both file limits

A standard sitemap file can contain up to 50,000 URLs and be no larger than 50MB uncompressed. Split files before either limit is exceeded, then reference them in a sitemap index where appropriate. Compression does not change the uncompressed-size limit. The Sitemaps protocol describes the XML structure and limits.

Use UTF-8. XML escaping and URL encoding solve different problems: the characters used in a query string must still be represented correctly inside XML. Even when a CMS generates the file automatically, verify that a parser can read the entire document and that every intended child file is available.

Use lastmod for real, significant changes

If you provide lastmod, tie it to meaningful changes in the page's main content, structured data, or important links. Do not reset every article's date whenever the sitemap is regenerated or a copyright year changes. Google's guidance says it uses consistently accurate lastmod values and ignores priority and changefreq.

A CMS timestamp might represent an editorial change, a publication operation, or a background process. Agree on the update definition and time handling with the team maintaining the generator. A technically valid date is not necessarily an informative account of when the content changed.

Create, verify, and submit the file

1. Check whether the CMS or site generator already publishes sitemaps.
2. Record the actual file locations, child files, and regeneration process.
3. Compare the listed URLs with the intended public canonical inventory.
4. Use an authorized method to verify retrieval and XML validity.
5. Confirm the correct Search Console property and the required permissions.
6. Submit the sitemap location and record processing status and last read.
7. Inspect important individual URLs separately.

Do not assume every website uses the same root-level filename. Check the CMS configuration, the robots.txt declaration, or maintained operating documentation. Submitting a sitemap tells Google where to retrieve it; it does not upload the file's contents into Search Console.

Property type and interface context affect how a location is entered. Confirm the domain, property scope, and permissions before submitting a file for a multi-tenant environment. Google's Sitemaps report documentation explains the current report and access requirements.

Separate retrieval success from individual indexing

A successful processing status establishes something about the file Google retrieved at that time. It does not prove that today's XML contains a particular URL or that every listed page is indexed. Record the current file, Google's last retrieval, and individual URL inspection as separate evidence.

In a fictional example, an article appears in the current XML but inspection reports “Discovered — currently not indexed.” Record both facts. If the state is “Crawled — currently not indexed,” Google retrieved the page without indexing it at that point. Investigate content, canonicalization, duplication, internal links, and technical conditions rather than naming content quality as the sole cause.

A fictional publishing-inventory example

Suppose a site has 100 published articles, adds two, moves one to a new address, and removes one. The expected article-URL count becomes 101. The move replaces an address; it does not add another article. If the sitemap also contains category pages, its total count will differ from the article count, so define the inventory scope first.

Check that both new URLs appear, the moved article uses its new address, and the removed address is absent. Record the generator's update time, then compare it with Google's next last-read time. Inspect selected URLs separately. A matching total can conceal the wrong individual URLs, which is why a release check should verify changed entries as well as counts.

Troubleshoot unavailable files and unexpected counts

A browser's failure to display XML can result from the viewing environment, an extension, an access restriction, or a delivery error. Unless another authorized method retrieves the file, record its individual listings as unverified. A historical Search Console success does not prove that the current file is accessible or correct.

When counts differ from the article inventory, check publication rules, language scope, deduplication, partitions, and generation time. A larger count is not automatically better. Document how new publication, migration, and removal update the CMS, normal links, and sitemap, including any timing differences.

Keep a short operating record: file URL, check date, retrieval method, last-read date, expected and observed counts, selected URL inspection results, and owner. Review changes after a release rather than repeatedly submitting an unchanged file without investigating the mismatch.

The broader SEO fundamentals guide can help place this task in context. Evaluate indexing state separately from search impressions and clicks. A submitted sitemap, an indexed page, and a page attracting useful visits are three different milestones.