“`html
WordPressで長くサイトを運営していると、以前は正常だったリンクがいつの間にか開けなくなっていることがあります。
例えば、
- 削除した自分のページへの内部リンク
- URLを変更した記事への古いリンク
- 閉鎖された外部サイトへのリンク
- 削除された画像へのリンク
- リンク先URLの入力ミス
などです。
こうしたリンク切れを探すWordPressプラグインとして、長く利用されているのがBroken Link Checkerです。
一方で、「Broken Link Checkerを入れるとWordPressが重くなる」という話を聞いたことがある方もいるかもしれません。
現在のBroken Link Checkerは、以前とは仕組みが変わっており、自分のWordPressサーバーで検査するLocal Engineと、外部サーバーで検査するCloud-Based Engineを選べます。
そのため、「便利だけれど重いから使わない」と一律に判断するのではなく、現在の仕組みを理解して、自分のサイトに合った方法を選ぶことが大切です。
この記事では、Broken Link Checkerの現在の機能、WordPressへの負荷、リンク切れとSEOの関係、検出されたリンクの正しい直し方まで順番に解説します。
Broken Link Checkerとは？
Broken Link Checkerは、WordPress内のリンクや画像などを調べ、正常にアクセスできないURLを見つけるためのプラグインです。
現在の公式プラグインでは、投稿や固定ページだけでなく、コメント、カスタム投稿タイプなども対象にしてリンクを確認できます。
リンク切れが見つかった場合は、WordPressの管理画面から確認し、URLの編集やリンク解除などを行えます。
見つけられる代表的な問題
- 存在しないページへのリンク
- リンク切れした外部URL
- 表示できなくなった画像
- リダイレクトされているURL
- 正常に応答しないリンク
記事数が少ないサイトなら一つずつ確認することもできますが、数百本の記事が蓄積してくると、すべてのリンクを人間が定期的に確認するのは現実的ではありません。
そのようなサイトでは、リンクチェックツールを利用するメリットがあります。
リンク切れがあるとSEO順位が下がる？
ここは誤解されやすい部分です。
404エラーがサイト内に存在するだけで、正常なほかのページまでGoogle検索の順位が下がるわけではありません。
ページを削除し、代わりになるページも存在しないのであれば、そのURLが404または410を返すこと自体は正常です。
問題になるのは、例えば次のような場合です。
- 現在公開中の記事から、存在しないページへ内部リンクしている
- 重要なページを移転したのに古いURLのリンクを直していない
- 存在しないページなのにHTTPステータス200を返すsoft 404になっている
- 画像が削除され、記事内で表示できなくなっている
- 訪問者が必要な情報へ進めない状態になっている
つまり、リンク切れ対策で最初に考えるべきなのは、単純な「SEOペナルティ回避」ではありません。
訪問者が記事を読んだあと、正しい次の情報へ進める状態を維持することが重要です。
削除したページに代替ページがなければ404や410は正常です。直すべきなのは、現在公開しているページからそのURLへ誤ってリンクしている場合や、本来別のページへ案内すべき場合です。
Broken Link CheckerはWordPressを重くする？
結論からいうと、どのチェック方式を使うかによって異なります。
現在のBroken Link Checkerには、大きく分けて2種類のリンクチェック方式があります。
Cloud-Based Engine
リンクチェックの主要な処理をWPMU DEV側のクラウドで行う方式です。
自分のWordPressサーバーですべてのリンクチェックを実行する方式と比べて、サーバーへの負荷を抑えやすいのが特徴です。
記事数やURL数が多いサイト、共用サーバーなどでサーバーリソースが気になるサイトでは、検討しやすい方式です。
利用にはWPMU DEVへの接続が必要ですが、公式案内ではCloud Engineの基本機能を利用するために有料会員になることは必須ではありません。
Local Engine
自分が利用しているWordPressサーバー上でリンクチェックを行う従来型の方式です。
外部サービスへ接続せずに利用できることがメリットですが、リンク数が多いほど、リンク確認のための処理を自分のサーバーが担当することになります。
そのため、サイト規模やサーバー性能によっては負荷を意識する必要があります。
Local Engineではなぜ負荷が発生するのか
リンクチェックは、単に記事内の文字列を探すだけではありません。
大まかには、
- WordPress内からURLを探す
- リンク先へアクセスする
- HTTPの応答を確認する
- リダイレクトなどを確認する
- 結果を記録する
- 一定期間後に再確認する
といった処理が必要になります。
記事数やリンク数が増えれば、その分だけ確認対象も増えます。
1．外部URLへの通信
外部リンクが正常か判断するには、リンク先サーバーへHTTPリクエストを行う必要があります。
数十件程度なら大きな問題にならなくても、長期間運営しているブログで数千・数万のリンクが存在すれば処理量も増えます。
2．データベース処理
どの記事にどのリンクがあり、どのリンクに問題があったのかを管理するため、データベース処理も発生します。
3．バックグラウンド処理
WordPressではWP-Cronなどを使って、画面を操作していない間にも定期処理を実行できます。
WP-Cron自体はWordPressの標準的な仕組みであり、それだけで大きな問題になるものではありません。
ただし、多数のプラグインが重い定期処理を登録しているサイトでは、バックグラウンド処理全体を確認する価値があります。
ではCloud Engineを選べばよい？
サーバー負荷だけを考えれば、Cloud Engineは有力な選択肢です。
ただし、どちらにも特徴があります。
| 項目 | Cloud Engine | Local Engine |
|---|---|---|
| リンクチェック処理 | 主にクラウド側 | 自分のサーバー |
| 自サーバーへの負荷 | 抑えやすい | サイト規模によって増える |
| 外部サービスへの接続 | 必要 | 不要 |
| 大規模サイト | 利用しやすい | 負荷を確認しながら利用 |
| 外部接続を避けたい場合 | 不向き | 選択肢になる |
「どちらが正解」というより、サイトの規模、サーバー環境、外部サービス接続に対する考え方によって選択するとよいでしょう。
リンク切れが検出されても、すぐ削除しない
Broken Link Checkerでエラーが表示されたからといって、すぐにリンクを削除するのはおすすめできません。
一時的にリンク先のサーバーへ接続できなかった場合や、アクセス制限によって自動チェックだけが拒否された場合なども考えられるためです。
検出されたURLは、まず実際にブラウザから開いて確認しましょう。
リンク切れを見つけたときの正しい対処方法
リンク切れは、原因によって対応方法が異なります。
ケース1：自分の記事を別URLへ移動した
新しいページがあるなら、記事内のリンクを新URLへ変更します。
さらに旧URLへ直接アクセスする人がいる場合は、内容が対応している新URLへ301リダイレクトを設定する方法があります。
ケース2：自分の記事を完全に削除した
代わりになるページが存在しなければ、無理にトップページなどへリダイレクトする必要はありません。
404または410を返し、そのページへ向いている内部リンクを削除または修正します。
ケース3：外部サイトの記事が移動した
同じ内容の新URLが見つかれば、新しいリンクへ変更します。
ケース4：外部ページそのものがなくなった
そのリンクが文章の理解に必要なものでなければ削除します。
参考資料として重要なら、同じ内容を確認できる信頼性の高い別資料へ差し替える方法もあります。
ケース5：画像が表示されない
画像URLだけが切れているのか、画像ファイル自体が削除されたのかを確認します。
自分のWordPress内の画像なら、メディアライブラリやサーバー内のファイルを確認しましょう。
ケース6：403・429・タイムアウトなど
必ずしもページが消えているとは限りません。
アクセス制限や一時的なサーバー障害などでも発生する可能性があるため、実際にブラウザで確認してから判断します。
リンクチェックツールは「確認が必要なURLを探す道具」と考えると安全です。削除・変更する前に、人間が実際のリンク先を確認しましょう。
リンク切れ対策で優先したい順番
大量のリンク切れが見つかった場合、すべてを同じ優先度で修正する必要はありません。
次の順番で対応すると整理しやすくなります。
優先度1：重要な内部リンク
サービスページ、問い合わせ、商品ページ、関連記事など、訪問者の次の行動につながるリンクを優先します。
優先度2：画像やファイル
記事内の画像、PDF、ダウンロード資料などが表示できない場合もユーザー体験への影響が大きいため確認します。
優先度3：記事内容の根拠となる外部リンク
官公庁や公式資料、参考データなどへのリンクが切れていれば、新しい公式URLがないか探します。
優先度4：補助的な外部リンク
本文の理解に大きく影響しないリンクは、その後で整理してもよいでしょう。
Broken Link Checkerの負荷を抑えて使う方法
1．可能ならCloud Engineを検討する
サーバー負荷が心配な場合は、現在用意されているCloud Engineを検討できます。
2．必要以上に頻繁なスキャンを行わない
リンクは秒単位で監視しなければならないものではありません。
記事更新頻度やリンク数に合わせて、必要な頻度で確認します。
3．チェック対象を必要な範囲にする
Local Engineを使用する場合は、確認する投稿タイプなどの設定を見直し、不要な対象までチェックしていないか確認します。
4．サーバー負荷を確認する
プラグインを有効にした前後で、
- 管理画面が極端に遅くならないか
- CPU使用量
- メモリ使用量
- データベース負荷
- サーバーのエラーログ
などに大きな変化がないか確認すると判断しやすくなります。
5．使っていないプラグインを増やしすぎない
WordPressの動作が遅い場合、原因がBroken Link Checker一つとは限りません。
バックアップ、セキュリティ、アクセス解析、画像処理、SNS連携など、複数のプラグインがバックグラウンド処理を行っている可能性があります。
サイト全体を見て判断することが重要です。
Broken Link Checkerを常時入れる必要はある？
サイトによって異なります。
常時監視が役立ちやすいサイト
- 記事数が多い
- 外部リンクが多い
- 商品やサービスへのリンクが多い
- 複数人で記事を更新している
- 古い記事を大量に保有している
定期的な確認でも対応しやすいサイト
- ページ数が少ない
- 外部リンクがほとんどない
- 更新頻度が低い
- サイト構成が単純
小規模なサイトなら、常時リンクチェックするより、サイト更新後や数か月ごとなど必要なタイミングで点検する方法でも管理できます。
リンクチェックだけでサイト管理は十分ではない
Broken Link Checkerが調べるのは、主にリンクが正常に応答するかどうかです。
しかし、正常に開くURLだからといって、そのリンクが現在の記事に適切とは限りません。
例えば、3年前の記事から古い制度説明へリンクしていて、そのページ自体は現在も表示できるケースがあります。
この場合、リンクチェックでは「正常」と判断されても、記事の情報としては古くなっている可能性があります。
そのため古い記事をメンテナンスするときは、
- リンクが開くか
- リンク先の内容が現在も正しいか
- より新しい公式情報がないか
- 自分の記事本文も古くなっていないか
まで確認すると、より役立つ記事を維持できます。
まとめ｜現在は「重いから使わない」ではなく方式を選ぶ
Broken Link Checkerは、WordPressサイト内のリンク切れを効率よく発見するための便利なツールです。
以前からLocal Engineによるサーバー負荷が話題になることがありましたが、現在は自サーバーへの負荷を抑えやすいCloud-Based Engineも用意されています。
そのため、現在は単純に「Broken Link Checkerは重いプラグイン」と考えるより、
- CloudとLocalのどちらを使うか
- サイトに何本くらいリンクがあるか
- どの程度の頻度で確認する必要があるか
- 自分のサーバーに余裕があるか
を考えて選ぶのが適切です。
そして、リンク切れが検出されたら、機械的に削除するのではなく、
- 本当にリンク切れなのか確認する
- 新しいURLがないか探す
- 移転ならリンク変更や301リダイレクトを検討する
- 完全削除なら不要な内部リンクを取り除く
- 代替ページがない404は無理にリダイレクトしない
という順番で対応しましょう。
リンク切れ対策の目的は、エラーの数字をゼロにすることではありません。
サイトを訪れた人が迷わず必要な情報へ進める状態を保つことが最も重要です。
参考情報
- WordPress.org「Broken Link Checker」
- WPMU DEV「Broken Link Checker Documentation」
- WordPress Developer Resources「PHP Optimization」
- Google Search Central「Troubleshoot crawling errors」
“`
