A person sees the error. Every tool that only reads the status code sees a healthy page. That gap is what Google calls a soft 404, and I had three of them without knowing.

What I ran

Just curl, asking only for the status code:

curl -s -o /dev/null -w "%{http_code}" https://yoursite.com/blog/this-does-not-exist

I did it on six of my sites, on the root and on every dynamic route I could think of (blog posts, launch pages, project pages, tools). Here’s what came back:

The root was fine everywhere. /this-page-does-not-exist gave a real 404 on all of them. That’s the one people usually test, and it’s the one that’s least likely to be broken.

Three dynamic routes were not. auraplusplus.com/studio/<fake>, auraplusplus.com/launches/<fake> and indiehunt.io/studio/<fake> all returned 200. The page titles literally say “Studio Post Not Found” and “Launch Not Found”.

The project pages on MakerHunt and SideHunt, and the alternatives pages on EarlyHunt, returned a clean 404. So same kind of stack, same person writing it, different answers depending on the route. That’s the annoying part. You can’t test one URL and call it done.

Why Google mostly didn’t care

Before panicking I looked at the HTML. All three pages carry a robots noindex meta tag. Each one has two of them, in fact. Google’s docs say that when a 200 page looks like an error or an empty page, Search Console reports it as a soft 404, and with noindex on it the page stays out of the index anyway. So no fake “Not Found” pages ranking for my brand. Good.

My best guess at the cause, and I haven’t confirmed it in our code yet: these sites run on Next.js. The Next.js docs say streamed responses start with a 200 status, and if notFound() runs after streaming has started (for example inside a Suspense boundary or under a loading file), the status stays 200 and Next.js injects a noindex tag instead. That matches exactly what I saw, double noindex and all. If you’re on Next.js, check which of your routes have a loading.tsx. Same framework where I wrote about a canonical in the root layout quietly landing on every page. The defaults are good until one line changes what every page says to Google.

Where it actually bites

Google is fine. Everything else that reads status codes isn’t.

Link checkers. If you run a broken link checker over your site, or over the directories you submitted to, a deleted post or a removed listing comes back 200 and gets marked as OK. You’d never find the dead link.

Uptime monitors. If your monitor pings a product page and someone deletes that product, the monitor stays green.

Backlinks and badges. This one matters for launch sites like mine. A maker puts a “featured on” badge on their homepage linking to their launch page. If that launch is ever removed, their badge points at a “Not Found” page that every tool says is alive. Neither of us would notice for months.

If you’d rather not use curl, the free redirect checker on Aura++ shows the status code for every hop of a URL, including the last one. It’s my site, so weigh that. Paste a made-up URL from each route and see if the last hop says 404 or 200.

The 2-minute version for your site

1. List your route patterns, not your pages

Blog post, product page, user profile, tag page, docs page, changelog entry. One fake URL for each. The root 404 doesn’t count, it’s almost always right.

2. Ask for the status code, not the page

Run the curl line above for each one. You want 404, or 410 if you deliberately removed something. A 200 on a URL you made up is the bug. A redirect to your homepage is a softer version of the same bug, Google tends to treat that as a soft 404 too.

3. Fix the route, then check again

On Next.js that usually means making sure the “does this exist” lookup happens before anything starts streaming, so notFound() can still set a real 404. On other stacks it’s usually a catch-all route rendering an error component without setting the status. Either way, re-run the same curl after deploying.

I’m putting this on my own list for Aura++ and IndieHunt this week. It also connects to something I wrote about why a new product doesn’t show up for its own name, where a leftover noindex is one of the first things to check. Same lesson, different header: what the page says and what the server says aren’t always the same thing.

When you test, use the Aura++ redirect checker or curl, whichever is closer. I’m curious what people find: did your made-up URL come back 404, or did your site also say “all good” about a page that isn’t there?

That means any public certificate authority is allowed to issue an SSL certificate for those names, as long as it thinks it validated that I control the domain. Not just Let’s Encrypt, which is the one we actually use. Any of them.

I don’t think that makes me unusual. Most small sites I’ve looked at have no CAA record, because nobody tells you about it. Your host gives you HTTPS automatically, the padlock shows up, and you never think about who else is allowed to make a cert for your name.

So this is the short version of what CAA is, how to check yours, and the record you probably want. I haven’t added it to my own domains yet as I write this, so I’m not going to pretend I have. This is the checklist I’m going to follow.

What a CAA record actually does

CAA stands for Certification Authority Authorization. It’s a DNS record where you list which CAs are allowed to issue certificates for your domain. The current rules are in RFC 8659, and public CAs have been required to check it before issuing since 2017.

Without one, the default is “everyone”. Let’s Encrypt’s own docs put it plainly: by default every public CA can issue for any domain, provided they validate control of it. So if any single CA has a bug in its validation, every domain without CAA is exposed to that bug.

