WordPressサブディレクトリ入門｜本当に有利？判断基準をわかりやすく解説

2026年2月25日

「ブログを example.com/blog/ に置くとSEO的に有利って聞いたけど、本当？」
「サブドメイン（blog.example.com）よりサブディレクトリのほうがいいの？」
「すでに直下で運用してるけど、後から /blog/ に移すと順位が落ちる？」
「WordPress本体をサブに置いて、表示は直下にする“コア分離”って何がいいの？」
「結局、自分のサイトはどの構造が正解なのか判断できない……」

WordPressのサブディレクトリは、うまく使えばサイト全体の設計が整理されて、SEOや運用が安定しやすい一方で、目的を間違えると評価の分散・カニバリ・移行トラブルにつながり、遠回りになることもあります。
特に「/blog/が正解」と決めつけて始めてしまうと、あとから構造変更が必要になって手間もリスクも増えがちです。

この記事では、初心者でも迷いを終わらせられるように、

サブディレクトリ／直下／サブドメインの違い
“本当に有利か？”を判断するための基準（SEO・運用・将来の拡張）
新規で作る場合／直下表示にする場合／既存サイトを移行する場合の考え方
よくある失敗パターンと、事故を防ぐチェックポイント

を、できるだけ分かりやすく整理します。

読み終えるころには、あなたの目的に対して
「どの構成を選べばいいか」「どこに気をつければいいか」が、はっきり決まるはずです。

最初に結論：あなたの目的はどのパターン？（ここで迷いを終わらせる）

サブディレクトリ運用は、ざっくり言うと「URLの見せ方」と「WordPress本体の置き場所」をどう分けるかの話です。
まずは、あなたがどのゴールに近いかで決めるのが最短です。

パターンA：URLも「/◯◯/」で公開（例：example.com/blog/）

結論：ブログやメディアを“サイトの一部”として増築したい人に最もわかりやすい選択肢です。

向いているケース

コーポレートサイト＋オウンドメディア（例：/blog/）
サービスサイト＋ヘルプ（例：/help/）
テーマ（話題）がメインサイトと強く関連している

メリット

URL構造が直感的で、ユーザーにも検索エンジンにも説明しやすい
管理がシンプル（「/blog/ はブログ」みたいに迷子になりにくい）
サイト全体の内部リンク設計が組みやすい（回遊を作りやすい）

注意点（ここで差がつく）

メインサイトと無関係なテーマを増やしすぎると、サイト全体の一貫性が薄くなる
カテゴリ／タグを増やしすぎると、同じ検索意図のページが増えてカニバリになりやすい

初心者向けの実務イメージ

まずサブディレクトリ（/blog/ など）を作る
そこにWordPressを普通にインストールして運用する
パンくず・内部リンク・カテゴリ設計を「親サイトとつながる形」で整える

パターンB：WordPress本体は「/◯◯/」に置くが、表示URLはドメイン直下（例：example.com）

結論：サイトは直下表示のまま、WordPressの“置き場所だけ”をサブディレクトリに逃がしたい人向けです。
（ファイルがルート直下に散らかるのが嫌、など）

向いているケース

すでに example.com でサイト運用していて、URLを変えずに整理したい
ルート直下の構造をスッキリさせたい（運用・保守の都合）

メリット

見た目のURL（example.com）はそのままなので、URL変更に伴う移行対応が基本いらない
WordPress関連ファイルをサブディレクトリ側にまとめやすい

注意点（ミスが多いポイント）

「WordPressアドレス」と「サイトアドレス」を混同すると詰みやすい
- 間違えると、ログインできない／リダイレクトループなどが起きがち
ルート側に置く index.php や .htaccess の調整が必要になることが多い
キャッシュ系・セキュリティ系プラグイン、CDN/WAFが絡むと挙動が変わることがある

初心者向けの安全な進め方（要点だけ）

作業前にバックアップ（ファイル＋DB）
影響が出る可能性があるので、メンテナンス表示ができると安心
公式手順の考え方に沿って
- サイトの表示先（直下）
- WordPress本体（サブディレクトリ）
  を正しく分けて設定する

パターンC：既存サイトを「直下→サブディレクトリ」へ引っ越し（URLを変える／変えない）

結論：ここは“移行案件”です。やり方を間違えるとSEOも運用も崩れます。
初心者ほど「URLを変えるのか／変えないのか」を最初に固定してください。

1) URLを変えない（表示は直下のまま）

実態（WordPress本体の置き場所）だけをサブディレクトリに移して、表示URLは維持する形
基本的に「パターンB」の考え方に近い

メリット

URLが変わらない＝移行ダメージを抑えやすい

注意点

設定ミスがあると、ログイン不可・表示崩れ・404が出やすい

2) URLを変える（example.com → example.com/blog/ など）

ここが一番大事：URLを変えるなら、必ずリダイレクト設計が必要です。

やることは大きく3つです。

301リダイレクト（旧URL → 新URL）
内部リンク・サイトマップ・正規URLの更新
Search Consoleでの監視（クロールエラー、インデックス、順位の揺れ）

初心者が事故りやすいポイント

“なんとなく”でトップだけリダイレクトして終わる（→下層が死ぬ）
旧URLと新URLが混在して、二重インデックスや評価分散が起きる
画像やCSSのパスが変わって表示が崩れる

パターンD：1ドメインで複数サイト（別インストール／マルチサイト）

結論：運用体制（誰が・何サイトを・どう更新するか）で決める領域です。SEOだけで決めると後悔しやすいです。

選択肢は主に2つ

別インストール（サブディレクトリごとにWordPressを個別設置）
- 例：/blog/ はブログ用、/academy/ は講座用…など
マルチサイト（1つのWordPressで複数サイトを管理）

別インストールが向くケース

サイトごとにテーマやプラグインを大きく変えたい
障害が起きたときに影響範囲を分けたい（切り離し重視）

マルチサイトが向くケース

共通ルールで量産・運用したい（更新者・権限設計が整理されている）
テンプレ・機能を共通化して管理コストを下げたい

注意点（初心者が見落としがち）

マルチサイトは便利ですが、あとからの要件追加で「制約」が効いてくることがあります
どちらにせよ、メインサイトと無関係な第三者コンテンツを置く運用は危険です
（“サイトの評判”を利用した不正行為と見なされるリスクがあるため）

判断の基準（SEO・運用・将来の拡張・トラブル耐性）

最後に、迷ったらこの表で決めるのが早いです。

スクロールできます

迷いどころ	おすすめ	理由
とにかくシンプルに始めたい	パターンA	URLも運用も直感的で、失敗しにくい
URL（example.com）を変えたくない	パターンB（またはCの“URLを変えない”）	表示URLを維持でき、移行対応が小さくなる
URLを /blog/ に変えて整理したい	パターンC（URLを変える）	構造を作り直せるが、移行設計が必須
1ドメインで複数サイトを本格運用したい	パターンD	体制・権限・更新フローで最適解が変わる

SEOで一番重要な判断軸（初心者向けに一言）

メインサイトと同じ“目的・テーマ”で伸ばすならサブディレクトリは相性がいい
逆に、テーマが別物なら「同じドメインに押し込む」より、構造やブランド設計から見直した方が安全なこともあります

サブディレクトリの基礎知識（ルート・サブドメインとの違いを1ページで）

ルートディレクトリ／サブディレクトリとは（URLとサーバー構造の対応）

まず、言葉をシンプルに整理します。

ルートディレクトリ（ドキュメントルート）：
Webで公開される“起点”のフォルダ（例：public_html や /var/www/html）
サブディレクトリ：
その起点の中に作る“下位フォルダ”（例：public_html/blog/）

基本イメージ（超ざっくり）
URLの階層＝フォルダの階層、になりやすいです。

スクロールできます

ブラウザで見るURL	サーバー上の場所（例）	意味
`https://example.com/`	`public_html/`	ルート（トップ）
`https://example.com/blog/`	`public_html/blog/`	サブディレクトリ（ブログ）
`https://example.com/help/`	`public_html/help/`	サブディレクトリ（ヘルプ）

ただし、ここが初心者のつまずきポイントです。

WordPressのようなCMSは、URLとフォルダが“完全に1対1”とは限りません
例：WordPress本体を example.com/wp/ に置いても、設定次第で表示URLを example.com/ にできます。
これは、index.php や .htaccess のルール（リライトルール）で「見せ方」を変えられるためです。

💡つまり、サブディレクトリは「URLの階層」でもあり「サーバー上の整理単位」でもありますが、CMSでは“見た目のURL”と“実体の置き場所”がズレることがある、と覚えると理解が早いです。

サブドメインとの違い（URL構造・“同一サイト扱い”のされ方の傾向）

サブディレクトリとよく比較されるのがサブドメインです。

サブディレクトリ：example.com/blog/
サブドメイン：blog.example.com

違いは「URLの見た目」だけではなく、運用上の切り分けに出ます。

