canonicalが安全なURLを指しているとは？HTTPSで正規URLを指定する理由・診断基準・修正方法

canonicalが安全なURLを指しているとは

canonicalが安全なURLを指しているとは、ページの <head> に書く <link rel="canonical" href="..."> が示す正規URLが、https: のURLになっている状態のことです。

<link rel="canonical" href="https://www.city.example.lg.jp/">

canonical（カノニカル）は、同じ内容に複数のURLでアクセスできる場合に「正規のURLはこれです」と検索エンジンへ伝えるための要素です。この診断項目は、トップページに canonical が書かれている場合に、その指し示す先が https: のURLになっているかを確認します。

canonical 自体は認証や暗号化の仕組みではありません。しかし canonical が http:// を指していると、検索エンジンやSNSのリンクプレビュー、RSSリーダーなどが HTTP のURLを「正」として扱い、住民が検索結果から暗号化されていない入口へ誘導されるおそれがあります。HTTPS 移行の際に、CMS のテンプレートやサイトURL設定だけ古い値のまま残る、という形で起きやすい設定漏れです。

canonical の仕組み（RFC 6596）

RFC 6596 は canonical リンク関係を「重複したコンテンツが複数のURLに存在する場合の、リソースの推奨版」を示すものとして定義しています。要点は次のとおりです。

• 1つのリソースに対して canonical は1つだけ指定する（指針）。
• 相対IRIを指定してもよい（MAY）。ただし Google は、相対パスは長期的に問題を招きうるため推奨しないと説明しています。
• 別ホスト・別ドメインや、http から https のように別スキームのURLを指してもよい（MAY）。
• 恒久リダイレクト（300・301）を返すURL、4xx などのエラーを返すURL、さらに別の canonical を宣言しているURLを指すことは避ける（指針）。

Google は canonical をどう扱うか

Google 検索セントラルは、rel="canonical" を正規URLの「強いシグナル」と位置付けつつ、最終的な正規URLは Google が判断すると説明しています。また、HTTPS ページを同等の HTTP ページより優先して正規URLに選ぶものの、次の場合は例外になるとしています。

つまり、HTTPS で配信していても canonical が http:// を指していれば、HTTP 版が正規URLに選ばれる余地を自ら作ることになります。そのため HTTP→HTTPS リダイレクト、HTTPS の canonical、HSTS をそろえることが推奨されています。

canonicalが安全なURLを指しているかをなぜセキュリティ診断で見るのか

canonical が HTTP を指している状態は、次のような「HTTPS 移行の不完全さ」の兆候です。

1. CMS の「サイトURL」設定や共通テンプレートに http:// が残っている。
2. その結果、OGP の og:url、サイトマップ、内部リンクにも HTTP が混在している可能性が高い。
3. 検索結果や共有リンクが HTTP 版を指すと、初回アクセスが平文になり、HSTS が未設定・未記憶の利用者は中間者による改ざん（SSL ストリッピング）の影響を受けうる。

関連標準として、OWASP ASVS 5.0.0 V12.2.1 は「外部向けHTTPサービスはすべてTLSを使い、非暗号化通信へフォールバックしない」ことを求めています。canonical の HTTPS 化は、この要件と CWE-319（機密情報の平文送信）を周辺から支える対策という位置付けです。

canonical についてよくある誤解

• 「canonical は SEO の話なのでセキュリティと無関係」：直接の脆弱性ではありませんが、平文の入口を検索エンジン経由で広めてしまう点で通信保護の一貫性に関わります。そのため重みは1と小さく設定しています。
• 「相対パスなら安全」：相対パスはページ自身のスキームで解決されます。ページが HTTPS で配信されていれば HTTPS になりますが、HTTP 版でも配信されているとそのまま HTTP になります。
• 「canonical がないと減点される」：canonical は任意の要素です。存在しないことはセキュリティ上の欠陥ではありません。

なお、ページ自体が HTTPS で配信されているかは「HTTPSで配信されている」、HTTP から HTTPS への転送は「HTTPからHTTPSへ転送」、画像やスクリプトの HTTP 混在は「Mixed Contentがない」、ブラウザに HTTPS を記憶させる設定は「HSTSが設定されている」の各項目で確認します。このページは canonical の指し先に絞って解説します。

canonicalが安全なURLを指しているの診断基準（セキュリティAIチェッカー）

取得対象と方法

• 診断対象URLを GET し、リダイレクト（最大4回）を追った最終URLのHTML本文（最大2MB）を解析します。
• rel の値が canonical である <link> 要素（引用符の有無・大文字小文字を問わない）を正規表現で最初の1件だけ抽出し、その href 属性の値を取り出します。data-href のような別名の属性は対象にしません。
• href を最終URLを基準に new URL() で絶対URLへ解決し、プロトコルが https: かを判定します。

判定条件

• スコアは「Σ(重み×係数) ÷ Σ(適用項目の重み) × 100」で計算され、pass=1.00、warn=0.45、fail=0 です。この項目に「△ 要確認（warn）」はありません。
• 診断結果の根拠欄には、取り出した canonical の値（先頭160文字まで）を表示します。

自治体サイトでの判定例

診断の限界

• 取得するのはトップページ1枚のみです。下層ページのテンプレートが異なる場合は別途確認が必要です。
• HTTP レスポンスヘッダー Link: <...>; rel="canonical" は評価していません。
• rel="canonical alternate" のような複数値は抽出対象外（対象外）です。JavaScript で後から挿入される canonical も評価できません。
• 2件目以降の canonical は評価しません（RFC 6596 は1つだけ指定するよう勧めています）。

