WordPressリンク切れチェック比較:WPMU DEVとAIOSEO

記事や外部資料へのリンクを定期点検するなら、WPMU DEVとAIOSEOのBroken Link Checkerを比較できます。WPMU DEVはローカル・クラウド方式の選択、AIOSEOはアカウント接続型のクラウド検査と月間枠を中心に検討しましょう。どちらの結果も削除対象の確定一覧ではなく、実際のアクセスと内容を確認する候補です。

リンク検査と404ログは何が違いますか?

リンク検査は、自分の記事やメニューが指しているURLを見つけ、リンク先を調べます。404アクセスログは、自サイトに存在しないURLへのリクエストを記録します。誰もクリックしていない誤記も検査で見つけられますが、自動スキャンの要求はどの記事からもリンクしていない場合があります。

例えば古いインストール記事が削除済みの公式文書を引用している場合、リンク検査はそのURLと掲載記事を特定するのに役立ちます。自サイトの記事を移した場合は本文リンクを更新し、外部から旧URLへ来る人のために必要なリダイレクトを別に用意します。外部サーバーの障害を自サイトの転送で直すことはできません。

内部・外部リンクに加え、画像、動画、メニュー、カスタムフィールドも対象にするか決めましょう。本文だけの検査をサイト全体の確認と考えないことが大切です。動画ページは開けても動画自体が非公開になった場合のように、応答コードだけでは判断できない資料もあります。

実行場所・アカウント・検査枠を比較します

方式 実行場所と接続 比較する点 導入前の確認
WPMU DEV Local 自サイトのサーバー。クラウド接続とは別 WordPress内での検査と修正 サーバー資源、頻度、対応コンテンツ
WPMU DEV Cloud WPMU DEVサーバー。Hub接続が必要 外部検査エンジンとHubの結果画面 無料アカウントの制限と公開アクセス範囲
AIOSEO Cloud AIOSEOサービス。アカウントと検査枠を確認 エラー理由とリンクの掲載場所 内部・外部の範囲、月間枠、再検査の条件

WPMU DEV:ローカルとクラウドで対象が異なります

WPMU DEVの公式文書はLocalとCloudを区別しています。クラウドにはHub接続が必要ですが、必ず有料会員でなければならないわけではありません。無料アカウントにも再検査や実行の制限があるため、無料Hubの条件を確認してください。両方式を同じ条件の無制限サービスとは考えないようにします。

ローカル検査は自サーバーを使うため、大きなサイトでは負荷と頻度を確認します。クラウドは公開アクセスに依存するので、会員専用ページ、メンテナンス画面の背後にある記事、通常のナビゲーションから到達できない孤立ページを調べ切れない場合があります。公式文書も方式による結果の違いを説明しています。マルチサイトの子サイトには別の条件がないかも確認しましょう。

AIOSEO:検査量と外部リンクの適用範囲を分けます

AIOSEOは接続したアカウントのサービスを使います。料金案内と配布説明の無料枠は月250件で、有料プランは月間量とサイト数が異なります。リンク数は記事数ではありません。一つの記事に多数のURLがあれば複数の検査項目が生じるため、記事が少なくても毎回の全件検査が枠内とは限りません。

無料の外部リンク対応には確認が必要です。WordPress.orgの説明は「月250件の内部リンク」としていますが、公式変更履歴の1.2.6は無料を含む全プランの外部対応を記載しています。文言が一致しないため、無料版は常に内部専用と断定したり、外部検査が無制限と約束したりしません。外部資料が主な目的なら、接続アカウントの範囲と残り枠を確認し、内部・外部の例を一つずつ試して選びましょう。

現在の配布案内はメニュー、カスタムフィールド、同期パターン、対応ページビルダーのデータも扱います。ただし発見できることと、報告画面から直接安全に書き換えられることは別です。ビルダーの記事はその編集画面で修正する場合もあるので、報告された掲載場所を確認してください。

初回は小さい範囲で検査します

