Website Launch Checklist: Before You Go Live

At launch, lots of small settings start to matter at once: a staging setting that hides the site from search, a form that sends to an old inbox, a redirect nobody added. None of them show up when you click around the homepage. They show up later, in Search Console or in an inbox that stays quiet.

We build and launch sites through our WordPress development service, so weigh that. Every fact below about Google Search, Core Web Vitals, WCAG, WordPress, HTTPS and cookie consent was checked against the official documentation in October 2026.

Short answer: Before you point DNS at the new site, check five things: search engines aren’t blocked (robots.txt, noindex and the WordPress “Discourage search engines” box), HTTPS works and every other version of the domain redirects to one preferred version, every old URL that matters has a permanent redirect to its new home, every form reaches someone who reads it, and analytics records a visit. Then check performance, accessibility, legal pages and security. After launch, submit the sitemap in Search Console and watch for errors for a few weeks.

What the Official Docs Say Before Launch

As of October 2026, from Google Search Central, web.dev, W3C, WordPress.org, Let’s Encrypt and the ICO:

Sources: robots.txt, noindex, sitemaps, site moves, canonicalization, title links, web.dev Core Web Vitals, WCAG 2.2, WordPress Reading settings, WordPress file permissions, Let’s Encrypt FAQ, ICO cookie guidance.

Technical Infrastructure

• HTTPS works on every version of the domain. Check the certificate is valid for the bare domain and the www version. Let’s Encrypt doesn’t charge for certificates, and its default certificates are valid for 90 days (source), so renewal must be automatic. Confirm your host does it.
• HTTP redirects to HTTPS. http://yoursite.com should send visitors to https://yoursite.com with a permanent redirect. On Cloudflare, Always Use HTTPS redirects every http request to https for all subdomains and hosts (source). Elsewhere it’s set in the server config or the host’s panel.
• One preferred host. Pick www.yoursite.com or the bare domain. The other should 301 to it. Google treats a redirect as a strong signal for which URL becomes canonical (source).
• DNS is ready to switch. TTL controls how long each DNS record is cached, and so how long a change takes to reach visitors (source). Lower it at least one current TTL period before the switch, then check the site from more than one network.
• Production matches staging. PHP version, database version and memory limits should be the same. On WordPress, Tools > Site Health shows critical issues on the Status tab and server details on the Info tab (source).
• No broken internal links. Crawl the whole staging site with a link checker before launch.
• Missing pages return a real 404. A custom 404 page with navigation helps, but its status code must still be 404. If an error page returns 200, Search Console reports a soft 404 (source).

SEO Essentials

• robots.txt doesn’t block the site. Staging sites often carry Disallow: /. Remove it. robots.txt controls crawling. It’s not a mechanism for keeping a page out of Google: for that, Google says to use noindex or password protection (source).
• No leftover noindex. In WordPress, the “Discourage search engines from indexing this site” box under Settings > Reading adds a noindex, nofollow robots tag, and it’s up to search engines to honor it (source). Untick it at launch. If you do want a page kept out, don’t also block it in robots.txt: the crawler has to reach the page to see the noindex (source).
• Permalinks are final. Choose the structure under Settings > Permalinks, for example Post name (source), before launch. Changing it later means a redirect for every URL.
• The XML sitemap is accurate. It should list absolute, canonical URLs, within 50MB or 50,000 URLs per file. Submit it in Search Console, or add a Sitemap: line to robots.txt (source).
• Search Console is verified. A Domain property is verified with a DNS record and covers both http and https and every subdomain (source). Verify it before launch so you have data from day one.
• Every page has a unique title. Google sets no length limit on the title element, but truncates title links to fit the device. It advises against vague titles like “Home” and against keyword stuffing (source).
• Every page has a unique meta description. Google sometimes uses it for the snippet and recommends a unique description for each page (source).
• The main heading is clear. Google looks at the main visual title and heading elements when it builds title links, and says to make clear which text is the main title (source). On WordPress the page title is usually the H1. Check for pages with none or with competing ones.
• Images have alt text. WCAG 2.2 requires a text alternative for non-text content, and decorative images should be ignorable by assistive technology (source), usually with alt="".
• Canonical tags point to the right page. Google recommends a self-referential canonical on the canonical page, and warns against mixed signals, such as one URL in the sitemap and another in rel=“canonical” (source).
• Open Graph tags are set. The protocol’s four required properties are og:title, og:type, og:image and og:url (source).
• Structured data validates. Google suggests the Rich Results Test during development and the rich result status reports after deployment, and says not to mark up information visitors can’t see (source).
• Analytics records a visit. The GA4 Realtime report shows active users in the last 5 and 30 minutes (source). Visit the site and look for yourself.

