Sitemap Priority

TL;DR — Sitemap priority is a number from 0.0 to 1.0 you can put on each URL in your XML sitemap to say how important it is. Here’s the short version: Google ignores it, and the protocol never defined it as an absolute ranking instruction. Don’t waste time tuning those sliders in your SEO plugin — spend it on internal links and clean site structure instead.

What sitemap priority is

An XML sitemap is a list of your URLs you hand to search engines so they can find your pages. The original sitemap format let you attach two optional extra tags to each URL:

• <priority> — a number from 0.0 to 1.0 (the default is 0.5) that’s supposed to say how important that page is compared to your other pages.
• <changefreq> — a word like daily, weekly, or monthly that’s supposed to say how often the page changes.

The idea sounded reasonable: mark your homepage 1.0, mark an old archived page 0.2, tell Google your news section changes daily, and it would crawl and rank accordingly.

The catch: it doesn’t work

That’s not how it turned out. Google ignores both tags completely. Not “weighs them less” — ignores them. Google’s own documentation says so in plain words: “Google ignores <priority> and <changefreq> values.” Bing does the same thing.

Setting a page to priority 1.0 does not make Google crawl it first, index it faster, or rank it higher. Setting changefreq to daily does not make Google visit daily. These numbers go into the sitemap and search engines throw them away.

Why do SEO plugins still show it?

This is the confusing part. If you use a WordPress SEO plugin, you may still see priority and change-frequency options in the sitemap settings. That’s a leftover from years ago, when the sitemap format was new and nobody was sure whether the tags mattered. They persist in the settings screen even though the search engines that matter ignore whatever you set. You can safely leave them alone.

What actually tells Google a page is important

If priority is dead, how do you signal that a page matters? The honest answer is: the same way you always should have.

• Link to it. Pages you link to a lot — especially from your homepage and main menu — read as important. This is the real “priority” signal.
• Keep it close to the homepage. A page one click from the homepage looks more important than one buried six clicks deep.
• Put it in the navigation. Where a page sits in your menus and categories tells search engines (and people) what you care about.
• Keep your sitemap clean and accurate. Being in a tidy sitemap with an honest last-modified date does more than any priority number inside it.

Want the full story — the exact Google and Bing quotes, why these tags collapsed, and what to use instead — switch to the Advanced tab.

TL;DR — <priority> and <changefreq> are optional sitemaps.org tags meant to rank a URL’s relative importance and its expected change rate. Google ignores both — the current Search Central docs say “Google ignores <priority> and <changefreq> values,” Illyes called priority “a bag of noise” (2017), Mueller said it “doesn’t really play that much of a role” (2015). These fields are self-reported, and the widely repeated industry explanation — not one Google or Bing states directly — is that they got universally gamed: everyone set 1.0/daily, so the fields carried no information. The one sitemap tag engines do use is an accurate <lastmod>. Real importance signals are internal links, click depth, sitemap inclusion, observed crawl frequency, and navigation prominence — all observed, none declared.

What the tags were designed to do

Both tags come from the sitemaps.org protocol, the 0.9 spec that defines the XML sitemap format Google and Bing both read.

<priority> takes a value from 0.0 to 1.0, defaulting to 0.5. Its stated job is to describe “the priority of this URL relative to other URLs on your site.” The key word is relative — it was never meant to be an absolute importance score across the whole web, only a ranking of your own pages against each other. And even the spec that invented it hedged hard: it says outright that “the priority you assign to a page is not likely to influence the position of your URLs in a search engine’s result pages.” The tag’s own creators told you it wasn’t a ranking lever.

<changefreq> takes one of always, hourly, daily, weekly, monthly, yearly, or never. The spec is explicit that this “value provides general information to search engines and may not correlate exactly to how often they crawl the page” — it’s “considered a hint and not a command.” Search engines were always free to recrawl a never page to check for surprises, and to ignore a daily claim if the content sat still.

