How to Monitor Sitemap Changes Automatically

To monitor sitemap changes, save a copy of the sitemap's URL list on a fixed schedule and compare each copy with the previous one. The differences worth acting on are URLs that appear, URLs that disappear, and lastmod dates that move in bulk.

A sitemap is the one file where a CMS lists, in plain text, the pages it thinks should exist. When a migration or a plugin change removes a section, the sitemap reflects it the same day, while rankings can take weeks to show anything. Most teams check it at launch and never open it again.

Reading a sitemap diff

Each type of change has a common harmless explanation and a failure you need to rule out.

Change	Often harmless because	Rule out
URLs added	New posts or products were published	Tag archives, filter parameters, attachment pages or staging URLs being generated
URLs removed	Content was deliberately deleted or merged	Pages unpublished by mistake, set to noindex, or lost in a migration
lastmod changed on a few URLs	Those pages were edited	Usually nothing
lastmod changed on every URL	Rarely a real edit	A deploy or cache rebuild rewriting timestamps

Removed URLs deserve the closest attention. Google keeps a page indexed for some time after it leaves the sitemap, so traffic won't warn you. Additions matter most on ecommerce sites, where an update that switches on attribute or filter pages can add a large batch of thin URLs overnight.

Bulk lastmod changes are less urgent but still worth fixing. Google's sitemap documentation says it uses lastmod only when the value is consistently and verifiably accurate, so a sitemap that stamps today's date on everything teaches Google to ignore the field. Writing the file correctly is covered in XML sitemap best practices.

A manual diff you can run today

For a single flat sitemap:

curl -s https://example.com/sitemap.xml \
  | grep -o '<loc>[^<]*' | cut -c6- | sort > today.txt
comm -3 yesterday.txt today.txt

comm -3 prints URLs found only in yesterday's file in the first column and URLs found only in today's file, indented, in the second. That's easier to scan than diff output.

Most real sites serve a sitemap index instead. Yoast serves /sitemap_index.xml, which points to post-sitemap.xml, page-sitemap.xml and similar files. WordPress core without an SEO plugin serves /wp-sitemap.xml. Shopify's /sitemap.xml is an index of child sitemaps for products, collections, pages and blogs. Run the one-liner on any of those and you get a list of child sitemaps, not pages. A short loop fixes that:

curl -s https://example.com/sitemap_index.xml \
  | grep -o '<loc>[^<]*' | cut -c6- \
  | while read child; do
      curl -s "$child" | grep -o '<loc>[^<]*' | cut -c6-
    done | sort -u > today.txt

Two caveats. Gzipped sitemaps (.xml.gz) need gunzip -c in the pipe, and a <loc> wrapped in CDATA or split across lines will slip past grep, so a proper XML parser is safer if you keep the script long term. If you don't know where a site's sitemap lives, the Sitemap: line in its robots.txt usually says.

Where the script stops being enough

Scheduling is the first weak point. A cron job on a laptop stops when the lid closes, and one script per client site is one more thing nobody maintains.

Search Console won't cover the gap. Its Sitemaps report shows each submitted file's status ("Success", "Has errors" or "Couldn't fetch") and a count of discovered pages, but it doesn't list which URLs went missing and it sends no notification when that count falls. Filtering the Page indexing report by sitemap shows the indexing status of the URLs a file contains, which is helpful for diagnosis once you already know something is wrong.

The last gap is that a URL list says nothing about the pages behind it. /pricing/ can still be in the sitemap after the same deploy removed its title or added a noindex.

Automating it with Deltio

Deltio checks each site's sitemap on a daily cycle and compares it with the previous check. When URLs are added or removed, it sends an alert to Slack and email for that site listing the URLs involved, rather than a net count. On the same cycle it checks the pages for noindex, canonical, title, meta description and H1 changes, so a sitemap change and a page-level regression from the same release arrive together. It pairs with SEO change alerts and the wider job of monitoring client websites for changes.

A daily cycle has a blind spot: a sitemap that breaks and recovers within a few hours may never show up. For most sites that trade-off is fine, and on a launch day you can run the script above alongside it. The 14-day free trial gives you two weeks of diffs on the client site you worry about most.