Performance

• Core Web Vitals are in the good range. web.dev defines good as LCP within 2.5 seconds, INP of 200 milliseconds or less and CLS of 0.1 or less, measured at the 75th percentile of page loads (source). Before launch you only have lab tests. Field data from real visitors comes later, through the Chrome User Experience Report.
• Test the pages that matter. Run the homepage, the main service page and the heaviest content page through PageSpeed Insights. Fix what it flags before you look at the score.
• Images are compressed and sized. No image should be larger than its display size. Use WebP or AVIF. Run your pages through honest.designodin.com for a performance and SEO report before launch.
• Caching is configured. Server-side caching stops WordPress building every page from scratch. Check response headers for a cache hit.
• The CDN is active, if you use one. Static files should load from the CDN, not from your origin server.
• Compression is on. Look for a content-encoding header (gzip or br) on text responses in your browser’s developer tools.
• Fonts load cleanly. Self-host where you can, preload the main font and check the text doesn’t jump when the font arrives. That jump counts toward CLS.

Functionality

• Every form sends and arrives. Submit each one. Check it reaches the right inbox, the confirmation message or redirect works, and submissions are stored somewhere other than email, so a spam folder can’t swallow a lead.
• Forms are labelled. WCAG 2.2 requires labels or instructions when content needs user input (source).
• Spam protection is on. Add a challenge such as Cloudflare Turnstile or reCAPTCHA, or a honeypot field, and check real submissions still get through.
• The CRM connection works. If forms feed HubSpot, Salesforce or another CRM, test the whole path: submission, contact created, the right person notified.
• Phone numbers are tappable. Wrap them in a tel: link so mobile visitors can call in one tap.
• External links work. Click each one.
• Cookie consent is functional. For UK visitors, the ICO says you must tell people about cookies, explain what they do and get consent. It also says you can’t set non-essential cookies on your homepage before the user has consented, though cookies essential to a service the user asked for are exempt (source). The ICO notes it is revising this guidance. For other countries, check your own regulator. Then test that analytics and ad tags really wait for consent.
• Search works, if you have it. Try a few real queries and an empty one.
• Checkout is tested end to end. On WooCommerce, place an order in your payment provider’s test mode and check the email, the admin order and the stock count.

Content and Legal

• The privacy policy is accurate. It should name the tools you actually run, such as analytics and ad pixels. Your legal adviser should review it, not your web agency.
• Terms are in place where you need them. Sites that take payments or registrations usually need them. Get a legal review.
• Placeholder content is gone. Search the CMS for “lorem”, “TBC” and “insert”.
• Contact details match everywhere. Phone, email, address and hours should agree across the footer, the contact page and any structured data.
• Prices are right. If you list prices, check every one.
• Dates on blog posts and case studies are correct. Future-dated posts may sit unpublished. Past dates should match when the content was written.
• Accessibility is covered. The US Department of Justice says the ADA applies to businesses open to the public, including what they offer on the web, and points to WCAG as helpful guidance (source). Two checks you can do yourself, both WCAG 2.2 AA: text contrast of at least 4.5:1, and tap targets of at least 24 by 24 CSS pixels (source).

Security

