요약

  • Google은 2009년 2월 rel="canonical"을 도입해 사이트가 중복 페이지 중 검색 결과에 쓰이길 원하는 주소를 밝히게 했다. 발표 당시부터 이를 다른 신호와 함께 평가하는 강한 힌트라고 설명했다. 제안권은 발행자에게, 선택권은 검색 색인에 있었다.
  • 2012년 RFC 6596은 잘못된 지정의 대가를 적었다. 긴 글의 2쪽이 1쪽을 정본으로 가리키면 2쪽에만 있는 문장이 중복 취급을 받아 검색 처리에서 빠질 수 있다.

같은 상품에 붙은 여러 주소표

상품 하나에 기본 URL, 분류 매개변수가 붙은 URL, 광고 추적 주소, 세션 번호가 붙은 주소가 생긴다. 구매자에게는 같은 상품이지만 크롤러에는 별도의 페이지들이다. Google은 2009년 2월 12일 발표에서 중복 페이지의 HTML <head>에 <link rel="canonical" href="...">을 넣어 사이트가 선호하는 대표 주소를 밝히도록 했다.

이 코드는 방문자를 이동시키는 리디렉션이 아니다. 검색 색인을 향한 요청이다. Google은 링크 평가 등의 신호를 선호 URL에 모아 결과에 그 주소를 보일 수 있다고 설명했다. 명령이냐는 질문에는 다른 신호와 함께 고려하는 강한 힌트라고 답했다. 사이트는 자신이 만든 주소들을 알지만, 검색 서비스는 크롤링 기록과 링크 및 중복 묶음을 갖고 있다. 사이트가 후보를 적어 내고 검색 서비스가 대표를 골랐다.

발표문에 남은 수정 날짜는 기능의 범위를 구분해 준다. 처음에는 하위 도메인 사이의 지정은 허용했으나 완전히 다른 도메인 사이에서는 허용하지 않는다고 설명했고, 도메인 이전에는 영구 리디렉션을 권했다. 2009년 12월 17일 덧붙인 수정에서 도메인 간 canonical 지원을 발표했다. 나중에 넓어진 적용 범위를 2월의 출시 기능으로 소급하면 역사가 흐려진다.

첫 쪽은 둘째 쪽의 내용까지 품지 못한다

2012년 4월의 RFC 6596은 canonical을 중복 내용 또는 원본의 내용을 모두 포함하는 대상에 붙이는 선호 관계로 정의했다. HTML 요소뿐 아니라 HTTP Link 헤더에도 담을 수 있다. 이를 읽는 프로그램은 대상만 처리하고 링크 신호를 합치며 대상 주소를 표시할 수 있다. RFC가 관계의 뜻을 정했어도 모든 검색 서비스의 개별 판단을 대신하지는 않았다.

RFC의 다쪽 기사 사례가 핵심이다. 1쪽과 2쪽에는 각각 다른 문단이 있고, 전체 보기에는 두 쪽 모두 담겨 있다. 각 쪽이 전체 보기를 가리키면 대상이 원문의 내용을 포함한다. 하지만 2쪽이 1쪽을 정본이라고 가리키면 1쪽에 없는 문단까지 같다고 주장하는 셈이다. RFC는 2쪽이 중복으로 분류돼 그 문장이 처리되지 않을 수 있다고 경고했다. 독자는 브라우저로 2쪽을 열 수 있어도 검색 색인에서는 글의 한가운데가 사라질 수 있다.

RFC는 자원마다 canonical을 하나만 지정하고, 오류를 반환하거나 영구 이동하거나 다시 다른 정본을 가리키는 대상을 피하라고 권한다. 잘못된 지시를 받은 프로그램은 이를 무시하고 자체 판단을 쓸 수 있다. Google의 현재 설명 역시 여러 신호로 대표 페이지를 고르며 사이트의 선호와 다른 URL을 선택할 수 있다고 밝힌다. 현재 문서는 현재의 운영을 설명한다. 권한의 경계 자체는 2009년의 ‘힌트’라는 답변에 이미 있었다.