page-XXX.phpは避けるべき？WordPress界隈の議論を整理して考えてみた

2026年4月中旬、Xにおいて「WordPressにおけるpage-XXX.phpの是非」について活発に議論が巻き起こっていました。私が観測している限りでは、この話題は定期的に議論され適度に盛り上がるように思います。

この記事では今回のXでの議論と論点を整理し、その上でこの話題について個人的に感じていることを率直にまとめています。

そもそもpage-XXX.phpとは

page-XXX.phpとは、WordPressで特定のスラッグ（URLの末尾）を持つ固定ページ専用のテンプレートファイルです。1つの固定ページにつき、1つのテンプレートファイルが割り当てられるというイメージです。

例えばaboutというスラッグを持つ固定ページの場合、page-about.phpというテンプレートファイルが適用されます。このpage-about.phpというファイルにページのコンテンツを直書きすることが良い選択なのか、悪い選択なのかという点が今回の議論の焦点です。

Xでの意見を集約

Xの検索窓で「page-XXX.php」と検索すると、様々な意見が見つかりました。page-XXX.phpの使用に肯定的な意見と否定的な意見に分けて整理してみます。

※個別の投稿には触れず、あくまでも一般化した内容となります。

肯定的な意見

実務上の合理性を重視する肯定的な意見が多く見られました。

• 目的達成を優先する実務志向

  • 問題なく運用できており成果（検索順位など）も出ているなら問題ない

• コスト・納期への適合

  • フルブロック化は工数が大きく、予算やスケジュールに見合わないケースがある
  • 制作フロー全体を変更できない現場事情がある

• デザイン再現性の担保

  • ブロックエディタでは再現が難しいデザインが存在する
  • ブロックエディタではマークアップを厳密にコントロールしづらいケースがある

• 編集範囲の制御

  • あえて編集可能範囲を限定することで、レイアウト崩れや誤操作を防ぐことが可能
  • クライアントのリテラシーを考慮した設計である

• クライアント要件ベースの柔軟性

  • 更新が必要な部分のみブロック化やカスタムフィールド化すればよい
  • 最終的にはクライアントとの合意が重要である

• 従来手法としての慣習

  • 学習教材や従来の制作フローで一般的に採用されてきた手法である

否定的な意見

一方で、WordPress本来の設計思想や長期運用の観点から、否定的な意見も多く挙がっていました。

• コンテンツ管理との分離

  • コンテンツがデータベースに蓄積されないため、再利用性や一元管理が難しい
  • REST APIやRSS、サイト内検索などとの連携が弱くなる

• SEO・機能実装の負担

  • 画像最適化などを個別に実装する必要がある
  • 構造化されたコンテンツとして扱いにくい

• 保守・拡張性の低下

  • テンプレートの増加により管理が煩雑になる
  • 共通部分の重複や修正漏れが発生しやすい

• ユーザー（クライアント）視点の欠如

  • 管理画面から更新できない設計は操作性に欠ける
  • テキストや画像変更等の編集をするにはコーディングの知識が必要になる

• WordPressの思想との乖離

  • コンテンツは管理画面で管理するべきという基本思想に反する
  • 更新しないのであれば静的サイトでよいのでは、という指摘もある

• 代替手段の存在

  • カスタムブロックなどで柔軟かつ管理可能な構成が実現できる

主な論点の整理

5つの主要な論点に絞って、page-XXX.php活用時と非活用時の違いを表にまとめてみました。

コストと納期、デザインの再現性といった実務上の合理性を重視する人は、page-XXX.phpを支持し、WordPressの思想や保守性を重視する人は、page-XXX.phpを使わない方針を支持する傾向があるように感じました。

今回の論点には入れておりませんが、「変更履歴のバージョン管理方法」も大きな違いです。

page-XXX.phpではテンプレートファイルに直接コンテンツを記述するため、Gitでバージョン管理を行うことができます。一方でブロックエディタではWordPress標準機能の「リビジョン」を活用することで、変更履歴の管理が可能です。それぞれ使い勝手が異なる点に注意が必要です。

個人的な意見

私自身は固定ページのテンプレートにコンテンツを直接記述することも、記述しないこともあります。大まかな割合としてはpage-XXX.phpでの構築が70〜80%程度、ブロックエディタでの構築が20〜30%程度です。ここ最近はブロックエディタでの構築が増えてきている印象です。

それぞれを経験してきた立場から、この話題について思うところを整理してみます。なおこの後の意見は主に以下のような立場と前提に立って述べています。

• 受託制作で活動するフリーランスのコーダー（5年目）
• 完成したデザインデータをもとにコーディングすることが多い
• デザイナーにフィードバックする機会は少なく、基本的に一方通行
• 小〜中規模のコーポレートサイトや採用サイト制作がメインである
• オリジナルテーマ（クラシックテーマ）での制作が多い

基本的にはあらゆるデザインデータをブロックで構築可能

page-XXX.php支持派の意見として、「ブロックエディタでは再現が難しいデザインが存在する」というものがあります。確かに再現が難しいデザインもありますが、ほとんどのデザインデータはブロックで構築可能だと考えています。

ブロックエディタでコンテンツを構築する場合、簡単なものから複雑なものまで次のような選択肢があります。

