Website Handover Checklist for Agencies: Before Client Sign-Off

By SiteSutra · 17 October 2026

An approved website preview is an important milestone. It is not the whole handover. Your agency still needs to know which source version was accepted, who controls the accounts, how important interactions were tested and what happens after launch.

For a design or marketing agency working with a white-label developer, these decisions protect the client relationship and make the next change easier to manage. This checklist helps define an inspectable delivery package. It is a planning framework, not a record of a SiteSutra client engagement.

Agree what sign-off actually covers

Separate design approval, functional acceptance and permission to publish. A client may approve the appearance while content, account access or an integration is still pending. Record those decisions explicitly rather than treating one approval message as acceptance of everything.

Before work starts, agree the pages, interactions, review rounds, supported test conditions and named approver. If the client supplies copy or provider access, list those dependencies. A change to the approved brief should receive a cost and schedule assessment before development proceeds.

Request a handover package you can inspect

Make source delivery usable

A folder named final is difficult to audit when several rounds of feedback exist. Ask for a named revision, the corresponding preview and any generated files needed for release. The instructions should say how to run, build and deploy the agreed site, including any dependencies.

For example, a static website may contain source templates plus generated HTML. If hosting serves generated files, handing over templates alone may not match the preview. The handover should explain which files are edited, which are generated and how the two stay in sync. This is an implementation example, not a requirement to use one particular platform.

Keep credentials outside the repository and public documentation. Account owners should grant appropriate access through the provider’s supported roles. Your handover inventory can name the provider and responsible person without containing passwords or secret keys.

Ask for test evidence, not a checked box

A note saying mobile tested does not tell the agency which pages, widths or interactions were reviewed. Ask for enough context to repeat important checks and distinguish a defect from a new request. Record the browser or device conditions, expected behaviour, observed outcome and reviewer.

W3C’s Easy Checks covers initial reviews of areas including titles, headings, keyboard focus, image alternatives and form labels. It also makes clear that a basic pass does not establish comprehensive accessibility. Use such checks as a starting point, with any deeper assessment defined in the project scope.

• Follow navigation and the primary call to action using a keyboard.
• Check visible focus and whether menus can be opened and closed.
• Review headings, labels and important content on narrow screens.
• Inspect content and navigation when text is enlarged.
• Record remaining issues and who decides whether they block release.

web.dev’s form-testing guidance recommends keyboard testing and checking that focus order follows the visual order. A polished screenshot does not demonstrate those behaviours. The agreed test record should include functional states, not only the default design.

Treat forms and bookings as complete journeys

Check an empty required field, an invalid value, a valid submission, a failure state and the intended destination. Test messages should be agreed with the recipient and kept separate from customer enquiries. A visible success message is useful only when it accurately describes what the system has confirmed.

MDN’s form-validation guidance distinguishes browser checks from server validation: browser validation can help people correct input, but it is not sufficient protection for a receiving service. Where a form uses an external provider, document who controls that provider and what validation and delivery checks were completed.

For a booking flow, identify the event, timezone handling, calendar connection and notification recipient. For an email-draft link, state that the visitor still has to send the email. A demonstration form that does not submit should remain clearly described as a demonstration.

A hypothetical landing-page handover

Imagine a branding agency commissions a developer to implement an approved campaign page. The agency supplies copy and visual assets. The developer delivers the page, responsive navigation and an enquiry integration. The client controls the receiving inbox.

The agency could accept the layout and source revision while recording that inbox access is still missing. The enquiry integration should remain an unresolved acceptance item until an authorised person confirms receipt. That is more useful than marking the entire project complete or hiding the dependency in a chat thread.

A suitable record would identify the pending test, its owner and the decision required before publication. This example does not claim a completed project, verified integration or commercial result.

Define the white-label working boundary

Specify who speaks to the end client, who approves changes and whether the developer may use any material in a portfolio. Source access does not automatically confer permission to publish client names, designs or internal conversations.

A handover should also record recurring provider costs and ownership of the domain, hosting and other accounts. Confirm the agreed editable files and licence conditions. Resolve questions about usage rights in the project agreement rather than assuming that every supplied asset can be reused freely.

Separate release support from future changes

Record the support period or arrangement, the route for reporting faults and how new work is estimated. An implementation fault, a new content request and a provider outage may need different responses. The agreement should explain those boundaries in terms the agency and client understand.

Keep an identifiable previous release and a documented rollback route. Before relying on it, confirm what restoring the website would and would not restore. Site files, provider settings and any external data may be managed separately.

Download the handover review sheet

Download the agency website handover checklist (CSV). Assign a reviewer, attach appropriate evidence and record open decisions. Its rows are initially unreviewed: downloading or completing the sheet does not certify the site or authorise a production release.

Keep private account and customer details in your approved internal system. The checklist needs a reference to evidence, not passwords or copied customer messages. Use the scope guide to agree responsibilities before work starts and the editing and maintenance guide to clarify what the client needs after delivery.

Start an agency pilot with a defined handover

For the next project, agree one deliverable and its acceptance package before estimating. That gives your agency a concrete way to review implementation quality and the working relationship.

Explore SiteSutra’s white-label web development for agencies, inspect the original working concepts, or bring an approved brief to a discovery call. For a direct business project, see small-business website development and redesign.

References checked on 17 October 2026

• W3C WAI: Easy Checks — a first accessibility review
• web.dev: Test forms across devices and platforms
• MDN: Client-side form validation

The handover framework, hypothetical brief and worksheet are SiteSutra’s planning material. They are not a claim of client results or an accessibility certification.

Put the guidance into your project

• White-label web development for agencies
• Website redesign and handover