Website Launch Checklist: 25 Things to Check Before Going Live
A website launch checklist is a structured list of checks you should run before making a new or redesigned website public. It covers SEO, accessibility, security, performance, and content quality - everything that affects whether your site works properly from day one.
I've seen too many launches go wrong because someone forgot to set up redirects, left placeholder text on the about page, or launched with zero security headers. These aren't rare edge cases. They're the things that get missed when the focus is on design and deadlines rather than the fundamentals.
This checklist covers 25 items across the areas that matter most. Not everything will apply to every site, but if you work through this before hitting publish, you'll avoid the problems that most launches ship with.
SEO Essentials (Items 1-6)
1. Title tags are unique and under 60 characters
Every page needs a unique title tag that includes the primary keyword and stays under 60 characters. Duplicate or missing title tags are one of the most common issues found in website audits - roughly 60% of sites have this problem.
2. Meta descriptions are written and under 155 characters
Meta descriptions don't directly affect rankings, but they affect click-through rates from search results. Write a benefit-led description for every key page. If you leave them blank, Google will auto-generate one - and it's rarely what you'd choose.
3. H1 tags are present on every page (one per page)
Each page should have exactly one H1 tag that clearly describes what the page is about. The H1 should include your primary keyword for that page. Multiple H1s or missing H1s confuse search engines about what the page is targeting.
4. robots.txt is configured correctly
Your robots.txt file tells search engines which pages to crawl and which to ignore. Before launch, verify it's not accidentally blocking your entire site (a surprisingly common mistake). Allow all public pages, block admin areas, API endpoints, and staging environments.
5. Sitemap.xml exists and is submitted
Generate a sitemap that includes all your public pages with proper priority values and last-modified dates. Submit it to Google Search Console. Without a sitemap, Google has to discover your pages through crawling alone, which is slower and less reliable.
6. Redirects are in place for any changed URLs
If you're relaunching or redesigning, every old URL that's changing needs a 301 redirect to its new location. Missing redirects mean broken links from external sites, lost link equity, and 404 errors for anyone who bookmarked the old pages. This is the single most common launch mistake I see.
Accessibility (Items 7-12)
7. All images have alt text
Every image needs descriptive alt text that explains what the image shows. This is the most common accessibility violation on the web and it's one of the easiest to fix. Decorative images should have empty alt attributes (alt=""), not missing ones.
8. Colour contrast meets WCAG AA standards
Text must have sufficient contrast against its background - a minimum ratio of 4.5:1 for normal text and 3:1 for large text. Low contrast makes text harder to read for everyone, not just people with visual impairments. Test your colour combinations before launch.
9. Forms have proper labels
Every form field needs an associated <label> element. Without labels, screen reader users can't tell what information a field is asking for. Placeholder text is not a substitute for labels - it disappears when the user starts typing.
10. Keyboard navigation works throughout
Tab through your entire site using only the keyboard. Can you reach every link, button, and form field? Can you see where the focus is? Are there any keyboard traps (elements you can tab into but not out of)? This is critical for users who can't use a mouse.
11. Heading hierarchy is logical
Headings should follow a logical order: H1, then H2s, then H3s. Don't skip levels (H1 to H3 without an H2) and don't use heading tags for visual styling. Screen readers use heading hierarchy to navigate pages, so a broken structure makes the page unusable for those users.
12. Language attribute is set
Your HTML element needs a lang attribute (e.g., lang="en" for English). Without it, screen readers don't know what language to use for pronunciation. This is a single line of code and it's missing on a huge number of websites.
Security (Items 13-17)
13. HTTPS is active and forced
Your site must load over HTTPS with a valid SSL certificate. Verify that HTTP requests redirect to HTTPS (not just that HTTPS works when you type it in). Check for mixed content warnings - any HTTP resources loaded on an HTTPS page will trigger browser warnings.
14. Security headers are configured
HTTPS is step one. Security headers are the rest. At a minimum, configure:
- Content-Security-Policy - prevents XSS attacks
- Strict-Transport-Security - forces HTTPS connections
- X-Content-Type-Options - prevents MIME sniffing
- X-Frame-Options - prevents clickjacking
- Referrer-Policy - controls what's sent in the Referrer header
15. Sensitive files are not publicly accessible
Check that .env files, database backups, admin panels, and config files are not accessible via URL. Try navigating to common paths like /wp-admin, /.env, /config.yml, and /backup.sql. If any return content instead of a 404, you have a problem.
16. Cookie security flags are set
Cookies should use the Secure flag (only sent over HTTPS), HttpOnly flag (not accessible via JavaScript), and SameSite attribute (prevents CSRF attacks). Check your authentication cookies especially.
17. Admin and staging URLs are locked down
Ensure staging environments, admin panels, and development tools are not accessible from the public domain. Password-protect or IP-restrict anything that isn't meant for public access.
Performance (Items 18-21)
18. Images are compressed and in modern formats
Uncompressed images are the single biggest cause of slow page loads. Convert images to WebP format, resize them to the actual display dimensions (don't upload a 4000px image displayed at 800px), and lazy-load everything below the fold. This is typically the highest-impact change for Core Web Vitals scores.
19. Core Web Vitals pass on mobile
Test your site against Google's Core Web Vitals thresholds:
- LCP (loading): under 2.5 seconds
- INP (responsiveness): under 150ms
- CLS (visual stability): under 0.1
Test on mobile specifically - not just desktop. Mobile pass rates are significantly lower than desktop, and Google uses mobile-first indexing.
20. Render-blocking resources are minimised
Scripts and stylesheets that block rendering delay everything. Defer non-critical JavaScript with the defer or async attribute. Inline critical CSS in the <head> so above-the-fold content renders immediately.
21. Cache headers are set for static assets
Static files (images, CSS, JS, fonts) should have long cache lifetimes (at least 1 year for hashed filenames). This doesn't help first-visit performance, but it dramatically improves repeat visits and reduces server load.
Content Quality (Items 22-24)
22. No placeholder content remains
Search every page for lorem ipsum, "coming soon", placeholder images, and test data. Check the about page, footer links, privacy policy, and any pages that tend to get written last. Launching with placeholder content is embarrassing and damages credibility.
23. Links are working (no 404s)
Click every link on every page. Check internal links, external links, and any links in the footer, navigation, and CTA buttons. Broken links on a brand new site signal neglect to both users and search engines.
24. Author and contact information is visible
For E-E-A-T signals, your site should clearly show who's behind it. An about page, author bios on blog posts, and visible contact information all contribute to trustworthiness in Google's evaluation.
Final Checks (Item 25)
25. Run a full website audit
After checking everything above manually, run an automated website audit to catch what you missed. Manual checks are thorough but they're also human - automated tools find the issues that visual inspection misses.
Kritano scans all 6 pillars (SEO, accessibility, security, performance, content quality, and structured data) in under 2 minutes. Run it before launch and again a week after to catch any issues that only appear under real traffic.
Frequently Asked Questions
What is a website launch checklist?
A website launch checklist is a structured list of items to verify before making a new or redesigned website public. It typically covers SEO setup, accessibility compliance, security configuration, performance optimisation, and content quality checks.
When should I start the launch checklist?
Start at least one week before your planned launch date. Some items (like setting up Google Search Console and submitting your sitemap) need time to take effect. Leaving everything to launch day creates unnecessary pressure and missed items.
What's the most commonly missed item on a launch checklist?
URL redirects. When a site is redesigned, old URLs often change. Without 301 redirects from old URLs to new ones, you lose all existing link equity, break external links pointing to your site, and create 404 errors for returning visitors.
Should I run an accessibility check before launching?
Yes. 96% of websites fail basic accessibility checks, and many of these issues are introduced during the build process. Checking before launch is significantly easier and cheaper than fixing accessibility problems after the site is live and indexed.
How do I check my website's performance before launch?
Use Google Lighthouse in Chrome DevTools or run a website audit that includes Core Web Vitals. Test on mobile with CPU throttling enabled to simulate real-world device performance. Target LCP under 2.5s, INP under 150ms, and CLS under 0.1.
My Take
In my honest opinion, most launch checklists focus too heavily on the visual stuff - does the design match the mockup, do the animations work, is the branding consistent. Those matter. But the things that actually determine whether your site succeeds - SEO foundations, accessibility compliance, security headers, performance metrics - are the ones that get skipped because nobody sees them until something goes wrong.
The 25 items here aren't aspirational. They're the minimum. If you're launching without checking these, you're shipping a site that looks finished but isn't.
If you want to run through everything quickly, audit your site across all 6 pillars before you launch. It takes less than 2 minutes and it'll catch what this checklist can't - the issues that only automated scanning finds.
Founder of Kritano
5 years in web development. I specialise in web auditing, WCAG 2.2 compliance, and search engine optimisation.
I built Kritano after years of running audits with fragmented tools. I write about SEO, accessibility, security, and performance based on real auditing data from thousands of scans.