Zenn noindex on Every Post: 8 Weeks Unnoticed

At the end of August I lined up the view counts for 49 of my Zenn articles. The median was 25. Out of 18,500 total views, the top 5 accounted for 17,304. Ninety-four percent sat in five posts, and the other 44 clustered between 1 and 69.

My first guess was that I had gotten worse at writing. Weak titles, wrong topics. The shape of the data reads that way.

It wasn’t that. The articles were not being distributed — not to search engines, not to Zenn’s own topic pages. Every one of them carried noindex, nofollow.

It took me eight weeks to notice. During those eight weeks I was snapshotting view counts and likes every single day.

A view count can’t tell “unpopular” from “undelivered”

That sentence is the whole story of the eight weeks.

When you see a post with few views, there are two readings available. It reached people and they didn’t read it, or it never reached them. A view count does not distinguish between those. Both come back as a small number.

My monitoring hit Zenn’s public API daily and accumulated per-article like counts. Views I collected by hand. From that I aggregated which topics landed and picked the next ones. As instrumentation, it’s coherent.

What it did was assume delivery. When that assumption broke, the metric didn’t report a broken assumption. It reported “unpopular.”

Another number from the same period makes the shape clearer. In a snapshot from June 12, articles 0–30 days old had a median of 108 views, and 31–60 days old had 71. Today, at the same ages, it’s 25 to 27. A drop of three to four times.

And the topics I was strongest in fell hardest.

Topic	Through 6/12 (median)	July–Aug (median)
graphrag	583	16
knowledge graph	452	16
rag	452	33
claudecode	142	26

The strongest topic collapsed the most. Topic selection doesn’t produce that shape.

Measuring it

I pulled the HTML and read meta name="robots".

status: published
shouldNoindex: true
<meta name="robots" content="noindex, nofollow">

Published, and refusing search engines.

I nearly got this wrong. I opened one article from another author, and it carried the same noindex, nofollow. For a moment I read that as “this is just how Zenn works.”

It wasn’t. I had gone after 164 URLs with six workers in parallel, Cloudflare had rate-limited me, and what I was reading was not an article. It was a block page. Block pages carry noindex. The document.title said Access denied | zenn.dev used Cloudflare.

I waited 55 minutes for the limit to lift and measured again, same procedure, 25 seconds apart.

Target	robots	shouldNoindex
Four other authors	(none)	false
My 5 articles (Apr 4, May 20, Jul 4, Jul 10, Aug 18)	noindex, nofollow	true
My 2 Zenn Books	noindex, nofollow	true
My profile page	(none)	—

All of them status: published.

Three things I hadn’t expected.

One. It applies retroactively. The May 20 article earned 22,403 views and 312 likes. It was plainly indexed at the time. It is noindex now. If the decision were made per-article at publish time, this wouldn’t be the shape. It was applied later, in bulk.

Two. Zenn Books are included. Not just articles. My Zenn Books doubled as the path to the Kindle editions, so that path went dark at the same time.

Three. The profile page is untouched. /kenimo49 indexes normally. The account stays; only the content leaves circulation. What’s being stopped isn’t the person.

There’s corroborating evidence. The llmo topic page holds 27 articles across its entire history. None of my three llmo articles are among them. I’m out of Zenn’s own listings, not just out of search.

This is not a shadowban

The word comes to mind, and most of the conditions are met.

Shadowban criterion	Here
Author isn’t notified	Yes. No notice, no email
Looks normal to the author	Yes. Still published, likes still arrive
Only distribution stops	Yes
Designed to be undetectable	No

The last one breaks it.

A shadowban’s design goal is that you can’t detect it. Here the opposite is true: the evidence is sitting in public HTML. Any reader can hit “view source” and find the meta robots tag, and Next.js’s __NEXT_DATA__ carries it under the name shouldNoindex, which states the intent outright. Nothing about it is concealed.

So it was never hidden. It simply wasn’t announced.

I checked Zenn’s own documents. The terms of service list “suspension, restriction of viewing, or deletion of content” as available measures. The AI content policy lists “measures including account suspension” and “a per-user cap on posts per period.” Nowhere is noindex named as a measure.

I think the design is rather good. Suspend an account and you get an argument. Delete the posts and the absence is visible to everyone. With noindex, the content stays, the URLs stay, followers still get it. Only new inflow stops. It cuts at exactly the point with the least friction.

