[要約] RFC 6596は、ウェブページの正規URLを示すための「canonical」リンク関係を定義しています。目的は、検索エンジンに対して重複コンテンツを避けるために、正規URLを明示的に指定することです。
Internet Engineering Task Force (IETF) M. Ohye
Request for Comments: 6596 J. Kupke
Category: Informational April 2012
ISSN: 2070-1721
The Canonical Link Relation
正規リンク関係
Abstract
概要
RFC 5988 specifies a way to define relationships between links on the web. This document describes a new type of such a relationship, "canonical", to designate an Internationalized Resource Identifier (IRI) as preferred over resources with duplicative content.
RFC 5988は、Web上のリンク間の関係を定義する方法を規定しています。このドキュメントでは、このような関係の新しいタイプである「正規」について説明し、国際化リソース識別子（IRI）を重複コンテンツを持つリソースよりも優先するものとして指定します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6596.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6596で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
The canonical link relation specifies the preferred IRI from resources with duplicative content. Common implementations of the canonical link relation are to specify the preferred version of an IRI from duplicate pages created with the addition of IRI parameters (e.g., session IDs) or to specify the single-page version as preferred over the same content separated on multiple component pages.
正規リンク関係は、重複するコンテンツを持つリソースからの優先IRIを指定します。正規リンク関係の一般的な実装は、IRIパラメータ（たとえば、セッションID）を追加して作成された重複ページからIRIの優先バージョンを指定するか、複数のコンポーネントで区切られた同じコンテンツよりも単一ページバージョンを優先として指定することです。ページ。
In regard to the link relation type, "canonical" can be described informally as the author's preferred version of a resource. More formally, the canonical link relation specifies the preferred IRI from a set of resources that return the context IRI's content in duplicated form. Once specified, applications such as search engines can focus processing on the canonical, and references to the context (referring) IRI can be updated to reference the target (canonical) IRI.
リンク関係タイプに関して、「標準」は、リソースの作成者の優先バージョンとして非公式に説明できます。より正式には、正規リンク関係は、複製された形式でコンテキストIRIのコンテンツを返すリソースのセットから優先IRIを指定します。指定すると、検索エンジンなどのアプリケーションは正規の処理に集中でき、コンテキスト（参照）IRIへの参照を更新して、ターゲット（正規）IRIを参照できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The target (canonical) IRI MUST identify content that is either duplicative or a superset of the content at the context (referring) IRI. Authors who declare the canonical link relation ought to anticipate that applications such as search engines can:
ターゲット（正規）IRIは、IRIのコンテキスト（参照）でコンテンツの複製またはスーパーセットのいずれかであるコンテンツを識別しなければなりません（MUST）。正規リンク関係を宣言する作成者は、検索エンジンなどのアプリケーションで次のことができることを期待する必要があります。
o Index content only from the target IRI (i.e., content from the context IRIs will be likely disregarded as duplicative).
o ターゲットIRIのコンテンツのみにインデックスを付けます（つまり、コンテキストIRIのコンテンツは重複していると見なされる可能性があります）。
o Consolidate IRI properties, such as link popularity, to the target IRI.
o リンクの人気度などのIRIプロパティをターゲットIRIに統合します。
o Display the target IRI as the representative IRI.
o ターゲットIRIを代表IRIとして表示します。
The target (canonical) IRI MAY:
ターゲット（正規）IRIは次の場合があります。
o Specify a relative IRI (see [RFC3986], Section 4.2).
o 相対IRIを指定します（[RFC3986]、セクション4.2を参照）。
o Be self-referential (context IRI identical to target IRI).
o 自己参照的である（コンテキストIRIはターゲットIRIと同一）。
o Exist on a different hostname or domain.
o 別のホスト名またはドメインに存在します。
o Have different scheme names, such as "http" to "https" or "gopher" to "ftp".
o 「http」から「https」または「gopher」から「ftp」など、異なるスキーム名を使用します。
o Be a superset of the content at the context IRI.
o コンテキストIRIでコンテンツのスーパーセットになります。
* As an example, each component page (e.g., page-1.html, page-2.html) of a multi-page article MAY specify the "view-all" version (e.g., page-all.html), the superset of their content, as the target IRI. This is because the content from each component page is contained within the view-all version. Given this implementation, applications can mark page-1.html and page-2.html as duplicates of page-all.html, process content only from page-all.html, and disregard the component pages. All references can then be made to the view-all version (page-all.html, the target IRI), and no content will have been lost in this process.
* 例として、マルチページ記事の各コンポーネントページ（たとえば、page-1.html、page-2.html）は、「view-all」バージョン（たとえば、page-all.html）のスーパーセットを指定できます（MAY）。ターゲットIRIとしてのコンテンツ。これは、各コンポーネントページのコンテンツがすべて表示バージョンに含まれているためです。この実装により、アプリケーションはpage-1.htmlとpage-2.htmlをpage-all.htmlの複製としてマークし、page-all.htmlからのみコンテンツを処理し、コンポーネントページを無視できます。次に、すべて表示バージョン（page-all.html、ターゲットIRI）へのすべての参照を行うことができ、このプロセスでコンテンツが失われることはありません。
* Using the same example above, page-2.html SHOULD NOT designate page-1.html as the target (canonical) IRI because this may cause a loss of data. When page-2.html designates page-1.html as the canonical, only content from the target IRI, page-1.html, will be processed. page-2.html may be marked as a duplicate of page-1.html and its content disregarded.
* 上記と同じ例を使用すると、page-2.htmlはpage-1.htmlをターゲット（正規）IRIとして指定しないでください。これにより、データが失われる可能性があります。 page-2.htmlがpage-1.htmlを正規として指定すると、ターゲットIRI、page-1.htmlからのコンテンツのみが処理されます。 page-2.htmlは、page-1.htmlの複製としてマークされ、そのコンテンツは無視されます。
o Be the source IRI of a temporary redirect. For HTTP, this refers to status codes 302, 303, or 307 (Sections 10.3.3, 10.3.4, and 10.3.8, respectively, of [RFC2616]).
o 一時的なリダイレクトのソースIRIになります。 HTTPの場合、これはステータスコード302、303、または307を指します（[RFC2616]のセクション10.3.3、10.3.4、および10.3.8のそれぞれ）。
To better ensure that applications properly handle the canonical link relation, administrators ought to consider the following guidelines:
アプリケーションが正規リンク関係を適切に処理することをより確実にするために、管理者は次のガイドラインを考慮する必要があります。
o Specify only one canonical link relation for a resource. (It would be confusing to consider/label/designate more than one IRI as authoritative.)
o リソースの正規リンク関係を1つだけ指定します。 （1つ以上のIRIを信頼できるものとして検討/ラベル付け/指定することは混乱を招くでしょう。）
o Avoid designating the target (canonical) as:
o ターゲット（正規）を次のように指定しないでください。
* The source IRI of a permanent redirect (for HTTP, this refers to 300 and 301 response codes, defined in Sections 10.3.1 and 10.3.2 of [RFC2616]).
* 永続的なリダイレクトのソースIRI（HTTPの場合、これは[RFC2616]のセクション10.3.1および10.3.2で定義されている300および301応答コードを指します）。
* An IRI that also specifies a canonical link relation to an IRI other than itself.
* 自分自身以外のIRIへの正規リンク関係も指定するIRI。
* An IRI that returns an error code, such as a 4xx response in HTTP (Section 10.4 of [RFC2616]).
* HTTPの4xx応答などのエラーコードを返すIRI（[RFC2616]のセクション10.4）。
* The first page of a multi-page article or multi-page listing of items (since the first page is not duplicative or a superset of the context IRI). For example, page-2.html and page-3.html of an article SHOULD NOT specify page-1.html as the canonical. This may cause a loss of data from page-2.html and page-3.html as they will be marked duplicative of page-1.html with only content from page-1.html being processed.
* 複数ページの記事の最初のページまたはアイテムの複数ページのリスト（最初のページは重複していないか、コンテキストIRIのスーパーセットではないため）。たとえば、記事のpage-2.htmlとpage-3.htmlは、page-1.htmlを正規として指定すべきではありません（SHOULD NOT）。これにより、page-1.htmlのコンテンツのみが処理され、page-1.htmlの複製としてマークされるため、page-2.htmlとpage-3.htmlのデータが失われる可能性があります。
When the canonical link relation is declared improperly, such as creating chained canonicals (i.e., target IRI specifies the source IRI of a permanent redirect) or designating a target IRI that returns a 4xx response, applications can use their own heuristics when processing the resource. For instance, an application can choose to ignore any improper canonical designation and continue to process the remaining content on a page.
連鎖リンクの作成（つまり、ターゲットIRIが永続的なリダイレクトのソースIRIを指定する）や、4xx応答を返すターゲットIRIを指定するなど、正規リンク関係が不適切に宣言されている場合、アプリケーションはリソースを処理するときに独自のヒューリスティックを使用できます。たとえば、アプリケーションは、不適切な正規の指定を無視して、ページの残りのコンテンツの処理を続行することを選択できます。
The following example illustrates:
次の例で説明します。
o Three IRIs that serve duplicate content.
o 重複するコンテンツを提供する3つのIRI。
o One IRI that is the canonical or "preferred version".
o 正規または「推奨バージョン」である1つのIRI。
o Two IRIs with additional query parameters, making them the non-preferred version of the content (duplicates). The canonical link relation is therefore specified on these duplicates.
o 追加のクエリパラメータを持つ2つのIRIにより、コンテンツの非優先バージョン（重複）になります。したがって、正規リンク関係はこれらの複製で指定されます。
If the preferred version of a IRI and its content exists at:
IRIの優先バージョンとそのコンテンツが次の場所にある場合：
http://www.example.com/page.php?item=purse
Then duplicate content IRIs such as:
次に、次のようなコンテンツIRIを複製します。
http://www.example.com/page.php?item=purse&category=bags
http://www.example.com/page.php?item=purse&category=bags&sid=1234
may designate the canonical link relation in HTML as specified in [REC-html401-19991224]:
[REC-html401-19991224]で指定されているように、正規リンク関係をHTMLで指定できます。
<link rel="canonical"
href="http://www.example.com/page.php?item=purse">
or as a relative IRI:
または相対IRIとして：
<link rel="canonical" href="page.php?item=purse"> or alternatively, in the HTTP header field as specified in Section 5 of [RFC5988]:
<link rel = "canonical" href = "page.php？item = purse">または、[RFC5988]のセクション5で指定されているHTTPヘッダーフィールド：
Link: <http://www.example.com/page.php?item=purse>; rel="canonical"
This signals to applications, such as search engines, that these are duplicates of the target (canonical) IRI:
これは、検索エンジンなどのアプリケーションに、これらがターゲット（正規）IRIの複製であることを通知します。
http://www.example.com/page.php?item=purse.
ｈっｔｐ：／／ｗっｗ。えぁｍｐぇ。こｍ／ぱげ。ｐｈｐ？いてｍ＝ぷｒせ。
Applications may then select the canonical value as the display IRI (such as in search results), and additional IRI properties such as indexing and ranking signals can be transferred as well.
次に、アプリケーションは表示値IRI（検索結果など）として正規値を選択でき、インデックス付けやランキング信号などの追加のIRIプロパティも転送できます。
Before adding the canonical link relation, verification of the following is RECOMMENDED:
正規リンク関係を追加する前に、以下の検証をお勧めします。
1. The content of the context IRI is duplicated within the content of the target (canonical) IRI.
1. コンテキストIRIのコンテンツは、ターゲット（正規）IRIのコンテンツ内で複製されます。
2. For HTTP, permanent HTTP redirects (Section 10.3.2 of [RFC2616]), the traditional strong indicator that a IRI's content has been permanently moved, could not be implemented in place of the canonical link relation.
2. HTTPの場合、永続的なHTTPリダイレクト（[RFC2616]のセクション10.3.2）は、IRIのコンテンツが永続的に移動されたことを示す従来の強力なインジケーターであり、正規のリンク関係の代わりに実装できませんでした。
3. In the case where the target (canonical) IRI is a superset of content from the context IRI (i.e., the case where page-1.html and page-2.html designate page-all.html as the canonical), that the user experience is strongly taken into consideration, both in regard to possible increased load time and potential complexity in navigation.
3. ターゲット（正規）IRIがコンテキストIRIのコンテンツのスーパーセットである場合（つまり、page-1.htmlおよびpage-2.htmlがpage-all.htmlを正規として指定する場合）、ユーザーロード時間の増加とナビゲーションの潜在的な複雑さの両方に関して、経験が強く考慮されます。
IANA has registered the Canonical Link Relation below as per [RFC5988].
IANAは、[RFC5988]に従って、以下のCanonical Link Relationを登録しています。
Relation Name:
リレーション名：
canonical
正規の
Description:
説明：
Designates the preferred version of a resource (the IRI and its contents).
リソースの優先バージョン（IRIとそのコンテンツ）を指定します。
Reference:
参照：
This specification.
この仕様。
Notes:
ノート：
None.
なし。
Application Data:
アプリケーションデータ：
None.
なし。
When a site is compromised, the canonical link relation can be implemented with malicious intent to designate the attacker's IRI as the preferred version of the content. While this technique is largely unnoticeable to humans, automated programs may cluster the compromised resource as duplicative of the attacker's target IRI, transferring properties such as link popularity away from the compromised resource to the attacker's designated canonical. (Naturally, even a site that is not compromised could provide inaccurate or misleading information about which URI is canonical.)
サイトが侵害された場合、悪意を持って正規のリンク関係が実装され、攻撃者のIRIがコンテンツの優先バージョンとして指定される可能性があります。この手法は人間にはほとんど気づかれませんが、自動化されたプログラムは、攻撃されたリソースを攻撃者のターゲットIRIの複製としてクラスター化し、リンクの人気などのプロパティを攻撃されたリソースから攻撃者の指定された正規に転送します。 （当然ながら、侵害されていないサイトでも、どのURIが正規であるかについて不正確または誤解を招く情報を提供する可能性があります。）
Internationalization considerations for link relations are provided in Section 8 of [RFC5988].
リンク関係の国際化に関する考慮事項は、[RFC5988]のセクション8に記載されています。
[REC-html401-19991224] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 Specification", W3C Recommendation REC-html401-19991224, December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>.
[REC-html401-19991224] Raggett、D.、Le Hors、A。、およびI. Jacobs、「HTML 4.01仕様」、W3C勧告REC-html401-19991224、1999年12月、<http://www.w3.org / TR / 1999 / REC-html401-19991224>。
Latest version available at <http://www.w3.org/TR/html401>.
<http://www.w3.org/TR/html401>で入手可能な最新バージョン。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC5988]ノッティンガム、M。、「Webリンク」、RFC 5988、2010年10月。
Automated programs that implement functionality with regard for the canonical link relation include:
正規リンク関係に関する機能を実装する自動化プログラムには、次のものがあります。
o Google, canonical link relation HTML and HTTP header support, within the same domain and across domains:
o Google、正規リンク関係のHTMLおよびHTTPヘッダーのサポート、同じドメイン内およびドメイン間：
* <http://googlewebmastercentral.blogspot.com/2009/02/
specify-your-canonical.html>
* <http://googlewebmastercentral.blogspot.com/2011/06/
supporting-relcanonical-http-headers.html>
* <http://googlewebmastercentral.blogspot.com/2009/12/
handling-legitimate-cross-domain.html>
o Yahoo, canonical link relation HTML support within the same domain:
o Yahoo、同じドメイン内の正規リンク関係HTMLサポート：
* <http://www.ysearchblog.com/2009/02/12/
fighting-duplication-adding-more-arrows-to-your-quiver/>
o Bing, canonical link relation HTML support within the same domain:
o 同じドメイン内のBing、正規リンク関係HTMLサポート：
* <http://www.bing.com/community/site_blogs/b/webmaster/archive/
2009/02/12/
partnering-to-help-solve-duplicate-content-issues.aspx>
Authors' Addresses
著者のアドレス
Maile Ohye
Ohyeメール
EMail: maileohye@gmail.com
URI: http://maileohye.com/
Joachim Kupke
ヨアヒム浴場
EMail: joachim@kupke.za.net