When and how to relaunch your product

The test is whether someone who saw the first launch would learn something new from the second. Product Hunt’s list of what qualifies is a good general standard (Product Hunt’s relaunch guide):

• A major new feature or set of features.
• A new platform, like a mobile app or browser extension.
• A significant redesign or a new version.
• A pivot, where the product does something meaningfully different.

The same page says small fixes, minor UI tweaks or a new pricing plan usually aren’t enough on their own. Hacker News draws a similar line: new features and routine upgrades don’t qualify for Show HN, while a major overhaul probably does (Show HN guidelines).

A first launch that went quietly is not a reason by itself. If nothing changed, the result is unlikely to change either. Work out what went wrong first, using the guide on what to do after a quiet launch, and relaunch when the fix is something you can show.

A quick way to decide: write the one-line announcement. Compare:

• Not a relaunch: “Now with dark mode and a new pricing page.”
• A relaunch: “Version 2: now reads invoices from email, and there’s an iPhone app.”

Read on Product Hunt’s help pages in November 2026:

• You can launch every time you ship a major feature or update. If more than two months have passed since your last launch, you submit as usual. If less than two months have passed, you’ll be asked to submit a relaunch request explaining what changed and why it’s worth launching again, and the team reviews it and emails a decision (source).
• The two-month gap applies to products that share the same root domain, and to posts from the same company. Product Hunt’s examples of a significant update are a new mobile app or a complete redesign with new functionality; new UIs and pricing changes are named as not significant. An approved relaunch is not guaranteed a place on the homepage (source).
• When you submit, Product Hunt checks whether the same product URL has launched recently. The submit form has a “Launching again?” box where you choose your existing product, so the new launch is added to its product page (source).
• Don’t change your URL to get around the two-month window. Launches that try to bypass the duplicate check are removed (source).

One older help article, dated February 2025, says a product can always be resubmitted after six months, with featuring at the team’s discretion (source). The two relaunch articles are newer and both say two months. If the difference matters to your timing, Product Hunt’s help page suggests emailing its team before you put work into the post.

The Hacker News FAQ says that if a story has not had significant attention in the last year or so, a small number of reposts is OK, and that otherwise reposts are buried as duplicates. It also says not to delete and repost the same story (HN FAQ). So a Show HN that sank without comments can be posted again. One that had a real discussion needs the major overhaul the Show HN guidelines describe before it comes back.

Other communities and launch boards set their own rules, and many don’t write them down. Before reposting anywhere:

• Read the rules and any pinned posts on reposts and self-promotion.
• Where they’re silent, ask a moderator or the site owner, and say what changed.
• Say in the post that it’s a new version and link to the earlier thread. People who remember the first one will notice, and saying so first reads better than being caught.

On directories and boards where each product has a permanent page, a second page for the same product splits your votes, comments and links between two addresses and leaves an out-of-date one in search results.

• Edit the existing listing. Many sites let the maker change the description, screenshots and link. If there’s no edit button, email the owner with the listing URL and the new text.
• Use the platform’s relaunch path if it has one. Product Hunt attaches a new launch to the existing product page. Others have their own process or none; ask.
• Go through your launch log. The spreadsheet of listings from your first launch is now a to-do list. Open each one and check its name, tagline, screenshots and link. The backlink checker shows where each link points.

Refresh the text and images while you’re there. The guides on the tagline and description and listing visuals cover both.

A relaunch often comes with a new name, a new domain or a new URL structure. Every listing, post and bookmark from the first launch points at the old addresses, and they keep working only if you redirect.

1. Map old URLs to new ones. Google’s site-move guide starts here: list each old URL and the new URL that replaces it (Google on site moves).
2. Use permanent, server-side redirects. Google treats 301 and 308 as permanent: it shows the new target in results and takes the redirect as a signal that the target should be canonical. 302 and 307 are temporary and don’t carry that signal. JavaScript redirects should be used only if you can’t do server-side or meta refresh ones (Google on redirects).
3. Redirect page to page. Sending many old URLs to one irrelevant page, such as the new homepage, can confuse users and may be treated as a soft 404 (source). The old pricing page goes to the new pricing page.
4. Avoid chains. Redirect each old URL straight to its final destination, not through an intermediate one.
5. Keep the redirects. Google says to keep them as long as possible, generally at least a year. That means renewing the old domain.
6. Tell Search Console. If the domain or subdomain changed, submit a Change of Address for the old site.

Then ask the owners of your most valuable listings to update the link to the new address. A direct link is better than one that depends on a redirect you have to maintain.

Relaunches leave duplicates on your own site: an old landing page next to the new one, a /v2 or /beta path with the same content as the homepage, a staging copy that crawlers found. Google lists a demo version of a site left accessible to crawlers among the causes of duplicate pages (Google on canonicalization).

Google describes a redirect and a rel="canonical" link as strong signals for which URL should be canonical, and inclusion in a sitemap as a weak one (Google on canonical URLs). So:

• If the old page has no reason to exist, redirect it permanently to the new one.
• If both must stay reachable, point the duplicate’s canonical at the page you want in search:

<link rel="canonical" href="https://example.com/">

• Update the sitemap so it lists only the new URLs.
• Check the new pages’ own canonical tags. After a rename, a canonical still pointing at the old domain tells Google to prefer the address you’re leaving.
• Don’t use robots.txt or noindex to pick a canonical. Google advises against both.

A canonical is a hint, and Google may choose differently. In Search Console’s page indexing report, old URLs should move to “Page with redirect” or “Alternate page with proper canonical tag” over the following weeks (Search Console help). The indexability checker shows the status code, redirect target and canonical for any URL, and the guide on canonical tag mistakes covers the common errors.

1. Write the one-line statement of what’s new. If it reads like a changelog entry, wait.
2. Check each platform’s rule and timing. Send relaunch requests where they’re required.
3. If URLs changed, put redirects in place and test them before you announce anything.
4. Update existing listings: name, tagline, screenshots, link.
5. Tell the people from the first launch individually, especially those who asked for what you built.
6. Post the new launch with new text, say it’s a new version, and link to what changed.
7. A week later, recheck redirects, canonicals and every listing’s link. The launch checklist covers the rest of launch week.