With a record like this, you’re saying only Let’s Encrypt may issue:

example.com.  CAA  0 issue "letsencrypt.org"

The 0 is the flags field, and you’ll almost always leave it at 0. “issue” is the tag. The value is the CA’s identifying domain. A CA that isn’t on the list is supposed to refuse.

What “done” looks like on big sites

I looked up a few sites I trust, using Google’s public DNS, on Oct 30, and checked them again on Nov 2. Same answers.

google.com publishes exactly one record: issue “pki.goog”. Google only lets its own CA issue for it. Simple.

github.com publishes seven. For normal certs (issue) it allows DigiCert, Sectigo, Let’s Encrypt and GlobalSign. For wildcard certs (issuewild) it allows DigiCert, Sectigo and Let’s Encrypt. So GlobalSign can issue a cert for github.com, but not for *.github.com. That’s the detail most people miss: issue and issuewild are separate permissions, and if issuewild exists it wins for wildcards.

medium.com does something similar. Let’s Encrypt is on its issue list but not on its issuewild list, so Let’s Encrypt can’t issue a wildcard for it.

And for comparison, dev.to had no CAA record when I checked. Big sites skip it too. It’s not a sign of a broken site, it’s just an open door nobody closed.

How to check yours in a minute

If you have a terminal:

dig example.com CAA +short

Empty output means no record, so any CA can issue. If you’d rather not read raw records, I built a free CAA record checker on Uno Directory. It’s one of my sites, so take that into account. You type a domain, and it tells you in plain words which CAs can issue for the name and for a wildcard of it. It also walks up to the parent domain when the name you typed has no record, because that’s how CAs do it too. It only does a DNS lookup, nothing else.

Next, find out which CA you actually use today. Open your site, click the padlock and look at the issuer, or run:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -issuer

All four of my domains came back as Let’s Encrypt. Do this for every subdomain that serves something (app, api, docs, status), because different parts of your stack might use different CAs without you knowing.

Adding the record without breaking your HTTPS

This is the part where people get burned, so go slowly.

1. Put it on the root domain

CAs look for the record on the exact name first, then walk up one label at a time until they find one. So a record on example.com covers www.example.com, app.example.com and so on, unless a subdomain has its own record that overrides it.

2. List every CA you really use

If your marketing site is on Let’s Encrypt but your docs tool or status page is hosted somewhere that uses a different CA, and you only list letsencrypt.org, that other service fails at its next renewal. Records are additive, so just add one issue line per CA.

3. Watch out for Cloudflare and CNAMEs

If you’re on Cloudflare with Universal SSL, Cloudflare’s docs say it adds CAA records for its own partner CAs automatically once you add any CAA record, and those auto-added ones don’t show in the dashboard. Check with dig after you save.

CNAMEs matter too. If docs.example.com is a CNAME to some provider’s hostname, CAA checking follows the CNAME, so the provider’s CAA rules apply. Usually fine, just know that’s where to look if a cert suddenly won’t renew.

4. Lock down parked domains completely

This one is free and I like it most. Indie hackers collect domains. If a domain doesn’t serve any site, you can say no CA may issue for it at all:

parked-idea.com.  CAA  0 issue ";"

An issue tag with no CA name means “no issuance”. Nobody gets a valid cert for a domain you forgot you owned. I wrote about the other side of forgotten domains, the old CNAMEs that point at things you don’t own anymore, and it’s worth doing both on the same afternoon.

5. Re-check after saving

Run the dig command again, or the checker, and make sure the answer matches what you meant. Then wait for your next renewal and confirm it went through. If you renew automatically, you might as well check your renewal setup at the same time, since certificate lifetimes are getting shorter. Let’s Encrypt is moving to 64-day certificates, so a renewal job that quietly broke will show up faster than it used to.

What CAA doesn’t do

I want to be honest about the limits, because people oversell this.

CAA is checked by the CA at the moment it issues. It does nothing to certificates that already exist. It doesn’t stop a CA you allowed from making a mistake. And it depends on CAs following the rules, which public CAs are required to do, but it’s still a request, not a lock on your server.

If someone takes over your DNS, they can just change the CAA record. That’s what the optional accounturi parameter is for: it ties issuance to your specific ACME account, so even a person who can pass domain validation can’t get a cert without your account key. Let’s Encrypt supports it. For most small sites the plain issue record is enough to start. The bigger lesson is that your registrar login matters more than any record in it. I put registrar lock and the other account lockout checks in a separate checklist.

It also doesn’t replace watching for certificates. Certificate Transparency logs record publicly trusted certs, and you can search them on crt.sh to see every cert issued for your domain. CAA reduces who can issue. CT shows you what was issued.

The whole thing, short

