Website Launch SEO Checklist: What to Verify Before You Go Live

Launch day is when small technical mistakes become public. A staging rule that blocks crawlers gets copied to production. Canonical tags still point at a test domain. The sitemap lists addresses that redirect. None of this shows up when you look at the page in a browser, which is why a launch needs a written checklist rather than a quick look around.

This website launch SEO checklist is for site owners, developers and agencies who are about to publish a new site or a redesign. It focuses on what you can verify: whether search engines are allowed to crawl and index the right pages, whether each URL returns the right status, whether the basics on each page are present, and whether you can see what happens after launch. By the end you will have a pass or fail result for each area and a short list of fixes.

A checklist cannot promise rankings, traffic or a particular indexing date. Google says no particular site is certain to be added to its index, and that some changes take effect in hours while others take months. The aim is to remove avoidable obstacles so that the content you publish can be found.

Before you begin

Access: you need the live (or near-live) site, its server or hosting configuration, the CMS, DNS access and, ideally, a Google account for Search Console.
Time: half a day for a small site; longer for large or multilingual sites.
Risk: the main risk is skipping the indexing check. Plan to run the whole list twice: once on staging, and again on production within an hour of the switch.
Back up: copy the current robots.txt, sitemap and redirect rules, and keep a list of old URLs if you are replacing an existing site. For a replacement, also read the website migration checklist.
Tools: a browser, curl or similar, and a crawler that reports status codes, titles and canonicals.

Step-by-step instructions

Step 1: Fix your URL plan and the canonical host

Why: every other check depends on knowing which address is the real one.

Action: choose one scheme and host, such as https://www.example.com. List the main page types and the URL pattern for each. Prefer descriptive, stable URLs; Google's starter guide recommends descriptive words rather than random identifiers. Make sure the other variants (HTTP, and the host you did not choose) redirect to the canonical one in a single hop. See www vs non-www.

Confirm: all four variants of the home page end at the same final URL.

Step 2: Make sure the right pages can be indexed

Why: the most damaging launch error is a leftover block. Google's site-move guidance tells you to plan to remove any temporary blocks or noindex rules when the new site goes live.

Action: check three places.

robots.txt: open /robots.txt on production. It should not contain a blanket Disallow: / unless you want the site hidden. Robots.txt controls crawling, not indexing: Google says a blocked URL can still appear in results without a description.
Meta robots and X-Robots-Tag: search the HTML and response headers for noindex. Google can only follow these rules if crawlers are allowed to fetch the page, so a page that is both blocked and marked noindex will not have its noindex seen.
Platform settings: many CMS and site builders have a "discourage search engines" or "hide from search" option. Turn it off.

Pages that should stay private (admin, carts, internal search) need noindex or a password, not only a robots.txt rule. See robots.txt blocking search engines and noindex vs robots.txt.

Confirm: a crawl of production finds no unexpected noindex and /robots.txt allows your key pages.

Step 3: Check status codes and redirects

Why: search engines and visitors rely on status codes to know what a URL means.

Action: crawl the site and confirm that important pages return 200, retired URLs redirect permanently (301 or 308) to a close replacement, and nonexistent URLs return 404. Avoid chains: Google's migration guide says Googlebot can follow up to 10 hops, but recommends redirecting straight to the final URL and keeping any unavoidable chain short. Do not send many old URLs to the home page. See redirect chains and loops.

Confirm: no important URL returns 4xx or 5xx, and a made-up URL returns a real 404, not a 200 "not found" page.

Step 4: Check HTTPS end to end

Why: a valid certificate and consistent HTTPS avoid browser warnings and duplicate versions of pages.

Action: confirm the certificate covers every host you use and is not close to expiry. Load key pages and look for mixed content, which means an HTTPS page loading an HTTP resource. Confirm internal links, canonicals and sitemap URLs all use HTTPS. Review security headers such as HSTS only after HTTPS is stable. See mixed content and HTTP security headers.

Confirm: no browser warnings, no mixed-content errors in the console.

Step 5: Check page-level basics

Why: these are the signals that describe each page.

Action: for each template (home, category, article, product, contact), view the source and check:

A unique <title> and a meta description that matches the page. Google's starter guide asks for titles that are unique, clear and concise. See title and meta description guide.
One canonical link pointing to the production URL, not staging or a different host. See canonical URLs.
A single clear <h1> and logical subheadings.
Descriptive alt text on meaningful images.
Real <a href> links between pages, because Google discovers links through them.
Structured data, if you use it, that matches visible content.

Confirm: a crawl report shows no duplicate titles on distinct pages and no canonical pointing to the wrong host.

Step 6: Check mobile content and performance

Why: Google uses the mobile version of your content for indexing, so anything missing on mobile may be missing from the index.

Action: compare mobile and desktop for the same page. Google asks that mobile pages have the same content, headings, structured data, metadata and image alt text as desktop, that robots.txt does not block mobile resources, and that primary content is not hidden behind interactions such as swiping or clicking. For performance, check the three Core Web Vitals against the "good" thresholds, measured at the 75th percentile: LCP within 2.5 seconds, INP of 200 milliseconds or less and CLS of 0.1 or less. These are field metrics, so a new site will have little real-user data at first. Lab tools such as Lighthouse can find problems early, but they are not the same measurement. See mobile-first indexing and Core Web Vitals explained.

Confirm: the mobile page contains the same main content, and lab tests show no obvious blocking problems.

Step 7: Publish a clean sitemap

Why: a sitemap tells search engines which URLs you consider canonical and worth crawling.

Action: generate an XML sitemap with only indexable, canonical, HTTP 200 URLs on the production host. Keep it under 50,000 URLs and 50 MB uncompressed, and reference it in robots.txt with a Sitemap: line. Google's sitemap overview says submitting one does not ensure crawling or indexing, and that small, well-linked sites may not strictly need one. See how to create an XML sitemap.

Confirm: the sitemap loads, every URL returns 200, and none carries noindex.

Step 8: Set up Search Console and monitoring

Why: you cannot fix what you cannot see.

Action: verify a Domain property in Google Search Console, submit the sitemap and, if you care about Bing, verify in Bing Webmaster Tools. Set up uptime monitoring and make sure analytics tags are present once. See Search Console setup and Bing Webmaster Tools setup. Schedule a review for the first month; the first 30 days guide lists what to watch.

Confirm: the property is verified and the Sitemaps report shows "Success".

Final verification checklist

Production robots.txt allows crawling of the pages you want found.
No unexpected noindex appears in HTML or headers.
CMS "discourage search engines" settings are off.
One canonical host serves 200; all other variants redirect once.
Important URLs return 200; removed URLs redirect or return 404.
HTTPS works on every host, with no mixed content.
Titles, descriptions and canonicals are unique and correct.
Mobile pages carry the same primary content and metadata as desktop.
Core Web Vitals have been tested, with field data to follow.
The sitemap lists only canonical, indexable, working URLs.
Search Console is verified and the sitemap is submitted.
Pre-launch notes record who checks what in week one.

Common mistakes to avoid

Copying staging settings to production. Check robots.txt, meta robots, canonicals and environment variables after the switch.
Blocking a page and expecting noindex to work. Crawlers must fetch the page to see the tag.
Launching with placeholder titles. Default templates create hundreds of duplicates.
Leaving the sitemap pointing at staging URLs. Regenerate it from production data.
Redirecting everything to the home page. Map old URLs to close equivalents.
Judging performance on a fast office connection. Test on realistic mobile conditions and read field data later.
Hiding mobile content in collapsed or interaction-only sections. Google does not load content that needs user interaction.
Skipping the second check. Repeat the list on the live domain, not only on staging.

Frequently asked questions

How long before a new site appears in Google?

It varies. Google's Page indexing documentation says a new site or page can take a week or so to start being crawled and indexed, and indexing is never instant. Some sites take longer.

Do I need to submit a sitemap?

It is optional. Google says it can help, especially for new sites with few external links, but it does not ensure indexing.

Should I block the site until it is perfect?

Use a password on staging. On production, avoid keeping a blanket block longer than needed, because it removes the chance for crawling.

Does this checklist work for a redesign of an existing site?

Yes, with extra care for redirects and URL mapping. Use the migration checklist alongside it.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.