
Publish the folder that contains the finished index.html, then test the public URL and every route. A page that works on localhost has not yet passed a deployment check. This guide starts with reviewed plain HTML, CSS, and local assets. It does not cover exporting from Bolt, v0, or another builder; that workflow has its own guide. It also does not cover diagnosing why an existing builder site is absent from Google.
Use a folder with index.html at its top level. In this fictional example, the folder also contains styles.css, services/index.html, and contact/index.html:
site-output/
index.html
styles.css
services/index.html
contact/index.html
This is an example artifact, not a site we deployed. Before publication, replace hello@example.com and every other placeholder. Confirm that business facts, images, fonts, and logos are approved for public use. Remove test data, secrets, local paths, and scripts you do not need. A public static site exposes its delivered files to visitors; do not put credentials in the folder. If the files came from a framework, upload the built output rather than an unbuilt source directory. Keep the exact tested output folder as your release copy.
Netlify's official add-project guide documents a manual deploy: sign in, open the team's Projects page, select Add new project and Deploy manually, then drag the output folder to the dropzone. Netlify also offers a drag-and-drop page and a Git-connected workflow. This guide uses the manual path because it matches plain files with no build command. The account and team you use may have their own access and deployment controls; review those before upload.
Select site-output, not its parent folder. The folder's top level must contain the homepage file. Netlify's error reference warns that a missing root index.html can produce a successful-looking deploy with a page-not-found result. For the example tree, Netlify's request-chain documentation says /services/ can match services/index.html. That route rule is host behavior, not a reason to assume every host maps folders the same way.
Do not upload until the content owner has approved the final files. A manual upload is a production action: the resulting site can be publicly reachable. The first deploy should use a host-generated URL. Connect a custom domain only after you have checked that URL. Domain and DNS changes are a separate task with risks to existing web and email records.
Open the URL that the host reports after the deploy completes. Do not rely on a dashboard label that says "published." First inspect the project's visibility and access settings. Some Netlify projects can start private under a team's default setting, so a working owner preview does not prove visitor access. Open a signed-out private window and visit /, /services/, and /contact/ on the final hostname. Confirm that each route is visible without your account, password, or preview token. Then use the site's own navigation between them. Check the network panel for missing CSS, images, and fonts. Inspect a phone-width view. Activate the contact link, but do not send a test message to an address you do not control. If the link opens a draft addressed to your real inbox, send a message only when you have permission to test delivery.
Record results in a release table:
| Check | Result to record |
|---|---|
| Home URL | Final URL, HTTP result, visible heading |
| Signed-out visitor access | Each required route opens without owner credentials |
| Service and contact routes | Exact URL, expected content, working navigation |
| Assets | CSS and images load without errors |
| Contact action | Correct destination or a named failure |
| Mobile view | Readable content and no horizontal overflow |
| Release copy | Folder name or commit that matches the deployed files |
A local pass does not fill in these cells. We did not perform a public deployment for this example, so there are no public results to report here. The table is for your actual release record. If a route fails, check the uploaded folder depth and link paths before changing the host's routing rules.
Keep the previous output folder or commit before you deploy. Netlify's deploy management documentation describes publishing a prior deploy from its Deploys area. It also explains that a later Git-triggered production deploy can overwrite a rollback on Git-connected sites. On a manual-only site, you can also upload the previous tested folder again. Check the public URL after any rollback; a rollback is not complete just because the dashboard changed.
For future updates, decide who owns the source and the deploy. A manual drop can publish fast, but it does not by itself give you review gates or a source history. If several people will change the site, put the source in Git and choose a host workflow with branch review. GitHub Pages, for example, documents publishing from a branch or a custom workflow; its choices differ from Netlify's manual upload.
If you need help framing edits to an existing site, Figment's live AI prompt-preparation tool can prepare a request. It cannot grant edit access by prompt. Check /ai-editor for editor availability. Figment currently edits a separate imported static copy; it does not deploy arbitrary generated output from this guide.
index.html and folder-route checks.