WordPressでカスタムメニューが反映されないときの対処

公開：2025.09.13

この記事はこんな人向けです

「外観＞メニュー」で保存したのに、フロントでメニューが変わらない
PCでは反映されるのに、スマホだけ別メニュー（またはハンバーガーメニューが空）になる
ブロックテーマ（FSE）のナビゲーションと従来メニューが混在していて迷子

WordPressレベル別対応難易度

Lv1 Lv2 Lv3 Lv4 Lv5 Lv6 Lv7

レベル判断は、右のレベル表（スマホは画面下）を参考にしてください。

赤：外注推奨オレンジ：条件付き自力可緑：自力対応可

カスタムメニュー反映不良の全体像と対応方針

カスタムメニューが反映されない原因は、「割り当て不備」・「キャッシュ」・「テーマ/ビルダー仕様の差」の3系統が多いです。
まずはメニューの「表示位置」や「デバイス別メニュー」を確認し、次に各種キャッシュを無効化・クリアして確認してみます。
ブロックテーマ（FSE）/ページビルダー利用時は、テンプレート内のナビゲーション設定や条件表示も見直すのが近道です。

カスタムメニューが反映されないとき～WordPressレベルごとのおすすめ対応

「割り当て」と「キャッシュ」だけ確認

まずは、基本の2点だけチェックしましょう。
1) 「外観＞メニュー」で編集したメニューが、テーマの表示位置に割り当てられているか（ヘッダー/フッター/モバイルなど）を確認する。
2) キャッシュ系（プラグイン・サーバー・CDN・ブラウザ）のクリアを実行して、再度メニューを確認する。

最近はテーマやページビルダー側でPC用とスマホ用が別メニューになっていたり、ハンバーガー用のメニュー位置が独立しているケースが増えています。
編集したメニューを「メイン」「モバイル」「ドロワー」など、該当する場所に割り当て直すだけで解決することもあります。

それでも直らない場合は、無理をせず外注に切り替えましょう。誤設定で「一部ページだけ違う」「階層メニューが出ない」など、症状を広げてしまうことがあります。
業者へ渡す準備物は、発生ページのURL・スクショ・使っているテーマ/ビルダー名・直前の操作あたりをメモしておけばOKです。これらを揃えておくことで解決が早くなります。

「表示条件」と「重ねがけキャッシュ」を疑う

オレンジレベルの方は、もう一歩踏み込んで状況を切り分けましょう。ポイントは次の通りです。

デバイス別メニュー：テーマ設定（カスタマイザー/テーマオプション）で、モバイル専用のメニュー位置が別れていないか。
特定ページだけ違う：固定ページやテンプレート単位で別ヘッダーが読み込まれていないか（LPテンプレ・ビルダーテンプレ）。
FSE/ナビゲーションブロック：ヘッダーテンプレート内のナビゲーションブロックが、期待するメニューを参照しているか（サイト編集＞テンプレート/パーツで確認）。
表示条件/会員制：メニュー項目に表示条件（ログイン時のみ表示等）を付ける系プラグインの影響。
マルチ言語：Polylang/WPML等で、言語ごとに別メニューの割り当てが必要。
キャッシュの重ねがけ：ページキャッシュ＋ミニファイ＋CDN＋ブラウザの多段キャッシュで、反映が遅延/固定化している。

チェック順は、「テーマ設定（デバイス別）→テンプレートの参照先→プラグインの表示条件→キャッシュ全クリア」の流れがおすすめです。
特にブロック（FSE）テーマでは、「従来の外観＞メニュー」よりも、サイトエディター内のナビゲーションブロックが実際の表示を握っていることが多いので要注意です。

ここまでやっても改善しないなら、テーマのヘッダーが複数ありページ単位で切り替えている、ビルダーのヘッダーウィジェットが別管理、役割/権限プラグインがリンクを非表示にしている…など構造的な要因の可能性が高くなります。
時間対効果を考えて、外注へスイッチすることも視野にいれましょう。

階層・パーツ・出力条件・CDN設定を精査

緑レベルの方なら、より技術的に切り分けられます。コード改修は避けつつ、構造の把握と設定の突き合わせで原因を詰めていきましょう。

テンプレート階層の確認：フロントで読み込まれているテンプレート（header.php / parts/header.html等）がどれかを把握。FSEは「テンプレート/パーツ」の実体を特定。
ナビゲーションの参照先：FSEのナビゲーションブロックが参照するメニューオブジェクト、クラシックテーマならメニュー位置（theme_location）の関連付けをUI上で再指定。
条件分岐：デバイス/投稿タイプ/カテゴリーでヘッダーを切り替える条件が仕込まれていないか（ビルダーの表示条件含む）。
最適化系の影響：CSS/JSの結合・遅延読み込みでハンバーガーが開かず「中身がないように見える」現象。結合除外や遅延解除の一時テストを実施。
CDN/エッジキャッシュ：パス別・クエリ別のキャッシュポリシーでヘッダー差し替えが反映されないことがあるため、該当パスのパージとバイパス確認。
多言語/マルチサイト：サイト/言語ごとに割り当てが独立。ネットワーク側・各言語側の両画面で設定を確認。
権限/ロール拡張：メニュー項目の表示制御をする会員制プラグイン・A/Bテストでセグメントごとに出し分けていないか。
リンク先の状態：ドラフト/非公開のページをメニューに入れていると、ログアウト時に非表示になる構成もあるため公開状態を点検。

切り分けのコツは、「テーマのメニュー位置」と「ブロックの参照先」と「キャッシュ」を独立に動かし、一つずつ作用を止めて挙動を観察すること。
最終的に、FSEへ一本化するのか、クラシックメニューで行くのかの運用ポリシーを決めておくと、以後のトラブルが減ります。

なお、ここまでの調査はテーマによっては構造把握に時間がかかります。納期や予算を見ながら、要所だけ外部の手を借りるのも有効です。

カスタムメニュー不良を外注する場合のポイント

「原因の見当がつかない」「今日中に直したい」なら、専門家に任せるのが早いです。費用感・流れ・準備物を押さえておきましょう。

項目	ポイント
費用の目安	・割り当て/キャッシュ整理のみ：5,000～10,000円・FSE/ビルダー混在の是正・テンプレ修正：15,000～30,000円・多言語/会員制/エッジキャッシュ絡みの調整：30,000円～（要見積もり）
依頼の流れ	1. 症状共有（発生URL・端末/ブラウザ・PC/スマホどちらで再現か・直前の操作） 2. 簡易診断と見積もり（範囲・納期・バックアップ方針） 3. 作業（検証→反映→再キャッシュ化）と結果報告
準備しておくと便利	・現在使っているテーマ名/ビルダー名（例：ブロックテーマ、Elementor等）・キャッシュ/最適化/多言語/会員制など、関連しそうなプラグイン一覧・発生条件（PCのみ・スマホのみ・特定ページのみなど）とスクリーンショット/スクリーン録画・CDNやサーバーキャッシュを使っていれば、その管理画面の情報