Look up your CAA record. Find which CAs you actually use, on every subdomain. Add one issue line per CA on the root domain. Add issue “;” on every parked domain. Check again after saving and after the next renewal.

It’s maybe fifteen minutes for a handful of domains. I’m doing mine this week. If you want to check yours first, the Uno CAA checker is free and needs no signup.

Curious if anyone here has actually had a CAA record break a renewal. Was it a CNAME, Cloudflare, or a service you forgot was issuing certs for you?

Our backlink spreadsheet has a column called “follow”. Every directory gets one word in it: dofollow or nofollow. For months I trusted that column like it was a bank statement.

On Oct 20 I finally checked it against the real pages, one listing at a time. The first one I opened was our Aura++ listing on SaaSHub. The sheet said nofollow. The page had three links to auraplusplus.com. “Official pricing” and “Blog” were rel=”nofollow”. But the big “Visit website” button had no rel at all. That’s a normal followed link. So the sheet was wrong, and wrong in the bad direction: we had written off a link that was actually working for us.

I was kind of proud of catching that. I even wrote about it.

Today, Oct 29, I opened the same SaaSHub page again before writing this. The “Visit website” button now says rel=”nofollow”. All three links to our site are nofollow. Nine days. Nobody emailed me. I don’t know why it changed and I’m not going to guess. Directories change their markup and their rules whenever they want, and they don’t owe you a notification.

So the sheet was wrong on Oct 20 and would be right today, completely by accident. Which means the column was never really telling me anything.

A backlink is a state, not a fact

This is the thing I got wrong for a long time. I treated “is this link dofollow” as something you find out once, when the listing goes live, and then write down forever.

It isn’t. It’s a state of one HTML tag on someone else’s page, on the day you looked. It can change when they redesign, when they change a policy, when your listing moves to a different template. And notice it’s per link, not per site. Same page, same day, SaaSHub gave us one followed link and two nofollow ones on Oct 20. “SaaSHub is nofollow” was never a true sentence. Neither was “SaaSHub is dofollow”.

Our PeerPush listing is the opposite kind of example. I checked it on Oct 20 and again today. One link to our site, the “Visit site” button, and its only rel value is “noopener”. People see a rel attribute there and panic. Don’t. noopener is a browser security thing for links that open a new tab. It has zero SEO meaning. That link is followed. The page itself also says index, follow in its robots meta tag and its canonical points to itself, so nothing at page level cancels it either.

And quick reminder because I still see people searching for it: there is no rel=”dofollow”. Nobody writes that. A link counts as followed when it doesn’t carry nofollow, ugc or sponsored. Google has treated those three as hints since 2019, not hard rules, but if a directory promised you a dofollow link and shipped nofollow, you didn’t get what you paid for or worked for.

How I audit one listing in two minutes now

No SEO suite, no browser extension. Just the page source.

First I open the listing URL itself, not my homepage, and view the source (Ctrl+U in Chrome). Then Ctrl+F for my domain. Every hit inside an a tag is a link I need to look at. On SaaSHub that’s three, on PeerPush one. If a directory shows other stuff like GitHub or LinkedIn links for your product, ignore those, they don’t point at your site.

For each hit I read the rel attribute. No rel, or only things like noopener and noreferrer: followed. Has nofollow, ugc or sponsored: not followed. I also glance at the anchor text, because it tells you which button you’re looking at.

Then I check the top of the page. A robots meta tag with nofollow or noindex changes the value of every link on the page, even the clean ones. Same for an X-Robots-Tag header, which you won’t see in the source. And the canonical tag should point at the listing itself, not somewhere else.

If my domain doesn’t show up in the source at all, that’s a result too. It usually means the button is added by JavaScript, or it goes through the directory’s own redirect URL. Either way there’s nothing in the server HTML to count, so I don’t count it.

That’s it. It really is about two minutes per listing once you’ve done it a few times. The annoying part is doing it again later, which is the whole point of this post.

If you have more than a handful of listings, I built a free tool that does exactly this check: the Aura++ Dofollow Link Checker. You paste the listing URL and your domain, it reads the server HTML (it does not run JavaScript) and lists every link to your site with its rel value and anchor text, plus page-level noindex/nofollow. Free, no signup. Disclosure: Aura++ is mine.

What I’m changing in the sheet

Two things, both boring.

The “follow” column goes per link, not per directory. SaaSHub gets three rows. It looks worse. It’s more honest.

And a new column: “last checked”. A follow status without a date is just a rumor. The plan is to recheck every listing we care about once a month, and anything older than that counts as unknown, not as dofollow.

I’m also done using “dofollow” as the main reason to keep a listing. If a page sends real people, keep it even if it’s nofollow. Domain Rating and link juice are a weak way to judge a directory on their own. I wrote more about what Domain Rating actually measures on the Aura++ blog if you want the longer version. And honestly most founders have the opposite problem anyway, too many listings and no idea which ones matter. That’s why I’d rather you stop submitting to 40 directories the week you launch and keep a short list you can actually recheck.

