// checklist //
The website deployment
checklist.
A website deployment checklist in three phases: what to verify before you ship, the launch steps themselves, and the post-deploy checks that catch what staging never shows. The third phase is where most silent damage happens - and the easiest one to automate.
Phase 1: Pre-deploy
- All tests green; build reproducible from the release branch.
- Staging reviewed on desktop and mobile for the pages this release touches.
- Database migrations rehearsed; rollback path written down, not assumed.
- Fresh backup taken and verified.
- SEO state on staging checked: intended titles, descriptions, canonicals pointing at the PRODUCTION domain, robots meta correct (staging usually noindexes - production must not inherit it).
- Redirect map prepared for any changed or removed URLs.
- Baseline captured: current production state of key pages recorded for comparison.
Phase 2: Deploy
- Ship during low-traffic hours when the release is risky.
- Run migrations; watch error rates during rollout.
- Invalidate CDN/page caches so users get the new release, whole.
- Confirm SSL and DNS if infrastructure changed.
- Smoke-test the golden path immediately: home, login, one conversion flow.
Phase 3: Post-deploy (where silent breakage lives)
- Every key page returns 200 - not just the homepage.
- Visual state on key pages matches intent - no reflowed layouts, missing sections, or font fallbacks.
- Robots meta: NO unexpected noindex anywhere (the classic staging leak).
- Canonicals point at production URLs, not staging.
- Old URLs 301 to the right destinations; no new redirect chains.
- Analytics, tag manager, and pixels present and firing on key templates.
- Payment/checkout scripts intact; conversion CTAs exist, visible, correctly linked.
- Internal links on updated pages resolve; sitemap.xml regenerated and reachable.
- Page weight and response times within normal range of pre-deploy baseline.
- Forms submit end-to-end (a real test submission, not a glance).
Automating phase 3
Phase 3 is a diff problem: “what does production look like now versus before the release?” That is exactly what baseline change monitoring does. With MyKavo, the pre-deploy baseline is already there; run a scan after shipping and every difference across visual state, SEO tags, links, scripts, and performance is listed with severity and before-and-after evidence. Expected changes: approve into the new baseline. Unexpected ones: fixed while the deploy is still warm - not discovered in next month's traffic report. Check a single URL's redirect behavior anytime with the free Redirect Chain Checker.
Frequently asked questions
What should a website deployment checklist include?
Three phases. Pre-deploy: tests green, staging reviewed, backups and rollback ready, SEO tags verified on staging. Deploy: migrations, cache invalidation, DNS/SSL if applicable. Post-deploy: verify real pages - status codes, visual state, SEO tags, redirects, tracking scripts, forms - because this is where silent breakage hides.
What is the most commonly missed step?
Post-deploy verification beyond the homepage. Classic misses: a noindex tag shipped from staging, canonicals pointing at the staging domain, the analytics snippet dropped from the new layout, and redirects lost during a URL restructure. All invisible on a quick homepage glance.
How do I verify a deployment automatically?
Baseline your key pages before the release, then scan right after it. A change-monitoring scan compares every page against the pre-deploy baseline and reports exactly what the release changed - expected changes get approved, unexpected ones get fixed while the deploy is still fresh.
Does this apply to CMS publishes, not just code deploys?
Yes. A Webflow publish, a WordPress plugin update, or a big CMS content push is a deployment in effect: the live site changes. The post-deploy phase of the checklist applies unchanged - which is why continuous monitoring beats remembering to check.