参照元ページの更新とHTTPSの被リンク — リンク切れと混在コンテンツを自分で点検する（2026年8月時点）

01 いま最新版は何か — HTTPSと被リンク評価をめぐるGoogleの説明

HTTPSがランキング要因に採用された経緯

被リンク元のページがHTTPS化されているかどうかは、なぜ気にする必要があるのでしょうか。まず押さえておきたい一次情報があります。Google Search Central Blogは、2026年から遡ること12年、2014年8月の記事(HTTPS as a ranking signal(訳: ランキング要因としてのHTTPS))で、HTTPSの利用を軽微なランキング要因として使い始めたと発表しました。同記事は「今のところ、この要因が持つ影響力は、良質なコンテンツを持つ他の要因と比べると軽い」としながらも、「時間をかけて、この要因をより重要にしていくかもしれない」とも述べています。

2015年、HTTPSページがデフォルトで優先的に索引される仕組みに

その後、2015年12月の記事(Indexing HTTPS pages by default(訳: HTTPSページをデフォルトで索引する))では、HTTPとHTTPSの両方が存在するページについて、特に指定が無くてもHTTPS版を優先的に索引するという方針転換が発表されました。この記事の中でGoogleは「これはHTTPSページが増えてきたことを踏まえた変更であり、常時HTTPS化を検討しているサイト運営者にとって、追加の作業を減らすものだ」と説明しています。

ブラウザ側もHTTPを「非セキュア」と表示するように

Googleの検索チームだけでなく、Chromeチームも同じ方向に動いています。2016年9月のセキュリティブログ(Moving towards a more secure web(訳: よりセキュアなWebへ))は、翌年からChromeがHTTPページの一部を「非セキュア」と表示し始めることを予告しました。検索エンジンのランキングだけでなく、ブラウザの表示という形でもHTTP前提のページには不利が積み重なっていったことがわかります。この記事では、被リンク元のページがこの流れにどう対応しているかを、自分のサイトの立場から確認する方法を整理します。

02 なぜ・背景 — 参照元ページは自分で書き換えられない

被リンク元は「相手の資産」である

自分のサイトの内部リンクであれば、リンク切れやURLの表記ゆれに気づけばすぐに修正できます。しかし被リンク元のページ——他のサイトが自分のサイトへ向けて張ってくれているリンク——は、相手の資産であり、自分の意思では書き換えられません。相手サイトがURLを変更したり、HTTPSへ移行したり、あるいはページ自体を削除したりすると、その影響はこちらの被リンクの状態にそのまま反映されます。この非対称性が、参照元ページの点検を「自分のサイトの点検」とは別の作業として扱う必要がある理由です。

混在コンテンツ(mixed content)というリスク

参照元ページの更新が引き起こす具体的な現象のひとつが混在コンテンツ(mixed content)です。web.devの解説記事(What is mixed content?(訳: 混在コンテンツとは何か))は、「HTTPSで配信されているページが、画像・スクリプト・スタイルシートなどのリソースをHTTP経由で読み込んでいる状態」がこれにあたると説明しています。参照元ページが常時HTTPSへ移行する過程で、自サイトへのリンクや埋め込みリソースの一部がHTTPのまま取り残されると、この混在コンテンツが発生することがあります。

Googleが求めるリンクの形と、崩れると何が起きるか

もうひとつ見落としやすいのが、リンクそのもののマークアップの形です。Googleのリンクに関する公式ドキュメント(Link best practices for Google(訳: Googleにおけるリンクのベストプラクティス))は、「Googleが確実にクロールできるのは、href属性を持つ<a>要素のリンクだけだ」と明記しています。同ドキュメントは、<span href="...">やonclick="goto(...)"のようなJavaScriptイベントに依存した記法を「Googleが試みて解釈することはあるが、推奨されない」形として挙げています。参照元サイトがリニューアルなどでJavaScriptだけのクリックイベントに切り替えた場合、ページ自体は残っていても、Googleにとってはそのリンクが「見えなくなる」可能性があります。参照元ページが健在に見えても、被リンクとしての効力が失われていることがある、という点は見落としやすいポイントです。