canonicalがHTTPを指しているとどんなリスクがあるか

• 平文入口の拡散：検索結果・SNS 共有・まとめサイトのリンクが HTTP 版を指すと、住民が公衆無線LANなどから平文でアクセスし、通信経路上で偽の告知や偽のフォームリンクを差し込まれる余地が生まれます。HSTS を設定していても、初回アクセスで HSTS ヘッダーを受け取るまでは保護されません（プリロード登録済みを除く）。
• 混在の兆候：canonical に HTTP が残るサイトは、画像・スクリプト・フォームの送信先にも HTTP が残っていることが多く、Mixed Content や「フォーム送信先がHTTPS」の問題の手がかりになります。
• 検索評価の分散：HTTP版とHTTPS版が別々に評価され、正しいページが検索上位に出にくくなるという運用上の不利益もあります。

具体的な被害事例として「canonical が HTTP だったことが原因の侵害」と特定された公的な報告は確認できていません。リスクは主に HTTPS 移行の不完全さを通じた間接的なものです。重みが1と小さいのはこのためですが、修正は容易で副作用も小さいため、見つけたら早めに直すことをおすすめします。

canonicalをHTTPSにする設定方法（CMS・Next.js・Apache・nginx・IIS）

1. 正規URLを HTTPS の絶対URLで書く

<link rel="canonical" href="https://www.city.example.lg.jp/kurashi/index.html">

各ページには、そのページ自身の正規URLを書きます。

2. CMS の設定を直す

• WordPress：「設定 → 一般」のWordPressアドレス・サイトアドレスを https:// に変更します。SEO プラグイン（Yoast SEO 等）は通常このサイトアドレスから canonical を生成します。DB 内の旧URLは WP-CLI の wp search-replace 'http://www.city.example.lg.jp' 'https://www.city.example.lg.jp' --dry-run で影響件数を確認してから置換します。
• 自治体向け商用CMS：テンプレート（ヘッダー部品）や「公開URL」「サイトルートURL」設定に http:// が残っていないかをベンダーに確認し、再書き出し（静的HTML生成）を行います。
• Next.js（App Router）：

// app/layout.tsx
export const metadata = {
  metadataBase: new URL("https://www.city.example.lg.jp"),
  alternates: { canonical: "/" },
};

metadataBase を HTTPS にしておけば、各ページの相対 canonical も HTTPS の絶対URLで出力されます。

3. HTTP 版へのアクセスを HTTPS へ統一する

canonical はヒントにすぎないため、サーバー側の恒久リダイレクトと組み合わせます。

Apache（.htaccess）

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteCond %{HTTPS} !=on
  RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

nginx

server {
  listen 80;
  server_name www.city.example.lg.jp;
  return 301 https://$host$request_uri;
}

IIS（web.config、URL Rewrite モジュール）

<rule name="HTTPS" stopProcessing="true">
  <match url="(.*)" />
  <conditions><add input="{HTTPS}" pattern="off" /></conditions>
  <action type="Redirect" url="https://{HTTP_HOST}/{R:1}" redirectType="Permanent" />
</rule>

4. PDF など HTML 以外の正規URL

Google は HTTP ヘッダーの Link で canonical を示す方法も案内しています（この方法は本診断の評価対象外です）。

<Files "guide.pdf">
  Header add Link "<https://www.city.example.lg.jp/files/guide.pdf>; rel=\"canonical\""
</Files>

5. 設定後の確認方法

# canonical の値を確認
curl -s https://www.city.example.lg.jp/ | grep -io '<link[^>]*canonical[^>]*>'

# HTTP版が301でHTTPSへ転送されるか
curl -sI http://www.city.example.lg.jp/ | grep -iE '^(HTTP|location)'

Google Search Console の「URL検査」で「Google が選択した正規URL」が HTTPS になっているかも確認します。修正後はセキュリティAIチェッカーで再診断し、根拠欄の canonical が https:// になっていることを確かめてください。

サイトを壊さないための注意点

• canonical をページ固有のURLではなく全ページ共通でトップページに向けてしまうと、下層ページが検索結果から消えることがあります。テンプレート修正時は「各ページ自身のURL」を出力しているか確認してください。
• canonical の先が 301 リダイレクトや 404 にならないようにします（RFC 6596 が避けるべきとする指定）。
• 1ページに canonical は1つだけにします。テーマとSEOプラグインの両方が出力して重複するケースに注意してください。
• HTTP→HTTPS リダイレクトを入れる前に、すべての下層ページ・添付ファイルが HTTPS で表示できることを確認します。

よくある質問（FAQ）

参考資料

• RFC 6596 The Canonical Link Relation
• Google 検索セントラル「rel="canonical" などを利用して正規 URL を指定する方法」
• OWASP ASVS 5.0.0 V12 Secure Communication

「canonicalが安全なURLを指している」と関連する診断項目

• HTTPSで配信されているcritical
• HTTPからHTTPSへ転送high
• Mixed Contentがないhigh
• HSTSが設定されているhigh
• フォーム送信先がHTTPScritical
• 過大な初期HTMLを配信していないlow
• Content-Typeが明示されているmedium
• ページタイトルが設定されているlow