サーバー・ドメイン・WordPressで
困ったときは

まず別回線や別端末でも再現するか確認し、サーバー会社の障害・メンテナンス情報を確認します。直前に設定を変えた場合は、変更箇所と時刻を記録して戻せる状態にします。

PHPや設定ファイル、プラグインなどサーバー内部の処理失敗が主な候補です。エラーログと直前の更新を確認し、原因が不明なままファイルを削除しないでください。

一時的な過負荷、メンテナンス、利用制限などが考えられます。障害情報とリソース使用量を確認し、時間を空けても続く場合はサーバー会社へ問い合わせます。

URLの入力間違い、ページ削除、パーマリンクや転送設定を確認します。移転したページには関連する新URLへの301転送を設定し、存在しないページは正しい404を返します。

障害情報、アクセス増加、容量不足、重い画像、プラグイン、外部通信の順に切り分けます。計測前に複数の高速化設定を同時変更すると原因が分かりにくくなります。

Webファイルだけでなく、メール、データベース、アクセスログ、古いバックアップも確認します。削除前に必要なデータか確認し、復元できるバックアップを確保します。

メールアカウント、容量、パスワード、送受信サーバー名、ポート、SSL設定を確認します。DNS変更直後は反映待ちの可能性もあります。

ドメインの有効期限、ネームサーバー、DNSレコード、サーバー側のドメイン設定を確認します。DNS変更直後は、環境によって新旧の応答が混在することがあります。

設定先のネームサーバーが正しいか、変更したレコード名・種類・値を確認します。端末や回線のキャッシュもあるため、複数環境で確認し、連続して設定を変えないことが大切です。

証明書の有効期限、対象ドメイン名、発行状態、サーバー時刻を確認します。秘密鍵の漏えいが疑われる場合は、提供元へ相談して証明書の失効・再発行を検討します。

ページ内の画像やスクリプトがHTTPで読み込まれる混在コンテンツを確認します。サイトURLを一括置換する前にバックアップを取り、テーマやDB内のURLも確認します。

まずレジストラの管理画面で更新・復旧可能期間を確認します。期限を過ぎると追加費用や取得不能の可能性があるため、自動更新と決済方法の有効期限を見直します。

使用するURLを一方に決め、もう一方から301転送し、canonical、内部リンク、サイトマップも統一します。別々のサイトとして公開し続けないよう確認します。

DNS反映中またはキャッシュの可能性があります。旧サーバーをすぐ解約せず、新旧双方のアクセスとメール受信を確認してから停止します。

URL、ユーザー名、パスワード、Cookieを確認し、パスワード再設定を試します。連続試行でロックされる場合があるため、むやみに繰り返さず管理者やサーバー会社へ相談します。

WordPressから届くリカバリーモードのメールを確認します。直前に更新したプラグインやテーマが原因候補ですが、作業前にファイルとDBをバックアップします。

PHPエラー、プラグイン、テーマ、メモリ不足などが候補です。公開画面へエラー詳細を表示せず、サーバーのエラーログやWordPressのリカバリーモードで確認します。

wp-config.phpの接続情報、DBサーバーの稼働、容量、ユーザー権限を確認します。DBを直接編集する作業は、知識がなければサーバー会社や制作者へ依頼してください。

更新処理が中断され、WordPress直下に.maintenanceファイルが残っている場合があります。更新状態とバックアップを確認し、判断できない場合は提供元へ相談します。

対象プラグインを停止して再現を確認し、互換性情報と変更履歴を調べます。本番サイトで直接試さず、可能ならステージング環境で検証します。

管理画面のパーマリンク設定を保存し直すと改善する場合があります。改善しない場合は、転送設定、スラッグ重複、サーバーの書換え設定を確認します。

ファイル形式・容量・画像サイズ、サーバー残容量、アップロード上限、ファイル権限を確認します。極端に大きい画像は事前に縮小・圧縮します。

迷惑メール、送信元アドレス、DNSのSPF等、サーバーのメール送信制限を確認します。重要な通知には、適切に設定したSMTP送信の利用も検討します。

ブラウザ、WordPress、サーバー、CDNの各キャッシュを順番に確認します。一度にすべて削除せず、どのキャッシュが影響しているか切り分けます。