サーバー・設定の違い（初心者向けに）

サブドメインは、DNSやサーバー設定で別の入口（別のサイト置き場）として作ることが多い
サブディレクトリは、同じサイトの中でフォルダを分けることが多い

“同一サイト扱い”の傾向（断言しない版）

検索エンジン的には、どちらも評価され得ます。
ただ、実務では
- サブディレクトリ：同一サイト内の拡張として設計しやすい
- サブドメイン：別サイトのように切り分けて運用しやすい
  という“使われ方の違い”がよくあります。

管理面で分かりやすい差：Search Consoleの見え方

Search Consoleでは、URL単位（例：https://example.com/blog/）で管理することもできますし、ドメイン全体をまとめて管理する考え方もあります。
「分けて見たい・まとめて見たい」の方針で、管理が変わるのがポイントです。

💡Google自身も「ビジネス上意味があるならどちらでも良い」という趣旨で述べています。
なので、SEOだけで決め打ちするより、“運用でどう切り分けたいか”→“URL設計”の順で決めるのが失敗しにくいです。

よくある利用シーン（コーポレート配下のメディア、機能別の整理など）

サブディレクトリがよく使われるのは、「同じブランド・同じ目的のまま、役割を分けたい」ときです。

王道の使い方（イメージしやすい順）

example.com/blog/：オウンドメディア・コラム
example.com/news/：お知らせ
example.com/recruit/：採用情報
example.com/support/ or example.com/help/：FAQ・マニュアル
example.com/case/：導入事例
example.com/academy/：学習コンテンツ・用語集

整理のコツ（独自性が出やすい考え方）

サブディレクトリ名は「役割（用途）」で切ると、後から拡張してもブレにくい
例：/blog/（発信）・/support/（サポート）・/recruit/（採用）など
逆に、テーマがバラバラなものを同居させると
ユーザーも検索エンジンも“何のサイト？”になりやすい
→ サブディレクトリは増やせば良いわけではありません。

注意が必要な利用シーン

テストサイトを example.com/test/ のように置くケース
→ 公開したままだと検索に出ることがあるので、アクセス制限やnoindexなどの対策が必要です。

SEOで失敗しないための前提（「作り方」より先にここが重要）

サブディレクトリは“同一サイト内の拡張”になりやすい：テーマの一貫性が最重要

サブディレクトリ（例：example.com/blog/）は、ユーザー視点でも「同じサイトの中のコーナー」として認識されやすい構造です。
だからこそSEOでは、サイト全体のテーマ（何のサイトか）と、サブディレクトリの役割が噛み合っているかが重要になります。

初心者が最初にチェックすべきポイントは、次の3つです。

目的の一致：本体サイトの目的と、サブディレクトリの目的がつながっているか
読者の一致：読者層（悩み・知識レベル・意思決定）が大きくズレていないか
導線の一致：サブディレクトリのページが、本体サイトの価値（商品・問い合わせ・信頼）に自然につながるか

これが揃うと、内部リンクや回遊設計も作りやすく、結果として評価も積み上げやすくなります。

本体サイトと関連しないテーマ混在が招くリスク（専門性の低下・評価の分散）

ありがちな失敗は、「記事数が増える＝強くなる」と思って、無関係なテーマを同じドメイン配下に増やしてしまうことです。

起こりやすい問題は、次の通りです。

専門性が薄まる
“何のサイトかわからない”状態になり、強みが伝わりにくくなります。
内部リンクの説得力が落ちる
関連しない記事同士は自然につながらず、回遊が弱くなります。
評価が分散しやすい
サイト内に別ジャンルの「小さなサイト」が乱立し、どこも伸びきらない状態になりがちです。

判断に迷ったら、次の質問を自分に投げてみてください。

そのサブディレクトリは、本体サイトの訪問者が「次に読みたい」と思う内容か？
“そのテーマだけ”で独立したサイトとして成立するほど別物ではないか？
そのコンテンツは、本体サイトの信頼・専門性を上げる方向か、散らす方向か？

YESが減るほど、サブディレクトリより「サブドメイン」や「別ドメイン」を検討する価値が上がります。

キーワード・カテゴリ設計でカニバリを防ぐ

サブディレクトリ運用で地味に効くのがカニバリ対策です。
（同じ検索意図のページが複数できて、順位が安定しない状態）

カニバリを減らす設計のコツは、「先に地図を作る」ことです。

おすすめの進め方（初心者でも再現しやすい）

検索意図を“目的”で分類する
- 例：比較したい／やり方を知りたい／料金を知りたい／トラブル解決したい
各意図に“代表ページ（柱）”を1つ決める
- 代表ページ：その意図で最も強くしたい1ページ
関連する子記事は“役割”を固定する
- 体験談、手順の詳細、用語解説、注意点、比較表…など
カテゴリは少なめ、タグは増やしすぎない
- 似た一覧ページが大量にできると、評価が散りやすいです

整理に便利な簡易表（自分のサイト用に埋めて使えます）

スクロールできます

検索意図	代表ページ（柱）	子記事の役割	やらないこと
比較したい	A vs B の比較	条件別おすすめ、体験談	似た比較記事を量産
やり方を知りたい	手順まとめ	画像付きの補足、トラブル集	手順記事を細切れに乱立
困りごと解決	トラブル総合	症状別の詳細	同じ症状の記事を複数作る

サブドメイン／新規ドメインと使い分けるべきケース

「サブディレクトリが良い／悪い」ではなく、運用の切り分けで決めると失敗しにくいです。

サブディレクトリが向きやすい

本体サイトとテーマが同じ（サービス理解を深める記事、ヘルプ、事例など）
同じ読者に向けた情報で、内部リンクを強く組みたい
更新・管理をシンプルにしたい

サブドメインが向きやすい

本体と目的が違う（例：サポートセンター、学習サイト、アプリなど）
技術基盤や運用ルールを分けたい（別CMS、別チーム、別サーバーなど）
失敗時の影響範囲を切り分けたい

新規ドメインが向きやすい

ブランドやテーマが完全に別物
本体サイトの信頼性を“薄めたくない”
将来的に売却・事業分離なども視野にある

迷ったときは、次のどれが強いかで決めると早いです。

一体運用したい → サブディレクトリ
切り分けて管理したい → サブドメイン
ブランドごと独立したい → 新規ドメイン

やってはいけない運用：第三者コンテンツを置く“ドメイン貸し”リスク

サブディレクトリで特に危険なのが、いわゆる 「第三者の都合で作られたページを置く」運用です。

たとえば、外部の業者が

本体サイトと無関係な商用ページを量産する
本体サイトの評価（信頼・被リンク・歴史）を借りる目的で掲載する

こういった形は、検索エンジン側で問題視されやすい領域に入ります。

安全側に倒すなら、次を満たす形に寄せてください。

誰が責任を持って編集・品質管理するかが明確
本体サイトの読者にとって必要な情報として成立している
“検索で上げるためだけ”のページになっていない

検索ポリシー回避（サブディレクトリ/サブドメイン悪用）に関する注意点

注意したいのは、「サブディレクトリだからOK」「サブドメインにしたからセーフ」といった話ではない点です。
構造ではなく“意図と実態”が見られます。

リスクを下げるための現実的な対策は、次の順で考えるのが安全です。

まず 企画そのものを見直す（本体と関係が薄いなら独立させる）
掲載するなら 編集権限と品質基準を自社側に置く
“場所を変えて隠す”発想（サブドメインに逃がす等）より、ユーザー価値で成立させることを優先する

Search Console・サイトマップ・robotsの設計（インデックス事故を防ぐ）

サブディレクトリ運用で多い事故は、作ったのに検索に出ない／出したくないのに出る、です。
これは多くの場合、「クロール」と「インデックス」の違いを混同して起きます。

robots.txt：主に クロールの制御
noindex（metaタグやHTTPヘッダー）：インデックス登録の制御

特に重要な注意点：

robots.txtでブロックしても、状況によってはURL自体が検索結果に出る可能性があります
逆に、noindexを効かせたいページをrobots.txtでクロール禁止にすると、noindexが読み取られず意図通りにならないことがあります

初心者向けのおすすめ運用（シンプル版）

公開したいページ
- クロールOK
- サイトマップに載せる
公開はするが検索には出したくないページ（例：サンクスページ、テスト）
- noindexを優先
- robots.txtは補助（過信しない）
そもそも見せたくないページ（例：開発用、機密）
- パスワード保護など サーバー側で遮断

プロパティ設計（ドメイン/URLプレフィックス）と移行時のチェック

Search Consoleは、見たい範囲に合わせて「プロパティ」を作れます。
サブディレクトリ運用で使いやすいのは次の考え方です。

ドメイン全体を俯瞰する用：ドメイン（Domain）プロパティ
/blog/ だけ細かく見る用：URLプレフィックス（https://example.com/blog/）プロパティ