Check me too

Since I’m poking at other directories, fair is fair. On Aura++, a free launch only gets a dofollow link if it finishes top 3 for the day and you show our badge. The $29 Premium launch gets a dofollow link guaranteed. Founder profile website links are nofollow by default unless you pay $5 once. That’s what our pricing pages say today. Don’t take my word for it, view the source on your own listing and see.

That’s really the only rule I’ve got left after this. Whatever a directory says, whatever your spreadsheet says, whatever I say: open the page, read the tag, write down the date. Then do it again next month. If you want to skip the View Source part, the free dofollow checker is there.

On Oct 26 the five sites had 1,219 visitors between them. The seven products that launched on Aura++ the day before got 15 visits to their pages that same day. Zero upvotes.

That bugged me more than a slow day would. A slow day I understand. This was traffic that showed up and then walked straight past the launches.

Where the visitors actually go

When I looked at where people land, it mostly isn’t the launch pages. It’s old listing pages. Project pages from months ago. Pages that rank for some long-tail search. Someone lands on a project from months ago, reads it, leaves. This week’s launches are two clicks away and nobody does the two clicks.

Oct 23 made it even clearer. The four weekly sites had 99 launches live that week. Those launch pages got 42 visitors that day, across all four sites. The sites themselves had 608 visitors that day.

So about 7 out of every 100 visitors touched a current launch. And the four sites never sent anyone to each other. Each one was its own little island, even though a person who cares about a launch on MakerHunt would probably care about one on SideHunt too.

I suspect a lot of small launch boards look like this. Ours just happen to have the analytics open.

What I changed, in two small steps

Step one, Oct 24. Aura++ already had a strip (since Oct 17) showing launches from the four weekly sites. The weekly sites had nothing pointing back. So on the project pages and launch pages of IndieHunt, EarlyHunt, MakerHunt and SideHunt we added an “Also live this week on the network” strip. Up to six launches that are live this week on the other three sites. Real projects, ranked by upvotes.

It’s not on the homepages, on purpose. The homepage has one job and I didn’t want to muddy it. The visitor I’m trying to catch is the one who landed on some old project page and is about to close the tab.

Step two, today (Oct 27). The weekly strip only knew about weekly launches. Aura++’s daily launches, the ones that got 15 visits across seven launches, weren’t in it. So Aura++ got a small public feed of today’s launches (shipped Oct 26), and the strip on the four weekly sites now reads from it too.

No new pages. No new site. One small JSON feed, and an existing strip that got one more source. If you want to see what gets pulled in on a normal day, it’s today’s launches on Aura++.

Why I didn’t build a “network” page

Honestly that was my first idea. One big page showing everything from all five sites. I dropped it for a boring reason: nobody would land on it. A new page starts with zero traffic. The whole problem was that the traffic already exists, on pages I don’t think about, so the fix had to live on those pages.

The other idea was to push makers harder on launch day. I’ve written about what to send your own audience on launch day and I still believe it. But that’s the maker’s job. This one was on me, as the person running the boards.

What I’m not claiming

The weekly strip is three days old. The daily feed is a few hours old. I have no result to share and I’m not going to pretend I do.

Every link in the strip carries its own UTM tag, with the sending site as the source, so over the next seven days I can see exactly how many people each site sends to the others and to the Aura++ launches. If it’s tiny I’ll say it’s tiny.

And I won’t judge it on clicks alone. The real test is whether a launch on a weekly site, on a random Tuesday, gets more than single-digit visits to its page.

If you run more than one site

Even two. A blog and a product. A tool site and a directory. Before you build anything, open your analytics and find out what share of visitors ever reach the page you actually care about. Mine was about 7%. I would have guessed way higher.

Then put the cross-link where people already land, not on a shiny new page. Tag it so you can see it working or not working. And leave the homepage alone if the homepage already does its job.

I wrote a longer piece on Aura++ about what actually happens after you launch, if the day-two part is what you’re stuck on.

And if you’re shipping something small soon, the weekly boards live on the IndieHunt launches page. With this change a launch there can also show up on the other three sites. I’ll post the numbers in a week, good or bad.

Nobody would ever notice this by looking at the site. You only see it when the link gets pasted somewhere and the platform crops the image to its own shape. The tag is telling crawlers one thing and the file is another, and the crawler believes the file.

That’s the whole problem with link previews. They are the first thing most people see of your launch, and almost nobody looks at them until something already went out.

Where your launch link actually gets seen

On launch day you post the link on a launch board and maybe X. But a lot of the real sharing happens somewhere else. A friend drops it in a WhatsApp group. Someone pastes it in a Slack channel at work. A cofounder sends it on LinkedIn. In all of those places nobody sees your landing page first. They see a little card: an image, a title, maybe one line of description.

