Website Handoff Checklist 2026: 57 Things to Get Before Final Payment

The most dangerous part of a website project is not always launch day.

It’s the handoff.

That’s when the site looks finished, the invoice is almost paid, and everyone assumes somebody else has the admin login, source files, DNS records, analytics access, backup plan, plugin license list, and form notification settings.

Then six months later the business needs to change a phone number, swap a hero image, fix a broken form, renew a domain, prove a lead source, or recover from a failed update. Nobody knows who owns what.

A good website handoff prevents that.

It protects the business owner from vendor lock-in. It protects the developer from support chaos. It protects the agency from “you never gave us that” emails after the project is closed.

This checklist is written for both sides of the table. If you’re a business owner, use it before final payment. If you’re a web professional, use it as your closeout SOP.

Why website handoff matters more in 2026

A business website is no longer just a few pages and a contact form. W3Techs reports that WordPress powers a large share of websites and holds the majority share among sites using a detectable CMS, which means many business sites now depend on themes, plugins, hosting rules, user roles, update schedules, and license renewals.

The risk is not theoretical. Verizon’s 2026 Data Breach Investigations Report says frequent breach causes continue to involve the human element, phishing, stolen credentials, and exploited software vulnerabilities. A messy handoff often leaves old contractor users active, passwords floating in email, and plugin updates nobody owns.

Performance and tracking matter too. Portent’s analysis of more than 27,000 landing pages found that B2B lead generation pages loading in 1 second convert 3x better than pages loading in 5 seconds and 5x better than pages loading in 10 seconds. If nobody documents what scripts were added, what events are tracked, or who can edit the tag manager, the business can lose leads quietly.

Accessibility should be part of handoff, not an afterthought. WebAIM’s 2026 Million report found 56.1 detected accessibility errors per homepage across the top one million sites. If the finished site has color contrast issues, missing labels, or broken keyboard behavior, somebody needs to own remediation after launch.

How to use this checklist

Do the handoff in two passes.

First, exchange ownership items before final payment. That includes domain access, hosting access, source files, analytics, Search Console, CMS admin rights, passwords, and paid licenses.

Second, review operational items 7 to 14 days after launch. That includes form delivery, indexing, redirects, conversions, uptime alerts, backups, and content editing comfort.

Do not send passwords in a plain email thread. Use a password manager, a one-time secret link, or account-level user invitations wherever possible. LastPass reports that many users remain confident about password management even while nearly two-thirds reuse the same password or a variation, so handoff should reduce bad password behavior instead of spreading it.

Part 1: Ownership and access

1) Domain registrar access

The business should know where the domain is registered, which email controls it, and when it renews. If the agency purchased the domain, transfer it or add the client as the controlling account owner.

2) DNS zone access

Document where DNS is managed, not just where the domain was purchased. DNS may live at Cloudflare, the registrar, hosting, or a managed IT provider. Cloudflare notes that proxied records use an automatic TTL of 300 seconds, so DNS behavior depends on the provider and record type.

3) Hosting account owner

The business should own the hosting account or have an owner-level login. Shared agency hosting can work, but the service agreement should say who owns the files, database, backups, logs, and migration rights.

4) CMS administrator account

Create a named admin account for the business owner or internal lead. Do not leave the only admin account under a developer’s personal email.

5) Remove unnecessary launch users

After launch, remove temporary developers, staging reviewers, old contractors, and test accounts. If access is still needed, reduce permissions.

6) Search Console owner access

Give the business at least one verified owner in Google Search Console. Google says Search Console owners can add and remove users, configure settings, view all data, and use all tools.

7) Google Analytics owner access

Make sure the business owns the GA4 property or has administrator access. If the agency created the property in its own account, move it or document the long-term access plan.

8) Google Tag Manager permissions

If GTM is used, hand over the account and container. Google’s Tag Manager documentation separates account permissions from container permissions, so verify both.

9) Google Business Profile access

For local businesses, confirm the website URL, appointment link, UTM rules, and owner access to the Google Business Profile. A website redesign can affect local lead flow if the profile points to the wrong page.

10) Paid tool and plugin licenses

List every paid license tied to the website: theme, plugin, form builder, SMTP service, CRM integration, page builder, SEO plugin, stock image subscription, cookie tool, backup service, CDN, and security monitor.

Part 2: Files, assets, and build materials

11) Source design files

