Codexで全ページ種別の内容品質を監査した実践ログ

今回やった作業

今回やった作業は、公開中サイトを1ページずつ場当たり的に直すのではなく、ページ種別ごとに内容品質を監査したことです。トップページ、一覧ページ、カテゴリページ、ランキングページ、個別ページ、レビュー系ページ、補助機能ページのように、役割ごとに分けて確認しました。

この作業では、すぐに本文を書き換えるのではなく、まず「どのページが薄く見えやすいか」「どのページをindex対象として厚くするべきか」「どのページはUX導線としてnoindex維持でよいか」を整理しました。ページが多いサイトでは、全ページを同じ重さで見ると優先順位が分からなくなります。

Codexには修正ではなく監査を任せました。HTTP、robots、canonical、title、description、H1、本文量、guideの有無、カード一覧中心度、内部リンク、404リンクを確認し、改善優先度をA/B/Cに分けるための材料を出してもらいました。

作業前の状態

作業前のサイトには、カード一覧やランキング表示があるページが複数ありました。見た目としてはページが存在しているものの、読者が見たときに「このページで何を確認すればよいのか」「どのページが入口なのか」が分かりにくい箇所がありました。

トップページ、カテゴリページ、ランキングページ、個別ページは、本来それぞれ役割が違います。トップページは全体の案内板、カテゴリページはテーマ別の入口、ランキングページは順位や比較の入口、個別ページは詳細確認の場です。それにもかかわらず、どのページもカード一覧に見えると、サイト全体が単調に見えます。

Search Consoleの反応を待つだけでは、どのページから直すべきか判断しづらい状態でした。反応が出たページだけを追うのではなく、人間が見て重要なページ、構造上リンクを集めるべきページ、補助導線として扱うページを先に分ける必要がありました。

作業前に問題だったこと

問題だったのは、薄いページ対策を個別記事の文字数だけで見てしまうことです。ページ数が多いサイトでは、1ページだけ厚くしても、トップや親ページが薄いままだとサイト全体の価値が伝わりにくくなります。

また、カード一覧や順位表があるだけでは、必ずしも有用なページとは言えません。ページの役割、見方、関連ページへの導線、内部詳細ページへの進み方がないと、読者は次に何をすればよいか分かりにくくなります。

さらに、すべてのページをindex対象として厚くしようとすると、作業量が膨らみます。補助機能ページや絞り込み用ページまで同じように厚くするより、重要ページと補助ページを分け、重要ページから優先して改善する必要がありました。

Codexに任せたこと

Codexには、まずサイト内の主要ページ種別を洗い出す作業を任せました。単にURL一覧を作るのではなく、トップ、一覧、カテゴリ、ランキング、個別、補助機能のように役割で分類し、それぞれのページがどの状態かを確認させました。

次に、各ページのHTTP状態、robots、canonical、title、description、H1、本文量、guideの有無、カード一覧中心度、内部リンク、404リンクを確認させました。ここで重要なのは、まだ修正しないことです。調査段階で修正まで進めると、優先順位が固まる前に局所的な変更が増えてしまいます。

• 主要ページ種別を分類する
• HTTP 200か確認する
• robotsとcanonicalを確認する
• title、description、H1を確認する
• 本文量とguideの有無を確認する
• カード一覧中心に見えるページを洗い出す
• 404リンクや未作成URLを確認する
• index対象とnoindex対象を整理する
• 改善優先度A/B/Cを提案する
• 次に行う最小実装案を出す

人間が判断したこと

人間側で判断したのは、全ページを一気に直さないことです。サイト全体を監査すると直したい箇所は多く出ますが、すべてを同時に進めると確認が粗くなります。まずページ種別ごとに役割を分け、重要な入口ページから改善する方針にしました。

また、index対象ページを優先して厚くすることも人間が判断しました。検索入口として見せたいページと、ユーザーの回遊を助ける補助ページは同じ扱いではありません。補助ページは無理にindex対象へ寄せず、必要ならnoindex維持でUX導線として使う判断もあります。

Search Consoleの反応があるページは、専用ハブ化や本文補強の候補として優先しました。一方で、反応待ちを理由に作業を止めるのではなく、人間が見て弱い親ページや重要導線は先に整える方針にしました。

実際に使った指示文の考え方

指示文では、「薄いページを直して」ではなく、「ページ種別ごとに内容品質を監査してください」と伝えることが重要でした。対象をページ単位ではなく種別単位にすることで、トップ、一覧、カテゴリ、ランキング、個別ページの役割差を見られます。

また、今回は修正しない条件を入れました。Codexは改善案を出せますが、監査段階でいきなり実装すると、どのページを優先するか決まる前に作業が散らばります。調査のみ、分類のみ、優先度整理まで、と範囲を区切ることで安全に進められます。

