A static site you can rebuild

Keep three distinct layers

The source is the material you want to edit: text, templates, styles and build instructions. The output is the set of files a browser can request. Deployment state is the environment that serves those files: configuration, certificates and the current release selection.

Mixing the three makes a small change surprisingly hard to review. A certificate renewal should not rebuild the prose. Editing a paragraph should not require a change to the server's global configuration. A release archive should contain neither development dependencies nor a private key.

source/       authored text and styles
build/        generated HTML and assets
releases/     versioned, verified output

These names are illustrative, not a prescribed directory layout. The important property is that each layer can be inspected and replaced without silently changing the others.

Lock the inputs, not just the output

A dependency lockfile records exact versions and integrity values used by a package manager. Keep it with the source. Also record the runtime and package-manager versions: a dependency graph alone does not specify every input to a build.

Prefer a clean install from the lockfile in a controlled working directory. Avoid downloading fonts or scripts during a visitor's page load. Local assets reduce external dependencies and make the rendered page less dependent on third-party availability.

Reproducible does not mean “it built twice.” Two successful builds can produce different bytes. If byte-for-byte reproducibility matters, build the same source in clean environments and compare the complete output. Timestamps, generated identifiers and tool versions can all introduce differences.

Inspect what the reader receives

Start with a file inventory. A small reading site should not unexpectedly ship source maps, environment files, a package cache or an administrative interface. Check internal links against the actual output paths rather than only the development server: some development servers turn unknown paths into a successful home-page response.

Then use a browser with the production output. Follow each navigation path, resize to a narrow viewport and navigate with a keyboard. Text should remain readable, focus should remain visible and a missing page should explain how to return. A screenshot can show layout; it cannot prove that a link works or that an error has the right HTTP status.

• Inspect the network panel for unexpected remote requests.
• Check the console for failures after navigation, not only at first load.
• Confirm that content is useful without JavaScript when the site does not need it.
• Verify error responses on the serving configuration, not only a preview tool.

Release without guessing

Package the checked output once and record its digest. Deploy that same artifact rather than rebuilding separately on every server. Keep the previous release until the new one passes the checks that matter: expected content, status codes, asset loading and certificate validation.

Content-addressed asset filenames let a browser cache a particular asset for a long time because changing its bytes also changes its URL. HTML is different: it points to those assets and needs a shorter caching policy or revalidation. Avoid applying a year-long immutable policy to every file just because some files have hashes.

Rollback is a release-selection operation, not an excuse to keep unverified backups indefinitely. Confirm that the prior files and their configuration are actually available, and that returning to them does not require recovering a missing secret.

The result is not an elaborate deployment platform. It is a small, inspectable chain: known inputs, checked output and an explicit decision about which output readers see.