Sitemap Best Practices for Blogs: What Google Actually Uses (and What It Ignores)

Most sitemap advice treats every field in the file as a lever. It isn't. Google's own documentation is blunt about it: "Google ignores <priority> and <changefreq> values." What Google does use is the list of URLs itself and, when it can trust it, the <lastmod> date.

So the short version of sitemap best practices for a blog is this: list only the canonical, indexable URLs you want in search results, keep lastmod honest, reference the file in robots.txt and submit it in Search Console, and stop tuning the fields Google throws away. Everything below is the detail behind each of those.

The Short Version: What Google Reads in Your Sitemap

Here is every element of a standard XML sitemap entry, and what Google says it does with it.

| Element | Does Google use it? | What to do | | --- | --- | --- | | <loc> | Yes — this is the URL it will try to crawl | Use the full, absolute, canonical URL | | <lastmod> | Yes, if it's "consistently and verifiably" accurate | Change it only when the page meaningfully changes | | <changefreq> | No | Leave it or remove it; it has no effect on Google | | <priority> | No | Same — don't spend time tuning it |

That table covers most of the decisions you'll make. The rest of this guide is about the two that do matter: which URLs go into <loc>, and how to keep <lastmod> believable.

Do You Even Need a Sitemap on a Blog?

Not always. Google's overview of sitemaps says you might not need one if your site is "small" — which it defines as "about 500 pages or fewer" — and "comprehensively linked internally," with few media files or news pages you want to show in search.

Google lists the opposite cases where a sitemap helps most:

• Your site is large, so it's harder to make sure every page is linked from at least one other page.
• Your site is new and has few external links to it, so Googlebot has fewer paths to discover your pages.
• You have a lot of rich media (video, images) or appear in Google News.

A new blog often fits the second case. And in practice most blogging platforms and SEO plugins generate a sitemap automatically, so the real question usually isn't whether to have one — it's whether the one you have is listing the right things.

Which URLs Belong in Your Sitemap

Google's instruction is simple: "Include the URLs in your sitemap that you want to see in Google's search results." The same page notes that "Google generally shows the canonical URLs in its search results." Put those together and you get the rule: one entry per page you want indexed, using the exact URL you've chosen as canonical.

On a blog, that means your published posts and the key pages you want ranking. It also means keeping out URLs that send Google the opposite signal:

• Redirected URLs. If an old post URL now 301s to a new one, list the destination, not the old address. Submitting redirecting URLs is one way to end up with a pile of Page with redirect statuses in Search Console.
• Pages marked noindex. Listing a page in the sitemap while telling Google not to index it is a contradiction. If you see Excluded by 'noindex' tag on URLs you submitted, one of the two signals is wrong.
• Non-canonical duplicates. Tracking-parameter versions, http versus https, and trailing-slash variants should not appear. Each listed URL should match the canonical tag on the page itself — the logic is the same as a self-referencing canonical tag.
• Thin archive pages you don't want ranking. Tag pages, date archives, and paginated lists are worth including only if you actually want them in search results.

None of these mistakes will usually cause an error on its own. The cost is quieter: you're asking Google to spend time on URLs you don't want indexed, and you're making the Indexing reports harder to read, because real problems get mixed in with the noise.

How to Get lastmod Right

lastmod is the one optional field Google says it actively uses. When Google announced changes to sitemap handling in June 2023, it explained that lastmod is "useful in many cases and we're using it as a signal for scheduling crawls to URLs that we previously discovered."

The catch is trust. In the same post, Google spelled out what happens when the date doesn't reflect reality: "if your page changed 7 years ago, but you're telling us in the lastmod element that it changed yesterday, eventually we're not going to believe you anymore when it comes to the last modified date of your pages."

Three rules follow from that.

Update it for significant changes only. Google's documentation says lastmod "should reflect the date and time of the last significant update to the page," and gives the counter-example directly: an update to the copyright date is not significant. The 2023 post lists what does count — changing the primary text, adding or changing structured data, or updating links. A sidebar widget or footer change does not.

Don't let the sitemap generator set the date. The sitemap protocol itself says the date "must be set to the date the linked page was last modified, not when the sitemap is generated." This is how a blog's lastmod can go wrong without anyone touching it: a static site build or plugin stamps every URL with the build time, so every page claims it changed today. Open your sitemap and look. If every entry shows the same timestamp, that's what is happening.