So from day one these were self-reported hints the spec itself disclaimed. What happened next is that the two biggest engines stopped reading them altogether.

Google’s position: “ignores” — and it’s been consistent for a decade

Google’s current, standing documentation is blunt. On the Build and Submit a Sitemap page, in the section on optional tags, it says: “Google ignores <priority> and <changefreq> values.” Not “gives less weight to,” not “deprioritizes.” Ignores. This is documentation, not a one-off tweet.

And it’s not new. The public statements go back years:

• 2015 — John Mueller. In a Webmaster Central hangout, asked whether priority and frequency matter: “Priority and change frequency doesn’t really play that much of a role with Sitemaps anymore… it is much better to just specify the time stamp directly.”
• 2017 — Gary Illyes. Asked on Twitter about the priority and changefreq fields, he replied: “we ignore those. It’s essentially a bag of noise.”

Two named Googlers, two years apart, saying the same thing the docs say today. This is settled, repeated, longstanding policy — not a rumor and not a recent change.

One footnote worth flagging: some 2017-era commentary claimed Google ignored the <lastmod> date too. That’s now outdated. Google’s current docs explicitly say Google does use <lastmod> — “if it’s consistently and verifiably… accurate.” Don’t conflate the two: <priority>/<changefreq> are ignored; an honest <lastmod> is not.

Does Bing treat it differently? No.

This is the loophole people reach for: “sure, Google ignores it, but maybe Bing still cares.” It doesn’t. Bing’s own February 2023 webmaster blog post on lastmod says that because these fields “do not accurately reflect the likelihood of a page being updated or the relative importance of a URL,” “Bing largely disregards these fields.” In the very same post Bing says it’s “revamping our crawl scheduling stack to better utilize the information provided by the lastmod tag” — exactly Google’s move. Both engines abandoned the self-reported tags and doubled down on the one they can verify.

Bing reinforced this in its July 2025 post on sitemaps in AI-powered search: XML “remains the preferred format… as it supports structured metadata like lastmod, which helps Bing assess content freshness and relevance more effectively.” Again — lastmod, not priority.

Why these tags likely got ignored (an explanation, not an official one)

Google and Bing document that they ignore priority and changefreq. Neither company has published why — so treat what follows as the standing industry explanation, not a stated Google or Bing rationale.

The common practitioner read is a trust problem: a signal is only useful if it’s hard to fake and correlates with something real, and priority/changefreq are neither:

• They’re self-reported. You declare them; nobody verifies them. A search engine has no way to confirm your 1.0 page is actually more important than your 0.4 page — you just typed the numbers.
• The widely cited explanation is that they got gamed. The theory — repeated across the SEO industry, not a line from Google’s or Bing’s own documentation — is that webmasters predictably set nearly every URL to 1.0 and daily to look important. When everything claims priority 1.0, nothing does — the field’s variance would collapse and it would stop carrying information.

That’s a plausible mechanism and it fits the pattern search engines describe for other self-reported fields, but it’s inference, not confirmed causation.

What is documented is the contrast with <lastmod>. Google uses it, but conditionally — “if it’s consistently and verifiably… accurate,” which it checks “by comparing to the last modification of the page.” That built-in verification check is a real, sourced distinction between the two tag types: whether or not gaming is the specific reason priority died, lastmod’s verifiability is why Google can trust it in a way priority never earned.

What actually signals a page’s importance instead

Priority isn’t replaced by another tag you set — it’s replaced by signals search engines observe rather than ones you declare. This is the section that matters most:

A couple of these deserve more:

Crawl frequency is observed, not declared. You can’t tell Google to crawl a page daily via changefreq. Google’s own crawl-demand model decides that from popularity (“URLs that are more popular on the Internet tend to be crawled more often to keep them fresher in our systems”) and staleness (“our systems want to recrawl documents frequently enough to pick up any changes”), per its crawl-budget documentation. Popularity is largely a function of links; staleness is a function of your real change rate reflected in an honest lastmod. Neither is something you set in a tag.

