sitemap.xml changefreq and priority: What They Mean and How to Use Them

The Three Optional Attributes in sitemap.xml

A sitemap URL entry has one required element (<loc>, the URL itself) and three optional elements:

• <changefreq> — how often the page is likely to change
• <priority> — the relative importance of this URL within your site
• <lastmod> — when the page was last modified

Here is what a fully annotated URL entry looks like:

<url>
  <loc>https://example.com/blog/my-post/</loc>
  <lastmod>2026-06-25</lastmod>
  <changefreq>monthly</changefreq>
  <priority>0.7</priority>
</url>

All three attributes are hints to search engines — they are not instructions that crawlers are obligated to follow. Understanding what they actually influence (and what they don’t) will help you fill them in sensibly rather than gaming a system that mostly ignores gaming attempts.

Use the sitemap.xml Generator to apply these values globally or per URL when building your sitemap file.

changefreq: The 7 Values and When to Use Each

The <changefreq> element tells crawlers how frequently the page’s content is likely to change. The Sitemaps protocol defines exactly seven valid values:

always

Use for: Pages that change with every single request — for example, a live dashboard, a real-time stock ticker, or a page whose content is completely dynamic and unique per visit.

In practice, very few standard web pages qualify. If you use always on static content, crawlers will learn to distrust your changefreq declarations.

hourly

Use for: Pages updated multiple times per day, such as a live news feed, a sports scores page, or a frequently updated social feed you want indexed as current as possible.

Honest use of hourly is rare. Most sites should not use this unless the content genuinely changes throughout the day.

daily

Use for: Blog homepages, news index pages, category pages, or any aggregation page that reliably gets new content every day. A busy news site’s homepage legitimately changes daily. A blog that publishes once a week does not.

weekly

Use for: Blog posts after their initial publication period, documentation pages with regular revision cycles, service or product pages that are refreshed weekly. This is one of the most practically useful values for content sites.

monthly

Use for: Stable blog archives, evergreen guides, “About” pages, contact pages, legal pages, and anything that changes infrequently but gets occasional updates. This is probably the most widely applicable value for static content on most sites.

yearly

Use for: Pages that rarely change — a static company history page, a terms-of-service page that is updated once a year, a directory listing that is reviewed annually. Not the same as never — the page may still be updated, just rarely.

never

Use for: True archives — content that is intentionally frozen and will not change. For example, a press release from five years ago, a historical news article, or a permalink to an archived product that has been discontinued. Only use never if you genuinely mean it.

changefreq in Practice: Do Search Engines Use It?

Here is the important caveat that many SEO guides understate: Google largely ignores changefreq.

Google’s John Mueller has confirmed multiple times that Googlebot determines its own crawl schedule based on internal signals:

• Historical change rate of the page (how often content actually changed between crawl visits)
• PageRank and perceived importance of the URL
• Overall crawl budget allocated to the domain
• Server response times and crawl capacity

What you declare in changefreq is a hint, not a directive. Google already has a better signal than your declaration — it can compare the content of consecutive crawls to see how frequently a page genuinely changes.

Bing and some smaller crawlers do pay more attention to changefreq, so including it is still worthwhile. But don’t expect changefreq: hourly to force Google to crawl a slow-changing page more often.

Practical recommendation: Fill in changefreq honestly based on actual content update patterns. Don’t inflate it hoping to game crawl frequency — it won’t work for Google and may teach other crawlers to distrust your sitemap.

priority: What 0.0 – 1.0 Actually Means

<priority> is a decimal value between 0.0 and 1.0 that expresses the relative importance of a URL compared to other URLs on your own site. The Sitemaps protocol default is 0.5 if the element is omitted.

The Key Point: It Is Relative, Not Absolute

Priority does not tell Google “this page is important on the internet.” It tells Google “of all the pages on my site, this one is more important than pages with a lower priority.”

A site with 1,000 pages all set to <priority>1.0</priority> has given crawlers no useful signal — every page is equally important, which is the same as saying no page is more important. The value is only meaningful when pages have different priorities.

Practical Priority Ranges

