A WordPress site has 3,000 URLs in its sitemap. Every one declares <priority>0.5</priority>, <changefreq>weekly</changefreq>, and a lastmod that's the build timestamp of the most recent deploy. Google's crawler reads it, recognizes the pattern, and effectively ignores all three.
The plugin author wrote it that way because the CMS doesn't know which pages are important and which aren't. The site owner never overrode the defaults. The result: Google falls back to its own crawl-priority heuristics, ignoring what the sitemap could have told it.
Meanwhile, a competing site declares <priority>1.0</priority> for the homepage, <priority>0.8</priority> for top categories, <priority>0.3</priority> for archive pages, and uses real lastmod values pulled from each page's actual modification time. Google reads it and trusts it. Crawl budget allocates accordingly.
The first site is leaving signal on the floor. The second is using the protocol the way it was designed.
What the XML Sitemap Priority Sanity does
You paste a sitemap URL. The tool:
- Fetches the sitemap, parses up to 200
<url>entries. - Analyzes priority distribution — flags uniform-everything (all 0.5).
- Analyzes changefreq distribution — flags boilerplate (all weekly or all monthly).
- Checks lastmod presence and validity — flags future dates, all-identical-timestamps.
- Spot-checks 10 random URLs by fetching them and comparing sitemap lastmod to actual
Last-ModifiedHTTP headers — flags >30-day mismatches. - Emits an AI prompt with concrete priority/changefreq strategy by URL type.
Why uniform signals get ignored
Google's official position (as articulated by John Mueller and the Google Search docs): when sitemap signals are uniform across the whole sitemap, they're treated as default values and ignored. The signal only carries weight when it varies.
Same logic for changefreq: if every URL says weekly, Google has no reason to believe any specific page actually updates weekly. It falls back to observed crawl history.
Same for lastmod: if every URL declares the same lastmod (typically the build timestamp), Google catches the pattern within a few crawls and stops trusting lastmod.
The four sitemap-signal anti-patterns
1. priority=0.5 for everything. The tell-tale CMS default. Google ignores. Fix: differentiate by content type.
2. changefreq=weekly for everything. Same problem. Fix: match changefreq to actual update cadence.
3. lastmod = build timestamp. Sitemap regenerates on every deploy and sets lastmod to "now" for every URL whether the URL changed or not. Google catches this on the second deploy, ignores from then on. Fix: derive lastmod from actual page modification (filesystem mtime, CMS publish/update timestamp, or Git history).
4. lastmod in the future. Common bug from timezone misconfiguration or CMS plugins that add a buffer. GSC flags it as a sitemap error. Fix: clamp to current time.
What good signals look like
A meaningful priority distribution for a typical SMB site:
- 1.0 — homepage only
- 0.8 — top-level categories, primary service pages
- 0.6 — products, location pages, evergreen guides
- 0.4 — blog posts, secondary content
- 0.3 — paginated archives, tag pages
- 0.1 — legal pages, footer-link pages
Meaningful changefreq:
- daily — homepage, blog index
- weekly — recent blog posts
- monthly — products, categories, location pages
- yearly — evergreen guides, legal, about
Meaningful lastmod:
- pulled from actual page modification — never the build timestamp
- updated only when the page's content actually changes (not on every deploy)
- stays stable for evergreen content even after re-deploy
The 14-day sitemap-rebuild path
Day 1-3: Run the audit on your current sitemap. Note which anti-patterns apply.
Day 4-7: Update your sitemap-generator (CMS plugin, build script, or framework helper) to derive priority/changefreq from URL pattern + content type. Pull lastmod from actual file mtime or CMS published-date field.
Day 8-10: Consider splitting one big sitemap into per-type sitemaps (sitemap-pages.xml, sitemap-blog.xml, sitemap-products.xml). Each can have a coherent freshness profile.
Day 11-14: Re-submit to GSC. Watch the Coverage report — sitemap-driven URL discovery typically improves within 7-14 days.
What this audit can't catch
Google's actual sitemap-handling is opaque. The tool catches the patterns Google has explicitly documented as ignored. There may be subtler ones it weighs that aren't measurable from outside.
The lastmod truthfulness check uses the live Last-Modified HTTP header, which CDNs sometimes overwrite with their own cache timestamp. A mismatch from this audit is a strong signal but not always actionable — verify by checking the page directly without CDN.
Related reading
- Sitemap Audit — sister tool focused on structural sitemap validity
- Index Coverage Delta — compares sitemap to live crawl
- Web Log Anomaly Detector — pairs with this for crawl-side visibility
- Mega SEO Analyzer — full SEO sweep including sitemap signals
Fact-check notes and sources
- Sitemap protocol spec: sitemaps.org — defines priority, changefreq, lastmod
- Google sitemap guidelines: Google Search Central — Sitemaps
- Priority "ignored when uniform" guidance: paraphrased from John Mueller commentary 2018-2024 on Google office hours
- Lastmod truthfulness signal: Google Search Central — Build and submit sitemap — explicit statement that lastmod is "ignored when not trustworthy"
This post is informational, not technical-SEO consulting advice. Mention of Google is nominative fair use. No affiliation is implied.
