The website launch checklist

A website launch has about 70 things that need to be true before you flip the switch, and three of them cause nearly every launch-day disaster. The site goes live with search engines still blocked. The old URLs have nowhere to go. Company email stops being delivered during the DNS change. Everything else on this list matters, but those three are the ones that turn a good week into a bad month.

This is written to be used, not read once. Copy the sections into a shared document, put a name and a date next to each line, and do not launch until every line has an owner who has actually looked at it. On a five-page site this is an afternoon. On a 200-page relaunch it is a week of someone’s time.

What are the three items that get missed most?

Mistake	What it looks like	How to catch it
noindex left on	Site looks perfect, gets zero organic traffic, panic sets in around week three	View source on the live home page and search for noindex. Then open yoursite.com/robots.txt and confirm it does not say Disallow: /
No redirect map	Old links from Google, Facebook, business directories, and email signatures all land on 404 pages	Export every URL from the old site before launch. Every one needs a destination
Broken company email	Staff stop receiving mail hours after cutover and nobody connects it to the website	Copy MX, SPF, DKIM, and DMARC records to the new DNS host before you change nameservers

The email one is the most damaging because the cause is invisible. Nobody thinks a new website could stop mail from reaching the front desk. It happens when someone points the domain’s nameservers at a new host and the new host’s blank DNS zone replaces the old records wholesale. Screenshot the entire old DNS zone before you touch it.

Content and proofing

