Do Sitemap Priority and Changefreq Tags Actually Matter to Google?

The XML sitemap protocol defines four fields per URL: loc, lastmod, changefreq, and priority. Google's own current sitemap documentation states plainly that it ignores priority and changefreq, and uses lastmod only when a site's history shows the value is consistently and verifiably accurate. Two of the four fields in a format built specifically for search engines are, by the leading search engine's own admission, not used at all.

Where the Sitemap Protocol Came From

Google introduced the original Sitemap protocol in 2005 as a way for site owners to explicitly list URLs for crawling, rather than relying entirely on discovery through links. In November 2006, Yahoo and Microsoft agreed to support the same format, and the three companies jointly established sitemaps.org to host the shared specification going forward (Ask joined in 2007). That joint origin is why the protocol still defines priority and changefreq: they were designed to give any participating search engine a hint about relative importance and expected update frequency across a site's own multiple crawlers, not built around how any one engine's ranking system actually works today.

What Google's Own Documentation Actually Says

Google's current "Build and Submit a Sitemap" documentation states that Google ignores the priority and changefreq values in a sitemap. It uses the lastmod value, but only if it's consistently and verifiably accurate, meaning Google checks it against evidence of an actual change to the page rather than trusting the timestamp at face value. This isn't a fringe reading of ambiguous guidance. It's the documentation's own stated behavior, and Google's Search team has reiterated the same point publicly on multiple occasions over the years: these fields were so widely misused (most sites simply mark every page priority 1.0, and changefreq values are typically guessed rather than measured) that neither one carries any real signal.

Why the Signal Broke

The mechanism behind why these fields stopped being useful is straightforward: a signal is only worth using if it discriminates between things. If nearly every sitemap marks its homepage, and often every other page too, as priority: 1.0, the field no longer separates important pages from unimportant ones. changefreq has the same problem from a different angle: it asks a site owner to predict how often a page will change, but most CMS platforms and static-site generators either hardcode a single value across every URL or set it based on a template default rather than actual edit history. A field that's rarely grounded in real behavior gives a crawler nothing reliable to act on, so ignoring it is the more defensible engineering choice, not an oversight.

Where This Leaves lastmod

lastmod survives specifically because it's checkable against real evidence: Google can compare a sitemap's claimed last-modified date against what it actually observes when it fetches the page (updated main content, changed structured data, or new links, for example). Google's own documentation notes that a change to something like a copyright-year footer isn't the kind of significant update that should trigger a new lastmod value. A sitemap generator that stamps every URL with the current date on every deploy, regardless of whether the page's actual content changed, produces a lastmod field that fails Google's own accuracy check, and the documentation implies Google can and does stop trusting a lastmod field once it's proven unreliable for a given site.

What About Bing?

Google isn't the only search engine that has said this in public. Bing's Webmaster Blog published its own study of sitemap quality on February 1, 2023, based on a crawl of sitemaps across its index. The headline numbers: 58% of hosts Bing crawled had at least one known XML sitemap, and of those, 84% included a lastmod attribute. Of the sitemaps that did set lastmod, Bing found 79% held accurate values, 18% were wrong, and the rest were only partially set. The most common error Bing identified was a lastmod date stamped to whenever the sitemap file itself was generated, rather than to when the page's actual content last changed, the same failure mode Google's documentation describes.

Bing's response was to revamp its own crawl scheduling system specifically to lean more heavily on lastmod where a site's history shows it's trustworthy, with a full rollout targeted for June 2023. On changefreq and priority, Bing's stated position is blunter than Google's: the blog states plainly that the majority of changefreq and priority tags in sitemaps are not set correctly, and that Bing largely disregards both fields as a result. Two independently operated search engines landed on the same conclusion about the same two fields, for the same underlying reason: neither field discriminates between pages when nearly every sitemap sets them to the same values by default.

A Quick Way to Audit Your Own Sitemap

Three checks catch most of the actual problem, without needing any special tooling beyond viewing the raw sitemap file:

• Open the sitemap and scan the priority values. If every URL carries the same value, or the values roughly mirror how deeply nested the URL is rather than anything about the page's real importance, the field was almost certainly set by a template default, not a deliberate decision, and removing it changes nothing either way.
• Compare lastmod timestamps against actual deploy history. A static-site generator or CMS that regenerates the whole sitemap on every deploy will often stamp every URL with that deploy's date, even for pages whose content didn't change. That pattern is exactly what Google's documentation describes as unverifiable, and it's a common, usually unintentional, default in a lot of site tooling.
• Check whether changefreq was ever based on real edit history. Most implementations hardcode it (weekly for blog posts, monthly for static pages) rather than deriving it from how often a URL is actually edited. Since Google ignores the field regardless, this isn't worth fixing for its own sake, but it's a useful sign of how much of a sitemap's content reflects real signals versus generator defaults.

