How to Create and Validate an XML Sitemap

Key takeaways

Validate the XML and review the listed URLs separately.
Distinguish a URL sitemap from a sitemap index.
Keep dates accurate and use intended public URLs.
Treat submission as discovery support, not an indexing guarantee.

To learn how to validate XML sitemap output, split the task in two. Check whether the file is valid and readable. Then Review whether its URLs are the pages you intend to present for search. A clean XML result does not prove that the listed pages are the right ones. Start with the crawling and indexing guide for the wider process.

This guide covers creating a practical URL set, checking the file or sitemap index, and verifying the live result. It does not replace an indexing diagnosis for every URL or promise that file upload will put a page into search.

Define the URL set before choosing a generator

Use the canonical URL check when the preferred live version is unclear.

List the live sections the file should show. Ask the content owner which versions should be shown in search. Keep that goal apart from the larger inventory of everything the site can serve.

Google recommends listing your preferred URLs as full, absolute addresses. Do not fill the file with every version simply because the CMS can export it. Review retired routes, test pages, and duplicate variants against the site’s agreed policy.

Record who owns the output. A CMS, plugin, framework, or custom process may generate it. If several tools produce distinct files, find the main sent source and how the others relate to it before adding another tool.

Create the file using the site’s existing system

For a site with working built output, start by checking that output rather than replacing it. Ask how newly live pages are added and how removed or changed pages leave the set. A key file must stay live after today’s review.

A small manual file can be suitable for a limited set. But it needs an owner and an update process. A build tool also needs review: automation can repeat the same wrong inclusion rule across many pages.

Keep a proposed file or test output apart from the live version. Agree which source is meant to go live. Otherwise a tester may approve a correct local file while the site continues serving an older one.

How to validate XML sitemap structure

Open the exact live file or load its content into a validator. Confirm that you received XML rather than a sign-in page, an error document, or an HTML preview mistaken for the actual file.

Check the format and key structure. In a URL file, entries find page locations; a sitemap index instead points to child file files. An index can pass while a child file fails. Test both.

A single file may hold up to 50,000 URLs. Its size must be no more than 50 MB uncompressed. Split a larger set into files. A sitemap index can list them. Use UTF-8 and correct XML escaping. Follow a parser’s error details to the broken value.

Do not fix the symptom only in a built file that will soon be overwritten. Give the developer the failing entry and tool rule so the correction can survive the next build or release.

Validate a sitemap index and its child files

Use the robots.txt access test for an access-rule question rather than assuming XML validity proves access.

For an index, note the child addresses and check that they return the planned files. Then validate the relevant children. A correct parent can still reference a missing child or a file with a different problem.

Choose a sample from each child type and build path. For a small site, checking every file may be practical. For a large set, make the coverage and any unchecked groups clear rather than calling one successful sample a complete review.

Keep failures tied to their file and entry. “The file is broken” is less key than naming the child, the affected address, and the actual error the tester reproduced.

Review the pages behind the entries

Check noindex output if a listed page is intentionally or accidentally excluded.

Open sample listed URLs and compare them with the planned live pages. Check the final address, response, and indexing goal. A working page at an unexpected address may still reveal a tool rule that needs attention.

Review exclusions too. Pick newly live and recently changed pages that should belong in the set. Then Check their presence. A file can be well formed while silently omitting a whole new section.

Keep a URL’s inclusion apart from its actual index status. A file supports discovery and shows preferences. It does not override a noindex rule, resolve a conflicting URL choice by itself, or guarantee a search result.

Check dates without manufacturing freshness

Use lastmod only when the tool can keep it correct. Give the date of the last change that matters. A daily build does not make an unchanged page new.

Ask which event updates the value: a meaningful content edit, a template export, or a routine rebuild. Compare a few known changes and unchanged pages. A date field that always equals today may be describing the build rather than the page.

Google ignores priority and changefreq values. Do not spend the review tuning those fields while missing URLs or invalid entries remain open. Focus on the data and behavior that matter to this task.

Example: a new service guide is missing from a valid file

If the page is listed but its answer is missing from tested output, run the focused JavaScript rendering check.

Imagine a fictional repair business whose validator reports no XML errors. The owner has just live a guide in a new blog section. This example assumes no measured traffic or indexing outcome.

The tester compares the expected page list with the built entries. The new guide is missing, while an older test route is included. The file parses correctly. But the URL-choice rule does not match the owner’s goal.

The developer adjusts the source rule, rebuilds the file, and the tester checks both cases again. The key result is a correct URL set and valid output, not a promise that every listed page will rank.

Verify submission and the next publication cycle

Inspect a relevant page with the URL Inspection workflow when its discovery or processing needs a closer review.

After releasing the planned file, open its live address again. Confirm that it matches the approved output. Use the relevant search-engine tools to check whether the sent file can be read and check reported errors with their dates.

Submission and acceptance of a file are not the same as indexing all its entries. Keep those results apart. Do not repeatedly send unchanged output as a substitute for fixing a checked access or content problem.

Test what happens when a page is added or removed. Does the live file change as planned? DEX can help with publishing and page checks. The site’s own tool must still build the right URL set. Close this task when the file and its update process work.

FAQ

Does valid XML mean every listed page should be indexed?

No. Check the URL set and page intent separately. A sitemap does not guarantee indexing.

Is a sitemap index the same as a URL sitemap?

No. An index points to sitemap files. Check those child files as well as the index.

Should lastmod change every day?

Use a truthful date for a significant update. Do not invent changes to make an unchanged page look fresh.

Sources

Build and submit a sitemap · Google Search Central

Dex SEO

Dex SEO is an AI SEO agent for small businesses. Every article here is planned from search data, drafted by Dex, fact-checked against the sources it cites, and reviewed by the team before it is published.

How this article was made: planned and drafted by Dex from search data, fact-checked by Dex (5 claims checked), then approved by the Dex SEO team.