Sitemap Best Practices for a SaaS Blog That Ships Daily

TL;DR A good sitemap for a small SaaS blog is a short, honest list: every canonical, indexable URL you want in Google, a lastmod date that only changes when the page really changes, and nothing you've deleted, redirected or noindexed. Submit it once in Search Console and reference it in robots.txt. After that, it's a discovery hint, not a promise that anything gets indexed.

This blog publishes a post every day. Every day a build runs, and every build regenerates the sitemap from the MDX files in the repo. I didn't think about that sitemap for weeks. Then I actually read the code that produces it and found two things Google ignores and one that would quietly start lying the first time I refresh an old post.

None of that is dramatic. It's the kind of sitemap drift that happens on every small site that ships often, and it's why I think most "sitemap best practices" advice aims at the wrong reader. The XML spec isn't the hard part. The hard part is keeping the file truthful when you publish daily and nobody reviews it.

So this isn't an XML reference. It's the short checklist I'd use on a small SaaS blog, plus what our own setup gets right and wrong.

Sitemap best practices: what the file is actually for

Start with what a sitemap can't do. Google's build-a-sitemap guide says 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." The Sitemaps report help page repeats it: "There is no guarantee that a page URL discovered in a sitemap has been or will be crawled or indexed by Google."

So a sitemap helps with discovery and crawl scheduling. It doesn't help with indexing decisions. If your posts are stuck in Discovered, currently not indexed or Crawled, currently not indexed, a cleaner sitemap won't get them out. Those are quality and prioritization problems.

By Google's own definition, most indie SaaS sites don't strictly need a sitemap. The sitemaps overview says you might not need one if your site is "small," meaning "about 500 pages or fewer," and comprehensively linked internally. Boomranq has about 90 posts. We're small.

But the same page lists "your site is new with few external links" as a reason you might need one, and that describes nearly every bootstrapped SaaS blog. When few sites link to you, Google has fewer paths to your new URLs. And the overview adds that "in most cases, your site will benefit from having a sitemap." So keep one. Just don't mistake it for an indexing lever.

The small-site sitemap checklist

These are the sitemap SEO best practices I'd actually enforce. Everything else is optional.

Rule	Why it matters	Source
List only canonical, indexable URLs	Google wants the versions you want in results	Build a sitemap
Use absolute URLs	Google crawls exactly what you list, so relative paths don't work	Build a sitemap
Keep lastmod truthful	Google uses it only when it's consistently accurate	Build a sitemap
Remove deleted, redirected and noindexed URLs	Otherwise you're sending mixed signals	Consolidate duplicate URLs
Skip changefreq and priority	Google ignores both	Build a sitemap
Stay under 50,000 URLs and 50MB uncompressed per file	Hard limit; split with a sitemap index if needed	Build a sitemap
Encode as UTF-8	Required format	Build a sitemap

A daily-publishing blog will take decades to hit the 50,000-URL limit. The first four rows are where small sites actually go wrong.

Canonical, indexable URLs only

Your sitemap should match your canonical tags exactly. Same protocol, same host, same trailing-slash choice. If a post's canonical points to the version without "www," the sitemap should list that version too.

Google treats sitemap inclusion as a canonical signal, but a weak one. The duplicate URL consolidation docs call it "a weak signal that helps the URLs that are included in a sitemap become canonical" and say it's less powerful than rel canonical. So a sitemap can't fix a canonical problem. But if it disagrees with your canonical tags, it adds noise to one. If Search Console already shows Duplicate without user-selected canonical, check the sitemap first.

What to keep out:

Noindexed pages. Listing a URL means "please index this," and noindex means the opposite. I covered when to use noindex in robots.txt vs noindex for SaaS.
URLs disallowed in robots.txt. Google can't crawl them, so listing them does nothing useful.
Redirecting URLs. List the destination, not the old slug.
Tag archives, pagination and search results, unless you really want them to rank.
App routes, login walls and preview deploys.

Truthful lastmod

This is the rule that matters most for a daily blog, and the one most generators get wrong.

Google's June 2023 post on the sitemaps ping deprecation says Google uses lastmod "as a signal for scheduling crawls to URLs that we previously discovered." Then it adds the warning: "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."

Once Google stops trusting your dates, you've lost the one sitemap field that helps small sites. That's a big deal for a refresh strategy. If you update old posts to win back rankings, a trustworthy lastmod is how Google learns about the update without waiting for a routine recrawl.

What counts as a change? The same post says "last significant modification": change lastmod if you "changed the primary text, added or changed structured data, or updated some links." Don't change it for a footer tweak. The build guide adds that updating the copyright date doesn't count.

The most common way to break this is to stamp every URL with the build time. On a site that deploys every day, that tells Google every page changed today. Every day. That's exactly the pattern the 2023 post warns about.

You're also allowed to leave lastmod out. The same post says it's fine to omit it for pages like the homepage or a category page that "just aggregates the other pages on the site."

Removed posts

When you delete a post, three things should happen together:

The URL returns a 404 or 410, not a 200 page that says "not found." That's a soft 404, and it's a common mistake on custom 404 templates.
The URL leaves the sitemap on the next build.
Internal links pointing at it get updated or removed.