If that card has no image, or a cut-off title, or your logo squashed into a corner, it looks like a dead link. People scroll past it. And you don’t get to fix it on the fly, because many of these apps cache the preview after the first time the link is shared.

What I found when I checked my own pages

On Oct 22 we ran a preview check on the 7 newest pages across my sites. Honest results:

• 1 page had no og:image at all. It’s a launch platform compare tool on Product Hunt Alternatives. I checked it again this morning (Oct 26) and it still has none, so a share of that page has no picture.
• 6 of the 7 page titles were over 60 characters, between 61 and 87. The compare tool page title is 67 characters today.
• The Aura++ share image is the one I opened with. Tags say 1200x630, the file is 1366x768. Still true this morning.

None of this broke the sites. All of it makes the shared link look worse than it should. And these are pages from someone who runs launch platforms for a living, so I’m guessing yours have a few of the same.

Three things I check before I share a launch link

1. Is there an image, and does it load?

Not “is there an og:image tag in the code”. Does the URL in that tag return an actual image, with a 200 response, from a public address? Images behind a login, on localhost, on a staging domain, or with a relative path are common reasons the card shows up blank. Open the image URL in a private window. If you can’t see it there, a crawler can’t either.

2. Is the image the size the tag claims?

1200x630 is the size most people use, roughly a 1.91 to 1 shape, and it’s what Facebook’s own guidance points to. If your real file is a different shape, each platform will crop it its own way and your text can get cut off at the edges. Keep anything important away from the edges anyway, and make sure the width and height tags match the real file. Mine didn’t.

3. Does the title survive being cut?

Long titles get trimmed in preview cards, same as in search results. Put the words that matter at the start, and the brand at the end where it can disappear safely. I wrote about how Google trims titles by pixels instead of characters, and the same idea applies here. Count width, not just letters.

You can check all three by hand with view-source and a private window. Or paste the URL into the free OG Image Checker on SideHunt, which is one of my sites. It previews the card for X, LinkedIn and Facebook, flags missing OG and Twitter tags, and checks the image itself, like whether it returns 200 and is 1200x630. No signup.

After you fix it, the old preview might still show

This is the part that catches people. You fix the image, share the link again, and the old broken card is still there. Platforms cache previews. LinkedIn has its Post Inspector and Facebook has the Sharing Debugger, and running your URL through them asks for a fresh scrape. Chat apps are less predictable, so the easiest fix is to check before the first share, not after.

A simple habit that works: the day before a launch, paste the link into a private chat with yourself on WhatsApp or Slack and look at it like a stranger would. Two minutes. If it looks bad there, it’ll look bad everywhere.

What I’m fixing

The compare tool page needs a share image. The Aura++ image needs to be exported at the size the tags say (or the tags changed to match). Titles I’m shortening as I touch each page, starting with the ones people actually share.

If you’re launching soon, run your own landing page through the OG image checker or just paste it into a chat with yourself. Then tell me in the comments: what was wrong with yours? I’m curious if the missing image or the wrong size is more common.

And it’s the week most of us tag those links worst. Somebody types utm_source=Reddit on Monday, utm_source=reddit on Tuesday, utm_source=r-saas on Wednesday. Ten days later the report shows three small rows instead of one clear one, and the question you actually cared about, which place sent people who paid, has no answer.

UTMs aren’t hard. The problem is that we treat them like something to type on the spot, when they’re really a naming system you decide once.

What goes wrong when you tag on the fly

Case splits your rows. In Google Analytics 4 the values you put in UTM tags are case sensitive in reports, so “Reddit” and “reddit” come out as two sources. Most smaller analytics tools do the same thing, they just show what you typed. Pick lowercase for everything and never think about it again.

A made-up medium ends up nowhere. GA4 sorts traffic into channels using fixed rules from Google’s default channel group doc. A medium of “social” goes to Organic Social, “email” to Email, “referral” or “link” to Referral. Something creative like utm_medium=launchpost doesn’t match any rule and lands in Unassigned, which is the one bucket nobody opens. You can still filter by it, but your channel overview will quietly lie to you.

Tagging your own internal links. If you put UTMs on a banner that goes from your blog to your pricing page, you overwrite where that visitor really came from. Tags are for links that live on other people’s pages and in other people’s inboxes. Never on your own site.

No way to tell two links on the same site apart. Say you post on X and also put the link in your X bio. Both say source x. That’s what utm_content is for, and almost nobody uses it.

Write the sheet before launch day, not during

This is the whole fix. The night before, open a plain spreadsheet with five columns: where the link goes, source, medium, campaign, content. One row per place you plan to post. Then fill it with a few boring rules:

Source is the site or list, lowercase, one word if you can: producthunt, reddit, x, linkedin, newsletter-name, waitlist.

Medium is only from a short list that GA4 understands: social, email, referral. Launch boards and directories are referral. Your waitlist email is email. Posts on Reddit or X are social. That’s it, don’t invent new ones.

Campaign is one name for the whole launch, like launch-oct-2026, so later you can filter everything in one go and compare it with the next launch.

Content is where you split the same site: post vs bio vs comment, or first email vs reminder email.

Then you generate every link from that sheet and paste from the sheet, never from memory. When you’re tired at 11pm on launch day replying to comments, that matters more than you think.

Full disclosure, I built a free UTM link builder on Posting Dude (one of my sites) because my own launch links kept turning into this mess. It runs in the browser, nothing gets uploaded, and there’s no signup. A spreadsheet formula works fine too. The tool doesn’t matter, the sheet does.

Where you can and can’t tag

Some places let you control the link fully: your own posts, your email, your bio, a DM. Tag all of those.

On launch boards and directories you usually submit a website URL in a form. Many will keep a query string if you paste the tagged URL in, some strip it. Check the live listing once it’s up and hover the button. If the tag is gone, don’t worry, that board still shows up as a referrer on its own because the visitor arrives from its domain.

And some traffic will never be tagged no matter what you do. A friend pastes your link in a group chat, someone types your domain after hearing it on a podcast. That lands as Direct. I wrote about catching that part in asking “where did you hear about us?” in free text, because referrer reports simply can’t see word of mouth.

What to actually look at after

Don’t stop at visits. A board can send 300 visitors who bounce and a small newsletter can send 12 who sign up and stay. Filter by your launch campaign, then look at signups or the first real action per source. That’s the number that should decide where you launch next time.

Give it about a week after launch day, not the evening of. Some people bookmark and come back.

If you’re running a side project and only want the minimum setup, there’s a good breakdown of setting up analytics you’ll actually check over on SideHunt.

So here’s my question. On your last launch, which place sent the people who actually paid, and did your analytics know it, or did you find out by asking them?

The problem is most versions of that snippet don’t stop at training. They also block the bots that ChatGPT search, Perplexity and Claude use to find pages and cite them in answers. So you wanted to say “don’t train on me” and you actually said “don’t ever mention me”.

For a big publisher that can be a deliberate choice. For a small SaaS that is trying to get its first users, it’s usually an own goal.

There are three kinds of AI crawler, not one

This is the bit most people miss. AI companies run separate user agents for separate jobs, and robots.txt treats each one as its own bot.

Training crawlers. They collect pages for model training. GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, CCBot, Amazonbot, MistralAI-Training.

Search and answer crawlers. They index pages so an assistant can find and link you when someone asks a question. OAI-SearchBot, Claude-SearchBot, PerplexityBot, DuckAssistBot, Amzn-SearchBot, MistralAI-Index. Googlebot and Bingbot sit next to these as the classic search baseline.

User-triggered fetchers. When a person pastes your URL into a chat or asks the assistant to open a page, it fetches it right then. ChatGPT-User, Claude-User, Perplexity-User, Amzn-User, MistralAI-User.

Blocking GPTBot is a training decision. Blocking OAI-SearchBot is a “do I want to show up in ChatGPT search” decision. They’re different lines in the file, and a lot of copy-paste snippets just list all of them together.

What a deliberate choice looks like

The New York Times is a good public example, because they clearly thought about it. When we ran their robots.txt through our checker on October 18, it blocked GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-SearchBot, Claude-User, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, CCBot and DuckAssistBot. It still allowed Googlebot and Bingbot.

So they stay in Google and Bing, and they opted out of the AI answer engines completely, search bots included, not only training. That’s a business decision from a company that sells its archive and has lawyers. It makes sense for them.

It probably doesn’t make sense for you. If nobody knows your product yet, an AI answer that names you is one of the cheapest bits of distribution you can get. Blocking the search bots throws that away to protect content that, honestly, no one is fighting to train on yet.

My rule for small products

Allow the search and answer bots. Always. That’s the whole point of having public pages.

Allow the user-triggered fetchers. If someone pastes your pricing page into ChatGPT to ask “is this worth it”, you want the bot to be able to read it. (These fetchers may not follow robots.txt anyway, so blocking them is mostly symbolic.)

Training bots are the only real judgment call. If you hate the idea, block those specific tokens by name and leave the rest alone. One note: Google-Extended only controls use of your content for Google’s AI models. It doesn’t change your Google Search ranking, so blocking it won’t hurt your SEO.

On our own site we allow all 23 crawlers we track, training included. We want to be cited, and we’re not precious about a tools page ending up in a dataset. You might land somewhere else on training, and that’s fine, as long as it’s a choice and not a pasted accident.