• Read every page out loud once. Typos survive silent reading.
• Phone number correct and identical on every page, including the footer and the contact page.
• Address correct and formatted the same way it appears on your Google Business Profile.
• Business hours correct, including holiday notes if you have them.
• Every staff name and title spelled correctly and current.
• No placeholder text anywhere. Search the site for “Lorem”, “TBD”, “coming soon”, and “[insert”.
• All images are real, licensed, and relevant. No stock photo of a boardroom you have never been in.
• Image file names and alt text describe the image.
• PDFs and downloads open and are the current version.
• 404 page exists, matches the design, and offers links back to the main sections.

Design and responsive checks

• Home page, one service page, and the contact page checked on a real phone, not just a browser resize.
• Checked on iOS Safari and Android Chrome at minimum. They break differently.
• Checked at 1280px and at 1920px on desktop. Wide screens expose stretched layouts.
• No horizontal scroll on any page at 375px wide.
• Favicon set. A default globe icon in the browser tab looks unfinished.
• Social share image (Open Graph) set, and tested by pasting a link into a private message.
• Print stylesheet acceptable if people print your forms or schedules. Schools and clinics still do.

Functionality and forms

• Every form submitted as a real test, from a phone, on cell data.
• The notification email arrives at the right inbox and is not in spam.
• The confirmation message or thank-you page appears after submitting.
• Required fields, error states, and success states all behave.
• Spam protection active. A honeypot field or a rate limit stops most bots without a puzzle.
• Every navigation link and every button clicked once. A link checker catches the rest.
• Search works if you have it, including a query that returns nothing.
• Payment, donation, or booking flows tested end to end with a real transaction you then refund.
• Third-party embeds load - maps, calendars, donation widgets, scheduling tools.

SEO

• Unique title tag on every page, roughly 50 to 60 characters, most important words first.
• Unique meta description on every page, 120 to 155 characters.
• One H1 per page that matches what the page is about.
• noindex removed. Check the live site, not staging.
• robots.txt allows crawling and points to the sitemap.
• XML sitemap generated and reachable at its URL.
• Canonical tags point at the live URL, not the staging domain.
• Redirect map complete - every old URL maps to a new one, using 301s, not 302s.
• Redirects tested by hand on the ten highest-traffic old URLs.
• Google Search Console verified for the live domain, sitemap submitted.
• Analytics installed and confirmed recording a session from your own visit.
• Structured data added where it applies - organization, local business, FAQ.

Redirects deserve more attention than they usually get. If the site is moving platforms as well as designs, read our guide on moving a website without losing rankings before launch week, not during it. The related website redesign checklist covers the baseline exports you should have taken before any of this started.

Performance

• Images compressed and served in a modern format. Nothing on the page should be a 4MB photo.
• Images sized correctly, so a 400px-wide thumbnail is not a 2400px file scaled down.
• Largest Contentful Paint under 2.5 seconds on mobile, which is Google’s own threshold for good.
• Layout does not shift while loading. Reserve space for images and embeds.
• Unused plugins, fonts, and tracking scripts removed. Every third-party script costs you time.
• Caching and compression enabled at the host or CDN.

Slow sites lose people before they read a word, and mobile visitors on a spotty connection give up fastest. If a page is still sluggish after this list, our article on why your website is slow walks through the usual causes in order of how much they cost you.

Accessibility

• Every image has alt text, or empty alt if it is decorative.
• Text contrast meets 4.5 to 1 against its background for body copy.
• The whole site is usable with the Tab key alone, and focus is visible as it moves.
• Headings are in order - H1, then H2, then H3 - and are not used just to make text big.
• Form inputs have real labels, not just placeholder text.
• Video has captions.
• Automated scan run with a free tool, then a manual keyboard pass. Automated checks catch a minority of real problems.

The WebAIM Million report finds detectable accessibility failures on the large majority of home pages it tests every year, so assume yours has some. If you serve people with disabilities directly - a disability services provider, a clinic, a school - this section is not optional, and our accessibility guide for small organizations explains which fixes carry the most weight.

Security, SSL, and legal

• SSL certificate installed and auto-renewing. The padlock shows on every page.
• All http:// URLs forced to https://, with no mixed-content warnings.
• Admin passwords are unique and strong, and two-factor is on for every admin account.
• Old contributor and developer accounts removed.
• Software, theme, and plugins updated to current versions the day before launch, not the day of.
• Privacy policy published if you use forms, email signup, or analytics.
• Cookie notice if you use non-essential tracking and serve visitors who require one.
• Terms of service if you sell something online.
• Copyright year in the footer set to update automatically.

Email deliverability and DNS

This is the section to slow down on. Do it in this order.

• Screenshot or export the entire current DNS zone before making any change.
• Lower the TTL on the A and CNAME records to 300 seconds at least 48 hours before cutover.
• Recreate every existing record at the new DNS host first - MX, SPF, DKIM, DMARC, and any verification TXT records for Google Workspace, Microsoft 365, or your CRM.
• Confirm who controls the domain registrar and that you can log in. If you are unsure, our guide on whether you actually own your website explains how to check.
• Change the A record or nameservers.
• Send a test email to and from a company address within 15 minutes of cutover.
• Send a second test the next morning, once propagation has finished.
• Raise the TTL back to normal after 48 stable hours.

Backups and rollback

• Full backup of the old site, files and database, stored somewhere you control.
• Backup of the new site taken immediately after launch.
• Automatic backups scheduled going forward, with a tested restore.
• A written rollback plan - who does what, in what order, if the site has to come down.

What should the launch day itself look like?

Launch Tuesday, Wednesday, or Thursday morning. Not Friday afternoon, not the day before a holiday, not a week when the person who built it is traveling. Most problems appear in the first four hours, and you want everyone awake.

Time	Task
Day before	Final content freeze, backup taken, TTL already lowered
Launch hour	DNS change, SSL confirmed, noindex removed, email test sent
First hour after	Ten redirect spot-checks, every form submitted, analytics confirmed
Same afternoon	Sitemap submitted in Search Console, indexing requested for the top pages
Same day	Update the website link on your Google Business Profile, Facebook, and email signatures

What do you watch in the first 72 hours and the first 30 days?

For 72 hours, check daily. Form notifications arriving. Search Console for crawl errors and a spike in 404s. Analytics recording sessions. Email flowing both directions. Ask two people outside the organization to open the site and tell you what breaks.

For 30 days, check weekly. Search Console coverage and the 404 report, because Google takes weeks to recrawl a site of any size. A small dip in traffic during the first two or three weeks is normal on a large relaunch and usually recovers. Compare against your baseline at 30, 60, and 90 days rather than reacting in week one. If organic traffic still has not returned by day 60, our article on why a site is not showing up on Google covers the diagnosis in order.

Also update the things that live outside your site - your Google Business Profile link, directory listings, and any printed material with the old URL structure on it.

Do you need to pay someone to run this checklist?

Often, no. If your site is five to ten pages on Squarespace or Wix, you are keeping the same domain, and no URLs are changing, you can work through this entire list yourself in an afternoon. The platform handles SSL, sitemaps, and hosting. There is nothing here that requires a developer, and paying an agency $95 to $150 an hour to tick boxes you could tick is a waste of your money. I would rather you spend it on photography or on a month of content.

Bring in help when the launch has real risk attached. Hundreds of URLs to map, a platform migration, a custom application, an e-commerce catalog, or a domain whose DNS controls the email for 30 staff. Those are the launches where a mistake costs more than the help would have. That is also true of the ordinary ones - if you have already paid for the site, the launch checklist should be included in the project, not billed separately.

A note on who owns the list

Whoever built the site should hand you this checklist completed, with names and dates filled in. If a studio cannot produce a launch checklist when you ask for one, that tells you something before you sign. The questions worth asking before you hire include this one.

If you want a look at how we handle launches, our web design and development work covers the full sequence, and our pricing page lists what a project includes. If you have a launch coming up and want a second set of eyes on the redirect map or the DNS plan, get in touch and we will tell you honestly whether you need us.