XML Sitemaps: How to Create, Submit and Troubleshoot Them

A sitemap is often one of the first files created during an SEO setup and one of the last files anyone reviews afterward. That creates a familiar problem: the website changes, while the sitemap continues to advertise old URLs, duplicate variants, or pages that were never meant to appear in search.

The solution is to treat the sitemap as part of publishing and maintenance. This guide explains how to decide what belongs in it, create a valid file, submit it, and diagnose common problems. It also shows how to turn a sitemap review into useful development tasks rather than simply recording that a file exists.

What an XML sitemap does—and what it cannot do

A sitemap is a machine-readable list of URLs, optionally accompanied by information such as meaningful modification dates. It helps search engines discover content and understand which URLs the site owner considers important. Google’s sitemap overview explains its role in discovery, especially for larger sites or content that is harder to find through ordinary links.

Keep four separate steps in mind: discovery, crawling, indexing, and ranking. A URL can be discovered without being crawled immediately. A crawled page can be excluded from the index. An indexed page can still have limited search visibility. Submitting a sitemap does not bypass these stages.

Nor does a sitemap replace useful navigation. Readers still need to reach important pages through menus, categories, contextual links, and pagination. If a valuable guide appears only in an XML file, its discoverability problem is also a website-structure problem.

XML sitemap versus HTML sitemap

An XML sitemap is primarily intended for automated processing. An HTML sitemap is a normal webpage that organizes links for visitors. Both can be useful, but they serve different needs. Publishing an HTML list of articles does not automatically create a valid XML sitemap, and an XML file is not a substitute for a readable resource directory.

For a small, well-linked website, a sitemap may be a simple supporting resource. For an online store or publication with many URLs, the generation rules become more important. Scale the process to the site rather than adding complexity for its own sake.

Start with the URLs you actually want indexed

Before generating a file, define the inclusion policy. Which content types are public? Which versions are preferred? Which pages provide independent value? A CMS may create archive pages, search results, attachment pages, and filtered variants automatically. Their existence does not mean they all belong in the sitemap.

Build an inventory from the publishing database or another authoritative source. A crawler can help compare what is linked with what exists, but it may miss orphaned pages or collect parameter combinations that should not be promoted. Comparing two inventories is often more informative than assuming either one is complete.

These are practical defaults, not a replacement for understanding the site. Some category or faceted pages can serve a genuine search need. Others are merely alternate ways to display the same list. Decide based on the page’s purpose, then align the sitemap with the wider indexing strategy.

Create a minimal, valid XML sitemap

The Sitemaps protocol defines a URL set with a namespace, a separate entry for each URL, and a location element containing an absolute address. Use UTF-8 encoding and escape XML-sensitive characters in values. Optional fields should be added only when you can populate them accurately.

This illustrative file contains two preferred URLs. Replace the example domain and paths with your own; the dates are examples, not recommended defaults.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/services/seo-audit/</loc>
    <lastmod>2026-08-20</lastmod>
  </url>
  <url>
    <loc>https://www.example.com/guides/site-launch/</loc>
  </url>
</urlset>

The second entry deliberately omits a modification date. That is better than manufacturing one. When a generator prints the current date for every page on every request, it obscures which content actually changed.

A query string containing an ampersand must escape it in XML, for example ?type=guide&lang=en. Escaping a character does not decide whether that parameterized URL belongs in the sitemap. Validate the inclusion policy first and the syntax second.

Keep URL formatting consistent

Use the intended HTTPS version, hostname, capitalization, and trailing-slash convention. Do not mix production and staging domains. If the preferred page is served at a clean directory URL, avoid listing an alternate filename version solely because it appears in an export.

During review, compare the sitemap URL with the page’s canonical and internal links. They should tell a coherent story. A sitemap can express a preference, but it cannot force a search engine to ignore contradictory signals or treat duplicate pages as distinct resources.

Choose a generation method that survives the next edit

