XML Sitemap Checklist

Use this for: A site with an existing or newly generated sitemap.

In your website editor, look for its sitemap setting or generated sitemap address. You can also open /robots.txt on your public domain and look for a Sitemap line, or open Search Console → Sitemaps for a previously submitted address. Do not assume every site uses /sitemap.xml.

Open the address. If the XML root is sitemapindex, each loc beneath a sitemap element names a child file. Open those children before counting pages. A urlset file contains page entries beneath url elements.

1. Find the sitemap address in your CMS, robots.txt or existing Search Console record.
2. Identify whether its root is sitemapindex or urlset.
3. Open each child in the scope of your audit and keep its address available.

Use this for: Public sitemap files and indexes.

Open each sitemap in a private browser window. In Chrome Developer Tools → Network, reload, select the sitemap request and open Headers. Inspect its Status Code and the Response content. A successful request should return the sitemap, not a login form or an HTML error page.

If the old address redirects, use its final working sitemap address for discovery and submission. Test a failing child directly; a working index does not prove that its children load.

1. Load the index and child files without a signed-in session.
2. Read the request status and response content in Network.
3. Give failed file addresses and response details to the site owner; retest after repair.

Use this for: XML URL sitemaps and sitemap indexes.

Use your sitemap generator’s validation result or ask the developer to parse the saved XML against the sitemap schema. In the file, a URL sitemap needs urlset, the sitemap namespace, and a loc inside each url. It must use UTF-8 and properly escape XML values.

Read representative loc values as well as the validation result. Each page address should be complete, including protocol and host, and should use the intended public domain. A browser stylesheet can make XML look like a table; inspect the underlying file when its format is unclear.

1. Validate the saved file with the generator or a developer’s XML parser/schema check.
2. Check loc values for complete public addresses and correct escaping.
3. Fix the generator or source data, then validate the regenerated file.

Use this for: Every sitemap file, especially large or compressed inventories.

Read the URL count and uncompressed byte size in your generator or sitemap audit report for each child file. Each URL sitemap can contain at most 50,000 URLs and be at most 50 MB uncompressed, which the protocol defines as 52,428,800 bytes. A small gzip download does not establish the uncompressed size.

When either limit is exceeded, ask the developer to split the output and list the resulting files in an index. Recheck every new child. Sensible grouping by content type can make future errors easier to isolate; it is not a ranking requirement.

1. Find each child file’s URL count and uncompressed size.
2. Compare both measurements with the limits.
3. Split oversized files and verify that the index lists working new children.

Use this for: Published canonical pages that should be represented in the sitemap.

In your CMS, list the published service, product, category and guide pages you want discovered in search. Search the relevant child sitemap for each intended canonical address. Start with recent additions and one page from each template if a full check is too large.

A larger review can compare a site crawl with the sitemap inventory. If you use Screaming Frog, its sitemap-only list mode checks the supplied entries but cannot find pages missing from that input. Use an independent CMS list or a full site crawl to find omissions.

1. Get an intended-page list from the CMS or publishing record.
2. Compare exact preferred addresses with the relevant sitemap entries.
3. Add unintended omissions through the generator and inspect the fresh output.

Use this for: Page types with explicit include/exclude decisions.

Compare the sitemap entries with your site’s intended exclusions, such as account pages, internal search results and confirmation pages. Open an example before deciding. A parameter in a URL is not automatically a reason to exclude it; it may identify a distinct useful page.

If the page is meant to stay outside search, exclude it from the sitemap generator. If a wanted page has an accidental noindex or crawl block, repair that page’s setting instead of hiding the problem by removing its entry. Removing a sitemap entry alone does not remove a page from Google.

1. Choose a listed URL from each suspect page type.
2. Confirm whether its exclusion from search is intentional.
3. Remove intended exclusions from sitemap output, or repair accidental page restrictions.

Use this for: Page URLs included in the sitemap.

Open a sample of listed page addresses in Chrome Developer Tools → Network. Reload and inspect the main document request before any redirect, then the final page. Check that it directly returns the expected content, not a redirect, error or empty not-found screen.

For a larger inventory, Screaming Frog → Mode → List → Upload → Download XML Sitemap can fetch the listed addresses. Review response codes and final destinations. Fix broken wanted pages; replace moved entries with the intended final URL; remove genuinely retired entries.

1. Fetch the listed address and inspect its response and displayed content.
2. Decide whether the page moved, was retired or is unexpectedly broken.
3. Repair the page or update the sitemap to its intended working destination.

