Page type quality audit

Codexでページ種別ごとに
薄いページを分類した実践ログ

薄いページ対策は、URLを一件ずつ眺めるだけでは整理しにくい作業です。トップページ、一覧ページ、カテゴリページ、個別ページ、ランキングページ、レビュー系ページ、機能ページでは役割が違うため、必要な本文量、内部リンク、index対象かどうか、補強方法も変わります。

この記事は、実際の作業を一般化してまとめた実践ログ型ガイドです。具体的な案件名、内部情報、サーバーパス、秘密情報は掲載していません。

Google公式のSearch Console解説ではなく、公開中サイトを改善するための実務上の考え方として整理しています。Search ConsoleやSEO順位の改善を保証するものではありません。

今回やった作業

公開中サイトを、ページ種別ごとに分けて内容品質を確認した作業を一般化して書きます。いきなり全ページを修正するのではなく、まずサイト内のページを役割別に分けました。確認対象は、トップページ、一覧ページ、カテゴリページ、個別ページ、ランキングページ、レビュー系ページ、機能ページなどです。

そのうえで、どの種別が薄く見えやすいか、どの種別を優先して補強するべきか、どの種別はnoindex維持でよいかを整理しました。大事なのは、全ページに同じ説明文を足すことではありません。ページごとの役割を見て、共通guideで底上げできるページ、専用ハブ化した方がよいページ、個別に本文を補強した方がよいページ、観測でよいページを分けることです。

作業前の状態

作業前のサイトには複数種類のページがありました。カード一覧やランキング一覧があるページもあれば、個別ページとして情報を持っているページもあります。ただし、個別ページに情報があっても、親ページや一覧ページが薄く見えると、読者はどこから読めばよいのか分かりにくくなります。

また、機能ページや補助ページもあり、すべてを検索流入の主役にするべきか判断が必要でした。全ページを一括で修正すると、重複文や不自然な説明が増える可能性があります。そのため、どのページから補強するか、どのページはnoindex維持でよいか、どのページは親ページからの導線を整えるだけでよいかを決める必要がありました。

作業前に問題だったこと

薄いページ対策をURL単位だけで考えると、作業が散らばりやすくなります。トップページにはトップページの役割があり、一覧ページには一覧ページの役割があります。カテゴリページはテーマ別に何が見られるかを伝える場所で、個別ページは一つのテーマを深く説明する場所です。ランキングページでは順位、指標、比較軸、内部導線が必要になります。

一方で、機能ページは検索流入の主役ではなく、ユーザー体験を補助する役割を持つ場合があります。すべてを同じ基準で厚くしようとすると、ページの役割がぼやけます。文章量を増やすことだけが内容品質の改善ではなく、そのページで読者が何を判断できるか、次にどこへ進めるかが重要です。

ページ種別ごとに見る理由

ページ種別ごとに見ると、改善方針を決めやすくなります。トップページはサイト全体の案内板として見ます。一覧ページは関連ページへ進む入口として見ます。カテゴリページは、そのテーマで何が読めるのかを説明するページとして見ます。個別ページは一つの疑問や作業を深く説明するページとして見ます。

ランキングページは、順位、順位指標、何順なのか、内部詳細ページへ進めるかを見ます。レビュー系ページは、評価や感想が単なる並びではなく、読者の判断材料として整理されているかを見ます。機能ページは、検索流入の主役にするか、noindexでUX補助にするかを見ます。このように分けることで、同じ「薄く見えるページ」でも、何を足すべきかが変わります。

Codexに任せたこと

Codexには、いきなり修正させず、まず監査を任せました。確認させたのは、ページ種別の一覧化、各ページのHTTP状態、title、meta description、H1、canonical、robots、noindexの有無、sitemap掲載有無、本文説明の有無、カード一覧中心かどうか、内部リンクの有無、404リンクの有無、内容品質の弱いページ候補、改善優先度の提案です。

