What this deployment checklist tool is for
Static Deployment Checklists is a practical launch companion for small static websites, Vite apps, documentation sites, and single-purpose tools that are published under a root domain or a subdirectory. It is meant for developers, operators, and site owners who want a repeatable preflight review before moving files to a VPS, object storage bucket, or static host. The tool does not deploy anything automatically. Instead, it turns the common failure points of static launches into a structured review: build output, public base path, direct routes, canonical URLs, robots.txt, sitemap.xml, HTTPS redirects, asset status, and browser-rendered content.
The most useful moment to use this site is after a production build exists but before the final upload or Nginx reload. A homepage can return HTTP 200 while the actual JavaScript bundle, stylesheet, sitemap, or deep route is broken. These checklists force you to inspect the files that browsers and crawlers will request, not only the one URL that looks fine in a terminal.
Inputs to collect before you start
- Final public URL: the exact domain and path, such as
https://your-domain.test/orhttps://your-domain.test/my-tool/. - Build directory: the local output folder, usually
dist,build, orpublic. - Framework base setting: the Vite
base, Astrosite, Next export path, or equivalent configuration. - Important routes: homepage, two to five content pages, disclosure or policy page, sitemap, robots file, and one intentionally missing file.
- Server rule location: the Nginx location block, static host routing rule, or CDN behavior that decides whether a URL returns a file, fallback HTML, or a real 404.
How the checklist logic works
The review follows a simple layered model. First, the generated HTML must point to the right assets. If a site is deployed under /static-deployment-checklists/, script and stylesheet references should include that folder unless the hosting platform rewrites paths intentionally. Second, each important URL must return the correct status code and content type. HTML pages should return 200 text/html, real JavaScript should return a JavaScript content type, and missing assets should remain 404 rather than being hidden by a broad SPA fallback. Third, search files must match the index plan: canonical links, local sitemap URLs, and robots directives should describe only the pages that are ready to be indexed.
A useful rule of thumb is: build paths first, server paths second, browser rendering third, and search metadata last. Reversing that order wastes time because SEO files cannot compensate for missing assets or a blank application shell.
Example launch scenarios
1. Vite app under a subdirectory
A small calculator is deployed to /calculator/. The homepage loads, but the browser console shows a 404 for /assets/index.js. The checklist points to the Vite base setting. After setting base: '/calculator/', rebuilding, and redeploying the entire dist folder, the browser requests /calculator/assets/index.js and the page renders correctly.
2. Nginx fallback masking broken files
A single-page app uses try_files $uri $uri/ /index.html at the domain root. Deep routes work, but missing CSS files also return HTML with status 200. The checklist separates HTML fallback from static asset rules, so missing hashed files surface as real 404s and can be fixed instead of silently serving the wrong content.
3. SEO files copied from an old staging build
A new static guide is uploaded successfully, but sitemap.xml still lists staging URLs and the canonical tag points to your-domain.test. The pre-launch search file step catches the mismatch before the page is submitted for indexing.
Frequently asked questions
Is an HTTP 200 response enough to approve a launch?
No. HTTP 200 only proves that the server returned something. You still need to confirm that the response is the intended HTML, that JS and CSS assets load, and that a fresh browser tab can render the expected H1 and main content.
Should every static app use an SPA fallback?
No. Multi-page static exports should usually serve real files for each route. SPA fallback is helpful when client-side routing owns the path, but it should be scoped so missing assets do not look successful.
Why do subdirectory deployments break so often?
Many local builds assume the site lives at the domain root. When the same output is placed under a folder, root-relative paths such as /assets/app.js no longer point to the deployed asset directory.
Do I need to rebuild after changing a base path?
Yes. The base path is written into the generated HTML and asset references during the production build. Changing only the server folder usually will not repair already-generated URLs.
Can these commands be copied directly to production?
Treat all commands as examples. Confirm your distribution, Nginx layout, backup procedure, TLS setup, and existing location rules before reloading a production server.
When should sitemap URLs be submitted?
Submit only pages that have complete content, correct canonical URLs, working assets, and a clear indexing purpose. Do not use a sitemap to push unfinished shells or thin draft pages.
Limitations and safety notes
This site is focused on static websites and static front-end applications. It is not a security audit, incident response plan, database migration guide, payment-system checklist, or full DevOps runbook. If a server hosts private dashboards, user accounts, production APIs, email services, or payment flows, review those systems separately and keep a rollback path. When in doubt, test on a staging host and back up the active Nginx configuration before changing production rules.