⚙️ ログの記載例（公式マニュアルより）

[Fri Nov 02 11:56:17.072078 2018] [core:error] [pid 100956] [client ***.***.***.***:58482] AH00124: Request exceeded the limit of 10 internal redirects…

💬 初心者が注目すべき2つのポイント

全部読もうとしなくて大丈夫です。まずこの2点だけ確認しましょう。

• エラーレベル：「error」や「crit」が並んでいれば要確認。「notice」「info」は参考情報なので無視OK
• エラー内容（末尾の英文）：ここをまるごとコピーしてAIに「これはどんなエラーですか？」と聞くだけで原因がわかります

🏆 AH01276：autoindex:error（ディレクトリ一覧の表示禁止）

最もよく見るエラーの一つです。攻撃スクリプトが /wp-includes/ や /wp-content/uploads/ などのディレクトリを直接開こうとしたときに記録されます。

AH01276: Cannot serve directory /home/…/wp-includes/html-api/: No matching DirectoryIndex found, and server-generated directory index forbidden by Options directive

対応：これはエックスサーバーが正常にディレクトリリスティングを禁止している証拠です。エラーとして記録されますが、実害はなく対応不要です。サーバーのセキュリティが正しく機能しています。

⚡ AH00124：内部リダイレクトの上限超過

.htaccessの設定ミスや、WordPressのパーマリンク設定と実際のディレクトリ構造が合っていないときに発生します。

AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error.

対応：サイトがリダイレクトループに陥っている可能性があります。WordPressのパーマリンク設定（管理画面 → 設定 → パーマリンク）を一度保存し直すと解決することが多いです。

⚙️ PHP Fatal error / PHP Warning

WordPressのプラグインやテーマのPHPコードに問題があるときに発生します。プラグインを更新した後に画面が真っ白になった場合、このエラーが記録されていることがほとんどです。

PHP Fatal error: Uncaught Error: Call to undefined function… in /home/…/wp-content/plugins/…

対応：エラー内容に記載されているファイルパスを確認します。wp-content/plugins/プラグイン名 が含まれていれば、そのプラグインが原因です。FTPまたはサーバーパネルのファイルマネージャーでプラグインフォルダを一時リネームすることで無効化できます。

🏢 File does not exist / Not Found

存在しないファイルへのアクセスが発生したときに記録されます。リンク切れ・プラグインが参照するファイルが見つからない・favicon.icoが設置されていないなど、様々な原因で発生します。

対応：大量に同じURLへの「File does not exist」が出ている場合は、そのURLのリンク切れを修正します。散発的であれば対応不要なことが多いです。

⚠️ 1日に何度も「ディレクトリ探索」が繰り返されている

午前9時から午後10時にかけて、複数の異なるIPアドレス（Azureのクラウド環境）から、以下のようなディレクトリへのアクセス試行が繰り返し記録されていました。

• /wp-includes/html-api/
• /wp-content/uploads/
• /wp-includes/PHPMailer/
• /wp-includes/images/
• /wp-includes/rest-api/

これらはすべて autoindex:error として記録されており、エックスサーバーがディレクトリリスティングを禁止することで正常にブロックされています。WordPressサイトを狙った自動スキャンは毎日当たり前のように来ており、エラーログを見るとその実態がよくわかります。

💬 「エラーが出ている＝危険」ではない

エラーログを初めて見ると、大量にエラーが記録されていて驚くかもしれません。しかし autoindex:error のように、サーバーが正常にブロックした結果もエラーとして記録されます。「エラーが記録されている＝問題がある」ではなく、「どんな種類のエラーか」を確認することが重要です。

確認すべきは「PHP Fatal error」「500 Internal Server Error」など、サイトの動作に直接影響するエラーです。

🏆 場面① サイトが真っ白になったとき（WSoD）

WordPressの「白い画面（White Screen of Death）」はエラーログで原因が特定できることがほとんどです。プラグインを更新した直後に発生した場合、エラーログに PHP Fatal error とともに問題のあるプラグインのパスが記録されています。

エラーログを確認 → 問題のプラグインを特定 → FTPまたはファイルマネージャーでそのプラグインフォルダをリネーム（例：plugin-name → plugin-name_bak）→ サイト復旧という流れで対処できます。