ここで重要なのは、Codexに「薄いページを直して」とだけ頼まないことです。その指示では、文章を足すだけの作業になりやすくなります。今回は、ページ種別を分け、確認項目をそろえ、修正ではなく調査と改善案に留めるよう指定しました。これにより、広範囲のファイル変更や意図しないSEOタグ変更を避けやすくなります。

人間が判断したこと

人間が判断したのは、全ページ一括修正ではなく、ページ種別ごとの改善にすることです。index対象ページを優先し、noindex維持でよいページを無理にindex対象へ寄せない方針にしました。共通guideで底上げできるページと、専用ハブ化すべきページも分けます。

同じ説明文を大量展開しないことも判断しました。共通の説明が必要な場合でも、すべてのページに同じ文章を貼るのではなく、親ページやハブページに置き、下層ページから自然に進めるようにします。Search Consoleで反応があるページは優先候補にしつつ、親ページや一覧ページも軽視しません。検索データだけではなく、サイト構造と読者導線を合わせて判断します。

ページ種別ごとの見方

トップページでは、サイト全体の役割が分かるか、主要ページへ進めるか、リンク集だけに見えないか、最初に読むべきページが分かるかを確認します。トップページはすべての詳細を説明する場所ではありませんが、サイト全体の入口として、どのカテゴリへ進めばよいかを示す必要があります。

一覧ページでは、ただのリンク一覧になっていないか、カテゴリや下層ページの選び方が分かるか、内部リンクの意味が説明されているかを見ます。カテゴリページでは、そのカテゴリで何が見られるか、カード一覧だけになっていないか、関連する個別ページへ進めるかを確認します。

個別ページでは、一つのテーマとして本文が成立しているか、title、H1、本文内容が一致しているか、関連ページへ自然に進めるかを見ます。ランキングページでは、順位、順位指標、何順か、内部詳細ページへの導線、ランキング理由の長さを確認します。レビュー系ページでは、レビューや評価が整理され、読者が判断できる情報になっているかを確認します。機能ページでは、検索流入の主役にするべきか、noindex維持でよいか、UX補助導線として必要か、sitemapに入れるべきかを見ます。

改善優先度をどう分けたか

改善優先度は、A、B、C、観測の四つに分けました。Aは優先して補強するページです。トップページ、親ページ、Search Consoleで反応があるページ、index対象のカテゴリページ、カード一覧だけに見える重要ページが入ります。これらはサイト構造上の入口になりやすく、読者が最初に迷う場所でもあります。

Bは既存記事に追記するページです。本文はあるものの説明が少し足りないページ、関連リンクやチェックリストを足せば改善できるページが該当します。Cはnoindex維持でよいページです。検索流入の主役ではなく、UX補助として必要な機能ページや、内部導線としては必要だがsitemapに入れないページです。観測は、公開して間もないページや、構造上の問題が明確ではないページです。すぐ本文を増やすより、親ページからの導線を先に整える方がよい場合があります。

全ページ一括修正を避けた理由

全ページに同じ説明文を一括で追加すると、重複した文章が増える可能性があります。また、ページごとの役割に合わない説明が混ざると、読者にとって不自然になります。たとえば、機能ページに検索流入向けの長い説明を足しても、UX補助としての役割とは合わないかもしれません。

そのため、まずページ種別ごとに監査し、共通guideでよいページと、専用guideが必要なページを分けます。共通guideは、複数ページにまたがる考え方をまとめる場所として使います。専用ハブは、特定テーマの入口として、下層ページを束ねる場所として使います。個別ページは、そのページのテーマに合わせて自然に補強します。修正前の分類があると、作業範囲を小さく保ちながら品質を上げやすくなります。

うまくいった点

うまくいった点は、ページごとの役割が整理できたことです。薄いページ候補を感覚ではなく分類で見られるようになり、index対象とnoindex対象も分けやすくなりました。全ページ一括修正を避けられたことも大きな収穫です。

