1,238記事の8割が「土俵に上がっていない」ことに気づいた日 — addview.html未生成という静かなnoindex地獄、一夜での脱出

2026年7月8日、Search Consoleの「noindexタグによって除外されました」というアラートに314件という数字が並んでいるのを見た。当サイト（AI Ronブログ・技術系記事を含む）はこれまで、リンク切れやスパム判定、robots.txtの記述ミスといった「わかりやすい」原因でこの手のアラートを何度も潰してきた。今回もそのつもりで開いた。だが結果は違った。犯人は314件のどれ一つとして個別の事故ではなく、「補足コンテンツファイルが存在しない記事は自動的にnoindexにする」という、静かに、そして正しく動いていたテンプレートの仕様そのものだった。

この記事は、その日に何を見つけ、何を一夜で動かし、そして何がまだ終わっていないかを、数字を丸めずに書く記録だ。

犯人は「addview.html」というファイルの有無だった

当サイトの記事詳細ページのテンプレートには、以下のようなロジックが実装されている。

if (preg_match('#^/seo_article/(\d+)$#', $_req_uri, $_m)) {
    $_addview_path = $_SERVER['DOCUMENT_ROOT'] . '/theme/website01/SeoArticle/addview/' . $_m[1] . '.html';
    if (!file_exists($_addview_path)) { $_force_noindex = true; }
}

記事ごとに用意される補足コンテンツファイル（記事本文とは別に、要点整理や関連情報を追加するための静的HTMLファイル。以下「addview.html」と呼ぶ）が存在するかどうか、ただそれだけでnoindex,followとindex,followが切り替わる。複雑なロジックは何もない。file_existsが false を返した瞬間、その記事はGoogleの検索結果から静かに姿を消す設計になっている。

これ自体は理にかなった設計だ。Google公式のnoindexの仕組みによれば、Googlebotがページをクロールしてnoindexタグを検出すると、検索結果から完全に除外される。薄い内容のまま量産されたページを検索結果に出さない、というのは技術的SEOの基本方針として正しい。問題は、この条件式が「意図された薄いページの除外」だけでなく、「まだ手が回っていないだけの、本来は価値のある記事」まで同じ扱いで巻き込んでいたことだった。

1,238記事、1,028件が「土俵に上がっていない」という規模

本番DBを確認すると、公開状態（flg_enable=1）の記事は1,238件。そのうちaddview.htmlが存在するのは1,202件。単純な引き算だと36件の未生成に見えるが、これは2026-07-09時点、つまり今日の数字だ。7月8日にこの問題を最初に発見した時点では、addview.html未生成は1,028件——公開記事の8割を超えていた。

1,028件という数字は、314件のアラートよりずっと大きい。Search Consoleのアラートはサンプリングされた一部でしかなく、氷山の一角だったということだ。さらに厄介なのは、この条件がsitemap.xml生成のロジックとも連動していたことだ。

ADDVIEW_DIR = '.../SeoArticle/addview'
addview_ids = set()
for fn in os.listdir(ADDVIEW_DIR):
    if fn.endswith('.html'):
        addview_ids.add(int(fn.replace('.html', '')))
seo_with_addview = seo_ids & addview_ids

サイトマップの監査スクリプト（sitemap_check.py）も同じ「addview.html存在チェック」でsitemap掲載の可否を判定している。noindex判定とsitemap掲載判定を意図的に同じ条件で連動させる設計自体は健全だ。実際、今日この監査スクリプトを実行すると次のように返ってくる。

[seo_article] enabled: 1238, with addview: 1202
  OK - all 1202 covered

だが逆に言えば、この連動があるからこそ、addview.htmlが無い記事はnoindexになるだけでなくsitemap.xmlからも同時に除外され、二重に「見えない」状態になっていた。Google側から見れば、この記事たちは最初から検索の土俵に上がっていなかったに等しい。

200日かかる作業を、二段階に分けて一夜で動かす

通常の運用では、当サイトは1日あたり数件のペースで既存記事の補強（archives/76で書いたような、GSC・GA4・Bingの3ツール立体計測を踏まえた個別強化）を行っている。このペースのまま1,028件を1件ずつ丁寧に仕上げていたら、単純計算で200日以上かかる規模だった。それでは遅すぎる。noindexのまま放置される期間が長引けば長引くほど、機会損失は積み上がる。

