canonical 태그: 언제 필요한지, 흔한 실수 5가지 (+ 점검 명령)

핵심 답변: canonical 태그는 페이지의 <head>에 넣는 <link rel="canonical"> 요소입니다. 같은 콘텐츠가 여러 주소로 접근될 때 Google이 대표 버전으로 취급할 주소를 알려 줍니다. 아무것도 지정하지 않으면 Google이 스스로 대표 주소를 고르므로 모든 사이트에 꼭 필요한 것은 아니지만, 중복 페이지가 생기는 순간부터는 두는 편이 좋습니다. 그리고 이것은 명령이 아니라 힌트입니다.

canonical 태그란 무엇인가요?

Google은 서로 같아 보이는 페이지를 발견하면 하나의 그룹으로 묶고 대표 주소를 하나 고릅니다. Google은 이를 canonicalization이라고 부릅니다. 대표(canonical) 페이지는 가장 규칙적으로 크롤링되고 중복 페이지는 덜 자주 크롤링되며, 검색 결과도 보통 대표 페이지를 가리킵니다. 예외는 검색하는 사람에게 더 알맞은 중복 페이지가 있는 경우입니다. 예를 들어 휴대폰으로 검색하는 사람에게 보여 주는 별도의 모바일 페이지가 그렇습니다.

canonical 태그는 내가 선호하는 주소를 알리는 방법입니다. HTML의 <head> 안에 들어갑니다.

<link rel="canonical" href="https://example.com/dresses/green-dresses">

이 콘텐츠가 나타나는 모든 주소가 이 줄을 담고, 줄마다 같은 주소를 가리킵니다. Google이 드는 이유는 네 가지입니다. 사람들에게 보이는 결과에 어떤 주소가 나올지 내가 정하고, 링크 같은 신호가 하나의 주소로 통합되고, 지표를 읽기 쉬워지고, Googlebot이 중복 페이지가 아니라 새 페이지에 시간을 쓰게 된다는 것입니다. 이 문서들에서 순위가 오른다는 약속은 찾지 못했습니다.

시작하기 전에 한 가지가 중요합니다. Google은 “indicating a canonical preference is a hint, not a rule”, 즉 canonical 선호를 알리는 것은 규칙이 아니라 힌트라고 분명히 말합니다. Google은 내가 지정한 것과 다른 페이지를 고를 수도 있습니다.

canonical 태그는 언제 필요한가요?

필요하지 않은 경우가 많습니다. Google의 대표 URL 지정 문서는 이렇게 말합니다. “none of them are required; your site will likely do just fine without specifying a canonical preference”, 즉 어떤 방법도 필수가 아니며 canonical을 지정하지 않아도 사이트는 대체로 잘 작동한다는 것입니다. 정확히 하나의 주소로만 존재하는 페이지에는 도움이 필요 없습니다.

같은 콘텐츠에 주소가 둘 이상 있다면 고민해야 합니다. Google의 목록과 예시에서 가져온 대표적인 원인은 다음과 같습니다.

• 추적 매개변수와 사이트 기능. https://example.com/dresses/cocktail?gclid=ABCD가 Google의 예시입니다. 카테고리 페이지를 정렬하고 필터링해도 같은 종류의 사본이 생깁니다.
• 프로토콜과 호스트의 변형. http와 https, www가 있는 것과 없는 것입니다. 우리의 견해로는 이 경우 리디렉션이 더 깔끔한 도구입니다.
• 기기별 변형. 별도의 주소를 쓰는 모바일 버전입니다.
• 같은 언어 안의 지역별 변형. 텍스트가 같은 미국용 페이지와 영국용 페이지입니다. canonical은 hreflang과 함께 쓰세요.
• 의도하지 않은 변형. 크롤러가 접근할 수 있는 사이트의 데모나 테스트 사본입니다.
• HTML이 아닌 파일. 페이지와 같은 내용을 담은 PDF입니다.

중복 콘텐츠 자체가 위반은 아닙니다. Google은 일부 중복은 정상이며 스팸 정책을 위반하지 않는다고 씁니다.