• コアブロックのブロックスタイルを拡張する
• コアブロックにクラスをつけてCSSを直接適用する
• コアブロックを組み合わせてブロックパターンを登録する
• Lazy Blocksでカスタムブロックを作成する
• スクラッチでカスタムブロックを作成する
• ショートコードを活用する
• カスタムHTMLブロックを作成する（最終手段）

これらの手法を駆使することで、複雑なデザインデータであっても管理画面からコンテンツを編集できるようにすることは可能です。「デザインが複雑だからできない」は多くの場合で真実ではなく、別の理由が隠れている可能性があるように感じます。

セマンティックにタグを使用することも可能

page-XXX.php支持派の意見として、「ブロックエディタではマークアップを厳密にコントロールしづらい」というものもあります。例えば以下のようなマークアップです。

1
<hgroup>
2
  <p>works</p>
3
  <h2>制作実績</h2>
4
</hgroup>

ラッパーのHTMLタグにhgroupを使用しています。WordPress標準のグループブロックではHTML要素としてhgroupを選択することはできないため、一見するとカスタムブロックを作成するしかないと思うかもしれません。

しかし、コードエディターを開いてtagNameをhgroupに変更することでグループブロックに任意のHTMLタグを選択することが可能です。

tagNameを変更後にビジュアルエディターに戻すと、「このブロックには、想定されていないか無効なコンテンツが含まれています。」と表示されます。これは保存されているHTMLタグと変更したタグがマッチしないために起こる現象です。「復旧を試みる」ボタンを押すと次のようにブロックが正しく展開されます。

少し力技で裏技的な方法にはなりますが、この見出しのグループブロックをパターンに登録しておくことで、繰り返し他の見出しにも適用できるようになります。

他にもWordPressコアのリストブロックには通常段落ブロックしか挿入できませんが、この方法を活用することで画像なども挿入できるようになります。カスタムブロックを作成するよりコストが低く管理も容易なため、良い方法だと感じています。

なおこの方法は以下のXの投稿でも共有されていました。

意外と知られていないかもですが、グループブロックは内部的にあらゆるタグをサポートしており、添付画像のようなものも正しいとみなされます。これをパターンやバリエーションとして用意しておくと便利かもです。
P.S. hgroupのサポートを提案するIssueも上がっています。https://t.co/AGxY87y5fb https://t.co/cKeyswD4UU pic.twitter.com/Q9eLziTJpR

— Aki Hamano (@tetsuaki_hamano) April 20, 2026

ただしグループブロックのtagNameを書き換えるこの方法は、theme.jsonファイルがある環境でのみ有効です。theme.jsonがない場合には次のように展開されてしまいます。

theme.jsonファイルが存在しないクラシックテーマでは、wp-block-group__inner-containerというクラスを持つdivタグが自動的に追加されます。

HTML仕様では、hgroupタグの内容モデルは見出し要素（h1〜h6）とp（サブタイトル用）のみが許可されています。divタグを子要素に持つことはできません。そのため上記は不正なマークアップとなります。

theme.jsonを適切に設定したテーマでのみこの手法を採用するのが良いでしょう。

コストと納期面ではpage-XXX.phpが有利

それではコストと納期面ではどうでしょうか。

完成したデザインデータをもとにコーディングを行う一般的な制作フローでは、page-XXX.phpの方が工数的に有利なケースが多いでしょう。

これはフルブロック化では、完成したHTML/CSSをWordPressに流し込む作業や、カスタムブロックに変換する作業がプラスアルファでかかるためです。最初からブロックで組んでおき、適切にスタイリングを追加することである程度工数を減らせますが、それでもハードコーディングと比べると工数はかかるでしょう。

体感としてはフルブロック化する場合、ハードコーディングと比べて20%~50%程度の工数が上乗せされる印象です。当然ながらデザインデータの複雑さによってはその比率は変わりますが、大まかな印象としてはこのようなものです。

ただ最近のAIエージェントの進化により、「HTML/CSSをWordPressに流し込む作業」や「カスタムブロックに変換する作業」は様々な場面において効率化が可能になってきていると感じます。フルブロック化とハードコーディングの工数差が徐々に縮小してきている印象です。

page.phpは必ず整備するべき

今回の議論とは少しズレますが、コンテンツをハードコーディングする場合でも、クラシックテーマにおいてはpage.phpのテンプレートファイルは必ず整備するべきだと考えています。

改修に入ったプロジェクトで、ブロックでコンテンツを追加しようとしたところ、page.phpがないためページが表示されないというケースに遭遇することが稀にあります。全ての固定ページがpage-XXX.phpでハードコーディングされているケースでした。

公開後もクライアントが任意のページを追加できるように、最低限page.phpのテンプレートファイルは整備しておくほうが良いと考えます。

まとめ

ここまでの考察を整理します。

• ブロックエディタで再現が難しいデザインもあるが、ほとんどのデザインはブロックで構築可能。
• ブロックエディタでマークアップをコントロールし、セマンティクスに配慮することも可能。
• コストと納期面ではpage-XXX.phpが有利なケースが多い。
• AIエージェントの進化により、フルブロック化の工数が徐々に縮小してきている。
• 公開後もクライアントが任意のページを追加できるようにするため、page.phpは整備するべき。

0か100かの問題ではなく、そのプロジェクトの要件や背景、現場の事情に合わせて適切な選択をすることが重要だと考えています。場合によっては固定ページAはpage-XXX.phpでハードコーディングし、固定ページBはブロックで構築するというような使い分けもあり得るでしょう。