How to verify a website release before search problems spread
A practical release check for important pages, feeds, sitemaps and the publishing route that puts them live.
Written by Rob KnottA successful build is not proof that the right site is live. A deployment can complete while omitting a feed, replacing a route with an error page or publishing an older version of an article. Those failures are easy to miss when the homepage still looks normal.
A small release check should establish what was expected, test the public result and leave enough evidence to diagnose a mismatch. The checks below are designed for teams that publish articles or make frequent changes to important search pages.
Define the expected release before it starts
Record the deployment identifier, intended content changes and the URLs that must work after publication. Include one representative URL for each important page type, rather than testing only the homepage. If an article is due, record its slug and publication date in the site’s editorial time zone.
Include supporting files in that list: the relevant sitemap, RSS or Atom feed, robots.txt and any assets needed to render the new page. A feed can disappear while the article page remains available, so it needs its own check.
Test the public response and the page behind it
Request the live URL after the deployment has finished and any agreed cache window has passed. Check the final URL, HTTP status and content type. Then inspect the returned body for the expected title, canonical URL, date and a meaningful portion of the article. A 200 response alone can still be a fallback page or an error rendered inside the site shell.
For feeds, parse the XML and compare the newest item with the article that should be live. Open that item’s link and check the article page too. For sitemaps, confirm the new canonical URL appears where expected. Google advises that sitemap lastmod values should reflect significant page changes and be consistently accurate; updating every date on every build is not a substitute for checking the actual content.
Compare the live deployment with the last good one
When a file is missing, compare the current deployment’s file list with a known good release. That narrows the problem to generation, packaging or upload. If the file exists in the build output but not in the deployed artifact, investigate the deployment path. If it is absent from both, investigate the content source and build steps.
Keep the previous deployment available for a controlled recovery. Restoring it may also roll back newer changes, so identify what those changes were before promoting an older release. A repair can instead preserve the current files and add the missing output, provided the resulting artifact is tested as a complete deployment.
Make failure visible to the right owner
Run the checks after the publication time and a short grace period in the site’s local time zone. Alert on a missing or invalid file, an overdue publication, or a newly broken route. Include the expected date, observed date or status, affected URL and deployment identifier so somebody can act without repeating the investigation.
Assign separate owners for editorial readiness and delivery. A technical monitor can prove that an article is absent; it cannot create an approved, accurate article on its own. The editorial calendar needs prepared work and a person responsible for the final decision, while the deployment process needs a check that rejects incomplete artifacts.
Key takeaways
- Check the public artifact, not only the build result.
- Verify page content, feeds and sitemaps as separate outputs.
- Compare a failed deployment with the last good release before restoring it.
- Record dates, URLs and deployment identifiers in actionable alerts.
- Give editorial supply and technical delivery clear owners.
Sources and further reading
About Rob Knott
Rob is an independent SEO and AI-search consultant with experience spanning LinkedIn, technical SEO and search leadership at MoreNiche. He helps teams turn difficult questions into clear decisions, practical plans and measurable next steps.
Available remotely for AI-search and GEO strategy, visibility baselines, website migrations, technical investigations, content planning and automation. Bring Rob in for a focused project, fractional support or ongoing strategic advice.
