AIで増やした記事は、証拠が揃うまで検索に出さない

「53本あるなら、さすがに少なくはないでしょう」

一瞬、そう思いたくなった。

でも昨日の棚卸しで、そこを信用してはいけないと分かった。

サイトには攻略ガイドが53本あった。

文字数も少なすぎるわけではなかった。

台帳には、本文量の中央値が約6,034字だったと残っている。

それでも、検索や広告の対象として残せたのは2本だけだった。

残り51本は、本文とURLを消さずに noindex,follow にした。

タグ39ページも検索対象から外した。

数字だけ見ると、かなり強い処置に見える。

でも、これは削除ではない。

証拠が足りない記事を、読者に強く見せすぎないための保留だった。

AIで記事を増やすと、ページ数はすぐ増える。

見出しも、手順も、比較表も作れる。

ただ、そこに自分の実測、画面、ログ、判断の記録が入っていなければ、ただのよくできた一般論になる。

今日の記事は、ガイドの中身を紹介する話ではない。

増えた記事をどう止めるか。

検索に出す条件を、どうルール化するか。

そこを1回、作業ログからほどいておく。

53本あっても、薄いものは薄い

最初に見た数字は、少なくなかった。

攻略ガイドは53本。

タグページは39本。

サイト記事数の計器盤も90まで増えていた。

ここだけ見ると、ちゃんと積み上がっているように見える。

でも、コンテンツの価値は本数では測れない。

今回の台帳には、問題がかなりはっきり書かれていた。

• 外部情報を整理した一般解説が多い
• 同じ検索意図の記事が近接している
• 自分の実測と第三者情報が混ざって見える
• 「正直に評価」「完全手順」のような言葉が、一次性の代わりになっていない

これは、AIを使って記事を増やすと起きやすい。

AIは、一般的な説明を整えるのがうまい。

だから、見た目だけなら読める記事ができる。

でも、読めることと、検索から来た人に出していいことは別だ。

「長い記事」でも、自分で見た画面や失敗ログがなければ、薄い記事になる。

今回、残せた2本はどちらも理由があった。

1本は、LステップとUTAGEを解約した導入判断の記録。

もう1本は、設定画面の記録を含む初期設定の確認記事。

つまり、強かったのは文章のうまさではない。

「自分の条件で何を見たか」が残っていることだった。

ここを見ずに、記事数だけを見ていたら危なかった。

53本あるから大丈夫、ではない。

53本あるからこそ、証拠のないものが混ざる。

AIで増やした棚は、増えたあとに一度、検索へ出していい棚と保留棚に分け直す必要がある。

残す条件を4項目にした

今回の中間物でいちばん効いていたのは、再indexの条件を曖昧にしなかったことだ。

台帳には、再indexには次の4項目を登録すると残っている。

• evidence_type
• verification_date
• scope
• observed_result

日本語にすると、こうなる。

• どんな証拠か
• いつ確認したか
• どこまで確認したか
• 何が観測できたか

この4つがない記事は、検索対象に戻さない。

ここを決めたのが大きい。

なぜなら、「あとで直す」はだいたい直らないからだ。

人間もAIも、本文を読んでいるとつい言葉を直したくなる。

言い回しを柔らかくする。

見出しを強くする。

古い表現を削る。

もちろん、それも必要だ。

でも、今回の問題は言葉の表面ではなかった。

証拠がないまま、説明だけがきれいになっていることが問題だった。

だから、直す順番も変えた。

先に文章を磨かない。

先に証拠を集める。

LINE Harnessなら、エラー画面、設定箇所、修正後の成功確認。

Cursor日本語化なら、設定ファイル、再起動後の画面、失敗状態と復旧後。

料金記事なら、確認日、入力条件、実際の請求または上限画面。

この素材が揃ってから、記事に戻す。

逆に言えば、素材が揃うまでは、どれだけ文章が整っていても検索には出さない。

これは少し冷たいルールに見える。

でも、AI運用ではこのくらい冷たくしないと、良さそうな記事がどんどん増える。

良さそうな記事ほど、あとで人間が見逃す。

noindexは削除ではなく保留

今回、私は削除をしていない。

ここは大事だと思う。

残り51本のガイドは、URLも本文も保存した。

ただし、noindex,follow にした。

広告コードも外した。

sitemapや一覧からも外した。

つまり、読めなくしたのではなく、強く見せないようにした。

この差は大きい。

削除は、履歴まで消す。

保留は、次に証拠を足して戻せる。

今回の台帳にも、次の証拠収集順が残っている。

1. LINE Harnessのエラー系
2. Cursor日本語化
3. 実際に契約・利用したサービス
4. ニュース・発表の要約だけの記事

この順番があるなら、保留は前向きな状態になる。

「見えないところへ捨てた」のではない。

「戻す条件つきで置いた」になる。

AIで作った記事を直す時、いきなり消すより、まず公開面から外して証拠待ちにする。

この運用は、初心者にもかなり使いやすいと思う。

ブログでも、noteでも、LPでも同じだ。

書いたものを全部消す必要はない。

でも、検索・広告・トップページ・おすすめ欄に出すかどうかは分けていい。

自分の体験が入っているものは表に出す。

一般論のままのものは、下書きではなく保留記事として残す。

そして、保留を戻す時だけ条件を厳しくする。

このほうが、作った努力も、読者への誠実さも残せる。

次からは証拠が先、文章は後

今日のルールは、かなり単純にできる。

AIに記事を書かせる前に、証拠の箱を先に作る。

箱に入れるものは4つ。

• 証拠の種類
• 確認日
• 確認した範囲
• 観測した結果

この4つが空なら、記事は公開しない。

公開済みの記事でも、4つを後から埋められないなら、検索からは外す。

ここまで決めておくと、AIへの頼み方も変わる。

「このテーマでSEO記事を書いて」ではなくなる。

「この画面、ログ、確認日、結果をもとに、初心者向けに説明して」になる。

この差は大きい。

前者は、AIが一般論を拾ってくる。

後者は、AIが自分の証拠を読者向けに翻訳する。

私が欲しいのは後者だ。

AIで記事を増やすこと自体は悪くない。

むしろ、運用ログや失敗記録を読める形にするには、かなり助かる。

でも、増やすほど止めるルールが必要になる。

今回の53本棚卸しで、その線が少しはっきりした。

次にガイドやログを増やす時は、本文の前に証拠レコードを見る。

4項目が揃っていれば書く。

揃っていなければ、先に検証する。

AI記事は、文章から始めない。証拠の箱が埋まってから、読者の言葉に直す。