リンクをクロール可能にする ── href属性が無ければ、Googleには読まれない13項目（2026年9月時点）

01 何が起きたか — Googleが「クロール可能なリンク」の条件を1ページに整理している

<a href>タグだけが、クロールされるリンクの形

Google Search Centralの「リンクをクロール可能にする」というページには、検索エンジンが「これはリンクだ」と認識できる条件が明記されている。要点は単純で、href属性を持つ<a>要素だけが、クロール可能なリンクとして扱われるというものだ。公式ドキュメントはこう説明している。「Googleはリンクを、ページの関連性を判断する信号として、また新しいページを見つける手段として使う」。この2つの役割（発見と信号）は、いずれもhref属性を実際に読み取ることが前提になっている。逆に言えば、見た目がリンクのように動いていても、href属性が存在しない、または解釈できない形式で書かれていれば、Googleはそのリンクをたどることも、評価に使うこともできない。

検索エンジンが読めないリンクの共通パターン

公式ドキュメントは「Googleが確実に解析できないパターン」として、具体的な書き方を列挙している。href属性を持たない<a>要素、onclick="goto('url')"のようにスクリプトのイベントハンドラだけでURLを渡す形、<span href="url">のようにリンク以外の要素にhrefを付けてしまう形、href="javascript:goTo('products')"のようにjavascript:プロトコルを使う形、そしてAngularなどのフレームワークが使うrouterLink="products/category"のような独自属性である。これらはすべて、ブラウザ上ではクリックして遷移できるにもかかわらず、Googleのクローラーからは「リンクではない何か」として扱われる。見た目の挙動とクロールされるかどうかは、まったく別の話だということが、この列挙からはっきり分かる。

この基準が、他のSEO対策より前段に置かれる理由

コンテンツの質やmeta descriptionの書き方、構造化データの整備など、SEOの施策には数多くの論点がある。だが、それらの施策がどれだけ丁寧に行われていても、そのページへ至るリンクがクロール可能な形で書かれていなければ、施策の効果を測る以前の段階でつまずく。新しく公開したページが検索結果に一切出てこない、更新した内容がいつまでも反映されない、といった相談の多くは、コンテンツの質より前に、リンクの形式そのものを確認したほうが早く原因にたどり着くことがある。本記事の確認作業は地味に見えるかもしれないが、他の施策の土台に位置する作業だと捉えておくとよい。

02 なぜ・背景 — リンクは「発見」と「評価の通り道」の両方を担っている

リンクが担う2つの役割

リンクがクロールされないと何が起きるのか。公式ドキュメントの説明を分解すると、失われるものは2つある。1つ目は新しいページの発見である。サイト内の他のページや、外部サイトへの新しいページは、多くの場合リンクをたどることで見つかる。リンクが読めなければ、そのリンク先のページはクロールの起点として認識されない（別の経路、たとえばsitemapや外部からの被リンクがあれば発見はされうるが、その内部リンクからの発見という経路は失われる）。2つ目は関連性の信号である。あるページから別のページへリンクが張られていること自体が、両者の関連性やページの重要度を判断する材料としてGoogleに使われている。リンクが読めなければ、この信号も届かない。見た目のナビゲーションは機能していても、検索エンジンの評価という観点では、そのリンクは存在しないのと同じになる。

JavaScriptで挿入されたリンクは「後から」読まれる

もう1つ押さえておく必要があるのが、JavaScriptで動的に挿入されるリンクの扱いである。Googleの「JavaScript SEOの基礎を理解する」ページによれば、Googleのシステムは「クロール・レンダリング・インデックス登録」という3つの段階を経てページを処理する。まずGooglebotがURLを取得してリンクを抽出し、次にそのページをレンダリングキューに入れ、Chromiumベースのレンダラーが実際にJavaScriptを実行して初めて、動的に挿入されたリンクが見える状態になる。公式ドキュメントは次のように明記している。

"The page may stay on this queue for a few seconds, but it can take longer than that."

（訳: ページはこのキューに数秒間とどまることもあるが、それより長くかかることもある。）