None of this requires ripping fields out of a sitemap generator that already produces them. It's simply not worth spending further time tuning priority or changefreq values, and worth spending a little time making sure lastmod, the one field with any actual weight, reflects genuine changes rather than a build timestamp.

Generating an Accurate lastmod Value From Common Stacks

The audit above tells you whether a sitemap's lastmod values are trustworthy. Fixing them means pulling the date from wherever the actual content-change timestamp already lives in your stack, rather than from whenever the sitemap itself gets rebuilt.

In a Next.js site using the App Router's sitemap.ts file convention, the documented return shape for each URL entry includes a lastModified field that accepts either a Date object or a date string. Next.js's own documentation example pulls this value from a real per-record timestamp, product.date in a products sitemap, rather than a single new Date() call repeated for every URL. Calling new Date() once at build time for every entry produces exactly the failure mode Google's and Bing's documentation both warn about: every URL gets an identical, deploy-time stamp regardless of whether that page's content actually changed. The fix is mechanical: read the record's own updatedAt or equivalent column from the database or CMS query that's already building the page list, and pass that value through instead.

WordPress sites running Yoast SEO follow a similar principle from the other direction. Per Yoast SEO's own open-source sitemap code, it sets lastmod from a post's post_modified_gmt field, WordPress's own stored timestamp for when a post was last saved, falling back to post_date_gmt (and finally post_date) only if no modification has been recorded. That's the same underlying idea in a different stack: use the timestamp the platform already tracks for real edits, not a value computed fresh on every sitemap request.

The general principle carries across any stack: a sitemap generator should read a genuine last-modified column, not generate one at render time, and a content edit that doesn't touch the actual page (a typo fix buried in an admin note, or the copyright-year footer change Google's own documentation specifically excludes) shouldn't bump the timestamp either.

How Sitemap Index Files Work for Large Sites

The sitemap protocol caps a single sitemap file at 50,000 URLs or 50MB uncompressed, whichever limit is hit first, per Google's own sitemap documentation. A site with more URLs than that doesn't get to just keep appending entries. It has to split into multiple sitemap files and list those files inside a separate sitemap index file, a small XML document using its own sitemapindex root element, with a sitemap entry and loc tag pointing to each individual sitemap's URL. Google accepts either the individual sitemaps submitted one by one or the single index file submitted on its own, and every sitemap referenced inside an index file has to be hosted on the same site as the index itself.

Next.js's App Router provides a direct mechanism for this through a generateSitemaps function exported alongside sitemap.ts. It returns an array of small objects, each carrying an id, and the default sitemap function then receives that id and returns only the slice of URLs belonging to that chunk, commonly by querying a fixed range like id * 50000 to (id + 1) * 50000 from a products table. Next.js handles serving each chunk at its own URL automatically. Whatever the stack, the mechanics stay the same: pick a chunk size safely under 50,000 URLs per file, generate one sitemap file per chunk, and list every chunk inside one index file that a site owner submits as a single entry point.

Submitting and Monitoring Your Sitemap in Search Console

Building an accurate sitemap only matters if Google actually knows it exists. Search Console's Sitemaps report is where that happens: paste a sitemap's URL, or a sitemap index's URL, into the "Add a new sitemap" field and submit it. Google fetches the file close to immediately to confirm it parses correctly, though actually crawling every URL listed inside it can take considerably longer, depending on the site's size and how Google already prioritizes it.

The same report is also the place to monitor sitemaps after submission. Its main table shows every sitemap and index file submitted through the report or the Search Console API, the date it was last read, and the status of that last request. When a sitemap's status isn't a clean success, clicking into that row surfaces the specific parsing errors Google encountered (malformed XML, an unreachable URL, entries that don't match the sitemap protocol), letting a site owner fix the actual problem instead of guessing. The Sitemaps report doesn't replace the Coverage report for checking whether individual URLs got indexed, but it can filter that report down to only the URLs that came from a specific sitemap, a fast way to check whether a whole newly submitted sitemap is being picked up as expected rather than checking URLs one at a time.

Does This Mean Sitemaps Themselves Don't Matter?

No, and that distinction matters. A sitemap's core job, listing URLs a site wants crawled, is still genuinely useful, especially for large sites, newly published pages, or sites where internal linking alone doesn't surface every URL quickly. What this evidence actually narrows down is which fields inside that sitemap do anything. Submitting a sitemap is not the same claim as tuning its priority values, and conflating the two leads to time spent hand-tuning a field Google has stated it doesn't read. For what actually influences whether Google reaches and processes a page at all, see crawling vs. indexing and crawl budget and log files, both of which cover the access layer a sitemap only partially addresses.

Related: crawling vs. indexing, crawl budget and log files, indexed but not ranking.