How to Run a Real
Website Smoke Test

What This Process Tested

A website smoke test should prove that a real visitor can become a real lead without the business process breaking. For sylvect.biz, that meant testing the deployed site, the intake form, Turnstile, Cloudflare Pages Functions, email routing, Calendly, resource pages, mobile layout, SEO basics, security headers, and production deployment behavior.

Production Availability

Before clicking through pages, check that the public site and important URLs return clean status codes.

curl -sS -o /tmp/home.html -w "home %{http_code} %{time_total}\n" https://example.com/
curl -sS -o /tmp/sitemap.xml -w "sitemap %{http_code} %{time_total}\n" https://example.com/sitemap.xml
curl -sS https://example.com/robots.txt
curl -sSI https://example.com/

The Lead Funnel

The intake form is the business-critical path. If a prospect fills it out and the owner never receives it, the website failed even if every page looks polished.

Test the lead form as a real prospect. Fill required fields with clearly marked SMOKE TEST data, verify anti-bot behavior, submit once, confirm the redirect, confirm owner notification delivery, confirm customer confirmation delivery, and verify no-token and honeypot guardrails. Do not modify production settings during the test.

For the documentation rerun, the form was screenshot without sending another live lead. The earlier remediation pass had already verified live submission and owner notification routing.

Calendly After Submission

The thank-you page needed to show the next step after intake. The remediation restored the Calendly path, added CSP frame permission, and kept a direct booking fallback.

Verify the booking flow after lead submission. Confirm all booking CTAs, branded redirects, thank-you page booking options, embedded scheduler behavior, and Content Security Policy frame permissions. Do not create a real calendar appointment unless I explicitly approve that final action.

Resources Section Cleanup

The resources section was checked as both a visitor-facing funnel and a search asset. Internal working labels that had leaked into the visitor experience were removed.

Audit the resources section as a visitor and as a search crawler. Confirm every listed resource opens, category labels make sense to readers, internal working labels are not visible, resource CTAs work, canonical metadata is present, and the newest article appears in the listing.

Service Offer Accuracy

The app-deployment page had a monthly support package that needed to become a contact option. The screenshot below verifies that the third card now routes the visitor toward a fit review instead of presenting a fixed monthly plan.

Review service pages for CTA accuracy. Confirm each package or option matches the current offer, pricing language is intentional, buttons route to the right form or section, and no outdated offer remains visible after deployment.

Mobile Rendering

Mobile layout failures are easy to miss when the site looks good on a desktop monitor. During the audit, two resource articles had mobile overflow issues. The remediation fixed the responsive layout.

Test the deployed site at common mobile widths. Check every key page for horizontal overflow, overlapping text, clipped buttons, inaccessible navigation, oversized tables, broken cards, tap target issues, and content hidden under sticky headers. Provide screenshots and CSS-level remediation suggestions.

Findings and Remediation

The first report grouped real failures instead of mixing them with cosmetic preferences. The main fixes covered CSP, Calendly, owner email routing, mobile overflow, resource labels, service offer language, and metadata.

Before and After Evidence

Evidence keeps the process honest. Each issue needed a before state, a fix, a production deploy, and a retest.

Final Production Verification

The final pass confirmed that the production domain served the remediated pages and that the focused browser pass had no remaining active smoke-test errors.

Verify the latest production deployment. Confirm the production domain serves the changed files, cache has propagated, critical pages return 200, redirects behave correctly, fixed UI text is visible, the form still submits, the booking flow still works, and the browser console is clean on the tested pages.