A Technical SEO Checklist for Launching a New Website

Launch day is when small configuration mistakes do the most damage. A noindex left over from staging, a robots.txt copied from the dev server, a 404 page that returns 200, or a domain switch with no redirects can each keep a good site out of search for weeks, and none of them is visible to someone just looking at the homepage.

This is the checklist I run for a new site launch, split into before launch, launch day, and the first month after. Each item links to the documentation behind it, mostly Google Search Central, so you can check the reasoning rather than take my word for it.

Before launch

1. Decide your canonical hostname

Pick one version: https://www.example.com or https://example.com. Every other variant (http://, the other www choice, trailing-slash differences) should 301 to it in one hop.

Google calls redirects and rel="canonical" strong canonicalization signals and sitemap inclusion a weak one (Google: Consolidate duplicate URLs). Use redirects for hostname variants and a self-referencing canonical on each page.

Test all four combinations:

for u in http://example.com http://www.example.com https://example.com https://www.example.com; do
  echo "== $u"
  curl -sIL "$u" | grep -iE '^(HTTP/|location:)'
done

Each should end at the same final URL with no more than one redirect.

2. HTTPS everywhere

Install the certificate, redirect HTTP to HTTPS, and check for mixed content: anything on the page loaded over http://. MDN's mixed content guide explains what browsers upgrade and what they block. Google lists being "served in a secure fashion" among page experience considerations (Google: Page experience). Certificates also expire; Let's Encrypt certificates last 90 days, so make sure auto-renewal works before you rely on it. If you're on WordPress, my post on HTTPS and Mixed Content on WordPress After Installing SSL has the platform-specific steps.

3. Real 404s

Request a URL that doesn't exist:

curl -s -o /dev/null -w '%{http_code}\n' https://example.com/this-page-does-not-exist-123

It must return 404 (or 410), not 200. Google says that if a page's content suggests an error, "an empty page or an error message," Search Console will report a soft 404 (Google: HTTP status codes). Single-page apps and some themes get this wrong by default. Also don't redirect every missing URL to the homepage. Google treats those as soft 404s too (Google Search Console Help).

4. Titles and meta descriptions

Every indexable page needs a unique, descriptive <title>. Google's title link guidance asks for unique, concise titles and notes Google may rewrite them. Write a meta description for key pages. Google may use it for the snippet but isn't required to. Add Open Graph tags so shares look right. I covered all of these in detail in The SEO Meta Tags Checklist: Title, Description, Canonical and Open Graph.

5. Crawlable links and navigation

Google follows links in <a href> elements. Navigation built from click handlers on <div>s or <span>s may not be crawled (Google: Link best practices). Check that every important page is reachable through normal links from the homepage, and that anchor text describes the destination.

6. Core Web Vitals baseline

Run PageSpeed Insights or Lighthouse on your main templates (home, article/product, category). The "good" thresholds are LCP 2.5 seconds or less, INP 200 ms or less and CLS 0.1 or less, measured at the 75th percentile of page loads (web.dev: Web Vitals). Before launch you only have lab data. Search Console's Core Web Vitals report uses real-user field data and fills in once you have traffic. Common launch-time fixes are image dimensions, not lazy-loading the hero image, and trimming third-party scripts.

7. If you're replacing an old site: map redirects