Check what your file actually does

Reading robots.txt by eye is harder than it looks. Rules are grouped by user agent, a bot uses the most specific group that matches it, and one stray “Disallow: /” under a wildcard can do more than you think.

Full disclosure, this is my tool: I built a free AI crawler checker on Posting Dude for exactly this. You paste a domain and it reads the live robots.txt, then shows each of the 23 bots as allowed or blocked, which group applied, and the exact line that decided it. No signup. It also tells you if your robots.txt is missing (that means everything is allowed) versus unreachable, which is a different problem.

Whatever you use, the check is quick:

• Is OAI-SearchBot allowed?
• Is PerplexityBot allowed?
• Is Claude-SearchBot allowed?
• Are Googlebot and Bingbot still allowed? (You’d be surprised.)

If any of the first three say blocked and you didn’t mean it, fix the file before you do anything else on “AI visibility”. It doesn’t matter how good your pages are if the bot can’t fetch them.

What robots.txt won’t do

Two honest caveats. robots.txt is voluntary. Well-behaved crawlers follow it, bad scrapers ignore it, so it’s not a security control. And allowing the bots doesn’t mean you’ll get cited. It just means you’re eligible.

Getting from eligible to actually named is a separate job. When my launch site scored 0 out of 40 on AI recall, all its SEO checks were green and nothing was blocked. The bots could read it, they just didn’t know what it was. I wrote up the fixes for that part in a longer guide on getting a small startup cited in AI answers.

And if you added an llms.txt this year, quickly check that /llms.txt on your site returns the text file and not your homepage HTML. That happens more than you’d think. We made an llms.txt checker for that too. Just keep in mind llms.txt is still a proposal, not a ranking factor. robots.txt says what bots may fetch. llms.txt says what’s worth reading. The first one matters a lot more right now.

So, a question for anyone who blocked AI bots on purpose: did you block only the training ones, or the search ones too? And was it a decision or a snippet you found?

Most launch board comparisons sort by domain rating. Uneed around DR 74, Fazier around 59, MicroLaunch around 59, and so on. Fine, that matters if you want the backlink. But it’s not the thing that usually breaks a launch plan.

What breaks it is the clock. Every board runs on its own timer, and if you don’t plan around that you end up “launching” on four sites spread over two months, with no overlap and no momentum.

Disclosure first: I run a few of these boards (Aura++, IndieHunt, MakerHunt, EarlyHunt, SideHunt) and the Best Launch Platforms site I link further down. So read the bits about my own boards with that in mind.

There are basically four clocks

Daily boards. Product Hunt, Uneed, Fazier, Aura++. You get one day on the homepage. Product Hunt resets at 12:01am Pacific, Aura++ at 8:00am UTC. One day means you have to staff it. Be in the comments, send your own people, answer the weird questions. The listing stays up afterwards, but the competitive window is that one day.

Monday weeks. IndieHunt, MakerHunt, EarlyHunt and SideHunt start a new week every Monday at 8:00am UTC, and Peerlist Launchpad is weekly too, typically Monday. Seven days on a homepage is a lot more forgiving. Your people don’t all have to show up in the same twelve hours.

Monthly. MicroLaunch runs a monthly cycle. Slow burn, not much pressure on any single day.

Instant. Spotlitely says there’s no queue at all. You submit, you’re listed. Good for a listing, not really a launch “moment”.

None of these is better than the others. They just want different things from you, mostly different amounts of your time on different days.

The queue is part of the clock

This is the part people miss. A daily board with a free queue isn’t daily for you. It’s daily for whoever got in line weeks ago.

Uneed is the clearest example. The free queue can take weeks, and skipping the line is about $29.99. So founders treat it as a $30 question: pay or don’t pay.

I think that’s the wrong question. The real cost isn’t the $30, it’s your launch date. Say you planned a proper launch week: quiet soft launch on Monday, Product Hunt on Tuesday, your newsletter on Thursday. Then your free Uneed slot lands five weeks later. Now that traffic shows up alone, after the post, after the newsletter, after you stopped sitting in the comments. If the free queue runs past your launch week, paying the ~$30 is usually cheaper than breaking the sequence.

The opposite holds too. If you don’t have a launch week and you’re just getting listed in places, take the free queue and forget about it. No reason to pay to be early to nothing.

One thing that comes up a lot: BetaList is not a free queue anymore. Their FAQ says all submissions are paid, with a full refund if you’re not selected. So don’t build a plan around a free BetaList lane.

Stack the clocks, not the days

Once you see the timers, a plan mostly falls out by itself. Use a Monday weekly as the base, because it gives you seven days of being visible while you do everything else. Put one daily board inside that week, on a day you can actually be online the whole time. Don’t put two daily boards on the same day, you can only run one comment section properly. Product Hunt and Uneed work fine on different days, one doesn’t replace the other. Monthly and instant listings can go anywhere, they don’t need you awake.