こうしておくと、

サイト全体の問題（セキュリティ、全体的なインデックス異常）
サブディレクトリ固有の問題（/blog/配下だけ急に除外、クロール急減）

を切り分けて追いやすくなります。

移行時（例：直下→/blog/ に構造変更）の最低限チェック

新旧URLが混在していないか（内部リンク、canonical、サイトマップ）
主要ページがインデックスされているか（URL検査の活用）
404・リダイレクト・ソフト404が増えていないか
サイトマップが正しく受理されているか
robots/noindex設定が意図通りか

ここを押さえるだけで、「気づいたら検索流入が落ちていた」をかなり防げます。

作業前のチェックリスト（事故の9割は準備不足）

バックアップ（ファイル＋DB）と“復元テスト”

サブディレクトリ化（移行／配置変更）は、「ファイル」＋「データベース」の両方が揃って初めて“戻せる状態”になります。
どちらか片方だけだと、復旧できても 表示崩れ・リンク切れ・ログイン不能が起きやすいです。

最低限バックアップするもの（初心者向け・これだけでOK）

✅ データベース（DB）
✅ WordPress本体のファイル
- wp-content/（特に重要：テーマ・プラグイン・uploads）
- wp-config.php
- .htaccess（ある場合）
- 可能なら robots.txt（運用している場合）

よくある勘違い

画像は「メディア」だからDBに入っている → ❌
画像の実体は多くの場合 wp-content/uploads/ にあります。

“復元テスト”は難しく考えなくてOK（簡易版で十分）

「復元テスト」と聞くと身構えますが、初心者はまず “バックアップが使えるか”の確認だけでも効果が大きいです。

簡易チェック（現実的で失敗しにくい順）

バックアップファイルが開けるか
- zipが壊れていない／サイズが極端に小さくない
DBがエクスポートできているか
- .sql が出力されている（中身が空でない）
できれば 別環境で1回だけ復元手順をなぞる
- ローカルやステージングに
  「ファイル配置 → DBインポート → 表示確認」まで

復元テストで見るポイント（全部やらなくてOK）

トップが表示される
管理画面に入れる
画像が数枚表示される（uploadsが戻っている目印）

メンテナンス表示・作業時間帯・ロールバック手順

移行中に更新が入ると、差分が発生して 「移したのにデータが消えた」が起きます。
初心者ほど、作業を始める前に“止め方”と“戻し方”を決めておくのが安全です。

メンテナンス表示は「見せ方」より「止め方」が大事

目的は2つだけ

ユーザーに「いま作業中」と伝える
フォーム送信・コメント・購入など、更新系の操作を止める

可能なら、メンテナンス中に検索エンジンへ「一時的な停止」と伝わりやすい状態にしておくと、余計な誤解を招きにくくなります（対応しているプラグインもあります）。

作業時間帯の考え方（初心者向けの現実解）

アクセスが少ない時間帯を選ぶ（深夜・早朝など）
ただし “自分が落ち着いて確認できる時間”を優先
→ 焦ると、URL設定やリダイレクトのミスが増えます

ロールバック（戻す手順）を“先に”書いておく

ここが一番効きます。
作業前に、メモでいいので 「失敗したらこう戻す」を1枚作ってください。

ロールバック用メモ（テンプレ）

戻す対象：ファイル / DB / DNS / CDN設定
戻し方：
- ファイル：バックアップを上書き
- DB：バックアップSQLをインポート
- DNS：切替前に戻す（触る場合のみ）
- CDN/WAF：一時停止した設定を元に戻す
判断基準（例）：
- 管理画面に入れない
- トップが真っ白（500）
- リダイレクトループが止まらない

ポイント
「直す」より先に「戻す」を用意すると、事故が“致命傷”になりにくいです。

キャッシュ/セキュリティ系プラグイン・CDN・WAFの影響確認

サブディレクトリ移行で厄介なのは、設定が正しくても キャッシュやWAFが古い状態を見せたり、転送を上書きしたりすることです。
「自分は直したのに直ってない」状態の原因がここにあることが多いです。

まずは“二重キャッシュ”を疑う

キャッシュは、だいたい次のように重なります。

ブラウザキャッシュ
WordPressキャッシュ系プラグイン
サーバー側キャッシュ（LiteSpeed/Nginx/ホスティングの最適化など）
CDNキャッシュ（例：Cloudflare）
画像最適化・遅延読み込み系のキャッシュ

移行前にやること（最低限）

✅ キャッシュ系プラグインの設定を把握（メモでOK）
✅ 「圧縮」「結合」「自動最適化（JS/CSS）」が有効なら一時的に弱める判断も持つ
→ 移行直後は“表示確認”が最優先のため

CDN/WAF（Cloudflare等）を使っているなら、ここだけ確認

移行前にチェックしたい代表例

自動HTTPSリダイレクト／www統一／ページルール
WAFのルール（/wp-admin/ の保護や制限）
キャッシュの削除方法（全部消すのか、URL単位で消すのか）

初心者がハマりやすい症状

変更したのにCSSが変わらない → CDNキャッシュが残っている
急にログインできない → WAFやセキュリティプラグインがブロック
リダイレクトループ → サーバー側とCDN側で“二重に転送”している

SSL・混在コンテンツ・リダイレクトの現状把握

サブディレクトリ関連の作業は、URL設定やリライトが触れやすいので、HTTPS・www統一・転送の状態を“作業前に固定”しておくと事故が減ります。

まず現状を棚卸し（作業前にスクショ推奨）

次の4つを、今のサイトで確認してメモします。

http://example.com → どこに飛ぶ？
https://example.com → どこに飛ぶ？
http://www.example.com → どこに飛ぶ？
https://www.example.com → どこに飛ぶ？

理想は「最終到達URLが1つ」です。
ここがバラついたまま移行すると、あとで原因切り分けが一気に難しくなります。

混在コンテンツ（Mixed Content）のチェックは「移行前」がおすすめ

HTTPSページの中に、http:// の画像やスクリプトが混ざると、ブラウザがブロックして

デザインが崩れる
ボタンが動かない
フォームが送れない

などが起きます。

チェック方法（初心者でも簡単）

ブラウザの開発者ツール（Console）で警告を見る
“httpで読み込まれている素材”がないか確認する

移行後に起きると「移行が原因なのか、元からなのか」が分かりにくいので、事前に把握しておくと安心です。

リダイレクトの“二重管理”に注意

リダイレクトは複数箇所で設定できます。

WordPress（サイトURL設定）
.htaccess やサーバー設定
CDN側のHTTPS設定やページルール

このうち2つ以上が同じ方向へ転送していると、ループや転送チェーンが起きやすくなります。

事前の安全策

どこで転送しているか（サーバー／CDN／WP）を把握する
“片方に寄せる”意識を持つ（全部に入れない）

パターンA：サブディレクトリでそのまま公開する（example.com/blog/）

サブディレクトリ作成〜WordPress新規インストール（最短手順）

最短で失敗しにくい流れは、「置き場所を作る → WordPressを入れる → ブラウザで初期設定」です。
（多くのレンタルサーバーには“簡単インストール”がありますが、やることの本質は同じです）

サーバー側（ディレクトリ/DB/権限/接頭辞）

1）サブディレクトリ名を決める（最初に固定）

サブディレクトリ名は、後から変えると移行コストが跳ね上がります。
迷ったら、次のルールで決めると安全です。

短い英字（例：blog media news help）
小文字のみ（URLのブレを避ける）
意味が役割に直結（“何がある場所か”が分かる）

2）サーバーにフォルダを作る

例：public_html/blog/ を作成
ここが公開URL https://example.com/blog/ になります

3）動作環境をチェック（“推奨”だけ押さえればOK）

サーバー側で、最低限これが満たせると安心です。

スクロールできます

チェック項目	目安
PHP	推奨バージョンを満たす
DB	MySQL または MariaDB の推奨バージョンを満たす
Webサーバー	Apache / Nginx でリライトが使える
HTTPS	SSLが有効（常時HTTPS）

※数値まで厳密に覚える必要はありません。「WordPress公式の推奨を満たすか」だけで十分です。

4）データベース（DB）を作成する

サーバーパネルで以下を作ります。

データベース名
DBユーザー名
強いパスワード
ユーザーにDBへの権限を付与

ここで初心者がやりがちなのがパスワードの弱さです。
後からログインできるか不安なら、パスワード管理ツールに保存しておきましょう。

5）WordPressを配置する（2択）

A：簡単インストール（おすすめ）

サーバーの管理画面で
「インストール先：/blog/」を選ぶだけで完了することが多い

B：手動インストール（仕組みを理解したい人向け）

WordPressを公式サイトからダウンロード
解凍した中身を /blog/ フォルダ直下へアップロード
https://example.com/blog/ にアクセスしてインストール開始

6）パーミッション（権限）を雑にしない