이 태그가 맞지 않는 경우가 하나 있는데, 신디케이션입니다. 제휴사의 페이지가 대개 크게 다르기 때문에 Google은 이 경우에 canonical 태그를 권장하지 않습니다. 가장 효과적인 해결책은 제휴사가 내 콘텐츠의 색인을 막는 것입니다.

canonical 태그는 어떻게 넣나요?

Google은 선호를 알리는 방법을 세 가지로 소개하고, 이 방법들을 겹쳐 쓸 수 있다고 말합니다. 둘 이상을 쓰면 내가 선호하는 주소가 표시될 가능성이 커집니다.

링크 요소에 대한 Google의 조언은 다음으로 요약됩니다.

• 중복 페이지마다 <head> 안에 넣고, https://가 붙은 전체 주소를 쓰세요.
• 대표 페이지 자신에게도 같은 태그를 넣으세요(아래에서 자세히 설명합니다).
• PDF처럼 HTML이 아닌 파일에는 대신 HTTP 헤더를 보내세요. Link: <https://www.example.com/downloads/white-paper.pdf>; rel="canonical" Google은 이 방식을 웹 검색 결과에 대해서만 지원합니다.
• 요소와 헤더 중 하나를 고르세요. 둘 다 쓰는 것도 가능하지만 Google은 오류가 생기기 더 쉽다고 말합니다.
• WordPress, Wix, Blogger 같은 CMS에서는 HTML을 직접 편집하지 못할 수 있습니다. CMS 안에서 검색 엔진 설정 페이지를 찾아보세요.

중복 페이지가 사라져야 한다면 리디렉션이 맞는 방법입니다.

페이지가 자기 자신을 가리켜야 하나요?

네. Google은 대표 페이지 자신에게도 rel="canonical" 링크를 두는 자기 참조 canonical을 권장합니다. 그러면 누군가 추적 매개변수가 붙은 주소 등으로 접근한 모든 버전이 같은 말을 하게 됩니다.

Google의 의견이 아니라 우리의 견해입니다. 태그의 주소는 요청받은 주소가 아니라 그 페이지의 깨끗한 주소에서 만드세요. 그렇지 않으면 매개변수가 태그에 들어갑니다. 이를 테스트하는 방법은 아래 점검 절에 나옵니다.

자주 하는 실수: canonical 태그 오류 5가지

Google은 이 오류들을 각각 canonical 관련 문서에 적어 두었습니다. 얼마나 자주 일어나는지는 우리가 측정하지 않았습니다.

실수 1: 상대 주소, 프래그먼트, 잘못된 프로토콜

전체 주소를 쓰세요. Google은 상대 경로를 지원하지만, 예를 들어 테스트 사이트가 실수로 크롤링되는 경우처럼 나중에 문제를 일으킬 수 있어서 권하지 않습니다. Google의 예시는 이렇습니다. https://www.example.com/dresses/green/green-dress.html은 좋고, /dresses/green/green-dress.html은 나쁩니다.

