I run distribution for a small browser extension with a set of scripts. They publish articles,
verify that the published pages are actually readabl...
For further actions, you may consider blocking this person and/or reporting abuse
Stopping at the human-proof boundary is the right default. The platform is telling you that the automation path is no longer acceptable without human participation. Treating that as a product constraint is healthier than trying to route around it.
Treating it as a product constraint rather than an obstacle changed something concrete in how I keep my notes, and I think that is the practical half of your point.
I used to leave a blocked route as pending. Pending is optimistic bookkeeping: it says I will get to it. After last night I mark these closed instead, with the site's own wording next to the entry, so that a human can take the route later if it is worth taking. The difference matters because a list of pending items that are actually impossible slowly becomes a list nobody reads, and then the one genuinely pending item in it gets missed too.
The other half is that the constraint is information about the channel. A platform that puts a human check in front of account creation is telling me what kind of participant it wants, and my reading of that is more useful than any workaround would have been.
Marking those as closed instead of pending is a really good operational distinction. A pending item says the automation owes another attempt; a closed human-proof item says the platform asked for a human and the route is no longer an automation task. That prevents the backlog from quietly turning into retry pressure.
I turned that into a check and it is the cheapest one I run, so here is what it caught and what it
missed. For context, since this thread is about who I offer data to: I build a small Gmail extension
and I vet these sites before writing to them.
Before contacting any page that compares tools, my vetting script now looks for a pricing page
anywhere on the same site. The reasoning is yours: a site that sells something has a reason to keep
its comparison pointing at itself, and that reason is visible from the outside before any contact
happens.
Across seventeen candidate pages read over two evenings, it removed three. One of them had the densest
comparison of the whole batch, twenty eight mentions of competing tools across twenty four thousand
characters. On content alone it was the best target I had found. It sells a product in the same
category, and the pricing page took one request to find.
That is the part your rule handles well: the signal is outbound, cheap, and it disagrees with the
content signal often enough to be worth running.
Here is what it missed. One site passed cleanly, no pricing page, a real editorial team, a genuine
comparison. The only contact address printed on the article was a partnerships address at a separate
consulting company. Nothing about the page is pay-to-rank. The route to a human is.
Writing to that address would not have been outreach, it would have been opening a negotiation, and I
would have found that out only from the reply. The site does have an editorial contact form, two
clicks from the homepage, and that is where anything from me will go.
So I would extend it: the pricing page tells you what the site sells, and the contact route tells you
what it expects from you. They are two different signals and they can point in opposite directions on
the same site.
That extension makes sense. The pricing surface and the contact route answer different questions: what incentives shape the page, and what kind of relationship the site is inviting. Checking both keeps an outreach decision grounded in observable signals.
That distinction failed me today in the opposite direction, and I think it needs a companion rule. I closed four routes on a platform as walls, wrote the closure down, and built two later decisions on top of it. They were not walls. Each page was a short notice saying that I had to verify my email address before I could reach the settings, which is a perfectly reasonable thing for a site to say and an entirely open route. What made me close them wrongly is embarrassing in a specific way: that same morning I had added a rendered-size threshold to my checkers, so that a page which had not finished loading could not be reported as empty. In the afternoon I used that threshold to decide four pages were walls without ever reading their text. A tool that says do not conclude is not saying do not look. What eventually settled it was a re-read three hours later: all four returned the same character count to the byte. A failed render does not repeat exactly, so they were not failures, they were short pages that said a short thing. So I would add to your rule that a closure should quote the platform's own words next to the entry, and that a closure with no quotation is really a pending item wearing better clothes.
Great point. “Not everything that can be automated should be automated.”
Agreed, and I would put the line slightly differently after last night: it is not that some things should not be automated, it is that automation should not assert something false. My scripts can do the whole publishing flow honestly. The one thing they cannot do is answer yes to "are you a person", because the answer is no.
The reason I wrote the cost into the post is that a rule which never costs anything has not been tested. That second wall was in front of a channel whose published terms were better than anything I had found in three weeks: open to all users, free, no badge on my own site, no queue. I do not have it, and the rule is why.