A website handoff should answer a practical question: what happens when the opening hours, a price or a sentence needs to change?
A login is only part of the answer. The client also needs to know what they can edit, whether saving makes it public, and who can help if something goes wrong. Use this checklist before you close a website project, or to repair an existing handoff.
## 1. Separate ownership from editing access
Write down who owns the domain, hosting account and website workspace, and who pays each bill. Record renewal dates and the person responsible for them. Keep passwords in an appropriate password manager, not in the handoff document.
Then list the people who need editing access. Someone responsible for opening hours may not need access to billing, integrations or page layout. Check what the site's actual platform, plan and roles permit before promising a particular workflow.
## 2. Name the changes the client can make
“Update content” is too vague. Use examples taken from the actual site:
| Change | Agreed route |
| --- | --- |
| Replace the opening hours in an existing field | Client updates the field, then checks every page where it appears |
| Correct a sentence on the About page | Client edits it within the agreed access |
| Add a service, location or pricing tier | Discuss structure, scope and timing first |
| Change a booking or payment flow | Send a separate request to the person maintaining the integration |
This is a starting point, not a universal permission policy. A price change may be routine on one site and require business approval on another.
## 3. Explain saving and publishing separately
Have the client show you what happens when they save. Does the change become public immediately? Is there a draft? Can their role publish? Who approves wording that changes an offer or a promise?
Write down the observed behavior in plain language. Do not describe an approval stage that the current setup does not provide.
For example: “Saving this field updates the live page. Get the new holiday hours approved before saving.” Another site might instead say: “Save a draft and send the page link to Alex. Alex reviews and publishes it.”
## 4. Practise one real update together
Choose a small, authorized change that the client actually needs. Let them do the work while you observe.
Ask them to find the relevant page, replace the text, follow the correct publication process and reload the public page. Then check a narrow screen. Longer wording can wrap differently, and a changed button label still needs a working destination.
If the same information appears in several places, check those too. A correct contact page does not fix an outdated homepage banner.
The goal is to find the point where the client gets stuck before they need to make an urgent change alone.
## 5. Leave a recovery instruction they can use
Test which recovery actions their role actually permits. They may have version history, a draft they can discard, or only the ability to restore the previous wording manually.
Keep the old text for the practice change. Explain how to restore it and who to contact if the problem involves layout or functionality. Do not promise that undoing a text edit restores every part of a website.
## 6. Give requests a useful format
Use this template when a change still needs the developer:
> Page URL:
> Current wording:
> Exact replacement wording:
> Where else this appears:
> Required date and reason:
> Person approving the change:
> How we will check it after publication:
“Urgent” should include a reason. An expired offer and a preferred headline need different timing decisions. Agree a normal request channel and response window so the client knows what to expect.
## 7. Choose the simplest ongoing workflow
Use the existing CMS if it already handles the work well. Repeated records such as events or team profiles usually need structured fields and a clear way to add and remove entries.
A maintenance service may fit clients who prefer to send requests. State whether it covers requested edits, proactive checks for outdated information, or both. The [website maintenance cost tool](https://www.recopyfa.st/tools/website-maintenance-cost) can support that discussion; its estimates are not a quote for your project.
For occasional wording changes on existing pages, an in-place editor is another option. ReCopyFast adds an editing layer after a developer installs it. It does not rewrite source files or replace a CMS for new pages and structured publishing. Start with the [installation guide](https://www.recopyfa.st/docs/install) to understand the setup.
## A one-page handoff card
Copy this into your project documentation and fill it in together:
- **Site and account owners:** …
- **You can update:** …
- **Ask us before changing:** …
- **Saving does this:** …
- **Publication is approved by:** …
- **After an update, check:** …
- **To restore previous wording:** …
- **Send other requests here:** …
- **Normal response window:** …
A useful handoff is one the client can follow during their first update. If the instructions do not match the site's permissions or the client's preferred way of working, change the agreement before adding another tool.
A login is only part of the answer. The client also needs to know what they can edit, whether saving makes it public, and who can help if something goes wrong. Use this checklist before you close a website project, or to repair an existing handoff.
## 1. Separate ownership from editing access
Write down who owns the domain, hosting account and website workspace, and who pays each bill. Record renewal dates and the person responsible for them. Keep passwords in an appropriate password manager, not in the handoff document.
Then list the people who need editing access. Someone responsible for opening hours may not need access to billing, integrations or page layout. Check what the site's actual platform, plan and roles permit before promising a particular workflow.
## 2. Name the changes the client can make
“Update content” is too vague. Use examples taken from the actual site:
| Change | Agreed route |
| --- | --- |
| Replace the opening hours in an existing field | Client updates the field, then checks every page where it appears |
| Correct a sentence on the About page | Client edits it within the agreed access |
| Add a service, location or pricing tier | Discuss structure, scope and timing first |
| Change a booking or payment flow | Send a separate request to the person maintaining the integration |
This is a starting point, not a universal permission policy. A price change may be routine on one site and require business approval on another.
## 3. Explain saving and publishing separately
Have the client show you what happens when they save. Does the change become public immediately? Is there a draft? Can their role publish? Who approves wording that changes an offer or a promise?
Write down the observed behavior in plain language. Do not describe an approval stage that the current setup does not provide.
For example: “Saving this field updates the live page. Get the new holiday hours approved before saving.” Another site might instead say: “Save a draft and send the page link to Alex. Alex reviews and publishes it.”
## 4. Practise one real update together
Choose a small, authorized change that the client actually needs. Let them do the work while you observe.
Ask them to find the relevant page, replace the text, follow the correct publication process and reload the public page. Then check a narrow screen. Longer wording can wrap differently, and a changed button label still needs a working destination.
If the same information appears in several places, check those too. A correct contact page does not fix an outdated homepage banner.
The goal is to find the point where the client gets stuck before they need to make an urgent change alone.
## 5. Leave a recovery instruction they can use
Test which recovery actions their role actually permits. They may have version history, a draft they can discard, or only the ability to restore the previous wording manually.
Keep the old text for the practice change. Explain how to restore it and who to contact if the problem involves layout or functionality. Do not promise that undoing a text edit restores every part of a website.
## 6. Give requests a useful format
Use this template when a change still needs the developer:
> Page URL:
> Current wording:
> Exact replacement wording:
> Where else this appears:
> Required date and reason:
> Person approving the change:
> How we will check it after publication:
“Urgent” should include a reason. An expired offer and a preferred headline need different timing decisions. Agree a normal request channel and response window so the client knows what to expect.
## 7. Choose the simplest ongoing workflow
Use the existing CMS if it already handles the work well. Repeated records such as events or team profiles usually need structured fields and a clear way to add and remove entries.
A maintenance service may fit clients who prefer to send requests. State whether it covers requested edits, proactive checks for outdated information, or both. The [website maintenance cost tool](https://www.recopyfa.st/tools/website-maintenance-cost) can support that discussion; its estimates are not a quote for your project.
For occasional wording changes on existing pages, an in-place editor is another option. ReCopyFast adds an editing layer after a developer installs it. It does not rewrite source files or replace a CMS for new pages and structured publishing. Start with the [installation guide](https://www.recopyfa.st/docs/install) to understand the setup.
## A one-page handoff card
Copy this into your project documentation and fill it in together:
- **Site and account owners:** …
- **You can update:** …
- **Ask us before changing:** …
- **Saving does this:** …
- **Publication is approved by:** …
- **After an update, check:** …
- **To restore previous wording:** …
- **Send other requests here:** …
- **Normal response window:** …
A useful handoff is one the client can follow during their first update. If the instructions do not match the site's permissions or the client's preferred way of working, change the agreement before adding another tool.