Blog Sitemap: What It Should Contain (and What It Shouldn't)

A blog sitemap is an XML file listing the URLs on your blog you want search engines to know about. One rule governs the whole thing: list only canonical, indexable URLs that return a 200 status code. Every entry should be a page you would be happy to see ranking, at the exact address you want ranked. Anything else, a redirect, a noindexed page, a paginated archive, a parameter variant, does not belong.

This guide covers what goes in, what stays out, which XML fields Google actually reads, when you need a sitemap index file, and how to keep the file from going stale the moment you publish.

XML Sitemap vs HTML Sitemap

Two different files share the word "sitemap," and only one of them is the SEO artifact.

An XML sitemap is a machine-readable file written to the sitemaps.org 0.9 protocol. Search engines fetch it, parse it, and treat it as a list of candidate URLs to crawl. It usually lives at /sitemap.xml or /sitemap_index.xml. Nobody is meant to read it. This is the SEO artifact, and the rest of this guide is about it.

An HTML sitemap is an ordinary web page that links to your content, often at /sitemap/, organized by section. It exists for humans, and it works as a crawlable internal-linking surface as a side effect. Googlebot crawls it like any other page. It is a navigation aid, not a protocol.

A large blog can run both. But if someone asks whether your blog has a sitemap, they mean the XML file, and an HTML sitemap page is no substitute.

What Belongs in a Blog Sitemap

The inclusion test is one question: is this URL the canonical, indexable, 200-status address of a page I want in search results? If yes, include it. If any part fails, exclude it. For a typical business blog that resolves to:

Individual post URLs. The reason the file exists. Every published post meant to rank belongs in it, at its canonical URL, with the trailing slash convention your site actually serves.

The blog index page. Your /blog/ root, if it is a real page with content and internal links rather than a redirect.

Category pages, when they are canonical and substantive. A category page with fifteen posts, a description, and a self-referencing canonical is a legitimate landing page and can rank. A category page with two posts and no unique text is not.

Author pages and static pages inside the blog. Author archives can carry E-E-A-T weight when they include a genuine bio, credentials, and links, so include those and leave empty templates out. Same test for a resource hub or glossary index.

That is the entire list for most blogs.

What Does Not Belong in a Blog Sitemap

This is where most blogs get it wrong, usually because a plugin dumped every URL it could find into the file.

Redirected URLs. A URL returning a 301 is not a destination, it is a forwarding instruction. Listing it tells a crawler to fetch an address you have already told it not to use. This is the most common failure after a migration.

Noindexed pages. A page carrying both a noindex directive and a sitemap entry sends contradicting signals: the sitemap says "consider this for indexing," the meta tag says "do not index this." If the page should stay out of search, pull it from the sitemap too.

Paginated archive pages. URLs like /blog/2/ or /blog/page/3/ let readers and crawlers reach older posts. They are not landing pages, and their contents shift every time you publish. Let them stay crawlable and self-canonical, but keep them out of the sitemap.

Parameter URLs and other non-canonical duplicates. Anything carrying ?utm_source=, ?ref=, session identifiers, or filter and sort parameters. Same for http alongside https, www alongside non-www, or one post reachable under two category paths. One URL per page, matching the canonical tag exactly.

Thin tag pages. Blogs accumulate tags with one or two posts each, producing archives that near-duplicate each other and the posts they list. Note the distinction from crawl blocking: keeping tag pages out of the sitemap is a prioritization choice, while blocking them in robots.txt is usually a mistake, since crawlers use them as paths to your posts. Our robots.txt guide for blogs covers that line.

Pages returning 4xx or 5xx, and staging or preview URLs. Deleted posts linger for months when nothing regenerates the file, and draft routes leak in wherever the generator crawls a filesystem rather than a route list.

The Sitemap Fields That Actually Matter

The protocol defines four tags per URL entry. Only two earn their place, and Google is explicit about which. Here is a minimal, valid entry:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://yourdomain.com/blog/blog-sitemap-guide/</loc>
    <lastmod>2026-08-06</lastmod>
  </url>
</urlset>

<loc> is required and must be exact. The full absolute URL, correctly escaped, on the same host as the sitemap, matching the page's canonical tag character for character. A mismatch in protocol, subdomain, or trailing slash points the entry at a URL that is not your canonical.

<lastmod> matters only if it is true. Google's documentation states that it uses the <lastmod> value "if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate" (Build and submit a sitemap). The word doing the work is "verifiably." If your generator stamps today's date on every URL on every build, Google learns the field carries no information and stops trusting it. The value should reflect the last significant change to page content, not a template tweak or a rebuild. Use W3C Datetime format: 2026-08-06 or 2026-08-06T14:30:00+05:30.

<changefreq> and <priority> are ignored. Google's documentation says so directly: "Google ignores <priority> and <changefreq> values." Most generators still emit them because the protocol allows them. They cost nothing and buy nothing. Setting priority to 1.0 on every post does not make anything a priority.

Sitemap Index Files for Large Blogs

A single sitemap file is capped. Google's documentation states that all formats "limit a single sitemap to 50MB (uncompressed) or 50,000 URLs." Cross either limit and you split the file, then list the pieces in a sitemap index, a sitemap of sitemaps.

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://yourdomain.com/sitemap-posts.xml</loc>
    <lastmod>2026-08-06</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://yourdomain.com/sitemap-categories.xml</loc>
    <lastmod>2026-08-01</lastmod>
  </sitemap>
</sitemapindex>

Google's large sitemaps documentation notes that a sitemap index file may itself contain up to 50,000 loc tags, and that you can submit up to 500 sitemap index files per site in Search Console. Sitemaps may be gzip-compressed, but the 50MB ceiling applies to the uncompressed file.

Almost no blog approaches 50,000 URLs, so why does this matter at 400 posts? Because splitting by content type is diagnostically useful well before you are forced into it. Separate sitemaps for posts, categories, and pages let you read the Search Console Sitemaps report per file. One monolithic file gives you one aggregate number and no signal about where the problem sits.

How Search Engines Actually Use a Blog Sitemap

A sitemap is a discovery hint, not an indexing command. Google states it plainly: "submitting a sitemap is merely a hint: it doesn't guarantee that Google will download the sitemap or use the sitemap for crawling URLs on the site." Its overview documentation adds that a sitemap "doesn't guarantee that all the items in your sitemap will be crawled and indexed."

Take that literally, because the gap between "listed" and "crawled" is measurable. On our own blog, running a zero-intervention crawl experiment, posts that appeared in the sitemap the moment they published still sat at "Discovered - currently not indexed" in Search Console for one to three weeks. Posts published in the same window, on the same template, in the same sitemap, were crawled within two days. What differed was internal linking and Google's crawl scheduling.

So a sitemap removes the excuse that Google does not know a URL exists. It does not move that URL up the queue. Internal links from pages Google already crawls frequently do that, which is why every new post should ship with inbound links from existing posts (our internal linking guide covers how to build that mesh). Our guides on SEO crawling and blog indexing cover both sides of that pipeline.

Submitting Your Sitemap and Keeping It Fresh

Two submission methods are worth using.

Google Search Console. Open the Sitemaps report, enter your sitemap path, and submit. Google's documentation recommends this route because it lets you "see when Googlebot accessed the sitemap and also potential processing errors." Confirm the status reads Success. Do the same in Bing Webmaster Tools.

The robots.txt Sitemap: line. One line, and every crawler that reads the file finds your sitemap, including engines you never register with:

Sitemap: https://yourdomain.com/sitemap.xml

Note what is no longer on the list. Google retired the old unauthenticated sitemap ping endpoint in 2023, and its current documentation lists only Search Console, the Search Console API, the robots.txt line, and WebSub for Atom and RSS feeds. Tooling still hitting the ping URL is doing nothing.

Freshness is the part that quietly breaks. If your sitemap is built by a weekly cron job, by a plugin that rebuilds only on cache purge, or by a script someone runs by hand, every post published between rebuilds is missing from the file during the window when discovery matters most. Regeneration on publish is the requirement (platforms like Superblog rebuild the file on every deploy, which is the section after next). Anything slower is a stale file with a fresh-looking timestamp.

Validate before you rely on it. Run the file through our sitemap XML validator to confirm the syntax parses and the entries are well formed, then spot-check listed URLs by hand: each should return 200, not redirect, and carry a self-referencing canonical.

Common Blog Sitemap Mistakes

Stale lastmod on everything. A build process that stamps the current date on all URLs makes the field meaningless, and Google's use of lastmod is explicitly conditional on accuracy. If you cannot generate honest values, omit the field rather than fake it.

Redirected URLs after a migration. When you move platforms, the sitemap is what everyone forgets. The new file inherits old paths that now 301, or old URLs stay listed somewhere. Every entry should be a final destination. Regenerate after the migration completes, verify a sample returns 200 rather than 301, and resubmit in Search Console. Our WordPress migration guide covers the URL-preservation side of this.

Forgetting the sitemap after a platform switch. Related, and worse. The robots.txt Sitemap: line still points at /sitemap_index.xml from your old plugin, which now 404s, while your new sitemap sits at /sitemap.xml unreferenced and unsubmitted. Confirm the robots.txt line, the Search Console submission, and the live file agree, and delete any leftover second file.

Sitemap on the wrong host. A sitemap should list URLs on the same host that serves it. A file at blog.yourdomain.com/sitemap.xml listing yourdomain.com/blog/ URLs is a cross-host submission that requires verifying both properties.

Treating the sitemap as the indexing plan. It is a list, not a strategy. The rest of the technical baseline is in our blog SEO checklist.

How Superblog Handles Your Blog Sitemap

On WordPress the sitemap is a plugin's responsibility, which makes it a plugin conflict waiting to happen: two SEO plugins each generating a file, a caching layer serving last week's version, a rewrite rule that stops the file resolving after a core update. None of it announces itself. You find out when a post from a month ago is still not indexed.

Superblog regenerates your XML sitemap automatically on every deploy, and a deploy happens every time you publish. The file reflects your published content the moment it is live, with canonical URLs and correct trailing slashes. On subdomain and root-domain blogs, the Sitemap: line in robots.txt is generated for you and points at the right file. On subdirectory setups, robots.txt lives at your main site's root, so add one line there pointing at yoursite.com/blog/sitemap.xml. Canonical tags are correct on every page, including subdirectory setups like yoursite.com/blog, so sitemap URLs and page canonicals never drift apart. Multilingual blogs get hreflang annotations automatically. No plugin to install, no conflict to debug, no cron job to babysit.

If you want a blog where the discovery layer maintains itself, start a 7-day free trial (no credit card required) and publish on infrastructure that keeps your sitemap current for you.

FAQ

Does a blog need a sitemap?

Almost always yes. Google says most sites benefit from having one, and that you might not need one only if your site runs around 500 pages or fewer with comprehensive internal linking. A blog that publishes regularly outgrows that condition quickly, because each new post starts life with few inbound links. A sitemap guarantees Google knows the URL exists. It does not guarantee crawling or indexing.

How do I create a sitemap for my blog?

It depends on your platform. Managed platforms including Superblog generate and update the file automatically, so there is nothing to create. WordPress generates a basic sitemap in core and a fuller one through an SEO plugin. Static site generators build one at compile time. Manual generation with a third-party crawler is a last resort, because the file goes stale the moment you publish again. Whichever route you take, the file must regenerate on publish, not on a schedule.

Where should my blog sitemap be located?

At the root of the host that serves your blog, conventionally /sitemap.xml or /sitemap_index.xml. A subdomain blog at blog.yourdomain.com needs its sitemap on that host, while a subdirectory blog at yourdomain.com/blog is covered by the root domain's sitemap. Reference it from that host's robots.txt and submit it in Search Console.

Should category and tag pages be in my sitemap?

Category pages, yes, if they are canonical, indexable, and carry enough content to be worth ranking. Tag pages, usually no. Most blogs accumulate tags with one or two posts each, producing near-duplicate archives that add nothing to search results. Keep the substantial archives in and consider a noindex tag on the thinnest ones.

Does adding a URL to my sitemap get it indexed?

No. Google is explicit that a sitemap submission is a hint and does not guarantee listed URLs will be crawled or indexed. In our own testing, posts listed in the sitemap from the moment of publishing still sat undiscovered in Search Console for weeks while others were crawled within two days. The sitemap makes a URL known. Internal links from pages Google already crawls frequently are what get it fetched.

What happens if my sitemap has errors?

Search Console reports parse failures and unreachable files, and a file that fails to parse is not used at all. Softer errors are worse, because nothing flags them: redirected URLs, noindexed pages, and dishonest lastmod values are all valid XML, and they erode how much weight the file carries. Validate the syntax with a sitemap XML validator, then audit the entries for status codes and canonical agreement.