The Complete Website Launch Checklist for Agencies

Nobody notices a good launch. The site appears on the domain, the forms deliver leads, the old URLs land where they should, and the client assumes that is simply what happens. What they never see is the difference between that and the other kind of launch: rankings that vanish because redirects were skipped, a contact form that silently dropped three weeks of leads, analytics that counted nothing during the most important month of the project.

Launches fail quietly, which is exactly why they need a checklist instead of confidence. This is the sequence we run on every site we put into production, organized the way the work actually happens: QA before anything moves, then the cutover, then verification on the live domain, then close-out. Steal it, adapt it, and run it every time, including the launches that feel too small to need it. Especially those.

What skipping this actually costs

It is worth being concrete about the stakes, because every item below exists to prevent a specific, recurring disaster. A redesign launched without its redirect map can shed a large share of its organic traffic in weeks, and recovering those rankings takes months if it happens at all. A form with a broken endpoint costs the client every lead until someone happens to notice, and nobody notices, because a broken form produces silence, not errors. Analytics misconfigured at launch means the baseline month, the one you will be asked about forever after, simply does not exist. And a DNS cutover attempted without registrar access at hand turns a twenty-minute switch into a week of emails with whoever built the last site.

None of these failures announce themselves at launch. The site looks live, everyone celebrates, and the damage compounds quietly. That is the entire case for running the same boring list every time.

Before you schedule anything

Three preconditions, all boring, all regularly skipped:

• Written approval on the final preview, from the agency and, if your process includes them, the client. "Looks good on the call" is not written approval.
• Access to the domain's DNS: registrar credentials, or a named person who can change records while you wait. Discovering at cutover time that the domain is controlled by an ex-employee's GoDaddy account is a rite of passage you only need once.
• A launch window with a human on call. Never launch on a Friday evening. Someone must be reachable for the first hours after cutover, because that is when surprises surface.

Phase 1: Pre-launch QA, on the final preview build

Content and placeholder sweep

• Search the codebase and CMS for placeholder artifacts: lorem ipsum, template business names, example.com links, demo API keys, test phone numbers. Placeholders survive to production far more often than anyone admits.
• Verify the facts a client notices instantly: business name spelling, phone number, address, hours, service names, prices if listed. Check them against the client's own information, not against earlier drafts.
• Proofread every page once, out loud if you can. Fluent copy that says slightly the wrong thing is the signature failure of AI-drafted content.

Function

• Click every link: navigation, footer, in-page buttons, and text links, on every page. Broken internal links are a two-minute fix before launch and an embarrassment after.
• Submit every form with a labeled test entry. Confirm the submission actually arrives where leads are supposed to land, the success state renders, and any notification emails fire. Then delete the test data.
• Confirm the site builds cleanly with no errors or console noise, and that there are no references to staging URLs in the built output.

Mobile

• Do a full pass on a real phone or at 375px width, on every page. Most of your client's customers will only ever see this version.
• Check the specifics that break: sticky headers, menus, tables, embedded maps, and forms. Confirm every phone number is a tappable tel: link.

SEO and metadata

• Every page has a unique title (under about 60 characters) and meta description (under about 160). Check the built HTML, not just the CMS fields.
• The canonical URL configuration points at the production domain, not the staging URL. Canonicals and sitemap URLs usually derive from one site setting; if it still says staging, your sitemap will too.
• Favicon and social share image load; run one page through a social card preview tool.
• Heading structure is sane: one h1 per page, sections in h2s. Screen readers and search engines both read it.

Performance

• Run Lighthouse or an equivalent on the homepage and one heavy inner page. On a modern static build, performance in the 90s and accessibility in the high 90s are reasonable expectations; investigate anything far below, and check images first, because it is almost always images.

Phase 2: The redirect map (redesigns and migrations)

If this launch replaces an existing site, the redirect map is the highest-stakes item on this page. Every URL that exists today and will not exist tomorrow must 301 to its closest equivalent, or the site's accumulated rankings and every old link on the internet break at once. This is how redesigns "mysteriously" lose their traffic.

1. Inventory the old site's URLs: crawl it, export from the CMS, and cross-check against Search Console's indexed pages so nothing invisible is missed.
2. Map every old URL to its new home. Pages that are intentionally being dropped redirect to the nearest parent page, not to the homepage. Mass-redirecting everything to home is treated as a soft 404 and wastes the link equity you are trying to preserve.
3. Implement the map as server-level 301s at the hosting layer, not as meta refreshes or JavaScript.
4. Keep the map file; you will spot-check it after cutover and keep the redirects in place long-term.