This is the most expensive item to skip. Export every URL from the old site (sitemap, crawl, analytics, and Search Console's top pages), map each one to its closest new equivalent, and 301 it. Google's site move guide recommends keeping redirects for at least a year, and its Change of Address tool is only for moves to a new domain. My full recovery process is in 404 Errors After a Site Migration or Redesign: A Recovery Checklist.

Launch day

8. Remove the staging noindex

The classic launch bug. Staging sites are usually kept out of search with <meta name="robots" content="noindex">, an X-Robots-Tag: noindex header, or WordPress's "Discourage search engines" setting, and the flag survives the launch.

Check both places:

curl -sI https://example.com/ | grep -i x-robots-tag
curl -s https://example.com/ | grep -io '<meta[^>]*robots[^>]*>'

Then check a few inner templates too. A noindex can live in one template only.

9. Fix robots.txt

A staging Disallow: / copied to production blocks crawling of everything. Two things from Google's robots.txt introduction are worth knowing:

• robots.txt manages crawling and "is not a mechanism for keeping a web page out of Google."
• For noindex to work, the page "must not be blocked by a robots.txt file," because a blocked crawler "will never see the noindex rule" (Google: Block indexing).

So don't combine them on the same URL. For pages that shouldn't be indexed, allow crawling and use noindex. Use Disallow for things like infinite filter URLs or internal search results that waste crawl activity.

Add a Sitemap: line pointing to your sitemap.

10. Sitemap

Generate an XML sitemap containing only canonical, indexable URLs that return 200. No redirects, no noindexed pages, no staging hostnames. Many platforms do this automatically (WordPress has served /wp-sitemap.xml since 5.5). Google says small, well-linked sites of about 500 pages or fewer may not need one (Google: Sitemaps overview), but a sitemap is cheap and it gives Search Console a list to report against.

Quick check that every sitemap URL returns 200:

curl -s https://example.com/sitemap.xml | grep -oE '<loc>[^<]+' | sed 's/<loc>//' \
 | while read -r u; do echo "$(curl -s -o /dev/null -w '%{http_code}' "$u") $u"; done | grep -v '^200'

No output means every URL listed returns 200 directly. (For a sitemap index, run it on each child sitemap.)

11. Search Console

Verify the site, preferably as a Domain property so it covers every protocol and subdomain. Submit the sitemap. Use the URL Inspection tool on the homepage and a few key pages. Its live test shows what Google can fetch and render, and you can request indexing. Add teammates with the right permission level rather than sharing a login. Bing Webmaster Tools is worth setting up at the same time.

12. Analytics

Confirm your analytics tag fires on every template, including thank-you and checkout pages, and that staging traffic is excluded. It's not an SEO ranking factor, but you'll want data from day one to judge everything else.

The first month

13. Watch Page indexing

In Search Console's Page indexing report, look for:

• Excluded by 'noindex' tag on pages you want indexed (a leftover from step 8)
• Blocked by robots.txt on pages you want indexed (step 9)
• Not found (404), usually old URLs missing a redirect (step 7) or broken internal links
• Soft 404 (step 3)
• Duplicate, Google chose different canonical than user, which suggests mixed signals between redirects, canonicals and internal links (step 1)

New sites take time to be crawled and indexed, so don't panic over a slow first week. Look for patterns, not individual URLs.

14. Crawl your own site

Run a full crawl after launch. Screaming Frog SEO Spider is free up to 500 URLs (limits). Look for:

• Internal links to 404s or to redirected URLs (update them to the final URL)
• Redirect chains, especially left over from the old site
• Missing or duplicate titles and descriptions
• Broken images
• Pages with no internal links pointing to them

15. Re-test after every deploy

Launch isn't the only risky moment. Every deploy can bring back a noindex, break a template's canonical, or remove a page. Put the checks from steps 1, 3, 8 and 10 into your deploy pipeline or a scheduled job.

Ongoing monitoring

Steps 13 to 15 are where launches usually slip: they need repeating, and nobody owns them once launch week is over.

Disclosure: I build Uchik, which automates the recurring part. Uchik crawls a site daily and emails a report of broken links, missing images, redirect chains and loops, mixed content and pages that can't be reached. The how it works page explains the crawl, the features page lists the checks, and the sample report shows the output. Honest limits: it isn't a replacement for Search Console's indexing data; it reads server-delivered HTML, so links added only by JavaScript may be missed; its redirect-chain warning targets chains longer than 3 hops, so use the curl loop above to enforce one-hop redirects; and the free plan covers one site. You can sign up for free.

The checklist

Before launch

• [ ] One canonical hostname; all variants 301 to it in one hop
• [ ] Self-referencing canonicals on every indexable page
• [ ] HTTPS everywhere, no mixed content, auto-renewal confirmed
• [ ] Missing URLs return 404/410, not 200 or a homepage redirect
• [ ] Unique titles; descriptions on key pages; Open Graph tags
• [ ] Navigation uses real <a href> links
• [ ] Core Web Vitals lab baseline on main templates
• [ ] Old-site URL inventory mapped to 301s (if replacing a site)

Launch day

• [ ] No noindex meta tag or X-Robots-Tag on live templates
• [ ] robots.txt has no staging Disallow: /; includes Sitemap:
• [ ] Sitemap lists only 200, canonical, indexable URLs
• [ ] Search Console verified, sitemap submitted, key URLs inspected
• [ ] Analytics firing; staging excluded

First month and beyond

• [ ] Page indexing report reviewed weekly
• [ ] Full crawl: broken links, redirects, titles, images, orphan pages
• [ ] Launch checks automated for every deploy