← All Tools

Sitemap priority & changefreq — the Tags Google Already Said It Ignores

Guide · Last verified Aug 26, 2026

If you've ever agonized over whether to set <priority> to 0.9 or 1.0, or whether <changefreq> should be daily or weekly, that time was essentially wasted. Google has stated for years, officially, that it doesn't use either tag to determine crawl priority. This guide covers why that happened, and what you should actually pay attention to in your sitemap instead.

1. What priority and changefreq Were Originally For

When the sitemap protocol (sitemaps.org) was first defined, <priority> was a tag where a site owner would manually indicate, on a scale from 0.0 to 1.0, "how important is this URL relative to other URLs on my site." <changefreq> let you indicate "how often does this page change," using one of always/hourly/daily/weekly/monthly/yearly/never. The intent itself was reasonable — the idea was that when a search engine allocates crawl resources, a hint straight from the site owner would help.

2. Why Google Ended Up Ignoring Them: The Self-Reporting Trap

The problem is that both values rely entirely on the site owner's own self-reporting. Since around 2014, Google — through official channels including John Mueller — has repeatedly confirmed that it does not use priority or changefreq to determine crawl priority. The reason is simple: because every site owner wants their own pages to look important, it's common in practice to open a sitemap and find almost every single URL marked priority 0.8–1.0, with changefreq blanketed in daily across the board. When values are uniformly "high" across an entire URL set, they become effectively meaningless as a relative priority signal. So instead of trusting these values, Google independently computes and uses signals it actually observes — past crawl history, how often a page genuinely changes, and importance signals derived from internal link structure.

3. So What in a Sitemap Still Matters?

First, <loc> (the URL itself) is obviously still central to a sitemap's core function — it's still important. It plays the basic role of telling Google this URL exists and is a canonical, indexable page. <lastmod> is a field Google has said it "can" reference. But there's a condition attached — it's only trusted when the lastmod value is honestly tied to actual content changes. A sitemap that blanket-updates every URL's lastmod to "today's date" every single time falls into exactly the same trap as marking every priority as 1.0 — and Google detects this pattern too, lowering how much it trusts that field.

In short: <loc> — required, still the core. <lastmod> — a valid reference signal when kept honest. <priority> / <changefreq> — effectively no impact on crawl priority.

4. So Where Should You Actually Spend Your Time?

Frequently Asked Questions

Q. Can I just remove priority and changefreq entirely?

A. Yes. Both tags are optional under the sitemaps.org spec. A sitemap with just <loc> is perfectly valid. That said, including them doesn't hurt anything — if they're already auto-generated for you, there's no need to go out of your way to strip them out.

Q. Do other search engines (Bing, Naver) ignore these tags too?

A. Bing has also stated, in its own official documentation, that it doesn't place much trust in priority. Exact policy can vary a bit by search engine, but the general tendency of favoring independently observed signals over self-reported values is common across the board.

Q. How do I manage lastmod "honestly"?

A. The most accurate approach is having your CMS or static site build system automatically pull each file's actual last-modified timestamp into the sitemap. If your setup requires entering dates manually, the key habit is only updating it on days you actually changed the content.

Q. Does this mean sitemaps have basically no SEO value at all?

A. No. A sitemap's core function — telling search engines which URLs exist on your site and which of them are the canonical version — remains valid and important. What's become meaningless is just two secondary fields: priority and changefreq.