Client Website Launch Checklist: What Agencies Need From Clients Before Launch

Short answer

A client website launch checklist helps agencies collect everything clients must provide or approve before go-live: final content, safe access paths, DNS ownership, form routing, legal review, stakeholder feedback, launch-day availability, and final approval. The best checklist assigns each client-owned task to a named owner so blockers are visible before launch week.

Why agencies need a client website launch checklist

Website launches rarely depend only on the agency team.

By the time a site is close to go-live, the final work often sits with the client: approving copy, confirming business details, inviting the agency into tools, deciding who owns DNS, testing forms, reviewing legal language, and giving final launch approval.

When those requests live across email threads, meeting notes, Slack messages, and comments, the launch can feel nearly done while the actual launch readiness is still fragile.

A client website launch checklist fixes that by making client-owned launch tasks visible, specific, assigned, and easy to follow up on.

It answers four practical questions:

1. What do we still need from the client?
2. Who owns each item?
3. What blocks launch?
4. What can safely move to post-launch?

That difference matters. A project can be 90 percent complete and still not ready if one client-side task blocks go-live.

What should agencies collect from clients before launch?

Before launching a client website, agencies should collect or confirm:

• Final approved page content
• Final images, logos, downloads, and brand assets
• Business details such as addresses, phone numbers, hours, and service areas
• Domain, DNS, hosting, CMS, analytics, and Search Console access plans
• Redirect decisions for changed or removed URLs
• Form recipients, CRM routing, and autoresponder details
• Legal, privacy, cookie, accessibility, and compliance approvals
• Stakeholder feedback and final decision ownership
• Launch-day availability from the client team
• Final written launch approval

The checklist should separate agency-owned work from client-owned work. Internal QA matters, but it does not replace client confirmation.

Client website launch checklist for agencies

Use this checklist as a practical framework for the client side of your website launch process.

1. Final page content

Content should be treated as a launch dependency, not a loose creative input.

Agencies should collect final approved content for:

• Homepage sections
• Service or product pages
• About page
• Team bios
• Case studies
• Testimonials
• Pricing or package language
• Careers or hiring pages
• FAQ content
• Footer text
• Calls to action
• Downloadable PDFs or lead magnets

The key word is approved.

A draft document, a forwarded email, or a comment that says “this should work” is not the same as final launch-ready content. Before go-live, the client should confirm that the content can be published as written.

Track content with clear status labels:

This prevents a common launch-week problem: everyone says the content is “done,” but nobody knows whether it was actually approved.

2. Images, files, and brand assets

Clients often underestimate how many assets a website launch needs.

Ask for:

• Logo files in approved formats
• Brand guidelines
• Approved photography
• Team headshots
• Product or location images
• Partner logos
• Customer logos with permission to publish
• Case study images
• PDF downloads
• Social sharing images
• Icons or illustrations, if client-owned

For each asset, confirm whether the agency has permission to publish it. This is especially important for testimonials, customer logos, licensed photography, partner logos, and regulated industries.

A useful launch task is specific:

Please approve the three customer logos on the homepage by Thursday at 2 p.m., or confirm which ones should be removed before launch.

That is easier to act on than “please review assets.”

3. Business details and operational facts

Small business details can become annoying launch blockers because they are easy to leave until the end.

Confirm:

• Legal business name
• Public brand name
• Address or service area
• Phone numbers
• Email addresses
• Office hours
• Location details
• Team names and titles
• Product or service availability
• Pricing or package details
• Social profile URLs
• Careers or hiring links
• Emergency or support contacts

This is not just housekeeping. Incorrect hours, addresses, phone numbers, or service areas can create real client frustration after launch.

For multi-location, franchise, healthcare, legal, finance, or home services websites, assign operational details to someone who can verify them instead of asking the general project contact to guess.

4. Safe access to accounts and tools

Access can delay a launch quickly, but it needs to be handled carefully.

Agencies may need access to:

• CMS
• Hosting
• Domain registrar
• DNS provider
• Analytics
• Tag manager
• Search Console
• CRM or form tool
• Booking tool
• Email marketing platform
• Plugin or theme accounts
• Third-party widgets

Clients should not paste passwords, API keys, recovery codes, private tokens, SSH keys, payment credentials, or other secrets into Shipperly, a project board, a spreadsheet, or a normal message thread.

