Blog

A Post-Deployment Website Smoke Test You Can Finish in 15 Minutes

Use a focused 15-minute smoke test after a website release to check public pages, assets, key actions, and search settings before closing the deployment.

Sep 6, 2026 | 3 min read

A deployment can finish successfully while the public website serves yesterday's page, a missing stylesheet, or a broken contact form. The deployment log tells you that the release process completed. A smoke test tells you whether a small set of important visitor experiences still works.

Keep this test short enough to run after every release. Its purpose is to catch obvious failures before the person who understands the change moves on to something else. It does not replace your automated test suite or a full accessibility, security, or performance review.

Before the release: write down five URLs

Choose the homepage, a page that brings qualified traffic, a conversion page, a recently changed page, and a URL that should return a genuine not-found response. For a small service business, that might mean the homepage, the main service page, contact, a revised case study, and an invented path.

Beside each URL, record what a pass means. “Loads” is too vague. “Shows the current service name, loads the stylesheet, and links to the contact form” gives the reviewer something concrete to verify. Add the release identifier and one visible change that distinguishes the new version from the old.

Minutes 1–4: check the public response

Open the production address in a signed-out browser window. Confirm the final hostname, path, and visible release change. Visit the selected URLs directly instead of reaching every page through the homepage.

Look for certificate warnings, maintenance screens, login prompts, unexpected redirects, and errors. Use the browser's Network panel to inspect the document response when the visible page is ambiguous. A friendly error template can look polished while the requested content is missing.

Check the phone layout too. Pay particular attention to navigation, sticky elements, long button labels, and the first action a visitor needs to take. A working desktop menu does not establish that mobile navigation survived the release.

Minutes 5–9: complete one important action

Choose the action affected by the release: send an authorized test inquiry, complete a sandbox checkout, or follow the registration flow with an approved test account. Verify the outcome beyond the success message. A form is not finished until the inquiry reaches its intended destination.

If an action creates a real charge, booking, or customer notification, use the team's established test procedure. Record which part was tested and which part was deliberately left outside the smoke test. “Checkout button opens” and “payment completed” are different results.

Minutes 10–12: inspect the shared template

Compare the title, canonical URL, and robots meta setting on a representative public page with the expected release state. Open robots.txt and the sitemap if the deployment changes routing, SEO settings, or content publication.

This is a comparison exercise. An unexpected change needs an explanation, but it does not automatically establish an attack. For broader incident symptoms, use the existing website investigation checklist.

Minutes 13–15: make the release decision

Use a small record rather than a long narrative:

  • Release and review time, including timezone.
  • URLs and actions actually tested.
  • Expected changes confirmed.
  • Unexpected findings, their owner, and the next decision time.
  • Decision: accepted, held for investigation, or sent to the rollback owner.

For example, a changed footer year should not block an unrelated release. A form that reports success without delivering the inquiry should. Decide those thresholds before a busy launch, when the team has time to discuss tradeoffs.

If a failure appears, preserve the response and screenshot before changing the system again. Retest the failed check after the fix, plus the nearby behavior the fix could affect.

Ambastly's free website integrity check can add an outside view of public signals to this routine. Keep the browser action test alongside it: an external page check does not confirm that your customer's entire journey succeeded.