放置されたリンク切れは、時間をかけて評価から外れる

被リンク元ではなく、こちら側が発信しているリンクが切れてしまうケースにも触れておきます。HTTPステータスコードの扱いを説明する公式ドキュメント(How HTTP status codes affect Google's crawlers(訳: HTTPステータスコードがGoogleのクローラーに与える影響))は、「以前使われていたURLが4xxステータスを返すようになった場合、Googleのシステムは時間をかけてそのURLの利用を停止する」と説明しています。これは被リンク元にも、当サイトが外部へ張っている発リンクにも同じように当てはまります。リンク切れは即座に評価を失わせるわけではありませんが、放置する期間が長いほど、評価から外れていくという理解を持っておく必要があります。

HTTPS移行は「サイト移転」の一種として扱われる

参照元ページがHTTPからHTTPSへ移行する場合、Googleはこれを単なる設定変更ではなくサイト移転の一種として扱います。サイト移転を扱う公式ドキュメント(Site Moves and Migrations(訳: サイトの移転))は、移転の代表例として真っ先に「HTTPからHTTPSへのURL変更」を挙げています。つまり参照元サイトがHTTPS移行を行うとき、内部では旧URL(HTTP版)から新URL(HTTPS版)へのリダイレクトが設定され、この記事の前半で扱った301リダイレクトと同じ仕組みが働いているはずです。参照元ページのリンクがHTTPのまま残っている場合、リダイレクトを経由してこちらに到達しているのか、それともリダイレクトすら設定されずリンク切れになっているのかを、区別して確認する必要があります。

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

混在コンテンツ(mixed content)とは

rel="sponsored" / rel="ugc" / rel="nofollow"とは

アンカーテキストとは

前掲のLink best practices for Googleは、アンカーテキスト(リンクの視認テキスト)について「具体的で、簡潔で、リンク先の内容と関連していること」が望ましいと述べています。参照元ページのアンカーテキストが「こちら」「詳しくはこちら」のような汎用的な表現から、より具体的な表現に更新されることもあります。この変化自体は被リンクの有効性を損なうものではありませんが、参照元の更新履歴を把握する手がかりのひとつになります。

04 型別 — 適用範囲・限界・手順

🅰 適用範囲 — このガイドが当てはまる場面

このガイドが特に役立つのは、他サイトから被リンクを受けているサイト全般です。新しく立ち上げたばかりで被リンクがまだ無いサイトでは、点検の対象自体が存在しないため、優先度は相対的に低くなります。まずは05章のチェックリストの最初の項目で、自分のサイトが現在どれだけの被リンクを持っているかを確認するところから始めるのが妥当です。

🅱 定期点検が保証しないこと

被リンク元の点検を定期的に行っても、それだけで解決しないことがあります。点検はあくまで「現時点での状態を確認する」行為であり、参照元サイトが点検の直後に更新してしまえば、また状態は変わります。02章で触れたとおり、参照元ページは相手の資産であるため、こちらにできるのは状態を把握し、必要であれば連絡するところまでです。強制的に修正させる手段は基本的にありません。

🅲 手順 — 参照元点検の流れ

実際の点検は、07章で扱う4段階(収集・到達性確認・HTTPS確認・記録)に沿って進めます。まず記事や被リンクレポートから参照元URLの一覧を作り、次に1件ずつHTTPステータスを確認し、HTTPのまま残っていないかを確認し、最後に確認日と結果を記録に残す、という流れです。

よくある失敗パターン

実務でよく見られる失敗が、被リンクの点検を「一度やって終わり」にしてしまうケースです。参照元ページは自分の管理下に無いため、いつ更新されるかを予測できません。定期的に繰り返し確認する仕組みを持たないと、リンク切れやHTTPのまま残ったリンクに気づかないまま長期間が経過してしまいます。もうひとつの失敗は、被リンクの本数だけを見て、個別の状態を確認しないことです。本数が変わらなくても、その内訳(到達性・HTTPS化の状況)は変化している可能性があります。

05 自分のサイトで確認するチェックリスト

チェックリストの3つの観点

ここまでの内容を、今日から手を動かせる作業に翻訳しました。観点は、被リンクの現状把握、到達性とHTTPSの点検、記録の運用確認の3つに分かれます。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されません。

• Search Consoleの「リンク」レポートを開き、被リンク元のドメインを10件書き出す
• その10件について、実際にブラウザでアクセスし、ステータスコードが200で表示されるか確認する
• 200で表示されたページの中に、実際に自分のサイトへのリンクが残っているか確認する
• そのリンクのURLがHTTPSで始まっているか、HTTPのまま残っていないか確認する
• 参照元ページの「ソースを表示」を開き、自サイトへのリンクが<a href>の形式になっているか確認する(JavaScriptのみのリンクになっていないか)
• 参照元ページの読み込みリソース(画像・スクリプト等)に、HTTP経由のものが混ざっていないかブラウザの開発者ツールで確認する
• 自分の記事内で外部サイトへ張っている引用元リンクを5本選び、到達性を確認する(参照元と発リンクの両方を点検する)
• その5本のリンクに付与しているrel属性(nofollow等)が、リンクの性質と合っているか確認する
• 参照元ページのアンカーテキストが、自分のサイトを正しく指し示す内容になっているか確認する
• Search Consoleの「ページ」レポートを開き、自サイトのHTTP版URLが索引に残っていないか確認する
• 被リンク元の点検結果(参照元URL・最終確認日・ステータスコード・HTTPS化の有無)を記録する一覧が社内に存在するか確認する(無ければ「無し」と記録する)
• 前回の点検からの経過日数を数え、一定期間(たとえば3か月)を超えていないか確認する

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

最初の3項目は被リンクの現状把握、4番目から6番目はHTTPSとマークアップの点検、7番目から9番目は自分が発信する側のリンクの点検、10番目から12番目は記録と運用の確認に対応しています。すべてに目を通す時間の目安は被リンク元10件あたり20分程度です。まずはSearch Consoleで確認できる被リンク元の中から、掲載順位や流入の多いページを優先して手を動かし始めることをおすすめします。

06 参照元点検の観点比較

3つの点検観点、それぞれで見えるもの

参照元ページの点検には、複数の観点があり、どれか1つだけでは全体像がつかめません。以下は、それぞれの観点が「何を検出できて、何を検出できないか」を整理した表です。

観点	検出できること	検出できないこと
HTTPステータス 確認	ページが200で表示されるか、リンク切れ(404等)になっていないか	ページ内にリンクが実際に残っているかどうか
ソース表示 での確認	リンクが<a href>形式か、HTTPかHTTPSか	JavaScriptで動的に生成されるリンク(レンダリング後にしか現れない)
当サイトの (🔧 WEBサイト総合分析ツール・無料)	ページ全体の技術的な健全性(HTTPS化・混在コンテンツ等)をまとめて確認	被リンクとして自サイトへ向いているかどうかの判定は含まれない

組み合わせて使うのが前提

この表からわかるとおり、HTTPステータス確認だけでは「ページが生きているか」しかわかりません。実際にリンクが残っているか、そのリンクがHTTPSかどうかまで確認するには、ソースを直接開く作業が欠かせません。特にJavaScriptで動的にリンクを生成しているサイトでは、単純なHTTPステータス確認だけでは、リンクの有無を正しく判定できないことがあります。当サイトの🔧 WEBサイト総合分析ツールを使えば、自分のサイトが参照元として見られたときの技術的な健全性を、被リンクの点検と並行して確認できます。

07 当サイトの実測

既存記事1本の外部リンク12本を実際にチェックした

このガイドを書く過程で、当サイトが実際に発信している側のリンクも確認しました。既存記事1本(URLパラメータを扱った回)に掲載している外部リンク12本を抽出し、それぞれのHTTPステータスを実際に確認したところ、12本すべてが200で到達しました。これは06章で触れた「発リンクの点検」を実践した結果であり、公開時点では一次情報への参照が正しく機能していることを確認できた形です。

確認の方法は、記事本文からリンクのURLだけを抽出し、1本ずつ実際にHTTPリクエストを送ってステータスコードを取得するというものです。06章の比較表で触れたとおり、この方法で分かるのは「ページが200で応答するか」までで、そのページの中に当サイトへの言及が実際に残っているかどうかは別途確認する必要があります。今回の12本は、いずれも当サイトが引用している一次情報(公式ドキュメントやヘルプページ)であり、ページの性質上、内容が急に差し替わる可能性は低いと考えられますが、この前提が崩れる場合もあるため、定期的な再確認は必要です。

canonicalタグがHTTPSで一貫しているかを確認した

あわせて、自サイトの記事ページのcanonicalタグが、常にHTTPSの絶対URLを指しているかも確認しました。複数の記事ページのソースを直接開いたところ、いずれもHTTPSの自サイトURLを自己参照するcanonicalタグになっており、HTTPとHTTPSが混在する形でcanonicalが指定されている箇所は見つかりませんでした。これは02章で触れた混在コンテンツのリスクとは別の話ですが、参照元として他サイトから引用されたときに、どちらのURLが正規版として扱われるべきかを、当サイト側から明確に示せている状態です。

今回確認できたのは「発リンク」側だけである

今回実際に確認できたのは、当サイトが外部へ向けて張っている発リンクの到達性と、自サイトのcanonicalタグの一貫性です。02章で触れたとおり、被リンク元——他サイトが当サイトへ向けて張っているリンク——の点検は、相手のページを1件ずつ開いて確認する必要があり、今回のような一括チェックとは性質が異なります。05章のチェックリストにあるとおり、この2つは別の作業として、どちらも継続的に行う必要があります。発リンクは自分の記事を編集するだけで直せますが、被リンクは相手に連絡するか、あるいは相手の更新を待つことしかできません。この非対称性を前提に、点検の頻度や優先順位を決めておくと、限られた時間を効率よく使えます。

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

被リンクの時代は終わったのかを検証した回

AIに引用される「ブランドメンション」と、従来型の被リンクの関係を整理した回があります(archives/73)。本記事の02章で扱った「参照元ページは相手の資産である」という前提は、被リンクという評価軸そのものが今どう位置づけられているかという、この回の議論の延長線上にあります。

4層の整合性をcurlで確認した回

sitemap・canonical・内部リンク・末尾スラッシュという4つの要素が食い違っていないかを、curlコマンド3行で確認する方法を以前まとめたことがあります(archives/39)。本記事の07章で扱ったcanonicalタグの確認は、この4層整合性の一部を、被リンクという観点から改めて確認したものです。

出力は在った。だから誰も測らなかった回

datePublished・og:type・用語ハイライト・sitemapという4つの項目で、「値が出ているように見えて、実は違う値だった」という穴を見つけた回があります(archives/128)。02章で触れた「参照元ページが健在に見えても、被リンクとしての効力が失われていることがある」という論点は、この回で扱った「出力の有無」と「値の正しさ」のズレと同じ構造を持っています。

記事をつなげ、サイトに知性をと題した回

記事同士を内部リンクでつなぎ、サイト全体の構造を設計する考え方を以前まとめたことがあります(archives/6)。03章で触れたアンカーテキストの重要性は、この内部リンク設計とまったく同じ考え方が、外部からの被リンクにも当てはまることを示しています。

再クロール待ち行列547件を記録した回

URLを書き換えた際、Googleの再クロールが完了するまでに実際どれくらいの時間がかかるかを、547件の待ち行列とともに記録した回もあります(archives/108)。02章で触れたHTTPS移行後の再クロールも、この記事で扱った待ち行列と同じ仕組みの上で進みます。参照元サイトがHTTPS移行を発表した直後に点検しても、Googleの索引側の反映がまだ追いついていないことがある、という前提を持っておくと、点検の結果を早合点せずに済みます。