lastmod is the tag to get right. But get it right — don’t blanket-stamp today’s date on everything, which is just another way of gaming a signal and gets your dates distrusted. Update it only on significant content changes.

Should you still include priority and changefreq?

Practically: it’s fine to leave them out entirely. Including them isn’t harmful, but it isn’t helpful either, and when your generator sets them all to the same default value they signal literally nothing. Most sitemap tools and SEO plugins still emit them by default (and still expose priority sliders in their UI), which is the main reason this myth won’t die. Removing them will not hurt your SEO; a lean sitemap of <loc> plus an accurate <lastmod> is current best practice. Your time is far better spent on internal linking and site architecture.

Where this sits

This is a discovery-stage topic. If you’re building or debugging sitemaps more broadly, see the sitemaps hub, the XML sitemap deep dive, and sitemap index for large sites. For the “what actually works instead” side, internal links, crawl depth, and crawl frequency are the pages to read next.

Myths, quickly

• “Priority 1.0 makes Google crawl/rank my page first.” No — ignored; crawl demand (popularity + staleness) decides, not your declaration.
• “changefreq=daily makes Google crawl daily.” No — ignored; even the spec called it a hint engines can disregard.
• “Priority affects rankings.” Never did — the sitemaps.org spec itself said it’s “not likely to influence” rankings.
• “Maybe Bing still uses them.” No — Bing “largely disregards these fields.”
• “Since Google ignores lastmod too, none of it matters.” Outdated — Google’s current docs say it does use an accurate lastmod.
• “Removing priority/changefreq will hurt my SEO.” No — a lean sitemap is standard practice.

AI summary

A condensed take on the Advanced version:

• Sitemap priority = the optional <priority> tag (0.0–1.0, default 0.5) from the sitemaps.org protocol, meant to rank a URL’s importance relative to other pages on the same site. <changefreq> is its companion (a change-rate hint).
• Google ignores both — literally. Its docs say “Google ignores <priority> and <changefreq> values.” Illyes (2017): “a bag of noise.” Mueller (2015): “doesn’t really play that much of a role.” This is consistent, decade-long policy.
• Bing ignores them too. Bing’s 2023 blog: it “largely disregards these fields” and is investing in lastmod instead. Closes the “maybe Bing cares” loophole.
• Never a ranking factor, even by design — the sitemaps.org spec said priority is “not likely to influence the position of your URLs” in results.
• Why they likely died: self-reported, and per the common industry explanation — not one Google or Bing states directly — universally gamed (everyone set 1.0/daily), so the fields carried no information. lastmod survived because it’s verifiable.
• What actually signals importance: internal link count, click depth, inclusion in a clean sitemap, an accurate <lastmod>, and navigation prominence — all observed, not declared. Crawl frequency is an output of popularity + staleness, not something you set.
• Practical guidance: fine to omit both tags; harmless but useless to keep; removing them won’t hurt SEO. SEO plugins still expose priority sliders, which is why the myth persists.

Official documentation

Primary-source documentation from the search engines and the protocol that defines the tags.

Google

• Build and Submit a Sitemap — the standing doc that states “Google ignores <priority> and <changefreq> values” and explains when <lastmod> is used.
• Optimize your crawl budget — crawl demand as popularity + staleness, i.e. what actually drives crawl frequency instead of changefreq.

Bing / Microsoft

• The Importance of Setting the “lastmod” Tag in Your Sitemap (Feb 2023) — says Bing “largely disregards these fields” (priority/changefreq) and is revamping crawl scheduling around lastmod.
• Keeping Content Discoverable with Sitemaps in AI-Powered Search (July 2025) — XML preferred because it supports lastmod for freshness; no mention of priority as a signal.

Protocol (origin of the tags)