Does Google Use Priority?

Google uses priority as a signal but not a strong one. Like changefreq, it is a hint rather than an instruction. Google’s own analysis of crawl patterns, PageRank, and user engagement signals carries more weight than your declared priority.

That said, for very large sites with tight crawl budgets, using priority differentiation can help guide which pages get crawled first when Googlebot visits. It is a meaningful signal at the margins.

Practical recommendation: Use a sensible tier structure — don’t set everything to 1.0. Give your homepage and core pages the highest priority, your key content pages a mid range, and supporting pages the lower end. Be consistent.

lastmod: What It Does and Why Accuracy Matters

<lastmod> tells crawlers the date (and optionally time) when the page was last meaningfully modified. The required format is W3C Datetime — the simplest valid form is YYYY-MM-DD.

<lastmod>2026-06-25</lastmod>

What lastmod Actually Influences

lastmod is the one attribute in this trio that Google pays the most attention to — provided it is accurate and reflects genuine content changes.

When Google re-crawls your site, it compares the lastmod value in your sitemap against its internal record of when it last crawled the page. If the lastmod date is more recent than the last crawl, that is a signal to re-crawl the page sooner. This can meaningfully help fresh content get picked up faster.

The Problem With Fake lastmod Values

Some CMS plugins and sitemap generators set lastmod to today’s date for every page, every time the sitemap is regenerated. This is a significant mistake. Google’s John Mueller has explicitly said that fake lastmod values — where every page appears to have been updated today — train Google to ignore the attribute entirely.

If Google sees that 5,000 pages all report a lastmod of today, but when it crawls them, the content hasn’t changed in months, it will stop trusting lastmod for your domain.

Practical recommendation: Only update lastmod when content actually changed. For blog posts, use the actual publication date or last-edited date from your CMS. For static pages, set the date when you last made meaningful edits. Never use a dynamic “today” date for all pages.

Best Practices by Site Type

Blog or Editorial Site

• changefreq: monthly or weekly for individual posts; daily for the homepage and category index if you publish frequently
• priority: 1.0 for homepage, 0.8 for category pages, 0.6–0.7 for individual posts
• lastmod: Use the actual published or last-modified date from your CMS

E-commerce Site

• changefreq: daily or weekly for product pages (prices and stock change); monthly for stable category pages
• priority: 1.0 for homepage, 0.8–0.9 for main category pages, 0.6–0.7 for product pages, 0.4 for filter/facet pages
• lastmod: Use the actual product update timestamp; update it when prices, descriptions, or images change

Documentation Site

• changefreq: monthly or weekly for actively maintained docs; yearly for stable reference pages
• priority: 0.9 for the docs homepage and key guides, 0.6–0.7 for reference pages, 0.4 for deeply nested or rarely updated pages
• lastmod: Update when documentation content is revised — most docs platforms track this accurately

Static Site or Portfolio

• changefreq: monthly for main pages; yearly for content that is rarely updated
• priority: 1.0 for homepage, 0.7 for main project or service pages, 0.5 for supporting content
• lastmod: Set to the actual date content was last edited; don’t update it on every build if the content hasn’t changed

Generating Your Sitemap with the Right Attributes

Setting up changefreq, priority, and lastmod correctly is much easier when you have a tool that handles the XML structure for you. The sitemap.xml Generator lets you:

• Set global defaults for all three attributes in one step
• Override changefreq, priority, or lastmod on a per-URL basis for pages that need different values
• Output the result as clean, valid XML ready to upload or submit directly to Google Search Console

Key Takeaways

• There are exactly 7 changefreq values: always, hourly, daily, weekly, monthly, yearly, never — use whichever honestly reflects your update cadence
• Google largely ignores changefreq — Bing and smaller crawlers use it more; fill it in honestly but don’t game it
• Priority is relative to your own site — setting everything to 1.0 is meaningless; use a genuine tier structure
• lastmod is the most impactful of the three — but only if it reflects genuine content changes; fake lastmod dates train Google to ignore the field
• Different site types call for different defaults: blogs, e-commerce, docs, and static sites each have sensible conventions