Hand-writing a sitemap is reasonable for a very small static website when updates are rare and someone owns the task. Once publishing becomes regular, automate generation from the same records that define public pages. That reduces the chance of adding an article to the blog but forgetting its sitemap entry.

For a CMS, first check whether sitemap functionality already exists. Identify which component owns it and what content types it includes before adding another plugin. Two overlapping generators can create confusing maintenance responsibilities even when both files are technically readable.

A practical publishing workflow

1. A page is approved for public release.
2. The publishing system confirms its final URL and indexing intent.
3. The sitemap is generated or refreshed using those records.
4. A validation step checks XML syntax and samples the listed URLs.
5. The release owner checks that the public sitemap reflects the change.

For custom websites, add a repeatable build step rather than relying on an editor to remember a separate file. The generator should exclude drafts and unwanted variants explicitly. Keep that logic understandable so a developer can explain why a particular page is missing.

For ecommerce, decide what happens when a product becomes unavailable. Temporary stock changes do not automatically mean a useful product page should disappear. Permanent removal, replacement, and variant consolidation are different situations. The sitemap should follow the page’s actual public state and intended indexing treatment.

When to split files and use a sitemap index

A sitemap is limited to 50,000 URLs and 50 MB uncompressed. Larger collections need multiple files, which can be referenced by a sitemap index. Google’s build-and-submit guidance documents supported formats, limits, and recommended practices.

You can also split earlier for operational clarity. Separate article, product, and category sitemaps may make it easier to identify which publishing process introduced a problem. Do not split just to create an impression of technical sophistication; use boundaries that help the team investigate and maintain the site.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://www.example.com/sitemaps/articles.xml</loc>
  </sitemap>
  <sitemap>
    <loc>https://www.example.com/sitemaps/services.xml</loc>
  </sitemap>
</sitemapindex>

A sitemap index lists sitemap files, while a URL sitemap lists webpages. Mixing these structures is a common implementation mistake. Validate the index and its child files separately, and confirm that every referenced file remains accessible after deployment.

Validate the file before submitting it

Opening a sitemap in a browser is a useful first check, but it is not a complete validation. A page can look like XML while containing malformed entities, unexpected HTML, or URLs that do not meet your intended policy.

• Confirm that the sitemap URL returns the actual file without requiring a login.
• Check that the response is successful and does not contain a challenge page or error template.
• Parse the XML and verify the namespace and expected structure.
• Check for duplicate entries, staging addresses, and relative URLs.
• Test a representative sample from each content type.
• Compare listed URLs with their response status, indexing directives, and canonical destination.

Do not limit sampling to the homepage and one article. Include a recently published page, an older page, a page with special characters, a redirected address, and a content type that uses a different template. This small variation often exposes assumptions hidden in a generator.

Save the result of the validation with the release. If someone later reports that an article is missing, you can distinguish a generation problem from a caching problem or a subsequent change to the page.

Make the sitemap discoverable and submit its address

Publish the sitemap at a stable public address. A common choice is a root-level file such as https://www.example.com/sitemap.xml. The address is more important than a particular filename: it should reliably serve the intended content.

You can advertise the location in robots.txt with a line such as:

Sitemap: https://www.example.com/sitemap.xml

Use the correct Search Console property and submit the sitemap address through its Sitemaps report. You are telling Google where the file is hosted, not uploading your local XML directly into Google. The official Sitemaps report documentation explains submission, permissions, and reported processing problems.

After submission, record the file location and review the reported status. Processing can take time. If the file changes at the same address, keep it current rather than creating a new filename for every article. A clear ownership record is more useful than repeated submissions with no investigation.

Troubleshoot the right layer

Start by deciding whether the failure concerns fetching the sitemap, parsing the file, discovering its URLs, or indexing individual pages. These are different problems and require different evidence.

Example: a new guide is missing

