短.beURL 正規化 (URL Normalization / URL Canonicalization) とは、同じ Web ページを指す複数の URL 表記を、1 つの標準的な形式に統一する処理です。たとえば「http://Example.COM/page/」「https://example.com/page」「https://example.com/page/index.html」はすべて同じページを指す可能性がありますが、検索エンジンはこれらを別の URL として扱います。
URL 正規化で統一すべき主な要素は、プロトコル (http → https)、ホスト名の大文字小文字 (Example.COM → example.com)、末尾のスラッシュ (有無の統一)、デフォルトポート番号の除去 (:443 や :80)、パーセントエンコーディングの統一 (%7E → ~)、不要なクエリパラメーターの除去、パスの正規化 (/a/../b → /b) です。
短縮 URL サービスにとって URL 正規化は核心的な技術です。ユーザーが入力した URL を正規化してからデータベースに保存することで、同じページに対して複数の短縮 URL が生成されるのを防げます。「https://example.com/page」と「https://example.com/page/」を別の URL として扱うと、同じページに 2 つの短縮 URL が割り当てられ、クリック統計が分散してしまいます。
逆に正規化を強くかけすぎると、別のページを同じ URL とみなす事故が起きます。とくに危ないのはクエリパラメーターの除去です。utm_source のような計測用パラメーターは消しても同じページに着きますが、?id=123 や ?page=2 のように表示内容を決めるパラメーターを消すと、まったく別のページへ転送してしまいます。「残して良いもの」を推測するより、許可リストで「消して良いパラメータ」を列挙する方が安全です。末尾スラッシュも同様で、サーバーによっては /page と /page/ が別の内容を返すことがあるため、正規化の対象は実際の応答を確かめてから決めます。
SEO の観点では、URL 正規化の不備は重複コンテンツ問題を引き起こします。同じコンテンツが複数の URL でアクセス可能な場合、検索エンジンはどの URL を正規版として扱うか判断に迷い、検索順位が分散します。canonical タグ (<link rel="canonical">) で正規版を明示するのが基本の対処です。ただし canonical は検索エンジンへのシグナルであり、必ずそのとおりに扱われるとは限りません。Google は正規化に影響する手段を影響の強い順に挙げる際、canonical タグより先にリダイレクトを置いています。1 つの URL に確実に寄せたい場合は、リダイレクトでアクセス経路自体を統一したうえで canonical を併用します。
RFC 3986「Uniform Resource Identifier (URI): Generic Syntax」は URI の構文とあわせて正規化の規定も置いています。スキームとホスト名を小文字に揃えること、パーセントエンコードされた unreserved 文字 (英数字と - . _ ~) を元の文字に戻すこと (%7E → ~)、スキームの既定ポートを省略すること、パスの ../ を解決することは、この仕様に沿った処理です。一方で、http を https に揃えるか、www を付けるか、末尾スラッシュをどちらに寄せるかは RFC が決めることではありません。これらは同じ資源を指すとは限らないため、サイト側の方針と Web サーバーの設定で決め、リダイレクトで一方に統一します。