changefreq and priority across 24 sitemaps: 17 send neither, and four of the rest send one value

FIELD TEST · 2026-09-09 · 30 domains · 24 with a readable sitemap · one pass

Sample and method: 30 domains were each requested once on 2026-09-09 with a desktop Chrome user agent and no JavaScript executed. For every domain we read robots.txt, took the first Sitemap: line it declared, and fell back to /sitemap.xml when it declared none. Where that file turned out to be a sitemap index, we read its first three child sitemaps in document order. Twenty-four domains returned parseable <url> entries and six returned none, for 168,434 entries in total.

Seven of those 24 sitemaps still carry changefreq, six carry priority, and 17 carry neither. Google and Bing have each published a flat sentence saying they ignore both fields. The part worth reading is what the seven actually put in there: on four of them one value covers 97% or more of the file, so the field separates nothing at all — before any engine gets to decide whether to look at it.

How we measured this

One pass, from outside, with no account anywhere. The path is the one a crawler would take: robots.txt first, /sitemap.xml as the fallback, then whatever those files point at. Nothing here needs Search Console access, so you can run it against a competitor as easily as against yourself.

# The whole measurement for one domain
curl -s https://example.com/robots.txt | grep -i '^sitemap:'

curl -s https://example.com/sitemap.xml \
  | grep -c '<changefreq>'

curl -s https://example.com/sitemap.xml \
  | grep -oE '<priority>[^<]+' | sort | uniq -c | sort -rn

Three limits, and the middle one decides how the per-site numbers below can be read. Six domains gave us nothing to parse: github.com answered 406 to our client, mozilla.org and stackoverflow.com and news.ycombinator.com answered 404, wikipedia.org answered 403 on the URL its own robots.txt names, and reddit.com served an HTML page at /sitemap.xml. For the 15 domains whose entry point was a sitemap index we read three children out of as many as 27,845, so those entry counts are a slice rather than a census — a site could use changefreq in a child sitemap we never opened. Nine domains were a single complete file, and for those the counts are the whole thing.

The third limit is the one we cannot fix by fetching more. We can see the value in the file. We cannot see who chose it, and on most of these sites the honest guess is that nobody did — the value arrived with a plugin default. That distinction matters for the advice at the end, and the measurement does not reach it.

What Google and Bing say about changefreq and priority

Both have written it down, in one sentence each, on pages meant for site owners. Google's sitemap documentation puts it without qualification: "Google ignores <priority> and <changefreq> values" (Build and submit a sitemap, read 2026-09-09). Bing's webmaster blog says the same thing about itself: "Optional sitemap tags like changefreq and priority are ignored by Bing and do not influence how your content is crawled or ranked" (Keeping content discoverable with sitemaps in AI-powered search, published 2025-07-31, read 2026-09-09).

Neither page explains why, and we are not going to fill that in for them. What both do instead is point at the field next door. Bing's wording: "The lastmod field in your sitemap remains a key signal, helping Bing prioritize URLs for recrawling and reindexing, or skip them entirely if the content hasn't changed since the last crawl." Google's condition on the same field is that it uses lastmod "if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate."

The sitemap protocol itself was never as confident about priority as the people filling it in. It defines the value as "the priority of this URL relative to other URLs on your site", sets the default at 0.5, and adds a warning that has been sitting there since 2005: "Assigning a high priority to all of the URLs on your site is not likely to help you. Since the priority is relative, it is only used to select between URLs on your site" (sitemaps.org protocol, read 2026-09-09).

A field that carries the same value on every URL carries no information, whatever the engine decides to do with it.

Seventeen of 24 sitemaps carry neither field

Most of this panel has already stopped. The two fields travel together almost perfectly — only substack.com sends one without the other.

The 17 include every developer platform on the panel except two, all four news sites we could read, and both of the largest files: framer.com ships 31,084 entries and webflow.com 72,559 across the children we read, and neither carries a single changefreq. By entry count the split is wider than by site: 15,836 of 168,434 entries have a changefreq, which is 9%.

Sixteen of the 24 do send lastmod, the one field both engines say they use. That is twice the adoption of the fields they ignore, and it is the shape you would want. Whether those dates say anything true is a separate measurement, and it did not go well: we read sitemap lastmod across 24 sites three weeks earlier and 13 of them stamped every URL with the same date.

The seven that do send it put one value on almost every URL

Here is the whole set, and the pattern is hard to miss once the counts are next to each other. Four files are effectively single-valued, and a fifth is close.

Medium and Shopify are unanimous: every entry we read from Medium says monthly, every entry from Shopify says daily, and those two files disagree with each other by a factor of thirty about how often a page changes. Ars Technica sends weekly on 2,000 of 2,001 entries and priority 0.3 on the same 2,000. Three of the seven set exactly one URL to priority 1.0, which is the homepage getting its badge and every other page being told it is worth the same as every other page.

Medium is the exception, and it is the one the protocol warned about. It spreads priority across five values but puts 1.0 on 1,055 of the 5,182 entries we read — one URL in five at maximum importance, on a site with tens of thousands of sitemap files. Relative to what, is the question the field is asking, and 1,055 URLs is not an answer to it.

Across all 168,434 entries the vocabulary in use is five words wide, and two of the seven legal values never appear at all.

One entry in 168,434 says always, on Ars Technica. Nothing on this panel says hourly or never — including the news sites, whose front sections change several times an hour and whose archives will not change again.

What this changes for you today

Open your own sitemap and count. If changefreq is in there, the question is not whether it is accurate; it is whether the generator that put it there is also handling the field that gets read.

• Spend the effort on lastmod instead, and make it a real modification time rather than a build time — that is the field both engines describe as an input
• Leave changefreq and priority in place if removing them means editing a plugin you do not control; they cost bytes and nothing else
• Do not set priority 1.0 on a group of pages, because the protocol says the value is only ever compared within your own site
• Do not read a competitor's changefreq as intelligence about their publishing schedule — Shopify says daily on a page that has not moved in months

If you are deciding what belongs in the file in the first place rather than auditing one that exists, the four per-URL fields and which two get read are worked through in how to create a sitemap. And if the underlying worry is that pages are missing from search rather than mislabelled inside the sitemap, the sitemap is the wrong end to start from; that is what the gap diagnosis is for.

Common questions

How did you measure this?

One request per domain on 2026-09-09, desktop Chrome user agent, no JavaScript. robots.txt first for a declared Sitemap: line, /sitemap.xml as fallback, and the first three child sitemaps when the entry point was an index. Twenty-four of 30 domains returned parseable entries, 168,434 of them. The commands in the method section reproduce the counts for any single domain.

Does changefreq do anything at all?

Not at Google and not at Bing, on their own published statements. What other crawlers do with it is not something we tested, and most of them publish nothing about their sitemap handling, so we have no basis for an answer either way.

Should I remove changefreq and priority from my sitemap?

Only if it is free. Two ignored elements per URL cost a few bytes and no crawl budget worth naming, so a sitemap generator you cannot configure is not a problem to solve. Removing them by hand from a file that regenerates on every deploy is work you will do twice.

Why do so many sites still send them?

We do not know, and the file cannot tell us. The distribution points at generator defaults rather than decisions — a single value across an entire file is what a template produces, not what an editor produces — but we cannot see the settings screen behind any of these sites, so that stays a reading rather than a finding.

Which sitemap field should I actually get right?

lastmod, and only if you can make it truthful. Google's condition is that the value is "consistently and verifiably accurate", which rules out stamping the whole file with the deploy time. Sixteen of the 24 sites here send lastmod; the earlier survey found that most of the ones who send it are stamping rather than reporting.