Exporting a static website produces files. Publishing it makes those files available at the correct addresses. The gap between the two contains several practical checks: whether every asset is present, whether clean URLs work, whether the domain is consistent, and whether you can recover the previous version if the new one is wrong.
This walkthrough assumes that you already have a small public website made with HTML, CSS, images, and optional browser JavaScript. It does not require a database or an application server. The objective is a predictable handoff from a browser design workspace or local project to a static host, with enough documentation for someone else to maintain it.
Identify the actual deployable folder
Many projects contain both authoring files and finished output. The source may include templates, package configuration, or a build script. The public output should contain the files the host needs to serve. Find that boundary before uploading anything, because a source archive is not always a ready-to-publish website.
Check the public root
For a directory-based site, the deployable root normally contains the homepage index file, asset directories, and directories for other pages. A route such as /about/ is represented by an about directory with its own index file. The archive should not introduce an unexpected enclosing project folder if the intention is to extract directly into the public root.
Keep the authoring project separately when available. It helps future maintainers regenerate shared navigation and styles consistently. The public package should remain usable without that project when the brief requires a no-build deployment. State that distinction in the handover rather than making the owner discover it after upload.
Inspect the export for hidden dependencies
Open the HTML and review the resources it requests. Images, stylesheets, scripts, icons, and fonts may be local or remote. A remote dependency is not automatically wrong, but it should be intentional and documented. Remove development-only tools and temporary preview URLs from the finished output.
Check for features that imply a backend. A contact form needs a destination that handles its submission. A signup button needs an actual account flow. A search interface needs a working implementation. When those services are outside the project's scope, replace the controls with honest alternatives such as a visible email link or a static topic index.
Confirm that secrets have not been placed in the public files. Browser-delivered code is not a suitable place to hide a private service key. Inspect configuration files and example snippets as well as the visible pages. Exporting a folder should never mean publishing the entire development environment indiscriminately.
Test over HTTP, not only from a file
Opening a page directly from disk is convenient, but it is not the same as serving it through a website. Root-relative asset paths and directory URLs may behave differently. Use a local static server or a temporary deployment preview that serves the exported directory as its document root.
Test more than the homepage. Enter a deep article address directly, refresh it, and follow links to another section. Confirm that the correct styles and images load at every depth. A relative path that works on the homepage can fail several directories below it.
Check the site with an empty cache when practical. A missing asset can be masked by a browser that already has an older copy. Keep the browser console and network panel available for failed requests, but do not rely solely on them: read the page and exercise the user journey as well.
Choose a host based on the required behavior
The essential requirement is serving your files at the intended routes. Ask whether the host supports directory index pages, HTTPS, custom domains, a missing-page response, and the deployment method you plan to use. Additional features matter only when they fit the site, rather than because they appear on a long platform comparison.
GitHub's explanation of GitHub Pages provides one example of static hosting that publishes HTML, CSS, and JavaScript from a repository. It is not the only option, and service terms or project requirements may make another host more appropriate. Review the current provider documentation before choosing an account or deployment configuration.
Pay particular attention to the base path. A site served at a domain root and a site served under a project subdirectory may need different internal asset paths. A package designed for BrowserPress.com should be tested at that root-style location or deliberately adapted before use beneath another path.
Set the production identity consistently
Before launch, check the site name, contact address, canonical URLs, sharing metadata, sitemap, feed, and structured data. A visible logo replacement does not necessarily update every machine-readable field. Search the exported text for the original template domain and any temporary staging hostname.
Confirm the domain configuration with the account owner. Publishing files does not automatically create an email inbox for the domain, and placing an email address on the contact page does not verify its delivery. Test the mailbox separately through the organization's normal setup process before treating it as an operational contact channel.
Use the hosting provider's supported HTTPS configuration and inspect the final public URLs. Do not claim a deployment is live because a local preview works. The owner should have a clear record of which folder was delivered, which environment was tested, and which production steps have actually been completed.
Verify navigation and failure cases
Click every header and footer item. Check article links, category archives, tag pages, breadcrumb trails, image paths, and feed links. A complete website has more destinations than its main menu. Automated link checks are helpful, but visual review can identify a technically valid link that leads to the wrong topic.
Test an unknown address. The host should return an appropriate missing-page response rather than presenting unrelated content as if it exists. A custom 404 page can offer useful routes back into the website, but the response behavior still depends on the host's configuration.
Review mobile navigation and keyboard access on the deployed output. A sticky header should not cover a section reached through an anchor link. Buttons need visible focus and meaningful actions. The exported version, not the editor's preview environment, is the artifact the visitor will use.
Keep a rollback package
Before replacing an existing release, save its files and record the deployment date. Use clear version labels rather than folders named final, final-new, and final-really-new. A rollback should be a specific artifact with a known restore procedure, not a hope that an old browser cache contains the missing page.
Test restoration in a non-production environment when possible. Confirm that the previous version includes its assets and metadata, not just the homepage. If the new release changes URLs, account for the associated redirects and sitemap changes when restoring it.
Record any changes made directly on the host. Otherwise, the authoring source and the deployed files can diverge, and the next build may silently overwrite an emergency fix. Prefer a workflow where reviewed changes can be reproduced from the maintained source, even when the public site itself needs no build step to run.
Hand over the minimum useful documentation
Include a concise guide identifying the public root, preview command, update process, and known dependencies. State which interactive features run locally and which require separately configured services. Give the owner a way to locate the main content files and regenerate the stylesheet when future changes require it.
Include a page inventory and the results of concrete checks. Avoid calling a site universally compatible based on a single browser session. Report the viewports and tools actually used, along with any remaining host-specific setup. The getting started page provides a visitor-facing introduction; the deployment handover serves the maintainer.
The takeaway
Treat export, preview, and publication as separate stages. Inspect the files, test the site over HTTP, verify production identity, and keep a recoverable release. A static website is straightforward to host when its paths and dependencies are explicit. A careful handover makes that simplicity available to the next person as well as the original builder.