Use safer access options instead:

• Invite the agency as a user with the right permission level.
• Create a temporary user account for the agency.
• Ask the client’s IT or admin contact to complete the action directly.
• Use a secure password manager when credential sharing is truly necessary.
• Share only non-sensitive confirmations, such as “Agency added as admin” or “DNS admin will update records on launch day.”

Track the access path, not the secret.

This keeps the website launch process moving while avoiding unsafe credential handling.

5. Domain and DNS ownership

Do not wait until launch day to ask who controls DNS.

Before go-live, confirm:

• Domain registrar
• DNS host
• Current DNS owner
• Whether the agency will be invited as a user
• Whether the client admin will make the changes
• Required DNS records
• Launch window
• Time zone
• Backup contact
• Whether email or other services depend on existing records

Domain and DNS work is a classic hidden blocker. The client may know who bought the domain years ago, but not who controls the DNS now. Sometimes DNS is managed by IT, a former vendor, a hosting company, or a founder’s personal account.

The checklist should identify the person who can make the change and confirm they are available during the launch window.

6. Redirect decisions and SEO launch inputs

If URLs are changing, the client may need to help decide what happens to old pages.

Collect or confirm:

• Priority pages that must keep search visibility
• Old URLs that need redirects
• New destination URLs
• Pages that should be retired
• Pages that should remain live
• Whether any content is being consolidated
• Search Console access
• Sitemap submission plan
• Post-launch monitoring owner

Google’s site move guidance recommends preparing URL mappings, testing redirects, checking robots and noindex rules, and submitting updated sitemaps in Search Console when URLs change. For agencies, the practical takeaway is simple: redirect and indexing tasks should be handled before launch, not after the client asks why traffic dropped.

Client input matters because the agency may not know whether an old page still has business value, supports paid campaigns, receives sales referrals, or must remain available for compliance reasons.

7. Forms, lead routing, and conversion paths

A site can look finished and still fail if leads go to the wrong place.

Ask the client to confirm:

• Which forms should exist
• Who receives each form submission
• Whether submissions should enter a CRM
• Required fields
• Sales routing rules
• Autoresponder copy
• Thank-you pages
• Booking links
• Newsletter destinations
• Phone and email links
• Conversion events that matter

Then test the full path. Submit the form, confirm the inbox or CRM receives it, check the thank-you state, and verify any tracking that matters for launch.

Accessibility matters here too. Web.dev’s forms guidance emphasizes that form controls need clear labels so people understand what each field is for. At launch, agencies should at least check visible labels, required field messaging, keyboard access, error messages, and mobile usability on important forms.

Do not ask the client to “test the site” in general. Give them targeted tasks:

• Submit one Contact form test.
• Confirm the lead reached the correct inbox.
• Confirm the sales owner is correct.
• Confirm the autoresponder language is approved.
• Confirm the booking link opens the right calendar.

Specific requests reduce vague feedback and missed checks.

8. Legal, compliance, and policy approvals

Agencies should not guess on legal or compliance content.

Assign approval for:

• Privacy policy
• Terms and conditions
• Cookie notice
• Accessibility statement, if used
• Industry disclaimers
• Medical, legal, financial, or regulated claims
• Employment language
• Promotional terms
• Copyright-sensitive content
• Testimonials and case study permissions
• Customer logo usage

The approval task should name the owner and the page or asset being approved.

Weak request:

Please review legal pages.

Better request:

Please confirm by Friday whether the Privacy Policy and Terms pages are approved for launch, or identify the specific changes needed before approval.

That turns a vague review into a decision.

9. Stakeholder feedback and final approver

Many launches slow down because the agency is receiving feedback from several people without a clear decision owner.

Before final review, ask the client to name:

• Client Lead
• Final approver
• Backup approver
• Stakeholders who must review
• Stakeholders who may provide post-launch input
• Who can decide whether a late change blocks launch

A Client Lead is especially useful when multiple departments are involved. Instead of the agency chasing legal, marketing, sales, IT, and leadership separately, the Client Lead helps route requests internally and clarify decisions.

A simple rule helps:

During final launch review, every client comment must be marked as launch blocking or post-launch.

This keeps late feedback from turning into endless revision loops.

