Zenn全記事noindex、気づくまで8週間

8月の終わりに、Zenn の記事のビュー数を49本ぶん並べて眺めていました。中央値は25でした。合計18,500ビューのうち、上位5本で17,304。94%が5本に集まっていて、残り44本は1から69の帯に固まっていました。

最初は書き方の問題を疑いました。タイトルが弱いのか、テーマがずれたのか。実際、そう読める形をしています。

違いました。記事は検索エンジンにもZenn内のトピックページにも配信されていませんでした。全記事に noindex, nofollow が付いていました。

気づくまで8週間かかりました。その間、私は毎日ビュー数といいね数をスナップショットしていました。

数字は「不人気」と「未配信」を同じ顔で返す

これが8週間の正体です。

ビューが少ない記事を見たとき、そこから読める話は2つあります。届いたけれど読まれなかったのか、そもそも届いていないのか。ビュー数という指標は、この2つを区別しません。 どちらも小さい数字として出てきます。

私が回している観測は、毎日 Zenn の公開APIを叩いて、記事ごとのいいね数を蓄積するものでした。ビューは手で拾っていました。そこから「どのテーマが当たったか」を集計して、次に書くテーマを決める。指標としては筋が通っています。

ただ、この設計は記事が配信されていることを前提に置いていました。前提が崩れたとき、指標は崩れたと言わずに「不人気」と言います。

同じ時期の別の数字を見ると、崩れ方がはっきりします。6月12日時点のスナップショットでは、公開から0〜30日の記事のビュー中央値は108、31〜60日は71ありました。いまは同じ経過日数で25から27です。3倍から4倍落ちています。

しかも、得意にしていたテーマほど激しく落ちていました。

トピック	6/12まで（中央値）	7-8月（中央値）
graphrag	583	16
ナレッジグラフ	452	16
rag	452	33
claudecode	142	26

一番強かったトピックが一番落ちている。テーマの当たり外れではこの形になりません。

実際に測る

記事のHTMLを取って meta name="robots" を読みました。

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

公開済みなのに、検索エンジンに拒否を返しています。

ここで一度、間違いかけました。他人の記事を1本開いたら、そちらにも同じ noindex, nofollow が付いていたのです。Zennの仕様なのだと読みかけました。

そうではありませんでした。並列で164本取りに行ったせいでCloudflareに弾かれていて、私が読んでいたのは記事のHTMLではありませんでした。ブロックページです。ブロックページには noindex が入っています。document.title を見たら Access denied | zenn.dev used Cloudflare でした。

レート制限が解けるのを55分待って、同じ手順・25秒間隔で測り直しました。

対象	robots	shouldNoindex
他ユーザー4名	（なし）	false
自分の記事5本（4/4・5/20・7/4・7/10・8/18）	noindex, nofollow	true
自分のZenn Book 2冊	noindex, nofollow	true
自分のプロフィールページ	（なし）	—

全部 status: published です。

3つ、想定していなかったことがありました。

1つ目。過去に遡っています。 5月20日の記事は22,403ビュー、312いいねを取ったものです。当時は明らかにインデックスされていました。それが今はnoindexです。公開時点で1本ずつ判定していたなら、この形にはなりません。後からまとめて付いたと読むしかありません。

2つ目。Zenn Bookも対象です。 記事だけの話ではありませんでした。私の場合、Zenn Book は Kindle 版への導線でもあったので、そこも同時に切れていたことになります。

3つ目。プロフィールページだけ無傷です。 /kenimo49 は普通にインデックスされています。アカウントは消さずに、コンテンツだけを流通から外しています。止めているのは人格のほうではありません。

傍証もあります。llmo というトピックページは全期間で27件しか記事がありません。そこに私のllmo記事3本が1本も入っていません。検索だけでなく、Zenn内の一覧からも外れています。

これはシャドウバンではありません

シャドウバンという言葉が浮かびます。実際、条件の多くは揃っています。

シャドウバンの要件	今回
著者に通知されない	該当。通知もメールも来ていません
著者の画面では正常に見える	該当。published のまま、いいねも付きます
配信だけが止まる	該当
本人に気づかせない	非該当

最後の1つが違います。

シャドウバンは、検出できないことが設計目標です。今回は逆で、証拠が公開のHTMLに書いてあります。meta robots はブラウザの「ページのソースを表示」で誰でも読めますし、Next.js の __NEXT_DATA__ には shouldNoindex という、意図がそのまま読める名前で入っています。隠す気配がありません。

つまり、隠されてはいませんでした。告知されなかっただけです。

Zennの公式文書も確認しました。利用規約は措置として「コンテンツの公開停止、閲覧制限もしくは削除」を挙げています。AIコンテンツに関する方針では「アカウントの凍結を含む措置」と「ユーザーごとに期間あたりの投稿上限数」が挙がっています。noindex を措置として名指ししている記述は、どこにもありません。

私はこの設計を、けっこう良くできていると思っています。凍結すれば揉めます。削除すれば消えたことが誰の目にも見えます。noindexなら、コンテンツは残り、URLも生き、著者のフォロワーには届く。止まるのは新規の流入だけです。もっとも摩擦が少ない場所を正確に切っています。

