The Client Website Launch Checklist Agencies Actually Use

Most website launch checklists on the internet are written for one person launching one site. They assume you own the hosting login, you remember which plugins you installed, and you will notice if something breaks because it is your own business. That is not how an agency works. We launch dozens of these a year, on accounts we do not always control, for clients who will notice the day a contact form goes quiet, and hold us to it.

So this is the checklist I actually run, grouped by phase, written for the team that launches client sites for a living. It is platform-agnostic on purpose. Some of it is obvious. The obvious items are the ones that get skipped when launch day runs long, which is exactly why they belong on a list and not in your head. Bookmark it, fork it, turn it into a template in whatever you run your projects in.

Phase 0: The week before launch

The single most expensive launch mistakes happen before launch day, in the part everyone treats as admin. Get the access and the approvals locked down early, while there is still time to chase a client who has not replied.

• -Collect every credential you will need: domain registrar, DNS host, current hosting, email, and any third-party tools. Log into each one now, not on launch day.
• -Confirm who actually controls the domain. The number of launches stalled because the domain is locked inside a former web guy's personal GoDaddy account is not small.
• -Lower the DNS TTL on the records you are about to change to 300 seconds, a day or two ahead, so the cutover propagates in minutes instead of hours.
• -Get explicit written sign-off on the final content and design. "Looks good" in a meeting is not sign-off; a reply on the staging link is.
• -Pick a launch window that is not Friday afternoon. If it breaks, you want a full business day to fix it.
• -Take a full backup of the existing live site (files and database, or an export) before you touch anything.

Content and copy

Clients judge a launch on typos and stock photos long before they judge it on Core Web Vitals. This is the cheap, high-visibility pass, so do it with fresh eyes and do it last as well as first.

• -Proofread every page out loud, or paste it through a checker. Headlines and CTAs are where typos hide because everyone skims them.
• -Kill every piece of placeholder text. No lorem ipsum, no "describe this item," no "coming soon" that nobody plans to finish.
• -Check the client's business name, phone number, address, and hours appear correctly everywhere, and match their Google Business Profile exactly.
• -Replace stock-everything with real photos and real proof. Stock is the fastest tell of a generic site.
• -Confirm every image is correctly sized and licensed, with meaningful alt text on anything that conveys information.
• -Verify the heading hierarchy reads as an outline: one clear H1 per page, then H2s and H3s in order, not chosen for how big they look.

SEO and metadata

The number one thing that silently tanks a launch is shipping with the staging site's "discourage search engines" setting still on. I have seen agencies launch a beautiful site and wonder for three weeks why it will not index. Check this first, then everything else.

• -Remove the noindex. Confirm the live site is crawlable: no leftover noindex meta tag, no Disallow: / in robots.txt carried over from staging.
• -Write a unique title tag (around 60 characters) and meta description (around 150 to 160) for every important page. No two pages sharing a generic site-wide title.
• -Set canonical URLs so the staging domain, www, and non-www do not fight each other for the same content.
• -Generate an XML sitemap and submit it in Google Search Console. Verify ownership of the production domain, not the staging one.
• -Add structured data where it fits: LocalBusiness, Organization, Article, FAQ. It is free eligibility for rich results.
• -Set Open Graph and Twitter card tags, then actually paste a URL into a preview tool to confirm the image and title render.
• -Add a favicon and the touch icons. A missing favicon is a tiny thing the client always notices.

Performance and Core Web Vitals

"Run PageSpeed" is not a checklist item, it is a vibe. Give yourself real targets and test the pages that matter on a throttled mobile connection, because that is what most of the client's traffic is on.

• -Aim for the green thresholds: LCP under 2.5s, INP under 200ms, CLS under 0.1, measured on mobile, not just the flattering desktop score.
• -Compress and convert images to modern formats (WebP or AVIF), and serve them at display size. The hero image is almost always the LCP element.
• -Reserve space for images, embeds, and ads so nothing shifts as the page loads. That is your CLS.
• -Defer or remove render-blocking scripts, and audit third-party tags. One heavy chat widget or tracking script can wreck INP on its own.
• -Make sure pages are served over HTTP/2 or better from a CDN, with sensible cache headers on static assets.
• -Lazy-load below-the-fold media, but never lazy-load the LCP image.

