夜中に重い腰を上げてサーバー移行を決意し、祈るように「簡単移行」のボタンを押す。
……なのに、画面には無情にもタイムアウトのエラー表示。
「えっ、嘘でしょ……明日も朝から仕事なのに」
絶望でパソコンをそっと閉じた経験、あなたにもありませんか？
私もまったく同じ経験があります。
何年もかけて育ててきたブログ。画像もたくさん入っているし、記事数も膨大。それをシンレンタルサーバーに引っ越そうとしたら、容量が大きすぎて移行がストップしてしまうという悲劇。
ネットで調べると「不要な画像を削除しましょう」「サイトを軽くしましょう」なんて正論ばかりが出てきます。
でも、本音を言えば「ブログの表示に必要な画像をちまちま消してたら、レイアウト崩れるし無理だよ……」ですよね。
実は、大容量サイトの簡単移行が失敗するとき、あなたが最初に削るべきなのは「画像」ではありません。
この記事では、私が実際に何十GBという巨大サイトを移行させたときの泥臭い失敗談をもとに、「絶対に消してはいけないデータ」と「真っ先に捨てるべき過去のゴミ」の見分け方をお伝えします。
「会社を辞めずに、限られた時間で賢くサイトを運営したい」。そんなあなたの無駄な時間をこれ以上奪わないための、リアルな生存戦略です。
結論｜移行失敗時はWordPress本体より「不要な巨大ファイル」を先に確認する
「サイトの容量が大きいから簡単移行に失敗した」
そう突きつけられたとき、多くの人は真っ先に「uploads」フォルダ、つまり今まで一生懸命アップロードしてきた画像にメスを入れようとします。
でも、ちょっと待ってください。
結論からお伝えすると、移行ツールが悲鳴を上げる原因は、あなたが書いた記事や画像そのものではないケースがほとんど。
本当の犯人は、サーバーの奥底に眠っている「不要な巨大ファイル」たちという現実。
例えば、過去にプラグインが自動生成した古いバックアップZIPファイル。
エラーを吐き出し続けたまま放置されている巨大なログデータ。
あるいは、以前別のサーバーから引っ越してきたときに使った移行ツールの残骸……。
これらは、今のあなたのブログを表示するためには「1ミリも必要のないデータ」です。
引っ越しをするとき、新居に「何年も開けていないゴミ袋」をわざわざトラックに積んで持っていく人はいませんよね？
サーバー移行も全く同じ。まずはWordPress本体（サイトの命）ではなく、その周りにこびりついている不要な巨大ファイルを特定して捨てる。これが、タイムアウトを回避する最短ルートです。
実際にWordPress簡単移行でタイムアウト・バックアップ失敗が起きた
偉そうなことを言っていますが、私も過去に盛大にやらかしています。
何年も運営している思い入れのあるサイトを、新しいサーバーへ移そうとしたときのこと。
簡単移行中にタイムアウトした
マニュアル通りに移行元の情報とパスワードを入力し、「あとは待つだけだ」とドヤ顔でコーヒーを淹れに行きました。
戻ってきて画面を見ると、そこには無情なエラーメッセージ。
処理が重すぎて途中で通信が切れてしまう、いわゆる「タイムアウト」です。
「え、簡単移行プラグインって全自動でやってくれるんじゃないの？」
焦って何度か再実行ボタンを押しましたが、結果は同じ。時間だけが深夜2時、3時と過ぎていき、翌日の通勤電車の中では白目になりながらスマホで解決策を探すハメになりました。
データベースのバックアップで失敗したケース
別のサイトでは、ファイルのコピーすら始まらず、その手前の「データベースのバックアップ処理」の段階でコケたこともあります。
データベースといえば、これまで書き溜めてきた記事のテキストデータなどが詰まっている心臓部。
「まさか、記事データが壊れた？」と一瞬血の気が引きましたが、冷静に調べてみると、データベースそのものが異常に肥大化していたり、移行ツールが一時的に作るバックアップ処理の負荷にサーバーが耐えられなくなっていたのが原因でした。
調べるとサイト容量が想像以上に大きかった
「いくらなんでも、ただのブログなのにそんなに重いわけがない」
そう思ってFTPソフト（ファイルマネージャー）を開いて、サイト全体の容量を確認したときの衝撃は今でも忘れられません。
数GB程度だと思っていたサイト容量が、なんと数十GB、ひどいものでは数百GBにまで膨れ上がっていたのです。
「俺、こんなに画像アップしたっけ……？」
パニックになりながらフォルダの中身を一つずつ開いていくと、そこには私がすっかり忘れていた「過去の遺物」たちが、デカデカと居座っていました。
WordPressの容量はどこで確認する？
「サイトの容量がデカいのは分かった。じゃあ、自分のサイトのどこがどれくらい重いのか、どうやって調べればいいの？」
当時の私は、そもそもここから躓きました。
普段、WordPressの管理画面（ダッシュボード）で記事を書いているだけだと、サイト全体の容量なんて見えないんですよね。
確認するためには、現在あなたが使っている「移行元サーバー」のコントロールパネルから「ファイルマネージャー」を開くか、FTPソフトを使ってサーバーの中身を直接覗き込む必要があります。
「うわ、黒い画面とか英語の羅列とか苦手なんだけど……」
大丈夫です。私もプログラマーではないので、最初はアレルギーが出そうになりました。でも、見るべき場所は決まっています。
まずは現状把握。以下の順番でフォルダのプロパティ（容量）をチェックしてみてください。
public_html全体
まずは、あなたのサイトの全データが入っている大元、「public_html」フォルダ（サーバーによってはドメイン名のフォルダ）の容量を確認します。
これが例えば「2GB」とかなら、簡単移行ツールでもサクッと終わるはず。
しかし、ここが「50GB」「100GB」と表示された場合。
間違いなく、この中に巨大な“何か”が潜んでいます。
wp-content
「public_html」の中に入り、さらに「wp-content」というフォルダを探して容量を見ます。
実は、WordPress本体のシステムファイル自体は数MB〜数十MB程度しかありません。容量を食い潰している犯人の99%は、この「wp-content」フォルダの中にいます。
ここは、テーマ、プラグイン、そして画像などのアップロードファイルが格納される場所。
このフォルダが異常に重いことを確認したら、さらにその奥へと進みます。
uploads
「wp-content」の中にある「uploads」フォルダ。
本来は、あなたが記事に挿入した画像ファイルが「2021」「2022」のように年・月ごとに整理されて保存されている場所です。
普通にブログを運営していれば、ここが一番大きくなるのは当然。
しかし、後述しますが「uploads＝画像だけが入っている」と思い込むのは非常に危険です。
バックアッププラグインの保存先
ここからが本題。
「wp-content」や「uploads」の中に、「backwpup-xxxx」や「updraft」といった、見覚えのあるプラグイン名のフォルダはありませんか？
もしあなたが、過去に「BackWPup」などのバックアップ系プラグインを入れていたなら、要注意。
多くの場合、この中に過去のバックアップファイル（ZIP形式などの巨大な塊）が蓄積されています。
過去の移行ツールが作ったフォルダ
もう一つ見落としがちなのが、「ai1wm-backups」などのフォルダ。
これは「All-in-One WP Migration」という超有名な移行プラグインが作るフォルダです。
「そういえば昔、別のサーバーから引っ越してきたときに使ったかも……」
もしそうなら、数年前のサイト丸ごとのデータが、そのまま放置されている可能性大です。
容量が大きいからといってuploadsをすぐ削除しない
ファイルマネージャーを覗いてみて、「uploads」フォルダが数十GBもあるのを発見したとき。
多くの人はこう思います。
「よし、昔の記事の画像なんて誰も見てないし、古いフォルダごと削除して容量を軽くしよう！」
ちょっと待ってください。
その手、今すぐ止めてください。それ、サイトが崩壊するフラグです。
uploadsには使用中の画像が入っている
当たり前ですが、uploadsの中には「現在進行形でサイトに表示されている画像」がたっぷり詰まっています。
これを手動で適当に消してしまうと、ブログのあちこちで画像が「リンク切れ（×マーク）」になり、レイアウトが崩壊します。
読者からすれば「なんだこの壊れたサイト？」と一瞬で離脱される原因に。
せっかく新しいサーバーで表示速度を上げようとしているのに、サイト自体を壊してしまっては本末転倒ですよね。
年月フォルダごとの削除は危険
「じゃあ、アクセスが少ない2018年のフォルダだけ丸ごと消すか」というのも悪手です。
昔の記事でも、検索エンジンから細々とアクセスを集めている「隠れたお宝記事」があるかもしれません。
また、昔アップロードした画像を、最近のプロフィールページやまとめ記事で「使い回して」いませんか？
大元の画像を消せば、当然そちらも連鎖的に消えてしまいます。
未使用画像の判定は簡単ではない
「だったら、使っていない画像だけを消せばいいのでは？」
理屈はそうなのですが、WordPressの場合、画像を1枚アップロードすると、テーマの仕様に合わせて「サムネイル用」「スマホ表示用」など、自動で複数のサイズにリサイズされた画像が生成されます。
つまり、1枚アップロードしたつもりが、サーバー上には5〜6枚の画像ファイルが存在している状態。
どれがどこで使われているかをファイルマネージャーから目視で判別するのは、完全にプロでも不可能な作業です。
だからこそ、私は断言します。
**「タイムアウトを回避するために、真っ先に画像を削ろうとするのは間違っている」**と。
私たちが狙うべきは、そんなリスクの高い「現在進行形のデータ」ではなく、安全に捨てられる「過去のゴミ」なのです。
BackWPupだけで約59GB残っていた
では、具体的に「過去のゴミ」とは何なのか。
私の実体験の中で、最も破壊力があった犯人を名指ししましょう。
それは、バックアップ系プラグインが吐き出した「過去のZIPファイル」の山です。
当時、私のサイトは簡単移行ツールがピクリとも動かず、完全にフリーズしていました。
原因を突き止めるためファイルマネージャーを漁っていた私は、あるフォルダの容量を見て、文字通りPCの前で固まりました。
「59GB……？」
私のPCのハードディスク容量じゃないですよ？
たった一つのブログの、さらにその中の一つのプラグインフォルダ（BackWPupの保存先）だけの容量です。
古いバックアップが蓄積していた
WordPressを運営しているなら、万が一のクラッシュに備えて「BackWPup」や「UpdraftPlus」などのバックアッププラグインを入れるのは鉄則。
私も過去の失敗から学び、週に1回、自動でフルバックアップを取る設定にしていました。
ここまでは良かったんです。
問題は、「保存するバックアップの世代数（残しておく数）」の設定と、その「保存場所」でした。
サイトが育って1回のフルバックアップが約2GBになっていたとして。
もしプラグインの設定で「過去30回分を保存」にしていたら？
2GB × 30回 ＝ 60GB。
そう、ブログの記事や画像が重いのではなく、サーバーの奥底で「自分のサイトのコピー」がマトリョーシカのように大量生産され、ひたすらサーバー容量を食い潰していたのです。
削除前に必要なバックアップか確認する
原因が分かれば話は早いです。
これらは現在表示されているサイトには全く影響しない「ただの過去データの塊」ですから、丸ごと削除してしまえば一気に数十分の1までサイト容量は軽くなります。
ただし、ここで焦って「ええい、全部消してしまえ！」とDeleteキーを連打するのは危険。
削除する前に、必ず「最新のバックアップZIPファイル」を1つだけ、自分のパソコンのローカルフォルダにダウンロードしておいてください。
これから大掛かりなサーバー移行をするわけですから、手元にお守り（最新のバックアップ）を残しておくのは絶対のルールです。
お守りを確保したら、あとは容赦無く古いバックアップファイルをサーバー上から消し去りましょう。
不要分を整理してから容量を再確認する
あの時、私は手元に最新のバックアップを1つだけ残し、残りの約59GB分のZIPファイルをファイルマネージャーからすべて削除しました。
そのあと、改めてサイト全体の容量を確認したときの爽快感といったら。
数十GBと表示されていた私のサイトは、スッキリと数GBにまでダイエット成功。
「これならいける！」
そう確信して再びシンレンタルの簡単移行ツールを回したところ、あれだけタイムアウトを連発していたのが嘘のように、スルスルと移行処理が進んでいきました。
移行ツール自身が巨大なデータを残していることもある
バックアッププラグイン以外にも、厄介な置き土産を残していく奴らがいます。
それが、「過去に使ったサーバー移行ツール」たちです。
「今回が初めての引っ越しじゃない」という方。
過去にエックスサーバーやConoHaなどから、別の移行プラグインを使って引っ越してきた経験はありませんか？
過去の移行データを確認する
WordPressの引っ越しにおいて超定番なのが「All-in-One WP Migration」というプラグイン。
初心者でも数クリックで引っ越しできる神ツールなのですが、こいつが残す「.wpress」という独自のバックアップファイルが、とにかく巨大になりがちです。
移行が無事に終わった後、このファイルをサーバー上から削除するのを忘れたまま何年も放置していると、それが丸ごと今回の「シンレンタルへの簡単移行」の足枷になります。
約95GBまで肥大化した実例
私の別のブログでの話。
このサイトの「public_html（全体容量）」を調べたところ、なんと約201GBというとんでもない数字を叩き出しました。
動画サイトでも運営してるのか？というレベルの異常値です。
中身を調べると、
・現在のサイト本体（uploads等の純粋なデータ）：約106GB
・過去の移行ツール関連のデータ：約95GB
という、恐ろしい内訳でした。
なぜこんなことになっていたのか？
実は過去に引っ越しをした際、移行ツールが「その時点でサーバー内に残っていた古いバックアップZIPファイル」ごと、まるっと一つのファイルに圧縮して新サーバーへ持ち込んでいたからです。
ゴミが入った袋を、さらに大きなゴミ袋で包んで持ち歩いているような状態。
そりゃあ、95GBにもなりますよね……。
「uploadsが大きい＝すべて画像が原因」とは限らない
ここで、前半でお伝えした「uploadsをすぐ削除してはいけない」という話に繋がります。
ファイルマネージャーで容量を確認したとき、「wp-content」の中の「uploads」が数十GBという絶望的な数字を出してくることがあります。
でも、安心してください。
一部のバックアッププラグインや移行ツールは、仕様上「uploads」フォルダの中に専用のフォルダ（例えば ai1wm-backups など）を作り、そこに巨大なデータを保存することがあるんです。
つまり、あなたが見た「巨大なuploadsフォルダ」の中身は、決して画像のせいだけではない可能性が高いということ。
「容量が足りない！画像を消さなきゃ！」とパニックになる前に、まずは落ち着いて「uploads」のさらに一つ下の階層を開いてみてください。
そこに、巨大なZIPファイルや「.wpress」という見慣れない拡張子の塊が眠っていないか。
それを特定して捨てるだけで、あなたのサイトの寿命は劇的に延び、サーバー移行への道がパッと開けるはずです。
データベースが大きい場合はファイル削減だけでは解決しない
「過去のゴミZIPも捨てたし、移行ツールの残骸も掃除した。ファイルマネージャーで見ても数GBまで減った。これで完璧！」
そう思って意気揚々と簡単移行ツールを回したのに、なぜかまだエラーで止まってしまう……。
そんな時に疑うべき、もう一つの見えない敵。
それが「データベースの肥大化」です。
WordPressファイルとデータベースは別
ここ、サーバー周りに詳しくない過去の私のような人はよく混同してしまうので、少しだけ整理させてください。
今までファイルマネージャーで必死に探して削除していたのは「画像・テーマ・プラグイン・古いバックアップZIP」などの、いわゆる「ファイルデータ」です。
一方、あなたが今まで心血を注いで書いてきた「記事のテキストデータ」や「サイトの各種設定」「いただいたコメント」などは、ファイルではなく「データベース（MySQL）」という全く別の引き出しに保管されています。
いくら画像やZIPファイルを消してサーバーの容量を空けても、この「データベース」の引き出し自体がパンパンになっていると、移行ツールはそこで力尽きてしまいます。
DBバックアップ段階で失敗する場合はDB容量も確認する
シンレンタルの簡単移行ツールが動く時、画面のプログレスバーをじっと見ていると「データベースのバックアップ中…」といったメッセージのままピタッと止まってしまうことがあります。
この場合、原因はファイル容量ではなく「データベースの容量が大きすぎて処理がタイムアウトしている」可能性が極めて高いです。
「テキストデータばかりのデータベースが、なんでそんなに重くなるの？」
そう思いますよね。
実は、記事を修正・更新するたびに自動保存される「リビジョン」の蓄積や、毎日飛んでくるスパムコメント、プラグインが残した一時データ（トランジェント）などが何年も溜まり続けることで、データベースが異常に膨れ上がっているケースがあるんです。
この場合は、ファイルの整理とは別に「WP-Optimize」などのプラグインを使って、データベース内の不要なゴミを掃除してあげる必要があります。
私が実際に容量を減らした順番
ここまで、移行エラーの原因となる「見えない巨大なゴミたち」の正体を見てきました。
「理屈はわかったけど、結局何から手をつければいいの？」
「間違えて必要なファイルを消しちゃいそうで怖い……」
そんな当時の私と同じように、PCの前でフリーズしているあなたに向けて。
私が実際に何十GBもある巨大サイトをダイエットさせ、簡単移行を成功させた「10のステップ」をチェックリストにまとめました。
焦っている時ほど、この順番通りに進めてみてください。
- public_html全体の容量確認
まずはファイルマネージャーでサイトの全データが入っている「public_html」のプロパティを開き、現状の総容量（敵の規模）を把握する。 - wp-content確認
WordPress本体のシステムファイルではなく、「wp-content」の中身が肥大化の元凶であることを確認する。 - uploads確認
「絶対に画像を安易に消さない」と誓いつつ、「uploads」フォルダ全体の容量をチェックする。 - バックアップフォルダ確認
「BackWPup」や「UpdraftPlus」など、バックアップ系プラグインが作った専用フォルダを特定する。 - 移行ツール関連フォルダ確認
「ai1wm-backups」など、過去に使った引越しプラグインの残骸がないか探す。 - 巨大ZIP・アーカイブ確認
ステップ4と5で見つけたフォルダの中に、数GB単位の「.zip」「.tar.gz」「.wpress」などの塊が眠っていないか目視で確認する。 - 必要なバックアップは外部保存
見つけた巨大ファイルの中から、必ず「最新のフルバックアップ」を1つだけ、自分のパソコンのローカルフォルダにダウンロード（退避）しておく。 - 不要ファイル削除
お守りを確保したら、サーバー上に残っている「過去の古いバックアップデータや移行ツールの残骸」を未練なく削除する。（※絶対に画像やシステムファイルは触らないこと！） - 容量を再確認
もう一度「public_html」の容量を確認し、数十GB単位で激減してスッキリした数値をニヤニヤしながら眺める。 - WordPress簡単移行を再実行
身軽になった状態で、祈りを込めながらシンレンタルの簡単移行ツールを回す。
この順番さえ守れば、「焦って必要な画像を消してしまい、サイトのレイアウトが崩壊する」という最悪の事態は100%防げます。
あなたが捨てるべきなのは、時間をかけて積み上げてきたブログの努力の結晶ではなく、システムが過去に吐き出したまま放置されている不要なゴミだけなのです。
容量を減らしても簡単移行できない場合
「チェックリスト通りに過去のゴミZIPも消したし、サイト容量も劇的に軽くなった。よし、今度こそ！」
そう意気込んで再実行ボタンを押したのに、またしても画面に虚無のエラー表示……。
もしあなたが今、この絶望的なループにハマっているとしたら。
痛いほど気持ちはわかります。真夜中のPCモニターの前で「もうブログごと消して寝たい」と何度思ったことか。
でも、ここまで容量のダイエットが完了しているなら、ゴールはもう目の前です。
サイトの容量以外に移行を阻んでいる「見えない壁」を一つずつ突破していきましょう。
時間を空けて再実行する
「えっ、精神論？」と思われるかもしれませんが、これ、意外とバカにできません。
私たちが使っているレンタルサーバーは、マンションのような「共有サーバー」です。
例えば、金曜日の夜や休日の夜間など、他の利用者（住人）が一斉に重い処理を行っている時間帯は、サーバー全体の動きが鈍くなります。
移行元サーバーの機嫌が悪いタイミングで無理やりデータを引っ張り出そうとしても、途中で通信がブツッと切られてタイムアウトになりやすいんです。
焦る気持ちはわかりますが、いったん画面を閉じて寝ましょう。
そして、翌朝の早朝（みんなが寝静まっている時間帯）に再実行してみると、嘘みたいにスルスルと移行が完了することが多々あります。
データベース容量も確認する
先ほども触れましたが、もし移行ツールの処理が「データベースのバックアップ中」などの表示で止まるなら、原因はファイル容量ではなく「データベースの肥大化」です。
長年ブログを運営していると、何千回という記事の下書き保存（リビジョン）や、スパムコメントの残骸がデータベースに蓄積しています。
これを「WP-Optimize」などのプラグインを使ってサクッと掃除（最適化）するだけで、データベースの処理が軽くなり、タイムアウトを抜け出せるケースがあります。
シンレンタルサポートへ確認する
「やれることは全部やった。でも動かない！」
そんな時は、一人で抱え込まずにプロに頼るのも立派な生存戦略です。
シンレンタルサーバーのサポートは、非常にレスポンスが早いことで有名。
「簡単移行ツールを使っているが、○○の段階でエラーになり進まない。旧サーバーの容量は○GBまで減らした」と、現状を具体的に添えて問い合わせてみてください。
サーバー側のエラーログを確認して、「旧サーバーのPHP制限が原因ですね」など、あなた一人では絶対に見つけられない的確な原因を教えてくれることがあります。
手動移行へ切り替える
そして、これが最後の選択肢。
時間を空けても、サポートに聞いても解決の糸口が見えない場合。あるいは、旧サーバー側のセキュリティ制限がガチガチで、自動ツールからのアクセスをことごとく弾いてしまう場合。
悔しいですが、ここで「簡単移行ツール」に見切りをつけます。
自動でダメなら、自分の手で荷物を運ぶ「手動移行」へ切り替える決断が必要です。
大容量サイトは最初から手動移行した方がいい？
「結局手動になるなら、最初から手動移行しておけばよかったじゃん……私の時間を返して！」
その気持ち、痛いほどわかります。
ただ、手動移行はFTPソフトを使ってデータを直接ダウンロード・アップロードし、データベース（phpMyAdmin）を直接触るという、初心者には少しハードルの高い作業です。
そのため、「とりあえず最初は簡単移行を試す」というアプローチ自体は間違っていません。
では、どのタイミングで「再挑戦」と「手動移行」を見極めるべきなのか。私の経験から一つの基準をお伝えします。
簡単移行を再挑戦しやすいケース
不要な過去のバックアップや移行ツールの残骸を削除した結果、サイトの総容量（public_html全体）が数GB程度まで綺麗に収まった場合。
この状態なら、サイト自体はすでに「身軽」です。
エラーの原因は、一時的なサーバーの混雑や、ちょっとした通信エラーの可能性が高い。
時間を空けたり、データベースの最適化を挟んだりして、もう一度簡単移行ツールを回してみる価値は十分にあります。
手動移行を検討しやすいケース
一方で、過去のゴミをすべて綺麗に掃除したにも関わらず、
「純粋な画像データ（現在使っているuploads）だけで数十GBもある」
「記事数が異常に多く、データベース自体が巨大すぎる」
という、正真正銘の「超・巨大優良サイト」に育ち上がっている場合。
この場合は、どんなに移行元サーバーの機嫌が良くても、ブラウザ上で動く「簡単移行ツール（PHPプログラム）」の処理能力の限界を超えてしまい、何度やってもタイムアウトになる確率が高いです。
目安として、純粋なサイトデータだけで10GB、20GBを超えてくるような猛者の場合、「自動ツールでは無理だ」と早めに見切りをつけましょう。
「手動移行」と聞くと難しそうに感じますが、やっていることは「旧居から荷物を箱詰めして、新居に運び、配置する」という単純な引っ越し作業です。
なにより、この手動移行のスキルを一度身につけてしまえば、今後どんなにサイトが巨大化しようが、どんなサーバーへ引っ越そうが、もう二度と「謎のエラー」に怯えることはなくなります。
会社を辞めずに、限られた時間でブログを運営し続ける私たちにとって、「サーバーの仕組みを直接触って理解する」ことは、一生モノの武器になるはずです。
削除候補と慎重に扱うファイルを整理
「よし、不要なファイルは消すぞ！」と決意しても、いざファイルマネージャーの英語の羅列を前にすると「これを消して本当に大丈夫か……？」と手が止まりますよね。
過去の私も、ビビり散らして冷や汗をかきながらDeleteキーを押していました。
そこで、あなたが誤って「サイトの命」を消してしまわないよう、削除していいファイルと、絶対に触ってはいけないファイルを一覧表に整理しました。
作業前に、必ずこの表を手元で確認してください。
| フォルダ・ファイル名 | 削除の可否 | 理由・注意点 |
|---|---|---|
| 古いバックアップ（.zip / .tar.gz） | 🟢 削除OK | 容量肥大化の最大の原因。最新版を1つ手元のPCにダウンロードしてから、サーバー上の古いものは全削除。 |
| 過去の移行データ（.wpress等） | 🟢 削除OK | ai1wm-backupsなどのフォルダ内にある過去の残骸。現在のサイト表示には一切不要。 |
| 巨大なログファイル（error_log等） | 🟢 削除OK | エラーが蓄積して数GBになっている場合がある。削除しても自動で再生成されるため問題なし。 |
| 使っていないテーマ・プラグイン | 🟡 慎重に | 削除してもOKだが、容量削減の効果は薄い。「現在有効化しているもの」や「子テーマ」は絶対に消さないこと。 |
| uploadsフォルダ内の画像 | ❌ NG | 「使用中」と「未使用」の判別が困難。安易に消すとサイト内の画像がリンク切れを起こしレイアウトが崩壊する。 |
| wp-config.php | ❌ 絶対NG | データベース接続情報などが書かれた心臓部。これを消すとサイトが真っ白（データベース接続確立エラー）になる。 |
| wp-admin / wp-includes | ❌ 絶対NG | WordPressを動かすためのシステムコアファイル。素人は絶対に触れてはいけない領域。 |
「容量が大きいから」という理由だけで、赤色の「❌NG」領域には絶対に手を出さないでください。
私たちが狙うのは、あくまで緑色の「🟢削除OK」のゴミデータだけです。
移行前に確認しておきたい容量チェックリスト
ここまでの泥臭い検証と実体験を踏まえて、あなたがシンレンタルの「簡単移行」ボタンを再び押す前に、最後に確認してほしい項目をチェックリストにまとめました。
指差し確認でチェックしてみてください。
- public_html全体が数十GB〜数百GBに膨れ上がっていないか？
- wp-content内に、見慣れない巨大なバックアップフォルダがないか？
- BackWPupなどのバックアップZIPデータが何世代も蓄積していないか？
- 過去の引っ越しで使ったプラグインのデータ（.wpress等）が残っていないか？
- 必ず「最新のフルバックアップ」を自分のPCにダウンロード（退避）したか？
- ファイルの容量だけでなく、データベース（MySQL）自体が肥大化していないか？
これらをクリアして、サイト全体がスッキリと数GB（純粋なサイトデータのみ）に収まっていれば、準備は完了です。
もし、このリストをこなしてもエラーが解決しない場合や、「プラグインのインストールに失敗しました」などの別なエラーが出る場合は、容量以外の問題（PHPのバージョンや移行元のセキュリティ制限など）が絡んでいます。
その際は、無理せず「シンレンタルWordPress簡単移行完全ガイド（※内部リンク）」などの専門記事を参照するか、シンレンタルの優秀なサポートを頼ってください。
まとめ｜移行する必要のないデータまで新サーバーへ運ばない
「ブログの表示を早くしたい」
「もっと安定したサーバーで、安心してサイトを育てたい」
そんな前向きな理由でシンレンタルへの移行を決意したのに、謎のタイムアウトエラーで貴重な睡眠時間と精神力を削られるのは、本当に辛いですよね。
私も、夜な夜なエラー画面と睨めっこしながら「もうブログなんて辞めてやる」と何度ふて寝したかわかりません。
でも、今回お伝えした通り、大容量サイトの簡単移行が失敗する原因の多くは、「サイトそのもの」ではなく「過去に溜め込んだゴミデータ」にあります。
「容量が大きい＝画像を消さなきゃいけない」という呪縛から解放されてください。
引っ越しで一番大事なのは、新居に持っていく必要のない「見えないゴミ袋」を、トラックに積み込む前に捨てること。
手元にしっかりと最新のバックアップという「命綱」を握りしめながら、不要な過去の遺物を切り捨てる。
この感覚さえ掴めば、あなたのサイトはもっと身軽になり、新しいサーバー環境への扉は必ず開きます。
通勤電車の揺れの中でこの記事を読んでいるあなたが、今夜こそ無事にサーバー移行を終わらせて、安心してぐっすり眠れることを心から応援しています。