Sitemap <priority> and <changefreq> do nothing in Google: its sitemap documentation says it ignores both values, and Bing said in 2023 that it largely disregards them too. The optional field both search engines act on is <lastmod>, and Google uses it only when it is consistently and verifiably accurate. So the practical answer is to remove priority and changefreq and spend the effort on an honest lastmod. This guide explains what each tag was meant to do, why search engines stopped trusting two of them, and how to set lastmod so it keeps working. The XML sitemap guide covers everything else that goes in the file.
Quick answer
<priority>: ignored by Google and Bing. Remove it or leave it; it has no effect on crawling or ranking.<changefreq>: ignored by Google and Bing. Remove it.<lastmod>: used by both, for deciding what to recrawl, as long as it is honest. Set it to the date of the last significant change to the page's content.- Format is W3C datetime:
2026-09-25or2026-09-25T14:30:00+02:00. A time needs a timezone. - If you cannot produce an honest date, omit
<lastmod>. Missing is neutral; faked costs trust. - Run the sitemap checker to see the lastmod range, format problems and whether the listed pages answer 200.
What sitemap priority, changefreq and lastmod mean
The sitemaps.org protocol, published in 2006, defines one required and three optional children of each <url>:
| Tag | Allowed values | Intended meaning | Used by Google |
|---|---|---|---|
<loc> | Absolute URL | The page | Yes (required) |
<lastmod> | W3C datetime | When the page last changed | Yes, if accurate |
<changefreq> | always, hourly, daily, weekly, monthly, yearly, never | How often the page is likely to change | No |
<priority> | 0.0 to 1.0, default 0.5 | Importance relative to other URLs on your own site | No |
Priority was never a ranking signal between sites. The protocol says it only compares your URLs with each other, so a site that set every URL to 1.0 told crawlers nothing. Changefreq was described as a hint from the start, and crawlers were free to visit more or less often than it said.
Does Google use sitemap priority?
No. Google's "Build and submit a sitemap" documentation says it ignores <priority> and <changefreq> values, and uses <lastmod> if it is consistently and verifiably accurate. Microsoft's Bing Webmaster blog said in February 2023 that most priority and changefreq values it sees are not set correctly, so Bing largely disregards them and relies on lastmod for crawl scheduling instead.
The reason is simple: the values were self-reported and almost never true. Generators set every page to priority 0.8 and changefreq daily, including an "About" page unchanged for five years. A signal that is wrong on most sites is worth nothing to a crawler, while lastmod can be checked: Google fetches the page and sees whether it really changed.
Should you remove priority and changefreq?
Yes, when you control the generator. They add bytes to every entry, and an invalid value (a changefreq of sometimes, a priority of 5) can make a strict parser report the file as having errors. A clean entry is two lines:
<url>
<loc>https://example.com/products/leather-tote/</loc>
<lastmod>2026-09-18</lastmod>
</url>If a plugin you cannot configure writes them, leave them. Valid values are harmless; they are simply not read by Google or Bing. Other crawlers may still read them, but none of the major search engines has said it uses them. WordPress core's /wp-sitemap.xml and Yoast SEO's sitemaps already omit both.
Why lastmod is the one that matters
When lastmod is right, a changed page is recrawled sooner and an unchanged one is left alone, which is exactly how you want crawl requests spent on a site with thousands of pages. Google compares the date with what it finds on fetching the page. If the sitemap says the page changed yesterday and the content is identical to last month's, that is a strike. A file where every URL changed "today" on every read teaches Google to discount the field for the whole file, and then it does nothing even for pages that did change.
The benefit shows on pages people forget: an updated price on a product from 2022, a corrected address on the contact page, a rewritten article. Without a trusted date, Google recrawls them on whatever schedule it settled on, which for a quiet page can be months. On a large site that is one reason behind why a page is not in Google after an update.
How getReport checks it
The report fetches the sitemaps declared in robots.txt (the first three) and /sitemap.xml, gunzips them when needed, and parses each with a strict XML parser. Every <lastmod> is checked against the W3C datetime grammar, and invalid changefreq and priority values are reported too. Valid dates are reduced to a range, oldest to newest, shown in the files table and in the passing finding's evidence ("lastmod up to 2026-09-24").
Up to 25 listed URLs, spread evenly through the file, are requested to confirm they answer 200 and land on themselves, and the page you tested is looked up in the file:
Read the range first. A healthy sitemap on an established site spans months or years, with the newest date near your last publication. A range that collapses to one date, especially today's, means the generator writes the current time. A newest date a year old on a site that publishes weekly means the generator reads a field nobody updates.
How to set lastmod correctly
1. Decide what "changed" means
The date should move when a reader would notice a difference: text, price, availability, images, the title. It should not move for:
- A new comment.
- A theme or template change that touched every page identically.
- A change to the footer, menu or a sidebar widget.
- A resave without edits, a bulk category change, a plugin touching posts on activation.
- The sitemap being regenerated.
In a sitemap index, each <sitemap> entry's <lastmod> is the newest date inside that child file, never the generation time. See sitemap index files.
2. Use the format Google reads
W3C datetime, a fixed profile of ISO 8601. Both are valid:
<lastmod>2026-09-25</lastmod>
<lastmod>2026-09-25T14:30:00+02:00</lastmod>These are not: 25/09/2026, Sep 25 2026, 2026-09-25 14:30:00 (space, no zone), 1758803400 (Unix time), 2026-09-25T14:30:00 (time without a zone). A date alone is enough for almost every site.
In PHP and JavaScript, from the content's own modified time:
<?php
$modified = new DateTimeImmutable('2026-09-25 14:30:00', new DateTimeZone('Europe/Zagreb'));
echo '<lastmod>' . $modified->format(DATE_W3C) . '</lastmod>';
// <lastmod>2026-09-25T14:30:00+02:00</lastmod>// lastmod from the content's modified date, not from Date.now()
const lastmod = new Date(page.modifiedAt).toISOString(); // 2026-09-25T12:30:00.000Z3. Find what bumps the modified date
Most CMSs update the modified timestamp on every save, whether or not the content changed. The usual culprits:
- Bulk edits: a category change on 300 posts updates 300 dates.
- Builders and plugins that resave on every editor open or on activation.
- Syncs that write to every product nightly even when stock did not change.
- Import scripts and cache warmers that update every record.
If the range in the files table jumps to today on a day nobody published, something touched every record.
4. Fix the generator, not the file
Hand edits last until the next regeneration. If the generator writes the generation time, switch it to the page's modified field. If that field is unreliable, stop the operations that bump it, or track content changes separately (a hash compared on save). If neither is possible, remove <lastmod>.
Platform notes
WordPress. Core's sitemap writes <lastmod> from each post's post_modified_gmt, and Yoast SEO and Rank Math also use the post's modified date. All three are honest by default; problems come from what moves post_modified: any save, Quick Edit, bulk edit, and plugins that call wp_update_post(). Comments and theme or plugin updates do not change it.
Shopify. Shopify writes lastmod into its generated sitemaps and offers no setting for it. If every product looks freshly dated, an app writing to all products on a schedule is the usual cause; pause it and watch the range.
Static sites. A generator that writes new Date() at build time dates every page to the deploy. Use the content's own date from front matter, or the last commit that touched the file:
git log -1 --format=%cI -- content/products/leather-tote.md
# 2026-09-18T09:12:44+02:00News sitemaps use <news:publication_date> rather than lastmod, list only articles from the last two days, and hold up to 1,000 URLs.
Verify
- The files table shows a lastmod range matching the site's real publishing history, with no "not W3C dates" problem.
- Edit one page, regenerate, re-run: only that page's date moved.
curl -s https://example.com/sitemap-posts.xml | grep -A1 "leather-tote"shows it. - Search Console → Sitemaps shows a "Last read" date that keeps moving.
- The sampled URLs answer 200 and land on themselves.
Common mistakes
- Tuning priority to boost pages. It is ignored. Internal links and content decide what Google treats as important.
- Setting changefreq to
alwaysorhourlyfor faster crawling. Also ignored. - Stamping the generation time on every URL. One date for the whole file, always today. Read the page's modified field, or drop the tag.
- A timestamp without a timezone.
2026-09-25T14:30:00is invalid; add the offset or use the date only. - Fresh dates on redirecting or deleted URLs. Remove those entries; see XML sitemap errors.
Questions people ask
Does sitemap priority affect SEO?
No. Google ignores the <priority> value, and Bing has said it largely disregards it too, so it changes neither crawling nor rankings. Even under the original protocol it only compared URLs within your own site. To signal which pages matter, link to them prominently from your navigation and other pages, and keep them in the sitemap with an accurate lastmod.
What does changefreq mean in a sitemap?
<changefreq> was meant to tell crawlers how often a page is likely to change, using one of seven values from always to never. It was always a hint, and Google and Bing now ignore it because the values were rarely true. An accurate <lastmod> gives them the same information in a form they can check, so remove changefreq when you can.
What should the sitemap priority be for the home page?
It does not matter. Google and Bing ignore priority, so 1.0 on the home page and 0.5 elsewhere has no effect. If your generator insists on a value, any number from 0.0 to 1.0 is valid. Your home page's importance comes from links, not from the sitemap.
Should lastmod change when I fix a typo?
Yes, if you want Google to pick up the correction; a typo fix is a content change. What should not move the date is anything readers would not notice: a resave without edits, a new comment, a footer or theme change. Keeping those out is what keeps the date trusted for the changes that matter.