URL 프래그먼트(# 뒤의 부분)도 쓰지 마세요. Google은 대체로 프래그먼트를 지원하지 않기 때문입니다. 그리고 canonical이 http 버전을 가리키는 https 페이지는, Google이 http 버전을 선호하게 만들 수 있는 충돌 중 하나입니다.

실수 2: 서로 어긋나는 신호 둘

같은 페이지에 대해 서로 다른 방법으로 다른 canonical을 지정하지 마세요. 예를 들어 사이트맵에는 한 주소를, 태그에는 다른 주소를 쓰거나, 헤더에는 한 주소를, 요소에는 다른 주소를 쓰는 경우입니다. CMS나 그 플러그인이 의도하지 않은 주소를 태그에 넣을 수도 있습니다. Google은 브라우저의 개발자 도구에서 HTML을 점검해 보라고 제안합니다. 내부 링크는 중복 페이지가 아니라 대표 주소로 연결하세요.

해결책은 방법 하나, 주소 하나입니다. 태그, 사이트맵, 내부 링크가 모두 그 주소를 가리켜야 합니다.

실수 3: canonical 대신 noindex, robots.txt, 삭제 도구를 쓰는 것

Google은 canonical 지정에 쓰지 말아야 할 것 세 가지를 꼽습니다. 첫째는 robots.txt입니다. Google이 “may still index URLs that are disallowed in robots.txt without their content”, 즉 robots.txt로 막은 URL도 콘텐츠 없이 색인할 수 있기 때문입니다. 둘째는 URL 삭제 도구로, URL의 모든 버전을 검색에서 숨깁니다. 셋째는 noindex로, 페이지를 검색에서 완전히 차단하게 됩니다.

noindex가 있으면서 다른 주소를 canonical로 지정한 페이지는 정반대의 메시지를 두 개 보내는 셈입니다. 우리 점검의 조언은 이렇습니다. 페이지가 사라져야 한다면 noindex를 두고 canonical을 지우세요. 다른 페이지에 합산되어야 한다면 noindex를 지우고 canonical을 두세요.

실수 4: Google이 읽을 수 없는 태그, 또는 이를 바꿔 버리는 JavaScript

Google은 링크 요소를 <head> 영역 안에서만 받아들이므로, 적어도 그 영역은 올바른 HTML이어야 합니다. Google의 JavaScript SEO 문서는 가장 좋은 방법은 HTML에서 canonical을 설정하고 JavaScript가 이를 바꾸지 않게 하는 것이라고 말합니다. 그럴 수 없다면 HTML에서는 빼고 JavaScript로만 설정하세요. HTML에는 한 주소를, 스크립트에는 다른 주소를 적는 일은 절대 하지 마세요.

실수 5: 중복이 아닌 페이지를 태그가 가리키는 것

이 태그는 중복되거나 매우 비슷한 페이지를 위한 것입니다. 번역된 버전은 본문이 다른 언어이면 중복이 아니며, hreflang을 쓸 때 Google은 canonical이 같은 언어의 페이지, 그것이 어렵다면 가능한 한 가장 가까운 대체 페이지를 가리키기를 원합니다. 모든 언어 버전이 영어 페이지를 가리키는 사이트는 이 조언에 어긋납니다.

해결책은 각 언어 버전이 자기 자신을 가리키고, 버전들이 hreflang으로 서로를 가리키게 하는 것입니다.

Google이 내가 지정한 것과 다른 canonical을 고르면: 해야 할 일

이 태그는 힌트이므로 Google이 다른 주소를 고르기도 합니다. 그러면 Search Console이 “Duplicate, Google chose different canonical than user”라고 보고합니다(영어 화면에서의 상태 이름이며 URL 검사 도움말에 나옵니다). Google의 문제 해결 문서는 다음 단계를 제안합니다.

• Google이 무엇을 골랐는지 확인하세요. URL 검사 도구에서 그 URL의 색인된 버전을 열어 “User-declared canonical” 옆에 있는 “Google-selected canonical”을 읽으세요(영어 화면의 항목 이름). 라이브 테스트로는 이를 예측할 수 없습니다.
• Google의 선택이 맞는지 따져 보세요. 검색에서 오는 방문자에게 Google의 선택이 내 선택보다 나은가요?
• 기술적 원인을 찾으세요. Google의 목록은 이렇습니다. hreflang이 없는 언어 변형, 잘못된 canonical을 지정하는 CMS나 플러그인, 잘못 설정된 서버, 해킹 뒤에 삽입된 리디렉션이나 다른 도메인을 가리키는 canonical, 신디케이션된 콘텐츠, 내 사이트를 베낀 사이트입니다.
• 하나여서는 안 되는 페이지라면 정말로 다르게 만드세요. Google은 수정한 뒤에도 최대 2주 동안 페이지를 중복 클러스터에 둘 수 있고, “Request Indexing”은 할당량으로 제한되므로 중요한 URL에 아껴 쓰세요.

canonical 태그는 어떻게 점검하나요?

브라우저에서 페이지 소스를 열어 rel="canonical"을 검색하거나 터미널을 쓰세요. 두 번째 명령은 HTTP 헤더로 보낸 canonical도 보여 줍니다. 세 번째 방법은 Search Console의 URL 검사로, Google이 선택한 것을 보여 줍니다.

curl -sS https://example.com/page | grep -i 'rel="canonical"'
curl -sSI https://example.com/page | grep -i '^link'

seogrinder.com에서는 이렇게 보입니다. 2026년 11월 4일에 첫 번째 명령을 주소 세 곳에 실행했습니다. 홈페이지는 <link rel="canonical" href="https://seogrinder.com/">를 반환했고, ?utm_source=test를 붙여 요청한 같은 페이지도 같은 결과였습니다. 소프트 404 오류 글은 자기 자신의 주소를 반환했습니다. 그 글의 영어판도 자기 영어 주소를 canonical로 쓰고, 두 버전은 hreflang으로 서로를 나열합니다. 홈페이지의 Markdown 버전은 HTML head가 없으므로 canonical이 HTTP 헤더에 있습니다. Link: <https://seogrinder.com/>; rel="canonical"

SEOgrinder의 무료 스캔은 입력한 페이지의 태그를 점검합니다. 「Google에서의 페이지」 탭의 「Canonical」 카드는 발견한 주소와 그것이 「자기 자신을 가리킴」인지 「다른 곳을 가리킴」인지를 보여 줍니다. 할 일 목록에는 「canonical 태그가 없습니다」, 「canonical이 다른 주소를 가리킵니다」, 「canonical이 접근할 수 없는 페이지를 가리킵니다」, 「noindex와 canonical이 서로 어긋납니다」, 그리고 서로 다른 canonical 태그가 여러 개일 때의 발견 항목이 나올 수 있습니다. 한계는 두 가지입니다. 이 테스트는 HTTP 헤더의 canonical을 감지하지 못합니다. 그리고 「Google이 다른 주소를 canonical로 선택합니다」는 Search Console 연결이 필요한데, 이 연결은 로컬 설치에만 있습니다. seogrinder.com에서는 Google의 선택을 Search Console에서 직접 읽으세요.

자주 묻는 질문

모든 페이지에 canonical 태그가 필요한가요?

아니요. Google은 어떤 방법도 필수가 아니라고 말합니다. 다만 대표 페이지 자신에 자기 참조 태그를 두는 것은 권장합니다.

canonical 태그와 301 리디렉션 중 무엇을 써야 하나요?

중복 페이지가 사라져야 한다면 리디렉션입니다. 방문자도 함께 이동시키기 때문입니다. 추적 매개변수가 붙은 버전처럼 중복 페이지가 접근 가능한 채로 남아야 한다면 canonical 태그입니다. Google은 이 방법들을 함께 쓸 수 있다고 말합니다.

중복 콘텐츠는 페널티를 받나요?

Google은 일부 중복 콘텐츠는 정상이며 스팸 정책 위반이 아니라고 말합니다. Google이 드는 비용은 방문자의 혼란과 추적의 어려움입니다.

canonical 태그는 noindex와 같은가요?

아니요. noindex는 페이지를 검색에서 완전히 뺍니다. canonical 태그는 비슷한 여러 페이지 중 어느 것을 선호하는지만 알리고, 결정은 Google이 합니다.

다음 단계

홈페이지와 가장 중요한 페이지의 소스를 열어 세 가지를 확인하세요. 태그가 <head> 안에 있는지, 주소가 전체 주소인지, 페이지가 자기 자신을 가리키는지입니다. 그런 다음 SEOgrinder로 무료 스캔을 실행해 「Google에서의 페이지」 탭의 「Canonical」 카드를 보고, 수정할 때마다 「다시 확인」을 눌러 새 결과를 확인하세요.

함께 읽어 보세요

• hreflang 설정: 12개 언어 구성 사례와 흔한 오류 5가지
• 301 리디렉션 vs 302: 무엇을 쓸지, Google은 몇 번까지 따라가는지