公式の配布経路から導入し、重要な公開記事を中心に始めます。本文を書き換える操作の前にはバックアップと戻し方を用意しましょう。外部アカウントを接続するなら、どのURLや結果を送信・保管するかも確認します。

  1. 方式を選びます。WPMU DEVのLink CheckerではLocalとCloudを区別し、Cloudなら接続案内に従います。AIOSEOではアカウントとプランの状態を確認します。
  2. コンテンツと資料の範囲を決めます。投稿・固定ページ・メニュー・画像など必要な対象を選び、ログイン専用URLや外部連携先は公開資料と分けて扱います。
  3. 検査が完了したか調べます。待機中・検査中・失敗を区別します。結果が0件でも完了や正常の証拠にはなりません。接続、残り枠、公開アクセス、ローカル処理の実行を確認します。
  4. リンク先と掲載場所を記録します。URL、該当記事やメニュー、応答または理由、最終検査時刻を残します。多数の記事で同じURLを使っていないか調べ、優先順位を付けます。
  5. 一件を手動確認して修正します。以下の基準で実際のリンクを確かめてから該当箇所を直します。一括変更前には対象と件数を確認してください。

削除文書を複数記事で引用していたら、同じ主題の新しい公式文書を探します。現在の説明を裏付ける場合だけ置き換え、記事の主張も読み直します。開けるだけの別ページへ変更すると、エラーは消えても根拠が誤ったままになります。

エラー表示と実際の削除を区別します

結果 考えられる意味 次に確認すること
404・410 削除、URL誤り、アクセス方法の差 誤記と公式サイトの移転・検索情報
301・302など 移転または一時案内 最終URLと内容が同じ資料か
403・405・418 自動アクセスや要求方式の拒否の可能性 通常のブラウザーで開き、HEADだけ失敗ならGETでも確認
429 要求頻度の制限の可能性 検査頻度を下げ、時間を置いて再確認
5xx・タイムアウト 一時障害や応答の遅れ 後で再確認し、繰り返すか記録
200だが別の内容 ログイン・点検・エラー表示、資料変更 必要な根拠や機能が本当にあるか読む

HEADは本文を取得せず応答情報を求め、GETは実際の内容を取得します。自動要求が拒否されても通常のブラウザーで開ける場合があります。逆に検査では応答があっても、訪問者のブラウザーには証明書の警告が出る場合もあります。数字だけで有効・安全と結論付けず、警告の回避や証明書検証の停止で検査を通そうとしないでください。

ログイン中の運営者だけが読める資料なら、一般の読者のアクセスも検討します。制限自体がリンク切れとは限りませんが、無料公開ガイドとして紹介した先が会員限定になれば、紹介文や出典を調整する必要があります。AIOSEOのエラー説明も遮断・時間切れ・ログイン必要・証明書問題を分けているので、理由を読んで判断しましょう。

修正後の確認と運用間隔を決めます

自分の誤記は正しいURLへ直し、公式資料が移転したら同等の新しい場所へ変更します。代替根拠がないなら、リンクを外すだけでなく依存していた主張も見直します。正常な資料が自動検査だけ拒む場合は理由を記録し、必要な除外を設定して時々再確認しましょう。

公開記事でリンク文言、到着内容、画像表示、動画再生を確認し、対象を再検査します。複数箇所を変更したら本文以外の共通メニューや同期パターンへの影響も調べます。誤修正を戻せるよう、変更前のURLと文章を保存してください。

小規模なブログなら新記事や大きな更新の際に確認し、外部引用が多い記事には定期点検を加えられます。全件を毎日何度も調べる必要はありません。サーバー資源、クラウド枠、外部の頻度制限を考慮し、予約処理が実行されるかも確認しましょう。メール報告を使うなら通知の受信も試します。

読者がよく使う重要リンク、多くの記事にある無効URL、主張の根拠となる外部資料を優先すると整理しやすくなります。点検は読者が必要な情報へ到達するための保守であり、エラー数を減らすだけで検索順位の向上を保証するものではありません。結果と実際の内容を一緒に検討しましょう。