Publish a static site

A deployment is not complete until the public page works

Static hosts publish HTML, CSS, JavaScript, and assets without requiring your own application server. The platform may build from a repository or accept a prepared output directory.

Pre-deploy checklist

• Open every page directly.
• Remove unfinished placeholders and secrets.
• Check relative links and filename case.
• Confirm each page has a title and language.
• Compress images and reserve dimensions.
• Add a useful 404 page when the platform supports it.

Verify the real URL

After deployment, open the production URL in a clean browser session. Check HTTPS, the response status, navigation, mobile layout, form honesty, canonical URLs, and social preview information. A successful command does not prove the public route is correct.

How hosts and browsers behave

A deployment maps an immutable or generated artifact to an environment. The provider may build from a commit, cache dependencies, inject environment variables, and serve through a content delivery network. A green build proves that process completed; it does not prove the apex domain, redirects, headers, or dynamic dependencies work.

Browsers cache assets and redirects. Verify in a clean session and inspect response headers so a warm local cache does not hide a missing file. DNS and certificate changes can take time or differ by region, which is why production checks should record the exact URL, artifact, and time.

Decisions and trade-offs

Use a preview for review and keep it noindexed or access-controlled. Promote the same tested artifact when the platform supports promotion; rebuilding during release can introduce dependency or configuration drift. Record the prior healthy artifact and rollback method before switching production traffic.

Environment variables belong in the deployment environment, not source files. Expose a variable to client code only when it is intentionally public. Keep canonical-host and feature-toggle validation strict enough that a preview cannot masquerade as production.

Accessibility consequences

Production is where fonts, third-party failures, headers, caching, and real network conditions meet. Repeat keyboard, zoom, reflow, reduced-motion, and screen-reader checks on the public host. A local audit is evidence about the artifact, not the final delivery path.

Error pages need a useful heading, navigation or recovery link, and the correct status. Maintenance and access-control pages must not trap focus or present a blank client shell.

Common failures and fixes

• The domain shows an older release. The alias points to another artifact or cache. Inspect deployment assignment and purge only the affected cache.
• Deep links 404. Rewrites or output structure differ from local routing. Test representative direct paths before promotion.
• Preview URLs become canonical. Base URL configuration is wrong. Fail the production build when the canonical origin is invalid.
• Rollback is improvised during an outage. The prior artifact was not recorded. Capture and rehearse the provider's rollback path in advance.

Verify it

Record the commit, build identifier, deployment identifier, and canonical domain. Request home, a deep page, robots, sitemap, a missing path, and any API health boundary. Confirm statuses, one-hop host redirects, TLS, security headers, canonicals, and noindex on previews. Complete primary browser journeys at desktop and 320 pixels, check telemetry receipt without sensitive payloads, scan runtime logs after traffic, and execute a rollback rehearsal in a safe environment.

Exercise and next step

Publish a two-page test site to a preview URL. Change one heading, publish a second preview, and confirm the earlier preview remains a distinct artifact. Next, use the full publishing guide to turn these checks into a repeatable promotion and rollback runbook.

Boundary of this lesson

Static hosting reduces server operations, but it does not remove domain, security-header, dependency, accessibility, privacy, or incident responsibilities. A static site can still load unsafe scripts, leak analytics data, publish stale claims, or become unavailable through configuration. Keep the release record proportional to the site while preserving the essentials: exact artifact, environment, verification time, observed production behavior, and a recoverable prior state.

Practice a recovery

Publish a harmless visible defect to a preview, promote it only in a noncritical test project, and use the documented rollback to restore the prior artifact. Record the time, domain assignment, cache behavior, and post-rollback smoke results. A practiced recovery demonstrates whether the deployment record contains enough information when pressure is high and whether rollback changes only code or also restores required configuration.