XML Sitemap Best Practices (and What Silently Breaks Them)

XML sitemap best practices come down to one rule: the sitemap should list the canonical, indexable URLs you want search engines to find, and nothing else. A clean sitemap helps Google discover and recrawl important pages. A careless one sends it redirects, 404s and URLs you never meant to be indexed, which makes the whole file a weaker signal.

The rules themselves are simple. The harder part is that sitemaps are produced by software, and a plugin update or deploy can make a correct sitemap wrong without anyone noticing.

What a sitemap is for, and what it is not

A sitemap is a discovery aid. It helps search engines find pages, especially on large sites, new sites, and pages with few internal links. It is not a ranking factor, and listing a URL does not make Google index it.

A minimal file looks like this:

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

That is almost everything Google reads. Google has said it ignores <priority> and <changefreq>, and uses <lastmod> only when it is consistently accurate. Spending time tuning priority values achieves nothing for Google.

The practices worth enforcing

Include only URLs that return 200, are canonical to themselves, and carry no noindex. If a page should not be indexed, it should not be in the sitemap. Redirecting URLs and 404s are the most common pollutants, and they usually appear after content is moved or deleted while the generator keeps an old list.

Use absolute URLs on the same protocol and host as the sitemap. A sitemap at https://www.example.com/ should not list http://example.com/ URLs. The file must be UTF-8, and characters such as & in URLs need to be escaped as &.

Keep lastmod honest. It should change when the page's main content changes, not on every rebuild. If a platform stamps today's date on every URL each night, the value tells Google nothing and it will learn to disregard it.

Respect the limits. One sitemap file can hold up to 50,000 URLs and 50MB uncompressed. Larger sites split URLs across several files, often by content type, and list them in a sitemap index. Splitting by type also makes problems easier to locate, because you can see which child sitemap lost URLs. Files can be gzipped, but the 50MB limit applies to the uncompressed size.

Make it discoverable. Add a Sitemap: https://example.com/sitemap_index.xml line to robots.txt, and submit the sitemap in Search Console's Sitemaps report and in Bing Webmaster Tools. Google retired its sitemap "ping" endpoint in 2023, so submission and the robots.txt line are the routes that remain. Our guide on how to check your robots.txt covers the rest of that file.

Who generates the file

Knowing the generator tells you what can change it. Since WordPress 5.5, core outputs a basic sitemap at /wp-sitemap.xml. Yoast SEO and Rank Math disable that and serve their own at /sitemap_index.xml, controlled by per-content-type settings, so switching a type off in the plugin removes all of its URLs at once. Shopify generates /sitemap.xml automatically and does not let you edit it directly. Headless and static sites usually build it at deploy time, which means a build configuration change can alter it.

Ways a valid sitemap goes wrong

Problem	Typical trigger	How it shows up
Unwanted URLs listed	Plugin starts including tag archives, attachment pages or noindex pages	Page indexing report fills with excluded URLs from the sitemap
Real URLs missing	Generator reset during a deploy or migration, content type toggled off	Discovered URL count drops in the Sitemaps report
Meaningless lastmod	Every URL restamped on each build	All entries share the same recent date
Old sitemap still referenced	Sitemap path changed, robots.txt not updated	Search Console reports a fetch error or a stale file
Cached file	CDN or caching plugin serving an old version	Sitemap does not reflect pages published days ago

None of these produce an error on the site. The XML still parses, and the difference only appears if someone compares the file with how it looked before.

Why agencies miss these changes

On one site you control, you might notice eventually. On twenty client sites where other developers deploy, there is rarely a reason to open a sitemap on a normal Tuesday. The person updating a plugin or merging a release is not thinking about the sitemap, so any breakage is a side effect. The first visible sign tends to be slower indexing of new pages, or pages dropping out, weeks later.

Checking by hand, and monitoring the rest

A manual check is straightforward: open the file, note the URL count per child sitemap, spot-check a sample of URLs for status code, canonical and noindex, and confirm the robots.txt line. It works well on sites you remember to check.

For the others, Deltio reads each client site's sitemap on a daily cycle and compares it with the previous check, alerting when URLs are added or removed. It also checks the pages those URLs point to for noindex, canonicals and title changes, and watches robots.txt, because a sitemap rarely changes in isolation. Alerts go to Slack and email per site, naming the site and the affected URLs. It is a daily check, so a change is reported on the next cycle rather than the moment it happens. The format of those notifications is covered in SEO change alerts.

You can add a client site on a 14-day trial to see what its sitemap contains today.