WordPressの通常投稿を親子の記事として整理したい場合、記事同士の関係とURLの階層は分けて設計します。
まとめ記事から個別記事へリンクするだけなら、投稿のURLやWordPressの検索処理を変更する必要はありません。
旧稿では通常投稿に親を設定し、URLとメインクエリを変更する実験コードを掲載していました。
2026年10月21日の本文見直しで、URL判定やクエリの整合に未解決の問題があるため、導入手順から取り下げました。
運用結果のないコードを、設定完了の例として扱うことはできません。
まず、親子関係を何に使うか決める
関連記事の案内やトピックごとの整理が目的なら、通常投稿のままカテゴリーとまとめ記事を使い、親に当たる記事から個別記事へリンクします。
個別記事からもまとめ記事へ戻るリンクを置きます。
この方法でURLを変更せずに記事間の関係を伝えられます。
URLを階層化するだけで検索順位が上がるとは判断できません。
サービス案内やマニュアルなど、親子構造で管理する独立したページ群なら、固定ページの親設定が候補になります。
既存の通常投稿をそのまま固定ページへ変更する手順ではありません。
日付別一覧・カテゴリー・フィードなど、通常投稿として使っている機能への影響を先に整理します。
新しいコンテンツ群を別管理するなら、階層型のカスタム投稿タイプを設計する方法もあります。
WordPressのhierarchical設定は管理上の階層性に関わるもので、URLのrewrite、編集画面、パンくず、権限、RESTへの対応も個別に設計します。
既存投稿のURL移行まで自動で解決する設定ではありません。
固定ページの親設定を試す手順
検証環境で親にする固定ページと子にする固定ページを作り、子の編集画面で「親」または「ページ属性」の親ページを選択して保存します。
項目の名称や場所はWordPressの版・エディターによって異なります。
保存後に編集画面を開き直し、選択した親が保持されていることと、生成されたパーマリンクを確認してください。
子ページのURLを直接開き、正しい内容とHTTPステータスが返ることを確認します。
親を変更するとURLも変わり得るため、公開済みのページでは旧URLや内部リンクへの影響を調べます。
親を設定しても、親ページに子ページへの案内が自動で並ぶとは限りません。
必要なリンクを本文やナビゲーションへ追加します。
操作の基礎はWordPress公式の固定ページ作成ガイド、独自投稿タイプの設計はregister_post_typeの仕様を参照してください。
旧コードを取り下げた理由
旧コードはREQUEST_URI全体へbasenameを適用して投稿スラッグを探していました。
URLに検索パラメーターが付いた場合など、パスだけを取り出した判定になりません。
また、URL内に「親/子」の文字列が含まれるかという部分一致では、正しい親子関係のパスかを確定できません。
post_linkの文字列置換はスラッグと同じ文字列をURL内で置き換えるため、目的のパス部分だけを変更する設計ではありません。
親が1階層上までの実装なので、複数階層・同名スラッグ・親の変更・非公開の親も別途検証が必要でした。
SQLにprepareを使うことは、このURL対応の問題を解決しません。
さらに、通常投稿を取得しながらis_pageとis_singleを両方trueにし、page_idを設定していました。
テンプレート選択やcanonicalの判定などと整合する保証がありません。
WordPress公式のpre_get_postsの説明も、メインクエリの種類を変える際はクエリの状態をそろえる必要があるとしています。
これらはパーマリンク設定を一度変えて保存し直せば解決する問題ではありません。
旧稿の「以上で階層化できました」という断定と、本番へ貼り付けるためのコード一式を削除しました。
SWELLのパンくずは別に確認する
親子関係、公開URL、画面のパンくず、構造化データは別の確認項目です。
旧稿のSWELL用フィルターは親1件と現在の記事だけを返すため、カテゴリーなど既存の経路を置き換えます。
見た目だけ親子にしても、URL解決や構造化データとの一致を保証しません。
テーマ・SEOプラグインが生成するパンくずと構造化データをそれぞれ調べ、必要な経路を決めてから検証します。
他テーマへ同じSWELLフィルターを使う手順ではありません。
旧版を設置している場合の確認と復元
本記事由来のconfigure_post_hierarchy、retrieve_parent_slug、get_sample_permalink・post_link・pre_get_postsの匿名処理、my_override_breadcrumb_list_dataとその登録箇所を特定します。
停止前にコード・親設定・現在と変更前のURLを控え、検証環境で切り替えます。
同じフックを使う別の処理まで一括削除しないでください。
コードを外しても保存済みのpost_parentや、外部から参照されるURLが自動で元に戻るわけではありません。
旧URL・現在URL・存在しないURL、クエリ付きURL、親子の直接アクセス、検索・カテゴリー一覧、ログアウト時の公開状態を比較します。
公開済みURLを変える場合は対応する転送先と内部リンクの修正を用意し、リダイレクトのループや404を確認してください。
パーマリンク設定の変更やリライトルール再生成は、使用する実装の仕様に従って行います。
原因を確認せず、サイト全体のURL形式を変更する復旧手順にはしないでください。
旧稿の画像と今回の確認範囲
以下の2枚は旧稿の記録として保持しています。
現在推奨する固定ページの手順や、修正版コードの動作を検証した画像ではありません。
2026年10月21日は旧コード全文とWordPress公式仕様を読み、問題点と代替の設計を整理しました。
現在の管理画面操作、実URLの移行、canonical・構造化データ、SWELLのパンくず、PC・スマートフォン表示は未検証です。
スクリーンショットは撮影していません。
この本文更新でサイトの投稿設定やURLは変更していません。
