mixhostでWordPressを立ち上げる手順｜迷わない導入ロードマップ

2026年2月24日

「mixhostでWordPressを始めたい」と思って調べてみたけれど、こんなところで止まっていませんか？

「クイックスタートって使うべき？契約後に入れても同じ？」
「cPanel？ WP Toolkit？ WordPress Manager？結局どれを触ればいいの…」
「無料SSL（https）は“自動”って聞くけど、鍵マークが出ないこともある？」
「移行したいけど、ダウンタイムやメールの影響が怖い」
「LiteSpeed Cacheって設定が多そう…。何から触れば安全？」
「更新したら壊れたらどうしよう。バックアップや復元って難しい？」

WordPressは“立ち上げ”でつまずくより、立ち上げ後の設定や運用で迷って時間が溶けることが多いです。
mixhostは機能が豊富で、うまく使えば心強い反面、初心者ほど「何をどの順番でやるか」が分からなくなりがち。

そこでこの記事では、mixhostでWordPressを立ち上げる流れを、迷わない一本道のロードマップとして整理します。

申し込み前のチェック（ドメイン・メール・プランの考え方）
最短で公開する手順（クイックスタート）／契約後に入れる手順（WP Toolkitなど）
SSL（https）を確実に通す確認ポイント
LiteSpeed Cacheで“壊さず”速度を上げる順番
バックアップ・復元・テスト環境で事故を防ぐ方法
移行（他社→mixhost）の失敗しない段取りと、よくあるトラブル対処

「まずこれをやって、次にこれ」まで具体的に追えるので、読み終わる頃には 自分の状況に合う進め方 が決まります。
焦らず、でも遠回りせずに、今日からWordPressを動かしていきましょう。

mixhost 公式サイト

「mixhost × WordPress」で多い悩みと、この記事で解決できること

最短で公開したい（契約と同時に立ち上げたい）

「できれば今日中に公開したい」「設定で迷いたくない」という人がつまずきやすいのは、契約 → ドメイン → WordPress設置 → SSL（https） を別々にやろうとして手順が増えることです。

このパートでは、最短で進めるために次を押さえます。

最短ルートの考え方
契約時に“まとめて”セットアップできる導線を使う（手順が分断されない）
事前に用意しておくもの（これだけ）
- サイトのタイトル（後で変更OK）
- 管理者ユーザー名（推測されにくい文字列）
- 強いパスワード（自動生成でOK）
- 連絡用メールアドレス
公開できたか確認するポイント
- 管理画面にログインできる
- 表示がhttpsになっている（鍵マーク）
- 余計な“初期ページ”が残っていない

💡コツ：「最短で公開」＝「最小構成で公開」です。最初からプラグインを入れすぎると、後で不具合の切り分けが難しくなります。まずは“動く状態”を作り、次に見た目や機能を足していくのが安全です。

契約後にWordPressを入れたい（cPanelで作業したい）

「契約は済んだ」「ドメインもある」「ここからWordPressだけ入れたい」というケースですね。
mixhostは管理に cPanel を使うため、初心者は“どこから入れるの？”で迷いがちです。

このパートでは、目的別に迷わない選び方を整理します。

WordPressの入れ方は大きく3択（考え方だけ覚えると迷いません）

管理をラクにしたい人
→ WordPress管理ツール（WP Toolkit など）で入れる
バージョン管理やセキュリティ設定をまとめて触りやすい
最低限で入れたい人
→ インストール機能でサッと入れて、WordPress側で運用する
手作業に慣れている人
→ 手動設置（上級者向け：今回は初心者向けなので深追いしない）

さらに、失敗が多いのが「入れる場所」です。

ドメイン直下に置く（例：https://example.com/）
→ 企業サイト/ブログの“本体”ならこれが基本
サブディレクトリに置く（例：https://example.com/blog/）
→ 既存サイトがあって“ブログだけ追加”したいとき

✅この記事では、どこに入れるか → どう確認するか → うまくいかない時の戻し方まで、初心者が事故りやすい順に解説します。

HTTPS化や表示崩れ（混在コンテンツ）で詰まる

WordPress初心者の“あるある”がこれです。

SSL（https）は入ったはずなのに、ページ内の画像やCSSが httpのまま
鍵マークが出ない／「保護されていない通信」になる
画像が表示されない、レイアウトが崩れる

ここで覚えるべきポイントは、原因がほぼ2つに集約されることです。

混在コンテンツが起きる主な原因

WordPressのURL設定が http のまま
記事内・テーマ内のリンクや画像URLが http のまま残っている

この記事での解決方針（安全な順）

SSLが有効になるまでの待ち時間を前提に確認（焦って何度も設定を変えない）
WordPress側の サイトURLをhttpsに統一
残った http を 段階的に置換（一気にやらない）
表示崩れが出たら 戻せる手順で対処（バックアップ or 置換の取り消し）

💡ワンポイント：高速化系・最適化系のプラグインを先に入れていると、キャッシュが原因で「直ってないように見える」ことがあります。https化 → 表示確認 → その後に高速化の順が安定です。

他社サーバーから移したい（無料/有料どれが安全？）

移行は「早さ」より 安全性（戻せること） が最重要です。
ここを間違えると、アクセスやメール、SEOに影響が出ます。

この記事では、移行方法を“初心者が判断できる形”に整理します。

移行手段のざっくり比較（目安）

スクロールできます

移行方法	向いている人	失敗リスク	ポイント
プラグイン移行	小〜中規模・シンプルなサイト	中	容量が大きいと失敗しやすい
手動移行（ファイル＋DB）	仕組みが分かる人	中〜高	手順ミスが事故につながる
移行代行	失敗したくない・時間がない	低	事前条件の確認が重要

初心者が“安全に移す”ための鉄則

先に バックアップ（旧サーバー・新サーバー両方）
いきなり切り替えないで、まず 新環境で表示確認（テストURLやhostsなど）
切り替えはアクセスが少ない時間に
メールを使っている場合は、Webだけでなく メールの移行設計もセットで考える

✅この記事では「どれを選べばいい？」を、サイト規模・スキル・停止できる時間の3条件で判断できるように解説します。

表示速度を上げたい（LiteSpeed Cacheの最適化）

mixhost環境で速度改善を狙う場合、やり方を間違えると逆に不安定になります。
そこでこの記事では、“壊さず速くする順番”にこだわります。

最初にやるべき順番（これが一番失敗しにくい）

現状を計測（体感ではなく数値で）
キャッシュを導入（LiteSpeed Cache）
画像最適化（必要な範囲だけ）
CSS/JS最適化は最後（崩れやすいので慎重に）

よくある失敗と回避策

キャッシュ系プラグインを複数入れて競合
→ キャッシュは基本1つに統一
いきなりCSS/JS最適化をONにして表示崩れ
→ まずはキャッシュだけで効果を見る
「反映されない」＝キャッシュが残っているだけ
→ どのキャッシュ（ブラウザ/プラグイン/サーバー/CDN）か切り分ける

💡実務的なコツ：
速度改善は“平均点アップ”より、遅いページ（トップ・記事・カテゴリ）を優先したほうが体感が改善しやすいです。この記事では、改善の優先順位もテンプレ化して説明します。

mixhost 公式サイト

まず確認：mixhostはWordPress用途で何が強み？

LiteSpeed環境＋キャッシュで高速化しやすい

mixhostの強みを一言でいうと、「速くしやすい土台が最初からある」ことです。
WordPressは便利な一方で、テーマ・プラグイン・画像が増えるほど重くなりがちです。そこで効いてくるのが、LiteSpeed系の仕組みです。

初心者にとってのメリット（体感しやすい順）

ページの表示がキビキビしやすい（特にトップ・記事ページ）
アクセスが増えたときも、表示が崩れにくくなりやすい
設定が「段階的」にできる（いきなり難しい最適化をしなくていい）

やることはシンプル（失敗しにくい順番）

まずは計測（PageSpeedなどでOK）
LiteSpeed Cache を入れて「キャッシュだけ」有効化
効果を見てから、画像最適化やCSS/JS最適化へ（最後が安全）

✅重要：キャッシュ系プラグインは複数入れるほどトラブルの元です。
すでに別のキャッシュを使っている場合は、どれか1つに絞るのが基本になります。

cPanelとWordPress管理ツールで、設置〜保守が一元化できる

WordPress初心者がつまずきやすいのは、作業場所が分かれてしまうことです。

WordPress管理画面（投稿・固定ページ・外観・プラグイン）
サーバー側（ドメイン・SSL・バックアップ・PHPなど）

mixhostは、サーバー管理に cPanel を採用していて、さらに WP Toolkit / WordPress Manager のようなWordPress管理ツールが用意されています。
これにより「設置して終わり」ではなく、運用で必要な作業をまとめて扱いやすいのが強みです。

一元化できる代表例（初心者が助かるところ）

WordPressのインストール（ドメイン直下／サブディレクトリの選択も含む）
複数サイトの一覧管理（「どのURLがどのWP？」が迷いにくい）
ワンクリックログイン、メンテナンスモードなどの状態管理
バックアップ／復元（更新前に“戻せる状態”を作りやすい）
アップデートの影響チェック（更新で壊れないか事前確認できる機能がある）

💡初心者向けの使い分けルール（これだけ覚えると迷いません）

記事を書く・デザインを触る → WordPress管理画面
ドメイン・SSL・バックアップ・PHPなど“土台” → cPanel / 管理ツール

この分担ができると、「どこを触っているのか分からない問題」が一気に減ります。

移行手段が複数ある（ログイン情報だけの移行/代行など）

「いま他社で動いているWordPressをmixhostへ移したい」人にとって、移行は不安が大きいですよね。
mixhostが強いのは、移行の“難易度別ルート”が用意されていることです。

代表的な選択肢（初心者が選びやすい順）

ログイン情報だけで移行できる仕組み（条件が合えばかなりラク）
プロに任せる移行代行（失敗したくない・ビジネス用途向け）
自分で移行（プラグイン／手動）※経験者向け

移行でいちばん大事なのは、スピードではなく 「戻せる状態で進めること」 です。

事故を防ぐチェック（最低限）

旧サーバーのバックアップを取ってから着手
移行先で表示と管理画面が問題ないか確認
最後にネームサーバー変更（切り替え）
メールを使っている場合は、Web移行とは別に影響範囲を確認

✅ポイント：移行は「作業自体」より、確認と切り替え手順で失敗が起きます。
“確認→切り替え”を丁寧にできる仕組みがあるのは、初心者ほど安心材料になります。

注意点：管理画面が高機能ゆえ初心者は迷いやすい

強みの裏返しとして、mixhostは機能が多いぶん、最初は「どこを触ればいいの？」となりがちです。
ここで迷わないために、最初に“地図”を持っておくのがコツです。

初心者が迷いやすいポイントと対策

「WordPressを入れた場所が分からない」
→ まず管理ツール側でURL一覧を確認（複数サイト運用ほど効きます）
「SSLを有効にしたのに鍵マークが出ない」
→ SSLの反映待ち／URL統一／混在コンテンツの順で切り分ける
「機能が使えない（見当たらない）」
→ 契約時期やプランで使える機能が異なることがあるため、公式の対象条件を確認する

もう1つの注意：料金は“初回”と“更新”が違うことがある

申し込み時は割引が入っていて、更新時は通常料金になるケースがあります。
初心者ほど「月額だけ見て決める」と後でギャップになりやすいので、

初回の月額換算
更新時の月額換算
契約期間の一括前払い

この3点は、申し込み前に必ずセットで確認しておくのがおすすめです。

mixhost 公式サイト

事前準備チェックリスト（5分で決める）

「mixhostでWordPressを始める前に、何を決めればいい？」を 迷わない順番 に整理します。
ここを固めておくと、申し込み後の“行ったり来たり”が減って、失敗も防げます。

サイトの種類（ブログ/企業サイト/複数サイト運用）

最初に決めるのは「何を作るか」です。サーバー選びの基準がここで変わります。

1分で決める質問（当てはまるものに✓）

□ 個人ブログ（記事中心・シンプル運用）
□ 企業/店舗サイト（固定ページ中心・問い合わせ導線が重要）
□ 複数サイト運用（将来2サイト以上を想定）
□ 収益サイト（表示速度・安定性を優先したい）

ここが決まると、次がスムーズになります

ブログ中心 → “記事が増える”前提で、画像やキャッシュの方針を立てやすい
企業/店舗 → “問い合わせ導線”を先に作るので、メール・フォーム周りも先に考えられる
複数サイト → “1契約で何サイト運用するか”がプラン選びに直結する

初心者の結論（迷ったらこれ）
最初は「1サイト・小さく開始」を前提にしてOKです。
ただし、半年以内に2サイト目を作りそうなら、最初から複数運用を想定したプランに寄せると移行の手間が減ります。

ドメイン（新規取得 or 既存ドメイン持ち込み）

ドメインは「住所」です。ここでの失敗は、後で地味に効きます。

新規取得が向く人

これからブログ/サイトを初めて作る
旧サイトがない（移行しない）
とにかく最短で公開したい

既存ドメイン持ち込みが向く人

すでに他社でドメインを持っている
メールも含めて同じドメインで運用したい
旧サイトから移行予定

初心者がやりがちな落とし穴（先に回避）

wwwあり/なしを決めないまま進めて、後でURLが混在
サブディレクトリ（/blog など）運用なのに、ドメイン直下に入れて作り直し
既存ドメインで「ネームサーバー変更」を急ぎすぎて、切替前に確認できない

おすすめの決め方（安全な順）

基本は「ドメイン直下」か「/blog配下」かを先に決める
新規なら“最短”導線、既存なら“確認してから切替”導線に寄せる
URL表記（wwwあり/なし）を統一する前提で進める

メールを使うか（移行時に影響が出やすい）

意外と重要なのがメールです。
サイトは表示できても、メールだけ止まると仕事に直撃します。

まず決めることは2つだけ

このドメインでメール運用する？（例：info@あなたのドメイン）
メールの“保存場所”はどこ？（サーバー／Gmailなど外部）

メールを使う場合のチェック（初心者向け）

どのアドレスが必要か
- 例：info@ contact@ support@ など
受信の形
- サーバーに保存して使う
- Gmail等に転送して使う（管理を楽にしたい人向け）
移行があるなら、切替当日に影響が出る可能性を見込む
- Webの切替（ネームサーバー）＝メールにも影響することがあるため、手順を分けて考える

初心者の結論（迷ったら）
最初は「メールは後回し」でもOKです。
ただし、仕事で使うなら 先に転送設計（どこで受け取るか） を決めておくと事故が減ります。

プラン選びの考え方（アクセス規模・複数サイト・将来の拡張）

プラン選びは「今」より「3〜6か月後」を見たほうが失敗しません。
理由は、WordPressはだいたい 記事数と画像が増えるほど重くなるからです。

判断軸はこの3つ

サイト数：今後増えるか（1つで終わるか）
更新頻度：週1か、毎日か（増え方が違う）
成長目標：月数万PVを狙うか、名刺代わりで十分か

公式の目安がある項目（選びやすい）

プランごとの“推奨PV”やリソース目安
ディスク容量やファイル数の上限目安（増えやすいのは画像・バックアップ）

このあたりを「将来こうなったら困る」を基準に選ぶと、後悔が減ります。

初期費用より「更新時の料金」と機能差を見て決める

レンタルサーバーでありがちな失敗が、初回の割引価格だけで決めることです。

最低限チェックしたいのはここ

初回（キャンペーン）価格と、更新時の料金
契約期間（3か月/6か月/1年…）で月額換算が変わるか
プランごとの機能差（特にバックアップ・移行・運用系）

初心者が安心しやすい考え方

「最安」より、戻せる仕組み（バックアップ）を重視
“最初の1〜2か月”は試運転期間として、
公開→最低限の設定→運用に慣れる、の順で進める

※なお、mixhostには初回利用向けの返金保証制度があります（条件あり）。不安が強い場合は、その条件も先に確認しておくと安心です。

ステージング/サイト複製などが必要か

初心者ほど、ここは効きます。
なぜなら、WordPressの事故はだいたい 「更新したら崩れた」 だからです。

ステージング（テスト環境）が役立つ場面

テーマを変える
大きめのデザイン調整をする
重要プラグインを追加・削除する
WordPress本体/テーマ/プラグインをまとめて更新する

“サイト複製”が向く人（初心者の安全策）

触る前にコピーを作って、そこで試す
問題なければ本番へ反映する
ダメならコピーを消してやり直せる

ただし、プランによっては使える機能が異なる場合があります。
「テスト環境を使って安全に触りたい」タイプなら、申し込み前に“複製/ステージングが対象か”を確認しておくのがおすすめです。

mixhost 公式サイト

最短ルート：申し込みと同時にWordPressを立ち上げる手順

「最短で公開したい」場合は、契約画面の中でWordPress設定まで一気に済ませるのがいちばん迷いません。
ただし、入力ミスしやすいポイントもあるので、ここだけ丁寧に押さえましょう。

申し込み画面で入力する項目（プラン・期間・ドメイン）

申し込み画面では、大きく次の3つを決めます。

プラン：サイト規模と将来の拡張（複数サイト運用など）で決める
期間：月額換算だけでなく、更新タイミングも意識する
ドメイン：新規取得か、既存ドメインの持ち込みか

初心者が迷いやすいのは「ドメイン設定」です。ここは判断を単純化できます。

ドメインの決め方（迷ったらこの順）

新規でサイトを作る → 新規取得（契約と同時に進めやすい）
すでにドメインがある → 持ち込み（ネームサーバー変更が必要になるケースあり）
URLをどうしたいか
- トップ（企業サイト/ブログ本体）で運用：https://example.com/
- 既存サイト＋ブログだけ追加：https://example.com/blog/ のように分ける

ここでの“つまずき防止”チェック

「wwwあり/なし」を後から混在させない（最終的にどちらかへ統一）
既存ドメイン持ち込みの場合、ネームサーバー変更が済むまでSSLが発行されないことがある
→ 「すぐhttpsにならない＝失敗」ではないので落ち着いて確認する

WordPress情報（サイト名/ユーザー/パスワード）を安全に作るコツ

申し込み途中で入力するWordPress情報は、あとから変更できるもの・しにくいものがあります。
ここを理解しておくと、後悔が減ります。

先に結論：いちばん慎重にすべきは「ユーザー名」

サイト名：後で変更OK
パスワード：後で変更OK
ユーザー名：後から変えにくい（運用上も影響が出やすい）

入力のコツ（初心者でも安全に作れる）

サイト名

仮でOK（後で変えられる）
ただし検索結果やSNSに出ることがあるので、雑すぎる名前は避ける

ユーザー名（重要）

admin のような定番は避ける
メールアドレスや本名の一部も避ける
おすすめ：英小文字＋数字で推測されにくい文字列（例：wp7x9k_ のような雰囲気）

パスワード（重要）

12〜16文字以上を目安に、英大小＋数字＋記号を混ぜる
自分で考えるより、パスワード管理ツールで自動生成が安全
WordPress用と、mixhostのマイページ用は別のパスワードにする

ミスしやすいポイント

「WordPressのログインパスワード」と「mixhost会員ページのパスワード」を混同する
→ 役割が違うので、作成時点でメモのラベルを分けておくと安心です。

インストール完了後の確認（管理画面URL・ログイン）

申込み完了後、WordPressサイトが表示できるようになったら、まずは「ログインできる状態」を確認します。
いきなりテーマ変更やプラグイン追加を始めると、失敗時に切り分けが難しくなるためです。

確認する順番（最短で詰まりを回避）

サイトの表示確認
- まずはトップページが表示されるか
管理画面URLの確認
- 基本は https://あなたのドメイン/wp-admin
ログイン確認
- 申し込み時に作ったユーザー名・パスワードで入れるか

もしログインで迷ったら、マイページ側から管理画面へ入れる方法が用意されていることがあります。
「URLが分からない」「ログイン画面に辿り着けない」ときの近道になるので、覚えておくと安心です。

よくある引っかかり（ここだけ先に知っておく）

httpsで開けない／鍵マークが出ない
- ドメイン追加直後などはSSL反映に時間がかかることがあります
- 既存ドメイン持ち込みの場合、ネームサーバー変更が完了していないとSSLが発行されません
- 焦って設定を何度も変えるより、まずは反映状況を確認するのが安全です

最初にやるべき初期設定（一般設定・パーマリンク・不要機能の整理）

ログインできたら、次は「事故を起こしにくい初期状態」を作ります。
ここはSEO以前に、運用がラクになる下地です。

1）一般設定（最低限）

サイトタイトル・キャッチフレーズ（仮でもOK、後で整える）
タイムゾーン（日本なら東京でOKなことが多い）
管理者の表示名（投稿者名がIDのまま見えないように）
管理者メールアドレス（通知を確実に受け取れるものに）

2）パーマリンク（SEO・運用の土台）

原則「投稿名」系が扱いやすい
重要：記事を書き始める前に決める
- 途中で変えると、過去URLが変わって404や評価ロスにつながりやすい
- もし途中で変えたくなったら、リダイレクト方針もセットで考える

3）不要機能の整理（軽くして、トラブル源を減らす）

サンプル記事・サンプル固定ページを削除/非公開
使わないテーマは削除（最低限、現行テーマ＋予備1つ程度）
使わないプラグインは「停止」ではなく削除（放置しない）
コメントを使わないなら、ディスカッション設定でオフにしてスパム対策を簡略化

4）最初の安全策（“最低限”でOK）

WordPress本体・テーマ・プラグインは最新版を保つ（自動更新も検討）
プラグインは増やしすぎない（不具合の原因が追いづらくなる）
ログインパスワードは複雑に（短い・単純は避ける）

ポイント：最初の1日は「盛る日」ではなく、“整える日”にすると失敗しにくいです。
デザインや機能追加は、初期設定→表示確認→バックアップ確認のあとで十分間に合います。

mixhost 公式サイト

契約後に設置する：WordPressのインストール方法は3パターン

「申し込み時にクイックスタートを使わなかった」「あとからWordPressを入れたい」場合、mixhostでは主に3つの入れ方があります。
結論から言うと、迷ったら “WP Toolkit” がいちばん事故りにくいです。

方法A：WP Toolkit（cPanel内。管理・保守までまとめてやりたい人向け）
方法B：WordPress Manager（マイページ起点。画面がシンプルで迷いにくい）
方法C：cPanelのアプリインストーラー（Softaculous）（最小構成で入れたい／慣れている人向け）

方法A：WP Toolkitで入れる（管理・保守もまとめてやりたい人向け）

WP Toolkitは、WordPressのインストールだけでなく、運用中に必要な作業（更新・セキュリティチェック・バックアップ等）もまとめて扱えるのが強みです。

進め方のイメージはシンプルで、

cPanelにログイン
「WordPress Management」→ WP Toolkit を開く
「インストール」→ 必須項目を埋める → 実行

という流れになります。

インストール先（ドメイン/サブドメイン/ディレクトリ）の選び方

ここが一番大事です。どこに入れるかで、URL構造と運用のしやすさが決まります。

よく使う3パターン

ドメイン直下（例：https://example.com/）
企業サイト・ブログ本体におすすめ。迷ったらこれ。
サブドメイン（例：https://blog.example.com/）
本体サイトとブログを強く分けたいとき向け。
サブディレクトリ（例：https://example.com/blog/）
既存サイトがあって「ブログだけ追加」に向く。

初心者向けの判断ルール（最短）

1サイトで完結 → ドメイン直下
既存サイト＋ブログ追加 → /blog のようなサブディレクトリ
将来、用途別に複数運用（会員サイト・LPなど） → サブドメインも候補

既存フォルダに上書きしないための注意点

WP Toolkitで事故が起きるのは、ほぼここです。

要注意ケース

すでに同じ場所にファイルがある（HTMLサイト・別CMS・旧WordPressなど）
以前の試しインストールが残っている
public_html 直下に何か置いてあるのに、ドメイン直下へ入れようとする

安全策（これだけ守ればOK）

インストール先が不安なら、まず 空のサブディレクトリ（例：/wp や /test）で試す
本番運用の場所に入れる前に、バックアップ（最低でもファイルは退避）
「上書き」警告が出たら、“はい”を押す前に停止
→ その時点で、場所を変えるか、バックアップしてから実行する

方法B：WordPress Managerで入れる（マイページ起点で迷いにくい）

WordPress Managerは、mixhostのマイページから直接 WordPressを入れられる導線です。
cPanelに慣れていない初心者でも、「必要な入力欄だけ」埋めれば進む設計なので迷いにくいのがメリットです。

基本の流れは、

マイページから WordPress Manager を開く
「新規インストール」
画面の案内に沿って インストール先・ID/パスワード・サイト名 を入力
作成→サイト一覧に追加→ログイン

という感じです。

https/wwwの選択と、あとから変更する時の注意

WordPress Managerでは、インストール時に プロトコル（SSLやwww有無） を選べます。ここは初期に決めておくと後がラクです。

初心者の推奨

特別な理由がなければ https を選ぶ
wwwあり/なし は好みでOK（重要なのは “統一”）

あとから変更する場合の注意（ここだけ押さえる）

WordPressの「サイトURL」を変えるだけだと、
リダイレクトが整っていない場合に 表示崩れ・混在コンテンツ・SEO評価の分散 が起きやすい
変更するなら、次のセットで考える
- 301リダイレクト（旧→新へ統一）
- WordPress側URLの更新
- キャッシュ削除（ブラウザ／プラグイン／サーバー側）

※「変えられる」けど、“変えないで済むように最初に決める” のが初心者にはいちばん安全です。

方法C：cPanelのアプリインストーラー（最小構成で入れたい場合）

cPanelに Softaculous Apps Installer がある場合、そこから数クリックでWordPressを入れられます。
「必要最低限で入れて、あとはWordPress側で管理する」というスタイルに向きます。

ただし、mixhostの環境や収容サーバーによってはSoftaculousが表示されないことがあり、その場合は WP Toolkitを使う案内になっています。
初心者は無理にSoftaculousを探し回るより、見当たらなければWP Toolkitへ切り替えるのが早いです。

Softaculousを使うときのコツ

事前に、目的のドメインをcPanel側で利用できる状態にしておく（追加ドメイン等）
インストール先のURL（直下／サブディレクトリ）を必ず確認してから実行
インストール後は、管理画面に入れることを確認してからテーマやプラグインを入れる

どの方法が最適？目的別の選び分け早見

スクロールできます

目的	おすすめ	理由
とにかく失敗したくない（初心者）	方法A：WP Toolkit	上書き警告・管理機能が揃っていて安全運用に向く
cPanelが苦手／画面がシンプルな方がいい	方法B：WordPress Manager	マイページ起点で導線が分かりやすい
最小構成でサクッと入れたい／慣れている	方法C：Softaculous	手数が少ない（ただし表示されない環境もある）
複数サイトを運用して更新・保守もまとめたい	方法A：WP Toolkit	一覧管理、更新、セキュリティチェック等がやりやすい

mixhost 公式サイト

HTTPS化（無料SSL）を確実に通す：確認手順とよくある落とし穴

SSLが有効になるまでに起きがちなタイムラグと確認方法

mixhostの無料SSL（Let’s Encrypt系）は、基本的に自動で発行・更新されます。とはいえ、「設定したのにhttpsにならない」のは珍しくありません。多くは“待ち時間”か“前提条件”が原因です。

まず押さえる前提条件（ここがズレると永遠に発行されません）

ドメインがmixhost側に正しく追加されている
ドメインのネームサーバー（DNS）がmixhostを向いている
追加直後は反映に時間がかかることがある

待ち時間の目安

ドメイン追加・ネームサーバー変更後、最大24〜72時間程度かかることがあります（環境・反映状況次第）
72時間以上たってもエラーが続く場合は、設定の見直しやサポート相談が現実的です

確認は“この順番”が最短で迷いません

スクロールできます

何を確認する？	見る場所	OKの状態	NGの代表例
httpsでサイトが開くか	ブラウザ	httpsで表示される	証明書エラー／開けない
発行状況	cPanel（SSL/TLS Status）	対象ドメインが保護対象になっている	対象が出ない／未発行
DNSの向き	ドメイン管理側	mixhost指定のNSになっている	別サーバーのNSのまま

急ぎの場合の“現実的な一手”

自動発行を待っても進まないときは、cPanelの SSL/TLS Status から AutoSSL（Run AutoSSL） を手動実行できる場合があります。
これで発行が前に進むケースがあります。

注意：反映途中にあれこれ触ると、どこで詰まっているか分からなくなりがちです。
「DNS→SSL→WordPress設定」の順だけ守ると失敗が減ります。

WordPress側のURLをhttpsに統一する手順

SSLが有効になったら、次はWordPress側のURLを httpsに統一します。
ここをやらないと、表示はhttpsでも内部リンクがhttpのままで、混在コンテンツが残りやすくなります。

作業前にやること（30秒）

現在のURLをメモ
- WordPressアドレス（URL）
- サイトアドレス（URL）

手順（初心者向けの王道）

WordPress管理画面にログイン
設定 → 一般 を開く
次の2つを https に変更
- WordPressアドレス（URL）
- サイトアドレス（URL）
変更を保存
いったんログインし直す（URLが変わるため）

つまずきポイントと回避策

保存後にログインできない／管理画面がループする
→ まずは落ち着いて、httpsの管理画面URL（/wp-admin） から入り直します
それでも入れない
→ 無理に連打せず、直前にメモしたURLへ戻す（復旧優先）
※サーバー側（wp-configやDB編集）で戻す手段もありますが、初心者は“戻す→サポート相談”が安全です

“https統一”ができたかの確認チェック

トップページを開いたとき、URLが httpsで固定される
httpで開いても、httpsへ移動する（リダイレクトが効く）
管理画面もhttpsで開ける

混在コンテンツ（http画像/JS/CSS）が残る時の直し方

「鍵マークが出ない」「保護されていない要素があります」と出る場合、ほぼ混在コンテンツです。
原因はだいたい次のどれかです。

記事本文に httpの画像URL が残っている
テーマやプラグインが 外部ファイルをhttpで読み込んでいる
CSS/JSがキャッシュされていて、直したのに反映されない

まず“どれがhttpか”を特定する（これが一番早い）

Chromeなら（例）：開発者ツール → Console（またはSecurity）に、混在のURLが出ます
あるいはページソースで http:// を検索しても手がかりになります

よくある原因トップ3（初心者が直しやすい順）

画像URL（投稿・固定ページ内に直書き）
自作のHTML（ウィジェット・固定ページのカスタムHTML）
テーマの読み込み（フォント・解析タグ・外部JS）

キャッシュが邪魔することが多いので、直したらここも実施

ブラウザのスーパーリロード（Ctrl+F5など）
キャッシュ系プラグイン（例：LiteSpeed Cache）の削除
CDNを使っているならCDNキャッシュ削除

プラグインで直す vs 置換で直す：安全な手順

混在コンテンツの直し方は、大きく2つあります。結論はこうです。

応急処置で早く直す → プラグイン方式
根本的に直して将来の不安を減らす → 置換方式（検索置換）

それぞれ“安全な進め方”をセットで紹介します。

A. プラグインで直す（早い／元に戻しやすい）

特徴は 「DBを書き換えずに、表示時にhttpsへ補正する」 方向性です。
混在が多いサイトでも、まずは見た目を整えるのに向きます。

安全に使うコツは2つだけです。

使う機能は最小限（“とりあえず全部ON”にしない）
セキュリティ系プラグインは過去に脆弱性が話題になった例もあるので、最新版へ更新を徹底

※代表例として「Really Simple Security（旧 Really Simple SSL）」は、混在コンテンツの自動修正機能を持ちます。

B. 置換で直す（根本解決／運用が軽くなる）

こちらは、WordPress内部（DB）に残っている http://あなたのドメイン を https://あなたのドメイン に置き換える方法です。
一度きれいにすれば、プラグインに頼り続けなくて済むのがメリットです。

安全な手順（初心者向けテンプレ）

