Publish and verify a static website

Build once, inspect the artifact

A preview should represent the exact source and dependency lockfile that passed checks. Record the commit and deployment identifier. Avoid changing production configuration during an untracked manual build.

Preview safely

Preview URLs must use noindex controls or access protection. They should not emit the preview host as a production canonical. Exercise deep links, error states, copy or form behavior, mobile layout, and content review in the preview.

Promote only after gates pass

Run type, lint, unit, content, link, build, browser, accessibility, and security checks. If the platform supports promotion, promote the validated artifact instead of rebuilding different source for production.

Verify the real domain

Check HTTPS, alternate-host redirects, status codes, canonical tags, robots, sitemap, structured data, primary journeys, telemetry receipt, and availability checks. Do not replace this step with a deployment-success message.

Preserve rollback

Identify the prior healthy artifact and document the rollback operation before promotion. Practice against a preview or noncritical release so the procedure is not theoretical.

How the deployment path actually behaves

A static deployment still has several moving parts: source revision, dependency lockfile, build image, environment variables, generated artifact, provider configuration, domain alias, content delivery network, and browser cache. A failure can enter at any boundary. “Build succeeded” reports only that the provider produced an artifact; it does not prove that the canonical domain serves that artifact or that every route returns the intended status.

Treat the commit and deployment identifier as a pair. A preview should expose which commit it represents, and the release record should name the exact preview that was promoted. If the platform rebuilds for production, compare the dependency lock, build logs, environment, and output so the second artifact is not silently different.

DNS and TLS are part of delivery. The apex and www host may point to different projects, redirects can loop, and cached permanent redirects can conceal a repair. Test from a clean session and inspect raw response headers. A single canonical host should win in one permanent hop while preserving the path and query when appropriate.

Decisions and trade-offs

Preview protection and noindex address different risks. Access protection limits who can open a preview; noindex asks supporting crawlers not to include it. Use protection for confidential work. Use noindex and production-safe canonicals for public previews, but remember that a robots block can prevent a crawler from seeing the noindex directive.

Immutable assets can receive long cache lifetimes when filenames change with content. HTML and route responses need a policy that allows corrections and rollbacks to appear promptly. Do not attach an immutable policy to a stable HTML URL. Verify cache headers on the real response rather than assuming framework defaults match the host.

Choose promotion when it preserves the validated artifact. Choose a rebuild only when the platform cannot promote or when environment-specific generation is an explicit, tested requirement. In either case, keep the rollback unit small: the prior deployment should be identifiable without reconstructing an old local environment during an incident.

Accessibility and content consequences

Production fonts can fail, consent or protection layers can capture focus, and CDN behavior can change asset timing. Repeat the keyboard, visible-focus, screen-reader, 200% zoom, 320 CSS pixel, reduced-motion, and forced-color checks on the canonical host. Local evidence remains useful, but it does not cover the delivery stack.

Check page titles, headings, dates, sources, forms, and calls to action in the preview as content—not only as pixels. Remove placeholders and internal notes. If a form has no production endpoint, state that honestly or remove the success claim. If analytics is enabled, verify receipt with categorical test events and confirm no query text, generated content, email, session identifier, or other freeform payload is transmitted.

Error states are release surfaces. Request a missing page, a malformed dynamic route, and a disabled endpoint. The result needs a correct status, a clear heading, a recovery link, and the same focus and reflow quality as the happy path.

Common deployment failures

• The apex serves an old artifact. The deployment succeeded but the domain alias was not promoted. Inspect the domain assignment and record the corrected deployment identifier.
• Deep links return 404. Only the home page was exercised. Add representative direct paths to the smoke inventory and verify host rewrites.
• Preview URLs are indexable. Robots metadata and canonical configuration use production defaults incorrectly. Apply preview noindex and keep the canonical pointed at the real production page only when visible content is equivalent.
• A rollback restores code but not configuration. Environment changes were made outside the release record. Version or record configuration alongside the artifact and include it in rollback rehearsal.
• The public route works only on a warm cache. A required asset or upstream request fails when fetched fresh. Test a clean session and inspect the provider's runtime or edge logs after generating traffic.
• A success banner appears before the server responds. Client state is optimistic without recovery. Confirm success from an authoritative response and expose a safe retry.

Verify the release step by step

1. Record the source commit, package lock checksum, expected environment, build command, and prior healthy deployment.
2. Run formatting, strict types, lint, unit, content, link, SEO, public-copy, security, and production-build gates from a clean install.
3. Deploy a preview and inspect its build log, route inventory, headers, and environment validation.
4. Complete primary journeys in the required browser matrix, including keyboard-only, narrow viewport, zoom, reduced motion, invalid input, offline or slow network, and direct deep links.
5. Request robots, sitemap, feed, manifest, structured data, a known page, and a missing page. Confirm statuses and canonical-host behavior.
6. Promote the tested artifact, then repeat a bounded smoke against the apex rather than trusting the provider status.
7. Generate representative traffic and inspect telemetry receipt, function or edge errors, and availability monitors.
8. Record the production deployment identifier, evidence time, known limitations, and exact rollback command or provider action.

What this guide does not cover

This guide does not design a multi-region application database, zero-downtime schema migration, authenticated session rollout, or regulated-data incident plan. Those systems require additional consistency, backup, access-control, and recovery specifications. It also does not make a particular hosting provider mandatory; the same evidence chain applies when artifacts are uploaded to object storage, served by another static host, or deployed through an internal pipeline.

Exercise and next step

Create a release record for a small site before deploying it. Include the commit, preview URL, prior production artifact, smoke URLs, manual accessibility checks, promotion decision, and rollback operation. Ask another person to follow only that record. Any step they must guess is a runbook defect. Then use the site-launch checklist and deployment-audit prompt to make the evidence repeatable.