The Website Launch Checklist for Agencies

The Website Launch Checklist for Agencies

A good website launch is boring. Someone changes a DNS record, the new site appears, everyone checks a few things and goes for lunch.

A bad one starts at 4.45pm on a Friday. The contact form is emailing a staging address, the old blog URLs all return 404s, and the client's search traffic is about to find that out. The site is still set to noindex, so Google has been politely told to ignore it.

None of those failures are hard to prevent. They're just easy to forget, and that's what a checklist is for.

Plan the Launch Before Launch Day

Most launch problems are decided a week or more before go-live.

Agree the window

Launch early in the week, in the morning, when your team and the client are both around to fix things. Avoid Fridays, the day before a client's big campaign, and any day when the one person who understands the hosting is on leave.

Name a launch owner, and someone on call for the following 24 hours. Agree who at the client can make a decision if something's wrong.

Map every old URL

If the URLs are changing, this is the most important job on the list. Google's site move guidance says to build your list of old URLs from sources such as sitemaps, server logs, analytics and Search Console, and then map each one to its new home.

Google is specific on a few points that are worth building into your process:

• Use server-side permanent redirects, such as 301 or 308.
• Point each old URL straight at its final destination, with no chains.
• Don't send lots of old URLs to an irrelevant page, such as the homepage.
• Keep redirects in place for as long as possible, and generally for at least a year.

The redirect map is often where a client's search traffic is won or lost, so give it an owner and check it.

Lower the DNS TTL

TTL controls how long resolvers can cache a DNS record. If it's set to a day, a mistake can take a day to undo. (Cloudflare's documentation explains how it works.) A day or two before launch, lower it to a few minutes, so that the change goes live quickly and you can reverse it quickly. Restore it once everything has settled.

Make sure you have a way back

Take a full backup of the old site and database, and test that you can actually restore from it. The UK's National Cyber Security Centre gives sensible guidance on backups for small organisations. Write the rollback plan in three lines: what triggers it, who decides, and the exact steps. You're unlikely to need it, but deciding this at the moment of panic is the worst time to do it.

The Checklist

On staging, before you switch

• ☐ Final content is in, including legal pages and the cookie notice
• ☐ Every form has been submitted, and each email arrives at the right address
• ☐ Payment or checkout has been tested in test mode, if there is one
• ☐ Page titles and descriptions are filled in
• ☐ Images are compressed and sized
• ☐ Site tested on real phones and in the main browsers
• ☐ 404 page exists and looks right
• ☐ Redirect map is loaded and tested on a sample of old URLs
• ☐ Analytics and tag manager are installed on the new site
• ☐ Client has signed off in writing

During the switch

• ☐ Backup taken today
• ☐ DNS records updated, and nothing else on the domain broken

That last part catches people out. The domain's DNS often holds more than the website. Check that MX records for email and any verification records survive the move. "The website launched and the client's email stopped" is a very bad afternoon.

Straight after go-live

• ☐ SSL certificate is valid, and HTTP redirects to HTTPS
• ☐ The www and non-www versions resolve to one address
• ☐ Noindex tags have been removed
• ☐ robots.txt isn't blocking the whole site
• ☐ Forms work on the live domain, not just on staging
• ☐ Analytics is receiving live data
• ☐ Monitoring and uptime alerts are on

Check the noindex item twice. Staging sites should be hidden from search engines, so developers set a noindex rule, and it's alarmingly easy to carry that across to production. The site looks perfect to everyone, and it silently disappears from Google.

The next day and the next week

• ☐ Submit the new sitemap in Search Console
• ☐ Look for crawl errors and unexpected 404s
• ☐ Check that conversions are being recorded
• ☐ Restore the DNS TTL
• ☐ Confirm that backups are running on the new hosting
• ☐ Review traffic against the old site

Google warns that moves take time, saying that for a medium-sized site it can take a few weeks or more for new URLs to replace old ones. Tell your client that up front. Rankings often wobble after a migration, and it's much better if they've heard this from you before they notice it for themselves.

What Goes Wrong Most Often

The Honest Trade-off

This list is built for a real migration. If you're launching a brand-new brochure site on a new domain, there's no redirect map to make and much less to lose, and you can drop a third of these steps.

A checklist also can't replace judgement. Large or complex migrations, such as moving a big e-commerce store or merging domains, need proper SEO planning from weeks earlier. Treat that as its own project, not as a line on this list.

And don't let the checklist grow forever. Each time something goes wrong, you'll want to add a line. Do it, but take out anything that's never once caught a problem. Long checklists get skimmed, which defeats their purpose. We explain why short ones work in how to write an SOP your team will actually use.

Make It Yours

Your stack changes the details. A Vercel launch doesn't look like a WordPress one. Generate a version with your own tools named, then add the mistakes you've personally lived through.

Build your launch checklist SOP, free →

The goal of launch day is for nothing interesting to happen. Every exciting launch story you've heard is a checklist item someone skipped.