Static Hosting (Vercel/Cloudflare)

What is being published

Your studio site is a static product: index.html, CSS, JavaScript and assets are sent to visitors as files. JavaScript can still be interactive in a static site; “static” means the host does not need to run your own server code to generate each response.

GitHub stores your source and commit history. A host serves the working website. A GitHub repository URL is not the same as the host's live HTTPS URL. A CDN copies content across locations to reduce delivery distance; HTTPS encrypts the connection, not a guarantee the site is honest or bug-free.

Check the source before importing it

From your studio repository, confirm index.html is at the intended site root and its relative links point to existing files. Open it locally, test navigation and inspect Console/Network. Confirm your latest working change is committed and pushed, then find the same commit on GitHub.

Use your earlier Git workflow: status → diff → select files → staged diff → commit → push. Do not commit .env, keys or node_modules. You do not need a paid hosting plan or purchased domain for this activity; a host-provided address is enough.

Import a plain static site deliberately

Use your chosen host's current Git-based static-site guide. On Vercel, import the GitHub repository and choose the plain/Other framework setting when no framework exists. On Cloudflare Pages, choose the documented Git integration and plain static-site configuration. Product screens change; the underlying choices remain:

1. Authorise the host to access the repository you own, preferably only the repository needed.
2. Select the correct repository and production branch, normally main if that is your branch.
3. Choose the root directory containing index.html. If the website is in a subfolder, choose that folder rather than the whole workspace.
4. For a no-build HTML/CSS/JS site, do not invent npm run build: use the host's documented no-build setting. Where an output-directory field is required, it must point to the folder of ready-to-serve files. Providers use different defaults, so read the current static-site guide instead of guessing a framework output like dist.
5. Start the deployment and watch its log. Wait for success, then open the host-provided address.

A successful job does not necessarily mean the correct directory was served. If you see a default page or 404, inspect the selected root/output and deployed commit. Do not repeatedly change DNS before proving the host address works.

Verify as a visitor

Open the HTTPS address in a fresh private window. Confirm the studio name, stylesheet, images, navigation and your latest content. In Network, check that CSS and JavaScript return the intended files rather than a missing-file response. Filename case matters on many hosts even when your local filesystem was forgiving: Logo.png and logo.png may be different files.

For a read-only header check on Mac:

curl -I https://YOUR-HOST-ADDRESS

On Windows PowerShell use curl.exe -I https://YOUR-HOST-ADDRESS. Replace the whole placeholder with your actual host-provided address; do not type angle brackets. -I requests HEAD (headers only). The response may redirect: a 301/302 or 307/308 is not itself failure; inspect Location and test the final address in the browser. A 200 means a response succeeded, not proof every asset or interaction is correct.

Prove automatic updates

Change a harmless tagline locally, save and test it. Commit that change and push. In the host's deployments list, identify the new job and commit; wait for completion. Reload the live site and confirm the new tagline. Editing locally without commit/push will not update the hosted product. A host can also make preview deployments for other branches; those are not necessarily the production address.

Troubleshoot by stage

If a deployed update breaks, use a known working host deployment or make a corrective/revert commit. Do not force-push shared history just to restore a label. Keep real source checkpoints.

Assessment readiness

Before activity 1.4, show a live HTTPS address that renders your site, actual header output and an update arriving from a new Git commit. Explain which URL is your repository and which is your public product. Custom DNS is a later branch; it is not needed to ship this first site.