Deliver the Figma, Sketch, Photoshop, Illustrator, or Canva files used to create the site. If the contract excludes editable files, say that plainly before the project starts.

12) Logo package

Include SVG, PNG, light, dark, horizontal, stacked, icon-only, and favicon versions. A business should not need to ask a developer for a logo file every time it sponsors a local event.

13) Image library

Provide final image files, original image sources, photographer credits, and license notes. If AI-generated images were used, document that too.

14) Font names and licenses

List the fonts, weights, and license source. Google Fonts, Adobe Fonts, custom commercial fonts, and self-hosted fonts each have different access and licensing needs.

15) Code repository

If the site uses a repo, give access to the repository, default branch, deployment workflow, environment naming, and rollback process.

16) Build and deployment instructions

Write the commands needed to build and deploy the site. If the site is static, document the framework, Node version, package manager, and hosting provider.

17) Database export process

For CMS sites, document how to export and restore the database. WordPress’s administration handbook includes backup guidance for both files and databases, which is a good baseline for what should be recoverable.

18) Staging site access

If a staging site exists, document its URL, login, password protection, sync process, and rules for pushing changes to production.

19) Environment variables

List the existence of environment variables without exposing secrets in a loose document. Store API keys in the platform’s secret manager or a password manager.

20) Third-party scripts inventory

Create a plain list of analytics scripts, ad pixels, chat widgets, heatmaps, consent tools, CRM embeds, review widgets, and scheduling tools. Script sprawl slows pages and makes troubleshooting harder.

Part 3: SEO and search continuity

21) Final URL list

Deliver the final live URL list for core pages, service pages, location pages, landing pages, and blog posts.

22) Redirect map

If URLs changed, provide a redirect map from old URLs to new URLs. Google’s site move and redirect documentation explains that redirects help users and search engines find the new location of moved content.

23) XML sitemap URL

Document the sitemap URL and confirm it uses canonical URLs. Google says sitemap URLs should be absolute and canonical.

24) Robots.txt URL

Document the robots.txt location and confirm it is not blocking important pages. Google says robots.txt is not a way to hide pages from Google because disallowed URLs can still be indexed if linked elsewhere.

25) Canonical rules

Document how canonicals are generated. Google warns against specifying different canonicals for the same page through different methods.

26) Title and meta description pattern

Provide the naming pattern for title tags and meta descriptions, especially if templates create them automatically.

27) Structured data notes

List schema types used on the site, such as Organization, LocalBusiness, FAQPage, Product, Article, BreadcrumbList, or Review. Include where the schema is edited.

28) Indexing verification

After launch, verify that Search Console can inspect important pages and that the live site is not using staging noindex rules.

29) Image alt text policy

Give the client a simple rule for alt text. Decorative images can be empty. Informational images should describe the useful content.

30) Internal linking map

Document important internal links, especially from homepage sections, service pages, case studies, and high-traffic blog posts.

Part 4: Analytics, leads, and conversion tracking

31) GA4 property ID

Record the GA4 property name, measurement ID, account owner, and data stream.

32) Key event list

List every tracked lead action: form submissions, phone clicks, email clicks, booking clicks, quote requests, checkout events, and file downloads. Google’s GA4 documentation explains that conversions are created from Analytics events and are used for measuring important actions across Analytics and Google Ads.

33) Tag Manager change history

If GTM is used, publish a clean launch version and name it clearly. Future troubleshooting is easier when the handoff version is obvious.

34) Form destination list

For each form, document who receives the notification, where submissions are stored, what autoresponder fires, and what CRM or email tool receives the lead.

35) Test submissions

Send test submissions through every form and record the result. Include mobile, desktop, required field errors, thank-you pages, spam protection, and CRM delivery.

36) Phone tracking rules

If call tracking is used, document the provider, dynamic number insertion rules, fallback number, and whether numbers are used in Google Business Profile or ads.

37) UTM policy

Define a simple UTM naming policy for ads, newsletters, QR codes, and partner links. Messy UTMs make reporting harder than it needs to be.

38) Dashboard link

If a Looker Studio, HubSpot, Shopify, Stripe, or CRM dashboard exists, include the link and the access owner.

Part 5: Security, backups, and compliance

39) Backup schedule

Document backup frequency, retention period, storage location, and restore owner. A backup that nobody has restored is not a plan.

40) Restore test

Run one restore test before closing the project or document why it was not done. For high-revenue sites, this should be required.

41) Update policy