🏆 場面② .htaccessを編集した後に動作がおかしくなったとき

.htaccessを手動編集した後にサイトが表示されなくなった場合、エラーログに AH00124（リダイレクトループ）や 500 Internal Server Error が記録されます。エラーログで原因の行を特定し、.htaccessを修正することで解決できます。

🏆 場面③ 特定のページだけ表示されないとき

サイト全体は表示されるのに特定のページだけ404や500になる場合、エラーログにそのURLへのエラーが記録されていることがあります。テーマファイルの読み込みエラーや、ショートコードのプラグインが無効化されているなどの原因を特定できます。

💬 ChatGPT・Claudeへの聞き方

エラーログをコピーして、以下のように質問するだけです。

「エックスサーバーのエラーログに以下の内容が記録されていました。これはどんなエラーで、どう対処すればいいですか？

（エラーログの内容をここにコピペ）」

数十行あっても構いません。AIが内容を整理して、対処が必要なものとそうでないものを分けて教えてくれます。

⚙️ エラーコードを直接検索する方法

ログに含まれる「AH00124」「AH01276」などのエラーコードをそのままGoogleで検索すると、公式ドキュメントや解決事例がすぐ見つかります。エラーコードは世界共通の識別子なので、英語の解説も含めて豊富な情報が出てきます。

⚙️ ログの記載例

example.com 192.0.2.0 – – [11/Jul/2013:12:09:17 +0900] “GET /?action=hoge HTTP/1.0” 200 2602 “-” “Mozilla/5.0…”

💬 初心者が注目すべき3項目

全項目を読む必要はありません。トラブル調査では主にこの3つを確認します。

• IPアドレス：同一IPから大量のアクセスが来ていれば攻撃の疑いあり
• ステータスコード：404が大量に出ていればリンク切れや不正アクセスの可能性
• ユーザーエージェント：Googlebotならクロール、見慣れない文字列ならボットや攻撃ツールの疑い

🏆 使い所① 外部からの攻撃・不審なアクセスを調査するとき

サイトが重くなった・WordPressの管理画面に身に覚えのないアクセスが来ているなど、攻撃の疑いがある場合にIPアドレスを確認します。同一IPから短時間に大量のリクエストが来ていれば、そのIPをサーバーパネルの「アクセス拒否設定」でブロックできます。

実際のログでも、1つのIPが数秒以内にトップページ確認→WordPress検出→xmlrpc探索→ログインページ攻撃と連続アクセスしてくるパターンがよく見られます。すべて403で弾かれているため実害はありませんが、こうした動きをIPアドレスで追いかけられるのがアクセスログの強みです。

🏆 使い所② Googlebotのクロール状況を確認するとき

「記事を公開したのにGoogleにインデックスされない」と感じたとき、ユーザーエージェントに「Googlebot」が含まれるアクセスを探すことで、Googlebotが実際にサイトに来ているかどうかを確認できます。アクセス解析のロボット別レポートと合わせて使うと、より詳しい状況が把握できます。

🏆 使い所③ 404エラーが大量発生している原因を特定するとき

ステータスコード「404」が大量に出ている場合、どのURLへのアクセスで404が出ているかをログで確認できます。記事を削除したあとの内部リンク切れ、プラグインが参照しているファイルが見つからないなど、原因の絞り込みに使えます。

🏆 使い所④ 他社サーバーからの移行後に動作確認するとき

さくらやConoHa WINGなどから移行してきた方は、移行直後にアクセスログを確認すると「ファイルが正しく転送されているか」「リダイレクトが正常に機能しているか」を確かめる手がかりになります。ステータスコードが200で返っているページと、404や301が出ているページを比較することで、移行漏れや設定ミスを早期発見できます。

⚙️ 保存設定の変更手順

「アクセスログ」画面の「ユーザー領域への保存設定」タブをクリック → 対象ドメインの編集アイコン（鉛筆マーク）をクリック → 保存期間を選択して保存、の手順で設定できます。設定後は翌日午前4時以降から指定した期間のログが自動で蓄積されていきます。

⚠️ WordPress攻撃スクリプトの定番パターンが丸見え

あるIPアドレスが10:37に数秒以内に次の順序でアクセスしてきていました。

