5 分クイックスタート

最短で md サブドメイン配信を立ち上げるための手順です。 事前に DNS とサーバの土台が用意できていれば、所要時間 5〜10 分程度で https://md.example.com/ にアクセスして Markdown が返る状態まで持って行けます。

前提条件

本クイックスタートは 「DNS と SSL の準備が完了している」「md ホスト用の HTTP リクエストが WordPress に届く状態である」 を前提としています。これらが未準備の場合は先に DNS と Bootstrap を読んでセットアップしてください。

必要な環境

このページの全体像

これから次の 7 ステップを実施します。

1. プラグインインストール
2. md サブドメインの DNS 設定 (簡略)
3. プラグイン設定画面を開く
4. 一般タブで md_host を設定 + master switch ON
5. Bootstrap installer で md ホスト用 index.php を自動生成
6. Test renderer で出力プレビュー
7. ブラウザで https://md.example.com/ にアクセス

それぞれ実時間 30 秒〜2 分で済みます。詰まったら各ステップ末尾の「うまく動かないとき」 を参照してください。

Step 1: プラグインインストール

プラグインを WordPress にインストールして有効化します。この段階では md サブドメインに何もレスポンスは返りません (master switch が default OFF のため、503 が返る)。

Step 2: md サブドメインの DNS 設定

既に DNS が md.example.com を WordPress サーバへ向けている場合はこのステップはスキップしてください。 未設定の場合は概略を以下に示します。詳細は DNS と Bootstrap ページを参照してください。

必要な DNS レコード

サーバ側の設定

DNS だけでは不十分で、Web サーバ (Apache / Nginx / LiteSpeed) 側で md.example.com のドキュメントルートを WordPress と同じインストールに紐付ける 必要があります。 一般的なやり方は次のいずれかです。

• シンボリックリンク: md.example.com 用ドキュメントルートを WordPress ディレクトリへの symlink にする
• バーチャルホスト追加: Apache / Nginx で ServerName md.example.com のバーチャルホストを WordPress と同じドキュメントルートに向ける
• 共用ホスティングのサブドメイン機能: XServer / wpx / さくらインターネット / ConoHa WING 等のコントロールパネルで「サブドメイン追加」 → ドキュメントルートを WordPress と同じに指定

このプラグインは 「兄弟構成」 と 「ABSPATH 直下サブディレクトリ構成」 の 2 種類のレイアウトを Bootstrap installer でサポートしています。 どちらに該当するかは Step 5 で自動判定されます。

SSL 証明書

HTTPS で運用したい場合 (推奨)、md サブドメインに対する SSL 証明書を発行してください。 Let's Encrypt の DNS-01 / HTTP-01 認証で発行できます。 メインサイトが HTTP (http://) で運用されている場合は、md ホストも自動的に HTTP になります (ksmd_md_scheme filter で変更可能)。

Step 3: プラグイン設定画面を開く

プラグインを有効化すると、WordPress 管理画面のサイドバーに専用メニューが追加されます。

管理画面 URL

/wp-admin/admin.php?page=kashiwazaki-llmo-md

プラグインのトップレベルメニューは 「設定」直下の position 81 に配置されます。 アイコンは dashicons-text-page。実コードの該当箇所は次の通りです。

// admin/admin-loader.php
add_menu_page(
    __( 'Kashiwazaki LLMO Markdown Subdomain', '...' ), // page_title
    __( 'Kashiwazaki LLMO Markdown Subdomain', '...' ), // menu_title
    'manage_options',                                    // capability
    'kashiwazaki-llmo-md',                               // menu_slug
    'ksmd_render_settings_page',                         // callback
    'dashicons-text-page',                               // icon
    81                                                   // position
);

7 タブ構造

設定画面は次の 7 タブで構成されています (詳細は各タブのページ参照)。

1. 一般: master switch / kill switch / md_host (このページ Step 4 で扱う)
2. 対象範囲: post_type と route の ON/OFF
3. 出力: Schema header/footer / home_intro
4. Schema.org: post_type ごとの type マッピング
5. キャッシュ: backend と TTL
6. 言語: inLanguage の自動算出と明示指定
7. 診断: Test renderer / アクセスログ / 互換性チェック / Bootstrap installer / Export Import

