Add to Preferred Sources
When a web project closes, a website design handover checklist determines whether you own your domain outright, hold administrator access to your analytics, and have tested every form and integration — or whether you are signing off on assumptions. It maps every account credential, verified test and legal compliance document that must be in your hands before the agency sends its final invoice. For context on how a professional web design project in Johannesburg moves from brief to launch, the process shapes what a clean handover should contain.
Without a written checklist, SA operators regularly discover months after launch that they don't control their own domain registrar account, that GA4 is not recording a single conversion, or that the contact form routes enquiries to the developer's inbox. If you're still in the planning phase, the website planning guide for South African businesses covers what to lock down before a build starts. If you're at the close of a project, this checklist is what you run.
This web design handover checklist runs in five phases. Phases 1–4 must be confirmed before you sign off — including all legal compliance items, which cannot be deferred once a site is live. Phase 5 (documentation and training) may follow within 3–5 business days of launch, with completion dates agreed in writing before sign-off.
Quick Answer
A complete website design handover checklist runs through five phases: (1) quality and functionality — every page, form, link and device tested; (2) account access — domain, hosting, CMS, GA4, Search Console and payment gateway credentials transferred to the client; (3) SEO and performance — Search Console setup, redirects, Core Web Vitals; (4) legal compliance — POPIA privacy policy, SSL certificate, cookie consent and ECTA disclosures; and (5) documentation and training — site overview document and CMS walkthrough. Phases 1–4 are non-negotiable before sign-off — including all legal compliance items, which apply from the moment a site goes live. Phase 5 (documentation and training) may follow within 3–5 business days of launch, with completion dates agreed in writing before sign-off.
Jump To
Worried your agency won't hand everything over?
Share your project scope with us and we'll show you exactly what a complete handover should include for your platform, stack and business type.
Get a free consultationWhat a Complete Website Design Handover Checklist Contains
A website handover checklist is not the same as a website launch checklist. A website launch checklist confirms the site is technically ready to go live. A website design handover checklist confirms that you — the operator — own, can access, and can run everything that was built. The distinction matters because an agency can launch a site perfectly while still retaining control of your domain registrar account, leaving GA4 unconfigured, or delivering no training on the CMS they built for you.
The five phases below map to the natural sequence of a project close: quality assurance happens before the site goes live, credentials transfer happens at or just after launch, and training typically follows within the first week. Each table shows who is responsible for each item, and whether it must be confirmed before you provide written sign-off.
SA-specific items in this checklist
South African context appears throughout the phases: a POPIA-compliant privacy policy (required for all sites collecting personal data — POPIA s11 provides six lawful bases for processing, and a privacy policy is required regardless of which basis applies); a cookie consent notice (required before non-essential tracking cookies are set, where consent is the processing basis relied on); section 43 of the Electronic Communications and Transactions Act (ECTA) disclosures for transactional and e-commerce sites; local hosting providers (xneelo, Afrihost, and similar); and testing of local payment gateways (PayFast, Peach Payments, Yoco) where applicable.
Phase 1 — Quality and Functionality Confirmation
Every page, form, link and device must be confirmed working before the project closes, because a broken contact form on launch day is your responsibility from the moment you sign off. This phase belongs primarily to the agency to deliver, but you must witness or co-test before confirming — especially forms, which route to your inbox.
| Item | Who confirms | Required before sign-off? |
|---|---|---|
| All pages render correctly — no broken layouts, missing images or leftover placeholder text (Lorem ipsum, dummy headings, test product names) | Agency delivers; client confirms | Yes |
| Every internal link tested — navigation menus, footer links, in-body links, breadcrumbs, button links | Agency | Yes |
| Every contact form, quote form and booking form tested end-to-end: submission, on-screen confirmation message, email arrives in the correct inbox | Agency delivers; client confirms correct inbox | Yes |
| Payment gateway tested in sandbox mode (PayFast, Peach Payments, Yoco — whichever applies): test transaction completes, order confirmation arrives | Agency delivers; client confirms | Yes |
| Cross-browser test: Chrome, Firefox, Safari, Edge — desktop and mobile | Agency | Yes |
| Cross-device test: at least one Android and one iOS mobile device tested; tablet if relevant to your audience | Agency | Yes |
| 404 check — no broken internal URLs on any published page; crawl report provided | Agency | Yes |
| All images load and display correctly, including the Open Graph image used when pages are shared on social media | Agency | Yes |
| Content review complete — no dummy email addresses, placeholder phone numbers, test names or staging URLs visible on any live page | Agency delivers; client confirms content accuracy | Yes |
Test the form yourself
Submit your own contact form and check your business inbox immediately. This single test catches mis-configured email routing, which remains one of the most common handover failures — the form works, but the submissions land in the developer's inbox rather than yours.
Phase 2 — Account Access and Credential Transfer
The credential transfer phase is where legal ownership of the site becomes practical. You must be the account holder — not the agency — for every service your site depends on. The single most important item is the domain registrar account: whoever controls the registrar controls where your traffic goes and where your domain renewal notices are sent.
Credentials should be transferred via a password manager or a secure one-time link service — not in a plain email thread. Once transferred, the agency should remove their personal admin access unless they are on a signed maintenance retainer.
| Account / credential | What to confirm | Required before sign-off? |
|---|---|---|
| Domain registrar (xneelo, GoDaddy, Afrihost, Namecheap, or similar) | Your business is the registrant and account holder — not the agency or a freelancer. Domain renewal date noted and calendared. | Yes |
| Hosting control panel (cPanel, Plesk, or equivalent) | Client has admin access. Hosting plan tier and renewal date documented. | Yes |
| CMS admin login (WordPress, Webflow, Wix, or similar) | Client holds at least one admin account with full permissions. Agency retains a separate admin account only if on a signed maintenance retainer. | Yes |
| GA4 property | Client Google account is listed as Administrator on the GA4 property — not Viewer. Agency access is a separate Editor or Analyst role. | Yes |
| Google Search Console | Client Google account is a verified Owner of the property. XML sitemap has been submitted. | Yes |
| Google Business Profile (if applicable) | Client email is listed as a primary Owner of the profile. | Yes |
| Business email and email hosting | Client can log into the email hosting panel and manage mailboxes independently of the agency. | Yes |
| Payment gateway merchant accounts (PayFast, Peach Payments, Yoco) | Merchant account registered in the business name. API keys stored securely, not in a plaintext document or email. | Yes |
| SSL certificate — renewal date and provider | Certificate active and HTTPS enforced site-wide. Renewal date calendared. No mixed-content warnings in browser console. | Yes |
| FTP / SFTP access (if applicable) | Credentials transferred to client's password manager. | Can follow within 7 days |
| Backup schedule and storage location | Automated backups confirmed running. Client can locate and restore from a backup without agency involvement. For full guidance, see website backup best practices. | Yes |
What this looks like when it goes wrong
An operator signs off on a new WordPress site. Three months later the domain expires because the registrar account is in the agency's name and the renewal notice went to the agency's inbox. The site goes offline, and recovery requires the agency's cooperation to transfer ownership — cooperation that costs time and, sometimes, money. Building the site was not the problem; the ownership transfer was never documented.
Phase 3 — SEO and Performance Verification
SEO and performance checks confirm that the site is visible, crawlable, and fast enough to rank and convert — three things a visually finished site may still fail. These checks belong to the agency to run, but must be evidenced with a shared report or screenshots before sign-off. For a deeper look at how Core Web Vitals affect South African websites specifically, including how mobile network conditions affect real-user field data, see the dedicated guide.
| Item | What to confirm | Required before sign-off? |
|---|---|---|
| Staging noindex tag removed | The noindex directive that blocked the staging environment from Google has been removed from the live site. Confirm via a browser page-source check or Search Console Settings → Crawling. | Yes — this single omission can leave a site invisible to Google for weeks |
| XML sitemap submitted to Google Search Console | Sitemap.xml present, accessible at /sitemap.xml, and submitted in Search Console. Priority pages included and returning 200 status. | Yes |
| Redirect map implemented (redesigns only) | All changed URLs have a 301 redirect to the new equivalent page. No redirect chains. No old URLs returning a 404 without a redirect. For context on what URL changes typically accompany a redesign, see website redesign costs and scope in South Africa. | Yes for redesigns; N/A for new sites |
| Core Web Vitals — lab data | PageSpeed Insights (or Lighthouse) shows LCP under 2.5 s, INP under 200 ms, CLS under 0.1. Google's page experience documentation confirms Core Web Vitals are used by its ranking systems. Field data requires real traffic and populates over several weeks post-launch. | Yes — lab data at launch; field data monitored post-launch |
| HTTPS enforced site-wide | All pages load on HTTPS. Any HTTP URL redirects to the HTTPS equivalent. No mixed-content warnings appear in the browser console. | Yes |
| Canonical tags | Every page has a self-referencing canonical. Paginated pages, filtered catalogue URLs, and tag/category pages handled correctly to avoid duplicate-content signals. | Yes |
| Unique title tags and meta descriptions | No duplicate or missing title tags. Meta descriptions present and unique for all priority pages. | Yes |
| Alt text on images | All content images have descriptive alt text. Decorative images use an empty alt attribute (alt=""). | Yes |
| Robots.txt verified | Robots.txt does not block pages that should be indexed. Does not expose sensitive directories (e.g., admin paths). | Yes |
| GA4 conversion events firing | Real-time GA4 shows active sessions when browsing the live site. Form submission, purchase, or primary CTA events are firing correctly. Check in GA4 DebugView before sign-off. | Yes |
The staging noindex trap
Agencies routinely set a noindex directive on staging environments to prevent Google from indexing the work-in-progress site. The trap is forgetting to remove it on launch day. A site can look live to visitors while remaining completely invisible to Google. Confirm the removal with a page-source check — look for noindex in the <head> — before you close the project.
Phase 4 — Legal Compliance and Privacy Setup
Legal compliance on a South African website primarily means POPIA and ECTA requirements — both of which apply from the moment a live site collects any personal data, including an email address submitted through a contact form. These items cannot be deferred to after launch. For a comprehensive view of what your site must include under both POPIA and accessibility regulations, see the website compliance checklist for South Africa.
| Item | What to confirm | Required before sign-off? |
|---|---|---|
| POPIA-compliant privacy policy | Privacy policy accessible from every page (typically footer link). It must describe what personal data is collected, the purpose and lawful basis for collection, how long it is held, and how a user can request deletion or access. A generic template copied from another site does not meet POPIA's specificity requirements. | Yes — the site cannot legally collect personal data without it |
| Cookie consent notice | A cookie banner appears on the first visit and records explicit consent before non-essential cookies (GA4, Meta Pixel, remarketing tags) are set — where consent is the lawful basis relied on for those cookies. Consent must be freely given and withdrawable. (Sites relying on a different POPIA s11 lawful basis for analytics processing should document that basis in their privacy policy.) | Yes — where non-essential cookies are used |
| ECTA section 43 disclosures (transactional sites) | If the site sells products or services, section 43 of the Electronic Communications and Transactions Act requires the site to display the full business name, registration number, physical address, and returns or refund policy on an accessible page — not only in a footer line. Confirm these are present and accurate. | Yes for transactional / e-commerce sites |
| Terms and conditions | T&Cs present, linked from checkout or service enquiry forms, and written for your specific offering — not a generic global template. | Yes for transactional / service sites |
| Data processing agreement with agency | POPIA requires a written agreement with any party that processed personal data on your behalf during the build. If the agency had access to your CRM data, form submissions, or customer records, confirm a data processing agreement exists and is signed before the project closes. | Yes where personal data was processed by the agency |
Why the data processing agreement matters
POPIA requires responsible parties (your business) to have a written contract with any operator that processes personal information on their behalf. If your agency accessed customer data, form submissions, or any personal information during the build — even temporarily in a staging environment — a data processing agreement should be in place before the project closes. This is a legislative requirement, not optional documentation.
Phase 5 — Documentation and Client Training
The documentation and training phase has one goal: you can make common content changes — page text, images, blog posts, team profiles — without calling your agency. Every WordPress or CMS-built site should come with at minimum a recorded walkthrough and a written site overview document. Without these, you are operationally dependent on the agency for tasks you paid to own.
| Item | What to confirm | Can follow post-launch? |
|---|---|---|
| Site overview document | A written document (one to two pages) covering: CMS platform and version, hosting provider and plan name, theme or framework, all active plugins or integrations (with renewal dates and costs), and key dependencies. Stored in your Google Drive — not the agency's. | Within 3 business days of launch |
| Recorded CMS walkthrough | A screen-recorded walkthrough covering: how to edit a page, update a hero image, add a blog post, update navigation, and edit footer contact details. For WordPress builds, a minimum 20-minute recording. Stored in your Google Drive or as an unlisted YouTube video. | Within 5 business days of launch |
| DIY vs. developer boundary defined in writing | A written guide — even a short one-page document — specifying which changes you can safely make in the CMS and which require a developer. This prevents accidental theme edits, plugin updates, or PHP changes that break the site. | Within 5 business days of launch |
| Escalation path documented | Named contact at the agency or support service, response-time commitment, and process for urgent issues (site down, checkout not working). If no maintenance agreement exists, confirm the hourly rate and response time for ad-hoc requests. | Before sign-off — agree this in the handover document |
| Ongoing maintenance plan agreed | Who handles WordPress plugin updates, theme updates, security patches, and backup verification — and at what frequency and cost. Without a plan, these fall to you. For a full breakdown, see the website maintenance guide for South Africa. | Before sign-off — agree this in the handover document |
Ask for the site overview document
The site overview document — platform, hosting plan, all plugins with renewal dates, all third-party integrations — is the single most useful thing an agency can leave behind. If your agency doesn't provide it automatically, ask for it before settling the final invoice. Two years from now, when someone asks what CMS version you're running or when the SSL renews, this is the document you'll want.
Structuring the Formal Sign-Off
A formal sign-off is a short written document — one email or a PDF — that records which checklist phases were confirmed, by whom, and on which date. It triggers the final invoice and starts any agreed warranty or post-launch support period. Without it, a dispute three months later about whether a form was working at handover becomes a memory argument rather than a documented record.
The sign-off document should cover:
- Date and names of both parties
- A list of all checklist phases confirmed, and any items explicitly deferred with agreed completion dates
- Confirmation that client has received access to all accounts in Phase 2
- Statement that the client accepts the site in its current state, subject to any documented exceptions
- Agreed maintenance and escalation arrangement going forward
- Permission for the agency to use the project as a portfolio reference (if agreed)
For projects where you're commissioning a new site from scratch, the process that leads to a clean handover starts well before build: at the brief stage. The website project brief template for South Africa covers how to document requirements in a way that makes handover accountability clear from the start.
Not sure if your current site was properly handed over?
Tell us your platform, hosting setup and what access you currently hold — we'll show you what's missing and what it takes to fix it.
Get a free handover reviewWhy South African Businesses Choose Growth Pulse Media for Web Projects
Growth Pulse Media's web design work is operator-led, not agency-templated. Dirk van Greuning, the founder, built and scaled a South African ecommerce business before founding the agency — web build decisions are shaped by someone with direct experience operating SA digital businesses, not just advising on them. That operator's background informs what gets handed over and why each item on the checklist matters.
Our web design service operates with a limited client load, so senior attention stays on every project rather than being split across fifty accounts. Handovers include a full site overview document, a recorded CMS training session, and a structured sign-off checklist — not because clients ask for it, but because that is the standard we hold ourselves to. All work is executed in-house.
If you're weighing your options for a new web project, see responsive web design best practices for South African sites for the technical decisions that shape both the build quality and how easy the site is to hand over and maintain.
Who This Is NOT For
You want to hand the checklist to the agency and walk away
The credential transfer and testing phases require your direct involvement. Delegating the entire handover to a project manager who doesn't know your business email login or GA4 account structure means nobody verifies the things that actually matter. Checklists are tools, not proxies — the credential checks in Phase 2 must be confirmed by the person who will own those accounts.
You're closing the project the same day the site goes live
A same-day close skips the first 24–48 hours of live observation, when redirect errors, missing tracking events, and form routing failures first appear. Build at minimum 48 hours of post-launch monitoring into the handover window before providing formal written sign-off. This is not bureaucracy — it is the gap between a problem the agency fixes and a problem that is now yours.
Your site is built on a proprietary builder tied to the agency's hosting
If the platform locks your site to the agency's infrastructure and tools, a credential transfer doesn't give you real ownership — it gives you a password to an account you can't take elsewhere. Confirm before a build starts whether the finished site can be exported, migrated, or self-hosted independently. If the answer is no, the "handover" is a formality, not a transfer.
You have no ongoing maintenance plan
A complete handover transfers responsibility for security patches, plugin updates, and backup verification to you. If you don't have an agency maintenance agreement and aren't prepared to manage these tasks yourself, the checklist alone doesn't protect the site. Unpatched WordPress plugins are a primary entry point for site compromise — see the website security checklist for small businesses for what that means in practice.
Ready to launch your next SA web project properly?
Book a no-obligation call and we'll scope what a clean build, structured handover, and post-launch support plan looks like for your business.
Book a free scoping callFrequently Asked Questions
What should be included in a website design handover checklist?
A website design handover checklist should cover five areas: quality and functionality (all pages, forms and links tested across browsers and devices); account access (domain, hosting, CMS, GA4, Google Search Console and payment gateway credentials transferred to the client); SEO and performance (staging noindex removed, sitemap submitted, redirects implemented, Core Web Vitals confirmed); legal compliance (POPIA privacy policy, cookie consent, ECTA disclosures for transactional sites); and documentation and training (site overview document and recorded CMS walkthrough).
Who is responsible for the website handover — the agency or the client?
The agency is responsible for delivering every item on the checklist; the client is responsible for confirming them before signing off. Quality testing, technical SEO and performance checks belong to the agency to run and evidence. Credential transfers require the client to confirm that the right business account — not the agency's account — is the holder for the domain, hosting and analytics. Both parties sign the handover document.
What access do I need from my web designer when a project closes?
At minimum: your domain registrar account in your business name; your hosting control panel login; your CMS admin credentials (e.g. WordPress admin); GA4 as an Administrator, not a Viewer; Google Search Console as a verified Owner; and login for any payment gateway your site uses. You should also have the SSL renewal date and backup location documented in writing. Request these in writing before settling the final invoice — do not sign off until they are confirmed.
What POPIA requirements apply to a new website in South Africa?
A live site that collects any personal data — including contact form submissions — must have a POPIA-compliant privacy policy accessible from every page, and a cookie consent mechanism that records explicit consent before non-essential cookies are set. If the agency handled any personal data during the build (including access to form submissions or CRM records), a written data processing agreement is required between your business and the agency before the project closes. These requirements apply from the moment the site goes live.
How long should a website handover take?
A properly phased handover typically spans 3–7 business days from the agency's final build to formal written sign-off. Quality checks, SEO verification and credential transfer happen in the days around launch; documentation and training follow within 3–5 days post-launch, with completion dates agreed in writing before sign-off. A same-day handover that skips post-launch observation is a warning sign — at minimum 48 hours of live monitoring should precede final written acceptance.
Get Your Website Built — and Properly Handed Over
Growth Pulse Media delivers South African web design with full documentation, a recorded CMS training session, and a structured website handover process — so you own and can operate what you paid for from day one. We work in-house, keep a limited client load for senior attention on every project, and will get back to you within 24 hours. No obligation.
Start your web project