Publish a website and export HTML

Select a version that is ready

Start by reviewing the content you intend to share. Confirm the business details, button destinations and removal of temporary wording. Save the final changes. List the pages involved so you can check the same set after publishing. A polished homepage does not establish that the entire website is ready. Pay particular attention to the contact page and practical conditions: small errors there can prevent someone from reaching you or create the wrong expectation about your service.

• Review every page rather than only the homepage.
• Test telephone, email and external links.
• Save the final content changes.

Inspect the published result

Publish the intended version and then open its published URL. Compare headings, images and navigation with the version you meant to share. Where possible, also test from a separate browser window. Current websites under /sites carry noindex and belong to the pilot. An accessible URL is therefore different from an indexable search destination. Use this publication to review and discuss the work, without treating it as evidence of a completed launch on your own production domain.

Extract the complete ZIP

Download the HTML export and extract the entire archive before testing it. The standard export contains all pages with correct relative file links. Preserve the folder structure when moving files; casual renaming can break navigation. Open several pages and follow their menus. Images and fonts load online through Flova. A successful test while connected to the internet therefore does not establish that the website works offline or is fully independent of those external resources. Keep that distinction clear when handing files to someone else.

• Keep the original ZIP as a dated snapshot.
• Extract all files together.
• Test navigation starting from at least two different pages.

Arrange production hosting separately

To use the export on your own host, arrange separate checks for server configuration, HTTPS, the domain and final URLs. The pilot does not claim automatic domain connection or migration. Discuss long-term image and font management, including usage rights. Forms, a shop or a booking button each need an appropriate working service. A visible interface does not establish that messages are delivered, payments are processed or appointments are stored. Include these services explicitly in the handover rather than assuming they are part of the HTML files.

Repeat checks on the real host

Following a separate production deployment, inspect links, images and mobile pages again on the actual host. Review canonical URLs, indexability and any redirects there too. Do not blindly copy pilot settings into production. Google needs to crawl a page to see a noindex instruction; a robots block is a different setting. Record who maintains the content, hosting and external services. An export transfers files; it does not automatically provide ongoing maintenance or synchronise future edits across every copy of the website.

• Open the actual production URL on phone and desktop.
• Test each external service from start to finish.
• Record who handles later corrections and replacement exports.