Hosting a static website can be simple, but production is more than uploading a folder. The public result also depends on the build environment, domain, DNS, HTTPS, headers, redirects, cache behavior, external services, monitoring, access control, and a way back when a release fails.
The intended reader is a founder or developer with a reviewed static build and authority to publish it. The outcome is a small release runbook that takes one identified artifact through preview, production, verification, and rollback. Provider features and limits change, so confirm them in current official documentation before committing. Source review: 24 August 2026.
Define the deployment contract
Start with the inspected artifact from the static website build workflow. Do not ask a hosting dashboard or another agent to generate a different site during deployment.
Write down:
Source repository and approved commit:
Runtime and package-manager version:
Install command:
Build command:
Publish directory:
Environment variables and owners:
Preview URL and access policy:
Production domain and DNS owner:
Required redirects and headers:
External forms, analytics, or APIs:
Post-deploy smoke tests:
Rollback method and authorized operator:
For a conventional static Astro project, the build command is often pnpm run build and the publish directory is dist/. Confirm both in the repository and current Astro deployment guidance. A platform preset is an example, not evidence that your project uses the same settings.
Pin dependencies with the committed lockfile and use the supported runtime declared by the project. If the hosting build succeeds only because it silently selected a different runtime or refreshed dependencies, local and production artifacts are no longer comparable.
Choose a host from requirements
Most static company sites need a build pipeline, immutable deploys, preview URLs, custom domains, managed HTTPS, redirects, configurable headers, useful logs, and a quick rollback. Some also need access-controlled previews, form handling, server functions, regional controls, or team permissions.
Compare providers against a requirements table:
| Requirement | Evidence to collect |
|---|---|
| Build reproducibility | Supported runtime, lockfile behavior, build logs, artifact identity |
| Preview safety | Unique URLs, access control, indexing controls, secret handling |
| Domain operations | DNS requirements, certificate process, apex and subdomain support |
| Release control | Preview promotion, production permissions, atomic activation |
| Recovery | Retained deploys, rollback steps, expected recovery time |
| Web controls | Redirect syntax, custom headers, not-found behavior, cache controls |
| Data and privacy | Logging, analytics, forms, regions, retention, subprocessors |
| Cost exposure | Current included usage, overage behavior, alerts, spending controls |
| Ownership | Organization account, roles, MFA, billing and recovery contacts |
Cloudflare Pages documents deployment of static HTML sites, preview deployments, custom domains, headers, redirects, and rollbacks. Netlify documents its deploy lifecycle and published-deploy controls. Vercel documents promoting and rolling back deployments. These are viable systems to evaluate, not universal recommendations.
Do not hard-code a provider’s current price, quota, retention window, region, or plan entitlement into the runbook unless you record the plan and review date. Check the current contract before launch and whenever usage or architecture changes.
GitHub Pages can publish static files and is useful in its intended scope, but its official limits state that it is not intended or allowed as free hosting for an online business, e-commerce site, or commercial software-as-a-service site. Do not select it for a company website by assuming that every static host permits every use case.
Put hosting under organizational control
Create the project in a company-controlled organization or account. Require multi-factor authentication, least-privilege roles, more than one appropriate recovery path, and an owned billing method. Record who can change production, domains, environment variables, and payment details.
Do not leave the domain, hosting project, analytics property, or form inbox inside a contractor’s personal account. A handover should not depend on someone remembering a password or retaining employment.
Keep credentials out of the repository and prompts. Configure secrets in the approved platform only when the build truly needs them. Remember that any value embedded into generated HTML or browser JavaScript is public, even if the platform calls it an environment variable.
Build a preview from the exact branch
Connect the repository with the narrowest practical permissions or use an explicit artifact upload workflow. Configure the install, build, and publish settings from the deployment contract. Make the first deployment a preview, not production.
Verify in the build log:
- the expected repository, branch, and commit were checked out,
- the intended runtime and package-manager versions were used,
- dependency installation honored the lockfile,
- the expected build command ran without ignored errors,
- the publish directory exists and contains the reviewed routes,
- no unrelated server or development process was launched.
Treat preview URLs as public unless access control proves otherwise. Do not deploy confidential client content, personal data, unannounced product information, or secrets to an obscure URL and rely on obscurity. Add an appropriate no-index policy for non-production pages, but understand that indexing controls are not authentication.
Open the preview from a clean browser session and a mobile network if practical. This exposes missing login assumptions, absolute localhost URLs, unavailable assets, cookie behavior, and DNS or network dependencies that a developer session can conceal.
Verify the preview as a release candidate
Use a route and behavior checklist, not a visual glance:
- home, service, about, contact, policy, and not-found routes;
- navigation, logo link, skip link, footer, and every primary call to action;
- keyboard order, visible focus, zoom, narrow widths, reduced motion, and image alternatives;
- page titles, descriptions, canonical URLs, language metadata, sitemap, and social preview;
- internal and important external links;
- form submission, validation, delivery, duplicate handling, abuse control, and failure state;
- external scripts, consent behavior, privacy notice, and blocked-script fallback;
- response status, redirect chains, headers, cache policy, and compressed assets;
- absence of drafts, source maps, secrets, local paths, and private files.
Use browser automation and link checkers where they help, but keep manual checks for meaning, focus behavior, assistive technology, privacy, and real form delivery. Record the preview URL, commit, date, tester, environment, and result. “Looks good” is not release evidence.
Configure the domain and HTTPS carefully
Decide the canonical host, such as example.com or www.example.com, and redirect the alternative consistently. Inventory existing DNS records before editing anything. Mail verification, email delivery, ownership checks, and other services may share the zone. Do not replace the full DNS configuration to add one website record.
Follow the host’s exact domain instructions. Verify domain ownership, DNS propagation, certificate issuance, and renewal behavior. Test both the apex and www names, HTTP-to-HTTPS redirection, unknown subdomains, and the canonical URL emitted by the pages.
If changing nameservers or a live record, capture the current state and rollback value first. Lowering a time-to-live shortly before a migration may help only after existing cached values expire. Schedule meaningful domain changes with the person responsible for email and other services.
Managed HTTPS reduces certificate operations, but still verify the public certificate, hostname coverage, expiry automation, redirect behavior, and whether mixed HTTP assets remain. HTTPS protects traffic in transit. It does not make third-party scripts, forms, or published content safe.
Add headers and redirects as tested code
Configure security and policy headers in the platform’s supported file or control plane, version them with the site where possible, and test the actual response. Common candidates include Content Security Policy, X-Content-Type-Options, Referrer-Policy, frame restrictions, and a deliberate permissions policy. The correct policy depends on the site’s scripts, embeds, forms, and compatibility needs.
Start a restrictive Content Security Policy from the resources the site genuinely requires. Report-only mode can help observe violations before enforcement, but it is a measurement phase, not protection. Do not copy a large allowlist from a generator and call the work complete. Check every exception and remove sources that no longer exist.
Keep redirects explicit and finite. Test legacy paths, trailing slashes, case behavior, query strings where relevant, and not-found responses. A redirect to the home page for every missing route hides broken links and can confuse visitors and search engines.
Cache versioned assets for efficiency, while allowing HTML and release controls to update according to the chosen rollback model. Verify behavior at the public edge. A local development server cannot prove production headers or caching.
Promote, smoke-test, and observe
Prefer promoting the already verified preview artifact when the platform supports it. If production must rebuild, compare the production commit, dependency lock, runtime, build settings, and output manifest with the preview. Do not assume two green builds are identical.
Immediately after promotion, run a short production smoke test from outside the hosting account:
- resolve the canonical domain and load it over HTTPS;
- check the release identifier or expected content;
- visit critical routes and one deliberate not-found path;
- test navigation and the primary action;
- submit a clearly labeled test form and verify receipt;
- inspect response status, redirects, headers, and key assets;
- confirm analytics or monitoring only if they were approved;
- check that the previous deployment is still available for rollback.
Monitor signals that correspond to user harm: availability, failed builds, form-delivery failures, certificate or domain problems, and unexpected traffic or cost. Avoid collecting personal data merely because a dashboard offers it. Define who receives alerts and what they should do.
Rehearse rollback before you need it
A rollback procedure should name the target deployment, operator, command or control, verification steps, and communication path. Test it with a harmless release when possible.
Rollback the site when production behavior is materially wrong and recovery is safer than a forward fix. Then repeat the production smoke tests. DNS changes, deleted data, altered third-party settings, and broken form destinations may not roll back with the static files, so document those as separate recovery actions.
Record each release with the source commit, artifact or deployment ID, production time, operator, checks, known exceptions, and previous stable deployment. AI can format the record and compare checklists. It must not infer that the site is healthy from a successful upload.
The complete chain is now traceable: company assumptions and proof, selected design direction, reviewed static artifact, verified preview, controlled production promotion, and tested recovery. That chain is what makes a small site professionally operated, even when the hosting platform makes the final upload look effortless.
