WordPressのホワイトラベル化は、ログイン画面のロゴ、管理画面のフッター、管理バー、ダッシュボードの表示を自社やクライアントのブランドに合わせ、さらにクライアント用の権限を整えることで実現できます。どれもWordPressコアのフックで対応でき、専用プラグインがなくても小さなプラグイン1つにまとめられます。この記事では、制作会社やフリーランスがクライアントに納品するサイトを想定して、実装手順と、やりすぎて運用を壊さないための線引きを解説します。
ホワイトラベル化で何を変えるのか
ホワイトラベル化の目的は「WordPressであることを隠すこと」ではなく、クライアントが迷わず使える管理画面にすることです。変更対象は主に次の5つです。
- ログイン画面: WordPressロゴを自社またはクライアントのロゴに替え、ロゴのリンク先と代替テキストを変更する
- 管理画面フッター: 左下の「WordPressのご利用ありがとうございます。」と右下のバージョン表示を、サポート窓口の案内などに置き換える
- 管理バー: 左上のWordPressロゴメニューを外す
- ダッシュボード: 使わないウィジェットを外し、問い合わせ先や操作マニュアルへのリンクを載せる
- ユーザー権限: クライアントにはプラグインやテーマを操作できない専用の権限グループを用意する
見た目の変更はおまけで、実務上いちばん効くのは権限の整理です。クライアントが誤ってプラグインを無効化したり、テーマを切り替えたりする事故は、権限で防ぐほうが表示を隠すより確かです。
コードを置く場所を決める
ホワイトラベルの設定はテーマの functions.php ではなく、専用のプラグインかmu-plugins（Must Use プラグイン）に書くことをおすすめします。functions.php に書くとテーマを切り替えたときに設定が消え、子テーマを使っていない場合はテーマ更新で上書きされます。
mu-plugins は wp-content/mu-plugins/ に置いたPHPファイルが自動で読み込まれる仕組みで、管理画面から無効化できません。クライアントに触られたくない設定を置く場所として向いています。フォルダが無ければ作成し、agency-white-label.php のような名前でファイルを置きます。なお、mu-plugins はサブフォルダ内のファイルを自動では読み込まないため、PHPファイルはフォルダ直下に置き、画像などの素材だけをサブフォルダに入れます。
作業前には、本番サイトのファイルとデータベースのバックアップを取り、できればステージング環境で動作を確かめてから反映してください。PHPの構文エラーがあると管理画面に入れなくなることがあり、その場合はFTPやSSHでファイルを削除して復旧します。
ログイン画面のロゴとリンクを変える
ログイン画面のロゴは、login_enqueue_scripts アクションでCSSを追加して差し替えます。ロゴのリンク先は login_headerurl フィルター、ロゴの代替テキストは login_headertext フィルターで変更します。
<?php
/**
* Plugin Name: Agency White Label
* Description: ログイン画面・管理画面の表示を制作会社仕様に変更します。
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
// ログイン画面のロゴを差し替える
add_action( 'login_enqueue_scripts', function () {
$logo = plugins_url( 'agency-assets/login-logo.png', __FILE__ );
?>
<style>
#login h1 a, .login h1 a {
background-image: url(<?php echo esc_url( $logo ); ?>);
background-size: contain;
background-position: center;
width: 240px;
height: 80px;
}
</style>
<?php
} );
// ロゴのリンク先をサイトのトップページにする
add_filter( 'login_headerurl', function () {
return home_url( '/' );
} );
// ロゴの代替テキストをサイト名にする
add_filter( 'login_headertext', function () {
return get_bloginfo( 'name' );
} );この例ではロゴ画像を wp-content/mu-plugins/agency-assets/login-logo.png に置いています。初期状態のロゴ領域は小さいため、width と height をロゴの縦横比に合わせて調整します。表示が変わらないときは、ブラウザのキャッシュとキャッシュ系プラグインを確認し、開発者ツールでCSSが読み込まれているか、セレクタが他のCSSに負けていないかを見ます。
管理画面のフッターとバージョン表示を変える
管理画面の左下は admin_footer_text、右下は update_footer フィルターで変更します。右下にはコアが優先度10でバージョン表示を差し込んでいるため、それより後の優先度で上書きします。
// 左下のフッター文言をサポート窓口の案内にする
add_filter( 'admin_footer_text', function () {
return wp_kses(
'サイトの操作でお困りの際は <a href="https://example.com/support/">サポート窓口</a> までご連絡ください。',
array( 'a' => array( 'href' => array() ) )
);
} );
// 右下のバージョン表示を、管理者以外には表示しない
add_filter( 'update_footer', function ( $content ) {
if ( current_user_can( 'update_core' ) ) {
return $content;
}
return '';
}, 11 );右下の表示は、管理者には残しておくと保守作業の際に便利です。フッター文言の変更だけなら 管理画面フッターの文言を変える方法 でも詳しく扱っています。
管理バーとダッシュボードを整理する
管理バー左上のWordPressロゴメニューは、admin_bar_menu アクションで remove_node() を使って外します。ダッシュボードのウィジェットは wp_dashboard_setup アクションの中で remove_meta_box() を呼んで外し、代わりに wp_add_dashboard_widget() で案内用のウィジェットを追加します。
// 管理バーのWordPressロゴメニューを外す
add_action( 'admin_bar_menu', function ( $wp_admin_bar ) {
$wp_admin_bar->remove_node( 'wp-logo' );
}, 999 );
// ダッシュボードを整理し、案内ウィジェットを追加する
add_action( 'wp_dashboard_setup', function () {
remove_meta_box( 'dashboard_primary', 'dashboard', 'side' ); // WordPress イベントとニュース
remove_meta_box( 'dashboard_quick_press', 'dashboard', 'side' ); // クイックドラフト
remove_action( 'welcome_panel', 'wp_welcome_panel' ); // ようこそパネル
wp_add_dashboard_widget(
'agency_support_widget',
'サイト運用のご案内',
function () {
echo '<p>' . esc_html( '記事の更新方法は操作マニュアルをご覧ください。' ) . '</p>';
echo '<p><a href="' . esc_url( 'https://example.com/manual/' ) . '">操作マニュアルを開く</a></p>';
}
);
} );ようこそパネルの削除を wp_dashboard_setup の中に書いているのは、ファイルの読み込み時点ではまだコア側の登録が済んでおらず、早すぎる remove_action() は効かないためです。「サイトヘルス」ウィジェット（ID は dashboard_site_health）は、PHPのバージョンや自動更新の状態を知らせるので、少なくとも管理者向けには残しておくと保守に役立ちます。
クライアント用の権限グループを作る
クライアントには管理者権限を渡さず、編集者をベースにした専用の権限グループを用意するのがおすすめです。次の例は、編集者の権限に「外観」のメニューやウィジェット編集（edit_theme_options）を加えた権限グループを作ります。
// クライアント用の権限グループを一度だけ作成する
add_action( 'admin_init', function () {
if ( get_role( 'client_admin' ) ) {
return;
}
$editor = get_role( 'editor' );
if ( ! $editor ) {
return;
}
$caps = $editor->capabilities;
$caps['edit_theme_options'] = true;
add_role( 'client_admin', 'サイト担当者', $caps );
} );ただし、ブロックテーマのサイトでは edit_theme_options があるとサイトエディターでテンプレートやヘッダーも編集できるようになります。デザインを触らせたくない場合は、この1行を外して編集者と同じ権限にとどめます。
add_role() は権限をデータベースに保存するため、毎回の読み込みで作り直す必要はありません。権限の内容を後から変えたい場合は、remove_role( 'client_admin' ) で一度削除してから作り直すか、get_role() で取得したオブジェクトに add_cap() / remove_cap() を使います。作成後は「ユーザー」画面で、クライアントのアカウントの権限グループを切り替えて、実際にそのアカウントでログインし、見えてほしくないメニューが出ていないか確かめます。
あわせて wp-config.php に define( 'DISALLOW_FILE_EDIT', true ); を追加すると、管理画面からテーマやプラグインのファイルを編集する機能が無効になり、誤操作や乗っ取り時の被害を減らせます。権限の考え方は 編集者権限をカスタマイズする方法 も参考にしてください。
プラグインで済ませる場合
コードを書かずに済ませたい場合は、WordPress.org の公式ディレクトリにある「White Label CMS」や、管理メニューの並べ替え・非表示ができる「Admin Menu Editor」のようなプラグインが候補になります。設定画面の項目や無料版でできる範囲は更新で変わるため、導入前に配布ページで最新の説明を確認してください（2026年10月現在）。プラグインを使う場合も、クライアント用の権限設計は別に考える必要があります。
やってはいけない線引き
ホワイトラベル化には、ライセンスと信頼の両面で守るべき線があります。
- ライセンス: WordPressはGPLで配布されており、管理画面の表示を変えること自体は問題ありません。ただし、自社開発のCMSであるかのように説明したり、プラグインの作者表記やライセンス表示を消して再配布したりするのは避けます。見積書や契約書には「WordPressで構築」と明記しておくと誤解を防げます。
- セキュリティ更新を隠さない: 更新通知をクライアントから見えなくするのは、保守契約で制作会社が更新を担当している場合に限ります。その場合も、どの更新をいつ適用したかを定期的に報告します。誰も更新しない状態で通知だけを消すと、脆弱性が放置されます。
- 管理者アカウントの扱い: 解約や引き継ぎの際に、クライアントが自力で管理者権限を取り戻せるよう、管理者アカウントの情報と、ホワイトラベル用プラグインの場所・外し方を引き継ぎ資料に残しておきます。
まとめ
- ホワイトラベル化は、ログイン画面（
login_enqueue_scripts・login_headerurl・login_headertext）、管理画面フッター（admin_footer_text・update_footer）、管理バー、ダッシュボードの表示変更と、クライアント用の権限設計で構成します。 - 設定はテーマではなくmu-pluginsや専用プラグインに置くと、テーマ変更や更新の影響を受けません。
- 実務で効くのは表示を隠すことより権限の整理です。編集者をベースにした権限グループと
DISALLOW_FILE_EDITを組み合わせます。 - GPLのクレジットは残し、セキュリティ更新は隠さず報告することで、クライアントとの信頼を保てます。