「動かないから 777」は避けた方が安全です。
一般的には、次の目安で困ることは少ないです。

フォルダ：755
ファイル：644

（サーバーや環境により最適値は異なるので、まずは“過剰に緩めない”が大事です）

WordPress初期設定（パーマリンク・日本語URL・メディア設定）

1）インストール画面で最低限ここだけ慎重に

サイトタイトル：後から変えられる（仮でもOK）
ユーザー名：admin は避ける
パスワード：自動生成の強いもの推奨
メール：必ず受け取れるもの
「検索エンジンがインデックスしないようにする」：公開サイトならチェックしない

2）パーマリンク設定（SEOの土台）

多くのサイトで扱いやすいのは、投稿名ベースです。

例：/%postname%/

ポイントは2つだけ。

一度決めたら、むやみに変えない（URLが変わる＝移行になる）
表示が崩れたり404が出るときは、まず「変更を保存」で再生成（いわゆる“フラッシュ”）を試す

3）日本語URL（スラッグ）の方針を決める

結論としては、どちらでも運用できます。ただ、初心者が迷いにくい方針はこれです。

記事URLは 英数字（短く）にする
理由：共有・管理・リダイレクト時に扱いやすい

例）

OK：/blog/wordpress-subdirectory/
慎重に：/blog/ワードプレス-サブディレクトリ/

「最初は日本語で作ってしまった…」でも致命的ではありません。
ただし後から直すなら、リダイレクトまで含めて設計が必要になります。

4）メディア設定（最低限）

ここは凝りすぎなくてOKです。初心者は次だけ意識すると十分です。

アップロード先の整理（年月フォルダ）：基本はONのままで問題なし
画像サイズ：テーマに合わせて後から調整でOK
（最初から追い込みすぎると、設定変更で再生成が必要になりがちです）

公開前に必ずやるSEO初期設定

公開直前に“SEOの初期事故”を潰すだけで、後悔が一気に減ります。

noindex解除の確認／XMLサイトマップ／robots.txt

1）noindex事故を防ぐ（最優先）

WordPressには「検索エンジンに見せない」設定があります。
これがONのままだと、公開しても検索に出にくくなります。

設定画面で「検索エンジンがサイトをインデックスしないようにする」が OFF になっているか確認

2）XMLサイトマップを確認する

WordPressは標準でXMLサイトマップ機能を持っています（環境によってはURLが決まっています）。

サイトマップURLにアクセスして表示されるか
SEOプラグインを使う場合
→ サイトマップが二重にならないように、どちらを使うか方針を決める

初心者向けの考え方はシンプルです。

「送信するサイトマップは1系統」にしておく
（運用中に混乱しにくい）

3）robots.txtは“検索に出さない設定”ではない

ここ、勘違いが多いポイントです。

robots.txt は主に クロールの制御
検索結果に出したくないなら、基本は noindex や認証（非公開化）

また、サブディレクトリ運用で重要なのは、

robots.txt は通常 ドメイン直下（ルート）に置く
例：https://example.com/robots.txt

/blog/robots.txt を作っても効かないケースがあるので、まずはルートの状態を確認しましょう。

内部リンク・パンくず・カテゴリ構造（“階層が明確”を活かす）

サブディレクトリの強みは、「ここからここまでがブログ」と構造を明確にできることです。
これをSEOに活かすなら、公開前に次の3点だけ整えるのがおすすめです。

1）カテゴリは“少数精鋭”でスタート

最初から細かく分けすぎると、薄い一覧ページが増えやすくなります。

目安：まず 5〜8カテゴリくらい
各カテゴリは「何を学べる場所か」が一言で説明できる粒度にする

2）パンくずを有効にして、階層を分かりやすくする

パンくずは、ユーザーにも検索エンジンにも「位置関係」を伝えやすい要素です。

最低限の形としては、これで十分です。

トップ（/blog/）
→ カテゴリ
→ 記事

テーマで標準対応していればそのまま使い、未対応なら定番のSEO系プラグインなどで補うイメージでOKです。

3）内部リンクは“戻り道”を用意するだけで強くなる

初心者が最初にやるべき内部リンクは、凝った設計よりも 基本動線です。

記事の冒頭 or 末尾に「関連カテゴリ」「関連記事」を置く
重要記事（柱）へ自然に戻れるリンクを作る
本体サイト（例：サービスページ）へ行ける導線を、ヘッダー or フッターに置く

これだけで、サブディレクトリを“孤立したブログ”にせず、サイト全体の価値につなげやすくなります。

パターンB：WordPress本体はサブ、表示URLは直下（“コア分離”運用）

仕組みの全体像（なぜ直下表示できるのか）

この運用は、ひとことで言うと 「見せる住所（公開URL）」と「置き場所（WordPress本体）」を分ける方法です。

表示（ユーザーが見るサイト）：https://example.com/
WordPress本体（管理画面・コア一式）：https://example.com/wordpress/（例）

直下で表示できる理由はシンプルで、

直下にある index.php が「WordPress本体（サブディレクトリ）を読み込む」
直下の .htaccess（またはサーバー設定）が、アクセスを直下の index.php に集める
WordPressは 「サイトアドレス」を基準にページURLを作る（＝直下URLで出せる）

という流れになっているからです。

⚠️注意：フォルダ名を変えただけでは“強いセキュリティ”にはなりません。
あくまで ファイルを整理しやすいのが主なメリットです。

手順1：管理画面でURLをどう設定するか（2つのURLの役割）

まず最重要ポイントは「2つのURLを正しく分ける」ことです。

WordPressアドレス（URL）：WordPress本体の場所（サブディレクトリ）
サイトアドレス（URL）：ユーザーに見せるサイトのURL（直下）

例（本体を /wordpress/ に置く場合）

スクロールできます

項目	設定値
WordPressアドレス（URL）	`https://example.com/wordpress`
サイトアドレス（URL）	`https://example.com`

「WordPressアドレス」と「サイトアドレス」を混同しない

ここを間違えると、典型的に次が起きます。

両方を https://example.com/wordpress にする
→ サイト自体がサブディレクトリURLで表示される（直下表示にならない）
両方を https://example.com にする
→ コア分離にならない（本体が直下扱いのまま）

✅作業のコツ
この設定を保存した直後は、一時的に「表示できない」状態になっても慌てなくてOKです。
このあと ファイル（index.php/.htaccess）を直下に用意して整合を取ります。

手順2：index.php を調整して読み込み先を正しくする

直下表示の“心臓”がこの工程です。

やることは2つだけ

WordPress本体（サブディレクトリ）にある index.php を、直下へコピー
直下の index.php の読み込み先を、サブディレクトリに合わせて書き換える

書き換えるのは基本1行です（例：本体が /wordpress/ の場合）。

require( dirname( __FILE__ ) . '/wordpress/wp-blog-header.php' );

✅ポイント

移動ではなくコピーにする（本体側にも必要なことがあります）
パスは 自分のサブディレクトリ名に合わせる（/wp/ や /wordpress/ など）

手順3：.htaccess の調整（RewriteBase/RewriteRule/パーマリンク）

ここは「直下に来たアクセスを、直下の index.php に集める」工程です。

まず押さえるべき考え方

直下表示のとき、最終的に機能してほしい .htaccess は直下にあるもの
そして転送先は /index.php（直下）になっているのが基本

Apache環境で、直下の典型的なルールは次の形です（最小構成）。

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

失敗しやすい落とし穴（ここだけ注意）

サブディレクトリ側の .htaccess をそのまま直下に置くと、
RewriteBase /wordpress/ や /wordpress/index.php が残っていて 404やループの原因になりがちです。

✅おすすめの安全手順
パーマリンク設定画面を開いて「変更を保存」を押す（設定は変えなくてOK）
→ WordPressが直下に必要なリライトルールを出してくれるので、それを直下の .htaccess に反映します。

※Nginxは .htaccess が効かないため、サーバー設定（server block）側で同等のルールが必要です。レンタルサーバーなら「WordPressのパーマリンクに対応済み」のことが多いので、困ったらホスティング側の案内に従うのが安全です。

最終確認チェック（ログインURL・/wp-admin・画像/CSS・404）

仕上げは「表示ができるか」より “壊れてないか”の点検です。初心者はこの順で確認すると迷いません。

1) ログインと管理画面

管理画面URL：https://example.com/wordpress/wp-admin/（例）
ログイン後、表示されるサイトURLが https://example.com/ になっているか

✅ここで詰まったら
URL設定が不整合なことが多いので、直下 index.php の読み込みパスと、2つのURL設定を見直します。

2) 画像・CSSが崩れていないか（混在やパスずれ）

トップ＋記事ページを表示
画像が出るか
デザイン（CSS）が効いているか

⚠️よくある原因

キャッシュ（プラグイン / サーバー / CDN）が古いまま
http/https の混在（Mixed Content）

3) 404が出ないか（特に記事URL）