1. トップページ（/）を確認してWordPressサイトかどうか調べる
2. //wp-includes/wlwmanifest.xml にアクセスしてWordPressを特定
3. //xmlrpc.php にアクセス → 403でブロック
4. //wp-login.php にアクセス → 403でブロック

これは自動化されたWordPress攻撃ツールの典型的な動きです。すべて403で弾かれているため問題ありませんが、こうしたパターンを確認できるのはアクセスログだけです。

⚠️ install.phpへの攻撃が1日に何度も来ている

/wp-admin/install.php?step=1 への403が、異なるIPから1〜2時間おきに定期的に来ていました。IPが毎回違うにもかかわらずURLパターンが同一のため、分散した攻撃インフラからの自動スキャンと推測できます。すべて403なので対策は機能していますが、「攻撃は常時来ている」という現実がログから確認できます。

🤖 AIクローラーが積極的にコンテンツを収集している

GPTBot・OAI-SearchBot（ChatGPT検索）・ClaudeBot・ChatGPT-User・PerplexityBotと、複数のAIサービスのクローラーが1日に何度も訪問していました。特にGPTBotはサーバーキャッシュ関連の新記事を公開直後に大量クロールしており、AIへのコンテンツ流通が既に始まっていることが確認できます。

🔑 自分のWordPress管理画面操作も全部記録される

管理者がWordPressにログインして記事を編集した時間帯は、wp-admin・wp-json・admin-ajax.phpへのリクエストが大量に記録されていました。「自分のアクセスも除外できない」という制限がここで実感できます。数値を分析するときは、自分の作業時間帯のアクセス数は差し引いて読む必要があります。

⚙️ 確認できる主な指標

月別・日別・時間帯別・曜日別のアクセス推移に加え、以下の詳細データが確認できます。

• 訪問者数・訪問回数・ページビュー・ヒット数・転送量
• OS別・ブラウザ別の内訳
• アクセス流入元（検索エンジン・直接・外部リンク）
• 検索キーワード別
• ページ別アクセス数
• ロボット・スパイダー別（ボットのアクセス状況）
• エラーコード別（404などの発生状況）
• 滞在時間別
• IPアドレス・ホスト名別
• ドメイン・国別

📊 2026年4月 全体統計（pegasus-note.com）

• 訪問者数：1,110
• 訪問回数：1,591
• ページビュー：14,525
• 平均ページビュー：9.13
• ヒット数：35,758
• 平均ヒット数：22.48
• 転送量：746.4 MB

📊 2026年4月 アクセス元内訳

• お気に入りからやURL入力でのアクセス：1,955（78.3%）
• 検索エンジン：517（20.7%）
• 検索エンジン以外からのリンク：24（1%）

📊 検索エンジン別内訳（検索エンジン流入517の内訳）

• Google（www.google.com）：283（54.7%）
• Bing（www.bing.com）：200（38.7%）
• DuckDuckGo：8（1.5%）
• Google（google.com）：8（1.5%）
• Yahoo!（search.yahoo.co.jp）：8（1.5%）

📊 外部リンク流入（上位）

• t.co（X/Twitter）：5（20.8%）
• copilot.microsoft.com：3（12.5%）
• pub.a8.net（A8.net経由）：1（4.2%）

🏆 サーバーログ型で見えること

• ロボット・スパイダー別：Googlebotや各種クローラーが自サイトにどの程度アクセスしているかを把握できます。インデックスの頻度確認や、不審なボットのアクセスを検知する手がかりになります。
• エラーコード別：404（ページが見つからない）や500系エラーがどのURLで発生しているかを確認できます。内部リンク切れやプラグイン由来のエラーを早期発見できます。
• IPアドレス・ホスト名別：特定のIPから大量アクセスが来ていないかを確認できます。サーバー負荷が高いときの原因調査に役立ちます。
• 転送量：月間のデータ転送量を把握できます。画像が多いページや重いファイルの特定に使えます。

⚡ 便利機能① エラーコード別

404エラーが発生しているURLを一覧で確認できます。記事を削除したあとにリンク切れが残っている、プラグインのリソースが404を返しているなど、地味に重要なエラーを発見できます。定期的にチェックするとサイトの健全性維持に役立ちます。

⚡ 便利機能② ロボット・スパイダー別

