Publish a static site with a repeatable update path
https://patrickz.ai/learn/publish-and-update-a-static-site/

OUTCOME
Plan a site release with validation, a preview and a rollback checkpoint.

YOU NEED
A static practice site, version control and hosting you already control. Do not change domain records during this exercise.

1. Identify the actual source
Choose one repository and one output directory. Document the command that creates or validates the site. Keep credentials out of the files that will be served.

2. Preview the complete journey
Open the home page, one guide, a contact route and a missing URL. Test on a phone-sized screen. Verify local links and image paths before upload.

3. Separate validation from publishing
Have the workflow validate first, then upload only the intended output directory. Use an encrypted upload such as SFTP or FTPS with certificate checks, and repository secrets for credentials. Start with a non-production destination when available.

4. Verify the live release
Check the public URL, images and nested pages after deployment. Compare a visible changed detail with the preview. Keep the prior commit and hosting configuration so a failed release can be reversed.

PROMPT
Review this static-site release plan: [plan]. Identify the source repository, build/output directory, validation checks, encrypted upload method, secret storage, live verification and rollback. Flag any step that could affect unrelated sites. Do not change DNS or publish until the concrete destination and files are clear.

EXAMPLE / EXPERIMENT
This site’s own release is a worked example. (1) Every pull request and every push to main runs a validate job: link and file checks, unit tests and a JavaScript syntax check. (2) The publish job declares needs: validate, so nothing uploads unless those checks pass. (3) Publishing runs only on main, never for a pull request, and only while a DEPLOY_ENABLED repository variable is true. That gives you an off switch that needs no code change. (4) The FTPS login comes from repository secrets and never appears in the served files. (5) Each file goes up under a temporary name, is downloaded again and compared by SHA-256, then renamed into place. Nothing on the server is deleted automatically. (6) The files it replaced are kept as a 30-day workflow artifact, so a bad release can be undone. A green build with a skipped upload job is still not a live deployment: check the public URL and a nested page.

CHECK YOUR RESULT
[ ] Only the intended site directory is published.
[ ] Credentials are excluded from served files and source.
[ ] The live result and rollback point are verified.

IF IT FAILS
If the home page works but guides fail, check nested paths, document root and server routing. Avoid changing DNS as a first response to a file-path problem.

MY RESULT / NEXT CHANGE