How to turn RSS and sitemap checks into a release gate
Many teams treat feed and sitemap problems as small cleanup work after a deploy. That is a mistake. If RSS or sitemap is broken, discovery and indexing break even when the page build itself succeeded.
Use the web automation and ops systems unit page as the index for follow-up posts on deploy verification, reporting loops, and review automation. If you need the broader baseline first, start with the rules you should fix first.
1. Treat feeds as release artifacts
RSS and sitemap files are not optional extras. They are part of the release surface, so they should be checked the same way you check static pages.
2. Verify presence before content
The first gate is simple: the files must exist in the built output. Only after that should you care about structure, URL correctness, and live fetch behavior.
- Baseline 1: `dist/rss.xml` exists
- Baseline 2: `dist/sitemap.xml` or your real sitemap entry exists
- Baseline 3: the files are not HTML fallbacks or empty output
3. Fail the build when baseline files are missing
A missing RSS or sitemap file should stop the release. If the pipeline only logs a warning, someone will ignore it under time pressure.
4. Keep the checks cheap
The point is not a huge XML validation framework. The point is a small repeatable check that runs fast enough to stay in the loop every time.
if (!existsSync('dist/rss.xml')) throw new Error('missing rss');
if (!existsSync('dist/sitemap.xml')) throw new Error('missing sitemap');
Once that baseline is stable, the next cheap checks are obvious: confirm the file contains XML, confirm the sitemap URL matches production, and confirm RSS points to real published URLs.
What to do first
Start with one postbuild script that confirms RSS and sitemap files exist in `dist`. Once that never breaks silently again, you can add content-level checks later.