必ずバックアップ（DB＋できればファイルも）
置換ツールは ドライラン（試し実行） ができるものを選ぶ
置換対象は基本この形に限定する

http://あなたのドメイン → https://あなたのドメイン

実行後にチェック

トップ／記事／固定ページ／問い合わせページ

問題があれば、バックアップから戻す（事故を長引かせない）

置換でよくある失敗は「外部URLまで巻き込む」「いきなり全置換する」です。
“自分のドメインだけ”に絞ると安全性が上がります。

それでも直らないとき（最後の切り分け）

混在URLが 外部サービス（計測タグ、フォント、広告タグ） なら
→ その提供元のURLをhttps版に差し替え
テーマ由来なら
→ テーマ設定（カスタマイザー）や子テーマ側に直書きがないか確認
画像がhttpのままなら
→ メディアのURL置換／再登録が必要な場合あり（置換で解決することが多い）

mixhost 公式サイト

表示速度を上げる：LiteSpeed Cacheの考え方とおすすめ設定方針

まず測る（PageSpeed/実測）→次にボトルネックを切る

速度改善でいちばん多い失敗は、測らずに設定を盛って崩れることです。
LiteSpeed Cacheは強力なので、最初は「原因の特定 → 最小変更 → 効果確認」の順で進めるのが安全です。

最初に見るべき“3つの数字”

LCP：表示の体感（ファーストビューが出るまで）
INP：操作の重さ（クリックしたのに反応しない等）
TTFB：サーバー応答（キャッシュが効くと改善しやすい）

ボトルネック別：やること早見（初心者向け）

スクロールできます

症状	ありがちな原因	まずやる対策
画像が遅い	画像が重い/大きい	画像最適化・遅延読み込み（後述）
初回表示が遅い	キャッシュ未導入/設定不足	ページキャッシュを先に有効化
記事は速いがトップが遅い	スライダー・外部JS・フォント	外部読み込みを整理（最小化）
直ったはずなのに変わらない	キャッシュが残っている	“消しどころ”を順に消す（後述）

安全な進め方（これだけ守る）

重要ページを3つ決める（トップ / 記事 / お問い合わせ）
変更は「1項目ずつ」
変更のたびに、3ページを確認
崩れたら、直すより先に戻す（原因が見える）

キャッシュの基本（ログイン中/REST API/ログイン画面は原則キャッシュしない）

LiteSpeed Cacheの基本は「ページを作り直さず、作った結果を再利用する」ことです。
ただし、“キャッシュしてはいけないページ” を理解していないと、ログイン系の不具合やフォームの誤動作につながります。

原則キャッシュしない（または除外する）対象

管理画面（/wp-admin）とログイン画面（/wp-login.php）
ログイン中のユーザー操作が関わるページ（会員機能・マイページ等）
動的に内容が変わるページ
- カート/決済（EC）
- 予約フォームの入力途中
- 会員情報の更新ページ

REST APIは“基本OFF寄り”で考えると安全

LiteSpeed CacheにはREST APIのキャッシュ機能もありますが、プラグインによっては相性で不具合が出ることがあります。
初心者の方針としては、

まずは REST APIキャッシュは触らない（デフォルト重視）
もし特定プラグインで不具合が出たら、REST APIキャッシュをOFFにして挙動を見る

という順番が事故りにくいです。

まず入れるなら、この考え方が堅い

キャッシュ：ON（最初のメイン施策）
除外：ログイン系・管理系を確実に除外（崩れ防止）
最適化：後回し（崩れやすいので段階導入）

QUIC.cloudを使う場合の準備と、つまずきポイント

QUIC.cloudは、LiteSpeed Cacheと連携して「画像最適化」や「オンライン最適化機能」などを使えるようにする仕組みです。
mixhostでは、LiteSpeed Cacheの画面からQUIC.cloudサービス有効化を進められる手順が案内されています。

準備で大事なのはこの2つ

サイトが外部から見える状態であること（メンテナンス表示や強い制限があると連携が詰まることがあります）
WordPressとLiteSpeed Cacheが最新に近い状態であること（画面や項目が変わる場合があります）

つまずきポイント（初心者がハマりやすい順）

「QUIC.cloudを有効化」ボタンが出ない
→ プラグイン更新・表示箇所の確認（最近は画面構成が変わっています）
連携できたのに効果が見えない
→ 画像最適化は“処理待ち”が発生しやすい（即時反映とは限らない）
CDNを併用している（例：別CDN/プロキシ）
→ キャッシュが多段になり、反映確認が難しくなる（消しどころを整理する）

コツ：QUIC.cloudは「最初から全部ON」ではなく、まず画像最適化だけのように、機能を絞るほうが安定します。

画像最適化・CSS/JS最適化の順番（壊さないための手順）

速度改善で“壊れやすい順”を先に言うと、CSS/JS最適化が一番壊れやすいです。
なので、順番はこう固定すると安全です。

おすすめ順（初心者向け）

キャッシュをON（ページ表示の土台）
画像最適化（WebP/圧縮/遅延読み込み）
CSS最適化（最小化→結合は慎重）
JS最適化（遅延/延期は崩れやすいので最後）

壊さない運用ルール

1設定ON → 3ページ確認（トップ/記事/フォーム）
崩れたら「除外」を使う（特定ページ・特定スクリプトを対象外に）
どうしても直らないなら、その最適化は切る（速度より安定が優先）

表示が反映されない時の“キャッシュの消しどころ”

「設定を変えたのに変わらない」は、だいたいキャッシュです。
重要なのは、どこにキャッシュが残っているかを順番に潰すこと。

消す順番（効率がいい順）

LiteSpeed Cache（プラグイン）：Purge All（全削除）
ブラウザ：スーパーリロード（Ctrl+F5 など） or シークレットで確認
QUIC.cloud側（使っている場合）：キャッシュ削除
別CDN/プロキシ（使っている場合）：キャッシュ削除
それでもダメなら：サーバー側のキャッシュ関連を再確認

“反映されない問題”の切り分け小技

自分だけ反映されない → ブラウザキャッシュの可能性大
みんな反映されない → プラグイン/CDN側キャッシュの可能性大
一部ページだけ反映されない → そのページが除外対象 or 特定URLだけキャッシュ残り

mixhost 公式サイト

バックアップ・復元・テスト環境（事故らない運用の基礎）

WordPress運用で一番つらいのは「更新したら壊れたのに、どこまで戻せばいいか分からない」状態です。
mixhostは 自動バックアップ や WP Toolkit（WordPress管理） など“戻す手段”が複数あります。だからこそ、最初に 使い分けルール を決めておくと事故が激減します。

更新前に必ず取るべきバックアップ（範囲と頻度）

最初に覚えるべき結論はこれです。

自動バックアップは「保険」（便利だけど、毎日必ず作成される保証ではない）
更新前バックアップは「必須の儀式」（自分で確実に作る）
大きい変更ほど「テスト→本番」（いきなり本番で試さない）

バックアップ対象（最低限ここだけ）

初心者が「戻せる状態」を作るなら、バックアップ範囲は次の2つで十分です。

ファイル：テーマ / プラグイン / uploads（画像）など
データベース（DB）：記事・固定ページ・設定・フォーム送信先設定など

例：デザインが崩れた＝ファイル側の可能性が高い
例：記事が消えた・設定が戻った＝DB側の可能性が高い

頻度の決め方（迷わないテンプレ）

毎回やる（必須）
- WordPress本体の更新前
- テーマ変更・大型カスタマイズ前
- 主要プラグインの追加/削除/更新前（キャッシュ系・セキュリティ系・フォーム系など）
週1でやる（推奨）
- 通常運用の“定期バックアップ”（更新の有無に関係なく）
月1でやる（できれば）
- 外部に保管（PCや別ストレージへ）
  ※サーバー内だけだと、万一の障害で同時に失うリスクがあります

「どれでバックアップする？」早見表

スクロールできます

シーン	目的	おすすめ手段
更新直前に“確実に戻せる点”が欲しい	即復旧	WP Toolkit / WordPress Manager で手動バックアップ
“昨日の状態に戻したい”など過去日付で戻したい	保険・緊急	自動バックアップ（JetBackup系）
本番を触るのが怖い	事故防止	複製（コピー）→テスト→反映