記事・カテゴリ・固定ページを数本クリック
404が出るなら、まず パーマリンク設定画面で「変更を保存」を試す

4) 直下の /wp-admin がどうなるか

https://example.com/wp-admin/ にアクセスすると、環境によっては
サブディレクトリ側へ誘導されたり、404になったりします（どちらでも致命的ではありません）
基本は、運用ルールとして 管理URLはサブディレクトリ側と覚えておけばOKです

パターンC：既存サイトを移行する（直下→サブディレクトリ）

分岐：URLを変えない移行（表示は直下のまま）

「見た目のURLは example.com/ のまま」＝アクセス元も検索評価も基本は維持しつつ、WordPress本体だけをサブディレクトリへ移す方法です。
やることは“コア分離（パターンB）”を既存サイトに適用するイメージになります。

作業手順（ファイル移動→設定変更→index/.htaccess）

初心者が迷いにくいように、工程を「戻せる単位」で区切ります。

0）前提（ここだけ守る）

メンテナンス表示を出す（更新系を止める）
バックアップ（ファイル＋DB）を取る
キャッシュ・CDNの消し方を確認しておく

1）サブディレクトリを用意する

例：/wordpress/ や /wp/ を作成
※フォルダ名は短く、後から変えない前提で。

2）WordPressの“本体ファイル”をサブディレクトリへ移す

WordPressのコアファイル一式を、ルートからサブディレクトリへ移動
特に重要：wp-content/、wp-admin/、wp-includes/ が正しく移ること

3）管理画面でURLを2つに分けて設定する
設定画面の「一般」で、次の形にします。

スクロールできます

項目	例
WordPressアドレス（URL）	`https://example.com/wordpress`
サイトアドレス（URL）	`https://example.com`

ここで直下表示の“設計”が確定します。

4）ルート直下へ index.php と .htaccess を配置する

サブディレクトリ側の index.php を ルートへコピー
ルートの index.php 内の読み込み先を、サブディレクトリに合わせて修正
（例：/wordpress/wp-blog-header.php を読むようにする）

5）パーマリンクを再生成して整える

管理画面 → パーマリンク設定 → 「変更を保存」（設定変更しなくてOK）
これで、リライトや.htaccessの整合が取りやすくなります。

6）表示確認（直下・記事・管理画面）

https://example.com/ が表示される
主要な記事が404にならない
管理画面はサブディレクトリ側（例：/wordpress/wp-admin/）で入れる

注意：URL設定ミスで管理画面に入れなくなる典型パターン

よくある“詰み方”はほぼ決まっています。先に知っておくと焦りません。

典型パターン

2つのURLを同じ値にしてしまう（両方直下／両方サブ）
ルート index.php の読み込みパスが違う（フォルダ名の打ち間違い）
.htaccess がサブディレクトリ前提のまま（RewriteBaseが合わず404/ループ）
SSLやwwwの転送が二重（サーバー＋CDN＋WPで転送し合ってループ）

復旧の考え方（最短）

まず“戻す”が最優先（バックアップで復元できる状態を確保）
次に“URLの整合”を取り直す
- DBの siteurl / home を修正する
- もしくは wp-config.php でURLを一時固定してログイン回復（作業後に戻す）

ポイント：直下表示の移行は、URL設定と index.php の読み込み先が噛み合えば復旧できます。逆に、そこがズレると症状が派手に出ます。

分岐：URLが「/◯◯/」に変わる移行（構造変更）

こちらは「example.com/ → example.com/blog/」のように、公開URLそのものを変える移行です。
SEO面で重要なのは、作業の上手さよりも “旧URLと新URLの対応関係（リダイレクト設計）”です。

301リダイレクト設計（ページ単位・末尾スラッシュ・正規化）

まず結論

旧URLはできる限り、同内容の新URLへ1対1で301
まとめてトップへ飛ばすのは、ユーザーにも検索にも不利になりやすい

最初に決める3点（ここがブレると沼）

新しいサブディレクトリ名（例：blog / media）
末尾スラッシュの方針（WordPressのパーマリンクに合わせる）
正規化方針（http→https、www有無 をどこで統一するか）

おすすめの設計手順

重要ページだけでも「旧→新」の対応表を作る（まず20〜50URLでOK）
リダイレクトは可能なら “転送チェーンを作らない”
- 旧URL → 中継URL → 新URL、にならないようにする
テストはブラウザだけでなく、
「旧URLが最終的にどこへ301で着地するか」で確認する

簡易チェック表（見落としがちな箇所）

スクロールできます

チェック対象	期待する状態
旧URL	301で新URLへ
旧URL（末尾スラッシュ違い）	正しい1つに統一される
画像URL	可能ならそのまま表示（or 正しく新パスへ）
管理画面	想定通りのURLでアクセスできる

DB内URLの検索置換（シリアライズ対応の注意点も含む）

URL構造を変える移行では、DBに残る古いURLが原因で次が起こります。

画像・CSSの参照が旧URLのまま
内部リンクが旧URLのまま
直下へ戻される／意図しない転送が起きる

ここでの重要ポイントは2つです。

シリアライズ（PHPの保存形式）を壊さない
GUID列は基本的に置換しない（RSS等に影響するため）

初心者におすすめの安全策

WP-CLIの検索置換（シリアライズを考慮して処理できる）
もしくは、シリアライズ対応を明示している検索置換ツール／プラグインを使う

WP-CLI例（必要最低限の形）

wp search-replace 'https://example.com' 'https://example.com/blog' --skip-columns=guid --report-changed-only

注意：手作業でSQLの一括置換をすると、シリアライズが壊れて表示崩れの原因になりやすいです。慣れていないなら避けるのが安全です。

Search Console/アナリティクス/サイトマップ更新（移行後にやること）

URL構造変更後は「検索が新URLを見つけ、旧URLを卒業していく」フェーズに入ります。
そのために“やること”は次の3つに絞れます。

1）サイトマップを新URLで出し直す

新しい構造のURLだけが載ったサイトマップに更新
Search Consoleへ送信（旧URLのサイトマップを残すかは状況次第）

2）Search Consoleで“監視対象”を揃える

ドメイン全体（俯瞰）＋サブディレクトリ（詳細）で見られる状態にすると便利です
例：https://example.com/blog/ のURLプレフィックスを追加

3）計測（アナリティクス）の注釈・主要導線の再点検

GA4自体は同一ドメインなら計測は続きますが、
- 重要LPのURL
- コンバージョン導線（フォーム・予約・購入）
- 参照元が絡むパラメータ付きURL
  は移行後に必ず動作確認しておくと安心です。

移行後1〜4週間の監視（順位・クロール・インデックス・エラー）

移行後は「作業完了」ではなく「安定化フェーズ」です。
初心者は、次のリズムで確認すると抜け漏れが減ります。

当日〜2日目（致命傷を潰す）

主要ページが表示される（トップ・カテゴリ・記事数本）
旧URL → 新URL が想定どおり 301
404/500 が増えていない
サイトマップが取得できる

1週目（検索が動き始める）

Search Console：インデックスの増減、エラー（404/ソフト404）
リダイレクトチェーンがないか（旧→新が1回で着地しているか）
内部リンクが旧URLを踏んでいないか

2〜4週目（評価の引き継ぎを促す）

“旧URLが残り続ける原因”を潰す
- 内部リンク
- canonical
- サイトマップ
- 主要ページの再クロール（URL検査の活用）
重要KWの順位・流入ページの変化を追う（下がったページは導線と意図を再点検）

監視の観点を一枚にまとめると、こうなります。

スクロールできます

観点	見る場所	目的
404/ソフト404	Search Console	旧URL卒業の妨げを特定
インデックス	Search Console	新URLが増えているか
301の質	リダイレクト確認	チェーン・ループの排除
流入・CV	アナリティクス	“ビジネス影響”の早期検知

複数サイトを同一ドメイン配下で運用したい場合の最適解

方式1：サブディレクトリごとに別WordPressを個別インストール（分離が強い）

example.com/blog/ と example.com/shop/ のように、サブディレクトリごとにWordPressを“別々に”入れる方式です。
言い換えると「同じドメインに、独立したWordPressが複数いる」状態になります。

メリット（権限・テーマ・プラグインを分けやすい）

運用の自由度が高いのが最大の魅力です。

テーマ／プラグイン構成をサイト別に最適化できる
例：ブログは軽量テーマ＋SEO系、ショップはEC系プラグイン中心、など
更新・改修の影響範囲が限定される
1サイトでプラグイン更新に失敗しても、他サイトに波及しにくい
権限設計が分かりやすい
「ブログ担当はブログの管理画面だけ」など、運用ミスを減らしやすい
将来の切り離しが楽
例：/blog/ をサブドメインや別ドメインに移す…となっても、もともと独立しているので移行設計が立てやすい

デメリット（更新・管理が増える）

独立している分、“同じことを複数回やる”コストが発生します。