If you merge the post into another one, add a 301 redirect and list only the destination. Don't keep the old URL in the sitemap "so Google notices the redirect." That's listing a non-canonical URL, which breaks the first rule.

The reverse problem matters too: a live post that no page links to. A sitemap will still get it discovered, which hides the real issue. I wrote about why that's a trap in orphan pages SEO. A sitemap is a backup for internal links, not a replacement.

A copyable XML example

Here's all a small blog needs. Two posts, absolute URLs, a lastmod on each, no changefreq, no priority:

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/blog/first-post</loc>
    <lastmod>2026-09-12</lastmod>
  </url>
  <url>
    <loc>https://example.com/blog/second-post</loc>
    <lastmod>2026-09-28</lastmod>
  </url>
</urlset>

That's the full XML sitemap best practices story for most indie SaaS sites. Anything more is for image, video, news or multilingual sites. (Yes, the namespace URL is http, not https. Google's 2023 post says that's intentional.)

How our own Next.js sitemap stacks up

Boomranq's blog is plain MDX files in the repo. Next.js generates the sitemap at build time in app/sitemap.ts:

const posts = getAllPosts().map((post) => ({
  url: `${SITE_URL}/blog/${post.slug}`,
  lastModified: post.date ? new Date(post.date) : new Date(),
  changeFrequency: "monthly",
  priority: 0.7,
}));

return [
  { url: SITE_URL, changeFrequency: "weekly", priority: 1 },
  { url: `${SITE_URL}/blog`, changeFrequency: "weekly", priority: 0.8 },
  ...posts,
];

Here's my honest review against the checklist.

What works. URLs are absolute and built from the same slug as each post's canonical tag. The getAllPosts function filters out any post marked draft: true when the app is built for production. And the post page returns a 404 for drafts in production, so a draft can't show up in the sitemap or load as a live page. The locked /app and /api/ routes are disallowed in app/robots.ts and never appear in the sitemap. The same robots file points crawlers at /sitemap.xml. Deleting an MDX file drops the post from the sitemap on the next build, and because the post route pre-renders only known slugs, the old URL returns a 404. The homepage and blog index have no lastModified, which is what Google says is fine for aggregate pages.

What's dead weight. Every entry sets changeFrequency and priority. Google ignores both. They don't hurt anything, but they're noise. I'll remove them so nobody reading the code thinks they do something.

What will break. Two things, both about lastmod:

lastModified is the publish date from frontmatter. That's accurate today because we haven't refreshed any posts yet. The first time I rewrite an old post, the sitemap will keep reporting the original publish date, and Google won't hear about the change. The fix is an optional updated frontmatter field that I change by hand on significant edits, with lastModified using it when it's set.
If a post ever ships without a date, the fallback is new Date(), which is the build time. We build every day, so that post would claim a fresh modification every day. Every post has a date right now, but I'd rather fail the build than silently fall back to "today."

None of these bugs would show up in Search Console. The Sitemaps report would say "Success" either way. That's the real danger of generated sitemaps: they're valid XML long after they stop being true.

Submitting it to Google

Google's build guide lists three main ways to submit (plus WebSub for Atom and RSS feeds): the Search Console Sitemaps report, a Sitemap line in robots.txt, and the Search Console API. For a small site, do the first two once:

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

Then submit the same URL in Search Console. The robots.txt line lets any crawler find the file. The Search Console submission gives you status reporting, because the Sitemaps report tracks sitemaps submitted through the report or the API. It shows whether the sitemap was processed successfully, had errors, or couldn't be fetched.

You don't need to resubmit every time you publish. The same help page says to resubmit only after big changes and otherwise "let Google follow its regular crawling schedule."

And stop pinging. If an old plugin or deploy script still hits Google's sitemap ping URL, that endpoint is dead. Google announced in June 2023 that it would stop working within six months and that requests would return a 404. The same post says leftover ping code won't cause problems, but it won't do anything useful either.

The five-minute audit

If you want the Google sitemap best practices in one pass, here's what I'd check this week:

Open your sitemap in a browser. Search it for "draft," "preview," "tag," "page=" and your staging domain.
Spot-check five URLs. Each should return a 200, have no noindex, and have a canonical tag that points to itself.
Compare lastmod values across two deploys a day apart. If every value changed, your generator is stamping build time.
Open the Sitemaps report in Search Console and confirm the status is "Success."
Check your deploy scripts and plugins for a ping call and delete it.

If you're earlier in the journey, this belongs on the SaaS SEO checklist for your first six months, right after connecting Search Console. And if pages you want are missing from Google entirely, start with the diagnostic for a website not showing up on Google. The sitemap is rarely the cause.

The bigger point is the one I keep coming back to with Boomranq. On a low-authority site, Google hands you a small crawl and indexing budget, and every signal you send either earns trust or burns it. That's why I rank sitemap best practices below content choices: most sitemap XML best practices boil down to "don't lie," and a sitemap full of honest, canonical URLs and dates helps a little. A calendar full of winnable topics helps a lot more. You need both to be true, because Google checks.