Website Launch Checklist for Agencies: Before, During and After

A website launch checklist is the list of checks you run before, during and after a site goes live, so nothing breaks on launch day. Most checklists online are written for one person launching their own site. This one is written for agencies launching a site for a client, where the risks are different: someone else owns the domain, someone else signs off, and your name is on the result.

The list is split into seven phases. Copy it into your project tool, assign an owner to each line, and do not launch until every line has a name and a tick next to it.

Why agencies need their own launch checklist

When you launch your own site, a mistake costs you an evening. When you launch a client site, a mistake can cost the client leads, rankings or sales, and it costs you trust. The common failures are rarely about design. They are about access, timing and handover:

• nobody has the login for the domain registrar on launch morning;
• the staging site was set to “noindex” and the setting went live with it;
• old URLs were never redirected, so traffic from Google lands on 404 pages;
• the contact form works on staging but its emails never arrive on the live server;
• the client signs off verbally, then asks for changes a week after launch and calls them bugs.

Each phase below closes one of these gaps.

Phase 1: Access and ownership (two weeks before launch)

Collect and test every login well before launch day. Testing matters: a password in a spreadsheet is not the same as a working login.

• Domain registrar login, tested. Confirm who the registered owner is. It should be the client, not you or a former freelancer.
• DNS host login, if DNS is managed somewhere other than the registrar (for example Cloudflare).
• Hosting account for the live server, with SSH or SFTP access if you need it.
• Email provider details (Google Workspace, Microsoft 365 or other), so you do not break the client’s mail when you touch DNS.
• Accounts for analytics, Search Console, tag manager, payment gateway and any form or CRM tools the site connects to.
• A written list of who gets admin access after launch, and who loses it.

Store everything in a shared password manager, not in email threads. If the client wants to keep ownership of every account, add your team as a user instead of using their personal login.

Phase 2: Content and design sign-off

Get written approval before you schedule the launch. This protects both sides and turns “can we just change” requests into a clear phase two list.

• No placeholder text, dummy images or test products left anywhere. Search the database or CMS for “lorem” and “test”.
• Every page proofread by the client, including legal pages, footer text and thank-you pages.
• Images compressed, correctly sized and with alt text that describes them.
• Brand colours, fonts and components match the agreed website style guide.
• Favicon, social sharing image and page titles set for the main pages.
• A short sign-off email from the client that names the pages approved and the launch date.

Phase 3: Technical QA on staging

Run this on the staging site, then run the key items again on the live site after launch.

Functionality

• Submit every form and confirm the email arrives in the right inbox, not in spam.
• Test checkout end to end if the site sells anything, then switch the payment gateway from test mode to live mode at launch.
• Click through the main menu, footer and every call to action. Good website navigation means nothing if a link points to staging.
• Check the 404 page and search results page.

Devices and browsers

• Test on a real iPhone and a real Android phone, not only in browser dev tools.
• Test the latest versions of Chrome, Safari, Firefox and Edge.
• Check tap targets, menus and forms on small screens.

Speed and accessibility

• Run PageSpeed Insights on the home page and one key inner page. Google treats a Largest Contentful Paint up to 2.5 seconds, Interaction to Next Paint up to 200 ms and Cumulative Layout Shift up to 0.1 as “good”.
• Check colour contrast, heading order, keyboard navigation and form labels.
• Remove unused plugins and scripts. For WordPress builds, run through a WordPress security audit before launch, not after.

Phase 4: SEO and redirects

This is where client sites lose the most value. If you are replacing an old site, the redirect map is the single most important document in the project.

• Export every URL of the old site, plus its top pages from analytics and Search Console.
• Map each old URL to the closest new page and set 301 redirects. Avoid chains where one redirect points to another.
• Make sure the staging “hide from search engines” setting is switched off on live. In WordPress this is the “Discourage search engines from indexing this site” box under Settings, Reading.
• Check that robots.txt does not block the whole site.
• Unique title and meta description on every important page, one H1 per page.
• XML sitemap generated and ready to submit.
• Canonical tags point to the live domain, not staging.

Our guide to website redesign covers how to keep rankings during a rebuild in more detail.

Phase 5: The day before launch

