Part of the SiteMap Series
In the last lesson, we opened up a real XML sitemap and walked through its structure. You saw the XML declaration, the urlset element with its namespace, the url elements wrapping each entry, and the four child elements that can appear inside a url block. That gave us the anatomy at the surface level.
This lesson goes a step deeper. Each of those four elements has its own format, its own rules, and its own set of common mistakes. We’ll work through them in canonical order: loc, lastmod, changefreq, and priority. By the end, you should know exactly what each element is meant to do, how to format it properly, and what to watch out for when reviewing or building a sitemap.
One framing note before we start. Everything in this lesson describes what the protocol says each element is for and how it’s supposed to work. Whether the major search engines actually respect each of these elements is a separate question we’ll come back to in the next lesson. For now, we’re staying at the protocol level.
1. The loc element
The loc element holds the actual URL of the page. It’s the only required element inside a url block, and it does exactly one job: tell the search engine which URL this entry refers to.
We covered the formatting rules in Lesson 7: The Anatomy of an XML Sitemap, but they’re worth restating because they’re where most loc-element mistakes happen. The URL must be absolute, including the protocol (http or https) and the full domain. Relative URLs are not allowed. Special characters must be entity-escaped, so an ampersand in a URL becomes & and a less-than sign becomes <. The URL must follow RFC-3986, which in practice means no spaces, no unencoded special characters, and no broken structure. And the URL must be on the same host as the sitemap file itself, unless you’ve cross-submitted through Search Console.
The most common loc-element mistakes I see in practice are mixed http and https (some URLs on one protocol, some on the other within the same sitemap), inconsistent trailing slashes (some with, some without, for the same kind of page), and forgetting to escape special characters in URLs that contain query strings or filter parameters. All three create silent parsing issues that don’t always raise immediate errors but degrade how search engines treat the sitemap.
2. The lastmod element
The lastmod element tells search engines when the URL was last modified. It’s optional but useful when accurate because it helps crawlers decide whether a previously-crawled URL is worth recrawling.
The format is ISO 8601. At its simplest, that means a date in YYYY-MM-DD format, like 2026-05-30. If you need precision down to the time of day (rare for most sites), you can use the full datetime form YYYY-MM-DDThh:mm:ss with a timezone offset, like 2026-05-30T14:23:45+00:00. The protocol accepts both. Most sites use the simple date form, which is fine.
The most common lastmod mistake is setting it to the current date for every URL on every sitemap regeneration, regardless of whether the URL actually changed. This defeats the purpose of the element entirely. If every URL on your site claims to have been modified today, the lastmod data carries no signal. Search engines learn to ignore it after a while, and you’ve lost a genuinely useful piece of communication with crawlers.
The right approach is to only update lastmod when the underlying content actually changes. Major CMS platforms and SEO plugins handle this correctly out of the box, tracking the actual modification date of each piece of content rather than the date the sitemap was last generated. If you’re hand-rolling a sitemap or using a custom build process, it’s worth checking that lastmod reflects real content changes and not just script execution times.
Two other lastmod mistakes worth flagging. The first is using the wrong date format. DD/MM/YYYY, MM-DD-YYYY, and any other non-ISO format are invalid and will cause the entry to be flagged in Search Console. The second is setting lastmod to a future date, which makes no sense and signals a broken sitemap generator.
3. The changefreq element
The changefreq element hints at how often the page is expected to change. It’s the most misunderstood element in the protocol, partly because the name suggests precision, but the actual behaviour is much looser.
The protocol allows exactly seven values for changefreq, no more, no less:
- always
- hourly
- daily
- weekly
- monthly
- yearly
- never
Anything else is invalid. You can’t write “biweekly” or “every-two-weeks” or “rarely”. If your sitemap generator produces values outside that list, the entry gets flagged.
The values themselves are mostly self-explanatory, with two worth calling out. The “always” value is reserved for content that changes on every access, like dynamically generated dashboards or real-time data feeds. Almost no site should ever use it for normal pages, because regular pages don’t change on every access. Marking a homepage “always” is overstating what the page does. The “never” value is the opposite, reserved for archived content that you don’t expect to change again. Useful for old news articles, historical archives, and other permanently static content.
The most important thing to understand about changefreq is that it’s a hint, not a binding instruction. The protocol explicitly says crawlers “may take this information into account” but aren’t bound by it. A page marked “daily” can be crawled less often than that if the search engine decides the content doesn’t actually change that frequently. A page marked “yearly” can be crawled more often if the search engine sees evidence the content is updating.
Common changefreq mistakes include overstating the change frequency to try to encourage more crawling (which doesn’t work), understating it to try to reduce crawl load (which also doesn’t really work), and treating it as a ranking signal (which it isn’t). The element is supposed to describe how often the content changes, nothing more.
4. The priority element
The priority element communicates the relative importance of each URL on your site. It accepts a decimal value between 0.0 and 1.0, with 0.5 as the default when the element is omitted.
The critical word in that description is “relative”. Priority is relative within your own site, not absolute across the web. Setting your homepage to 1.0 and your contact page to 0.3 tells the search engine the homepage matters more to you than the contact page. Setting every page on your site to 1.0 tells the search engine nothing useful, because the relative ordering disappears. If everything is top priority, nothing is.
A sensible priority scheme for most sites might look like this. Your homepage at 1.0. Your main section pages (services, products, blog index, about) at 0.8. Your important content pages at 0.7. Your regular content and posts at 0.5 (the default). Your archive and utility pages at 0.3. That’s not the only valid scheme, but it gives you the shape: clear ordering with meaningful gaps between tiers.
The common priority mistakes are setting every page to 1.0 (eliminating the relative information), using overly precise values like 0.73 or 0.667 (the protocol doesn’t care about decimal precision beyond one decimal place in practice), and confusing priority with ranking signals like PageRank (priority is about your communicated importance, not about how the page ranks against pages on other sites).
A note on element ordering
The protocol specifies that elements within a url block should appear in the order loc, lastmod, changefreq, priority. Most parsers accept any order, but following the canonical order keeps sitemaps readable to anyone debugging them and makes the file behave consistently across the various tools that parse XML sitemaps.
If you’re using a CMS or SEO plugin to generate your sitemap, this happens automatically. If you’re hand-rolling or doing custom generation, putting the elements in canonical order is one of those small touches that signals a careful implementation.
Where this leaves us
You now know what each XML sitemap element is designed to do. The loc element is the required anchor of every url entry. The lastmod element communicates when content last changed. The changefreq element hints at update frequency. The priority element signals relative importance within your own site. Each has its format, its rules, and its specific common mistakes.
That’s what the protocol intends. Whether the major search engines actually respect each of these elements when deciding what to crawl and how often, is a separate question, and the answer is more interesting than you might expect.
In the next lesson, we look at what Google actually does with the optional elements you’ve just learned about. Specifically, whether priority and changefreq carry the weight the protocol implies, or whether they’re largely ignored in practice. The answer changes how you should think about filling in those fields when you generate or audit a sitemap.
Up next: Does Google Actually Use Priority and Changefreq? →
This is Module 1: Lesson 8 of The Sitemap Series, a Technical SEO series on sitemaps from first principles, built for the AI Search era.