Launch day is the worst possible time to discover that your contact form goes nowhere, your staging site is still blocking Google, or half your old URLs return a 404. The good news: almost every launch disaster is preventable with a structured pass through the site the day before you flip the switch.
This website launch checklist is written as a sequential audit. Start at item 1, work down to item 21, and you will have covered hosting, SSL, redirects, analytics, mobile testing, broken links, metadata, alt text, forms and legal pages. Most small business sites (5 to 20 pages) can be fully audited in three to four hours.
How to use this checklist
Do not jump around. The order matters, because fixing DNS after you have already tested forms means testing forms again. Block out an afternoon, open the site on a laptop and a phone side by side, and work in these four phases:
| Phase | Items | Time | Consequence if skipped |
|---|---|---|---|
| 1. Technical foundations | 1 to 8 | 60 to 90 min | Site invisible to Google, security warnings, lost rankings |
| 2. Content and on-page | 9 to 15 | 60 min | Poor click-through, placeholder text in public, legal exposure |
| 3. Functionality testing | 16 to 20 | 45 to 60 min | Lost leads, broken checkout, no tracking data |
| 4. Go live and monitor | 21 | 30 min plus 48 h watch | Problems discovered by customers instead of by you |
Rule of thumb: never launch on a Friday afternoon. Tuesday to Thursday morning gives you and your host a full working day to fix anything unexpected.
Phase 1: Technical foundations (items 1 to 8)
1. Confirm hosting, credentials and a full backup
Before anything else, make sure you actually control the assets. Collect and store in a password manager:
- Domain registrar login and DNS panel access
- Hosting control panel, SFTP and database credentials
- CMS admin account (with an admin account in the client’s name, not just the agency’s)
- Email provider, analytics and any third party integrations
Then take a full backup of both the old site and the new one, files and database, and download it locally. A backup that only lives on the same server is not a backup. Much the same conclusion turns up on wix.com.
2. Check DNS, www versus non-www, and lower your TTL
Decide once whether the canonical version of your site is https://example.com or https://www.example.com. Every other variant must redirect to it in a single hop. There are four combinations to test manually in the browser bar:
http://example.comhttp://www.example.comhttps://example.comhttps://www.example.com
All four should end on the same final URL. If you are moving hosts, drop your DNS TTL to 300 seconds a day or two before launch so propagation is fast, then raise it again afterwards.
3. Install SSL and force HTTPS everywhere
An SSL certificate is not optional in 2026. Browsers flag anything else as not secure and visitors bounce immediately. Check:
- Certificate is valid, covers both www and root, and auto renews
- A site-wide rule forces HTTP to HTTPS with a 301 redirect
- No mixed content warnings: open the browser console and look for images, fonts, scripts or embeds still loading over http
- Internal links, canonical tags and the sitemap all use the https version
4. Build and test the 301 redirect map
This is the single most damaging item to skip on a redesign. If your URL structure changed, every old address needs a 301 redirect to its closest equivalent on the new site.
- Export the old site’s URLs from Google Search Console, your analytics and a crawler.
- Map each one to a new URL in a simple two column spreadsheet.
- Point deleted pages to the most relevant parent page, not blindly to the homepage.
- Avoid redirect chains: old URL should reach the destination in one hop.
- After launch, re-crawl the old URL list and confirm every row returns a 200 at the end of the chain.
5. Remove every staging block
The classic launch failure. Search your new site for anything that was hiding it during development:
- noindex meta tags or the CMS setting that discourages search engines
Disallow: /in robots.txt- HTTP password protection or a coming soon plugin
- Staging subdomain still publicly crawlable (it should be blocked or taken offline so it does not compete with the live site)
Check the live page source for <meta name='robots' content='noindex'> on the homepage and at least three inner pages.
6. Publish the XML sitemap and a sane robots.txt
- Sitemap exists at a predictable URL such as
/sitemap_index.xml - It contains only canonical, indexable, https URLs and no staging domains
- robots.txt references the sitemap and does not block CSS or JS
- Submit the sitemap in Google Search Console immediately after go live
7. Favicon, touch icons and social preview image
Small details that make a site look finished. Confirm:
- Favicon appears in the browser tab and in a bookmark, at 32×32 and 16×16
- Apple touch icon (180×180) shows when the site is saved to a phone home screen
- Open Graph title, description and image are set so links look right when shared on social or messaging apps (1200×630 is the safe size)
- No default CMS logo left in place
8. Custom 404 page and site search
Type a nonsense URL such as example.com/asdf123. You should get a branded 404 page that returns a real 404 status code and offers a way back: navigation, search box, links to key pages and contact details. If you have site search, run three real queries and check the results are useful.
Phase 2: Content and on-page checks (items 9 to 15)
9. Unique meta titles and meta descriptions on every page
Open your crawler export or your SEO plugin overview and confirm there are zero duplicates and zero blanks. Working guidelines:
| Element | Target length | Must include |
|---|---|---|
| Meta title | 50 to 60 characters | Primary keyword near the front, brand at the end |
| Meta description | 140 to 160 characters | Benefit plus a reason to click, city name for local pages |
| URL slug | 3 to 5 words | Lowercase, hyphens, no dates or ID numbers |
10. One H1 per page and a logical heading structure
Each page needs a single H1 that describes the page, followed by H2s and H3s in order. Do not use headings purely to make text bigger, and do not skip from H2 to H4. Screen readers and search engines both use this outline.
11. Proofread and hunt down placeholder content
Read every page out loud or paste it into a spell checker. Specifically search the whole site for:
- Lorem ipsum, “insert text here”, TBC, XXX
- Demo content from the theme (fake team members, sample blog posts, dummy testimonials)
- Old company name, old phone number, outdated prices or opening hours
- Stock photos that were never swapped for the client’s own images
- Dates and year references that will look stale in a few months
12. Image alt text, file names and compression
Every meaningful image needs descriptive alt text. Decorative images should have empty alt attributes (alt='') so screen readers skip them. While you are in the media library:
- Rename files before upload:
brick-oven-pizza-antwerp.jpgbeatsIMG_4821.jpg - Serve WebP or AVIF where supported
- No image wider than it needs to be (a 4000px hero on a 1600px container wastes bandwidth)
- Width and height attributes set to prevent layout shift
- Lazy loading on below-the-fold images, but not on the hero image
13. Broken link scan, internal and external
Run a crawl of the full site and filter for anything that is not a 200 response. Fix or remove:
- Internal links pointing to staging URLs or old domains
- 404s from menu items, footer links and buttons
- Dead external links to partners, suppliers or news articles
- Broken image sources and missing PDFs or downloads
- Empty links (
href='#') left over from the design phase
14. Contact details consistent everywhere
Business name, address and phone number must match exactly across the footer, contact page, Google Business Profile and any structured data. Test the click-to-call link on a phone and the email link in a mail client. Check the map embed drops the pin on the right building.
15. Legal pages published and linked
Not glamorous, but a real risk if missed. At minimum, publish and link from the footer:
- Privacy policy that names your actual tools (analytics, forms, email marketing, payment processor) and explains data retention
- Cookie notice with genuine consent controls if you serve visitors in the EU or UK, including the ability to refuse as easily as to accept
- Terms and conditions, plus returns and delivery policy for ecommerce
- Legal or company information: registered name, company number, VAT number and registered address where your jurisdiction requires it
- Accessibility statement with a contact route for reporting barriers, which is now expected practice for many businesses selling in Europe
Phase 3: Functionality testing (items 16 to 20)
16. Mobile and cross-browser testing on real devices
Responsive preview in the browser is a starting point, not a test. Load the site on at least one real phone and one tablet, then check the main browsers.
| What to test | Pass criteria |
|---|---|
| Mobile navigation | Menu opens, closes, and every submenu item is reachable with a thumb |
| Tap targets | Buttons at least 44px, no accidental double taps |
| Horizontal scroll | None at 320px width |
| Text readability | 16px minimum body text, sufficient colour contrast |
| Browsers | Chrome, Safari, Firefox and Edge, plus iOS Safari and Android Chrome |
| Keyboard only | Tab through the page, visible focus outline, no keyboard traps |
17. Test every form end to end
Submit each form yourself, as a real visitor would, from a phone. For each one confirm:
- Validation messages are clear when a required field is empty
- The success message or thank you page actually appears
- The notification email arrives at the right inbox, not the developer’s
- It is not landing in spam: check SPF, DKIM and DMARC records, and send transactional mail through a proper SMTP service rather than the web server
- The autoresponder to the visitor is sent, and the sender name is correct
- Submissions are stored in the CMS or CRM as a backup
- Spam protection is active but not blocking real people
- File uploads work and respect the size limit
18. Run a real transaction or booking
If you sell or take appointments, complete a full purchase in live mode with a real card, then refund it. Check the confirmation email, the invoice, tax and shipping calculations, stock deduction, and what happens when a payment is declined. Test one guest checkout and one registered account checkout.
19. Speed and Core Web Vitals
Run the homepage, one service page and one blog post through PageSpeed Insights and look at mobile scores, not desktop. Sensible pre-launch targets:
- LCP under 2.5 seconds
- INP under 200 milliseconds
- CLS under 0.1
- Total page weight under roughly 2 MB where possible
Quick wins if you are short of time: compress the hero image, enable caching and a CDN, remove unused plugins and fonts, defer non-critical JavaScript, and cut the number of third party scripts.
20. Analytics, Search Console and conversion tracking
A launch without measurement means you cannot prove anything worked. Before go live:
- Analytics tag fires on every page, including the thank you page, and is installed only once (double tagging inflates traffic)
- Key events configured: form submit, phone tap, email click, purchase, quote request
- Consent mode wired to your cookie banner so tracking respects refusals
- Internal traffic filtered out by IP
- Search Console property verified for the correct domain, with the sitemap submitted
- Any ad platform pixels tested with the platform’s debug tool
- Uptime monitoring switched on with alerts to a phone, not just an inbox
Phase 4: Go live and monitor (item 21)
21. Launch, verify, then watch for 48 hours
Push the site live, then run this short verification pass straight away:
- Load the homepage in an incognito window on a mobile connection
- Re-check that noindex is gone and robots.txt is correct on the live domain
- Test the four domain variants again now that DNS has moved
- Submit the homepage and sitemap for indexing in Search Console
- Spot check 10 redirects from your old URL list
- Submit one live form and confirm the email lands
- Update the Google Business Profile link, social profiles and email signatures
Over the following 48 hours, keep an eye on Search Console coverage errors, 404 reports in your server logs or analytics, and real-time traffic. Week one is also the moment to publish your launch announcement: an email to your list, a social post with a short before-and-after, and a note to existing clients.
The one-page version of the website launch checklist
| # | Check | Priority |
|---|---|---|
| 1 | Credentials collected and full backup downloaded | Critical |
| 2 | DNS set, www versus non-www decided, TTL lowered | Critical |
| 3 | SSL active, HTTPS forced, no mixed content | Critical |
| 4 | 301 redirect map built and tested | Critical |
| 5 | noindex, robots block and password protection removed | Critical |
| 6 | XML sitemap and robots.txt live and clean | High |
| 7 | Favicon, touch icon and social preview image | Medium |
| 8 | Custom 404 page and working site search | Medium |
| 9 | Unique meta titles and descriptions | High |
| 10 | One H1 per page, clean heading order | High |
| 11 | Proofread, no placeholder or demo content | Critical |
| 12 | Alt text, file names and compressed images | High |
| 13 | Broken link scan complete | High |
| 14 | Contact details consistent site wide | High |
| 15 | Privacy, cookies, terms and accessibility pages live | Critical |
| 16 | Mobile, browser and keyboard testing done | Critical |
| 17 | Every form submitted and email delivery confirmed | Critical |
| 18 | Test purchase or booking completed and refunded | Critical for ecommerce |
| 19 | Core Web Vitals checked on mobile | High |
| 20 | Analytics, events, consent and Search Console live | High |
| 21 | Post-launch verification and 48 hour monitoring | Critical |
Five mistakes we still see on live sites
- Forms that go to a dead mailbox. The developer’s address was used for testing and never changed. Weeks of enquiries vanish.
- No redirects after a redesign. Rankings that took years to build disappear within a month.
- Analytics installed twice. Traffic looks doubled, bounce rate looks impossibly good, and every later decision is based on bad data.
- Cookie banner that only says OK. No refuse option, no real consent, and tracking loading before any choice is made.
- Nobody owns the domain. The registrar account belongs to a former employee or an old agency, and renewal fails a year later.
Frequently asked questions
What should be included in a website launch checklist?
A complete checklist covers four areas: technical setup (hosting, DNS, SSL, redirects, sitemap, robots.txt, favicon, 404 page), content quality (meta titles and descriptions, headings, proofreading, alt text, internal links), functionality (mobile and browser testing, form and checkout testing, speed, analytics) and legal compliance (privacy policy, cookie consent, terms, accessibility statement). The 21 items above cover all four. There’s a good explainer over at elementor.com.
How long does it take to run a pre-launch audit?
For a brochure site of 5 to 20 pages, budget three to four hours for one person. An ecommerce site with hundreds of products needs a full day, mainly because of transaction testing and redirect mapping. Automated crawling tools cut the broken link and metadata checks down to minutes.
What are the 7 C’s of a website?
They are commonly listed as context, content, community, customisation, communication, connection and commerce. They describe the strategic experience of a site rather than launch mechanics, so treat them as a design framework and use a technical checklist like this one for go live. Website Launch Checklist for Business Owners tackles the same question from another angle.
Should I launch a new site all at once or in stages?
For most small business sites, a single clean switch is simpler and safer, provided your redirect map is complete. Phased launches make sense for large sites with complex functionality, where you can move one section at a time and monitor traffic between phases.
What should I check in the first week after launch?
Watch Search Console for coverage and indexing errors, monitor 404 reports and fix any missed redirects, confirm form submissions are arriving daily, check that analytics data looks plausible, and review page speed with real user data once enough visits have accumulated.
Do I still need a privacy policy if my site has no forms?
Almost certainly yes. If you use analytics, embedded videos, maps, fonts loaded from a third party or any advertising pixel, you are processing visitor data and need to disclose it. A site with no data collection at all is rare.
Ready to launch with confidence?
Working through this checklist yourself will catch the overwhelming majority of launch problems. If you would rather have someone else run the audit, fix what turns up and handle the switch itself, that is exactly what our team does every week. Get in touch with Branded Web Design for a pre-launch review of your site, or to have your next website built, tested and launched properly from the start.