復元の考え方（ファイル/DB/WordPress単位で切り分け）

復元で失敗する人の共通点は「とりあえず全部戻す」です。
まずは症状から、戻す対象を絞ります。

症状→戻す対象の目安（最短で切り分け）

スクロールできます

症状	ありがちな原因	まず戻す候補
画面が真っ白 / 500系エラー	テーマ・プラグイン不具合	ファイル（該当プラグイン/テーマ）
デザインだけ崩れた	CSS/JS最適化、テーマ変更	ファイル＋キャッシュ削除
記事や設定が巻き戻った/消えた	DB更新失敗	DB
画像が表示されない	uploads欠損、URL不整合	ファイル（uploads）
ログイン不可・挙動が変	キャッシュ/設定/プラグイン	状況次第（まずキャッシュ→次にDB or 該当プラグイン）

復元の基本手順（事故らない順番）

いきなり本番で復元しない（できればコピーサイトで先に試す）
復元する対象を決める
- まずは DBだけ で直るか
- 直らなければ ファイルも
復元後に必ずやるチェック（ここで“直ったつもり”を防ぐ）
- トップ / 記事 / フォーム（送信まで）を確認
- 管理画面に入れるか
- 画像・メニュー・ウィジェットが崩れていないか
- キャッシュ削除（プラグイン/ブラウザ/CDN）で反映を確認

mixhostでの復元“考え方”のコツ

WP Toolkit / WordPress Manager のバックアップは
「WordPress単位で戻せる」感覚で扱えるのがメリットです（初心者向き）
自動バックアップ（JetBackup系） は
「サーバー全体の保険」寄り。ファイル/DB単位で戻せるのが強みです

重要：自動バックアップは便利ですが、毎日必ず作成される保証ではありません。
“絶対に戻したい更新”の前は、手動バックアップを作るのが安全です。

テスト用サイト（ステージング/複製）を使うべきケース

「バックアップは取った。でも本番で試すのは怖い」——この不安を解消するのが 複製（コピー） と ステージング です。
mixhostのWP Toolkitは、コピーサイトを作って試し、問題なければ本番へ反映する流れを取りやすいのが強みです。

ステージング/複製を使うべき代表ケース

テーマを変更する（特にブロックテーマ/大幅変更）
CSS/JS最適化や高速化設定を攻める（表示崩れが起きやすい）
主要プラグインを入れ替える（フォーム・会員・EC・キャッシュ）
WordPress本体のメジャー更新
“URLまわり”を触る（https統一、www統一、パーマリンク変更など）

安全な運用フロー（初心者向けテンプレ）

WP Toolkitでコピーサイトを作る
コピーサイトで作業する（更新・設定変更・表示確認）
OKなら、WP Toolkitの データコピー で本番へ反映
本番で最終確認（トップ/記事/フォーム）
問題が出たら、反映をやめて戻す（バックアップ or 再反映）

本番反映で事故らない注意点（ここだけ押さえる）

本番側に新規投稿・問い合わせ・注文が発生するサイトは特に注意
反映でDBを上書きすると、その間のデータが消える可能性があります。
迷ったら、反映時は「夜間・メンテ告知・短時間で実施」が安全です。
ステージングは検索に出さない
- パスワード保護（ベーシック認証）
- noindex設定（検索エンジンに載せない）
  これをやると“テストサイトが検索結果に出る事故”を防げます。

mixhost 公式サイト

他社サーバーからmixhostへ移行する方法（失敗しない順番）

サーバー移行で失敗しやすいのは、作業そのものより 「順番」と「確認不足」 です。
mixhostへの移行は大きく3ルートありますが、どれを選んでも共通して次の流れが安全です。

旧サーバーは解約しない（移行完了まで保険として残す）
先に移行 → 動作確認 → 最後にネームサーバー変更（切り替えは一番最後）
メール利用の有無を最初に決める（後から気づくと事故りやすい）

方法A：WordPressログイン情報だけで移す（対応条件と注意点）

mixhostには、移転元サイトの WordPressログイン情報（ログインURL / ID / パスワード） を使って移行できる機能があります。
手順が少なく、初心者が最短で成功しやすいのがメリットです。

ただし、対応条件に合わないと使えません。 ここを最初にチェックしてください。

対応条件（まずここだけ確認）

mixhost側で「WordPressらくらく引っ越し（WordPress Manager）」が使える契約である
移転元のWordPressに ID（またはメール）＋パスワードだけでログインできる
- reCAPTCHA、ベーシック認証、IP制限などがある場合は、移行中は解除が必要
ログイン直後に WordPressのダッシュボードが表示される
- 初回確認画面（メール確認など）が出ると、移行が止まることがあります

利用できないケース（当てはまるなら方法B/Cへ）

マルチサイト
サブディレクトリ運用（例：https://example.com/blog/）のサイト
サイトURLとWordPressの設置場所が違うなど、構成が特殊
移行先で最新WordPressが入るため、最新WP非対応のテーマ/プラグインを含む
単体で1.5GB超のファイル（バックアップ等）が含まれる
wordpress.com無料プランなど、特定プラグインが使えない環境
DB肥大化が著しい／特殊カスタマイズが強い

移行されない可能性があるデータ（あとで困るポイント）

移行自体が成功しても、次のようなものは “自動で持って来られない” ことがあります。

特定のバックアッププラグインが作ったバックアップファイル
wp-content の外側に置いた独自ファイル（独自の画像置き場など）
一部のキャッシュファイル・バックアップファイル

結論： 重要ファイルを wp-content 外に置いている自覚があるなら、方法B（プラグイン）か方法C（代行）が安全です。

失敗しないコツ（初心者向け）

移転元のセキュリティ系・キャッシュ系プラグインが強い場合は、移行中だけ一時停止する
移転先には、目安として サイト容量の約2倍の空き容量が必要になるケースがあります
移行が終わるまで、旧サーバーのデータは削除しない（“戻れる状態”を残す）

方法B：プラグインで移す（大容量サイト/マルチサイトの注意）

プラグイン移行は「移転元で書き出す → 移転先に読み込む」方式です。
ログイン情報移行が使えないケースでも対応できるため、適用範囲が広いのが利点です。

プラグイン移行の基本ステップ（全体像）

移転元：WordPress・プラグインを更新（動作安定のため）
移転元：移行プラグインでエクスポート（書き出し）してファイルを保存
移転先：新しいWordPressを用意（同じドメインで確認できる状態にする）
移転先：移行プラグインでインポート（読み込み）
動作確認 → 最後にネームサーバー変更

大容量サイトで詰まりやすいポイント

プラグイン移行で一番多いのは、アップロード上限（サイズ制限） に引っかかることです。

エクスポートしたファイル容量＞インポート側の上限
→ インポートできず停止します

この場合は、サーバー側で upload_max_filesize と post_max_size を調整して上限を上げる必要が出ます。
初心者は「上限を上げたら終わり」と思いがちですが、上げすぎると安定性に影響することもあるので、必要な分だけにするのが安全です。

マルチサイトは要注意（結論：ルートを選ぶ）

マルチサイトは、移行方法やプラグインの対応可否で難易度が上がります
mixhostの移行代行では マルチサイトは対象外 なので、基本は自己移行になります
不安なら、マルチサイト対応の移行手順（専門サービス／専門家）を検討するのが現実的です

キャッシュ・セキュリティ系プラグインは“移行中だけ”弱める

プラグイン移行でも、セキュリティ系・キャッシュ系が強いと失敗しやすいです。

移行中だけ無効化 → 移行完了後に戻す
「移行が終わったら元に戻す」までがセットです

方法C：移行代行を使う（費用・対象・事前確認）

「絶対に失敗したくない」「作業時間を取りたくない」なら、移行代行が最短です。
mixhostのWP移行サービスは、1サイト 9,900円（税込10,890円） が基本料金です。

代行が向いている人

仕事用サイトで、ダウンタイムや不具合が怖い
大容量でプラグイン移行が不安
自分でやると確認手順が抜けそう
複数の要素（SSL、キャッシュ、メール）が絡む

事前に知っておくべき注意点

