Kashiwazaki LLMO Markdown Subdomain マニュアル

AI クローラ (ChatGPT / Claude / Perplexity / Gemini 等) 向けに、専用サブドメイン (例: md.example.com) でサイト本体の Markdown 並行版を配信する WordPress プラグインの公式マニュアルです。 メインサイト (example.com) の HTML 出力には一切手を加えず、AI 向けの最適化レイヤだけを別ドメインで上乗せします。

このプラグインで何ができるか

一言でいえば、「サイト本体に何も触らずに、AI 検索向けの Markdown 版サイトをサブドメインで増設する」 プラグインです。 既存の SEO 資産 (canonical URL、被リンク、検索順位、Yoast / RankMath 等の設定) を一切変更しないまま、 AI クローラが効率よく読める専用版を別ドメインに用意します。

もう少し具体的には、以下のような出力の差を 1 つの WordPress インストールから同時に提供できます。

つまり、「AI 向け版サイトを増設しても、SEO 観点の主役はあくまで www 側」 という設計を、HTTP / Schema.org / Markdown 本文の 3 層で一貫して宣言します。

全体ワークフロー

導入から配信までの流れは大きく 3 フェーズに分かれます。詳細は 5 分クイックスタート と DNS と Bootstrap で扱います。

フェーズ 1: インフラ準備 (1 回のみ)

