Website launch checklist: 30 checks before a new site goes live

A website launch checklist is the list of things to verify before and right after a new site or redesign goes live: that search engines are allowed in, old URLs redirect, the site is secure and fast, every page has its title and share image, and forms, analytics and backups work. The launch mistakes that cost the most are predictable: the staging noindex comes along to production, old URLs stop working, the contact form sends mail nowhere. This checklist turns them into 30 items, each with how to verify it, plus a sequence for the night before, launch day and the week after. The indexing and content groups double as an SEO checklist for a new website; the reasons behind each are in technical SEO: crawling, indexing, speed and fixes. Plan an afternoon the week before launch and an hour on the day.

Quick answer

• A week before: run the full report on the new site's home page, one product or article page and one page with a form. Fix everything in Top fixes.
• The night before: back up, freeze content, confirm the redirect map, and lower the DNS TTL if the server changes.
• Launch day: remove every staging protection (noindex, password, "Discourage search engines"), re-run the report, test the old URLs, submit the sitemap, send a test form and place a test order.
• One week later: re-run the same pages and compare; check Search Console for 404s and pages not indexed.
• Copy the Markdown checklist below into your ticket or project board.

Why launches break

A launch changes everything at once: domain, server, theme, URLs, plugins. The things that break are rarely the things anyone was working on. A designer checks the pages look right; nobody checks that the old /shop/socks.html still leads somewhere, or that the robots meta tag changed. Search engines find these problems within days, and some of them (a whole site set to noindex, 500 old URLs returning 404) cost weeks of traffic to recover from. The fix is boring on purpose: the same list, every launch, in the same order.

How getReport checks it

The SEO audit covers the indexing and content items. For the rest, run the full report (paste the URL on the getreport.app home page): it runs all seven modules on one page, from Speed and Security to Accessibility, Structured data, Social and Best practices, and ranks what to fix first.

Top fixes is where a pre-launch run starts: the five findings that cost the most points, each with an effort of S, M or L. These four should never go live:

The report checks one page per run, so run it on at least three page types: the home page, a typical product or article, and a page with a form. For lists of URLs, the bulk URL checker returns the status, final URL, noindex and canonical of up to 1,000 addresses at once.

The 30 checks

Indexing (the SEO checklist for a new website)

1. No noindex anywhere. Check the robots meta tag and the X-Robots-Tag header on every page type. Verify: SEO audit, "The page is not set to noindex".
2. robots.txt allows the site. No Disallow: / from staging. Verify: the robots.txt tester on the home page and one deep page.
3. The sitemap is live, declared and submitted. Verify: "XML sitemap is reachable" and "robots.txt declares a sitemap" in the SEO audit; then submit it yourself in Search Console → Sitemaps.
4. Canonical tags point at the live domain. A canonical to staging.example.com gives your rankings away. Verify: the canonical finding fails with "points to another host".
5. Old URLs redirect in one hop, and unknown URLs answer 404. Build a redirect map from the old sitemap and your analytics' top landing pages. Verify: paste the old and new URL pairs into the migration redirect validator, up to 1,000 per run; Best practices checks for a proper 404 page. The site migration checklist covers redirect maps in depth.

Security

6. HTTPS everywhere, with a valid certificate, and http:// redirecting to https:// with one 301. Verify: the SSL check.
7. HSTS is set. Start with max-age=86400, raise it to a year once every subdomain works over HTTPS. Verify: security headers checker.
8. Security headers are set. X-Content-Type-Options, frame protection, Referrer-Policy, Permissions-Policy, a CSP in report-only mode to start. Verify: security headers checker.
9. Cookies carry Secure, HttpOnly and SameSite. Verify: security headers checker; it sees the cookies set on the page you test, so also test the login or cart page.
10. No exposed files. /.env and /.git must not be readable, and directories must not list their files. Verify: the Security module.
11. CMS, plugins and theme are up to date; staging is locked away. Verify: the Security module flags an outdated CMS version when the page reveals it, and the WordPress checker flags abandoned plugins and public staging copies. Also check the admin's update screen.

Speed

12. The LCP image is light and loads early. WebP or AVIF, sized for the screen, not lazy-loaded. Verify: speed test; the LCP finding names the element.
13. Text files are compressed and static files are cached. Verify: "Text files are compressed" and "Static files have a cache lifetime".
14. A CDN is in front of the site. Verify: "A CDN is in front of the site" in Best practices.
15. Fonts show text while loading. font-display: swap, self-hosted, one or two preloaded (web fonts without layout shift). Verify: speed test.

Content and SEO

16. Every page has its own title and description. Verify: SEO audit per page. The report does not compare pages with each other, so spot-check that product pages do not all share the shop's title; the on-page SEO checklist has what else to check per page.
17. One H1 per page, headings in order. Verify: SEO audit, "exactly one H1 heading".
18. Images have alt text. Descriptive for content images, alt="" for decoration. Verify: SEO audit and accessibility checker.
19. Structured data is valid. Organization on the home page, Product or Article on content pages. Verify: schema validator.
20. Every page type has a real share image. 1200×630 px, not the theme default. Verify: link preview tool.
21. Favicons are in place. A favicon and an apple-touch-icon. Verify: SEO audit.

Accessibility

22. Text has enough contrast. 4.5:1 for body text, 3:1 for large text. Verify: accessibility checker.
23. Every form field has a label. Contact, newsletter, search, checkout. Verify: accessibility checker on each page with a form.
24. The site works with a keyboard. The checker flags missing landmarks and skip links, but spend five minutes pressing Tab through the menu, a form and the checkout: every control reachable, focus always visible.

Legal and trust

25. Privacy policy and contact page are linked from every page. Verify: Best practices.
26. Cookie consent where the law requires it. In the EU, non-essential cookies need consent first. Best practices names the banner it detects, but open the site in a private window and look at DevTools → Application → Cookies before clicking anything: only essential cookies should be there.

Operations

27. Backups run, and a restore works. getReport does not check this. Restore last night's backup to a staging copy once before launch.
28. Someone is told when the site goes down or the certificate is about to expire. The SSL check shows the days left today; daily monitoring with alerts is a getReport funded unlock, so use your host's monitoring or an uptime service now.
29. Analytics records visits, and error tracking receives errors. Best practices lists the analytics it detects and catches JavaScript errors during one load. Open the analytics real-time view while you browse, and throw a test error to confirm your error tracker receives it.
30. Forms and checkout deliver. getReport cannot submit forms. Send every form once and place a real order (then refund it) on the live domain.

The night before

1. Freeze content changes on the old site; take a full backup of old and new (files and database).

2. Confirm the redirect map covers every old URL with traffic or backlinks.

3. If the site moves to a new server, lower the DNS record's TTL to 300 seconds at least one old-TTL period before the switch. The current TTL is the second column of:

   dig +noall +answer example.com A

4. Write down who does what tomorrow, and how to roll back.

Launch day

1. Switch DNS or deploy, then remove every staging protection: password, noindex header, "Discourage search engines".
2. Run the full report on the home page, a content page and a form page. Top fixes should hold nothing from indexing or security.
3. Run the robots.txt tester on the home page and a deep page, and the migration validator on the redirect map.
4. In Search Console, verify the property if it is new, submit the sitemap and use URL Inspection → Request indexing on the home page. If a page stays out of Google, why is my page not in Google? finds the cause.
5. Send every form, place a test order, and watch the analytics real-time view.
6. Send the report link (or its fixes view) to whoever fixes the rest: send fixes to your developer.

One week later

Re-run the same three pages with Re-run (reports are cached for 12 hours). A history strip under the score row shows the change since the previous report; anything that dropped is a regression from launch week. In Search Console, check Pages → "Not found (404)" for old URLs you missed and add redirects. Field Core Web Vitals need 28 days of real Chrome visits and enough traffic to appear; until then, the lab numbers are what you have.

The checklist to copy

## Website launch checklist

### Indexing
- [ ] 1. No noindex (meta tag or X-Robots-Tag) on any page type
- [ ] 2. robots.txt allows the site (no Disallow: / from staging)
- [ ] 3. Sitemap live, declared in robots.txt, submitted in Search Console
- [ ] 4. Canonicals point at the live domain
- [ ] 5. Old URLs 301 in one hop; unknown URLs return a real 404 page