Googlebotがどの程度の頻度でサイトにアクセスしているかを確認できます。「記事を公開したのにインデックスされない」と感じたとき、クロール頻度の参考情報になります。また不審なボットが大量アクセスしていた場合、サーバー負荷の原因として疑うきっかけになります。

⚡ 便利機能③ 滞在時間別

訪問者がサイトにどのくらい滞在したかの分布が確認できます。「すぐ離脱している」「じっくり読まれている」の傾向把握に使えます。GA4の平均エンゲージメント時間と合わせて見ると、記事の読まれ方をより立体的に把握できます。

⚡ 便利機能④ アクセスログ・エラーログのブラウザ表示（2025年10月〜）

2025年10月7日のアップデートで、アクセスログとエラーログをサーバーパネル上でそのまま確認できる「表示」ボタンが追加されました。以前はファイルをダウンロードしてから開く手順が必要でしたが、現在はサーバーパネル上でクリックするだけでログを確認できます。トラブル時の原因調査がより素早くできるようになりました。

⚡ 便利機能⑤ 時間帯別・曜日別

GA4のGA4では曜日別の分析が標準では確認しにくい仕様になっています。エックスサーバーのアクセス解析では時間帯別・曜日別のアクセス分布を簡単に確認できます。「自分のサイトはいつ読まれているか」を把握することで、記事の公開タイミングやSNS投稿の最適な時間帯の参考になります。

⚠️ データのエクスポート機能はない

現時点では、解析データをCSVやExcelなどでエクスポートする機能は搭載されていません。データを手元に保存したい場合は、画面をスクリーンショットで保存するか、必要な数値を手動でメモする方法になります。定量的な記録を残したい方は、GA4と組み合わせて使うのがおすすめです。

⚠️ 自分（運営者）のアクセスを除外する機能はない

GA4では「内部トラフィックの除外」設定で運営者自身のアクセスをデータから外せますが、エックスサーバーのアクセス解析にはこの機能がありません。自分が記事を確認するたびにアクセスがカウントされるため、記事数が少ない初期段階では実際の流入より多く見える場合があります。IPアドレス別レポートで自分のIPを確認し、数値を読む際に差し引いて考えるのが現実的な対処法です。

⚠️ ボット除外の仕様は非公開

エックスサーバーは標準のWebalizerを独自改良したツールを使用していますが、ボットのアクセスをどの程度除外しているかは公式には公開されていません。GA4より数値が高く出やすい傾向はありますが、Webalizerそのままよりは精度が高いとされています。数値はあくまで傾向の把握に使い、絶対値として比較する場合はGA4の数値を基準にするのが無難です。

⚠️ データの更新は6時間ごと

リアルタイム確認はできません。「今日投稿した記事に何人来たか」をすぐ確認したい場合はGA4のリアルタイムレポートを使ってください。エックスサーバーのアクセス解析は、日次・週次・月次のトレンド把握に向いています。

⚙️ キャッシュの保持期間

公式マニュアルによると、設定した各ファイルは最大7日間ブラウザ側に保持されます。7日間は読者が同じファイルにアクセスしてもサーバーへのリクエストが発生せず、端末の保存データで表示されます。

⚙️ 設定できる3つのモード

公式マニュアルに記載の3択から選びます。

• ON（全ての静的ファイル）※推奨：CSS・JS・画像など全ての静的ファイルが対象。デフォルトはこの設定。
• ON（CSS/JavaScript以外）：CSSとJSを除いた静的ファイルのみ対象。テーマのカスタマイズを頻繁に行う場合に選択肢になる。
• OFF：ブラウザキャッシュを無効にする。

🏆 自分の画面で確認する場合（ブログ管理者）

自分のブラウザのキャッシュをクリアするか、強制リロード（Windows：Ctrl＋Shift＋R、Mac：Command＋Shift＋R）を実行してください。これで最新の状態が表示されます。

⚙️ 読者に古い表示が届いている場合

読者側のブラウザキャッシュに古いデータが残っている状態です。最大7日間のキャッシュ期間が切れれば自動的に最新版が表示されます。緊急の場合は「CSS/JavaScript以外のON」または「OFF」に一時的に変更するか、読者にブラウザキャッシュのクリアを案内する方法があります。

⚙️ キャッシュされるファイルの保存期間

