Launching a website before it’s ready is expensive. A broken contact form means you lose leads silently. A missing SSL certificate means Chrome labels your site as “Not Secure” to every visitor. A wrong robots.txt setting means Google spends weeks or months not indexing your pages. These are not hypothetical risks — they’re the things we find when we audit sites that have been “live” for months.
This checklist covers what to verify before the DNS changes and your site goes public. Work through it category by category. The 20 minutes you spend on this prevents problems that take weeks to diagnose and fix.
Technical Infrastructure
1. SSL certificate is active Visit your site URL with https:// and verify the padlock appears in the browser address bar. If you see “Not Secure,” stop — do not launch without SSL. Most managed WordPress hosts (Kinsta, WP Engine) provision SSL automatically. If yours doesn’t, use Let’s Encrypt (free) through your hosting control panel.
2. Redirect all HTTP traffic to HTTPS SSL alone isn’t enough. Your server needs to redirect http://yoursite.com to https://yoursite.com with a 301 redirect. Otherwise, both versions of the site exist simultaneously — confusing Google and splitting your backlink equity. Verify in .htaccess (Apache) or nginx.conf, or via your CDN’s settings.
3. WWW/non-WWW redirect is consistent Pick one canonical version: www.yoursite.com or yoursite.com. Both should not simultaneously return 200 status codes. The non-preferred version should redirect to the preferred one with a 301. Verify in Google Search Console after launch.
4. DNS propagation is complete After changing nameservers or DNS records, wait for propagation (typically 15 minutes to 48 hours, usually under an hour for most providers). Verify at whatsmydns.net before assuming the site is fully live.
5. Hosting environment matches your development environment PHP version, MySQL version, and memory limits should match between staging and production. A site that works on staging and breaks on production often has an environment mismatch.
6. No broken links Use Screaming Frog (free up to 500 URLs) or Ahrefs’ broken link checker to crawl all internal links before launch. Every 404 on a new site is unnecessary — the content exists somewhere, it’s a linking error.
7. 404 error page is custom and functional The default host 404 page sends visitors back to Google. A custom 404 page with navigation links keeps them on your site. Verify that non-existent URLs return a 404 status code (not 200, which is called a “soft 404” and confuses crawlers).
SEO Essentials
8. robots.txt is correct
This is the critical one. During development, many staging environments block search engines with Disallow: / in robots.txt. This must be removed before launch. Visit yoursite.com/robots.txt and verify it does not block Googlebot. One incorrect line here means your site won’t get indexed for weeks.
9. XML sitemap exists and is correct Verify yoursite.com/sitemap.xml or sitemap_index.xml exists and lists your pages accurately. If using Yoast SEO or RankMath on WordPress, this is automatic. Submit to Google Search Console after launch.
10. Google Search Console is set up Add and verify your property in Search Console before launch, not after. Submit your sitemap. Set your preferred domain (www or non-www). This gives you immediate crawl data from day one instead of starting blind.
11. Every page has a unique meta title Meta titles should be 50–60 characters, include the primary keyword, and be unique across all pages. No two pages should have the same meta title. Duplicate titles are a crawlability signal that your content is generic.
12. Every page has a unique meta description Meta descriptions don’t directly affect rankings, but they affect click-through rate from Google results. Aim for 140–155 characters. Include a value statement or call to action. Again — unique per page.
13. H1 tags are present and correct Every page should have exactly one H1 tag containing the page’s primary keyword. On WordPress, the page or post title is typically the H1. Verify no page has multiple H1s or a missing H1.
14. Image alt text is complete
Every image should have a descriptive alt text. This serves three purposes: screen reader accessibility, a small SEO signal for image search, and a fallback when images fail to load. Skip decorative images (use alt="" for those).
15. Canonical tags are correct Canonical tags tell Google which version of a page is the “official” one. Verify that each page’s canonical tag points to itself (self-referential), not to another page. Incorrect canonical tags are a common cause of indexing problems on page builder sites.
16. Open Graph tags are set When your pages are shared on LinkedIn, Twitter, or Facebook, Open Graph tags control the title, description, and image displayed. If these aren’t set, social platforms generate their own — often poorly. Yoast and RankMath both handle OG tags.
17. Schema markup is in place At minimum: Organization schema on the homepage, LocalBusiness schema if you have a physical location, and Article schema on blog posts. Schema markup helps Google understand your content and can trigger rich results (review stars, breadcrumbs) in search.
18. Google Analytics (or equivalent) is tracking correctly Verify your GA4 property is receiving data before launch. In GA4, go to the Realtime report and visit your site — you should see yourself appear within 30 seconds. Broken Analytics means you have no baseline data from launch day.
Performance
19. Google PageSpeed score is 90+ on both mobile and desktop This is the floor, not the target. Run your homepage, your primary service page, and your most content-heavy page through PageSpeed Insights (pagespeed.web.dev). If any page scores below 80, fix the problems before launch. Below 70 is a significant ranking disadvantage.
20. Core Web Vitals pass Verify LCP under 2.5 seconds, CLS under 0.1, and INP under 200ms. PageSpeed Insights reports these. If you’re on Kinsta or WP Engine, their dashboards also show Core Web Vitals data.
21. Images are properly compressed and sized No image should be larger than necessary for its display size. Use WebP or AVIF format. A homepage hero image should be under 200KB in WebP at 1400px wide. Run your pages through honest.designodin.com to get a full performance report before launch.
22. Caching is configured
Server-side caching (on managed WordPress hosts, this is automatic) ensures WordPress’s PHP engine doesn’t process on every page request. Verify caching is active by checking response headers for X-Cache: HIT or similar signals.
23. CDN is active A CDN delivers your static assets from servers close to your visitors. Verify your CDN is properly configured and assets are loading from CDN URLs (usually a different subdomain or the CDN provider’s domain).
24. GZIP or Brotli compression is enabled Web servers should compress files before sending them to browsers. Verify at GtMetrix or WebPageTest. Look for the content-encoding header on responses. Uncompressed responses add unnecessary transfer size.
25. Font loading is optimized
Web fonts should be preloaded in the <head> and self-hosted where possible. No Google Fonts loaded via the standard JavaScript embed (it adds a render-blocking request). Verify there’s no FOUT (Flash of Unstyled Text) on first load.
Functionality
26. Contact form sends and receives correctly Submit every form on the site before launch. Verify the submission goes to the right email address. Verify the confirmation message or redirect works. Verify that form submissions are logged somewhere recoverable — email-only delivery means you’ll lose leads if your email goes to spam.
27. Contact form spam protection is active Google reCAPTCHA v3 or Cloudflare Turnstile should be on every contact form. Without spam protection, your form will receive bot submissions within days and fill your inbox with junk.
28. CRM integration works If form submissions connect to HubSpot, Salesforce, or another CRM, test the end-to-end flow: submission → CRM contact creation → notification to the right team member.
29. Phone number is clickable on mobile
Tel: links let mobile visitors call you with one tap. Verify your phone number is wrapped in <a href="tel:+1XXXXXXXXXX"> on mobile views.
30. All external links open correctly Check that external links work and (where appropriate) open in a new tab. A broken link to a key partner site or reference on launch day is a bad look.
31. Cookie consent is functional If you’re serving EU visitors or running Google Ads with conversion tracking, a cookie consent banner is legally required. Verify it appears on first visit, works correctly, and that analytics and ads don’t fire until consent is given (where required).
32. Search functionality works (if applicable) If your site has a search bar, test it. Search should return relevant results, not empty pages or errors.
33. E-commerce checkout is end-to-end tested If you have a WooCommerce store, run a real test transaction with a real card or Stripe’s test cards. Verify the order confirmation email sends, the order appears in WooCommerce admin, and the inventory (if tracked) decrements.
Content and Legal
34. Privacy Policy is in place and current Required by GDPR (EU), CCPA (California), and the terms of service for Google Analytics, Google Ads, and most third-party tools. It must be accurate — if you’re using GA4, your Privacy Policy must disclose that.
35. Terms of Service or Terms and Conditions are in place Required for any site that accepts payments, user registrations, or service agreements. Your legal counsel should review this, not your web agency.
36. All placeholder content is replaced “Lorem ipsum” text, placeholder images from the development phase, “Coming Soon” sections, and “[Insert testimonial here]” notes all need to be gone before launch. Run a text search across the CMS for “lorem” before signing off.
37. Contact information is accurate Phone number, email address, physical address (if applicable), business hours. Verify it’s consistent across the site — the footer, the contact page, and any schema markup should all show the same information.
38. All prices are accurate If you list pricing on the site, verify every number before launch. An incorrect price on a live site can create legal and customer service problems.
39. Dates on blog posts and case studies are correct Future-dated posts may not publish correctly on some configurations. Past dates should match when the content was actually created or published.
Security
40. WordPress admin access is locked down (if WordPress) The default WordPress login URL (yoursite.com/wp-admin) is targeted by automated brute-force bots within hours of a site going live. Rename or restrict access to the login URL. Enable two-factor authentication. Limit login attempts.
41. All default passwords are changed Admin user, database, hosting control panel, SFTP — all should have unique, strong passwords. No account should still have the password set during development.
42. File permissions are correct WordPress files should be 644. WordPress directories should be 755. wp-config.php should be 640. Incorrect permissions are a common entry point for compromised sites.
43. Automatic backups are configured Your host should take daily backups. Verify the backup schedule, the retention period (at least 14 days), and that you can restore from a backup without calling support. Test the restore process on staging before you need it in production.
Pre-Launch Verification
44. Cross-browser testing is complete Test in Chrome, Firefox, Safari (including iOS Safari), and Edge. The most common cross-browser issues: CSS grid layout inconsistencies, custom font rendering, and form element styling.
45. Mobile testing on real devices Browser developer tools mobile emulation is a starting point, not a substitute. Test on an actual iPhone and an actual Android device. Pay particular attention to navigation usability, form field behavior, and tap target sizes.
46. Stakeholder sign-off is documented Get written approval from anyone who needs to approve the site before launch — the business owner, the marketing team, legal. “We reviewed the site on a call” is not the same as written approval. This protects you if someone raises an objection after launch.
47. Redirect mapping from old URLs is complete (for redesigns) If you’re replacing an existing site, every old URL that had traffic or backlinks needs a 301 redirect to the appropriate new URL. A redesign that doesn’t include redirect mapping destroys the SEO equity built on the old site. This is one of the most common and most expensive mistakes in site redesigns.
FAQ
What happens if I skip some of these checks? Varies by item. A missing SSL certificate means Chrome shows a security warning to every visitor. An incorrect robots.txt means Google won’t index your site for weeks. A broken contact form means silent lead loss. Skippable items depend on your specific site — items 1–18 are close to mandatory for any business site.
How long does this checklist take to complete? For a well-built site that was properly QA’d during development, 2–4 hours. For a site with existing issues, however long it takes to fix them. This checklist is as useful during development as it is pre-launch.
Do I need to hire someone to run through this checklist? For items 1–18 (technical and SEO), a developer is useful. For items 34–43 (content and legal), you or your team should handle it — especially legal items. For items 44–47, the people who built the site should have already covered them.
What tools do I need for this checklist? Screaming Frog (free up to 500 URLs), Google PageSpeed Insights (free), Google Search Console (free), GTmetrix (free tier), WebPageTest (free), and honest.designodin.com for a performance and SEO audit.
What should I do if I find critical issues right before launch? Fix them. A one-week delay to fix a broken form or an incorrect robots.txt is always worth it. The cost of launching broken is higher than the cost of a short delay.
If you’re working with Designodin on a custom WordPress build, this checklist is incorporated into our standard launch process — not as a client responsibility, but as a deliverable. Every site we launch goes through a full pre-launch audit before DNS is pointed. Get started here to see what a properly launched site looks like.