• Lower the DNS TTL on the records you will change (for example to 300 seconds). Do this at least a day ahead, so the old, longer TTL has expired by launch time and the switch spreads quickly.
• Take a full backup of the old site: files and database. Store it somewhere other than the server you are about to change.
• Agree a rollback rule in writing: what counts as a failure, how long you wait, and who makes the call to switch back.
• Pick the launch window. Choose a weekday morning when your team and the client are both available. Avoid Fridays and the day before a holiday.
• Tell the client what they will see during the switch, and that some visitors may see the old site for a short time while DNS updates.

Phase 6: Launch day

1. Put the old site in maintenance mode if content could change during the move.
2. Move files and database to the live server.
3. Replace every staging URL in the database with the live URL. In WordPress, wp search-replace in WP-CLI handles serialised data safely.
4. Update DNS records and confirm the SSL certificate is active, with HTTP redirecting to HTTPS.
5. Switch payment gateways, form endpoints and API keys from test to live.
6. Turn on caching and confirm the site is not serving a cached staging page.
7. Run the key Phase 3 checks again on the live domain: forms, checkout, menus and mobile.
8. Test a sample of old URLs and confirm each one redirects to the right page.
9. Submit the XML sitemap in Google Search Console and check that analytics records a visit.

Phase 7: After launch (the first 30 days)

Most checklists stop at “go live”. The first month is when slow problems show up: pages dropping out of the index, forms that fail once a day, an SSL renewal that did not run.

• Day 1: set up uptime monitoring and check server error logs.
• Day 2 to 3: run a full crawl of the live site for broken links, missing titles and redirect chains.
• Week 1: review Search Console for crawl errors and 404s, and add redirects for anything missed.
• Week 2: compare traffic and form submissions with the old site’s baseline.
• Day 30: run a short review with the client, close the launch ticket and agree the phase two list.

The client handover pack

A clean handover is what makes a client come back for the next project. Send it in one place, not spread across emails:

• a list of every account, who owns it and who has access;
• a short guide or video on editing pages, posts and forms;
• the redirect map and the final sitemap;
• a backup of the launched site;
• the support terms: what is covered, response times and how to request changes.

Who owns each part of the launch

Launches go wrong when everyone assumes someone else checked a line. A simple split helps, whether the build was done in-house, by freelancers or by a white label partner:

Task	Agency (account lead)	Build team (in-house or partner)	Client
Logins and account ownership	Collects and tests	Uses	Owns and provides
Content and design sign-off	Runs the review	Fixes issues	Approves in writing
Technical QA and speed	Spot checks	Runs the full list	Tests key forms
Redirect map	Approves	Builds and tests	Confirms key pages
DNS switch and go-live	Schedules	Executes	Is available
Rollback decision	Makes the call	Advises	Is informed
30-day monitoring	Reports to client	Monitors and fixes	Reports issues

If you outsource web development, put this table in the brief so the partner knows exactly which lines are theirs.

From the studio: we keep the launch checklist inside the project from day one, not as a document opened the night before. Each line gets an owner when the project starts, and the access items in Phase 1 are closed before development is finished. When the final week arrives, the only open lines are the ones that can only happen on launch day.

For more on running projects this way, read our notes on the web design process, the most common web design mistakes, and how white label WordPress development handles handover between partner, agency and client.

Frequently asked questions

What should be on a website launch checklist?

At minimum: working logins, approved content, tested forms and checkout, mobile and browser checks, SEO settings, redirects, a backup and post-launch monitoring. For client sites, add written sign-off, a rollback plan and a handover pack.

How long does DNS take to update after launch?

It depends on the TTL set on your DNS records. If you lower the TTL a day before launch, most visitors usually see the new site within minutes to a few hours; with a long TTL it can take up to a day or two.

Should you launch a website on a Friday?

It is better not to. If something breaks, you want your team and the client available the next day, so a Tuesday to Thursday morning is a safer choice.

What should an agency hand over to the client after launch?

A list of accounts and owners, editing instructions, the redirect map, a backup of the launched site and clear support terms. Send it in one document so nothing gets lost.

Should I keep the old website after launch?

Keep a full backup of the old files and database for at least a few months. You may need an old page, image or URL later, and it lets you roll back if something goes badly wrong.

---

Need a team to build and launch client sites?

Inkyy is a white label design and development team for agencies. We build WordPress, Webflow and custom sites under your brand, run QA and launch checks, and hand over clean files. See our web development services and white label partnership, or book a call to talk about your next launch.