アップデート（本体・テーマ・プラグイン）がサイト数ぶん必要
バックアップ／セキュリティ対策／監視もサイト数ぶん必要
ログイン先・管理画面URLが増える（地味にミスが増えやすい）
共通部品の統一が難しい
例：全サイトで同じヘッダーにしたい、共通の問い合わせ導線を統一したい、などは仕組み化しないとブレやすい

方式2：WordPressマルチサイト（サブディレクトリ型）

こちらは、1つのWordPressで複数サイトを束ねる方式です。
見た目は example.com/siteA/ example.com/siteB/ のように分かれていても、裏側は“1つの本体”として動きます。

マルチサイトは「まとめて管理できる」反面、設計を間違えると後で詰みやすいのが特徴です。

向くケース／向かないケース（運用体制と権限設計で判断）

最初に、判断を一気にラクにするための“ざっくり結論”です。

向くケース（マルチサイトがハマる）

サイト群の目的が近い（同一ブランド／同一会社の部門・地域展開など）
共通テーマ・共通プラグインで統一したい
更新作業を中央で一括管理したい（保守担当がいる／運用を標準化したい）
新サイトを増やす頻度が高い（テンプレ的に量産したい）

向かないケース（個別インストールの方が安全）

サイトごとに要件がバラバラ（必要プラグインが衝突しやすい）
“失敗の波及”を絶対に避けたい（1サイトの障害が全体に影響すると困る）
権限が複雑（外部委託・複数チームが入り乱れて管理する）
近い将来、サイトの一部を別ドメイン／別サーバーへ移す可能性が高い

移行・拡張時の制約（あとから詰みやすいポイント）

マルチサイトは便利ですが、「後から構造変更しにくい地雷」があります。初心者はここだけ先に知っておくと失敗しにくいです。

1）“サブディレクトリ型”を選べない状況がある

既存の単体サイトをマルチサイト化する場合、条件によっては
サブドメイン型を推奨（または強制）されることがあります。
理由は、example.com/pagename（既存ページ）と example.com/sitename（新サイト）で衝突しうるからです。

2）1つの本体＝影響も共有されやすい

本体アップデートや、ネットワーク全体に関わる設定変更があると
複数サイトへ同時に影響します。
（一括管理のメリットが、そのままリスクにもなります）

3）データ構造が“ネットワーク前提”になる

マルチサイトは、サイトごとにテーブルが分かれる一方で、共有される領域もあります。
そのため、将来「このサイトだけ単体WPに戻す」「一部だけ別環境へ切り出す」となると、移行設計が個別インストールより難しくなることがあります。

4）URL方式の変更はできても簡単とは限らない

サブドメイン型⇔サブディレクトリ型は切り替え可能とされていますが、
設定・リライト・環境条件の影響を受けやすく、慎重な作業になります。

迷ったときの結論（最短の選び方）

初心者が迷ったら、まずは次のどちらかで決めると外しにくいです。

将来、サイトを切り離す可能性がある／要件がバラバラ
→ 方式1（個別インストール）が安全
同一ブランドで統一運用したい／サイトを増やす予定が多い／保守を一元化したい
→ 方式2（マルチサイト）が刺さりやすい

「管理のラクさ」を取りに行くのがマルチサイト、
「失敗の隔離」を取りに行くのが個別インストール、というイメージです。

セキュリティ：サブディレクトリ化は“補助策”と理解する

「直下に置かない」ことの意味と限界（過信しない）

WordPressをサブディレクトリに置く（例：/wp/ や /wordpress/）運用は、セキュリティ対策の「主役」ではなく「補助」です。
期待していい効果と、期待してはいけない効果を最初に切り分けましょう。

サブディレクトリ化で得られやすい“現実的なメリット”

ファイル構造が整理される（運用・保守・移行でミスが減る）
直下に不要ファイルを置きにくくなり、誤操作のリスクが下がる
バックアップや権限設定の対象が見えやすくなり、管理がしやすい

サブディレクトリ化だけでは防げないこと（ここが重要）

脆弱性（WordPress本体／テーマ／プラグイン）は場所を変えても残ります
→ 攻撃は「URLの見た目」より「脆弱性の有無」を狙います。
管理画面の存在は隠せません
→ ログインURLが完全に秘匿できるわけではありません（推測・探索されます）。
“置き場所を変えたから安全”は、いわゆるセキュリティの幻想（隠蔽）になりがち
→ 運用が雑だと、むしろ復旧が難しくなって被害が長引くことがあります。

よくある誤解（初心者がハマりやすい）

「/wp/ に移したから攻撃されない」→ ❌
「直下に置かない＝脆弱性が消える」→ ❌
「ログインURLを変えたら安心」→ ❌（効果は“補助”止まり）

結論として、サブディレクトリ化は
“整理された状態で、他の対策を正しく回せるようにする土台”として考えるのが安全です。

最低限セットでやる対策（更新・権限・WAF・ログイン保護・監視）

ここからは、初心者でも「順番どおりにやれば強くなる」ように、最小セットを実務ベースでまとめます。
全部を完璧にやる必要はありませんが、上から順に埋めると失敗しにくいです。

最小セット（まずここだけで“事故率”が大きく下がる）

1）更新（Updates）

WordPress本体・テーマ・プラグインを定期更新
使っていないテーマ／プラグインは削除（停止だけではなく、不要なら消す）

2）権限（Least privilege）

管理者アカウントを必要最小限にする
投稿者・編集者など、役割を分ける（“全員管理者”をやめる）
ファイル権限を緩めすぎない（「動かない→777」は避ける）

3）ログイン保護（Auth hardening）

強いパスワード（自動生成＋パスワードマネージャ推奨）
2要素認証（2FA）を有効化（可能なら最優先）
ログイン試行回数制限（ブルートフォース対策）
「admin」など推測されやすいユーザー名を避ける

4）監視（Visibility）

不正ログイン・ファイル変更・プラグイン更新などを通知できる状態にする
週1回でいいので、異常がないか“見る習慣”を作る
（アクセス急増、ログイン失敗急増、500エラー増加など）

“効果と狙い”が分かるように整理（チェック表）

スクロールできます

対策カテゴリ	まずやること	狙い
更新	本体・プラグイン・テーマを最新へ／不要物を削除	既知の脆弱性を塞ぐ
権限	管理者を絞る／役割分担／権限を緩めない	侵入後の被害拡大を防ぐ
ログイン	2FA／強PW／試行制限	パスワード突破を防ぐ
WAF	ホスティングWAF or CDN WAFを有効化	攻撃トラフィックを入口で落とす
監視	重要イベントを通知／週次の目視	早期発見・早期封じ込め

WAFは“1枚噛ませる”だけで効くことが多い

WAF（Web Application Firewall）は、初心者にとってコスパがいい対策のひとつです。

レンタルサーバーのWAFをONにする
もしくはCDN（例：WAF付き）を使う
可能なら /wp-admin/ や /wp-login.php への保護ルールを強める

ポイントは「完璧に防ぐ」ではなく、よくある攻撃を入口で減らすこと。
ログのノイズが減るだけでも、運用が楽になります。

もう一段だけ強くする（余裕が出たら）

ここからは“やると強いけど、サイト構成によって影響が出ることがある”項目です。
導入したら必ず動作確認してください。

管理画面に追加の鍵をかける（Basic認証／IP制限など）
wp-config.php の保護を強める（配置・アクセス制御）
管理画面からのファイル編集を無効化（改ざんの横展開を防ぐ）
XML-RPCやREST APIの扱いを見直す（必要なものだけ残す）
バックアップの世代管理＋復元手順の固定化（“戻せる”が最強の保険）

最後に：サブディレクトリ化の「正しい位置づけ」

サブディレクトリ化をセキュリティ面で活かすコツは、こうです。

“場所を変える”のは整理と運用安定のため
“守る”のは更新・権限・ログイン・WAF・監視で行う
事故が起きても被害を最小化するために、バックアップと復元手順をセットで持つ

このセットで考えると、「サブディレクトリ化＝補助策」という意味が腹落ちしやすくなります。

よくあるトラブルと解決手順（詰まりポイントを先回り）

サブディレクトリ関連の不具合は、原因が「WordPress設定」「サーバー設定」「CDN/WAF」「キャッシュ」のどれかに偏りがちです。
まずは最短で切り分けるために、最初の一手だけ表で整理します。

スクロールできます

症状	まず最初に見る場所	ここが当たりやすい
管理画面に入れない／ログインが戻る	WordPressの2つのURL設定（siteurl/home）	URL不整合・SSL・Cookie
リダイレクトが止まらない	CDN/サーバー/WordPressで転送が二重になっていないか	http↔https、www統一
画像やCSSが崩れる	ブラウザConsole、混在コンテンツ、キャッシュ	http参照・CDNキャッシュ
404が出る／記事だけ見れない	パーマリンク再生成、.htaccess/Rewrite	RewriteBase、権限
検索に出ない	noindex、robots、サイトマップ、GSC	インデックス設定ミス