10. Launch-day availability and communication

A client website launch checklist should include the launch day itself.

Confirm:

• Launch date
• Launch window
• Time zone
• Agency launch owner
• Client Lead
• DNS or IT owner
• Final approver
• Backup contact
• Post-launch QA owner
• Communication channel
• Expected response time
• Rollback decision owner, if relevant

Do not assume people are available. A launch can stall because the DNS owner is on vacation, the final approver is traveling, or IT requires a ticket that should have been submitted days earlier.

11. Final launch approval

Final launch approval should be clear enough that the agency can look back later and understand exactly what happened.

Record:

• Approver name
• Approver role
• Date and time
• Website or launch scope approved
• Known open items
• Decision: approved, approved with exceptions, or not approved
• Notes
• Agency team member who recorded it

Shipperly can record final launch approval for operational reference. It should not be treated as a replacement for legal e-signature tools or formal contracts.

The point is operational clarity: the agency should not launch based on a scattered “looks good” message that nobody can find later.

Practical client launch request template

Use this structure when asking clients for launch items.

For access-related tasks, use a safe version:

Common mistakes agencies make with client launch checklists

Mistake 1: Asking for everything at once

A massive checklist can overwhelm the client. Group requests by owner, due date, and launch impact. Show what blocks launch first.

Mistake 2: Using vague owners

“The client” is not an owner. Neither is “marketing” or “leadership.” Assign a person or ask for a Client Lead who can delegate internally.

Mistake 3: Mixing secrets with normal launch tasks

Do not ask clients to paste passwords or sensitive credentials into the checklist. Track the safe access path instead.

Mistake 4: Treating received content as approved content

Content can exist without being ready. Track whether it is received, reviewed, approved, or blocking launch.

Mistake 5: Leaving final approval informal

Final approval should be explicit. Record who approved launch, when, what was approved, and whether any exceptions remain.

How Shipperly helps agencies manage client launch tasks

Shipperly is an AI launch coordinator for website agencies. It helps agencies keep client-side website launch work moving by organizing launch requests, assigning ownership, detecting risk, surfacing blockers, drafting follow-ups for agency review, and recording final launch approval.

For a client website launch checklist, Shipperly helps agencies:

• Turn client-owned launch tasks into clear requests
• Assign tasks to a Client Lead or specific stakeholder
• Show overdue, unassigned, and blocked items
• Keep unsafe credential sharing out of normal launch requests
• Give clients magic-link access to their action portal
• Draft follow-up messages for agency review
• Surface launch readiness risk before the final week
• Record final launch approval for operational reference

Shipperly is not a generic project management tool, credential vault, file storage system, legal e-signature tool, or autonomous AI email sender. It is built for the client-side launch work that often determines whether the website goes live on time.

FAQ

What is a client website launch checklist?

A client website launch checklist is a list of the content, access, approvals, decisions, QA confirmations, and launch-day details the client must provide before a website goes live. It helps agencies manage client-owned launch tasks instead of chasing them across scattered messages.

What should agencies ask clients for before launching a website?

Agencies should ask clients for final approved content, brand assets, business details, safe access paths, DNS ownership, form routing, legal approvals, stakeholder feedback, launch-day availability, and final launch approval.

When should an agency send the client launch checklist?

Send the checklist early, not during the final week. Add client-owned tasks as soon as they appear, especially access, content, DNS, legal review, and final approval requirements.

Should clients share passwords in a launch checklist?

No. Clients should not paste passwords, API keys, recovery codes, SSH keys, payment credentials, or private tokens into a launch checklist or client portal. Safer options include inviting the agency as a user, creating a temporary account, using a secure password manager, or having the client admin complete the action directly.

Who should own client-side launch tasks?

Each task should have a named owner. For larger client teams, agencies should ask for a Client Lead who can delegate requests internally and confirm which items block launch.

Make the client side of launch visible

A smooth website launch depends on more than the agency’s internal QA list. It depends on whether client-owned content, access, approvals, DNS decisions, and final sign-off are clear before the launch window arrives.

Shipperly helps agencies turn those client-side launch needs into assigned requests, visible blockers, reviewed follow-up drafts, and a final approval record. Use it to give your next client launch a clear path from “almost ready” to actually ready.