Use this for: Listed pages with duplicate URL variants or canonical declarations.

Open a listed page, view its source and find rel="canonical". Compare the target with the sitemap address and your chosen representative URL. If the declaration points elsewhere, first decide which address is actually correct; the page template may be wrong.

Keep the intended representative in the sitemap and correct inconsistent declarations. Repeated inclusion of the same URL across valid files is not automatically a protocol error, but remove accidental duplicates when they make the inventory harder to maintain.

1. Compare the sitemap address, declared canonical and intended representative.
2. Resolve which signal is wrong before editing.
3. Regenerate the sitemap or fix the page template, then compare them again.

Use this for: Sitemaps that emit lastmod values.

Compare a page’s lastmod value with its revision history in your CMS. Review a page with a recent substantive edit and an older unchanged page. Changes to main content, structured data or useful links can justify a new date; a routine rebuild or copyright-year change alone does not.

If the generator uses the current request or deployment date for every page, ask the developer to use the significant-content modification date. When a dependable date is unavailable, omitting the optional lastmod is better than inventing one.

1. Read lastmod beside the exact URL in the child sitemap.
2. Compare it with the CMS revision showing the meaningful page change.
3. Correct the date source or omit unreliable values, then regenerate.

Use this for: Sites whose content changes after the sitemap is generated.

Use a recent approved publishing change as your test: a new page, a meaningful edit or a retired page. Compare the public sitemap with what the change should have done. You do not need to publish a dummy page just to run this check.

If you have before-and-after exports, compare exact URL additions and removals. Equal totals can hide a missing page replaced by an unwanted one. Ask the developer to fix the CMS query, regeneration hook or stale file when output does not follow the actual publishing state.

1. Identify a real publishing change and its expected membership/date change.
2. Compare the fresh sitemap with that expectation and any earlier URL list.
3. Repair stale or incorrect output and check the changed pages again.

Use this for: Sites using a robots.txt sitemap declaration.

Open /robots.txt on the site’s public host and find its Sitemap lines. Copy each address into a fresh tab. It should identify the intended current file, including protocol and host. A single line for an index can expose its child sitemaps.

If you choose robots.txt as a discovery method and the reference is missing or stale, ask the site owner to add or correct it. Do not rewrite unrelated crawl rules as part of this change. Search Console submission is another supported discovery method.

1. Read the Sitemap lines in the public robots.txt file.
2. Open the declared addresses and compare them with the current file inventory.
3. Correct missing or obsolete references if this discovery method is used.

Use this for: Sites where Search Console sitemap submission or review is part of the workflow.

In Search Console, select the property covering the public site and open Sitemaps. With owner permissions, enter the final working sitemap or index address under Add a new sitemap and choose Submit. The file must already be published on your site; this field does not upload an XML file.

If the correct file is already submitted, review its existing row instead of repeatedly submitting an unchanged file. An empty report does not prove Google has never discovered a sitemap through robots.txt. If owner access is missing, mark this check Blocked.

1. Open the correct property’s Sitemaps report.
2. Submit the final public address if needed, or open its existing row.
3. Confirm the report contains the intended submitted address.

Use this for: Submitted sitemaps with Search Console processing data.

Open the sitemap’s row in Search Console → Sitemaps. Read Status and Last read, then open error details when present. Compare the read date with the time you fixed or regenerated the file. A report from before the repair cannot confirm the repaired version.

For a fetch failure, retest the file address and public access. For a parsing error, locate the reported file or line and repair the generator. Resubmit after fixing a persistent failure, then check the later result. Success means the file was fetched and read, not that all listed pages entered search.

1. Read the submitted file’s status, last-read date and any error details.
2. Match the reported problem to a current fetch or parsing test.
3. Repair and retest, then check a later Search Console processing result.

Use this for: A listed page whose search state needs investigation.

When a sitemap is read successfully but a wanted page is absent from search, inspect that exact address in Search Console → URL Inspection. Open Page indexing and read its status, last crawl and canonical fields. Compare the crawl date with your latest page change.

Classify the result before changing the sitemap again. An intended duplicate can correctly select another URL. A wanted page with an accidental exclusion needs a page-level repair. A page awaiting a newer crawl has a different next step from an XML parsing failure.

1. Inspect one affected exact URL and open its indexed Page indexing record.
2. Compare the recorded state and crawl date with the intended page and current output.
3. Use the relevant page-level checklist for the unresolved condition.