ただし、著者側から見るとこうなります。何も言われないまま、数字だけが静かに落ちていく。原因を書き方に求めて、タイトルを変え、テーマを変え、それでも戻らない。私は8週間そうしていました。

なぜ8週間かかったのか

自分の側の問題として整理すると、原因は2つでした。

1つ目は、測っている対象がずれていたことです。 私が測っていたのは「読まれ方」でした。測るべきだったのは、その手前の「配信されているか」です。読まれ方の指標は、配信が生きている前提でしか意味を持ちません。前提が崩れたとき、指標は前提の崩壊を教えてくれず、結果だけを返します。

2つ目は、検知しても止める側を作っていなかったことです。

私の観測には、タイトルの型が偏っていないかを見る自己監査が入っていました。実際に動いていて、「タイトル型が飽和しています。52%（閾値40%）」と通知を出していました。正しく検知していたのです。

それでも、記事を生成する側には何の分岐もありませんでした。通知は人間に向いていて、実行系には向いていませんでした。 だから同じ型の記事が8週間出続けました。

ちなみに、その偏りは実測でこうなっていました。

指標	実測
公開間隔	48区間中42がきっかり1日
本文字数	平均6,572字・標準偏差1,118（44/49が5,000〜8,000字）
画像	37/49がちょうど1枚
タイトル型	2〜6月は0〜11% → 7月43% → 8月62%が同じ型

私のZenn投稿は、自分の本の内容から少し改善した既存記事を、自動化されたパイプラインで公開していました。週7本、毎日です。上の数字は、その足跡です。Zennの利用規約は「機械により自動生成された文章の投稿」をスパムとして禁止しています。運営はLLMにスパムを自動検出させていて、検出後は「違反報告と実際のコンテンツを運営メンバーが確認し、本当にスパム投稿かどうか確認します」と自ら書いています。

因果は確定できません。問い合わせていないので、Zennが何を見て判断したかは分かりません。ただ、他に説明できる変化がないのも事実です。

そして、原因が仮に自動生成の量だったとして、8週間気づかなかったことの説明にはなりません。そこは分けて考える必要があります。

測るときに気をつけること

同じことを自分の媒体で調べる人のために、実装上の注意を2つ書いておきます。

ブロックページ自体が noindex を持っています。 上で踏んだ罠です。レート制限、Cloudflareのチャレンジ、404ページ。どれもたいてい noindex を返します。素朴に meta を読むと、弾かれた瞬間から測定値が全ページnoindexに化けます。逆向きの誤りも起きて、本物のnoindexを「ブロックのせいだろう」と退けてしまいます。

なので、robotsを読む前に返ってきたページが本物かを判定します。ブロックの指紋（Access denied / used Cloudflare / Just a moment...）を含む応答は捨てる。本文が短すぎる応答も捨てる。捨てたURLは「noindexだった」とも「noindexでなかった」とも記録せず、計測不能として別に数える。全件計測不能なら、「異常なし」とは出さない。「測れませんでした」と出す。

対照を同じ手順で取ります。 自分の記事だけを測っても、それがプラットフォーム全体の挙動なのか自分固有なのかは分かりません。他ユーザーの記事を、同じUA・同じ間隔・同じ順序で測って比べます。私の場合、判定を3つに分けました。自分だけnoindexなら固有、対照も同じならサイト全体か計測側の問題、対照が取れなかったなら警告は出しつつ切り分けができていないことを明記する。

3つ目が要ります。対照が取れなかったときに黙って「固有」と結論すると、今回の私のように、ブロックページを根拠に間違った断定をします。

何を足したか

観測に、robotsを毎回記録する層を足しました。直近の記事を数本、他ユーザー1本と一緒に測って履歴に残します。noindexが付いたら通知が飛びます。外れたときも同じ仕組みで分かります。

投稿の側は、頻度を週7本から週2本に落として、連日をやめて3日おきにしました。それと、下書き1本ごとにタイトルの型・締めの見出し・字数・画像枚数を直近5本と比較する検査を入れて、揃いすぎていたら公開を止めるようにしました。さきほどの自己監査と違って、ここは止まります。

これで元に戻る根拠はありません。減量は「また付けられない」ための手当てであって、すでに付いているものを外す手当てではありません。 外す手段は、こちら側にはありません。shouldNoindex はZennのサーバーが返す値で、記事のfrontmatterに該当する項目はなく、リポジトリを何度pushしても変わりません。

同じ症状の報告も、探した範囲では公開の場に見つかりませんでした。異議申し立てのプロセスも文書化されていません。残っている道は問い合わせフォームだけです。

自分の媒体で、届いていることを測っていますか

この件で一番効いたのは、noindexの発見そのものよりも、自分の観測が何を見ていなかったかが分かったことでした。

ダッシュボードの数字は、たいてい結果を返します。ビュー、クリック、いいね。それらは全部「届いた後」の話です。届いているかどうかは、別に測らないと分かりません。そして届いていないとき、結果の指標は沈黙せず、小さい数字を返します。

やることは大きくありません。自分の記事のHTMLを1本取って、meta name="robots" を読む。それだけです。私の場合、それを8週間やっていませんでした。