Phase 3: Cutover

1. Deploy to production hosting first and confirm the site serves correctly on the hosting provider's temporary URL. DNS should point at something you have already verified.
2. If you control the DNS zone in advance, lower the TTL on the relevant records a day early so the switch propagates in minutes instead of hours.
3. Point the domain: apex and www both, with one chosen as canonical and the other 301-redirecting to it. Two hostnames serving the same content without a redirect is a duplicate-content problem you inflict on yourself.
4. Confirm TLS certificates issue for both hostnames and that HTTP redirects to HTTPS. Half-secured launches produce browser warnings that clients screenshot.
5. A note on trust: point the client's domain at your hosting; do not take ownership of it. Clients keep their domain and their content, always. It is their business, and being able to say so plainly is worth more than any lock-in.

Phase 4: Go-live smoke test, on the production domain

Propagation done, certificate green. Now verify everything again, live, because the production environment is the only one that counts:

• Load every page on the live domain. Watch the network tab for mixed-content warnings and 404 assets, the classic symptoms of hardcoded staging URLs.
• Submit a labeled test through the live form and confirm the lead arrives. Then remove it. A form that worked on preview and fails on production, usually over an endpoint or CORS detail, is the most expensive silent failure on this list.
• Confirm analytics registers your live visit in real time, and that form submissions and phone clicks fire as events. If conversions are not being counted from day one, the "how is the new site doing" conversation becomes a shrug.
• Spot-check three to five redirects from the map, including one dropped page redirecting to its parent.

Phase 5: Search Console, sitemap, monitoring

• Add and verify the domain in Google Search Console, via DNS record or an existing verification method.
• Submit the sitemap URL and confirm it is fetched without errors.
• For redesigns, request indexing on the homepage and the top money pages so the new versions get picked up quickly.
• Add the site to uptime monitoring. If the site goes down at 2am, the monitor should know before the client does.
• Calendar a check for a few days out: crawl errors and 404s in Search Console will surface any redirect you missed.

Analytics continuity, for redesigns

If the old site had analytics history, preserve the thread. Keep the same analytics property rather than starting a fresh one, so year-over-year comparisons survive the redesign. Carry over any ad platform pixels and conversion definitions, and re-verify that the events those campaigns optimize against still fire on the new site. An ad campaign pointed at a redesigned site with renamed conversion events will keep spending while learning from nothing. Where call tracking exists, confirm the tracking numbers survived the rebuild and still route correctly; a swapped number that quietly went to voicemail is a story every experienced agency can tell.

Phase 6: Close-out and handoff

• Write the launch record where your team tracks work: live URL, launch time, redirect count, GSC status, and anything deferred. Future-you, debugging something six months from now, will thank present-you.
• Hand off to the client: portal or dashboard access, any credentials they own, and a short walkthrough of how to submit change requests. A client who knows how to ask for changes is a client who renews.
• Start the care plan and the reporting cadence immediately. Launch is not the end of the project; it is the start of the retention engine.

The first week after launch

A launch is not finished when the confetti settles; it is finished when a week of live data says so. Three short check-ins close the loop:

• Day one or two: skim the analytics. Traffic arriving, pages registering, conversions counting. Check hosting logs or monitoring for any 404 spikes that reveal a missed redirect.
• Mid-week: Search Console. Confirm the sitemap processed, watch coverage begin to reflect the new URLs, and clear any crawl errors it surfaces. For redesigns, watch that impressions hold rather than slide.
• End of week: send the client a short launch report: the site is live, forms are delivering, here is the early traffic, here is what happens next month. That one unprompted email does more for retention than the launch itself, because it tells the client someone is still watching.

The condensed checklist

The one-screen version, for the day of:

1. Approval in writing, DNS access confirmed, launch window set.
2. Placeholder sweep clean, facts verified against the client.
3. Every link clicked, every form tested and cleaned up.
4. Full mobile pass on a real phone.
5. Unique titles and descriptions, production canonical, favicon, share image.
6. Lighthouse acceptable on home and one inner page.
7. Redirect map complete and implemented (redesigns).
8. Production deploy verified on the hosting URL before DNS.
9. DNS pointed, apex and www canonicalized, TLS green, HTTPS forced.
10. Live pages loaded, live form tested, analytics counting, redirects spot-checked.
11. GSC verified, sitemap submitted, indexing requested, monitoring on.
12. Launch record written, client handed off, care plan started.

This checklist is one of the operational skills our fulfillment team runs on every managed launch, and the same sequence ships in the free resources library as a procedure your own AI agent can follow. If you would rather never think about a launch again, website management exists for exactly that.