Leave it out when you can't be accurate. Google says it's fine to include lastmod only for the pages you're confident about. Its own example is a homepage or category page that simply aggregates other content and has no clear modification date of its own.

The format is W3C Datetime, which allows a plain YYYY-MM-DD date. If the format is wrong, Search Console will flag it after you submit the sitemap.

This is also why lastmod and content updates belong together. When you refresh an older post in a way that changes what it says, updating lastmod is the honest signal that it's worth recrawling. Bumping dates on posts you haven't really changed is exactly the pattern Google describes learning to ignore.

Why Sitemap Priority and Changefreq Don't Matter

These two fields generate a surprising amount of advice, so it's worth being precise. Google's sitemap documentation says it ignores both. The 2023 announcement repeated it — "Google still doesn't use the changefreq or priority elements at all" — and explained why:

• changefreq is "conceptually overlapping with lastmod." A real modification date tells Google more than a guess about how often a page might change.
• priority is "a heavily subjective field," and Google says that based on its internal studies it "generally doesn't accurately reflect the actual priority of a page relative to other pages on a site."

The practical takeaway: if your plugin outputs these fields, there's no need to remove them, and there's no point adjusting them. Setting your best post to 1.0 and everything else to 0.5 changes nothing about how Google crawls your blog. The way to tell Google a page matters is to link to it from your other pages.

The Technical Rules That Do Matter

These come straight from Google's "Build and submit a sitemap" documentation, and getting them wrong is what produces errors in Search Console:

1. Use absolute URLs. "Use fully-qualified, absolute URLs in your sitemaps." Google "will attempt to crawl your URLs exactly as listed," so /my-post is not enough — it must be https://example.com/my-post.
2. Encode the file as UTF-8. This is a requirement, not a recommendation.
3. Respect the size limits. A single sitemap is limited to 50 MB uncompressed or 50,000 URLs. A blog rarely gets close, but if it does, split the file and use a sitemap index.
4. Put it at the site root. A sitemap "affects only descendants of the parent directory," so a file at the root can cover the whole site.
5. Tell Google where it is. Add a Sitemap: line to robots.txt, submit it in the Search Console Sitemaps report, or submit it through the Search Console API. The old "ping" URL is no longer an option: Google announced in June 2023 that the endpoint would stop working within six months, and requests to it now return a 404.

If you submit and the status comes back as Couldn't fetch, the file isn't reaching Google at all — the step-by-step diagnosis is in our guide to Sitemap could not be read.

What a Good Sitemap Won't Do

Even a perfect sitemap is a hint, not an instruction. Google says submitting one "doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site," and the overview page adds that it "doesn't guarantee that all the items in your sitemap will be crawled and indexed."

Two consequences are worth keeping in mind.

First, a sitemap doesn't replace internal links. A post that appears in your sitemap but isn't linked from anywhere on your blog is still an orphan page. Google can discover it, but nothing on your site tells Google — or readers — that it matters.

Second, "submitted" and "indexed" are different numbers, and the gap between them is normal. If a large share of your sitemap URLs never make it into the index, the sitemap is usually not the cause. The reasons, and what to do about them, are covered in Google not indexing all your sitemap URLs.

Checking That Your Sitemap Is Doing Its Job

A quick audit you can run in a few minutes:

• Open your sitemap and confirm every URL is https, absolute, and matches the page's canonical.
• Spot-check a few lastmod values. If they all share today's timestamp, fix the generator before anything else.
• Check that no listed URL redirects or carries a noindex tag.
• In Search Console's Sitemaps report, confirm the status is Success and the discovered page count looks right.

After that, the useful signal is downstream: are new posts actually being picked up? Traffic Monitor doesn't read your sitemap, but it pulls Search Console clicks and impressions for each post daily, so a newly published post that never starts earning impressions shows up quickly instead of waiting for a monthly check. If that would help, you can connect your blog with read-only Search Console access.

Whichever way you check it, a good blog sitemap is mostly about restraint: list the pages you want found, date them honestly, and ignore the fields Google ignores.