From the author’s side, though, it looks like this. Nothing is said, and the numbers quietly slide. You look for the cause in your writing, change titles, change topics, and nothing comes back. I did that for eight weeks.

Why it took eight weeks

Sorting out my own share of it, there were two causes.

First, I was measuring the wrong layer. I measured how things were read. What I needed was the step before that: whether they were being delivered. Readership metrics only mean something while distribution is intact. When the assumption fails, the metric doesn’t report the failure — it reports a result.

Second, I had built detection without a way to stop anything.

My monitoring included a self-audit for title-pattern skew. It was running. It was emitting “title pattern is saturated: 52% (threshold 40%).” The detection was correct.

The generation side had no branch for it. The notification pointed at a human, not at the running system. So the same pattern kept shipping for eight weeks.

For reference, here’s what the skew actually looked like.

Metric	Measured
Publishing interval	42 of 48 gaps were exactly one day
Body length	Mean 6,572 chars, SD 1,118 (44 of 49 between 5,000 and 8,000)
Images	37 of 49 had exactly one
Title pattern	Feb–Jun 0–11% → July 43% → August 62% the same pattern

My Zenn posts were existing articles lightly reworked from the content of my own books, published by an automated pipeline. Seven a week, one a day. The numbers above are its footprint. Zenn’s terms prohibit “posting text generated automatically by machine” as spam. Zenn has an LLM sweep posts and file violation reports, and says its own staff then “check the report against the actual content” before deciding whether it really is spam.

I can’t establish causation. I haven’t contacted them, so I don’t know what they looked at. There’s also no other change that explains the data.

And even if the cause was the volume of generated posts, that doesn’t explain the eight weeks. Those are two separate failures.

If you go measure this yourself

Two implementation notes for anyone checking their own properties.

Block pages carry noindex themselves. That’s the trap above. Rate limits, Cloudflare challenges, 404 pages — most of them return noindex. Read the meta tag naively and, from the moment you get blocked, every page you measure looks noindexed. The error runs the other way too: you dismiss a real noindex as “probably just the block.”

So before reading robots, decide whether the page you got back is real. Drop responses containing block fingerprints (Access denied, used Cloudflare, Just a moment...). Drop responses whose body is implausibly short. Don’t record a dropped URL as noindexed or as clean — count it separately as unmeasurable. If everything is unmeasurable, don’t emit “no problems found.” Emit “couldn’t measure.”

Take a control through the same procedure. Measuring only your own articles can’t tell you whether it’s platform-wide behavior or specific to you. Fetch another author’s article with the same user agent, the same spacing, in the same run. I split the verdict three ways: only mine is noindexed means it’s specific to me; the control is noindexed too means suspect platform behavior or my own measurement first; the control couldn’t be fetched means warn, but state plainly that the question is unresolved.

You need that third branch. Silently concluding “specific to me” when the control failed is how I almost published a wrong conclusion off a block page.

What I changed

I added a layer to the monitoring that records robots on every run. It measures a handful of recent articles alongside one article from another author and appends to a history file. If noindex appears, I get a notification. The same mechanism will tell me when it lifts.

On the posting side, I cut from seven articles a week to two, and stopped publishing on consecutive days — now every third day. I also added a check that compares each draft against the last five posts on title pattern, closing heading, length, and image count, and blocks publication when they line up too well. Unlike the earlier self-audit, this one stops.

None of that is a reason to expect recovery. Cutting volume is a fix for not getting flagged again. It is not a fix for a flag that’s already set. There’s no lever on my side. shouldNoindex is returned by Zenn’s server, there’s no corresponding field in the article frontmatter, and pushing the repository changes nothing.

I also couldn’t find a single public report of the same symptom, and there’s no documented appeals process. The remaining path is the contact form.

Are you measuring that your work is being delivered?

The most useful thing here wasn’t finding the noindex. It was finding out what my own instrumentation had never been looking at.

Dashboard numbers mostly report outcomes. Views, clicks, likes. All of those describe what happens after arrival. Whether the thing arrived is a separate measurement. And when it doesn’t arrive, the outcome metrics don’t go quiet. They return small numbers.

It isn’t much work. Fetch the HTML of one of your own posts and read meta name="robots". That’s it. I went eight weeks without doing it.