A practical guide · October 28, 2026
A static website handoff that survives the next edit
A website handoff should let another person understand what they received, publish the right files and make the next small edit. A beautiful preview is only one part of that job. This checklist applies to any small static website, including hand-written HTML.
Start with a clean export
Put only publishable website files in the handoff directory. Do not upload the entire project, editor, workspace, private business brief, credentials or development notes. A small export might look like this:
website/
index.html
style.css
robots.txt
assets/
approved-photo.jpgThe exact filenames vary. The useful distinction is that these are the site’s public assets. A ZIP containing a password file is still a disclosure even if the webpage never links to it.
Check paths before choosing a host
Open the exported page through a local preview server where possible. Follow its relative image, stylesheet and navigation paths. A link to a developer’s home directory can work on their computer and fail everywhere else. Case differences can also pass locally and fail on a case-sensitive host.
Look for external fonts, scripts, images and embeds. An offline-capable export should not silently require a remote dependency. An intentionally external link is different from an asset required to render the page.
Test contact, keyboard and narrow layouts
Use actual content, especially long names and email addresses. Test a narrow screen, keyboard navigation, visible focus and heading order. Describe informative photos with useful alt text. Expand questions, follow the main action and check that contact links open the expected application.
A mail link is not a delivered message. A decorative booking button is not a booking system. If a feature needs a backend, test the real success and failure paths before describing it as functional.
Separate sample mode from launch approval
Keep fictional names, sample notices and placeholder contact details unmistakable while reviewing. Before launch, replace them with approved facts and assets. Check crawler settings deliberately: a draft may use noindex; an approved public site may allow indexing. Noindex does not protect private information from people who have the URL.
Make the next edit possible
Deliver editable source alongside a short explanation of how to make a change. If a builder uses a saved brief, retain it privately with the source assets and document how to reopen it. Keep its private data out of the public export. Explain which text can be edited safely, which layout decisions are fixed, and what the tool does not support.
For Nimbus Launch Kit, Python 3.10+ and a modern browser run the purchased local editor. The generated site is static HTML/CSS. Hosting, DNS, forms and booking are separate. Other builders may have very different runtime and licensing requirements.
Record deployment and rollback
Agree which account owns the domain and host. Upload only the export contents to the intended document root. Keep an independent copy of the previous published version before replacing it. After publication, test the public URL and contact path again; local preview cannot prove production configuration.
Write down the release date, export version and a simple rollback instruction. Keep passwords in the appropriate protected account manager rather than a handoff text file. A portable export avoids a platform runtime, but it does not remove the need to own and maintain hosting.
Prepare the actual business content with our service-business checklist, or inspect the fictional exported demonstration. Use whichever builder fits the project; these checks are useful regardless of a purchase.
Published by Nimbus Web Studio. Nimbus sells Launch Kit, but this guide can be used with any builder. Examples are fictional. This is practical guidance, not an accessibility, legal, security or search-ranking certification.