エックスサーバーの公式マニュアルに保存期間が明記されています。画像・CSS・JSなど静的ファイル（.jpg、.png、.css、.js等）は2分間、それ以外のファイルは1分間キャッシュされます。

⚙️ キャッシュされないケース

ログイン中のWordPress管理画面（/wp-admin/）、カート・マイアカウント・チェックアウトページ、WooCommerceのセッションCookieを持つアクセスなどは、自動的にキャッシュ対象外となります。会員制サイトやECサイトでも、ユーザーごとの表示が壊れないよう設計されています。

⚠️ OFFを検討するケース

.htaccessでIPアドレスやブラウザごとに表示を振り分けているサイト、または特定のユーザーにだけ非公開コンテンツを見せているサイトでは、キャッシュによって意図しないユーザーにデータが見えてしまう可能性があります。一般的なWordPressブログや情報サイトはこのケースに該当しません。

🏆 キャッシュ削除が必要なタイミング

以下のような場面では、手動でキャッシュを削除すると解決することがあります。

• 記事を更新したのに古い内容が表示されたまま（数分経っても直らない場合）
• デザインを変更したのに反映されていない（CSS・JSが更新されていない場合）
• プラグインを更新・削除後に表示崩れが起きた場合
• WordPressのテーマを変更した直後

⚙️ キャッシュ削除の手順

サーバーパネルの「高速化」→「サーバーキャッシュ設定」を開きます。対象ドメインの「キャッシュ削除」ボタンをクリックするだけで完了です。確認画面などはなく、クリックと同時に削除されます。

⚡ 静的ファイルの高速化（キャッシュ）

画像・CSS・JavaScriptといった「変化しないファイル」をサーバー上に一時保存（キャッシュ）します。同じファイルへのリクエストが来たとき、毎回ゼロから処理せず保存済みのデータを返すため、表示が速くなります。

⚡ PHPプログラムの高速化（Ver.2のみ）

WordPressはPHPというプログラミング言語で動いています。Ver.2ではこのPHPの処理速度を最大20倍に向上させる機能が追加されました。ページを表示するたびに走るプログラム処理が格段に速くなります。

🏆 メリット①　表示速度が上がりユーザー体験が改善する

サイトの表示が0.1秒速くなるだけでコンバージョン率が10%向上するという調査結果もあります。読者がページを開いてすぐ内容を見られるかどうかは、離脱率に直結します。

🏆 メリット②　SEOへのプラス効果が期待できる

Googleはサイトの表示速度を検索順位の決定要素のひとつに挙げています。ページが速くなることで「読者がすぐ内容を見られるか」という体験の質が上がり、検索流入にもプラスに働きます。

🏆 メリット③　アクセス集中時でもサイトが落ちにくくなる

キャッシュによってサーバーへの処理負荷が軽減されます。SNSで記事がバズったときや、キャンペーン告知で一時的にアクセスが急増したときでも、表示遅延やダウンを防ぎやすくなります。

⚡ 不安①「設定が難しそう」

WordPressのクイックスタートを使えば、サーバー・ドメイン・WordPressをまとめて申し込むだけで開設完了です。本来7つの手順が必要な作業が、フォーム入力だけで済みます。設定画面の操作が不安な方は、【初心者向け】Xserver新サーバーパネル全機能レビュー｜何ができるか全部触って調べたをあらかじめ確認しておくと安心です。

⚡ 不安②「料金プランが多くてわからない」

個人ブログや副業サイトならスタンダードプランで十分です。月額990円〜（キャンペーン時は最大30%オフで693円〜）から始められます。プレミアム・ビジネスプランが必要になるのは、複数サイトを本格運用する場合や法人利用がメインになってからで十分です。詳しい料金の内訳はエックスサーバー料金完全ガイドで解説しています。

⚡ 不安③「サポートが使えるか不安」

メール（24時間365日受付）・チャット・電話（平日10〜18時）の3チャンネルに対応しています。サーバー運用22年以上・稼働率99.99%以上の実績があり、初めてのサーバーとして選ばれている理由のひとつです。

🏆 初心者にはスタンダードをおすすめする理由

ブログ・アフィリエイトサイトの運用に必要な機能はすべてスタンダードに揃っています。500GBのストレージは個人運用では使い切ることがほぼなく、無料SSL・自動バックアップ・WordPressクイックスタートも標準搭載です。
プレミアム以上が有利なのは、有料WordPressテーマ「Xwrite（年額9,900円相当）」が無料になる点です。Xwriteを使いたい場合はエックスサーバー契約後にXwriteは買うべきかを参考にしてください。