報告形式も指定しました。ページ種別、URL、HTTP状態、index方針、薄く見える理由、改善方法、優先度を表に近い形で出させると、人間が次の実装オーダーに変換しやすくなります。

うまくいった点

うまくいった点は、ページを個別に眺めるのではなく、サイト全体の構造として見られたことです。トップページだけ、ランキングページだけを見るよりも、種別ごとに並べることで、どこが入口でどこが補助導線なのかが分かりやすくなりました。

改善優先度をA/B/Cに分けたことで、次の作業が決めやすくなりました。Aは重要な入口や検索対象として厚くするページ、Bは共通guideで底上げできるページ、Cはnoindex維持や後回しでよいページ、というように考えられます。

また、Search Console待ちで止めずに、内容品質の改善対象を見つけられたことも大きな成果でした。計測結果を見ることと、サイト構造を整えることは別の作業として並行できます。

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

危なかった点は、全ページに同じ説明文を貼ってしまうことです。共通guideは便利ですが、ページの役割が違うのに同じ文章を大量に入れると、かえって薄く見えます。共通で底上げできるページと、専用ハブ化すべきページを分ける必要があります。

もう一つの危険は、noindexページを無理にindex対象へ変えることです。補助ページや絞り込みページは、ユーザー導線として必要でも、検索入口として見せるべきとは限りません。index制御はページの役割とセットで判断します。

また、監査結果を見てすぐ全部修正したくなる点も注意です。修正は優先順位を決めてから、小さな単位で進め、各段階でHTTP、canonical、robots、内部リンクを確認する必要があります。

作業後に確認したこと

作業後は、主要ページ種別が整理されているか、各種別に改善優先度が付いているかを確認しました。監査は一覧を作るだけでなく、次にどのページをどう直すかまで見える状態にすることが目的です。

また、index対象とnoindex対象が混ざっていないか、重要ページへ内部リンクが集まる構造になっているか、canonicalやsitemapの扱いに矛盾がないかを確認しました。

最後に、次の最小実装案を作りました。たとえば、トップページを案内板化する、ランキングページに説明guideを入れる、カード一覧ページを読める入口にする、404リンクを整理する、というように、小さく実装できる単位へ落とします。

• 主要ページ種別を確認した
• HTTP 200を確認した
• robotsを確認した
• canonicalを確認した
• title、description、H1を確認した
• 本文量とguide有無を確認した
• カード一覧中心か判定した
• 404リンクを確認した
• index対象とnoindex対象を分けた
• 改善優先度A/B/Cを出した
• 次の最小実装案を出した

次から使える指示文テンプレート

次回同じ監査を行う時は、修正前にページ種別と役割を整理する指示にします。以下のテンプレートは調査専用です。

以下の公開中サイトについて、ページ種別ごとに内容品質を監査してください。

トップページ、一覧ページ、カテゴリページ、個別ページ、ランキングページ、レビュー系ページ、補助機能ページを確認し、HTTP、robots、canonical、title、description、H1、本文量、guide有無、内部リンク、404リンクを整理してください。

各ページを、説明が十分、カード一覧中心、薄い可能性あり、noindex維持でよい、技術修正が必要、のように分類してください。

今回は修正せず調査のみです。最後に、優先度A/B/Cで改善順を出し、次に行う最小実装案を提案してください。

確認チェックリスト

監査チェックリストは、ページを良い悪いで単純に分けるためではなく、次にどこから改善するかを決めるために使います。

• 主要ページ種別を洗い出した
• 各ページの役割を確認した
• HTTP 200を確認した
• robotsを確認した
• canonicalを確認した
• title、description、H1を確認した
• 本文量と説明guideの有無を確認した
• カード一覧だけに見えないか確認した
• 内部リンクと404リンクを確認した
• index対象とnoindex対象を分けた
• 改善優先度A/B/Cを付けた
• 次の実装案を小さく切った

関連する使い方ガイド

まとめ

内容品質監査は、ページを増やす前にサイト全体の役割を整理する作業です。トップ、一覧、カテゴリ、ランキング、個別ページを同じ目線で見るのではなく、それぞれの役割に合った厚みがあるかを確認します。

Codexには、記事を書かせるだけでなく、サイト全体の状態を分類させる使い方があります。ただし、どのページを重要扱いするか、どこをindex対象にするか、どこを補助導線にするかは人間が判断します。

次に同じ作業をする時は、修正より先に監査、監査より先にページ種別の整理です。改善優先度を決めてから小さく実装すると、サイト全体の品質を崩さずに底上げできます。

注意書き

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

同じ作業でも、サイト構成、公開環境、利用しているテンプレート、GitHub運用の有無によって確認すべき点は変わります。実作業の前には、対象ファイル、触らないファイル、停止条件、確認項目を決めたうえで進めてください。