(前掲のUnderstand JavaScript SEO basics)　つまり、JavaScriptで生成されたリンクであっても、正しく<a href>の形で出力されていれば最終的には読まれる。ただし「最終的に読まれる」までの時間は保証されておらず、静的HTMLに書かれたリンクより発見が遅れる可能性があるという点は、更新頻度の高いページを扱うサイトでは無視できない差になる。

リンクの評価は、サイト内でも受け渡される

「発見」と「評価の信号」という2つの役割のうち、評価の信号のほうは、外部サイトからの被リンクだけでなく、自分のサイト内のページ同士のリンク（内部リンク）でも同じように働く。トップページやカテゴリページなど、サイト内で多くのリンクを受けているページから新しい記事へリンクを張ると、そのページの発見と評価の両方が後押しされる。逆に、内部リンクがクロール不可のパターンで書かれていると、外部からの被リンクがどれだけ充実していても、サイト内での評価の受け渡しという経路が1つ失われることになる。共通のヘッダーやフッター、パンくずリストといった全ページ共通の部品は、サイト内の評価を広く行き渡らせる役割を担っているため、04章で述べるとおり優先して確認したい箇所である。

03 この記事で出てくる用語

なぜ同じ「クリックできる」でも、明暗が分かれるのか

WEBディレクターの立場からすると、「クリックすれば正しいページに移動する」ことと「Googleがそのリンクをたどれる」ことは、まったく別の合格基準だと考えたほうがよい。ブラウザは寛容で、onclickにJavaScriptの関数を書いてURLを組み立てるような実装でも、ユーザーの操作に応じて問題なく画面を遷移させる。だがGoogleの説明によれば、Google検索はページを操作しない。クリックもスクロールも行わないという前提でクロールの仕組みが作られているため、ユーザー操作をきっかけに動くリンクは、たとえ機能的には正しくても、発見も評価も行われない。この前提の違いが、同じ「動くリンク」の間で明暗を分ける理由である。

04 型別 — 適用範囲・この記事が測っていないこと・手順

🅰 適用範囲 — どんな場面でこの基準が効いてくるか

この基準が特に効いてくる場面は3つある。第一に、フロントエンドフレームワーク（React・Vue・Angularなど）でサイトを構築している場合。ルーティングライブラリの標準的な書き方が、そのままではクロール不可のパターンに該当することがある。第二に、「もっと見る」ボタンや無限スクロールなど、JavaScriptでコンテンツを後から差し込む実装をしている場合。第三に、ヘッダー・フッター・パンくずリストなど、サイト全体に配置される共通部品を1つのテンプレートで管理している場合。共通部品にクロール不可のパターンが1つ混ざると、その影響はサイト全体の全ページに及ぶ。逆に、通常のHTMLで<a href>を直接書いている静的なページ構成であれば、この記事で扱う問題が発生する可能性は低い。

🅱 この記事が測っていないこと

この記事は「リンクがクロール可能な形で書かれているか」という、マークアップの形式面だけを扱っている。リンク先のページ自体が実際にインデックスされるかどうか、リンクの本数や配置がページの評価（ランキング）にどれだけ影響するか、アンカーテキストの内容が適切かどうかといった論点は範囲外である。また、JavaScriptのレンダリングそのものが失敗するケース（スクリプトエラー・タイムアウトなど）についても、この記事では扱っていない。それらは別の観点からの確認が必要になる。

🅲 手順 — 3段階で確認する

確認は、棚卸し・分類・修正の3段階で進めるとやりやすい。まず自分のサイトの主要なテンプレート（ヘッダー・フッター・一覧ページのカード・パンくずリストなど）を対象に、リンクとして機能している箇所をすべて書き出す（棚卸し）。次に、それぞれのマークアップが<a href>の形になっているか、あるいは公式ドキュメントが挙げる非対応パターンのいずれかに該当するかを分類する。最後に、非対応パターンが見つかった箇所について、href属性を持つ<a>要素へ書き換える。onclick自体を削除する必要はない。公式ドキュメントの推奨例にも<a href="/products/category/shoes" onclick="javascript:goTo('shoes')">という、hrefとonclickを併用する形が挙げられており、href属性さえ正しく設定されていれば、onclickによる追加の挙動を残しても問題にならない。

