Choose Two Snapshots That Answer the Same Question
First decide what you want to compare. An old-versus-new snapshot reveals publishing or configuration changes. A staging-versus-production comparison reveals release differences, provided both environments are represented by suitable URL lists. Comparing unrelated websites may highlight topic coverage, but exact URL matches are rarely useful across different domains.
Save the original sitemap before editing plugins, changing permalinks, deploying a redesign, or moving domains. Save the second version after the change. Give each snapshot a clear date and environment label. If the site updates while you are collecting files, you may see differences caused by ordinary publishing rather than the change you are auditing.
Use the Sitemap Comparison Tool with the two input formats actually available in its interface. If it accepts sitemap addresses, check that both are publicly accessible. If it accepts XML text or files, provide complete copies rather than excerpts. Input and download options depend on the installed plugin version and should be confirmed in the live interface.
Understand Added, Removed, and Unchanged URLs
A basic URL comparison treats each sitemap as a set of page addresses. The first snapshot is the baseline; the second is the newer version. Comparing membership gives three useful groups:
A large removed count is not automatically a technical failure. For example, a site may intentionally remove thin tag archives or replace outdated product pages. Review the affected URLs by importance and expected behavior before deciding whether anything needs fixing.
A Small Sitemap Difference You Can Check Manually
Imagine a website with three URLs in the original snapshot and three in its updated snapshot. The example below uses fictional URLs; no website was crawled to produce these results.
Both snapshots contain three URLs, yet their contents differ. That is why comparing sitemap totals alone is inadequate. A matching URL count can conceal a missing page and an unexpected replacement.
Exact URL Differences Can Look Like Content Changes
Many tools match complete URL strings. Under exact matching, https://example.com/about and https://example.com/about/ are different entries. So are HTTP and HTTPS addresses, different hostnames, case changes in paths, and some query-string variations. A comparison may therefore show an old URL as removed and its reformatted version as added even when the content is essentially the same.
This matters most during domain and permalink migrations. If every address changes from old.example to new.example, an exact comparison can report nearly everything as removed and added. You then need an explicit old-to-new URL mapping or a deliberately normalized path comparison. Do not automatically strip query parameters or trailing slashes: those distinctions can be meaningful on a particular site.
For migration planning, use a website migration URL mapper to assess old and new destinations rather than assuming similar paths always lead to equivalent content.
Check Whether the Inputs Are Sitemap Indexes
A regular XML sitemap uses a <urlset> root and lists individual page locations in <url> entries. A sitemap index uses <sitemapindex> and lists child sitemap files instead. Comparing two index documents without expanding their children compares sitemap file references, not the page URLs inside them.
Some comparison services fetch every child sitemap, while others only accept a single URL sitemap. The registered shortcode alone does not establish which behavior this tool implements. Check its supported input type. If it does not expand an index, compare corresponding child sitemaps or extract their page URLs with a sitemap URL extractor.
The Sitemap protocol permits up to 50,000 URLs and 50 MB uncompressed per sitemap file. Larger websites commonly split their coverage across multiple files. Be alert to tool-specific fetch or file-size limits: a partial comparison can make valid pages appear missing when not all input files were processed.
Why Removed URLs Need a Decision, Not an Automatic Redirect
Work through removed URLs in this order. Was the page intentionally deleted? Was it replaced by a relevant equivalent? Is it still live and indexable but missing due to a plugin setting? Has its canonical URL changed? Each answer calls for a different action.
- Accidentally excluded: restore the correct sitemap inclusion rule and regenerate the file.
- Moved or renamed: check the old-to-new mapping and use an appropriate permanent redirect when the content has moved.
- Intentionally retired: remove obsolete references; an honest 404 or 410 response may be appropriate where no replacement exists.
- Still accessible but noncanonical: review the preferred canonical and list that preferred version in the sitemap.
Never redirect every removed address to the homepage merely to clear the comparison report. A redirect should take visitors to a genuinely relevant destination. Follow up on moved URLs with a bulk HTTP status and redirect checker; a sitemap diff does not test response codes.
When Last-Modified Dates Change but URLs Do Not
The optional <lastmod> element can show when a page was last significantly updated. If a comparison reports changed dates, investigate whether the content, structured data, or meaningful links actually changed. A plugin that rewrites every date on every regeneration may produce noisy signals rather than reliable update information.
Not every comparison implementation checks metadata fields. Even when one does, a changed <lastmod> is not evidence that Google recrawled or indexed the page. Google says it uses the value when it is consistently accurate. Focus on trustworthy publication data, not making every page look freshly edited.
WordPress Changes That Commonly Alter Sitemap Coverage
In WordPress, changes to SEO plugin settings, public custom post types, taxonomy archives, post visibility, or canonical URL patterns can alter sitemap contents. A redesign may also introduce staging links or accidentally exclude an entire category. Compare the sitemap before and after each significant change, then inspect the directories with the largest unexpected differences.
For example, if dozens of articles disappear at once, check whether the posts were moved to draft, marked noindex, redirected, or excluded by a sitemap setting. If category pages appear unexpectedly, review whether they should be indexable. A sitemap validator can help assess XML formatting separately from the content comparison.
Confirm the Outcome Beyond the Difference Report
After reviewing changes, test representative high-value URLs for access, canonical selection, and indexability. Confirm that internal links point to the preferred addresses. Regenerate the sitemap from its real source when corrections are necessary, rather than manually editing a temporary export that WordPress will overwrite.
Finally, review the submitted sitemap in Google Search Console and investigate relevant indexing reports. Being listed in a sitemap does not guarantee crawling, indexation, or ranking. Likewise, being absent from one sitemap does not mean Google immediately removes a page from search. Use the comparison as a change-control record, not as a standalone search performance verdict.
Questions to Resolve Before Closing an Audit
Can two sitemaps have the same number of URLs and still be different?
Yes. One URL can disappear while another is added, leaving the total unchanged. Compare the actual addresses, not only the counts.
Does a sitemap comparison verify that a removed page returns 404?
No. URL membership and HTTP response testing are separate operations. Check the actual page or use a redirect and status checker.
Should I compare sitemap indexes directly?
Only if you want to compare child sitemap references, or if the chosen comparison tool explicitly expands those indexes into their page URLs. Otherwise compare the child URL inventories.