If you want the cadence, price and link notes for Uneed and ten alternatives side by side, we put them in one table in the Uneed alternatives guide on Best Launch Platforms (my site). The prices there are copied from each platform’s own page, so still check before you pay anything.

DR still matters, just read the fine print

I’m not saying ignore the backlink. Just check it on the live listing, because a lot of “dofollow” is conditional. Fazier’s dofollow is often badge-gated. Aura++ gives it on Premium. IndieHunt free listings are nofollow unless you finish top 3. MakerHunt gives it on Premium or top 3. If the link is the main reason you’re there, read the conditions the same way you’d check the queue.

And please don’t respond to all this by submitting everywhere in the same week. I wrote about why that backfires in stop submitting to 40 directories the week you launch. If you’re stuck choosing between the two daily boards people compare the most, there’s a straight Product Hunt vs Uneed comparison on the Aura++ blog.

Curious about one thing: what’s the longest you’ve waited in a free launch queue, and did the slot land anywhere near the week you actually wanted?

Nothing wrong with asking. It’s just a weak ask. It asks for a favour and gives nothing back, and it’s one message for a day that lasts twelve hours or a week.

The room is emptier than you think

I run a few launch sites (Aura++, EarlyHunt, IndieHunt, MakerHunt), so this part isn’t a guess.

Yesterday the #1 launch of the week on EarlyHunt had 2 verified upvotes, 6 clicks out to its own site and 1 comment. This morning on MakerHunt, the #1 of 22 live launches had 0 upvotes and 3 outbound clicks.

That’s not a knock on those makers. It’s just how the smaller boards look. Which means the ten people you actually bring are not a bonus on top of the launch. On a board like that, they are the launch.

Why makers don’t bring their people

We built a live stats page for makers for one reason. Makers couldn’t see what launch day actually did for them, how many visitors, how many clicks, so they didn’t bother bringing their own audience. And when nobody brings anyone, the room stays empty for everyone.

Empty rooms stay empty. A page full of zeros doesn’t make anybody want to share it.

Send three messages, not one

Here’s what I’d send instead. Same people, same list, same channels. Just spread across the day and each one gives them a reason to click.

Morning: one specific ask

Don’t ask for an upvote. Ask for one thing that takes two minutes and gives you something back. “Try the import with a real CSV and tell me where it broke.” “Tell me if the pricing page makes sense in one read.”

Put the listing link there. People who try it are the ones who end up voting and commenting anyway, and their comments are better.

Midday: the proof

This is the message almost nobody sends, and it’s the one that works best for getting a second wave. Share where things actually are, with real numbers.

On Aura++ every launch now has a public live page, like this one for Kai. IndieHunt, EarlyHunt and MakerHunt have the same page now. It shows visitors, verified upvotes, guest votes kept separate (they don’t count for the ranking), clicks out to your site, GitHub and X, and comments. There’s a copy link and Share on X / LinkedIn buttons. (Disclosure, those are my sites.)

You don’t need my page to do this. A screenshot of your own analytics works. The point is the message changes from “please help” to something like “say, 40 people came by, 9 clicked through, two asked about the team plan, here’s the thread”. That’s a story. People like checking on something that’s moving.

Only rule: share numbers you can back up. The EarlyHunt page literally says “Nothing on this page is estimated” at the top, and I think your midday post should follow the same rule.

Evening: reply, then thank by name

By evening the job is answering comments, not getting more votes. Reply to every real one, and when someone from your list left a good question, tell them you answered it.

I wrote more about turning launch-day comments into paying users, which is what that evening hour is really for.

Ask for the click, not the arrow

Upvotes decide the badge. Clicks to your site are the thing you actually wanted.

Look at the EarlyHunt numbers again: this week’s #1 there had 6 outbound clicks on 2 votes yesterday. The clicks are where signups come from. So in every message, the link you push hardest should be “go try it”, and the vote is a nice extra if they liked it.

Also, on most of these boards guest votes don’t decide anything. On EarlyHunt, IndieHunt and MakerHunt they sit pending until the voter signs in, and on Aura++ they’re capped at 3 per project. Blasting a link to 200 people who won’t sign in mostly gets you a number that doesn’t count.

A few things I wouldn’t do

Don’t send everything at 7am and go quiet. One blast at the start burns your list before anything has happened.

Don’t fake momentum. If the midday number is small, say it’s small. “Slow start, 12 visitors so far, would love one honest opinion” gets more replies than pretending.

Don’t save it all for launch day. If you did a quiet soft launch first, you already have a handful of people who used the thing. They’re the best people to get the midday update, because they have something to say.

What’s the one message you send your own people on launch day? And do you ever send a second one, or does it stop at “we’re live”?