Your XML sitemap should list the preferred page URLs you want people to find in search: the versions that serve the intended content and aren't deliberately excluded from indexing. Leave out duplicate variants, old redirecting addresses, and pages you don't want indexed.
Review the URLs before worrying about the file's size or the number of entries. A useful sitemap reflects your publishing decisions. It doesn't make those decisions for you or repair a page that isn't working.
Choose the URLs you want people to find
Use the preferred page addresses as your starting point.
Start with your public content inventory. For each page, identify the address you would want a reader to reach from a search result. This guide focuses on ordinary web-page entries; image, video, and news sitemaps have additional requirements.
Google's sitemap introduction describes a sitemap as a discovery aid. It doesn't guarantee that listed URLs will be crawled or indexed. Keep important pages reachable through useful navigation and internal links as well.
When substantially the same page is available at several addresses, choose the preferred version. That is the canonical URL. Google's canonicalization guidance describes sitemap inclusion as a weaker signal than redirects or canonical annotations. It also advises against declaring different preferred URLs through different methods.
Make the page's canonical declaration, sitemap entry, and internal links agree with your intended choice. Adding an address to a sitemap doesn't force Google to select it as canonical.
Use complete addresses in the actual file, including the scheme and hostname. Google's sitemap-building guidance specifies absolute URLs rather than relative paths. Be consistent about the actual preferred host and URL format.
Check what each URL actually returns
A URL inventory should record the response and the decision.
Compare the inventory with the deployed site. Record the initial response, any redirect destination, the returned page, its canonical declaration, and relevant indexing controls.
Don't decide from the address alone. A plausible-looking guide URL might return an error page. A parameter might duplicate a page, or it might change the content meaningfully. Inspect it before applying a rule to an entire URL pattern.
A hypothetical review of a small publisher's sitemap
Imagine a furniture retailer reviewing its desk-buying guides. All paths, responses, and settings below are invented for this exercise. They are not HoneyWeRank audit results or observations of a real retailer.
The paths are shortened for readability. Actual sitemap entries would use complete URLs on the retailer's preferred public host.
| URL under review | Hypothetical observation | Decision |
|---|---|---|
/guides/choose-a-desk |
Returns the intended guide with HTTP 200, declares itself canonical, and has no indexing exclusion. | Include the preferred guide URL. |
/guides/choose-a-desk?source=newsletter |
Returns the same guide and declares the clean URL canonical. | Omit this duplicate variant; include the clean URL. |
/guides/desk-buying |
Permanently redirects to /guides/choose-a-desk. |
Omit the old address; list the reviewed destination. |
/search?q=desk |
Returns public search results with an intentional noindex rule. |
Omit it from the intended search-page inventory. |
/guides/desk-dimensions |
Returns HTTP 404, although the editor intended to publish a guide there. | Investigate the missing page; don't treat a sitemap entry as a repair. |
Only the first row is ready for inclusion on the evidence given. The other rows represent different decisions, even though each would disappear from the proposed file.
The duplicate remains accessible for its existing purpose. The retired address retains its redirect. The search page remains intentionally excluded from indexing. The missing guide needs an owner to decide whether to restore the intended page or retire the address appropriately.
That last row is the important exception to a mechanical cleanup. Removing a broken URL from a file may make the file tidier while leaving an intended article unavailable. Put the missing-content issue in the handoff rather than marking the whole review complete.
For the intentionally excluded search page, keep the indexing control distinct from the sitemap decision. Google's noindex documentation explains that Googlebot must be able to access the page to see its noindex rule. Removing an address from the sitemap is not an instruction to remove it from search.
Use update dates that reflect real changes
Tie the modification date to a meaningful change to the page.
An XML sitemap can include lastmod, the page's last-modification date. Tie it to the page's actual update history rather than the time the sitemap generator ran.
Google's XML sitemap notes say it uses lastmod when the value is consistently and verifiably accurate. The value should reflect the last significant update. Changes to the main content, structured data, or links can qualify; a copyright-date change doesn't. Google ignores priority and changefreq values.
For the fictional desk guide, imagine these two events:
- The editor corrects a measurement explanation and replaces an obsolete source. Record that content revision as a candidate for the significant-update date.
- The site rebuilds the following morning, while the guide stays the same. Don't substitute the rebuild time for the guide's revision date.
Have the person maintaining the generator identify where its date comes from. A content-revision field and a file-deployment timestamp describe different events. If the available field can't represent the intended update, fix the mapping or leave the optional value out until you can support it.
Keep the page's visible publication date separate from this record. A later edit doesn't mean the article was first published again.
Check the sitemap file and the listed pages separately
Once the URL choices are settled, have the site owner or developer validate the generated file and confirm that the published address returns the intended sitemap.
You can submit its URL through Search Console. Google's sitemap-building instructions also describe declaring the sitemap location in robots.txt. Work with the site's existing generator and submission method before adding a second competing file.
In Search Console, a successful sitemap read answers a narrower question than whether the pages are indexed. The Sitemaps report documentation defines Success as a file fetched and read without errors. Discovered pages counts the page URLs parsed from it, not a promise that those pages were crawled or indexed.
Use the Page indexing report's sitemap filter to examine indexing separately. For a specific missing page, follow the evidence in our indexing diagnosis guide.
An empty list in the Sitemaps report also needs interpretation. Google says the report lists sitemaps submitted through that report or the Search Console API; files found through other discovery methods might not appear there. Confirm the property and exact sitemap URL before concluding that no file exists.
Leave a decision record the next editor can use
A useful handoff should say what belongs in the file, what needs work elsewhere, and how completion will be checked. For the hypothetical retailer, it could read:
Ready to list: The clean desk-selection guide URL.
Keep out of this file: The reviewed duplicate, retired address, and intentionally excluded search page.
Unresolved: The dimensions guide returns an unexpected 404. The editor must confirm its intended destination; the site operator must verify the resulting response.
Date mapping: Use the recorded significant content revision, not the next build timestamp.
Completion check: Compare the regenerated file with these decisions, inspect the affected URLs again, and review sitemap processing separately from page indexing.
Before signing off, check an included URL, a duplicate, a retired address, and any unresolved page. Save the observations with the review date and the actual person responsible for each follow-up.
The goal is a file that agrees with the site you intend to publish. Keep a missing page marked as missing until its own issue is resolved, and keep an indexing question open until you have indexing evidence.
For help with SEO and AI search visibility, try HoneyWeRank.