Suppose an editor publishes a guide and confirms it appears in the blog. The sitemap still excludes it. First check whether the public file is cached. Then inspect the content record: is the page marked published, does it use a new content type, or does an old exclusion rule match its path?

If the generator is correct but an older cached file is being served, fix cache invalidation. If the generator excludes the new content type, update the rule and test another page from that type. Manually inserting one URL may conceal the underlying problem and leave the next article missing too.

Example: the report says success, but search does not show the page

A successful sitemap status means the file was processed, not that every URL earned an index entry. Use URL Inspection and review the page itself. Does it return useful content? Is there an unintended noindex? Does its canonical point elsewhere? Is it substantially duplicating an existing page?

Google’s URL Inspection guidance distinguishes information about the indexed version from a live test. Compare both when appropriate, and avoid interpreting a successful live fetch as proof that indexing has already happened.

Keep sitemaps aligned with the website

Sitemap maintenance works best when it is tied to real events: publishing, deletion, a URL change, a template update, or a migration. Assign responsibility for the generator as well as the content. Otherwise the editor may assume development owns the file while development assumes the CMS handles everything.

For routine reviews, compare totals by content type and investigate unexpected changes. A sharp increase could represent a successful archive import or accidental inclusion of filter URLs. A decrease could be intentional consolidation or an exclusion bug. The count is a signal to investigate, not a quality score.

Keep modification dates tied to meaningful page changes when you provide them. Do not update every entry simply because a footer or tracking script changed. If reliable dates are unavailable, omit the optional field until the generation process can support it honestly.

During a redesign or migration

Use the sitemap inventory alongside a redirect map and crawl results. Check the new preferred addresses, update internal links, and verify that old URLs lead to relevant replacements where intended. Avoid leaving a newly generated sitemap full of old destinations simply because the design changed more quickly than the URL data.

A migration needs its own release and monitoring plan. The sitemap is one component; it cannot compensate for missing content, broken redirects, accidental restrictions, or a changed navigation structure. For a broader publishing process, use our SEO checklist before and after publishing.

A concise sitemap review handoff

When an issue needs development work, provide enough information to reproduce it. “The sitemap is broken” is rarely sufficient. A useful ticket explains the expected result and the evidence that will show the fix worked.

1. File: the exact public sitemap or index address.
2. Scope: the affected content type or URL pattern.
3. Example: one missing, duplicated, or incorrect entry.
4. Expected state: whether the URL should be included and why.
5. Validation: a parse check, response check, and representative sample after deployment.
6. Owner: who verifies the public result and follows up in Search Console.

This approach keeps the investigation focused on a durable correction. It also helps an editor confirm that future pages will behave correctly, rather than accepting a one-off manual repair that cannot be reproduced.

Frequently asked questions

Does a sitemap improve rankings by itself?

No. It supports discovery and communicates URLs. Ranking still depends on the page, the search context, and many other factors. Treat sitemap health as a technical foundation, not a growth guarantee.

Should I list every URL the website can generate?

No. Start with preferred public pages intended for search. Review duplicates, filters, internal search results, and restricted areas against a clear inclusion policy rather than exporting everything.

Can I remove a page from Google by deleting its sitemap entry?

Removing an entry does not instruct Google to remove an already known page. Choose the appropriate page-level response, indexing control, or removal process for the situation. Sensitive content needs proper access protection.

Do I need priority and change-frequency values?

They are optional protocol fields, and Google says it ignores them. Focus on accurate URLs and useful maintenance instead of spending time assigning arbitrary scores to every page.

Should I submit separate sitemaps for each article?

Usually not. A stable sitemap or a sensible sitemap-index structure is easier to maintain. Keep the generator current and use meaningful divisions when the site’s scale or operations justify them.

What if sitemap checks reveal wider problems?

Review the site’s indexing rules, page templates, and publishing process together. Our SEO Audit service can help turn those findings into a prioritized action plan. Bring the sitemap address, sample URLs, and any relevant Search Console messages so the investigation starts with concrete evidence.