WordPressでWikiサイトやナレッジベースを作るには、記事を「階層を持てるカスタム投稿タイプ」と「カテゴリー用のタクソノミー」で整理し、検索・リビジョン・編集権限を用途に合わせて設定するのが基本です。手早く始めたい場合はドキュメント用プラグインを使う方法もあります。この記事では、どちらの方法でも共通する設計の考え方と、自作する場合の手順、社内Wikiとして非公開にする方法までを解説します。
WordPressで作るWikiの向き・不向き
WordPressで作るWikiは、「決まったメンバーが書き、多くの人が読む」形に向いています。製品マニュアル、FAQ、社内の手順書、サポート用のナレッジベースなどが代表例です。ブロックエディターで画像や表を入れやすく、テーマで見た目を整えやすいのが利点です。
一方、不特定多数が自由に編集し、ノートページで議論しながら育てるタイプのWikiには、MediaWikiのような専用ソフトのほうが向いています。WordPressで同じことをしようとすると、編集権限の管理や荒らし対策の作り込みが大きくなります。誰が書くのかを最初に決めてから、構築方法を選んでください。
構築方法を選ぶ
ドキュメント用プラグインを使う
BetterDocsやHeroic KB（Heroic Knowledge Base）のようなドキュメント・ナレッジベース用のプラグインを使うと、ドキュメント用の投稿タイプ、カテゴリー別の一覧ページ、ドキュメント内検索、目次などがまとめて用意されます。デザインのひな形も付いているため、短期間で公開したい場合に向いています。
無料版と有料版で使える機能が分かれていることが多く、内容も変わることがあります（2026年10月現在）。導入前に公式ページで機能の範囲を確認し、WordPress.orgやベンダーのページで最終更新日と対応バージョンも見てください。プラグイン独自の投稿タイプに記事を入れるため、あとで別の方法に移るときはデータの移行が必要になる点も考慮しておきます。
カスタム投稿タイプで自作する
自作する場合は、ブロックテーマ（サイトエディターで編集できるテーマ）とカスタム投稿タイプを組み合わせます。必要な機能だけで構成でき、プラグインの仕様変更に左右されません。以下では、この方法の手順を紹介します。
ドキュメント用の投稿タイプとカテゴリーを作る
Wikiの記事は、通常の投稿とは分けて専用の投稿タイプに入れます。ブログ記事と混ざらず、URLも /docs/ 以下にまとめられるためです。固定ページのように親子関係を持たせられる「階層型」にしておくと、「導入ガイド > 初期設定 > メール設定」のような構造を作れます。
作業前にサイトのバックアップを取り、次のコードを wp-content/plugins/site-docs/site-docs.php として保存して、管理画面の「プラグイン」から有効化します。
<?php
/**
* Plugin Name: Site Docs
* Description: Wiki・ナレッジベース用の投稿タイプとカテゴリー
*/
if ( ! defined( 'ABSPATH' ) ) {
exit;
}
add_action( 'init', function () {
register_post_type( 'kb_doc', array(
'labels' => array(
'name' => 'ドキュメント',
'singular_name' => 'ドキュメント',
'add_new_item' => 'ドキュメントを追加',
),
'public' => true,
'hierarchical' => true, // 親子関係を持たせる
'has_archive' => true, // /docs/ を一覧ページにする
'rewrite' => array( 'slug' => 'docs' ),
'show_in_rest' => true, // ブロックエディターを使うために必要
'menu_icon' => 'dashicons-book',
'supports' => array( 'title', 'editor', 'excerpt', 'author', 'revisions', 'page-attributes' ),
) );
register_taxonomy( 'kb_category', 'kb_doc', array(
'labels' => array(
'name' => 'ドキュメントカテゴリー',
'singular_name' => 'ドキュメントカテゴリー',
),
'hierarchical' => true,
'show_in_rest' => true,
'show_admin_column' => true,
'rewrite' => array( 'slug' => 'docs-category' ),
) );
} );投稿タイプの名前を docs ではなく kb_doc にしているのは、ドキュメント系のプラグインと名前がぶつかるのを避けるためです。URL上の表記は rewrite の slug で docs にしています。supports の page-attributes を入れると、編集画面で親ドキュメントと表示順を指定できるようになります。
有効化したら「設定」→「パーマリンク」を開き、何も変えずに「変更を保存」を押してURLのルールを更新します。これを忘れると /docs/ 以下のページが404になります。確認方法は、テスト用のドキュメントを親子で2件作り、/docs/親のスラッグ/子のスラッグ/ で表示されるかを見ることです。
ブロックテーマで表示を整える
ブロックテーマでは、「外観」→「エディター」のテンプレート画面から、ドキュメントの個別ページとアーカイブページ用のテンプレートを追加できます。Wikiとして読みやすくするために、次の要素を入れるのがおすすめです。
- 最終更新日: 情報がいつ時点のものかを読者が判断できるようにする。投稿日ではなく更新日を表示する
- パンくずリストと親子のナビゲーション: 階層のどこにいるかを示す。コアのブロックだけでは足りない場合は、テーマやプラグインの機能を使う
- 同じカテゴリーのドキュメント一覧: クエリーループブロックで、同じカテゴリーの記事を並べる
- 目次: 長いドキュメントでは見出しへのリンクを冒頭に置く
Wikiらしさは、記事同士のリンクで生まれます。ブロックエディターのリンク挿入欄に記事名を入力すると、サイト内のドキュメントを検索してリンクできるので、関連する手順や用語の解説にはこまめにリンクを張ります。
検索を使いやすくする
ナレッジベースでは、読者の多くが検索から目的のページを探します。WordPress標準の検索は、タイトルや本文に入力した文字列が含まれる記事を返す仕組みのため、日本語でも動作はしますが、関連度の高い順に並べる力は強くありません。
まずは、記事タイトルに読者が検索しそうな言葉を入れ、抜粋に要点を書くだけでも見つけやすさは変わります。記事数が増えて検索結果が使いにくくなってきたら、検索用のプラグインや全文検索の仕組みを検討します。日本語の扱いは仕組みによって差が大きいため、テスト環境で実際の検索語を使って結果を比べてから導入してください。
リビジョンで変更履歴を管理する
コードで revisions を有効にしているため、ドキュメントを更新するたびにリビジョン（過去の版）が保存されます。編集画面の設定サイドバーからリビジョンの画面を開くと、版同士の差分を比較し、必要なら過去の版に戻せます。誤った編集の取り消しや、「いつ誰が何を変えたか」の確認に使えます。
リビジョンは記事ごとに増え続けるため、更新の多いWikiではデータベースが大きくなります。保存する数を制限したい場合は、wp-config.php に define( 'WP_POST_REVISIONS', 20 ); のように書くと、1記事あたりの保存数を20件までに抑えられます。設定を変更する前には wp-config.php のバックアップを取ってください。
編集権限を決める
誰が書けて、誰が公開できるかは、WordPressの権限グループで決めます。上のコードは通常の投稿と同じ権限の扱いなので、次のように使い分けられます。
- 寄稿者: 下書きを書けるが公開はできない。書いた内容を編集者がレビューしてから公開する運用に向く
- 投稿者: 自分のドキュメントを書いて公開できる
- 編集者: すべてのドキュメントを編集・公開できる。Wikiの管理役に割り当てる
複数人で同じページを編集するときは、別の人が編集中だと警告が表示される仕組みはありますが、同時に書き換えた内容を自動で統合する機能はありません。大きな改訂は担当者を決めて進めるほうが安全です。
社内Wikiとして非公開にする
社内向けのWikiなら、サイト全体をログイン必須にします。まず「設定」→「表示設定」で、検索エンジンにインデックスさせない設定を有効にします。そのうえで、wp-content/mu-plugins/ に次のファイルを置くと、未ログインのアクセスはログイン画面へ送られ、REST APIからも読めなくなります。
<?php
/**
* 社内Wiki用: 未ログインでの閲覧を止める
*/
// サイトの表示はログイン画面へ送る
add_action( 'template_redirect', function () {
if ( ! is_user_logged_in() ) {
auth_redirect();
}
} );
// REST API も未ログインでは使えないようにする
add_filter( 'rest_authentication_errors', function ( $result ) {
if ( true === $result || is_wp_error( $result ) ) {
return $result;
}
if ( ! is_user_logged_in() ) {
return new WP_Error( 'rest_not_logged_in', 'ログインが必要です。', array( 'status' => 401 ) );
}
return $result;
} );確認は、ブラウザのプライベートウィンドウでトップページ、ドキュメントのURL、/wp-json/wp/v2/kb_doc を開き、いずれもログインを求められる（またはエラーになる）かで行います。なお、この方法でもアップロードした画像やPDFは、ファイルのURLを知っていれば開けます。機密性の高い資料を添付する場合は、サーバー側でアップロードフォルダへのアクセスを制限するか、ファイルはWikiとは別の共有ストレージに置いてください。
まとめ
- WordPressのWikiは「決まったメンバーが書き、多くの人が読む」用途に向く。誰でも編集できるWikiには専用ソフトを検討する
- 手早く作るならBetterDocsやHeroic KBなどのプラグイン、柔軟に作るなら階層型のカスタム投稿タイプとタクソノミーで自作する
- 自作した後はパーマリンクを保存し直し、ブロックテーマで更新日・パンくず・関連記事を表示する
- 検索はタイトルと抜粋の工夫から始め、記事が増えたら検索の仕組みを見直す
- リビジョンで変更履歴を残し、権限グループで書く人と公開する人を分ける。社内用はログイン必須にし、添付ファイルの扱いにも注意する