Diviビルダーでカスタムパーマリンクのページが404になる原因と直し方
Diviビルダーでカスタムパーマリンクを設定した固定ページを編集しようとしたとき、編集画面が404エラーになる現象は、パーマリンク管理プラグインがビルダー専用のクエリパラメータを不正に処理しているために起こる。多くの場合、プラグインの詳細設定で特定のクエリ文字列を除外するだけで解決する。
なぜDiviビルダーがカスタムパーマリンクのページで404エラーを起こすのか
Diviのビジュアルビルダー（フロントエンド編集）は、管理画面から対象ページのURLに「?et_fb=1」といったクエリパラメータを付与し、そのページをiframe内で読み込んで動作する。このとき、パーマリンク管理プラグイン（Permalink Manager Lite など）が設定したカスタムパーマリンクのリダイレクトルールが厳しすぎると、「?et_fb」がついたURLを本来とは別の場所に転送したり、存在しないページとみなして404ステータスを返してしまう。ページ自体は正常に表示されていても、ビルダーという編集専用のアクセスだけがブロックされるかたちになる。
具体的には、パーマリンク管理プラグインの「リダイレクト設定」や「正規化」機能が、付加されたクエリ文字列を除去してしまったり、ビルダー用のパラメータを含むURLをリダイレクト対象から外す設定になっていないことが原因だ。また、一部のキャッシュ設定が影響して、ビルダーがキャッシュ済みの不完全なページを読み込んで404を返すケースもある。
Permalink Manager Lite の設定を調整して404を解消する
カスタムパーマリンクで運用している環境でDiviビルダーが使えなくなったら、まずパーマリンク管理プラグインの詳細設定を見直す。ここでは日本語環境でも多く使われている「Permalink Manager Lite」を例に手順を示すが、他のパーマリンク系プラグインでも同様の考え方で対処できる。
上記の「除外するクエリパラメータ」には「et_fb」とだけ入力すればよい。クエリキー名のみをカンマ区切りで列挙する仕様のため、値や「?」を含める必要はない。保存後にDiviビルダーでカスタムパーマリンクのページを開き直し、編集画面が正しく表示されるか確認する。
リダイレクト無効化で管理者の編集を保護する
もう一つの有効な方法は、特定のユーザーに対してリダイレクト機能を一時的に無効化する設定だ。「詳細設定」画面の「リダイレクトを無効化するユーザー」で「管理者」にチェックを入れて保存する。こうすると管理画面からビルダーを開く管理者のリクエストにはリダイレクトルールが適用されず、クエリパラメータがそのまま残るため404が発生しなくなる。ただし、この設定は公開側のパーマリンク動作には影響しない。
デバッグモードで原因を可視化する
設定を変更しても改善しない場合は、「ツール」→「Permalink Manager」→「設定」→「詳細設定」にある「デバッグモード」を有効にしてみる。デバッグモードをオンにすると、ビルダーで404になった際にプラグインがどのURLを解決しようとして失敗したか、詳細なログが記録される。これを見ることで「et_fb」以外に必要な除外パラメータが見つかったり、リダイレクトルールの競合を特定できる。
キャッシュプラグインの影響を切り分ける
パーマリンク管理プラグインの設定を見直しても直らないときは、サーバーキャッシュやWordPressのキャッシュプラグインの影響を疑う。ビルダー読み込み時の動的URLがキャッシュから誤ったレスポンスを返す場合があるため、以下の手順で一時的にキャッシュを無効化し、症状が消えるか確認する。
- 使用しているキャッシュプラグイン（WP Super CacheやW3 Total Cacheなど）を一時停止する
- サーバー側でNginxのfastcgi_cacheやApacheのmod_cacheを使っているなら、管理画面経由でキャッシュをクリアするか、一時的に無効にする
- ブラウザのキャッシュもクリアしてからビルダーを再読込する
キャッシュを切った状態で編集が成功したなら、キャッシュプラグインの「除外するURLパターン」に「?et_fb」を含む設定を追加する。たとえば、et_fb というクエリ文字列がついたリクエストはキャッシュしないように設定すれば、運用を続けながら編集機能を維持できる。
どうしても直らないときの代替手段
上記すべてを試してもビルダーが404を返す場合、根本的にプラグインの仕組みがDiviビルダーと相性が悪い可能性がある。以下の対策を順に検討する。
パーマリンクプラグインを別のものに切り替える
カスタムパーマリンク機能自体は別のプラグインでも実現できる。「Custom Permalinks」や「WP Permalink」など、Diviとの競合報告が少ないプラグインを試すことで、リダイレクトの挙動を根本から変えられる。ただし、移行時には既存のURL構造を維持できるか事前にテスト環境で確認する必要がある。
ページ編集時だけパーマリンクを一時的にデフォルトに戻す
最終手段として、編集したい固定ページのパーマリンク設定を一時的に「デフォルト（?p=123）」に変更してビルダーで作業し、公開直前にカスタムパーマリンクに戻す方法もある。ただし、編集のたびに手作業が発生するため、恒常的な運用には向かない。
よくある質問
エラーは「このサイトで重大なエラーが発生しました」ではなく「404 Not Found」と表示されるのはなぜか
Diviビルダーはページをiframeで読み込む際に、サーバーに実際のHTTPリクエストを送る。カスタムパーマリンクのルールがリクエストを処理できないと、WordPressのルーティングが失敗し「ページが見つかりません」という404ステータスが返る。これはPHPの致命的エラーではなく、あくまでもURL解決の失敗が原因だ。
特定の固定ページだけ編集できず、他のカスタムパーマリンクページは問題ないのはなぜか
スラッグの重複やリダイレクトルールの複雑さによって、一部のURLだけ誤って別のルールにマッチしてしまうことがある。全ページに同じカスタム構造を割り当てていても、個別に手動で追加したリダイレクト設定が干渉している場合もあるため、プラグインの「重複チェック」や「リダイレクトリスト」を確認する必要がある。
除外するクエリパラメータに「et_fb」を追加しても直らない場合はどうすればよいか
その場合は、ビルダーが使用する可能性のあるすべてのクエリパラメータを確認する。たとえば「et_fb」「et_pb_preview」「et_fb_iframe」「preview」「preview_id」などが考えられる。開発者ツールのネットワークタブでビルダー起動時に送信されるリクエストを調べ、404になっているURLに含まれるパラメータをすべて除外リストに追加する。
キャッシュプラグインを停止しても404が消えない
サーバーレベルのキャッシュ（VarnishやNginx FastCGI）が影響している可能性がある。レンタルサーバーの管理パネルからキャッシュを手動でクリアするか、サーバー会社のサポートに一時的なキャッシュ停止を依頼して切り分ける。WordPressのキャッシュプラグインだけでは制御できない層があるためだ。
この記事のポイント
- パーマリンク管理プラグインの除外設定に「et_fb」を追加すれば大半のケースで解決する
- 管理者向けのリダイレクト無効化も有効な回避策になる
- キャッシュプラグインやサーバーキャッシュが404を悪化させることがあるため、一時停止して切り分ける
- デバッグモードで詳細なログを確認すれば、除外すべき追加パラメータを特定できる
- 根本的に相性が悪い場合は、パーマリンクプラグインの変更も選択肢に入る
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている