Product launch mistakes that waste launch day

Most product launch failures happen before anyone votes: the site carries a leftover noindex, the link preview is blank, signup or checkout breaks under real traffic, or nothing records where visitors came from. Each of those can be caught the day before with a specific check, which is what this list pairs with every mistake.

The last mistake is about people, not code: launching on every platform the same day with nobody free to answer comments. It wastes the attention the rest of the work earned.

What are the most common product launch mistakes?

The mistakes that waste launch day are the ones that make visitors leave or make their visits invisible to you. A page Google can't index, a share card with no image, a form that errors, and links without campaign tags all fall in that group. The table lists each one with the check that catches it.

Why does a new site launch without being indexed?

Because a noindex rule from staging or a preview build shipped to production. Google's documentation says that when Googlebot sees noindex in a meta tag or header, "Google will drop that page entirely from Google Search results, regardless of whether other sites link to it." A robots.txt Disallow: / has a similar effect on crawling.

The rule hides in one of three places, so check all three on your production domain:

1. The HTML head. View source and search for <meta name="robots" content="noindex"> or <meta name="googlebot" content="noindex">.
2. The response headers. Run curl -sI https://yourdomain.com/ and look for X-Robots-Tag: noindex or X-Robots-Tag: none. Vercel, for example, adds X-Robots-Tag: noindex to every preview deployment automatically. The header is right on a preview and invisible in the page source, which is how a hand-written copy of it in a config file reaches production unnoticed.
3. The robots.txt file. Open https://yourdomain.com/robots.txt and look for Disallow: / under User-agent: * or User-agent: Googlebot.

The two rules interact badly. Google's documentation warns that if robots.txt blocks a page, "the crawler will never see the noindex rule," so the page can still appear in results from links, and your later fix to the noindex goes unread.

Timing matters more than most launch plans allow. Google has to recrawl a page to notice you removed the rule, and its documentation says that "depending on the importance of the page on the internet, it may take months for Googlebot to revisit a page." Check a week before launch, not the night before. Once the fix is live, open Search Console, paste the URL into URL Inspection, run Test live URL to confirm "Indexing allowed?" reads yes, then click Request indexing. The guide to a noindex that shipped to production walks through finding which build step added it.

Why do link previews break when you share a launch?

Because the page is missing Open Graph tags, points at an image the platform can't fetch, or the platform cached an old version. On launch day your link gets pasted into X, LinkedIn, Slack, Discord and group chats, and each shows a card built from those tags. A missing card makes the share look like spam.

The Open Graph protocol lists four required properties for every page: og:title, og:type, og:image and og:url. Meta's sharing documentation sets the image rules for Facebook: at least 200 x 200 pixels, no more than 8 MB, at least 1200 x 630 pixels "for the best display on high resolution devices," and as close to a 1.91:1 aspect ratio as possible to avoid cropping.

Check these the day before:

1. The four og: tags are in the server HTML of the page you'll share, not added later by JavaScript, so a preview crawler that doesn't run scripts still finds them.
2. og:image is an absolute https:// URL that loads in a private window without a login.
3. The image is 1200 x 630 and the text on it is readable at thumbnail size.
4. Paste the URL into Meta's Sharing Debugger and LinkedIn's Post Inspector. Both show the card they'll build and let you force a fresh scrape after you change the tags.
5. Share the link once in a private Slack or Discord channel to see the card a real reader will get.

If the card is right in the debugger but wrong in a post, the platform is serving a cached copy. Re-scrape it in the debugger rather than changing the URL. The full diagnosis is in the guide to an OG image that isn't showing.

How do you know signup and checkout will hold under launch traffic?

Run the whole path yourself in production, then put the slowest step under load. A signup form that works for one tester can fail at launch because of an email provider's sending limit, an auth rate limit, a database connection cap or a payment webhook that was only ever tested in sandbox mode.

Test the path the way a launch visitor will take it:

1. In a private window, on a phone, sign up with an address you haven't used before. Confirm the verification email arrives, and check its spam folder too.
2. Complete onboarding to the first useful screen. Note every step that takes more than a few seconds.
3. Buy the cheapest plan in live mode with a real card, then refund yourself in the payment dashboard. Confirm the webhook fired and the account shows as paid.
4. Check the limits on every service in the path: transactional email sends per hour, auth sign-ups per hour, database connections, and any AI API you call per request. Raise them or queue work before launch.
5. Send traffic at the slowest endpoint with a load tool such as k6 or ab, at several times the rate you expect, and watch the error rate.
6. Prepare a plain status message for the homepage in case something fails, so visitors see an honest note instead of an error page.

Also click every main call to action. A button wired to a handler that was removed in a refactor looks fine and does nothing. The launch traffic readiness guide covers caching and error pages for the same day.

What happens if you launch without analytics or UTMs?

You get a spike and no idea what caused it. Tag every link you post with campaign parameters. Google Analytics says that "when you add parameters to a URL, you should always use utm_source, utm_medium, and utm_campaign."

Set it up before the first post:

1. Pick one naming scheme and keep it lowercase. Google's help notes that parameter values are case sensitive, so utm_source=google and utm_source=Google report as different sources.
2. Build one tagged URL for each place where you control the link, for example https://yourdomain.com/?utm_source=newsletter&utm_medium=email&utm_campaign=launch-2026-10 and the same with utm_source=x&utm_medium=social. Product Hunt's submission guide asks for a direct link with no link shorteners, so leave its URL field untagged and read Product Hunt visits by their referrer.
3. Use utm_content when one post has two links, such as the headline link and a link in your first comment.
4. Mark signup and first payment as key events in Google Analytics so each source is judged by what it produced, not by visits.
5. Click each tagged link once and confirm it appears in Acquisition, Traffic acquisition, under Session source/medium.

Keep the links in a sheet with the platform, the post URL and the date. The evening review after each launch day is ten minutes with that sheet and the Traffic acquisition report.

Why is launching on every platform the same day a mistake?

Every launch platform rewards attention in the first hours, and you can only give that attention to one thread at a time. Product Hunt, Hacker News and most launch boards rank by votes or points on the day, and their readers judge you by how you answer. Two launches on one date split your network and leave one thread unanswered.

The platforms say this in their own rules. The Show HN guidelines require a project "you're around to discuss," and Product Hunt asks makers to have people try the product, comment and share feedback rather than ask for upvotes, which only works when the maker is there to reply. A thread where the maker never answers reads as abandoned.

Space the dated launches across the week, one per day, and let free queues land when they land. Name one person for each day's comments, and a second on the days you expect the most traffic. The SaaS launch checklist puts this schedule into the wider pre-launch list.

What should you check the day before launch?

Work through the list in this order, because the early items take longest to fix and the later ones depend on them:

1. Search the production domain for noindex in the head, the X-Robots-Tag header and robots.txt. If any turns up, fix it and request indexing today.
2. Open every page you'll share in the Sharing Debugger and Post Inspector and fix the cards.
3. Sign up, onboard and pay once in production, then refund.
4. Check the limits on email, auth, database and paid APIs.
5. Click every call to action on a phone and a laptop.
6. Build the tagged link for each platform and test one.
7. Write the calendar: one dated launch per day, one named person per thread.
8. Draft the first comment or maker post for each platform, so the morning is spent answering people.

Check the site side in one pass

The site-side items on that list can be checked together. Run the free scan on LaunchScaler with your production URL and no account: it runs 156 checks across 6 of its 7 categories at no cost. It reports a noindex in the meta tag or the header on a page you want ranked, robots.txt rules that block it, a main call to action that is a dead control, forms that can't submit or that error on valid input, a signup flow or checkout that breaks before completion, JavaScript errors on load and slow server responses. The previews, the UTMs and the calendar stay on your list, and the scan clears the rest before the traffic arrives.