05 明日、自分のサイトで確認できることチェックリスト

ここまでの内容を、実際に手を動かせる作業に翻訳した。観点は、現状把握（サイト内のリンクの書き方を洗い出す）、非対応パターンの検出、実際の見え方の確認、修正後の検証、の4つに分かれる。

• ヘッダー・フッター・グローバルナビゲーションのHTMLソースを開き、リンクが<a href>の形で出力されているか確認する
• 一覧ページのカード（商品・記事のサムネイル部分）のリンク先が、カード全体をクリックできる場合でも<a href>で実装されているか確認する
• フロントエンドフレームワークを使っている場合、ルーティング部分の実装が独自のrouterLink属性のみになっていないか、フレームワークのドキュメントで確認する
• ソースコード全体をhref="javascript:で検索し、javascript:プロトコルを使ったリンクが何件あるか数える
• ソースコード全体をonclick=で検索し、href属性を伴わずにonclickだけでページ遷移させている箇所が何件あるか数える
• <span href=や<div href=のように、a要素以外にhref属性を付けている箇所がないか検索する
• 「もっと見る」ボタンや無限スクロールで後から表示される部分のリンクも、同じ形式で書かれているか確認する
• 非対応パターンが見つかった場合、そのリンクをhref属性を持つ<a>要素に書き換える（onclickは削除せず併用してよい）
• 修正した1ページをGoogle Search ConsoleのURL検査ツールで検査し、「取得したページ」のHTMLにリンクが<a href>として含まれているか確認する
• 同じURL検査ツールの「ライブテスト」で、レンダリング後のスクリーンショットとHTMLも合わせて確認する
• 修正前後で、対象ページからのリンク数がクロールの起点として意図どおり増減しているか、数日後にSearch Consoleの「クロール統計情報」で確認する
• サイト内のリンクチェックツールで、修正後にリンク切れが新たに発生していないか確認する
• 主要テンプレート1つの修正が完了したら、同じテンプレートを使う他のページにも反映されているか、無作為に3ページ選んで確認する

13項目の内訳と、かかる時間の目安

13項目は4つの観点に対応している。それぞれの観点にどの項目が入り、目安としてどれくらいの時間がかかるかを、以下の表にまとめた。

すべてに目を通す時間の目安は1テンプレートあたり40〜55分程度である（Search Console側の反映を待つ工程を含めると、確認完了までに数日を要することがある）。まずはヘッダー・フッターなどサイト全体に影響する共通部品から確認するとよい。

見落としやすい3つのポイント

チェックリストを実施する際に見落としやすい点が3つある。1つ目は、「もっと見る」ボタンなど、初期表示時には存在せずJavaScriptで後から追加される要素。これらは通常のHTMLソース表示（右クリック→ページのソースを表示）では確認できず、ブラウザの開発者ツールでレンダリング後のDOMを見る必要がある。2つ目は、広告配信タグやアクセス解析タグが動的に挿入するリンク。自社の実装ではなく外部スクリプトが生成するリンクは見落とされがちだが、サイトの評価という観点では同じ基準が適用される。3つ目は、PC版とスマートフォン版でテンプレートが分かれている場合、両方を個別に確認する必要があるという点である。片方のテンプレートだけ修正して、もう片方に同じ問題が残っているケースは珍しくない。

06 代替・他の選択肢（表で）

5つの書き方の、できることとできないこと

リンクの実装方法にはいくつかの選択肢があるが、それぞれクロールされるかどうかが異なる。以下は、公式ドキュメントが挙げる書き方を整理した表である。

この表から分かるとおり、「hrefという名前の属性が、a要素に付いているかどうか」が唯一の分岐点であり、onclickなどの追加の仕組みの有無は判定に影響しない。フレームワークを使う場合は、ルーティング用のコンポーネントが最終的なHTML出力として正しい<a href>を生成するかどうかを、レンダリング後のソースで確認する必要がある。

フレームワーク別に見る、実装上の注意点

