dead links audit
死にリンク0と報告した後に3種類出た|絶対URLと301の裏を検査する記録
複数のサイトで古いページを刈り取り、410(恒久的に削除)にしたあと、「サイト内の死にリンクは0」と報告しました。ところが同じ日のうちに3種類の漏れが出ました。原因は、検査が相対パスのhrefだけを数えていたことです。この面は2026年9月26日の実測を、自分のサイトで同じことを確かめたい人向けの手順にまとめたものです。
このサイトはAnthropicの公式サイトではありません。Claude Codeの機能・料金・提供範囲は変わる可能性があるため、重要な判断の前には公式のドキュメントと自分のアカウント設定を確認してください。
先に結論:死にリンクは3か所に隠れる
ページを消したあと、そのURLを指している場所は次の3つに分かれます。相対hrefの検索で見つかるのは、このうち1つ目の一部にすぎません。
| 隠れ場所 | 具体例 | 検査で見落とす理由 |
|---|---|---|
| 自ホストを絶対URLで書いたリンク | 構造化データの Offer.url、canonical、og:url、本文中の完全URL | 「href が / で始まるもの」だけ数えると入らない |
| 転送先が410になった301 | 設定ファイルの 301 の行。旧URLは生きているように見えて、先が410 | 旧URLは200ではなく301を返すので、リンク検査は「生きている」と判断する |
| 姉妹サイトからの参照と301 | 別サイトが自分のページを、消えた側のスラッグへ301している | 自サイトのファイルだけ走査しても見えない |
消した数が多いほど、この3か所の合計は「相対hrefの死にリンク」を上回ります。0と報告する前に、3つとも数える検査に変える必要があります。
読者が確かめる手順
- 消したURLの一覧を先に固定する。410にしたパスをファイルに書き出します。あとで「どれを消したか」を思い出す作業をなくすためです。
- 自サイトの全HTMLから、相対と絶対の両方で一覧を検索する。相対なら
href="/old-page/"、絶対ならhttps://自分のホスト/price/の形です。grep -rlに、自ホスト名つきのパターンも必ず足します。JSON-LD の"url":と"@id":も同じ検索に入ります。 - リダイレクト設定の転送先を全部抜き出し、転送先が一覧にあるものを探す。301の行を機械的に解析して「転送先パス」の列を作り、410の一覧と突き合わせます。
- 転送元と410が同じスラッグに重なっていないか見る。書き換え規則は別名転送の仕組みより先に効くため、同じスラッグに410と301があると301が死にます。意図した転送が静かに無効になっている状態です。
- 姉妹サイトの全リポジトリを走査する。自分が消したURLを、他のサイトのHTMLや設定が指していないかを調べます。自分の担当外のサイトは直さず、持ち主に渡します。
- 直したら、本番のファイルを取り直して同じ検索をもう一度かける。手元の写しが本番と同じだとは限らないからです。
転送先を決め直すときは、旧URLも410にするか、生きている近い面へ向け直すかの二択です。410へ送る301は、検索エンジンにとって「消えた先へ案内している」状態で、どちらの意味も弱めます。
数え方の注意として、リンク検査の全体像は内部リンクの本数を数える記録に、検査の道具そのものが嘘をつく例は検査コードの欠陥を直した記録にあります。
実際に起きた記録:9サイトの刈り取り(2026年9月26日)
この日、9つのサイトで中身の薄いページを刈り取りました。検査は相対hrefの死にリンクを数え、結果は0でした。そのあとで検査の範囲を広げたところ、次が出ました。
- 絶対URLの参照:あるサイトでは、410にした料金ページを、構造化データの Offer.url が指していました。しかもそのうち1サイトは、すでに本番へ出ていました。別のサイトにも同じ形がありました。人が目で見る本文のリンクは直っているのに、検索エンジンだけが読む部分が残っていた形です。
- 410へ送る301:あるサイトの設定ファイルに18本、別のサイトに2本、さらに別のサイトに76本。本数が多いのは、古い規則を畳まずに足し続けてきたからです。
- 姉妹サイトからの参照:あるサイトは自分の3ページを、姉妹サイトの同名スラッグへ301していて、その先が410になっていました。同じ形がほかに2組ありました。自サイトを0にしても、姉妹側の参照は別に数える必要があります。
直したあとの運用も変えました。刈り取り用の検査道具は、相対href、自ホストの絶対URL、設定ファイルの301の3つを見るようにしました。網をまたぐ分は、全リポジトリの出力フォルダを走査して、410にしたURLへの参照を出す別の道具で数えます。
もう1つ大事な点があります。生成元のプログラムが転送先を決めているサイトでは、設定ファイルを直接直してもビルドで元に戻ります。寄せ先の対応表を生成元の側に作り、そこで上書きしないと直りません。この種の戻りは生成元の写しに他サイトの痕跡が残る記録と同じ構造です。
この記録で確かめていないこと
外部のサイトが自分のURLを指している被リンクは、ここでは数えていません。自分が持つサイトの内部と、持ち主が同じ姉妹サイトの範囲に限った話です。外部の被リンクは、サーチコンソールのリンクの画面か、アクセスログの参照元で別に確かめてください。
この記録から作った点検の順番
刈り取りのたびに、次の順で回すことにしました。①消したURLの一覧を固定する。②自サイトを相対・絶対の両方で検索する。③リダイレクト設定の転送先を抜き出して一覧と突き合わせる。④姉妹サイトの全リポジトリを走査する。⑤直した結果を、手元ではなく本番のファイルで再検索する。どれも読むだけの検査なので、本番を傷めません。報告の書き方も変えました。「死にリンク0」とだけ書かず、どの3か所を何本ずつ数えたかを並べます。範囲を書かない0は、範囲外の漏れを隠してしまうからです。
もう1つ、構造化データは人が目で見ないので放置されやすい場所です。ページを消すときは、見える本文のリンクと同じ重さで、JSON-LDのurlの値も一覧に入れてください。
公式の記載で見る:Googleが301・404・410をどう扱うか(2026年11月15日確認)
410へ送る301や、消した面への参照を数える理由は、Google検索セントラルの「HTTP ステータスコード、ネットワーク エラー、DNS エラー」に書かれた扱いからも確かめられます。
- 301(恒久的な移動):Googleはリダイレクトに従い、転送先を処理の対象にすることの「強い」シグナルとして扱います。
- 404と410:この2つは、429を除く4xx系とまとめて説明されています。クロールの仕組みは、内容が存在しないことを次の処理へ伝え、登録済みのURLは検索のインデックスから削除されます。新しく見つかった404のURLは処理されず、クロールの頻度は徐々に下がります。
この記載から、次の整理ができます。301の転送先が410なら、旧URLは強いシグナルで転送先へ向けられ、転送先は存在しない扱いになります。つまり旧URLから来た評価の行き先が、消えた面になります。サイト内に残る参照(絶対URLや姉妹サイトからのリンク)は、クロールの頻度が下がるまで、消した面を訪ねさせ続けます。相対hrefだけでなく、絶対URLと転送の先まで数える手順に、この仕組みの裏づけがあります。出典:Google 検索セントラル「HTTP ステータス コード、ネットワーク エラー、DNS エラーと Google 検索」(2026年11月15日確認)。
よくある質問
410にしたページへ301を張れば、死にリンクは解決しますか。
旧URLを生きている近い面へ301するのは有効ですが、転送先が410だと意味がありません。転送先が200を返すことを、本番のURLで必ず確かめます。
絶対URLの参照はどう探せばいいですか。
自分のホスト名を含む完全URLの文字列で、HTMLと設定ファイルを全文検索します。構造化データ(JSON-LD)のurlとidも同じ検索に入ります。相対パスの検索と別に一回かけるのがコツです。
姉妹サイトの分も自分が直すべきですか。
持ち主が違うサイトは、触らずに持ち主へ「どのURLが何を指しているか」の一覧を渡す方が安全です。同じ担当の範囲内なら、生成元の対応表の側を直します。