管理画面に入れない／ログインループ（URL設定・Cookie・SSL）

よくある症状

ログインしてもすぐログイン画面に戻る
管理画面に入ろうとするとトップへ飛ぶ
「Cookieがブロックされています」的な挙動

原因になりやすいもの（優先順）

WordPressアドレス（siteurl）とサイトアドレス（home）の不整合
http/https の不整合（WPはhttps、CDNはhttpなど）
Cookieの保存先がズレる（URLの揺れ、サブディレクトリ移行直後）
セキュリティ系プラグインやWAFがログインをブロック

解決手順（上から順に）

シークレットウィンドウで試す
まずキャッシュやCookie要因を排除します（本体設定の検証がしやすい）。
2つのURLを確認する（最重要）
設定 → 一般で次が意図通りか確認します。
- 本体を /wordpress/ に置いて直下表示したい
  - WordPressアドレス：https://example.com/wordpress
  - サイトアドレス：https://example.com
管理画面に入れない場合は DBの値を直す
phpMyAdmin等で wp_options（テーブル接頭辞は環境で異なる）を開き、
- siteurl（WordPressアドレス）
- home（サイトアドレス）
  を修正します。
  ※ここが直るとログインループが解消するケースが多いです。
それでもだめなら wp-config.phpで一時固定
復旧のために一時的に下記を追加し、管理画面へ入れる状態を作ります。

   define('WP_HOME', 'https://example.com');
   define('WP_SITEURL', 'https://example.com/wordpress');

直ったら、最終的に管理画面側の設定に戻し、wp-configの固定は外す方が運用は楽です。

SSL設定（CDN含む）を見直す
ありがちな地雷は、CDN側が「httpでオリジンへ接続」なのに、サーバー側が「httpsへ強制転送」している状態です。
この場合、延々と転送が発生してログインが成立しません。

リダイレクトが止まらない（http↔https、www有無、二重Rewrite）

よくある症状

ブラウザで「リダイレクトが繰り返されました」
http→https→http のように行ったり来たりする
/blog/ に入ると、別URLへ飛び続ける

原因の王道

転送ルールが複数箇所に存在している
- WordPress（設定/プラグイン）
- .htaccess / サーバー設定
- CDN（HTTPSリダイレクト、www統一、ページルール）
  これが重なるとループしやすいです。

解決手順（安全な切り分け）

“統一ルールをどこで持つか”を決める
目安は次のどれか1つに寄せます。
- サーバー側で統一（.htaccessや管理画面）
- CDN側で統一（CDNのリダイレクト機能）
- プラグインで統一（なるべく最小）
一時的に“片側”を止めて挙動を見る
例：CDNの「Always HTTPS」やwww統一を一時OFF → 直るなら二重転送が濃厚。
.htaccess の転送と Rewrite を分離して考える
- https化/www統一：転送（Redirect）
- WordPressのパーマリンク：Rewrite（index.phpへ集約）
  両方を混ぜると、意図せずループします。
最終到達URLを1つに固定
https://example.com/ か https://www.example.com/ のどちらかを正規に決め、
それ以外は 1回の301 で着地するようにします（転送チェーンは作らない）。

画像/CSSが崩れる（パス・混在コンテンツ・キャッシュ）

よくある症状

デザインだけ崩れる（CSSが当たっていない）
画像だけ表示されない
一部ページだけ古いデザインのまま

原因の優先順位

混在コンテンツ（httpsページがhttpの画像/CSSを読んでいる）
キャッシュ（プラグイン／サーバー／CDN）が古い
URL変更移行で、DB内の参照先が旧URLのまま

解決手順（再現性の高い順）

ブラウザの開発者ツール（Console）で警告を見る
“Mixed Content” が出ていれば、まずそこを直すのが最短です。
キャッシュを上から順に消す
- WordPressキャッシュプラグイン
- サーバーキャッシュ（管理画面に機能がある場合）
- CDNキャッシュ（URL単位 or 全消去）
  これだけで直ることも多いです。
URL変更移行（例：直下→/blog/）なら DB内URLの置換を疑う
画像URLや内部リンクが旧URLを指していると崩れやすいです。
置換はシリアライズを壊さない方法（WP-CLIなど）を使うのが安全です。
テーマ側のURL出力を確認
ハードコードされた http:// がテーマ内に残っているケースもあります。
その場合は該当箇所の修正が必要です。

404が出る／パーマリンクが効かない（.htaccess・RewriteBase）

よくある症状

トップは表示できるのに、記事だけ404
/blog/配下だけ404
管理画面は入れるが公開側が死ぬ

解決手順（まずこれだけ）

パーマリンク設定で「変更を保存」
設定を変えなくてOKです。リライトルールが再生成され、直るケースが非常に多いです。
.htaccess の場所と内容を確認（Apache系）
- 直下表示（コア分離）の場合：直下の .htaccess が重要
- /blog/で公開する場合：/blog/ 側の .htaccess が重要
  特に RewriteBase が環境と合っていないと404になりやすいです。
Nginx環境は .htaccess が効かない
その場合はサーバー側の設定（try_files等）が必要です。
レンタルサーバーなら、WordPress用設定が用意されていることが多いので、案内に沿って調整します。
権限・ファイル有無を確認
- .htaccess が消えている／書き込み不可
- ディレクトリ権限が厳しすぎる
  なども地味に原因になります。

インデックスされない（noindex、robots、サイトマップ、GSC）

よくある症状

公開したのに検索結果に出ない
Search Consoleで「検出 – インデックス未登録」「除外」が増える

最初に確認すべき3点（ここで8割決まる）

noindexが付いていないか
- WordPressの「検索エンジンがインデックスしない」設定
- SEOプラグインのnoindex設定（カテゴリ/タグ/固定ページなど）
- X-Robots-Tag（サーバー側ヘッダー）
robots.txtで重要ページがブロックされていないか
- Disallowで全体を塞いでいないか
- noindexを効かせたいページまでクロール禁止にしていないか（読み取れず意図とズレることがあります）
サイトマップが新URLで正しく出ているか
- URL変更移行後に旧URLのサイトマップを送っていないか
- サイトマップが404になっていないか

解決手順（GSCでの動き方）

Search Consoleで対象URLを検査し、インデックス阻害の理由を確認
サイトマップを再送信
重要ページは「再クロール」を促す（URL検査の活用）
直すべき箇所が noindex/robots/canonical のどれかを特定して潰す

FAQ

「WordPress サブディレクトリ」で迷うポイントは、だいたい SEO（評価の集まり方）と 運用（管理のしやすさ）に集約されます。ここでは、初心者が判断しやすい形で整理します。

サブディレクトリとサブドメイン、SEO的にどっちが有利？

結論から言うと、「どちらが常に有利」とは言い切れません。
ただし実務では、次の考え方で決めると失敗が減ります。

同じブランド・同じテーマで伸ばしたいなら、サブディレクトリが無難になりやすい

例：example.com/blog/（本体サイトの延長として読ませたい）
内部リンクや導線が自然になり、運用も一体化しやすい

別物として切り分けたいなら、サブドメインが向く場合がある

例：docs.example.com（製品ドキュメント）、app.example.com（アプリ）
デザインや権限、技術スタックが違うものを分離しやすい

判断の軸（SEOの“体感差”が出やすいところ）

コンテンツの関連性：本体と話題が近いほど「一緒に管理」しやすい
内部リンクの設計：相互に自然にリンクできる構造か
更新・保守体制：担当者やリリース頻度が違うなら分離が安心
計測やSearch Consoleの管理：プロパティの管理単位をどうしたいか

要するに、SEOは“場所”というより 「同じサイトとして一貫して運用できるか」で差がつきやすい、という理解が安全です。

「/blog/」は本当におすすめ？（向くサイト・向かないサイト）

/blog/ は分かりやすく定番ですが、「ブログ＝何でも置き場」にすると逆効果になりがちです。

向くサイト

企業サイト配下で、役立ち記事・事例・ノウハウを積み上げたい
既存のサービスページと同じテーマで、検索意図がつながる
更新頻度が高く、カテゴリで整理しやすい

向かないサイト（別の名前や構造を検討）

お知らせ中心（更新頻度は低く、短文が多い）
→ /news/ や /info/ の方が意味が合う
採用やIRなど、ターゲットも内容も別世界
→ /recruit/ /ir/ のように目的別にした方が迷いにくい
本体と無関係なテーマを詰め込みたい
→ サブディレクトリでも“別サイト扱い”にしたい設計を検討（場合によりサブドメインも）

おすすめの命名早見表

スクロールできます

目的	例	こういう中身に合う
ブログ（継続的な記事）	`/blog/`	ノウハウ、比較、解説、コラム
メディア（体系化した記事群）	`/media/`	特集、カテゴリ設計を重視する情報
お知らせ	`/news/`	リリース、休業、更新情報
事例	`/case/`	導入事例、実績紹介
ヘルプ	`/help/`	FAQ、手順、トラブルシュート