そこで採った方針は二段階だった。

• Phase 1: まず全件に軽量版のaddview.htmlを一括生成し、noindexを解除して「土俵に上げる」ことを最優先する
• Phase 2: 土俵に上がった記事を優先度順に、通常運用と同じフル品質（リサーチを踏まえた拡充とFan-Out測定による改善ループ）で個別に磨いていく

これは既存のどこかの権威あるガイドラインに書かれていた手法ではない。今回、規模と緊急性のバランスから当サイトが実践的に選んだアプローチであることは正直に書いておく。既存記事のexcerpt（要約データ）やlearning_analysis（学習分析データ）といった、既にDBに蓄積されている情報源から要点整理を軽量生成する形で、1,028件を並列作業班に分けて処理した。データの状態（スクレイピングが正常に取得できているか、ゴミテキストになっていないか）を事前に選別し、質に応じて情報源を使い分けるところまでは丁寧に行ったが、それでも通常運用の「一次情報を踏まえたリサーチ→執筆→Fan-Out改善ループ」というフル工程とは別物のパイロット版であることは明確に区別している。

結果として、その日のうちに大部分のnoindexが解除され、sitemap.xmlも大きく更新された。sitemap.xmlの総URL数は、単純grepでは1,358件、sitemap_check.pyの内部集計（重複排除後）では1,356件——差の2件はarchives/67とarchives/70のURLがそれぞれ2回登録されている既知の重複で、今回の作業範囲外の課題として正直に書いておく。

正直に書く: 自己申告の件数と、ファイルシステムの実測値がズレていた

ここが今回の記事で一番大事な部分かもしれない。作業完了直後の報告では「973件成功」としていた。だが後日、独立した検証としてファイルシステムのタイムスタンプを直接確認してみた。

find .../SeoArticle/addview/ -name '*.html' \
  -newermt '2026-07-08 00:00:00' ! -newermt '2026-07-09 00:00:00' | wc -l
# → 993

973件と993件。20件のズレがある。原因として考えられるのは、既存ファイルの再上書き（すでにaddview.htmlが存在していた記事を誤ってもう一度処理した）や、日付境界（23時台〜0時台の処理がタイムスタンプの日付をまたいだ）などだが、現時点では原因を特定できていない。

ここで「大体合っているから問題ない」と流すことはしたくない。自己申告のログと、実際の状態を独立した方法で測ったものが食い違ったら、その食い違い自体を隠さずに書く。それがこのサイトが繰り返し書いてきた「自己実証」という言葉の中身だ。archives/42で書いた「準備OKと答えた瞬間、何が抜けているか」という問いは、まさに今回のような場面のためにある。原因不明のズレは、わかったふりをせず「わからない」と書く。

残っている36件、そして今日も増え続けている

2026-07-09時点で、addview.html未生成の記事は正確に36件残っている。前日の作業完了時点の記録では35件だったので、1件増えている。理由は単純で、作業完了後にid=1245「Search Console に新機能『プラットフォーム プロパティ』登場、XやYouTubeへのGoogle検索トラフィックを分析可能に」という新しい記事が公開されたからだ。この記事もまだaddview.htmlが無いため、未処理分に含まれている。

サイトは今も成長を続けている。昨日1,028件をゼロにしたつもりでも、今日また新しい記事が生まれれば、その記事は生まれた瞬間からnoindexの状態でスタートする。この「終わらない後追い」を止めるには、一括処理を1回やって満足するのではなく、新規記事の公開フローそのものにaddview.html生成のステップを組み込む必要がある。この気づきも、今回の作業を通じて初めて言語化できたものだ。

代替案として考えられるのは、記事公開処理（本番反映スクリプト）の中にaddview.html生成のステップを組み込み、記事公開と同時に自動生成する方式だ。デプロイフローの一部として組み込めば、人間が「今日は何件溜まっているか」を確認しに行く手間そのものをなくせる。ただしこれは当サイトでまだ実装していない案であり、記事公開時点では手作業チェック（今回のような定期的な突合せ）に頼っているのが現状の正直な姿だ。🔧 公開フローへの自動組み込みは未着手