Step 4: 一般タブ — md_host 設定

設定画面の「一般」 タブで md ホスト名を確認・調整し、master switch を ON にします。

md サブドメインのホスト名

「md サブドメインのホスト名」入力欄に、Step 2 で設定したサブドメインを入力します。 空欄のまま保存すると home_url() から「md. + メインホスト (www. 除去後)」が自動算出されます (実装は ksmd_default_md_host())。

master switch を ON にする

これで「md サブドメインで Markdown を配信する」状態に切り替わりました。ただしこの段階ではまだ Step 2 の DNS / Step 5 の Bootstrap が完了していないと、ブラウザからアクセスしても応答が得られません。

kill switch (緊急停止) について

画面下部の 🛑 kill switch ボタンは、運用中に何か問題が起きた時の 1 クリック緊急停止 です。 ON にすると md サブドメインへの全リクエストに HTTP 503 を返し、すべての ksmd キャッシュをフラッシュします。 メインサイト (www) には一切影響しません。Step 4 では使いません (default OFF のまま)。

Step 5: Bootstrap installer で md ホスト用 index.php 自動生成

md サブドメインのドキュメントルートに 「メインの WordPress に橋渡しする index.php」 を配置します。 このプラグインは SSH 不要・サーバへのファイル直接編集不要 でこの作業を完結できる Bootstrap installer を備えています。

診断タブを開く

設定画面の上部タブから「診断」 をクリック → 「md ホストブートストラップ」セクションまでスクロール。

md ドキュメントルートのパスを入力

index.php を生成

生成される index.php は次の 3 行 PHP で構成されます (実装: md-bootstrap-installer.php の ksmd_bootstrap_generate_template())。

<?php
/**
 * KSMD-BOOTSTRAP-MARKER v1
 * Generated by wp-plugin-kashiwazaki-llmo-md-subdomain on 2026-04-30T...
 * Do not edit manually. Use plugin admin UI to regenerate or remove.
 */
define( "WP_USE_THEMES", true );
require __DIR__ . "/../wp-blog-header.php";  // subdir 構成
// または
// require __DIR__ . "/../wp/wp-blog-header.php";  // sibling 構成

この 3 行が「md サブドメインに来たリクエストを WordPress に橋渡し」 する役割を果たします。 その後 template_redirect priority -1 で本プラグインがリクエストを捕捉し、Markdown を返却します。

3 重マーカーで安全性を担保

生成される index.php には KSMD-BOOTSTRAP-MARKER v1 という識別子が埋め込まれ、 さらに sha256 ハッシュとバージョン文字列の 3 重チェックで「本プラグインが生成したファイルかどうか」 を判定します。 手動編集された index.php や別の WordPress の index.php を 絶対に上書きしません。 削除時も同じ 3 重チェックがかかり、安全でない場合は警告して削除を中止します。

Step 6: Test renderer でプレビュー確認

実際にブラウザで md ホストにアクセスする前に、管理画面内で出力をプレビューできる Test renderer を使って動作確認します。

診断タブの Test renderer