This is the part that quietly justifies how you host. A site that ships as static HTML to a CDN passes these by default, with no caching stack to babysit per client. That is the model behind Seedly Sites hosting: static output to the edge, green on Core Web Vitals out of the box, the same on every site you launch.

Forms, integrations, and analytics

A contact form that looks like it works and silently drops leads is the worst bug an agency can ship, because the client loses money and never sees an error. Test the whole path, not just the submit button turning green.

• -Submit every form for real and confirm the notification email actually lands in the client's inbox, not their spam folder.
• -Check the success state and the autoresponder, and that submissions reach the CRM, spreadsheet, or inbox they are supposed to.
• -Add spam protection (a honeypot or a captcha) so the client is not buried in junk on day two.
• -Test every integration end to end: payment checkout in live mode (not test mode), booking widgets, newsletter signup, e-commerce flows.
• -Confirm analytics is installed and recording on the production domain, with the staging or dev property removed.
• -Set up the conversion events that matter (form submit, call click, purchase) so the client can see leads, not just pageviews.
• -Remove any test pixels, debug tags, or dev tracking IDs that came over from staging.

First-party analytics the client can actually read beats a wall of vanity metrics. See how we think about that in Seedly Sites analytics.

Accessibility

Accessibility is not a nice-to-have you bolt on for compliance theater. It is usability for real people, it overlaps heavily with SEO, and in a lot of markets it is a legal exposure you do not want to hand a client. Most launch checklists reduce it to "check accessibility," which helps nobody. Here is the real pass.

• -Check color contrast against WCAG AA: at least 4.5:1 for body text, 3:1 for large text. Low-contrast gray-on-white is the most common failure.
• -Navigate the whole site with only the keyboard. Every link, button, and form field must be reachable and operable, with a visible focus state.
• -Give every form field a real, associated label, not just placeholder text that vanishes when you type.
• -Add alt text to informative images and empty alt to decorative ones, so screen readers do not read out filenames.
• -Use semantic HTML and ARIA only where it is needed. A real <button> beats a clickable div every time.
• -Make sure video has captions and nothing important is conveyed by color alone.

Security and SSL

Most of the security advice in launch checklists is really WordPress-plugin advice: install Wordfence, disable file editing, limit login attempts. That is a tell that the platform itself is the attack surface. The fewer moving parts you ship, the shorter this list gets.

• -Confirm SSL is installed and HTTPS is enforced site-wide, with HTTP redirecting to HTTPS and no mixed-content warnings.
• -Fix mixed content: hardcoded http:// image or script URLs will break the padlock on an otherwise secure page.
• -Lock down every admin and CMS account with a strong password and two-factor auth, and remove any shared or default logins.
• -Remove staging password protection and any "under construction" gate from the production site.
• -Set sensible security headers (HSTS, a content security policy where practical) at the edge.
• -Confirm automated backups are running and that you have actually tested a restore, not just trusted that the toggle is on.

Redirects and URL preservation (if you are migrating)

This is the unglamorous phase that decides whether the client keeps the rankings they paid years to earn, and it is the one the generic checklists wave at in a single line. If you are replacing an existing site, the old URLs are an asset the client paid years of SEO to earn. Lose them and you lose rankings, backlinks, and the client's patience.

• -Crawl the old site and export every live URL before you turn it off. You cannot redirect what you did not write down.
• -Pull the top pages from Search Console and Analytics so you know which URLs actually earn traffic and links, and protect those first.
• -Build a one-to-one redirect map: every old URL to its closest new equivalent, with 301 permanent redirects, not 302s.
• -Avoid redirect chains and loops. Old URL to new URL in one hop, never old to interim to final.
• -Preserve or update canonical tags and internal links to point at the new URLs, so you are not relying on redirects forever.
• -Keep the old sitemap reachable for a while so search engines discover the redirects faster.
• -Spot-check the redirects after launch with a crawler. A 404 on a page that used to rank is a slow leak you will not notice for weeks.

Doing this by hand across a whole portfolio is brutal, which is why the migration pipeline ports the existing site into the builder for you, so you start the rebuild from your real pages instead of a blank canvas. The redirect map and the URL preservation above are still yours to do, but you are doing that work against a site that is already standing, not a rebuild you have not begun.

Cross-device and cross-browser QA

Your site looks perfect because you built it on your machine, in your browser, at your screen size. Your client's customers are on a three-year-old Android in Safari's weird cousin. Test like them.

• -Check the real browsers: Chrome, Safari, Firefox, and Edge, on both Mac and Windows.
• -Check the real devices: a small phone, a large phone, a tablet, and a wide desktop. Watch for horizontal scroll and clipped headings at 390px wide.
• -Test iOS Safari specifically. It breaks things nothing else breaks, especially sticky headers and form inputs.
• -Click every link in the nav, footer, and body, and run a broken-link crawler to catch the ones you missed.
• -Confirm the 404 page is branded, helpful, and routes people back into the site instead of dead-ending them.
• -Check tap targets are big enough and nothing important hides under a fixed mobile header.

Legal and privacy

This is the client's liability, but you are the one who launched without it, so make it a gate. Get them to confirm in writing that the legal pages are theirs to publish.

• -Publish a privacy policy, terms of service, and any disclaimers the client's industry requires.
• -Add a cookie consent banner if you are running analytics or ad pixels in a region that requires one, and make sure it actually gates the tags.
• -Confirm the client owns or has licensed every image, font, and piece of copy on the site.
• -Make sure contact details, business registration, and any required accessibility statement are present where the law expects them.

The go-live cutover

Launch is a sequence, not a button. Run it in order, and tell the client when you start so a few minutes of DNS propagation does not turn into a panicked phone call.

• -Take a final backup of both the old and the new site immediately before the switch.
• -Point the DNS at the new site. Because you lowered the TTL last week, this propagates fast.
• -Confirm SSL is valid on the production domain the moment it goes live, not just on staging.
• -Re-run the critical path on the live domain: homepage loads, navigation works, the main CTA and contact form submit and deliver.
• -Verify the redirects fire on the live domain by hitting a handful of old URLs directly.
• -Confirm the live site is indexable and resubmit the sitemap in Search Console.
• -Check analytics is recording real traffic on the production domain.

The first 48 hours after launch

The launch is not done when DNS resolves. It is done when you have watched it behave for a couple of days. This is also the window where a quick fix is cheap and a missed problem gets expensive.

• -Watch analytics for the traffic shape you expect and for any pages getting unusual error rates.
• -Re-crawl for broken links and 404s once the site has settled and search engines have started moving.
• -Watch Search Console for coverage and indexing errors as Google recrawls the new URLs.
• -Confirm at least one real lead has flowed all the way through the form to the client's inbox.
• -Hand the client a short doc: what changed, where to log in, who to call, and what their care plan covers.
• -Schedule the first content or maintenance touch so the relationship does not end at launch.

A launch checklist is not bureaucracy. It is the difference between a site you are proud of and a 3am call about a contact form that has been dropping leads for a week.

Rushed launch vs checklist launch

The gap between these two is rarely talent. It is whether someone ran the list. Here is what each one looks like a month later.

Make it repeatable

The real unlock for an agency is not running this checklist once. It is running the same one on every launch so quality stops depending on who was on the project or how tired they were. Turn this into a template, assign owners to each phase, and make the gates non-negotiable: no launch without sign-off, no migration without a redirect map, no go-live with noindex on.

It also gets easier the fewer moving parts you ship. A lot of this list exists to babysit databases, plugins, and caching stacks. When every client site outputs as static HTML on infrastructure you own, the security treadmill shrinks and the performance checks pass by default, so the list gets shorter and your launches get boring. Boring launches are the goal. If you want to see that model, try Seedly Sites live.