본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.
canonical 링크 기준 정리
rel="canonical"은 중복되거나 매우 유사한 URL 집합에서 어떤 URL을 대표본으로 볼지 알려 주는 신호다. 2026년 7월 5일 확인 기준으로 RFC 6596과 Google Search Central 문서를 보면, canonical은 중복 콘텐츠 정리와 검색 신호 통합에 유용하지만 항상 강제 명령처럼 동작하는 것은 아니다.
실무에서 중요한 질문은 네 가지다. 언제 canonical을 써야 하는지, HTML <link>와 HTTP 헤더 중 무엇을 고를지, 리디렉션이나 sitemap과 어떤 차이가 있는지, 그리고 크롤러가 canonical을 어디까지 믿어야 하는지다. 이 글은 공식 문서에 나온 범위 안에서만 선택 기준을 정리한다.
canonical 링크는 무엇을 뜻할까?
RFC 6596은 canonical link relation을 중복 콘텐츠 집합에서 선호하는 IRI를 지정하는 방법으로 설명한다. 예를 들어 같은 상품 페이지가 추적 파라미터나 정렬 파라미터 때문에 여러 URL로 열리더라도, 그중 대표 URL 하나를 canonical로 둘 수 있다.
이 문서에서 중요한 기준은 target canonical URL이 원본 페이지와 중복되거나 그보다 더 큰 내용을 포함해야 한다는 점이다. 즉 내용이 일부만 겹치거나, 오히려 정보가 줄어드는 페이지를 canonical 대상으로 삼으면 안 된다.
왜 canonical을 지정할까?
Google 문서는 canonical을 지정하는 이유로 검색 결과에 보여 줄 URL 통일, 중복 URL에 흩어진 신호 통합, 측정 지표 단순화, 중복 페이지 크롤링 시간 절감을 든다. 특히 같은 콘텐츠가 여러 URL로 노출되는 쇼핑몰, 문서 사이트, 필터 페이지에서 유용하다.
반대로 canonical이 없다고 해서 반드시 문제가 생기는 것은 아니다. Google은 canonical을 명시하지 않아도 자체적으로 대표 URL을 고를 수 있다고 설명한다. 따라서 canonical은 "필수 설정"이라기보다, 중복 URL 구조가 분명할 때 정확도를 높이는 명시적 신호에 가깝다.
어떤 URL을 canonical로 잡아야 할까?
가장 안전한 기준은 사용자가 실제로 공유하고 검색 결과에서 보게 하려는 URL 하나를 정하는 것이다. RFC 6596은 canonical 대상이 중복 콘텐츠이거나 상위 집합이어야 한다고 설명하고, Google도 검색 결과에 보여 주고 싶은 URL을 기준으로 canonical을 고르라고 안내한다.
- 추적 파라미터만 다른 URL은 정규 URL 하나로 모은다.
- HTTP와 HTTPS가 함께 열리면 보통 HTTPS 쪽을 canonical 후보로 둔다.
- 페이지 나뉜 문서를 전체 보기 한 장으로 제공한다면, 전체 보기 페이지가 각 분할 페이지의 상위 집합일 때만 canonical 후보가 될 수 있다.
- 언어가 다른 페이지끼리는 같은 언어 안에서 canonical을 정하고, 다국어 연결은
hreflang으로 분리한다.
특히 여러 페이지로 나뉜 글에서 2페이지나 3페이지가 1페이지를 canonical로 가리키는 방식은 피해야 한다. RFC 6596은 이런 구성이 내용 손실을 만들 수 있다고 명시한다.
HTML canonical과 HTTP 헤더 canonical은 무엇이 다를까?
Google은 두 가지 명시적 canonical 방법을 지원한다. 하나는 HTML <head> 안의 <link rel="canonical" href="...">이고, 다른 하나는 HTTP 응답의 Link 헤더다.
- HTML
<link>: 일반 HTML 문서에서 가장 흔하다. - HTTP
Link헤더: PDF 같은 비HTML 문서에도 쓸 수 있다.
Google 문서는 두 방식을 동시에 써도 되지만, 서로 다른 URL을 넣을 위험이 있어서 하나를 정해 일관되게 쓰는 편이 더 낫다고 권장한다. HTML 방식은 반드시 <head> 안에 있어야 하며, Google은 상대 경로도 해석할 수 있지만 절대 URL 사용을 권장한다.
canonical과 redirect, sitemap은 어떻게 다를까?
Google 문서는 canonicalization 방법을 비교하면서 permanent redirect, rel="canonical", sitemap을 함께 설명한다. 이 셋은 목적이 비슷해 보여도 쓰는 상황이 다르다.
- redirect: 기존 중복 URL을 더 이상 직접 노출하지 않을 때 적합하다.
rel="canonical": 사용자는 여러 URL에 접근할 수 있지만, 대표 URL을 알려 주고 싶을 때 적합하다.- sitemap: canonical 후보를 대량으로 제시하는 보조 신호로 유용하다.
Google 문서에 따르면 sitemap은 구현과 유지가 쉽지만, rel="canonical"보다 약한 신호다. 또한 redirect는 중복 페이지를 사실상 정리하는 방법이고, canonical은 여러 URL을 그대로 두면서 대표 URL을 선언하는 방법이라는 점이 다르다.
잘못된 canonical은 왜 문제가 될까?
RFC 6596은 canonical 대상이 4xx 오류를 반환하거나, 다른 URL로 다시 canonical을 거는 체인 구조이거나, permanent redirect의 출발점인 URL인 경우를 피하라고 권고한다. 이런 상황에서는 애플리케이션이 canonical을 무시하고 자체 판단을 사용할 수 있다.
Google도 비슷하게 같은 페이지에 서로 다른 canonical 신호를 섞지 말라고 안내한다. 예를 들어 sitemap에는 A URL을 적고 HTML canonical에는 B URL을 넣으면 해석이 모호해진다. 또한 robots.txt나 noindex는 canonical 대체 수단으로 쓰지 말라고 명시한다.
크롤러나 수집기는 canonical을 어떻게 해석하면 좋을까?
검색엔진이 아닌 일반 크롤러를 만든다면 canonical을 절대 진실처럼 믿기보다는, 중복 후보 정리용 힌트로 다루는 편이 안전하다. RFC 6596 자체도 잘못 선언된 canonical이 있을 수 있음을 전제한다.
- 대표 URL 저장 키를 정할 때 canonical을 우선 참고한다.
- 하지만 본문 유사도, HTTP 상태 코드, 리디렉션 결과도 함께 확인한다.
- canonical 대상이 404이거나 내용이 더 적다면 그대로 병합하지 않는다.
- HTML 문서는
<head>의 canonical을, 비HTML은 HTTPLink헤더를 함께 확인한다.
이 접근은 검색엔진의 내부 알고리즘을 흉내 내자는 뜻이 아니라, 공식 문서가 전제하는 실패 가능성을 수집 파이프라인에도 반영하자는 의미다.
실무 체크리스트
- 대표 URL이 실제로 중복 페이지의 내용과 같거나 더 큰 범위인지 먼저 확인한다.
- HTML 문서는
<head>안에 canonical을 넣고 절대 URL을 사용한다. - PDF 같은 비HTML 문서는 HTTP
Link헤더 canonical을 검토한다. - redirect, sitemap, 내부 링크가 서로 다른 대표 URL을 가리키지 않게 맞춘다.
robots.txt,noindex, URL fragment를 canonical 대체 수단으로 쓰지 않는다.
FAQ
Q. canonical을 넣으면 반드시 그 URL이 검색 결과 대표본이 될까?
항상 그렇다고 단정할 수는 없다. Google 문서는 canonical 신호를 종합해 대표 URL을 선택하며, 명시하지 않아도 자체적으로 대표 URL을 고를 수 있다고 설명한다.
Q. HTML canonical과 HTTP 헤더 canonical을 같이 써도 될까?
지원되기는 하지만, Google은 두 방식을 함께 쓸 때 서로 다른 URL을 넣는 실수가 더 발생하기 쉽다고 설명한다. 특별한 이유가 없다면 한 가지 방식을 일관되게 유지하는 편이 안전하다.
Q. 모든 중복 URL을 redirect로 바꾸는 편이 더 좋을까?
중복 URL을 실제로 없앨 계획이라면 redirect가 더 직접적일 수 있다. 하지만 여러 진입 URL을 계속 제공해야 한다면 canonical이 더 맞는 선택이다. 두 방법은 대체 관계라기보다 운영 목적이 다르다.
정리
rel="canonical"은 중복 URL 집합에서 대표 URL을 알리는 명시적 신호다. 2026년 7월 5일 확인 기준으로 RFC 6596은 canonical 대상을 중복 또는 상위 집합 콘텐츠로 제한하고, Google 문서는 HTML <link>와 HTTP Link 헤더를 모두 지원하되 절대 URL과 일관된 신호 구성을 권장한다. 운영 기준으로는 redirect가 필요한 상황과 canonical이 필요한 상황을 분리하고, 크롤러에서는 canonical을 힌트로 해석하는 구성이 가장 무난하다.
참고 자료
'시리즈물 > 데이터 수집을 위한 크롤링' 카테고리의 다른 글
| X-Robots-Tag 헤더 기준 정리 (0) | 2026.07.21 |
|---|---|
| 404와 410 상태 코드 기준 정리 (0) | 2026.07.14 |
| [크롤링] 데이터 수집을 위한 크롤링 11편 : RSS와 Atom 피드 사용법 (0) | 2026.06.24 |
| [크롤링] 데이터 수집을 위한 크롤링 10편 : Sitemap XML과 sitemap index 사용법 (0) | 2026.06.11 |
| [크롤링] 데이터 수집을 위한 크롤링 9편 : Last-Modified와 If-Modified-Since 사용법 (0) | 2026.05.22 |