Launch Knowledge Base
Static Site Launch Checklist
A practical checklist for publishing a static website, including build output, asset paths, routing, integrations, domains, and post-launch smoke checks.
A static site is the best first launch path for many projects. It has fewer moving parts than a full-stack application because the deployed artifact is a set of files. That does not mean there is nothing to check. Static launches still fail because of missing files, broken asset paths, incorrect rewrites, wrong environment values, failed forms, and unfinished domain setup.
Use this checklist before and after publishing.
Confirm what gets built
The deployable artifact should be clear. For a static site, it is usually an output directory such as dist, out, build, or public. The exact name depends on the framework.
Before uploading or deploying, confirm that the output directory contains the files users need. At minimum, there should be an entry HTML file, referenced JavaScript and CSS assets, images, fonts if used, and any static files such as robots.txt, sitemap.xml, or favicon assets.
Do not assume the source directory is the deployable output. Source code often contains development-only files, uncompiled components, TypeScript, local configuration, and dependencies that the browser cannot use directly.
Check asset paths
Broken asset paths are a common static launch issue. A page may load, but styles, scripts, images, or fonts return 404.
Common causes include:
- the site was built for a subpath but served from the domain root
- the site was built for the domain root but served from a subpath
- image references use local development paths
- CSS references fonts that were not copied into the output
- the framework expects a base path that production does not use
Open the production URL and inspect the browser network panel. A static site is not healthy just because the first HTML request returns 200. The supporting assets must also load.
Handle client-side routing
Single-page applications often rely on browser-side routing. A user can click from / to /pricing and everything works because the JavaScript router handles it. But if the user refreshes /pricing, the hosting layer may look for a real file at that path and return 404.
The usual fix is a fallback rewrite: unknown application routes should serve the entry HTML file so the client router can decide what to display. This is appropriate for app routes, but not for missing assets. If /assets/app.js is missing, returning HTML can hide the real problem.
Static sites with generated HTML pages may not need this fallback. Documentation sites and static site generators often produce real files for each route.
Verify integrations
Static does not always mean no backend. A waitlist, contact form, checkout link, analytics script, newsletter embed, or search provider is still an integration.
Check each integration in production:
- Submit a test form and confirm where the data lands.
- Confirm spam protection or rate limits do not block real users.
- Confirm analytics records the production domain, not localhost.
- Confirm outbound links point to production destinations.
- Confirm privacy or cookie notices match what the page actually loads.
If an integration requires an API key, decide whether the key is safe to expose in browser code. Public client keys are common for analytics and publishable payment keys. Secret keys do not belong in static JavaScript.
Prepare the domain
A static site can be live on a platform URL before the custom domain is ready. That is useful for testing, but users usually need the branded domain.
Before announcing:
- Choose the canonical host, such as
example.comorwww.example.com. - Decide whether the other host redirects to it.
- Add the DNS record requested by the hosting platform.
- Wait for DNS to resolve from public resolvers.
- Confirm HTTPS is active for the final hostname.
- Test the exact URL users will receive.
Do not launch from memory. Copy and paste the final public URL into a fresh browser session.
Smoke test after deploy
A smoke test is a small set of checks that proves the launch did not obviously fail.
For a static site, test:
- home page loads over HTTPS
- main navigation works
- important images and fonts load
- direct refresh on key routes works
- forms or embeds work
- mobile viewport is usable
- custom domain and redirect behavior are correct
- browser console has no obvious production-breaking errors
If the site has a call to action, test the call to action. A landing page with a broken signup form is not launched.
Keep rollback simple
Static site rollback is usually straightforward because each release is a set of files. The safest model is to keep prior artifacts and switch the active version back if the new release breaks.
Before replacing a known-good production site, know where the previous version is and how to restore it. This matters most for marketing launches, campaigns, and public announcements where broken pages quickly cost attention.
Flash Launch note
Flash Launch static deploy is designed to make the first path visible: upload or build the static artifact, receive a public URL, inspect deployment history, and roll back to a previous working version. The platform can simplify the mechanics, but the checklist still helps you recognize whether the public page is truly usable.