読み方の1ポイント
目的、対象、確認項目を分けて読む
このページでは、Codex作業を安全に進めるための考え方を整理します。実行前に、対象、触らないもの、確認項目を分けて見ると迷いにくくなります。
このページも、全部を一度に覚えないとダメ?
必要なところから読めば大丈夫です。作業前に対象と停止条件、作業後に確認項目を見ると安全です。
今回やった作業
今回やった作業は、公開中サイトで「guideブロックを対象ページだけに表示する作業」を安全に整理した流れを一般化したものです。単なる作業報告ではなく、作業前に何が弱かったのか、Codexにどこまで任せたのか、人間がどこを判断したのか、作業後に何を確認したのかまで残します。
この種の作業は、見た目の修正だけでは完了しません。ページの役割、内部リンクの文脈、canonicalやrobots、sitemapとの整合性、公開HTMLでの表示確認まで見ないと、ユーザーにとっても検索エンジンにとっても意味が伝わりにくくなります。
今回は、実ドメイン名や内部情報を出さず、ランキング型サイトや小規模情報サイトでも再利用できる手順としてまとめています。
作業前の状態
作業前は、ページやリンク自体は存在していましたが、複数ページが同じ共通ファイルを使っており、説明guideが対象外ページへ混入する危険があったという弱さがありました。ファイルやURLが存在していることと、読者が迷わず使えることは別です。
また、サイト内のページが増えるほど、親ページ、補助ページ、検索入口ページ、個別ページの役割が混ざりやすくなります。役割が混ざると、内部リンクを増やしても、どこが重要なのかが伝わりにくくなります。
そこで、Codexにはいきなり大きな修正をさせず、まず現状の表示、リンク先、robots、canonical、公開HTMLを確認させる方針にしました。
作業前に問題だったこと
共通ファイルへの追加は、1ページだけのつもりでも複数ページに反映される可能性がある。この状態のまま作業を進めると、ページ数は増えても、サイト構造としては弱いままになる可能性があります。
特に、共通テンプレートや共通Controllerを使っているサイトでは、1か所の修正が複数ページに反映されることがあります。狙ったページだけを補強したつもりが、対象外ページに説明が混入することもあります。
内部リンクやnoindexの扱いも同じです。URLが存在するからリンクする、ページがあるからsitemapに入れる、という判断ではなく、そのページが検索入口なのか、UX補助なのかを分ける必要があります。
Codexに任せたこと
Codexに任せたのは、まず現状を正しく把握することでした。対象ページ、リンク元、リンク先、表示条件、robots、canonical、sitemap掲載有無、公開HTML上の文言を確認させました。
次に、修正する場合も範囲を限定しました。DB、cron、.htaccess、robots.txt、ads.txt、AdSenseタグ、Search Console確認タグ、共通部品には触らず、対象ページと必要な静的guideまたはリンク文言だけを扱う方針です。
- 対象ページの実ファイルを確認する
- HTTP 200を確認する
- title、description、H1を確認する
- canonicalとrobotsを確認する
- 公開HTMLに追加文言やリンクが出るか確認する
- 対象外ページへの混入がないか確認する
- 追加リンク先が200 OKか確認する
- DB、cron、.htaccess、広告タグを触っていないか確認する
人間が判断したこと
人間側で判断したのは、全カテゴリ一括ではなく、反応があるページや重要ページだけに限定して表示するという点です。Codexはファイル確認や差分整理に強いですが、どのページを重要扱いするか、どの導線を残すか、どこまでindex対象にするかは人間の設計判断が必要です。
また、全ページ一括の変更を避けることも人間が判断しました。構造改善では、広く薄く直すより、対象ページを絞って、公開HTMLと実画面で確認できる単位にする方が安全です。
今回も、リンクやguideを足す前に、そのページの役割と読者の動きを確認しました。検索流入の主役にするページと、ユーザー体験を補助するページを混同しないことが重要でした。
実際に使った指示文の考え方
指示文では、「改善してください」だけでは足りません。対象ページ、追加する内容、触らないファイル、停止条件、確認項目を具体的に書く必要があります。
特に今回のような構造改善では、対象ページだけに反映する条件、対象外ページへの混入確認、追加リンク先のHTTP確認を入れることが大切です。Codexの報告だけで完了扱いせず、公開HTMLに実際に出ているかも確認させます。
さらに、修正前に調査のみで止める選択肢も持たせます。原因が明確な場合だけ最小修正し、範囲が広がる場合は停止して報告させることで、事故を防ぎやすくなります。
うまくいった点
うまくいった点は、ページの役割を先に決めてから修正できたことです。リンクや説明文を増やすこと自体が目的ではなく、読者が次にどこへ進めばよいか分かることを目的にしました。
また、公開HTMLとリンク先HTTPを確認したことで、作業報告と実際の公開状態のズレを減らせました。Codexに作業させる時は、実装だけでなく確認まで依頼することで、実務に使える成果になります。
内部リンク、robots、canonical、sitemapを分けて見たことで、検索入口ページと補助導線ページを整理しやすくなりました。
詰まった点・危なかった点
危なかった点は、同じ説明やリンクを広く一括反映してしまうことです。ページごとの役割が違うのに同じguideを出すと、不自然な内容になり、かえって内容品質を下げる可能性があります。
また、noindexページや補助ページを検索入口のように扱うと、サイト内の重要度がぼやけます。必要な導線として残すことと、sitemapに入れてindex対象として押すことは別です。
内部リンクの文言も注意が必要です。リンク先が200 OKでも、文言と遷移先の役割がズレていると、ユーザーは期待と違うページへ移動したように感じます。
作業後に確認したこと
作業後は、対象ページのHTTP 200、追加guideやリンクの公開HTML表示、canonical、robots、noindexメタなし、追加リンク先の200 OKを確認しました。
あわせて、対象外ページにguideや文言が混入していないかも確認します。条件分岐や共通部品を扱う場合、対象ページだけを見るのでは不十分です。
最後に、robots.txt、ads.txt、AdSenseタグ、Search Console確認タグ、DB、cron、.htaccessに触っていないことを確認しました。構造改善のつもりで重要設定を変えないことが大切です。
- 対象ページがHTTP 200
- 追加guideまたはリンクが公開HTMLに出ている
- 対象外ページに混入していない
- title、description、H1を変更していない
- canonicalが維持されている
- robotsが維持されている
- noindexメタが入っていない
- 追加リンク先がすべて200 OK
- sitemapの扱いが意図通り
- DB、cron、.htaccessを触っていない
- 広告タグとSearch Console確認タグを触っていない
次から使える指示文テンプレート
次回同じ作業をCodexに頼む時は、対象、触らない範囲、確認項目、停止条件を明確にします。
以下の公開中サイトで、特定カテゴリページだけに説明guideを追加してください。
共通Controllerや共通indexを使っている場合は、対象ページだけに表示される条件分岐を確認してください。対象外ページにはguideが出ないようにしてください。
作業後は、対象ページにguide文言が出ていること、対象外ページには出ていないことを公開HTMLで確認してください。全ページ一括反映は禁止です。
確認チェックリスト
チェックリストは、作業後に「表示されたか」だけでなく、「対象外に混じっていないか」「重要設定を変えていないか」まで確認するために使います。
- 対象ページにguideが表示されている
- 対象外ページにguideが混入していない
- 条件分岐が明確
- 公開HTMLで文言を確認した
- PHP構文エラーなし
- title、description、H1を変更していない
- canonicalとrobotsが維持されている
- 追加リンク先が200 OK
- 共通部品を壊していない
- 全ページ一括反映をしていない
まとめ
guideブロックを対象ページだけに表示する作業は、見た目の変更やリンク追加だけではありません。ページの役割、index方針、内部リンクの意味、公開HTMLでの表示まで確認して、はじめて構造改善として扱えます。
Codexには、ファイル確認、リンク先確認、公開HTML確認、チェックリスト化を任せると効果的です。一方で、どのページを主役にするか、どのページを補助導線として残すかは人間が判断します。
次に同じ作業をする時は、全ページ一括ではなく、対象ページを絞り、触らない範囲を決め、作業後の確認までセットで指示すると安全です。
注意書き
この記事は、実際の作業を一般化してまとめた実践ログ型ガイドです。具体的な案件名、内部情報、サーバーパス、秘密情報は掲載していません。
同じ作業でも、サイト構成、公開環境、利用しているテンプレート、GitHub運用の有無によって確認すべき点は変わります。実作業の前には、対象ファイル、触らないファイル、停止条件、確認項目を決めたうえで進めてください。


