Engineering · SEO

Why Dynamic Sitemaps Matter for Privacy-First Websites (And How We Built Ours)

Published April 2026 · 8 min read · By the TraceNull Team

If you run a website that publishes content regularly — blog posts, landing pages, documentation — you've probably dealt with sitemaps. They're one of those "set it and forget it" SEO basics that everyone recommends. Generate an XML file, upload it to your root directory, point Google Search Console at it, and move on.

Until it breaks.

We recently hit exactly this problem at TraceNull. Our blog content was growing, new articles were being published, and our static sitemap.xml was silently falling behind. Pages existed on the site that search engines didn't know about. So we rebuilt our sitemap system from the ground up — dynamically generated, always accurate, and fully compatible with our privacy-first architecture.

Here's why we did it, how it works, and why it matters more than you might think — especially if you're building privacy-respecting web properties.

The Problem With Static Sitemaps

A static sitemap is an XML file that lists every URL on your site along with metadata like last-modified dates, change frequency, and priority. It's simple and it works — as long as you remember to regenerate it every time your content changes.

In practice, static sitemaps fail in predictable ways:

New pages are missing. You publish a blog post but forget to regenerate the sitemap. Google doesn't discover the page for days or weeks.
Deleted pages linger. You remove or unpublish content, but the sitemap still points to it. Search engines crawl dead URLs and may flag soft 404 errors.
Last-modified dates are stale. If you update an article but don't touch the sitemap, search engines have no signal to re-crawl it.
Build pipelines add complexity. You need a CI/CD step, a build script, or a manual process to keep the file in sync. One more thing to break.

For a small, rarely-updated site, none of this matters much. For a product like TraceNull — where we're actively publishing guides, feature announcements, and comparison articles — it's a real SEO liability.

Our Approach: Generate the Sitemap at Request Time

Instead of maintaining a static file, we now generate sitemap.xml dynamically every time it's requested. The sitemap route in our Node.js + Express application reads all published blog articles from our JSON content files and builds the XML response on the fly.

Key principle: The sitemap is always a reflection of what actually exists on the site right now — not what existed the last time someone remembered to run a build script.

Here's the high-level architecture:

Blog articles are stored as JSON files in a /blog directory. Each file contains the article's slug, title, publication date, and content. This is the single source of truth.

The /sitemap.xml route reads the directory at request time. Using Node.js fs module, it scans the blog directory, parses each JSON file, and extracts the slug and publication date.

XML is constructed and returned with the correct Content-Type: application/xml header. Each blog URL gets a <url> entry with <loc>, <lastmod>, and appropriate <changefreq> and <priority> values.

Static pages are included too. The homepage, pricing page, and other fixed routes are hardcoded in the sitemap generator with their own priority values.

The result: publish a new article, and it appears in the sitemap immediately. Delete one, and it vanishes. No build step, no cron job, no stale data.

A Simplified Example

For developers curious about the pattern, here's a stripped-down version of how dynamic sitemap generation works in Express:

const fs = require('fs');
const path = require('path');

app.get('/sitemap.xml', (req, res) => {
  const blogDir = path.join(__dirname, 'blog');
  const files = fs.readdirSync(blogDir).filter(f => f.endsWith('.json'));

  let urls = `<url>
    <loc>https://tracenull.cc/</loc>
    <priority>1.0</priority>
  </url>`;

  for (const file of files) {
    const data = JSON.parse(fs.readFileSync(path.join(blogDir, file)));
    urls += `<url>
      <loc>https://tracenull.cc/blog/${data.slug}</loc>
      <lastmod>${data.datePublished}</lastmod>
      <priority>0.7</priority>
    </url>`;
  }

  const sitemap = `<?xml version="1.0" encoding="UTF-8"?>
  <urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
    ${urls}
  </urlset>`;

  res.header('Content-Type', 'application/xml');
  res.send(sitemap);
});

Note: In production, you'll want to add error handling, optional caching (e.g., a 10-minute TTL), and validation that each JSON file has the required fields. Our initial version actually shipped with a missing fs require — a reminder that even simple features need testing.

Why This Matters for Privacy-First Sites

You might wonder what sitemaps have to do with privacy. The connection is more important than it appears.

No Third-Party Sitemap Services

Many sites use third-party tools or WordPress plugins to generate sitemaps. These tools often phone home, collect analytics on your site structure, or inject tracking parameters. By generating our sitemap in-house with zero external dependencies, we eliminate another potential data leak.

No User Data in the Pipeline

Our sitemap generation reads static JSON files from disk. It doesn't query a database that contains user-generated content. It doesn't touch analytics tables. It doesn't log who requested the sitemap. The process is completely isolated from any user data.

Transparency Through Simplicity

Privacy-first architecture isn't just about what you don't collect — it's about building systems simple enough to audit. Our entire sitemap system is under 50 lines of code. Anyone on the team (or any user who reads this article) can understand exactly what it does and verify that it respects privacy.

SEO Benefits Beyond Discovery

A well-maintained, always-accurate sitemap does more than just help Google find your pages:

Benefit	How Dynamic Sitemaps Help
Faster indexing	New content appears in the sitemap immediately, so search engines discover it on their next crawl
Accurate last-modified dates	Dates come directly from article metadata, signaling freshness to crawlers
No crawl budget waste	Deleted pages are removed instantly, so search engines don't waste time on 404s
Better Search Console data	When your sitemap matches reality, coverage reports in GSC are actually meaningful
Automatic scaling	Publish 10 articles or 1,000 — the system works the same with no manual intervention

Lessons From Our Implementation

A few things we learned shipping this feature that might save you time:

Don't forget your imports. Our first deploy failed because the fs module wasn't imported in the route file. Node.js doesn't always fail loudly with missing requires depending on your setup — write a test that actually hits the /sitemap.xml endpoint.
Filter your content directory carefully. We had a _layout.json template file in the blog directory that isn't a real article. The sitemap generator needs to skip files like this, or you'll have ghost URLs in your sitemap.
Set the right Content-Type. Serving XML with text/html headers causes some crawlers and validators to reject or misparse the sitemap. Always set application/xml.
Consider light caching. If your blog directory has hundreds of files, reading them all on every request adds latency. A simple in-memory cache with a short TTL (5–10 minutes) gives you the best of both worlds.

The Bigger Picture: Every Layer Matters

At TraceNull, we think about privacy at every layer of the stack. Our URL shortener strips referrer headers three ways (Node.js response headers, Caddy server headers, and HTML meta tags). We don't store IP addresses. We don't use third-party analytics.

The sitemap is a small piece of this puzzle, but it reflects the same philosophy: build it yourself, keep it simple, keep it clean. Every external service you don't use is one fewer vector for data leakage. Every line of code you can audit is one more guarantee you can make to your users.

If you're building a privacy-first product, don't overlook the infrastructure details. The sitemaps, the headers, the server configuration — these "boring" layers are where privacy is actually won or lost.

Try TraceNull — The Privacy-First URL Shortener

Shorten links, strip referrer headers, and protect your users' privacy. No tracking, no IP storage, GDPR-compliant by design. Free tier available — no credit card required.

Get Started Free