Check it the way visitors arrive
Most of these checks fail in places you do not look while building: a link pasted into chat, a phone on a train, a search result, a typo in the address. Test from a private browser window, a phone on mobile data and the command line, not only from the laptop where you are already signed in.
The order below roughly follows how a visitor meets the site: the address and the certificate first, then how the page appears in search results and shared links, then speed, then the things that pay off after launch, such as search data and a way to reach you.
Website ready
0/10Two reachable versions of your site split your search signals, and a certificate warning ends the visit before the page loads.
What to check
Every version of your address (http and https, with and without www) should end on one canonical https URL in a single redirect. The certificate should be valid, cover both hostnames and renew on its own.
How to check it
Run curl -I against each of the four versions and read the status line and the Location header: you want one 301 straight to the canonical address, not a chain. Open the site in a private window and check the browser shows no warning, then look in the developer console for mixed content, which is an http image or script loaded on an https page.
What goes wrong
The www version has no certificate, redirects go through two or three hops, a staging domain is still reachable and gets indexed, and a certificate that was set up by hand expires three months after launch.
These are the words people read in search results and in shared links. Without them the browser and the search engine guess for you.
What to check
Every page has its own title, roughly 50 to 60 characters, that starts with what the page is about, and its own description of about 150 to 160 characters that says what the reader gets. No two pages share either one.
How to check it
View the page source, or run a crawler over the site (Screaming Frog is free up to 500 URLs) and sort by title to find duplicates and blanks. Paste a few URLs into a search result preview tool to see where the words get cut off.
What goes wrong
Every page titled with only the product name, a single page app that sets the title in JavaScript so some crawlers see the default, and one template description repeated on every page, which search engines ignore and replace with text of their own choosing.
Most of your launch links get shared in a chat window. A blank preview reads as broken, a clear one gets opened.
What to check
Each page people are likely to share has og:title, og:description and og:image tags. The image is 1200 by 630 pixels, served from an absolute https URL, and still readable when it is shown as a small card.
How to check it
Paste the URL into opengraph.xyz to see the card, then into the platforms' own tools, such as the LinkedIn Post Inspector, which also refreshes their cached copy. Then send the link to yourself in the chat apps your users use, because that is where most launch links end up.
What goes wrong
A relative image path that works in the browser and fails in every preview, an image behind a login or blocked by robots.txt, text too small to read at card size, and an old preview stuck in a platform's cache after you fixed it.
It is the only thing identifying your tab among the twenty others someone has open.
What to check
A favicon.ico at the root, an SVG or PNG icon linked from the page head, a 180 by 180 apple-touch-icon for phone home screens, and a web manifest with larger icons if people might install the site.
How to check it
Look at your tab next to twenty others, add the site to a phone home screen, and search for your product name to see the icon Google shows beside the result. Google asks for a square icon of at least 48 by 48 pixels at a URL that does not change.
What goes wrong
The framework's default icon still in place, a detailed logo that turns into a smudge at 16 pixels, and an icon path that redirects or is blocked, so browsers and search engines never pick it up.
They tell search engines which pages to read and which to leave alone, which matters most in the weeks when you are first being indexed.
What to check
robots.txt at the root allows the pages you want found and names your sitemap. The sitemap lists only canonical URLs that return 200, and nothing that redirects or is marked noindex.
How to check it
Open /robots.txt and /sitemap.xml in a browser on the live domain. Submit the sitemap in Google Search Console and Bing Webmaster Tools and check the number of discovered pages matches what you expect. Run the URL Inspection tool on your key pages to confirm Google is allowed to crawl them.
What goes wrong
The Disallow: / line from the staging site shipped to production, which quietly keeps the whole site out of search. Sitemaps that list redirecting or duplicate URLs, and a robots.txt that blocks the CSS and JavaScript a search engine needs to render the page.
Broken links happen at launch more than at any other time, because other people are writing about you. Send those visitors somewhere instead of nowhere.
What to check
A URL that does not exist returns an HTTP 404 status, not a 200 with an error message, and shows a page with your navigation and links to the places people most likely wanted.
How to check it
Run curl -I against a made up path such as /this-does-not-exist and read the status line, then open the same path in a browser. Single page apps and some hosts serve the home page for every unknown path, which looks fine until search engines find hundreds of copies of it.
What goes wrong
Soft 404s: an error page sent with a 200 status, which search engines treat as a thin duplicate page. A bare "Not found" with no way back into the site. Old URLs, or links other people already shared, breaking without a redirect to their new address.
Roughly half your launch traffic arrives on a phone, often on a poor connection, and usually from a link someone tapped in passing.
What to check
The page meets Google's "good" thresholds for Core Web Vitals on a phone: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1.
How to check it
Run PageSpeed Insights on the home page and your main landing pages and read the mobile result first. Its field data, when the site has enough traffic, shows what real visitors got; the lab score is a guide to what to fix. Then load the site on a mid range phone over mobile data and watch what appears first.
What goes wrong
A hero image several megabytes large, web fonts that hide the text until they load, analytics and chat widgets that hold up the first paint, and a layout that jumps when a cookie banner or an image without set dimensions arrives.
This is how you later find out which queries and which listings actually sent you people.
What to check
Google Search Console and Bing Webmaster Tools both have the site verified and the sitemap submitted, and everyone who needs the reports has access, before launch traffic starts.
How to check it
Verify the whole domain in Search Console with a DNS TXT record, which covers every subdomain and both protocols at once. Bing Webmaster Tools can import your sites straight from Search Console. After launch, open the page indexing report and read the reason given for each page that is not indexed.
What goes wrong
Verification done with a meta tag or an uploaded file that disappears in the next redesign, a property for only one of the four URL variants, and nobody reading the reports, so the queries and crawl errors from launch week go unnoticed.
A growing share of buyers ask an assistant before they open a search engine. If your pages are unreadable to an agent, or your claims are not stated in plain text, you are missing from the answer it gives.
What to check
Your key pages deliver their main content in the HTML rather than only after JavaScript runs, robots.txt does not block the AI crawlers you want reading the site, and the page says plainly what the product does, who it is for and what it costs.
How to check it
Fetch a page with curl and search the output for your main claims; if they are missing there, many agents will not see them either. Read robots.txt for rules naming GPTBot, ClaudeBot, PerplexityBot or Google-Extended. Then ask a few assistants what your product does and compare the answer with your own page.
What goes wrong
A bot protection rule that blocks every automated request, content that only exists in images or in tabs loaded by script, and pricing or features described so vaguely that an assistant has nothing to quote.
Directories check that it works, buyers use it, and it is often the only route a serious enquiry has to you.
What to check
A real address on your own domain, shown on the site as text, that reaches a person who reads it. If you send mail from the domain, SPF, DKIM and DMARC records are in place so your replies do not land in spam.
How to check it
Write to the address from an outside account and reply to that message. Check the domain's MX records and run the sending domain through a checker such as MXToolbox. Make sure someone still receives the mail when the person who set it up is away.
What goes wrong
A no-reply address, a contact form that drops messages when its email service fails, an inbox nobody checks, and an address shown only as an image, so neither people nor directories can copy it.
Questions
FAQHow long does this take?
Most of it is an afternoon. The two that take longer are page speed on a phone and getting titles and descriptions written for every page.
What is the one item people skip and regret?
The social share image. Most launch links get pasted into chat, and a blank preview reads as broken.
Do I need a sitemap for a five page site?
Not strictly, but it costs nothing and it helps while you are first being indexed.
Should the www or non-www version be the main one?
It does not matter which you pick. It matters that only one of them answers and the other redirects to it.
Is a contact form enough?
An address people can write to is better. Directories check it, and forms fail quietly.
More checklists
- The product launch checklistA free product launch checklist for SaaS, apps, AI tools and more. Every step says why it matters and when you can skip it.
- App launch checklistMobile app launch checklist: store review, device screenshots, privacy labels and every other step, with why each matters and when to skip it.
- SaaS launch checklistSaaS launch checklist: pricing, trials, payments, failed charges and every other launch step, with why each matters and when to skip it.