• WordPress admin access is locked down. The WordPress handbook recommends strong, unique passwords, two-factor authentication for every administrator (core doesn’t include it, so use a plugin or your identity provider) and rate-limiting login attempts. It says obscuring the login URL can reduce noise but shouldn’t be your only defense (source).
• Default passwords are changed. Admin users, database, hosting panel, SFTP. No account should keep a password set during development.
• File permissions are correct. WordPress documents directories at 755 or 750, files at 644 or 640, wp-config.php at 440 or 400, and never 777 (source).
• Backups are automatic and tested. A WordPress backup needs both the site files and the database (source). Confirm the schedule and the retention period, and test a restore on staging before you need one.

Pre-Launch Verification

• Cross-browser testing is done. Chrome, Firefox, Safari (including iOS Safari) and Edge. Look at layouts, fonts and form fields.
• Real devices, not only emulation. Test on an actual iPhone and an actual Android phone.
• Sign-off is written down. Get written approval from everyone who has to approve the site: owner, marketing, legal.
• Redirect mapping from old URLs is complete (for redesigns). Google’s site-move guidance says to map old URLs to new ones, use permanent server-side redirects (301 or 308), avoid redirect chains, return 404 or 410 for content you’re dropping, and keep redirects generally for at least a year (source). Start with old URLs that have traffic or links.

Launch Day in Order

1. Freeze content changes on the old site.
2. Take a final backup of the old site and the new one.
3. Untick “Discourage search engines” and remove any staging rules from robots.txt.
4. Switch DNS.
5. Load every host variant (http, https, www, bare domain) and check each ends on the preferred URL in one hop.
6. Spot-check old URLs from your redirect map.
7. Submit every form and place a test order.
8. Check GA4 Realtime for your own visit.
9. Submit the sitemap and inspect key URLs with Search Console’s URL Inspection tool, which can test the live URL and request indexing (source).
10. If the domain changed, use the Change of Address tool after the redirects are live. Google says not to use it for an http to https move (source).

The First Weeks After Launch

• Watch Search Console. Check the page indexing, sitemaps and HTTPS reports. Google lists the HTTPS report as the place to see which pages aren’t served securely (source).
• Watch for 404s. New 404s on old URLs are redirects you missed.
• Re-test the forms. Mail settings can change after DNS moves.
• Keep the old redirects. Don’t remove them once traffic settles.

Related Posts

• Website redesign checklist: protecting rankings when you replace a site
• What is a sitemap: what goes in it and why
• Website accessibility requirements: the standards behind the accessibility checks
• WordPress security best practices: hardening beyond launch day

FAQ

What happens if I skip some of these checks?

It depends on the item. A leftover noindex or robots.txt block keeps pages out of search until someone notices. A broken form loses leads with no error message. Missing redirects send old links to 404s. Those checks matter for every business site. Others, like checkout, only apply if you have them.

How long does this checklist take to complete?

It depends on the site and how much was tested during the build. On a well-tested site, most items are a quick confirmation. On a site with problems, it takes as long as fixing them.

Do I need to hire someone to run through this checklist?

Not for all of it. The infrastructure, SEO and security sections are easier with a developer. You or your team should own the content and legal checks, with your lawyer on the legal pages. Whoever built the site should already have done the pre-launch verification.

What tools do I need for this checklist?

Free ones cover most of it: Google Search Console, PageSpeed Insights, the Rich Results Test, GA4 Realtime, WordPress Site Health, your browser’s developer tools and a link crawler. honest.designodin.com gives a performance and SEO report in one place.

Should I block search engines while the site is on staging?

Yes, but the safest way is a password, because Google says robots.txt isn’t a way to keep pages out of its results. Whatever you use, put removing it at the top of the launch-day list.

What should I do if I find critical issues right before launch?

Fix them first. A short delay to fix a broken form, a missing redirect map or a robots.txt block is worth it. Otherwise you fix it on a live site while visitors and Google watch.