• sitemaps.org Protocol — the original <priority> and <changefreq> definitions, including the spec’s own admission that priority is “not likely to influence the position of your URLs in a search engine’s result pages.”

Quotes from the source

On-the-record statements from Google and Bing. Each link jumps to the quoted passage on the source page.

Google — the current documentation

• “Google ignores <priority> and <changefreq> values.” — Google Search Central docs, Build and Submit a Sitemap. Jump to quote
• “Google uses the <lastmod> value if it’s consistently and verifiably (for example by comparing to the last modification of the page) accurate.” — same doc, on the one tag Google does read. Read the doc

Gary Illyes, Google (2017)

• “we ignore those. It’s essentially a bag of noise.” — Gary Illyes, replying on Twitter to a question about the sitemap priority and changefreq fields, March 28, 2017. Read the coverage

John Mueller, Google (2015)

• “Priority and change frequency doesn’t really play that much of a role with Sitemaps anymore. This is something where we’ve tried various things but essentially, if you have a sitemap file and you are using it to tell us about the pages that were changed or updated, it is much better to just specify the time stamp directly so that we can look into our internal systems and say we haven’t crawled since this date therefore we should crawl again. And just crawling daily doesn’t make much sense if your content doesn’t change.” — John Mueller, Google Webmaster Central hangout, May 8, 2015. Read the coverage

Microsoft Bing (2023)

• “Bing largely disregards these fields.” — Bing Webmaster Blog, on <changefreq> and <priority>, February 2023. Jump to quote

Mistakes people actually make with these tags

Concrete things I see teams and plugins do around priority and changefreq — each one costs time or, in one case, quietly damages a signal that does matter.

Hand-tuning priority values page by page. Sitting down and deciding this category page is 0.7 and that one is 0.5 feels like optimization. It isn’t — Google and Bing both ignore the field, so every minute spent on it produces zero crawl or ranking effect. Spend that time on internal linking or site architecture instead; those actually move the needle on perceived importance.

Setting every URL’s changefreq to daily or hourly to look important. This is the kind of gaming widely blamed for the field losing engines’ trust in the first place — though neither Google nor Bing states that motive directly. What’s documented is simpler: when every URL claims daily, the field carries no distinguishing information, and the sitemaps.org spec itself calls it “a hint and not a command” that engines can disregard anyway. Leave it out.

Building custom priority-scoring logic into your sitemap generator (weighting by page depth, word count, or revenue) is real engineering effort spent on a field neither engine reads. If you have that kind of crawl/page data available, point it at internal-link recommendations or navigation placement instead — those are the levers that actually correlate with perceived importance.

Blanket-stamping today’s date on <lastmod> for every URL to look fresh. Unlike priority and changefreq, this one can backfire: Google says it uses <lastmod> only “if it’s consistently and verifiably… accurate,” checked by comparing to the page’s real modification date. Fake it across the board and you risk the one sitemap signal that actually gets read. Update it only when the content meaningfully changes.

Treating “fix priority values” as a line item in an SEO audit. It reads as productive work but delivers nothing measurable. Replace that line item with checking sitemap cleanliness and <lastmod> accuracy — the audit still looks thorough, but now it’s checking something that matters.

Assuming your SEO plugin’s priority sliders are worth configuring per template. Whatever values a plugin defaults to or lets you override, the outcome for crawling and ranking is identical: ignored. Leave the sliders alone and spend the configuration time confirming the plugin isn’t emitting malformed XML or duplicate URLs instead.

Which engines actually use these tags

A quick-reference table built from the official statements in the Official Docs and Quotes tabs — nothing here is inferred, only what each source says about its own engine.

This table only covers Google and Bing because those are the two engines with on-the-record statements in the brief — I’m not going to guess at Yandex’s or any other engine’s behavior without a sourced quote.

Quick sitemap-tag decision

Should I include priority and changefreq in my sitemap?

A short pre-publish checklist for deciding what to do with these tags — and, more importantly, getting <lastmod> right since that’s the one that matters.