1. サイトとは別の専用サブドメイン (例: md.example.com) を DNS で WordPress サーバへ向ける
2. サブドメインのドキュメントルートに、メインの wp-blog-header.php へ橋渡しする index.php を配置 (本プラグインの Bootstrap installer がワンクリックで自動生成)
3. SSL 証明書を発行 (Let's Encrypt 等)

フェーズ 2: プラグイン設定 (UI ですべて完結)

1. プラグインを有効化 (この時点では何も配信されない、master switch は default OFF)
2. 「一般」タブで md_host を確認、master switch を ON
3. 「対象範囲」タブで Markdown 化する post_type / route を選択 (default は全 ON)
4. 「出力」「Schema.org」「キャッシュ」「言語」タブで挙動を微調整
5. 「診断」タブの Test renderer で出力をプレビュー

フェーズ 3: 配信運用 (継続)

1. AI クローラが https://md.example.com/ 配下を巡回
2. Markdown を返却、内部リンクは md→md で完結
3. HTTP Link ヘッダで canonical を seo (www) に明示、authority/freshness/canonicalness は seo に帰属
4. 診断タブのアクセスログで来訪 bot を観測

対象読者

このマニュアルは以下の 3 タイプの読者を想定して書かれています。 自分に近い役割の章から読み進めてください。

サイト運営者・編集者

「ChatGPT や Perplexity に自社サイトの内容を正しく拾ってもらいたい」 「AI 検索の時代に何かしないと不安だが、SEO 設定は怖くて触れない」というニーズに応えます。 このプラグインは 既存サイトを 1 行も変えずに 別ドメイン経由で AI 向け配信を増設するため、 運用の心理的ハードルが極めて低いのが特徴です。

• まず 基本概念 で「なぜ別ドメインで Markdown を出すのか」を理解
• 次に 5 分クイックスタート で動かす
• うまく動いたら 対象範囲タブ で配信したい post_type を絞り込む

SEO / LLMO 担当・コンサル

既存の SEO 戦略 (canonical / OGP / JSON-LD / hreflang 等) を維持したまま、AI 検索向けのレイヤを上乗せしたい担当者向けです。 主従関係を HTTP Link ヘッダ・Markdown 冒頭の Canonical 注記・Schema.org の url フィールドの 3 層で seo (www) に宣言する設計を採用しています。

• Canonical の扱い で主従関係を確認
• Schema.org タブ で post_type ごとの type マッピングを調整
• 拡張ポイント の ksmd_schema_header_lines filter で独自プロパティを追加

開発者・プラグイン拡張者

プラグインの動作を WP のフィルタフックで拡張したい、社内ホスティング環境に合わせてカスタマイズしたい、 あるいは挙動を理解して別実装する必要がある開発者向けです。

• アーキテクチャ で URL 解決フロー・template_redirect 介入点を確認
• 拡張ポイント で公開済みフィルタの一覧と利用例
• 診断タブ の Test renderer / 互換性チェック / アクセスログを開発時の確認手段として活用

動作要件

マニュアルの読み方

このマニュアルは全 15 ページ構成です。「初めての方」「設定を追い込みたい方」「拡張したい開発者」の 3 タイプを意識した順番で並んでいます。 上から順に読めば自然に理解が深まりますが、目的別に必要なページだけ拾い読みすることもできます。

1. 概念編 (まず読むべき 3 ページ)

2. セットアップ編

3. 設定タブ編 (7 タブを 1 ページずつ解説)

4. 応用編 (開発者・上級者向け)

FAQ プレビュー

よくある最初の疑問に簡潔に答えます。詳細は トラブルシューティング・基本概念 を参照してください。

Q1. md ホストとは何ですか?

メインサイトのドメイン (example.com) とは別のサブドメイン (md.example.com 等) のことです。 このプラグインは「md ホストにアクセスされたときだけ」Markdown を返し、 メインホストのリクエストには一切介入しません。 md ホストの DNS 設定とサーバ側のドキュメントルート設定はユーザ側で行う必要があります (詳細は DNS と Bootstrap)。

Q2. メインサイトと何が違うのですか?

出力フォーマットが違います。メインは text/html を返し続け、md は text/markdown; charset=utf-8 を返します。 さらに md 側は X-Robots-Tag: noindex, follow ヘッダで Google 等の通常検索からはインデックスされないようになっています。 「人間と従来検索向けの www / AI クローラ向けの md」という役割分担です。

Q3. canonical はどう設定されますか?

md ページは HTTP Link: rel="canonical" ヘッダでメインサイト (www) の URL を canonical として参照します。 さらに Markdown 本文の冒頭にも > **Canonical:** https://example.com/... の blockquote が入り、Schema.org/Article の url フィールドも seo を指します。 つまり 「authority / freshness / canonicalness は seo 側に帰属、md は parallel version」 であることが HTTP・Markdown 本文・構造化データの 3 層で明示されます。

Q4. 既存の Yoast SEO や RankMath と併用できますか?

できます。本プラグインは md ホストのリクエストだけを処理するため、メイン側で動作する Yoast / RankMath / All in One SEO Pack 等の出力 (canonical / OGP / JSON-LD / sitemap) には一切干渉しません。 両者の責務がドメインで分離されている設計です。

Q5. 動かないときはまず何を見ればよいですか?

診断タブで以下の 3 つを確認してください。

1. 互換性チェック: PHP バージョン、必要拡張、WordPress バージョンが要件を満たしているか
2. md ホスト Bootstrap: md サブドメイン用 index.php が正しく配置されているか
3. Test renderer: 任意の URL を入力して、Markdown 出力をプレビューできるか

上記でも解決しない場合は トラブルシューティング のチェックリストを順に確認してください。

このプラグインの設計原則

ここまでで「何ができるか」 を見ましたが、それを支える設計上の原則も簡潔に押さえておきます。 細部の仕様判断はすべてこの原則から導かれているので、見えてくる挙動が一貫していると感じられるはずです。

原則 1. メインサイト無改変

プラグインのコードは HTTP_HOST が md ホストでなければ即 return します。 既存テーマ・SEO プラグイン・キャッシュプラグインの出力には一切の remove_action や wp_dequeue_* を行いません。「副作用ゼロ」 が文字通りの意味で実装されています。

原則 2. 既存資産を上回らない

md ページは canonical を seo (www) に向けることで、authority・freshness・canonicalness を seo 側に帰属させます。これにより「md がメインの SEO 順位を奪う」事態が起きません。 md は seo を AI に翻訳して見せるための補助レイヤであり、SEO 主役の地位は seo 側に残ります。

原則 3. Token 効率の最大化

HTML を Markdown に変換する際は、nav / aside / footer / script / style / form / iframe / noscript / svg / canvas を完全除外する ホワイトリスト方式を採用しています。AI コンテキストウィンドウ・API 課金の双方で効率を最大化します。

原則 4. 暴発しない default

master switch (enabled) は default OFF。プラグインを WordPress に有効化しただけでは md サブドメインに何も配信されません。一方で master switch を ON にした時点でユーザは「動かす意図」 を明示しているため、 post_type / route は default 全 ON で「ON にすれば全部動く」 ようになっています。 この組み合わせが「インストール直後の事故」 を最小化します。

原則 5. 緊急停止と通常運用の二段構え

運用中の問題への対応のため、master switch (通常 ON/OFF) と kill switch (緊急停止 + 全キャッシュフラッシュ) の 2 つを用意しています。 通常停止と緊急停止を分けることで、運用判断が明確になります。

原則 6. 観測専用、遮断しない

アクセスログ機能は「観測」 のためにあり、何も弾きません。bot 遮断は Cloudflare / WAF / DDoS L7 等の上位レイヤの責務です。 このプラグインは LLMO / GEO の趣旨に従って、AI クローラを歓迎する立場を採ります。

原則 7. SSH 不要のセットアップ

md サブドメインで動かすには、サブドメインのドキュメントルートに index.php を 1 つ置く必要がありますが、 この作業を診断タブの Bootstrap installer がワンクリックで自動化しています (atomic write + 3 重マーカー検証 + 24 時間 backup)。 非エンジニアの運用者でもセットアップを完結できます。

原則 8. 拡張可能性

主要な挙動はすべて apply_filters() 経由で外部から差し替え可能になっています。 ksmd_md_scheme, ksmd_host, ksmd_home_intro_markdown, ksmd_schema_type, ksmd_route_schema_header_lines, ksmd_route_schema_footer_lines, ksmd_archive_query_args 等。 詳細は 拡張ポイント を参照してください。

次のステップ

このマニュアルの構造に沿って、以下の 2 ルートのどちらかから読み進めることをおすすめします。

それぞれの章はクロスリンクで相互参照しているので、必要に応じて行ったり来たりしてください。 また、すべての設定タブの説明にはスクリーンショットと、必要に応じて実コードに対応する説明が含まれています。