A static website template launch checklist
Check real content, links, forms, search access, and your recovery plan before you publish a static website template.
On this page
Publish when the website works with your real content, each important action has a checked destination, and you can restore a known version. A successful build alone does not confirm these conditions.
This checklist suits a small public website made from an HTML or static site template. An application with accounts, payments, or stored customer data needs additional checks for those functions.
Define what the website must do
Write the visitor's main task in one sentence. For example: “A visitor reads the service description and sends an enquiry.” List the pages needed for that task. Identify the person who receives the request.
Use this short record during the release:
| Item | Example to replace with your own information |
|---|---|
| Main task | Send a service enquiry |
| Entry page | Service overview |
| Required action | Submit the contact form |
| Success condition | The intended recipient receives the request |
| Release owner | The person who can publish or restore the website |
These are examples, not measured results. Record the actual outcome of each check. An unfinished contact form is a release problem even when every page looks complete.
Replace demonstration content
Search for the template's original company name, sample email addresses, placeholder links, and demonstration prices. Check the page source as well as visible text. A sample title can remain in metadata after the main heading changes.
Use your real content on every page type. Try a long project title, a short description, and a page without an optional image. Confirm that the template still presents the information clearly.
Check whether the licence covers the assets you keep. A template licence does not automatically describe the rights for every photograph or font. Read our template licence guide when the source terms are unclear.
Check navigation and missing pages
Follow the main navigation from an internal page. Then open the same destination directly by its URL. Check the logo link, footer links, and any links inside cards.
Record a destination for every visible action. Replace an empty link with a working destination or remove the action until it is ready. Do not send every unfinished action to the homepage.
Request a URL that does not exist. Confirm that the server reports a missing page and presents a useful way back. A missing page should not silently display an unrelated successful page.
Test forms with real delivery
A static page can display a form without processing it. Check the form service or server endpoint separately.
- Submit a valid request with an address you control.
- Confirm that the intended destination receives it.
- Submit the form with a required value missing.
- Confirm that the page explains how to correct the error.
- Try again after a failed submission.
- Check the confirmation message on a phone.
Use test content that you can identify. Do not send real customer details through an unverified form. Record who owns the form service and where future delivery errors appear.
Check images and mobile content
Use an image size that suits the space on the page. Provide responsive image sources where the layout needs different sizes. Set image dimensions so the browser can reserve space before the file loads. The MDN image reference explains the relevant HTML attributes.
Review the page with the real heading lengths and image shapes. A landscape demonstration image can hide a problem that appears with a portrait.
Follow the mobile template checklist. Also perform an initial accessibility review before publication.
Confirm search access
Review the production title, description, canonical URL, and indexing directive. Check that they describe the real page and domain. Remove a development restriction only from pages that you intend to publish.
A sitemap helps search engines discover important URLs. It does not guarantee that they will crawl or index each page. Keep internal links useful even when a sitemap exists. See Google's sitemap guidance.
Our SEO checklist covers these checks in more detail. Keep account pages and private previews outside the public content plan.
Prepare recovery before publication
Record the version that you will publish. Keep the previous working build available. Identify the person who can restore it and the actions that justify restoration.
For a small service website, failure of the contact form can be more serious than a minor spacing defect. Agree on that distinction before release.
After publication, repeat the main visitor task on the public domain. Confirm that the expected assets and content belong to the new release. Record the date and the result. A local check cannot establish what the public server delivers.
When is the website ready?
The website is ready when the required tasks pass and the owner accepts any remaining limitations. Keep unresolved items explicit.
Do not describe the release as checked when you only inspected the homepage. The scope of the record should match the scope of the work.
Start with how to choose a website template if the current template cannot support the required pages or editing process.