• Check what your sitemap generator or SEO plugin actually emits. Open a sample sitemap file and look for <priority>/<changefreq> on a handful of URLs — most plugins still add them by default.
• If you’ve been hand-tuning priority values, stop. It has no effect on crawling or ranking; redirect that time to internal linking instead.
• Decide: leave the tags in, or strip them for a leaner file. Both are fine — including them isn’t harmful, it just isn’t helpful either. As covered in the Advanced tab, a lean sitemap of <loc> plus an accurate <lastmod> is the more current recommendation.
• If you strip them, validate the result. Run the file through the Sitemap Validator to confirm the XML is still well-formed and nothing else broke.
• Audit a sample of <lastmod> dates against real content-change dates in your CMS. A tag that’s accurate builds trust with Google’s verification check; a blanket “today” stamp on unchanged pages erodes it.
• If you regenerate the sitemap with a tool, prefer one that only emits <lastmod> when it has real evidence for it rather than one that invents a date for every URL — the XML Sitemap Generator does this by only emitting lastmod when the page provides evidence for it.

The real-signal audit: a 4-step framework for page importance

Since priority is dead, this is the repeatable way to actually figure out — and improve — which pages read as important to search engines. Run it per section or template, not per single URL.

Step 1 — Link census. Count internal links pointing at each URL, weighted toward links from high-value pages (homepage, main nav, top category pages). This is the real substitute for a declared priority number — it’s observed, not self-reported.

Step 2 — Click-depth check. Measure how many clicks each URL sits from the homepage. Pages several clicks deep read as less important structurally, regardless of any tag you set on them.

Step 3 — Sitemap and <lastmod> audit. Confirm the URL sits in a clean, canonical-only sitemap, and that its <lastmod> is both present and honest. Being in a tidy sitemap with an accurate date is a real signal; being absent, or sitting in a sitemap full of noindexed or redirected URLs, isn’t.

Step 4 — Navigation-prominence review. Check where the page sits in your menus, breadcrumbs, and category hierarchy. Placement here is a structural declaration of importance that both users and search engines read the same way.

Score pages by combining all four — a page that’s linked often, shallow, correctly included in the sitemap, and prominent in navigation is genuinely important. A page you’d have marked 1.0 in the old model but that fails all four checks isn’t important no matter what number you’d have typed into a tag nobody reads.

Toolkit: finding and stripping priority/changefreq tags

Since the recommendation is “fine to leave them out,” here’s how to check whether your sitemap has them and remove them if you decide to.

Regex to match a <priority> or <changefreq> element (for stripping or scanning):

<(priority|changefreq)>[^<]*<\/\1>

• (priority|changefreq) — capture group 1, matches either tag name.
• [^<]* — the tag’s text content (a number or a word like daily).
• <\/\1> — the matching closing tag, via a backreference to group 1, so <priority> only ever closes with </priority>.

Python — strip both tags from a sitemap file:

import re

with open("sitemap.xml", "r", encoding="utf-8") as f:
    xml = f.read()

# Remove <priority>...</priority> and <changefreq>...</changefreq> elements,
# including any surrounding whitespace/newline.
cleaned = re.sub(r"\s*<(priority|changefreq)>[^<]*</\1>", "", xml)

with open("sitemap-clean.xml", "w", encoding="utf-8") as f:
    f.write(cleaned)

macOS / Linux — quick count of how many URLs carry the tags:

grep -oE '<(priority|changefreq)>' sitemap.xml | sort | uniq -c

Windows PowerShell — same check:

Select-String -Path sitemap.xml -Pattern '<priority>|<changefreq>' -AllMatches |
  ForEach-Object { $_.Matches } | Group-Object Value | Select Name, Count

Chrome DevTools Console — fetch and check a live sitemap (paste into the Console panel on any page, editing the URL):