ポイントは、URLを見ただけで「何がある場所か」分かることです。

後から構造変更すると順位は落ちる？最小化する手順は？

URLが変わる構造変更は、短期的に順位や流入が揺れやすいです。
ただし、やり方次第でダメージはかなり抑えられます。

最小化の基本ルール

旧URL→新URLは1対1で301（まとめてトップに飛ばさない）
転送は チェーンを作らない（旧→中継→新、を避ける）
canonical / 内部リンク / サイトマップは 新URLに統一
移行直後は「大改修（デザイン・構成の大変更）」を同時にやらない
→ 原因切り分けが難しくなります

初心者向け・安全な手順（ざっくりこれだけ）

重要URLの対応表を作る（まずは上位50本でもOK）
301を入れる（旧→新へ1回で着地させる）
内部リンクを新URLへ更新（メニュー・パンくず・人気記事導線）
サイトマップを新URLで作り直して送信
Search Consoleでエラー監視（404/ソフト404/リダイレクト異常）
1〜4週間は「監視＋微調整」に集中（転送ミス・取りこぼしの修正）

“落ちるかどうか”よりも、落ちたときに早く戻せる設計を先に作るのがコツです。

サブディレクトリ名の決め方（短い英字／将来の事業拡張／重複回避）

サブディレクトリ名は、あとから変えるとコストが大きいので、最初にルールで決めるのが正解です。

命名ルール（失敗しにくい）

短い英字・小文字（例：blog media news）
意味が目的に直結（“何がある場所か”が分かる）
将来の拡張に耐える（「今だけの流行語」や事業名に依存しすぎない）
既存の固定ページやカテゴリスラッグと衝突しないようにする
1ドメイン内で“役割重複”を作らない（/blog/ と /column/ が同じ中身、など）

避けた方がいい例

あいまい：/contents/（何でも置けてしまい、結局散らかる）
ぶれやすい：/new/（後から意味が変わりがち）
既存ページと衝突しやすい：/service/ など汎用語（すでに使っている可能性が高い）

迷ったら、「3年後もその名称がしっくりくるか？」で判断すると外しにくいです。

“WordPress本体だけサブ”にする意味は？（運用・保守の観点）

これはセキュリティというより、運用の事故を減らすための設計です（いわゆる“コア分離”）。

意味（メリット）

ルート直下が散らかりにくく、管理が楽になる
直下に別の仕組みを置きやすい
例：静的LP、別CMS、アプリ、リバースプロキシなど
移行・復旧時に「WordPressの塊」が見えやすい（バックアップ対象が明確）

注意点（デメリット）

index.php / .htaccess の整合が必要で、設定ミス時に症状が派手に出る
キャッシュやCDNが絡むと、直したのに直って見えないことがある
“置き場所を変えた＝強固”ではない（更新・権限・WAF・監視が本体）

結論としては、「サイトを長く運用する」「周辺の仕組みと共存させる」なら有効で、
初心者でもルールを守れば実用的な設計です。

目的別の最短ロードマップ（迷ったらここだけ見ればOK）

まず結論：あなたはどのパターン？

次の質問に「YES」が付くところが、あなたの最短ルートです。

新しく example.com/blog/ を作りたい → パターンA
WordPress本体はサブに置きたいが、表示URLは直下 example.com のままがいい → パターンB
すでに動いているサイトを、直下→サブディレクトリへ移したい → パターンC
1ドメイン配下で複数サイトを運用したい → 複数サイト（個別インストール／マルチサイト）

共通の鉄則（ここだけ守れば事故が激減）

移行でも新規でも、やることはこの3つに集約されます。

URL方針を先に固定する
- 末尾スラッシュの有無、http→https、www有無、公開URL（直下か /blog/ か）
「戻せる状態」を作ってから触る
- ファイル＋DBのバックアップ、メンテ表示、ロールバック手順メモ
インデックス事故を先に潰す
- noindex、robots、サイトマップ、Search Console の確認

パターンA：`example.com/blog/` でそのまま公開（新規）

最短手順（これだけ）

/blog/ フォルダを作成（フォルダ名は最初に確定）
WordPressを /blog/ にインストール（簡単インストール推奨）
初期設定（パーマリンク、サイトタイトル、SSL）
公開前SEO初期設定（noindex確認、サイトマップ確認、パンくず・カテゴリ整理）
Search Consoleに https://example.com/blog/（URLプレフィックス）を追加してサイトマップ送信

つまずきやすい所だけ先回り

CSS/画像が崩れる → キャッシュ（WP/サーバー/CDN）を順に削除、混在コンテンツ確認
記事だけ404 → パーマリンク「変更を保存」、.htaccess（Apache）/サーバー設定（Nginx）確認

パターンB：本体はサブ、表示URLは直下（コア分離）

最短手順（これだけ）

本体の置き場を決める（例：/wordpress/）
管理画面で2つのURLを設定
- WordPressアドレス：https://example.com/wordpress
- サイトアドレス：https://example.com
ルート直下に index.php を用意し、読み込み先を /wordpress/ に合わせる
ルート直下の .htaccess を直下表示に合う形へ（パーマリンク再生成が近道）
最終確認（ログインURL、/wp-admin、画像/CSS、主要ページの404）

詰んだときの最短復旧

ログインループ／管理画面に入れない → siteurl/home（DB）と WP_HOME/WP_SITEURL（wp-config）で整合を取る
リダイレクト無限 → CDN/サーバー/WPの「https化・www統一」が二重になっていないかを止めながら切り分け

パターンC：既存サイトを移行（直下→サブディレクトリ）

分岐1：URLは変えない（表示は直下のまま）

やることは「既存サイトをパターンBに移す」のと同じです。

最短手順（これだけ）

バックアップ＋メンテ＋ロールバック準備
WordPress本体をサブへ移動（例：/wordpress/）
2つのURLを設定（siteurl/home）
ルート index.php と .htaccess を整合
動作確認（ログイン・主要ページ・画像・404）

分岐2：URLが `/blog/` に変わる（構造変更）

SEOの勝負は「移動」ではなく「転送」です。

最短手順（これだけ）

旧→新の対応表を作る（重要URLからでOK）
1対1の301（旧URL→新URLへ1回で着地、チェーン禁止）
DB内URLを置換（シリアライズ破壊に注意。WP-CLI等の安全手段を優先）
内部リンク・canonical・サイトマップを新URLへ統一
Search Consoleへサイトマップ送信＋エラー監視（404/ソフト404/リダイレクト異常）
1〜4週間は「監視→取りこぼし修正」に集中

複数サイトを同一ドメイン配下で運用したい場合

結論としては、迷ったらこう考えると外しにくいです。

スクロールできます

目的	おすすめ	理由
失敗の隔離・要件がバラバラ	個別インストール（方式1）	影響範囲が小さく、後で切り離しやすい
統一運用・量産・保守一元化	マルチサイト（方式2）	更新・管理をまとめられる

最短の判断基準

将来「このサイトだけ分離」する可能性がある → 個別インストール
同一ブランドで共通テンプレで増やす → マルチサイト

最終チェック（公開直前・公開直後にこれだけ見る）

公開直前（5分でOK）

noindexが残っていない
robotsで重要領域を塞いでいない
サイトマップが表示できる
主要ページが404にならない
http/https・www有無が最終到達URL1つに統一されている

公開直後（1週間の見方）

Search Console：インデックス除外理由、404/ソフト404、サイトマップの取り込み
実アクセス：画像/CSS、フォーム、購入/問い合わせ導線
リダイレクト：旧URLが新URLへ正しく301で着地（チェーンなし）

まとめ

WordPressのサブディレクトリ運用は、「SEOに強いらしいから」と始めるより、目的に合うかどうかで選ぶのが正解です。
有利・不利の本質は、場所そのものよりも テーマの一貫性・内部リンク設計・移行の丁寧さにあります。

あなたの最適解はこのどれか

新しく example.com/blog/ を作って情報発信を積み上げたい
→ サブディレクトリ公開（/blog/）が向きやすい
※カテゴリ設計・パンくず・サイトマップなど“構造の明確さ”を活かす
表示URLは直下のまま、WordPress本体だけをサブに置いて整理したい
→ “コア分離”運用が向く
※URL設定（2つのURL）と index.php/.htaccess の整合が肝
直下→/blog/ に移行してURL構造を変えたい
→ SEOは「移行」より「転送設計」で決まる
※旧→新の1対1の301、内部リンク・サイトマップの新URL統一、Search Consoleでの監視が必須
同一ドメイン配下で複数サイトを運用したい
→ 要件がバラバラなら個別インストール、統一運用ならマルチサイト
※“失敗の隔離”か“管理の一元化”かで選ぶ