### Security
- [ ] 6. HTTPS everywhere, valid certificate, http → https in one 301
- [ ] 7. HSTS set (short max-age first, then a year)
- [ ] 8. Security headers set (CSP in report-only to start)
- [ ] 9. Cookies Secure, HttpOnly, SameSite
- [ ] 10. No readable /.env or /.git, no directory listings
- [ ] 11. CMS, plugins, theme updated; staging locked or deleted

### Speed
- [ ] 12. LCP image compressed, sized, not lazy-loaded
- [ ] 13. Brotli/gzip on; long cache lifetimes for static files
- [ ] 14. CDN in front of the site
- [ ] 15. Fonts: font-display swap, self-hosted, preloaded

### Content and SEO
- [ ] 16. Unique title and description per page
- [ ] 17. One H1, headings in order
- [ ] 18. Alt text on content images
- [ ] 19. Structured data valid (Organization, Product/Article)
- [ ] 20. Share image 1200×630 on every page type
- [ ] 21. Favicon and apple-touch-icon

### Accessibility
- [ ] 22. Colour contrast 4.5:1 for body text
- [ ] 23. Every form field labelled
- [ ] 24. Keyboard walk-through done

### Legal and trust
- [ ] 25. Privacy policy and contact page linked from every page
- [ ] 26. Cookie consent blocks trackers until the visitor agrees (where required)

### Operations
- [ ] 27. Backups run; one restore tested
- [ ] 28. Uptime and certificate expiry alerts go to a person
- [ ] 29. Analytics records visits; error tracker receives a test error
- [ ] 30. Every form sent and a test order placed on the live domain

Platform notes

WordPress. The classic launch mistakes cluster here: Settings → Reading → "Discourage search engines" still ticked, plain ?p=123 permalinks, the "Hello world!" post still live, the default tagline. The WordPress Doctor panel in the full report flags each of them. In Settings → General, both "WordPress Address" and "Site Address" should use the live https:// domain.

Shopify. The storefront password (Online Store → Preferences → Password protection) keeps search engines and getReport out; remove it before the final run. Set the primary domain under Settings → Domains so every other domain redirects to it.

Static sites and custom builds. Staging protections usually live in the build or host config: an environment variable that adds noindex, a _headers rule, basic auth. Make sure the production build does not inherit them, and that the host serves the custom 404 page with status 404.

Common mistakes

• Running the checks on staging only. Staging and production differ in exactly the things that matter (headers, robots, DNS, CDN). Run the report again on the live domain within an hour of launch.
• Launching on a Friday afternoon. Redirect gaps and form failures show up with real traffic. Launch early in the week.
• Redirecting every old URL to the home page. Google treats it as a soft 404 and visitors are lost. Map each old URL to its closest new page.
• Removing redirects too soon. Google keeps crawling old URLs for months. Keep the redirects for at least a year.
• Testing only the home page. Product pages, forms and the checkout break differently. Three page types is the minimum.

Questions people ask

What should be on a website launch checklist?

Five groups: indexing (no noindex, robots.txt open, sitemap submitted, canonicals and redirects right), security (HTTPS, headers, updates), speed (images, compression, caching, fonts), content (titles, headings, alt text, structured data, share images) and operations (backups, monitoring, analytics, working forms). Verify each on the live domain on launch day, not only on staging, and re-run the checks a week later.

What SEO should I do before launching a new website?

Make sure search engines are allowed in and can find the right URLs: remove staging noindex and robots.txt blocks, point canonicals at the live domain, publish a sitemap, and give every page a unique title, description and H1. If the site replaces an old one, redirect every old URL to its closest new page with one 301. After launch, verify the site in Search Console and submit the sitemap.

How long does it take for a new website to show up on Google?

Usually from a few days to a few weeks, and there is no guaranteed time. Submitting the sitemap and requesting indexing of the home page in Search Console helps Google find the site, and links from sites Google already crawls help more. Showing up is not the same as ranking: a new domain often takes months to rank well for competitive searches.