薄いページ683本を「外す」と「書き足す」に振り分けた記録

文字数で測ると判断を間違える

薄いページを探す時、最初は本文の文字数で測っていました。「1,300字未満を書き足す」といった基準です。

ところが、全ページが1,500字を超えている状態で審査に落ちたサイトがありました。中身を見ると原因は明白でした。

各ページの本文が、他のページと共通の定型文でできていたのです。注意書き、免責、共通のFAQ、関連リンクの説明文——こうしたブロックを積み上げると、簡単に1,500字を超えます。しかしそのページにしか書かれていない内容は200字程度、という状態になります。

実例として、2,283字あるのにそのページ固有の記述は68字というページがありました。文字数の基準では合格、実態は空に近い状態です。

独自の本文量で測り直す

測り方を変えました。サイト内の全ページを取得して、複数ページに共通して現れる文を除き、残った文字数を数えます。

Claude Codeに「サイトマップの全ページを取得して、2ページ以上に出てくる文を除いた本文の量をページごとに出して」と頼めば作れます。処理としては単純で、200〜1,000ページなら数分です。

9サイトに流した結果です。

合計で683本が300字未満でした。平均の独自率が25〜26%というサイトもあり、ページの4分の3が共通の定型文でできている状態です。

定型文を置くこと自体は問題ではありません。免責や注意書きは必要です。問題はそれがページの大半を占めることで、独自の内容を足せば比率は自然に下がります。

検索データと突き合わせて振り分ける

683本を全部書き直すのは現実的ではないので、検索データと突き合わせました。判断は2つです。

結果は外す427本、書き足す256本。表示ゼロのページを外すだけで、6割が片付きました。

ここで注意点があります。この振り分けを機械的に流すと、運営者情報や免責のように「短くて当たり前で、表示回数もない」ページを巻き込みます。触ってはいけないページの定義を先に書いてください。実際に7本を巻き込んで復旧する羽目になりました。

サイトによって性格が正反対だった

振り分けた結果を見て、想定と違う点がありました。「薄いサイト＝同じ対処」ではありませんでした。

前者は、作ったものの誰にも見つかっていないページが大量にある状態です。外して身軽にするのが正解になります。

後者は、薄いのに表示が出ているという状態で、外すと今ある入口を自分で潰すことになります。こちらは時間をかけて書き足すしかありません。

同じ「薄いページが多いサイト」でも、作業量が10倍違います。測る前に工数を見積もらないでください。

書き足す時に効いたこと

実際に書き足してみて分かったことが2つあります。

1つ目。2節では足りません。最初は1ページに2節（450〜570字）を足しましたが、共通の定型文が1,300字あるため独自率がほとんど動きませんでした。3節・700字以上を最低ラインにして書き直しました。ビルダー側で700字未満を弾くようにしています。

2つ目。同じ節を配ってはいけません。似たページが並んでいると、つい同じ内容を足したくなります。しかしそれは新しい重複を作る作業です。実際、見出しまで同一のページが4本・3本・2本という塊がありました。切り口を意図的にずらして、それぞれ別の角度から書く必要があります。

優先順位は表示回数で決めました。表示20以上の27本を先に処理したところ、書き足し対象全体の表示の54%を占めていました。本数ではなく表示回数で数えると、少ない工数で効く範囲が分かります。

この作業の手順

まとめると、次の順番になります。

1. 文字数ではなく独自の本文量で測る — 共通の定型文を除いた量
2. 検索データと突き合わせる — 表示ゼロか、表示があるか
3. 触ってはいけないページを先に定義する — 運営者情報・免責・ポリシー・問い合わせ
4. 表示ゼロは外す — ファイルは消さず、元に戻せる形で
5. 表示があるものは、表示回数の多い順に書き足す — 1ページ700字以上、内容はページごとに変える

1番目を飛ばすと、以降の判断が全部ずれます。「全ページ1,500字あるから大丈夫」は、測り方が違うだけで根拠になっていません。