また、親ページと個別ページの関係を見直せました。個別ページだけを厚くしても、親ページや一覧ページから進めなければ、読者は見つけにくくなります。ページ種別ごとの監査を行うことで、次のCodexオーダーを作りやすくなりました。どのページを補強し、どのページは観測し、どのページはnoindex維持にするかを、報告書として残せます。

詰まった点・危なかった点

詰まった点は、ページ数が多いと全件確認が重くなることです。すべてのURLを同じ深さで見ると時間がかかり、判断も散らばります。そのため、代表ページ、親ページ、Search Console反応ありページ、カード一覧中心ページを優先して確認する必要があります。

一覧ページとカテゴリページの役割が混ざりやすい点も注意しました。noindexページまで無理にindex対象へ寄せたくなる場面もありますが、機能ページや補助ページは検索流入の主役にしない方が自然な場合があります。共通guideを入れすぎると重複しやすくなるため、どこに置くかも判断が必要です。修正前の監査で止めるつもりが、そのまま実装修正まで広がりそうになる点も危なかったところです。

作業後に確認したこと

作業後は、ページ種別を分けられているかを確認しました。トップページ、一覧ページ、カテゴリページ、個別ページ、ランキングページ、機能ページをそれぞれ見て、各ページの200 OK、title、description、H1、canonical、robots、本文説明の有無、カード一覧だけかどうか、index/noindex、sitemap掲載、内部リンク、404リンク候補を確認します。

さらに、改善優先度を出したかも確認しました。Aは優先補強、Bは追記候補、Cはnoindex維持、観測は今すぐ触らないページです。今回は調査と分類を主目的にしたため、本文追加やテンプレート変更は行わない前提にします。これにより、次の作業で「どこを直すか」から迷わずに済みます。

次回使えるCodex指示文テンプレート

同じような監査を行う場合は、次のように依頼します。修正を急がず、まず分類と改善案までで止めるのがポイントです。

公開中サイトをページ種別ごとに監査してください。

トップページ、一覧ページ、カテゴリページ、個別ページ、ランキングページ、レビュー系ページ、機能ページに分けて確認してください。

確認する項目は、HTTP状態、title、meta description、H1、canonical、robots、index/noindex、sitemap掲載有無、本文量、内容説明の有無、カード一覧中心度、内部リンク、404リンクです。

各ページを、優先度A、優先度B、優先度C、今は観測の4つに分類してください。

Aは優先して補強するページ、Bは既存記事に追記するページ、Cはnoindex維持でよいページ、観測は今すぐ触らず状況を見るページです。

今回は修正せず、調査と改善案のみ出してください。

DB、cron、.htaccess、robots.txt、ads.txt、広告タグ、Search Console確認タグは触らないでください。

確認チェックリスト

ページ種別ごとの品質監査では、次の項目を確認します。すべてを同じ修正にせず、ページの役割ごとに見るためのチェックリストです。

  • ページ種別を分けた
  • トップページを確認した
  • 一覧ページを確認した
  • カテゴリページを確認した
  • 個別ページを確認した
  • ランキングページを確認した
  • 機能ページを確認した
  • 各ページの200 OKを確認した
  • title / description / H1を確認した
  • canonical / robotsを確認した
  • index/noindexを確認した
  • sitemap掲載を確認した
  • 本文説明の有無を確認した
  • カード一覧だけか判定した
  • 内部リンクを確認した
  • 404リンク候補を確認した
  • 改善優先度を出した
  • 全ページ一括修正を避けた

注意書き

この記事は、実際の作業を一般化してまとめた実践ログ型ガイドです。具体的な案件名、内部情報、サーバーパス、秘密情報は掲載していません。

Google公式のSearch Console解説ではなく、公開中サイトを改善するための実務上の考え方として整理しています。AdSense審査通過やSEO順位上昇を保証する内容ではありません。Codexに任せる場合も、最終的な公開判断、index/noindexの判断、内容品質の判断は人間が確認します。