🛡️ 基本情報

2022年リリース。開発はクラウドセキュア株式会社（エックスサーバーグループ）が行い、2026年3月にエックスサーバー株式会社へ事業移管されました。
完全無料・登録不要で利用でき、日本語対応のマニュアルとフォーラムが整備されています。エックスサーバーの「WordPressクイックスタート」「WordPress簡単インストール」では、2025年3月25日より同時インストールが可能になりました。

⚡ エックスサーバーとの相性が特に良い理由

エックスサーバーはサーバー側でWAF・ログイン試行回数制限・XML-RPCアクセス制限などのセキュリティ機能を標準搭載しています。CloudSecure WP Securityはこれらと重複しない設計になっており、プラグインとサーバーのダブル防御が可能です。
他のサーバーでも利用できますが、エックスサーバー環境での動作検証が最も充実しています。

⚙️ 設定手順と推奨値

①「ログインURL変更」をONにする
②「変更後のログインページスラッグ」に任意の文字列を入力する
③「変更する」ボタンをクリックして保存

スラッグは推測されにくいランダムな文字列（例：login-a7x9k2）を使用してください。設定後は必ずメモを取るか、ブックマークに保存しておくこと。URLを忘れると自分自身がログインできなくなります。

🔒 管理画面アクセス制限

WordPressの管理画面（/wp-admin/）へのアクセスをログイン済みユーザーのみに制限します。ログインしていない状態でアクセスすると403エラーを返すため、管理画面への総当たり攻撃を防げます。

🔑 2段階認証

ログイン時にパスワードに加えて、Google AuthenticatorなどのアプリのワンタイムパスワードをGoogleを要求します。パスワードが漏えいしても不正ログインを防げる、最も強力な認証方法です。

⛔ シンプルWAF：エックスサーバーではOFFのまま

CloudSecure WP SecurityのシンプルWAFは、エックスサーバーのサーバー側WAF（Web Application Firewall）と同じ役割を担います。エックスサーバーではサーバー側のWAFがすでに常時稼働しているため、プラグイン側のシンプルWAFを追加で有効にしても防御効果はほとんど変わらず、処理負荷だけが増えます。

⚠️ ログイン無効化：エックスサーバー側の制限と重複する場合あり

エックスサーバーのサーバーパネルには「WordPressセキュリティ設定」→「ログイン試行回数制限設定」があり、デフォルトで有効になっています。CloudSecure WP Security側で「ログイン失敗回数」を多めに設定していても、エックスサーバー側の制限が先に作動してロックされる場合があります。
自分自身がロックされてしまった場合は、エックスサーバーのサーバーパネルで「ログイン試行回数制限設定」を一時的にOFFにしてから解除してください。

📋 ログイン履歴の見方

「CloudSecure WP Security」→「ログイン履歴」から確認できます。成功・失敗・ブロックの3種類のステータスで記録されます。
見知らぬIPアドレスからの失敗ログインが大量に記録されている場合、ログインURL変更や2段階認証が有効に機能していることの確認にもなります。記録が空であれば、そもそも攻撃を受けていない状況です。

🏆 エックスサーバーユーザーならCloudSecure WP Securityを選ぶ理由

デフォルトで8項目が有効になっているため、インストール直後から防御が始まります。SiteGuard WP Pluginは全項目を自分で設定する必要があるため、設定に時間がかかります。2段階認証と設定ファイルアクセス防止という重要な機能がCloudSecureにしかない点も優位です。エックスサーバーの自動インストール対応によりセットアップが最短で完了するため、初心者には特にCloudSecure WP Securityを推奨します。

📋 クイックスタートの基本情報

⚙️ 手動 vs クイックスタート：工程比較

💬 筆者が実際に使って感じたこと

さくらから移行した際、2台目のサーバーとしてクイックスタートで申込みました。申込フォーム自体はスムーズで迷う場面はほぼありませんでした。 ログイン後に確認するとSSL（https化）はすでに完了した状態になっておりテーマも申込時に選んだものがインストール済みでした。「ドメインとサーバーをつなぐ」「SSLを有効にする」といった作業を一度も意識しないままWordPressの管理画面に入れたのは正直拍子抜けするほどでした。