🔧 addview.html残36件の解消 着手中 🔧 7/8成功件数の20件ズレ原因特定 着手中 🔧 Fan-Out込みの本格拡張ミッション（Phase 2）着手中

明日から自分のサイトでできる5つのチェック

この記事が単なる「うちの裏側の失敗と復旧の記録」で終わらないために、読んだWEBディレクターが自分のサイトで今日か明日にできる具体的な手順を書く。

1. noindex判定条件をテンプレートから実コードで一行引用する。 「たぶんこの設定のはず」で済ませず、grep -n "noindex"のようなコマンドで実際の条件式を確認する。CMSの管理画面の設定項目だけを見ていると、テンプレート側に独自に実装された条件分岐（今回のようなaddview.htmlの有無など）を見逃す。✅ 当サイト実施済

2. DB上の「公開中」件数と、実ファイルシステム上の「関連ファイル」件数を突き合わせる。 次のように、公開件数のクエリと実ファイル数を並べて見るだけで、今回のような巨大なギャップが一発で見える。

# DB側の公開件数
SELECT COUNT(*) FROM articles WHERE flg_enable=1;
# ファイルシステム側の関連ファイル数
ls /path/to/addview/*.html | wc -l

今回は1,238件（公開中）に対してaddview.htmlが1,202件しかなく、その差が浮かび上がった。✅ 当サイト実施済

3. sitemap.xmlの件数は、単純grep件数と実際にXMLパースした件数の両方を取る。 今回、単純grepでは1,358件、XMLパース経由の集計では1,356件という2件差があり、これがarchives/67・archives/70の重複登録という別の問題を見つけるきっかけになった。件数の取り方を変えるだけで、隠れていた不整合が見つかることがある。✅ 当サイト実施済

4. 一括処理・一括修正の「成功件数」は、自己申告のログではなくファイルシステムのタイムスタンプで独立検証する。 今回の973件と993件のズレは、まさにこのチェックをやったから見つかった。ログの「成功しました」という文字列を信じるだけでは、20件の食い違いには一生気づかなかった。🔧 原因特定は継続中

5. noindex解除だけで終わらせず、除外条件を作っている監査スクリプト（sitemap生成など）が同じ条件を見ているかを確認する。 今回のケースでは、noindex判定とsitemap掲載判定が意図的に同じaddview.html存在チェックで連動する設計だった。もし連動していなければ、noindexを解除してもsitemapには載らない、あるいはその逆という、片方だけ直して終わったつもりになる典型的な事故が起きていたはずだ。✅ 当サイト実施済（sitemap_check.pyによる自動突合せ）

ここで一度、専門用語を整理しておく。

noindexタグとは、ページのHTML内に<meta name="robots" content="noindex">のように記述する、あるいはHTTPレスポンスヘッダーにX-Robots-Tagとして付与する指示のことで、検索エンジンにそのページを検索結果に含めないよう伝えるものだ。似た指示に「nofollow」があるが、こちらはそのページ内のリンクを辿らないよう伝えるものであり、noindexとは役割が異なる。robots.txtによるクロール自体のブロックとも別物で、robots.txtでブロックされたページはそもそもクロールされないためnoindexタグ自体が読まれず、意図通りに動かないことがある——これは冒頭で引用したGoogle公式のnoindexの仕組みでも明記されている注意点だ。

addview.htmlは、汎用CMSの標準機能ではなく当サイト固有の実装だ。記事本文とは別に、要点整理や関連情報を追加する静的HTMLファイルを記事ごとに用意する仕組みで、他CMSでいえばカスタムフィールドに近い役割を持つ、とイメージすると分かりやすい。当サイトではこのファイルの有無を、noindex判定とsitemap掲載判定の両方に流用している。

Fan-Outクエリ戦略とは、AI検索エンジンが1つの検索意図を裏側で複数の関連サブクエリに分解し、それぞれの答えをページ内から探索する仕組みのことだ。当サイトでは記事公開前に、想定される複数のサブクエリに対してその記事がどこまで答えを用意できているか（covered / partial / not_covered）を測定し、ゼロになるまで内容を補強する運用を行っている。この記事自体も、その測定と補強のループを経て今の形になっている。

クロール予算と「品質シグナル」という文脈で見る

今回の件を、Googleが公式に説明している別の概念とも突き合わせておきたい。まずGoogle公式のクロール予算の説明では、クロール予算は主に「週次で更新される100万ページ以上」といった巨大サイト向けの概念だとGoogle自身が明記している。当サイトの規模（1,238記事）にこれが直接当てはまるわけではないことは正直に書いておく。

一方で、Search Consoleのページインデックス登録レポートのヘルプページでは「クロール済み - インデックス未登録」という状態について、クロールはされたがインデックスされなかった、将来インデックスされる可能性もされない可能性もある、と説明されている。そして2021年、John Muellerは「クロール済み-未インデックス」が大量発生する場合、個別ページの問題というよりサイト全体の品質シグナルの問題であることが多い、という趣旨の発言をしている（Search Engine Roundtable, 2021年）。これは2021年時点の発言であり、最近の発言だと誤認しないよう明記しておく。

今回の1,028件はこの「品質シグナルの問題」とは少し性質が違う。中身がGoogleに評価される前の段階で、テンプレートの条件分岐によって機械的に検索結果から外れていた。ただ、Search Engine Journalが報じた2025年の品質評価ガイドライン改訂が指摘する「労力・独自性がほとんどなく、類似ページと比べて付加価値がないコンテンツ」という基準に照らせば、Phase 1で生成した軽量版addview.htmlがそのまま放置されていいわけではない。土俵に上げることと、その土俵で評価される中身を作ることは別の仕事であり、それがPhase 2として残っている理由だ。

なお、Googleは2026年6月にSearch Consoleへ生成AIパフォーマンスレポートを追加発表している。noindexで土俵に上がっていない記事は、この新しい計測窓口の対象にすらならない。archives/82で書いたSCのAI除外ボタンの話とあわせて、「見えるようにする」重要性が計測面でも増している。

まとめ — 静かな地獄は、静かにしか見つからない

今回の1,028件は、リンク切れのように404を返すわけでも、スパムフィルターに引っかかって警告が出るわけでもなかった。ページは正常に表示され、URLも生きている。ただ検索結果から静かに外れているだけだった。だからこそ、314件というサンプリングされたアラートの奥に、その3倍以上の規模が隠れていたことに気づくまで時間がかかった。

「まず全部を土俵に上げてから磨く」という判断は、通常の丁寧な運用とは違う緊急対応だった。その結果として生まれた新しい問題——973件と993件のズレ、残り36件、増え続ける公開記事——を隠さず次の課題として積み上げていく。数字を丸めず、わからないことはわからないと書く。それが読者にとっての実用性でもある。

関連 archives（連載軸として読む）

• archives/76「AIに表示された回数を知っているか — GSC・GA4・Bing、3ツール立体計測の正直な現在地」 ── 計測ツールそれぞれの限界を正直に書いた回。今回のnoindex問題もこの「立体計測」の土台がなければ気づけなかった
• archives/82「SCのAI除外ボタンを使うべきか — 当サイトの選択と、WEBディレクターが今確認すべき3つの数字」 ── Search Consoleの新機能を実際に使いながら判断した回
• archives/54「Googleの数字は11ヶ月、壊れていた — Search Console バグ・FAQ廃止・5月の変動」 ── 計測データそのものが壊れていた過去の教訓
• archives/42「『準備OK』と答えた瞬間、何が抜けているか — 自己認識ズレを機械で潰す3層検証」 ── 「わかったつもり」を機械的に潰す、という今回の20件ズレの扱い方に直結する回

一次情報出典

• Google Search Central: noindexによるブロック・インデックス登録
• Google: ページのインデックス登録レポート（Search Consoleヘルプ）
• Search Engine Roundtable: John Mueller発言（2021年）— クロール済み・未インデックスは品質シグナルの問題であることが多い
• Google Search Central: 大規模サイト向けのクロール予算管理
• Search Engine Journal: Googleの品質評価者ガイドライン改訂（2025年4月30日）
• Google Search Central Blog: 生成AIパフォーマンスレポート（2026年6月）