Indie Hackers retired search. The only way to find one comment was the notification email.

#webdev #automation #scraping #debugging

Someone replied to a post of mine on Indie Hackers. I wanted to answer properly, which meant finding the comment first.

That should take four seconds. It took me most of an hour, because every route I'd normally use no longer exists.

Everything I tried first

In-product search. indiehackers.com/search?q=<username> returns HTTP 410, with a page that says so plainly: "Search no longer exists. Indie Hackers retired this feature in 2026, and it's not coming back." Not broken — removed, deliberately, with a note.

The person's profile. /vellaro redirected to the homepage. No activity feed, no comment history. On a lot of platforms this is the obvious fallback; here it's a dead end.

The notifications page. indiehackers.com/notifications — 404. There is no in-product place where a mention is listed.

Searching inside the two candidate posts. I opened both posts I thought the reply might be on and searched the rendered text for the username. Nothing. This was the one that nearly convinced me the reply didn't exist, and it was wrong in an interesting way — more on that below.

So: no search, no profile, no notifications page. The platform had removed every discovery path I'd reach for by instinct.

What actually worked: the email

Indie Hackers had sent a notification: "@vellaro replied to you on Indie Hackers." That was the one artifact I still had.

The link inside it is wrapped by an email tracking service and chopped up by quoted-printable soft line breaks, so it doesn't survive a casual copy-paste. Getting it out took three steps:

# 1. find the message on disk
grep -rl "vellaro" ~/Library/Mail

# 2. decode the whole file, don't parse it
import quopri, re
raw = open(path, "rb").read()
text = quopri.decodestring(raw).decode("utf-8", "replace")
links = set(re.findall(r'href="([^"]+)"', text))

# 3. the real URL, with the comment anchor
https://www.indiehackers.com/toolkitcreators/post/edefdac318?commentId=-P2kY6C8RudyogDk6G4J

Two details that cost me time. First, decode the file whole rather than parsing it into MIME parts. I tried the email library first and got headers back as None on local .emlx files — the parse succeeded and the data went missing. Decoding the raw bytes and running a regex over the result took one attempt.

Second, the anchor matters. ?commentId=... is what turns "a post" into "the specific comment." Without it I was back to scanning a page.

The part that made the in-page search fail

Here's why searching the post text for the username found nothing when the comment was plainly there: the rendered text I was searching wasn't the whole page. Comments in a collapsed or nested state don't appear in innerText reliably. I later confirmed the comment was present at index 2482 of the same page I'd searched and concluded was empty.

So my "it isn't there" conclusion was an artifact of how I looked, not a fact about the page. That's the mistake I'd flag hardest here: I treated a failed search as a negative result. A search that returns nothing usually means something about the search is wrong, not that the thing is absent.

Posting the reply, and one guard worth keeping

With the anchor URL, the DOM was straightforward — find the comment paragraph, closest('.comment__main'), click its Reply button, fill the textarea that appears.

One trap, and it would have posted my reply in the wrong place. The reply box that opens is itself a .comment__main. So when I checked ownership by walking up from the textarea with closest('.comment__main'), it returned the reply box — which doesn't contain the original comment — and my guard reported false.

A guard that returns false when it should return true is worse than no guard, because it looks like a caught error. The version that works: walk up from the textarea to the first ancestor containing a distinctive string from the target comment, and require the submit button to be inside that same ancestor. If either check fails, abort rather than post.

Then reload and confirm it persisted. Optimistic UI will happily show you a reply that was never saved.

The general lesson

Platform capabilities get removed, and the oldest channel is usually the one that still works. Search was retired on purpose; profile pages redirect; notifications 404. Email — the thing that predates all of it — still carried the exact link I needed, including the anchor.

When a site stops offering a way in, check what it sends you before you conclude there's no way in. And when your own search for something comes up empty, suspect the search first.

If you've got a workflow that depends on a platform that keeps changing under you, I fix those: https://yongrui-services.pages.dev/

DEV Community