動作保証は WordPress本体が中心（テーマ・プラグインの完全保証ではない）
データ量が大きい場合、キャッシュ／バックアップ／解析系の一部データは移行しないことがある
マルチサイトは対象外
独自ドメインメールを使う場合は、ネームサーバー変更前にユーザー側の設定が必要

切り替え当日の手順（更新停止→動作確認→ネームサーバー変更）

ここが最重要です。移行がうまくいっても、切り替え手順を雑にすると事故ります。

当日のテンプレ（この順番でやればOK）

更新停止（短時間）
- 記事投稿、フォーム設定変更、商品追加などは避ける
- どうしても必要なら、予約投稿で対応
移行作業を実施（または代行が実施）
動作確認（必ずやる）
確認する場所は3つだけでOKです
- トップページ（表示・デザイン崩れ）
- 記事ページ（画像表示・内部リンク）
- フォーム（送信テストまで）
- 可能なら管理画面ログイン
ネームサーバー変更（最後）
- ここで初めて本番切り替え
- 反映に 最大72時間程度 かかることがあります
最終確認
- 切り替え後にもう一度、トップ／記事／フォームを確認
- 旧サーバーはすぐ解約しない（数日〜1週間は保険で保持）

メールを使っている場合に追加で必要な作業

メールが絡むと、サイト以上に「止まると困る」ので先に整理します。

最初に決めること（超重要）

メールの受信先はどこ？
- サーバーで受ける
- Gmail等に転送して運用する
- 既存のメールサービスを使い続ける

ネームサーバー変更の前にやること（最低限）

mixhost側でメールを使うなら、先に
- メールアカウント作成
- 必要なら転送設定
- メールソフト設定（IMAP/SMTP）
切り替え直後は、DNS反映のズレで
- 一時的に旧サーバーに届く／新サーバーに届く
  が混在しやすいので、重要メールが来る期間は特に注意

安全策（現実的に効く）

切り替え当日は、問い合わせフォームの通知先を一時的に別メール（Gmailなど）にしておく
重要なやり取りがある週は、切り替え日を避ける

mixhost 公式サイト

よくあるトラブル解決（mixhost×WordPressの詰まりポイント集）

サイトが真っ白/500系エラー：まず疑う3つ（テーマ・プラグイン・PHP）

真っ白（白画面）や「500 Internal Server Error」は、原因が広く見えても だいたい次の3つに収束します。

テーマ（更新・切り替え・カスタマイズ直後）
プラグイン（追加/更新/キャッシュ/セキュリティ系が多い）
PHPバージョン（テーマ/プラグインが未対応）

最短で切り分ける手順（戻しやすい順）

直前に変えたものを思い出す（更新履歴）
　「更新した／入れた／有効化した」ものがあるなら、それが最有力です。
WP Toolkit（またはWordPress Manager）でプラグインを一括停止してみる
　管理画面に入れない状態でも、サーバー側からプラグインの有効/無効を切り替えられるのが強みです。
　- まずは 全停止 → 表示確認
　- 表示できたら 1つずつ戻す（犯人を特定）
テーマを一時的にデフォルトへ切り替える
　テーマ起因なら、ここで復旧することが多いです。
　（子テーマを触った直後なら特に有力）
PHPバージョンを“試験的に”変更する（互換性チェック）
　古いテーマ/プラグインは、PHPの新しい版でエラーになることがあります。
　まずは ひとつ前の安定版などへ一時的に変更して、表示が戻るか確認します。

この症状の“やりがちNG”

いきなり大量の設定をON/OFFして、原因が追えなくなる
キャッシュ最適化（CSS/JS）まで同時に触って、崩れの要因が増える

復旧できたら、最後にこれだけ

直前の変更をメモ（次の再発防止）
バックアップを1つ作る（“直った状態”を保存）

データベース接続エラー：確認する順番（DB情報→権限→障害情報）

「データベース接続確立エラー」は、落ち着いて順番どおり見れば高確率で解決します。
ポイントは “wp-config.phpの情報” と “cPanel側のDB設定” が一致しているかです。

確認の順番（これ以外は後回しでOK）

wp-config.phpのDB情報が正しいか
　確認するのは次の4つです。
- DB名
- DBユーザー名
- DBパスワード
- DBホスト（環境により異なるため、cPanelの案内と照合）
DBユーザーがDBに割り当てられているか（権限）
　「ユーザーはあるけどDBに紐づいていない」状態だと接続できません。
　cPanel側で 該当DBにユーザーが割り当てられているかを確認します。
障害・メンテ情報を確認する
　設定が合っているのに突然発生した場合は、サーバー側要因の可能性もあります。
　公式の案内（お知らせ等）を確認し、必要ならサポートへ連絡するのが早いです。

安全のコツ

wp-config.phpを編集する前に、ファイルをコピーして退避（戻せるように）
“推測で書き換え”はしない（合っている箇所まで壊れる）

SSLは有効なのに鍵マークが出ない（混在コンテンツの残り）

httpsで開けるのに鍵マークが出ない場合、原因の多くは 混在コンテンツです。
つまり、ページ内の一部が http:// のまま読み込まれている状態です。

よくある混在の正体（多い順）

記事内の画像URLが http のまま
テーマが外部ファイル（フォント/JS）を http で読み込む
計測タグや外部スクリプトが http

最短で直す流れ

まず“どのURLがhttpか”を特定
　Chromeなら開発者ツールで混在URLが表示されます（原因のURLが出るので最短）。
WordPressのURLをhttpsに統一
　サイトアドレス/WordPressアドレスが http のままだと、混在が増えやすいです。
残ったhttpを解消（応急 → 根本の順が安全）
- 応急：混在修正系プラグインで表示を整える
- 根本：DB内の http://あなたのドメイン を https://あなたのドメイン に置換
  ※必ずバックアップ→試し実行（ドライラン）→本番実行の順

キャッシュ導入後にデザイン変更が反映されない

「外観を変えたのに反映されない」は、壊れているのではなく キャッシュが残っているだけのケースが大半です。

まず理解しておくとラクなこと
LiteSpeed Cacheは、記事編集などをきっかけに自動で消えるキャッシュもありますが、
外観カスタマイズは 手動で消さないと反映されないことがあります。

“消しどころ”テンプレ（効く順）

LiteSpeed Cache（WordPress側）：全パージ
ブラウザ：スーパーリロード／シークレットで確認
cPanel側（ある場合）：LiteSpeed Web Cache ManagerでFlush
CDNを使っている場合：CDNキャッシュも削除

それでも戻らないときの切り分け

変更したのが「CSS/JS最適化」に関わる箇所 → 一時的に最適化をOFFにして確認
画像だけ変わらない → 画像最適化/WebP/遅延読み込みの影響を疑う

ログインできない/管理画面が重い：緊急対応テンプレ

最後は「今すぐ何とかしたい」系です。ここは テンプレ通りに動くと早いです。

A：ログインできない（最短で戻す）

パスワードが怪しい
　→ サーバー側（WP Toolkit / Softaculous等）から再設定できるか確認
何度も失敗してブロックされた可能性
　→ セキュリティ機能によりIPがブロックされる場合があります
　- いったん時間を置く
　- CAPTCHAが出る場合はそれに従う
　- 解消しない場合はサポートへ（グローバルIPなどが必要）

B：管理画面が重い（原因を減らす）

管理画面の重さは「機能盛りすぎ」で起きがちです。まずは原因を減らします。

キャッシュ/最適化プラグイン：設定を攻めすぎていないか（特にJS最適化）
プラグイン数：使っていないものは停止→削除
直前に入れたプラグイン：いったん無効化して改善するか確認
画像最適化/バックアップの実行中：処理中は重くなりやすい（時間を置く）

緊急時の基本ルール（これだけ守れば事故が減ります）

変更は1つずつ
直ったらすぐバックアップ
直らないのに触り続けない（ログが追えなくなる）

mixhost 公式サイト

向いている人・向かない人（料金/サポート/機能で判断）

向いている：速度重視、複数サイト運用、移行も想定している

mixhost×WordPressは、ざっくり言うと 「速さと運用のしやすさを、あとから伸ばしやすいサーバー」 です。次に当てはまる人は相性がいいです。