fetch('/sitemap.xml')
  .then(r => r.text())
  .then(xml => {
    const priority = (xml.match(/<priority>/g) || []).length;
    const changefreq = (xml.match(/<changefreq>/g) || []).length;
    console.log({ priority, changefreq });
  });

XPath — for a Screaming Frog custom extraction to flag whether a crawled sitemap URL carries these tags:

//*[local-name()='url']/*[local-name()='priority']

(swap priority for changefreq for the other tag; local-name() is used because sitemap XML is namespaced, so a plain //priority won’t match).

Once you’ve stripped the tags (or decided to leave them), run the result through the Sitemap Validator to confirm the XML is still well-formed.

Test yourself: Sitemap Priority

Five quick questions on the priority and changefreq tags and what actually signals importance. Pick an answer for each, then check.

Resources worth your time

My related writing

• The Beginner’s Guide to Technical SEO — where sitemaps and discovery fit in the bigger picture.
• Robots.txt and SEO: Everything You Need to Know — the other side of crawl control that people confuse with sitemap tags.
• The Story of Blocking 2 High-Ranking Pages With Robots.txt — a first-party experiment on how crawl controls actually behave, versus what people assume.

From around the industry

• Google — Build and Submit a Sitemap — the primary doc; “Google ignores <priority> and <changefreq> values.”
• Bing — The Importance of Setting the “lastmod” Tag in Your Sitemap — Bing “largely disregards these fields.”
• sitemaps.org Protocol — the spec that defines <priority>/<changefreq> and admits priority is “not likely to influence” rankings.
• Search Engine Roundtable — Google: Sitemap Priority Field Is ‘A Bag Of Noise’ — Barry Schwartz’s coverage of the Illyes 2017 exchange.
• Search Engine Roundtable — Google Downplays Use Of Priority & Change Frequency In XML Sitemap File — the Mueller 2015 hangout.
• Ahrefs — How to Create an XML Sitemap (and Submit It to Google) — Joshua Hardwick’s guide; recommends leaving lastmod, changefreq, and priority off to keep sitemaps lean.

Sitemap priority

Sitemap priority is the optional <priority> tag (0.0–1.0, default 0.5) in the sitemaps.org XML protocol meant to rank a URL's importance relative to others on the same site. Google ignores it entirely — as does Bing — and it was never a ranking factor even by the spec's own admission.

Related: Sitemap, XML sitemap, Sitemap index

Sitemap priority

Sitemap priority is the optional <priority> element in the sitemaps.org XML protocol. It lets a site owner assign each URL a value from 0.0 to 1.0 (default 0.5) to indicate how important that page is relative to other pages on the same site. It was designed as a self-reported hint, not a directive — and the spec itself warned that “the priority you assign to a page is not likely to influence the position of your URLs in a search engine’s result pages.”

Google has confirmed, repeatedly and over nearly a decade, that it ignores the tag entirely. Its current documentation states plainly: “Google ignores <priority> and <changefreq> values.” Gary Illyes called the priority field “essentially a bag of noise” in 2017, and John Mueller said back in 2015 that priority and change frequency “doesn’t really play that much of a role with Sitemaps anymore.” Bing’s own webmaster blog says it “largely disregards these fields” too. It is not a ranking factor, not a crawl-priority signal, and not a substitute for internal linking or site architecture.

The companion tag <changefreq> (values always, hourly, daily, weekly, monthly, yearly, never) shares the same fate — also ignored by both engines, also self-reported. The widely repeated industry explanation is that it got gamed into meaninglessness when webmasters marked everything “daily,” though neither Google nor Bing states that motive directly. The one sitemap tag search engines actually use is <lastmod>, and only when it’s verifiably accurate against real content changes. What actually signals importance instead is internal link count and depth, inclusion in a clean sitemap, observed crawl frequency, and navigation prominence — none of which you declare in a sitemap.

Related: Sitemap, XML sitemap, Sitemap index

Changelog