React・Vue・Angularなど、代表的なフロントエンドフレームワークには、それぞれ標準のルーティングライブラリが用意されている。React Router・Vue Router・Angular Routerのいずれも、最終的に生成するHTML要素をhref属性付きの<a>タグにする設定が可能であり、多くの場合デフォルトの挙動もその形になっている。問題が起きやすいのは、独自のクリックハンドラでページ遷移を実装し、ルーティングライブラリの標準コンポーネントを使わなかった場合である。フレームワークが用意している標準の書き方（React Routerのリンク用コンポーネントなど）を使えば、多くの場合は意識しなくてもクロール可能な形でレンダリングされる。カスタム実装をしている箇所ほど、優先して確認する価値がある。

07 自社サイトで確認したこと — 自社の記事191本のリンクを数えた

非対応パターンは実在するか、自分のサイトで数えてみた

この記事を書くにあたり、当サイトのSEO関連記事191本（公開中のものと、公開前の下書きを含む）の本文ページを対象に、実際にどのようなリンクの書き方をしているかを機械的に数えてみた。結果は、<a href=の形で書かれたリンクが合計2,936本、span要素にhrefを付けた形（<span href=）は0件、javascript:プロトコルを使ったリンクも0件だった。一方で、onclick属性を併用しているリンクが1件見つかったが、確認したところhref属性も同時に指定されており、本記事06章の表で「可能」と分類した形（hrefとonclickの併用）に該当していた。クロール不可のパターンに該当する箇所は、少なくともこの191本の範囲では見つからなかった。

この確認でも分からないこと

今回の機械的な検索は、テキストパターンの一致で判定しているため、判定できないことも残る。たとえば、フレームワークのコンポーネントが実行時に生成するHTMLは、サーバー側であらかじめ生成された静的HTMLの中には現れない。当サイトのSEO関連記事は静的HTMLとして出力される構成のため今回の方法で概ね確認できたが、JavaScriptでレンダリングされる部分を多く持つサイトでは、ブラウザの開発者ツールでレンダリング後のDOMを確認する方法と組み合わせる必要がある。この点は05章のチェックリストにも、レンダリング後の確認手順として組み込んである。

08 このテーマの、これまで

「リンクは在るが、飛び先が正しくない」という別の失敗

リンクがクロール可能な形式で書かれていることと、そのリンクが正しい飛び先を指していることは、また別の話である。自社ブログの内部リンクを実際に数えたところ、リンク切れ自体は0本だったにもかかわらず、内部リンクの59.2%がnoindex設定されたページを指していたという事例を扱った回がある(archives/134)。HTTPステータスが200で返るため、リンクチェックツールだけでは気づけない種類の不具合であり、本記事の確認作業とあわせて実施する価値がある。

クロールされるまでの待ち時間を、実際の数字で確認した回

02章で触れたレンダリングキューの話に関連して、当サイトでは実際にクロールの待ち行列がどれくらいの規模になっているかを、Search Consoleのデータから確認した回もある(archives/108)。「最長2週間」という公式の説明の意味を、実際の待ち件数とあわせて整理している。リンクが正しくクロール可能な形式で書かれていても、発見からクロールの実行までにはこうした待ち時間が挟まることを、あわせて押さえておくとよい。

sitemap・canonical・内部リンクの整合性を、まとめて確認する回

リンクの書き方以外にも、サイト内の情報が整合しているかどうかを機械的に確認する方法を扱った回がある。sitemap・canonical・内部リンク・末尾スラッシュの4つをcurlコマンド3行で揃える方法を紹介した回(archives/39)と、sitemapに書いたURLがGoogleから実際にどう見えていたかを確認した回(archives/38)は、いずれも本記事のチェックリストと組み合わせて実施すると、サイト全体のリンク構造をより広い範囲で点検できる。

内部リンクの設計を、トピカルマップの観点から見直した回

個々のリンクがクロール可能な形で書かれているかという本記事の確認作業は、いわば土台の点検である。その土台の上で、どのページからどのページへリンクを張るべきかという設計そのものを扱った回もある(archives/6)。記事同士のつながりをトピックのまとまりとして設計する考え方を紹介しており、本記事のチェックリストで土台を整えたあと、次のステップとして参照する位置づけになる。