速度を武器にしたい（SEOもCVも体感も）

LiteSpeed環境＋LiteSpeed Cacheで、表示速度を伸ばしやすい
“重くなりがちなWordPress”を、キャッシュ前提で組み立てられる

複数サイトを運用したい

1つの契約でサイトが増えても「管理画面が散らかりにくい」
（WP Toolkit / WordPress Managerで、一覧管理やログインがしやすい）
料金や機能が段階的なので、最初は小さく始めて必要に応じて上げやすい

移行を“いつかやる”前提で動きたい

WordPressの移行手段が複数（ログイン情報での移行、プラグイン移行、移行代行など）
移行は結局「確認と切り替え」が9割なので、移行ルートが多いのは安心材料

目安があると決めやすい人

プラン比較で「推奨PV」や「inode上限」などの目安が提示されているため、選定がラクです。
例（レンタルサーバー）：推奨PVはライト10万/月、スタンダード20万/月、プレミアム30万/月、ビジネス60万/月。inodeはライト10万、スタンダード20万、プレミアム40万、ビジネス60万など。

注意が必要：手厚い電話サポート前提、超シンプルな管理画面が好み

mixhostが悪いというより、期待する運用スタイルによってはミスマッチになりやすいポイントです。

電話で“すぐ聞いて、すぐ解決”したい

公式の案内上、問い合わせ導線は「契約前/契約後のお問い合わせフォーム」が中心です。
文章で状況整理→問い合わせ→回答、の流れが合わない人はストレスになりがちです。
なお、Zoomサポート（予約枠/回数券）が用意されているため、「文章だけは不安」という人は逃げ道があります（ただし基本は別枠扱い）。

管理画面は“超シンプル一択”がいい

cPanelは機能が多いぶん、最初は迷いやすいです。
ただ、慣れると「困ったときの設定が揃っている」のが強みに変わります。
逆に、最低限の項目しか見たくない人には情報量が多く感じることがあります。

WordPressの“中身まで”全部サポートしてほしい

サポート範囲は「WordPressの基本操作」までで、ソースコード解析が必要な領域は対象外というスタンスです。
（テーマの深い改造・プラグインの競合解析などを丸投げしたい人は注意）

他社と比較する時のチェック項目（初期費用より更新・機能・移行）

比較で失敗しやすいのは、初回割引だけで決めることです。次のチェック表で見比べると判断がブレません。

1）料金（初回と更新）

✅ 初回割引は「初回支払い期間のみ」か
✅ 更新時の月額換算はいくらか（契約期間ごとに変わる）
✅ 支払いは一括前払いか（期間分まとめて、月額換算表示のケースが多い）

2）バックアップ（標準装備か・保持日数）

✅ 自動バックアップがプランに含まれるか（含まれないプランがある場合も）
✅ 保持日数（例：14日など）
✅ 復元が「ファイル/DB単位」でできるか

3）テスト環境（壊さず触れるか）

✅ ステージング／サイト複製が必要か（テーマ変更や大型更新をするなら重要）
✅ Smart Update（更新で壊れないか事前チェック）のような機能があるか
✅ どのプランから使えるか（“Deluxe”系機能は上位プラン側に寄りやすい）

4）運用のしやすさ（管理の一元化）

✅ WordPressを一覧で管理できるか（複数サイト運用なら効いてくる）
✅ ワンクリックログイン・メンテナンスモードなど、実務で使う機能があるか

5）移行（将来の引っ越しコスト）

✅ 移行の選択肢（ログイン情報移行／プラグイン移行／代行）
✅ 代行の料金と対象外（マルチサイト等）
✅ 切り替え当日の段取り（更新停止→動作確認→ネームサーバー変更）を想定できるか

比較の結論（迷ったら）

“安く始めたい”より、「更新後の負担」と「事故ったときの戻しやすさ」 を優先すると後悔が減ります。
WordPressは運用で必ず触るので、バックアップ・複製・管理の一元化は“保険”ではなく“日用品”です。

mixhost 公式サイト

よくある質問（FAQ）

クイックスタートを選ばなかった場合、あとから最短で入れる方法は？

最短で迷わないのは、次のどちらかです（結論：迷ったらWP Toolkit）。

WP Toolkit（cPanel内）
→ WordPressのインストールだけでなく、更新・バックアップ・複製など“運用”までまとめて扱える
WordPress Manager（マイページ起点）
→ 手順が少なく、画面がシンプルで初心者が迷いにくい

最短ルート（WP Toolkitの考え方）

先にドメインを使える状態にする（追加ドメインなら先に設定）
cPanel → WordPress Management → WP Toolkit → インストール
インストール先を決める
- 迷ったら ドメイン直下（https://example.com/）
管理者ユーザー名・パスワードを設定して実行
完了したら 管理画面（/wp-admin）にログインして初期設定へ

“時短のコツ”

最初はプラグインを盛らず、「ログインできる＋表示できる」までを最短で作る
SSL（https）がまだなら、先にSSLを有効化してからURL統一をする（混在コンテンツを減らせます）

wwwあり/なしはどっちがいい？途中で変えられる？

SEO的には、wwwあり/なしのどちらが有利という決定打はありません。
大事なのは どちらか一方に統一し、もう片方は 301リダイレクトで寄せることです。

おすすめの決め方（初心者向け）

こだわりがない → wwwなしに統一（短くて扱いやすい）
すでに名刺やSNSなどでwww付きが定着 → wwwありに統一

途中で変えられる？
変えられます。ただし“やり方”を間違えると、

検索評価が分散しやすい
http/httpsやwww混在で鍵マークが消える
キャッシュやリダイレクトが絡んで原因不明になる

といった事故が起きがちです。

安全な変更の基本（最小セット）

cPanelの「リダイレクト」で、統一先へ301リダイレクトを設定
WordPressのURL（サイトアドレス/WordPressアドレス）を統一先に合わせる
キャッシュを削除して確認（ブラウザ／プラグイン／CDN）

ポイント：“wwwの変更＝URL変更”なので、サイトが育ってからやるほど影響が大きいです。できれば初期に決めて固定しましょう。

複数サイトはどう作る？サブドメインとディレクトリの使い分けは？

複数サイト運用は、最初に「分け方」を決めると後が楽です。
使い分けは、目的（ブランドを分けるか／管理を分けるか）で決められます。

使い分け早見表

スクロールできます

方式	URL例	向いているケース	注意点
サブドメイン	blog.example.com	本体と別ブランド・別運用にしたい／実験サイトを切り離したい	SSL設定や計測設定を分けて管理しやすい反面、管理対象が増える
サブディレクトリ	example.com/blog	同じサイトの一部として運用したい（企業サイト＋ブログ等）	URL構造が一体なので、統一感は出るが“移行/切り離し”はやや手間
別ドメイン	example-blog.com	完全に独立させたい（別事業/別ターゲット）	ドメイン費用・管理工数は増えるが自由度は最大

初心者の結論（迷ったら）

企業サイト＋ブログ → /blog（サブディレクトリ）
1つのドメインで複数テーマ（趣味/仕事など）を分けたい → サブドメイン
将来的に売却や譲渡まで考える → 別ドメイン

mixhost側の実務ポイント
複数サイトを増やすなら、WP Toolkit / WordPress Managerで「一覧管理」できる状態にしておくと、
「どのURLがどのWordPressか」が迷子になりません。

高速化プラグインはLiteSpeed Cache以外でもいい？

使えます。ただしmixhostはLiteSpeed環境なので、基本方針としては LiteSpeed Cacheが最も相性が良いです。
（サーバーと連携できるため、同じ“キャッシュ”でも効き方が違います）

他の高速化プラグインを使うなら守るべきルール

ページキャッシュは二重にしない
例：LiteSpeed CacheのページキャッシュON＋別プラグインのページキャッシュON
→ 表示崩れ・更新反映されない・ログイン問題が起きやすくなります
役割分担を決める
- ページキャッシュ：どれか1つ
- 画像最適化：別ツールでもOK（ただし重複に注意）
- CDN：使うならキャッシュ削除手順もセットで覚える

おすすめの考え方（初心者向け）