A static website is ready to launch when the generated artifact, hosting configuration, and reader journeys work together. A local development preview can hide missing files, forgiving route fallbacks, or dependencies that will fail after upload. Review the actual release folder through a server configured like the destination, then repeat the essential checks on the public domain.

This checklist works for hand-written HTML and generated sites. Keep a short record of what was checked, what failed, and which artifact passed. That record makes release decisions and recovery much easier.

1. Freeze and identify the candidate release

Build from known source files and approved content. Record the source revision, configuration, build command, and resulting artifact. Use a fresh output directory so files removed from the project do not survive in the release. Verify that the upload includes only intended public files, without environment settings, private content, or build credentials.

Compare the generated page list with the intended information architecture. Check the homepage, topic pages, articles, archives, policy pages, downloads, and missing-page document. If the site advertises a feature, include its complete visitor journey in the release review.

Resolve essential scope questions before polishing small details. The static website planning guide helps define what belongs in a release, while the HTML publishing guide describes the public files the host must serve.

For a directory-style URL such as /guides/launch/, verify that the host serves the intended directory index. Open the route directly in a fresh tab and reload it. A development server can return the homepage for unknown paths, creating the impression that routes work even when the release lacks their files.

Test the chosen trailing-slash behavior, letter case, encoded characters, and any old URLs that should redirect. Prefer a consistent destination for each page. Where redirects are required, inspect both the response status and final location. Avoid chains and loops, and do not assume that a redirect configuration from another host will be recognized.

Request a deliberately nonexistent path. It should show a useful error page and return the appropriate missing-resource status, rather than reporting success with unrelated content. Check links with fragments as well: a valid page URL can still contain a broken jump to a heading that no longer exists.

3. Inspect titles, descriptions, and canonical addresses

Review the generated HTML of representative pages from every template. Each should have a meaningful title, a clear main heading, and a concise description that matches the page. Detect duplicated placeholders and source-domain references automatically, then read the actual wording. Mechanical uniqueness does not make an inaccurate description useful.

Set canonical addresses consistently with the public domain and chosen route convention. A canonical is a preference signal; it does not redirect visitors or substitute for correcting navigation. Inspect protocol, hostname, trailing slashes, and nested paths. Check that preview or staging domains have not been copied into production metadata.

Review social preview titles and image addresses where supplied. Structured data should describe visible, supported content and use accurate dates and identities. Remove invented ratings, unsupported offers, or obsolete organizational information. If the project supports multiple languages, verify the complete language relationships instead of adding incomplete annotations to a few pages.

4. Generate and validate the sitemap and feed

Create discovery files from the same approved content manifest used to generate pages. The sitemap should contain the public canonical URLs you intend to expose, with valid XML and truthful modification dates. Exclude drafts, private pages, obsolete redirects, and unsuccessful destinations. Changing every modification date on each build obscures which content actually changed.

Google's sitemap creation guidance explains supported formats and submission methods. Sitemap submission is a hint, not a guarantee that the listed pages will be crawled or indexed. Useful internal links remain part of the site's discovery system.

Check RSS as a reader would

If the publication provides RSS, validate the feed and subscribe with a feed reader. Check the channel title, public links, item identifiers, dates, descriptions, and XML escaping. Confirm that the latest intended article appears and that unchanged articles retain stable identities after rebuilding. Link to the feed from an appropriate visible location and include the document-level discovery link when supported.

5. Verify every image and asset reference

Check images, fonts, stylesheets, scripts, icons, and downloads against the actual release folder. Inspect CSS background references, responsive image candidates, and module imports as well as ordinary HTML links. A browser cache can disguise missing files, so run part of the review in a fresh context.

Use descriptive filenames that reflect the asset and update every reference after a rename. Set dimensions from the actual image files and provide alternative text that serves the image's purpose. Decorative images can have empty alternatives when appropriate; screenshots and diagrams may need surrounding explanation. Preserve required attribution and permission records.

Inspect layout stability and loading behavior at a representative narrow width and on a slower connection. Avoid delaying the image essential to the opening view unnecessarily. Load less urgent media thoughtfully, and remove unused heavy scripts. The static site performance article develops a practical measurement workflow.

6. Complete key journeys with keyboard and touch

Navigate the site without a mouse. Check the skip link, visible focus, menu controls, dialogs, accordions, search results, and forms. Make sure focus moves in a meaningful order and that closing an overlay leaves the reader in a sensible place. Test zoom, narrow layouts, and reduced-motion settings where animation exists.

Read the homepage and a long article as content, not merely as a layout. Verify heading order, descriptive links, readable line lengths, usable tables, and explanations for unfamiliar terms. Confirm that important information remains available when enhancement scripts fail. The accessible HTML and CSS guide provides deeper implementation checks.

Verify outcomes, including failure states

Submit a labeled test through every live form and confirm it reaches the intended system. Test invalid input, unavailable services, and repeated submissions. Check search with a useful query and a query with no results. Remove unfinished controls or provide an accurate explanation of the available alternative before release.

7. Check the host as well as the files

Verify HTTPS and the intended domain configuration. Check response codes and content types for HTML, XML, CSS, JavaScript, images, and downloads. Confirm compression and cache behavior where configured. A sensible cache policy should let changed HTML become visible promptly while permitting longer caching of versioned assets. During the rehearsal, change a stylesheet and an article, then verify that both updates arrive together. Check what happens when an older cached page requests its previous assets. Keep the files required by supported cached releases available for an appropriate transition period, or use the host’s documented release mechanism to manage that consistency.

Review any security headers in the context of the features actually used. A restrictive content policy can break approved scripts, fonts, or form destinations if it was copied without testing. Inspect browser errors on the hosted preview, and confirm that retained remote services operate from the final origin.

Check the robots file and page-level indexing controls for leftover staging restrictions. Treat access control separately: a crawler instruction does not protect private files. Validate any host-specific redirects, custom error handling, and deployment configuration using actual requests. The CSS static site guidance can help distinguish presentation defects from serving problems.

8. Release gradually and rehearse rollback

Keep the previous successful artifact and the configuration needed to restore it. Define the practical rollback triggers before launch: core routes failing, important assets missing, protected information appearing, or a critical enquiry process breaking. Test the recovery procedure on a preview environment when possible, and assign responsibility for the release window.

Promote the checked artifact using the host's supported release process. Repeat a focused set of checks on the public domain: homepage, a deep article, an archive, a missing path, media, feed, and the most important interaction. Check from a fresh browser context to reduce the chance of seeing cached success.

Record any remaining issues with clear ownership and priority. A good launch is a controlled transition with a working route back, followed by a repeatable process for the next correction. Reuse this checklist for significant releases and adapt the depth of review to the changes being shipped.