Say who updates the CMS, plugins, themes, dependencies, and server packages. WordPress, Shopify, Webflow, custom apps, and static sites all have different maintenance needs.

42) SSL certificate owner

Confirm who issues and renews the SSL certificate. Many platforms automate this, but the client should still know where HTTPS is managed.

43) User role policy

Document who should be admin, editor, author, viewer, or billing owner. Most staff members do not need admin rights.

44) Password reset process

Give the client a safe reset path for CMS, hosting, DNS, analytics, and payment tools.

45) Security monitoring

List any uptime monitor, malware scanner, web application firewall, CDN rule, or alert email tied to the site.

46) Payment and checkout scope

If the site accepts payments, document the checkout provider and PCI responsibilities. Stripe’s PCI guide explains that its dashboard can help generate required PCI documentation based on a merchant’s integration.

47) Privacy and data handling

Document what personal data the site collects through forms, analytics, chat, payments, scheduling, and newsletter signup. The FTC Safeguards Rule requires covered financial institutions under FTC jurisdiction to maintain safeguards for customer information, and many businesses have industry-specific privacy duties beyond the website itself.

48) Cookie and consent tool access

If a consent banner is installed, document the vendor, settings, regions covered, and who updates the policy text.

Part 6: Training and operating rules

49) Editing guide

Create a short editing guide with screenshots for updating pages, posts, services, team bios, testimonials, images, and menus.

50) Content approval workflow

Clarify who can publish directly and who needs approval. This prevents a well-meaning employee from breaking a service page before a campaign.

51) Brand and copy rules

Include headline tone, CTA wording, button labels, image style, color rules, and words to avoid.

52) Maintenance calendar

Set a recurring schedule for backups, updates, analytics review, broken link checks, form testing, and content review.

53) Support agreement

Define what is included after launch: bug fixes, content edits, design changes, emergency response, analytics help, and new feature requests.

54) Emergency contact list

List the people or vendors to contact for DNS, hosting, payment failures, security alerts, forms, analytics, and development support.

55) Known limitations

Write down what the site does not do yet. Examples include multilingual support, online payments, inventory sync, CRM automation, ADA remediation, or advanced reporting.

56) Final sign-off record

Keep a signed or emailed record that confirms what was delivered, what access was granted, what remains open, and who owns next steps.

57) Thirty-day follow-up

Schedule a 30-day review before the project closes emotionally. By then, real users have submitted forms, clicked CTAs, hit mobile layouts, and exposed issues that QA missed.

The website handoff packet

If you want the short version, the final handoff packet should contain five documents:

1. Access map: domains, DNS, hosting, CMS, analytics, Search Console, GTM, CRM, email, payment, licenses, and owners.
2. Technical map: repository, deployment, staging, build steps, environment variables, database, redirects, sitemap, robots.txt, schema, and scripts.
3. Lead map: forms, phone tracking, key events, dashboards, autoresponders, CRM routing, and test results.
4. Maintenance map: backups, restore process, updates, uptime, security monitoring, privacy tools, and support responsibilities.
5. Training map: editing guide, approval workflow, brand rules, limitations, and 30-day review date.

That is not busywork. It’s the difference between owning a finished business asset and renting a website you don’t fully control.

FAQ

Who should own the website after launch?

The business should own the domain, hosting or platform account, analytics, Search Console, source files covered by the contract, and paid tool accounts. The agency or developer can still have access, but the client should not be locked out of its own business asset.

Should final payment happen before or after handoff?

The cleanest process is to define handoff deliverables in the contract and complete access transfer before final project closeout. Final payment terms vary, but nobody should be surprised by what is included.

What if the agency hosts the site?

Agency hosting is fine if the terms are clear. The agreement should cover uptime, backups, migration rights, support response, billing, data ownership, and what happens if the client leaves.

Is a shared password spreadsheet acceptable?

No. Use account invitations, role-based access, and a password manager. Spreadsheets get copied, emailed, forgotten, and reused.

How long should a handoff take?

A simple small business site can usually be handed off in a few hours. A custom site with CRM, payments, tracking, staging, and multiple vendors may need a formal handoff meeting and a 30-day follow-up.

Want a website you actually own?

If your current website is hard to edit, hard to track, or tied up in vendor accounts you don’t control, that’s fixable.

Start a project with Your Web Team and we’ll help you build a site with clean ownership, clear tracking, and a handoff packet your team can actually use.