changefreq and priority: Google Actually Ignores Them
Sitemap optimization checklists still commonly advise "carefully fill in changefreq and priority on every <url>." But while both tags are still formally part of the sitemap protocol (sitemaps.org) spec, they are not signals Google actually uses to determine crawl priority. This guide covers why that happened, and how the Sitemap Validator treats these tags.
1. What changefreq and priority were originally meant to do
In the sitemap protocol's original design (around 2005, jointly established by Google, Yahoo, and Microsoft), <changefreq> was meant to tell search engines "how often this page changes" (always/hourly/daily/weekly/monthly/yearly/never), and <priority> was meant to convey "this URL's relative importance compared to other URLs on the same site" (0.0–1.0). The idea itself was reasonable — there's no need to recrawl a news page that updates daily and an about-us page that updates once a year at the same frequency.
2. Why it became a signal you can't trust
The problem was that site operators entered these values themselves. In practice, nearly every site inflated the numbers — marking its own important pages priority 1.0 and giving everything else at least 0.8 or higher. changefreq saw the same pattern: sites routinely set it to daily as a matter of habit, regardless of actual update frequency. Once self-reported data across the board converges on "I'm important and I change constantly," it loses all value as a signal for telling relative priority apart. Google has publicly stated, since around 2014, that it doesn't meaningfully factor these two values into crawl priority calculations, and has reaffirmed that position multiple times since.
3. So what does Google actually use to set crawl priority?
The signals Google actually references aren't changefreq or priority — they're things like the following.
- Accuracy of lastmod: A
<lastmod>value that genuinely matches the actual content modification time is practically used to judge recrawl timing. Manipulating it — for instance, resetting it to today's date every time — actually erodes its credibility instead. - Internal link structure: How many places within the site link to a page carries far more weight in determining actual importance.
- The page's own popularity and traffic signals: Real visit and search-impression data is a far more trustworthy signal than a self-reported number.
4. Does that mean you can be sloppy about your sitemap?
No. While changefreq and priority get ignored, the sitemap's own structural constraints remain very much in effect. The two most important ones are these.
| Constraint | Limit | If exceeded |
|---|---|---|
| URL count | Max 50,000 per file | Must be split using a sitemap index (<sitemapindex>) |
| File size | Under 50MB uncompressed | Must be split into multiple files bundled under an index |
For example, an e-commerce site with 120,000 product pages can't fit them all into a single sitemap.xml — it needs to split them across at least three files, with a sitemap-index.xml bundling them together, and only that single index file gets submitted to Search Console. Unlike self-reported values, this is a verifiable hard limit — if it isn't respected, parsing itself can fail or some URLs can be dropped entirely.
5. How modoohub's Sitemap Validator reflects this
If you look at the code behind the Sitemap Validator, the parseSitemap() function inside sitemap-validator.html only raises an actual error-level issue (errOver50k) when total>50000. In contrast, changefreq and priority values are simply displayed in the URL list table — there's no logic that scores their appropriateness or issues a warning about them. Instead, the FAQ section explicitly addresses "Do changefreq and priority actually help?" with: "Google ignores changefreq and priority, or treats them at best as a hint. Crawl frequency is decided by Google itself. An accurate lastmod matters more." In other words, the tool's own design reflects the principle that only format validity is checked, and what actually matters is lastmod and the URL count limit.
6. Practical priorities when working on a sitemap
- Keep lastmod accurate and aligned with real modification dates (don't arbitrarily stamp today's date).
- Include only canonical URLs — exclude noindex or redirected URLs.
- Split into an index file once you exceed 50,000 URLs or 50MB.
- changefreq and priority aren't a spec violation, so it's fine to include them — but don't waste time fine-tuning their values.
Frequently Asked Questions
Q. Is it fine to leave out changefreq and priority entirely?
A. Yes. Both tags are optional in the sitemap protocol. Since Google doesn't factor them into crawl priority, omitting them costs you nothing SEO-wise.
Q. Do other search engines, like Bing, also ignore these values?
A. Policies vary by search engine, so it's hard to make a blanket statement, but since Google holds by far the largest market share, it's practically reasonable to set your priorities based on Google's stance.
Q. Does lastmod actually matter?
A. Yes. A lastmod value that accurately matches the real content modification time is known to be a signal Google references when deciding when to recrawl a page. That said, setting it to the latest date unconditionally doesn't automatically help — overusing it regardless of actual changes can erode its credibility instead.
Q. Does having more than 50,000 URLs block sitemap submission outright?
A. If a single file exceeds the limit, parsing can fail or the excess entries can be ignored. In that case, split the URLs across multiple sitemap files, bundle them under one sitemapindex file, and submit only that index file to Search Console.