🏆 クイックスタート vs 通常申込の全項目比較

💬 こんな状況なら通常申込を選んでください

• すでに他社で取得したドメインを使いたい
• 今のエックスサーバー契約にWordPressを追加したい
• まず無料で試してから判断したい
• サーバーやWordPressの設定を自分で学びたい

💬 筆者が申込前に悩んだポイント

申込フォームの操作自体で迷うことはありませんでしたがフォームを開く前に2つのことで時間を使いました。

• ドメイン名をどうするか（一度取得すると変更できないため）
• テーマをどれにするか（申込画面で選ぶ必要があり、事前知識がないと選べない）

この2点だけ事前に決めておけばフォームは迷わず進められます。逆に言うと「とりあえず申込ページを開いてから考えよう」という進め方だとフォームの途中で止まることになるので先に決めておくことをおすすめします。

📋 選択可能なテーマ一覧（2026年4月時点）

価格は2026年4月時点・エックスサーバー経由購入時の割引価格。変更の可能性あり。
出典：エックスサーバー申込画面・Xwrite公式プランページ

⚡ テーマ選びに迷ったら：3パターンの結論

• ブログを無料で始めたい → Cocoon（200万DL超の定番。機能十分）
• デザインに妥協したくない・初心者でもプロっぽくしたい → Xwrite（エックスサーバー公式テーマ。プレミアムプランなら無料）
• 将来的にSEOで戦いたい → SWELL（速度・SEO設定が充実）

🏢 申込後の作業フロー（全体像）

💬 筆者が実際に時間がかかった初期設定

申込からWordPressにアクセスできるまでは実際には10〜30分ほどで完了しました。「最大24時間かかる場合がある」という案内が不安でしたが体感ではかなり早かったです。

ただしログイン後の初期設定で想定以上に時間を使ったのがテーマの設定とプラグインの選定でした。テーマはインストールされているだけでサイトとして見せられる状態にするには細かい設定が多くここだけで数時間かかります。 プラグインもSEO・セキュリティ・バックアップと役割ごとに選ぶ必要があり「何を入れればいいか」の調査が思ったより手間でした。クイックスタートで「10分で開設」は本当ですが「10分で使えるブログになる」わけではないという点は意識しておくといいと思います。

⚠️ ドメイン追加後に「NS相違」と表示されるが正常

ドメイン追加後は「反映待ち」→「NS相違」と表示されます。ネームサーバーがまだ旧サーバー（さくら）側を向いているために出る表示で、正常な状態です。今回の実測では3分ほどで「NS相違」に変わりました。焦って再設定する必要はありません。

⚡ 移行進行状況がバー表示されるので安心感がある

移行を開始すると進行状況がバーで表示されます。裏で何が起きているか分からないまま待つ必要がなく、「ちゃんと動いている」と確認できます。30〜40記事程度のブログであれば5分もかからず完了しました。

⏳ 変更後は「反映待ち」「NS相違」が続く——何度も設定を触らない

ネームサーバー変更後、エックスサーバーのサーバーパネルには「反映待ち」「NS相違」と表示されます。切り替え途中の正常な状態なので、何度も設定を触り直すのは逆効果です。そのまま待ちましょう。今回の実測では変更から正常化まで約1時間20分かかりました。

🔒 SSL ON直後に出るエラーはほぼ反映途中の正常表示

SSLをONにした直後から「Let’s Encrypt証明書の発行に失敗しました」「この接続ではプライバシーが保護されません」「NET::ERR_CERT_COMMON_NAME_INVALID」「無効なURLです」「プログラム設定の反映待ちである可能性があります」といった表示が出ました。どれも焦る表示ですが、結果的にすべて反映途中の正常な経過でした。20:57時点でもまだ「無効なURLです」と表示されていましたが、21:06には正常表示を確認できました。

✅ 移行で特に重要だったポイント

移行作業そのものは短時間で終わります。ネームサーバー変更前にSSLを気にしても意味はなく、SSL関連のエラー表示は反映途中に必ず出るものです。ブラウザ表示とコンパネ表示にズレが出ることもありますが、焦って設定を触り直すより、そのまま待つほうが正解な場面がほとんどです。