What to include in a website template handover
Prepare editing instructions, service ownership, asset records, release checks, and recovery details when you hand a template website to a client.
On this page
A website handover needs more than a folder of template files. The next owner needs to edit content, control service accounts, publish changes, and recover from a failed release. Prepare those instructions before delivery.
This article gives a practical handover structure. It does not define legal ownership or replace the agreements for a particular project.
State what the delivery includes
List the pages, source files, assets, and integrations included in the work. Identify items that remain unfinished. Keep optional future work separate from the accepted delivery.
Record the template name and the version used. Identify the custom changes. That record helps a maintainer understand which instructions still apply to the original template.
Do not describe a form as complete when delivery remains unverified. Use the contact form checklist to record its actual state.
Write instructions for ordinary content work
Document one complete editing task. Show where the owner changes a page title, replaces an image, and publishes the change. Use the workflow the delivered project actually supports.
Explain how to preview a change before publication. Name the person who can approve it. State how unpublished material stays outside the public site.
Use clear headings for each task. The W3C heading guidance explains why organized headings help readers find content. The instructions still need accurate project details.
Give image instructions that include dimensions, file location, and alternative text. Link to the image sizing guide for general concepts. Keep project-specific requirements in the handover.
Record service ownership without exposing secrets
List the domain registrar, hosting provider, form service, and other required accounts. Name the owner of each account. Confirm that the client can use the agreed access method.
Use the provider's account transfer or invitation process where available. Keep passwords and recovery codes outside public documentation and source files.
Record which services renew automatically. Identify who receives billing and failure notices. Do not assume that an invitation also transfers billing responsibility.
Include the asset and licence record
List the source of retained photographs, fonts, icons, and template files. Keep the applicable terms with the project record. Ask the owner to resolve unclear rights before delivery.
The template licence guide identifies questions to ask. It does not establish the rights for a particular download.
State which images are generated when that information belongs in the delivery record. Do not describe a generated image as a photograph of a real customer or product.
Demonstrate the release and recovery process
Ask the next maintainer to perform one ordinary update from the instructions. Record where additional explanation is necessary. Correct those instructions before the handover closes.
Keep a known working release available. Identify the person who can restore it. Explain which service settings or stored records require a separate recovery process.
Use this delivery record:
| Item | Evidence | Completion condition |
|---|---|---|
| Content editing | Owner performs the documented task | Correct change appears in the approved preview |
| Account access | Agreed access works | Owner can manage required services |
| Form delivery | Identifiable test message | Intended destination receives the message |
| Publication | Documented release procedure | Approved version reaches the public domain |
| Recovery | Named version and procedure | Maintainer knows the applicable recovery steps |
| Remaining work | Explicit list with owners | Client understands each limitation |
These conditions define the review. They do not claim that a project passed it.
Keep support terms specific
State the agreed support channel and scope. Separate defect correction from new features and content work. Do not publish a response deadline that nobody accepted.
Use the maintenance plan to assign work after delivery. Use the launch checklist before the public release.
Choose a template from the directory whose editing process fits the people who will maintain it. That decision starts before the download.