「診断」 タブの「Test renderer」セクションに、メインサイト側の URL を入力します。 (例: https://example.com/sample-post/ や /sample-post/)

Test renderer の仕組み

Test renderer は管理者の admin cookie を md サブドメインに送れない (cookieless) 制約を、 wp_salt('nonce') ベースの HMAC-SHA256 token で代替しています。 実装は includes/security.php:

function ksmd_generate_test_token( $uri ) {
    $expires = time() + 300; // 5 分有効
    $payload = $uri . '|' . $expires;
    $sig     = hash_hmac( 'sha256', $payload, wp_salt( 'nonce' ) );
    return base64_encode( $expires . '.' . $sig );
}

md ホスト側 (core-functions.php) では ksmd_verify_test_token() でこのトークンを検証し、 一致すればキャッシュをバイパスして即時再生成して返します。 これにより「キャッシュに残った古い出力ではなく、今この瞬間の最新出力」 を確認できます。

Step 7: ブラウザで md ホストにアクセス

最後に、実際のブラウザから md サブドメインにアクセスして Markdown が返ることを確認します。

確認すべき HTTP ヘッダ

正しく動作している場合、md ホストのレスポンスには次のヘッダが付きます。

メイン側 (例: example.com) のレスポンスにも、本プラグインが ON のとき以下のヘッダが追加されます (alt-link 機能、デフォルト ON、出力タブで OFF 可):

メイン側 HTML <head> 内にも対応する <link rel="alternate"> + <link rel="describedby"> タグが出力されます (取りこぼし防止のため両出し)。curl -sI https://example.com/posts/foo | grep -i ^link で確認できます。

md ホストの favicon リクエスト (/favicon.ico 等 5 URI) は、本プラグインが ON のとき以下のレスポンスを返します (favicon proxy 機能、デフォルト ON、一般タブで OFF 可):

• HTTP/2 302 + Location: https://example.com/wp-content/uploads/.../favicon.png (Site Icon にリダイレクト)
• Cache-Control: public, max-age=86400 (1 日キャッシュ)
• 例外: /site.webmanifest のみ動的 JSON 生成 (PWA 互換)

確認用 URL

一般タブ下部の「動作確認」 リストから、以下の 3 つの URL を順にクリックして開いてみてください。

• https://md.example.com/ — md ホームの Markdown 出力
• https://md.example.com/robots.txt — md 専用 robots.txt (Sitemap 行を含む)
• https://md.example.com/sitemap.xml — md 用 sitemap index

robots.txt と sitemap.xml はメインサイト側のものとは別物です (md ホスト用に専用生成)。

個別記事の確認

メインサイトの記事 URL のホスト部分だけを md.example.com に置き換えてアクセスすれば、 その記事の md 版が見られます。例:

• メイン: https://example.com/articles/foo/
• md 版: https://md.example.com/articles/foo/

うまく動かないとき

最初のセットアップで遭遇しやすい問題と、対処の入口を以下にまとめます。 詳細は トラブルシューティング ページを参照してください。

症状別のチェックリスト

ログ確認

設定タブ「診断」 → 「アクセスログ」を ON にすると、md ホストへの全リクエスト (URI / status / 応答時間 / User-Agent) が {prefix}ksmd_access_logs テーブルに記録されます。 「クローラが来ているのに 404 ばかり」 のような状態を可視化できます。 ログは default 7 日間保持、IP は default 匿名化 (IPv4 末尾オクテット 0、IPv6 /64 マスク)。

互換性チェック

診断タブの「互換性チェック」 セクションでは、PHP バージョン・WP バージョン・必要拡張 (DOMDocument / libxml / mbstring / hash) の有無が一覧表示されます。 セットアップ初期にここで赤色項目が出ていないかを確認してください。

Cloudflare 経由で 403 が返るとき

md ホストを Cloudflare の Proxied (オレンジ雲) で運用している場合、Bot Fight Mode / WAF / Rate Limiting が AI クローラを弾いてしまうことがあります。 Bootstrap installer の verify でも HTTP 403 / 520-525 が返ったときに「Cloudflare WAF / Bot 判定の可能性」 として警告が出ます。 CF ダッシュボードで md サブドメインの WAF ルールを見直してください。

次のステップ

無事に https://md.example.com/ から Markdown が返るようになったら、 次は運用に必要な設定を順に詰めていきます。以下の 3 ルートをおすすめします。

運用ベストプラクティス (簡略版)

• 「対象範囲」 タブで配信したい post_type / route を絞り込む (例: attachment はそもそも default 除外、feed や date archive は不要なら OFF)
• 「キャッシュ」タブで TTL を運用に合わせる (短すぎるとサーバ負荷、長すぎると更新が反映されにくい)
• 「診断」 タブの「アクセスログ」を有効化して、最初の数日は来訪 bot の実態を観測
• 定期的に https://md.example.com/sitemap.xml を確認し、AI 検索ツール (Search Console / Bing / Perplexity 等) に md サブドメインを別プロパティとして登録
• 「設定 export / import」 で本番設定をバックアップしておく