캐노니컬 태그

무엇을 모아 주고, 무엇은 제안에 그치는가

중복 URL은 일부러 만들어지는 경우가 거의 없습니다. 같은 상품이 두 카테고리에 걸리고, 추적 파라미터 하나가 페이지를 백 개로 늘리고, 인쇄용과 모바일용이 함께 살아 있고, 같은 콘텐츠가 www와 www 없는 도메인에서, 또 http와 https 양쪽에서 열립니다. 이런 변형들은 저마다 따로 링크와 노출을 쌓고, 그렇게 한 페이지가 같은 검색어를 두고 자기 자신과 경쟁하게 됩니다. 키워드 카니발리제이션에서 다룬 자해에 가까운 분산과 같은 현상입니다. 캐노니컬 태그는 남기고 싶은 버전을 지목하고, 나머지 버전의 신호를 그쪽으로 몰아 달라고 요청합니다.

창업자가 가장 자주 오해하는 지점은 이 요청의 세기입니다. 구글은 선언된 캐노니컬을 여러 입력 중 하나로 다루고, 전체 그림에서 자신이 선호하는 URL을 스스로 고릅니다.

• 선언한 캐노니컬 — 페이지 head 안에 있는 link 요소 그 자체.
• 리디렉션 — 301은 중복에 주석을 다는 대신 아예 없애기 때문에 태그보다 훨씬 강한 의사표시다.
• 내부 링크 — 사이트의 모든 링크가 선언하지 않은 쪽을 가리키고 있다면 그 선언은 자기 사이트의 내비게이션과 다투는 셈이다. 내부 링크가 이 판단과 분리될 수 없는 이유다.
• 사이트맵 — 목록에 올린 URL은 색인해 달라고 요청한 URL이기도 하다.
• [hreflang](/glossary/hreflang) 클러스터 — 서로를 참조하는 언어 변형은 한 묶음으로 읽히고, 클러스터와 어긋나는 캐노니컬은 대개 밀린다.

이 신호들이 서로 맞으면 태그는 거의 언제나 존중됩니다. 엇갈리면 구글이 스스로 결론을 내고, 자신이 고른 URL을 서치 콘솔에 알려 줍니다. 기술적으로는 멀쩡히 존재하는 캐노니컬이 아무 효력도 내지 못하는 일이 생기는 건 이 때문입니다.

가장 먼저 확인할 실패 유형

망가진 캐노니컬은 대부분 몇 가지 유형에 들어갑니다. 다른 곳으로 리디렉션되는 URL을 가리키는 캐노니컬은 더 이상 그 페이지를 서빙하지 않는 주소로 신호를 모아 달라고 요청하는 셈입니다. noindex 페이지를 가리키는 캐노니컬은 색인에서 빼 달라고 이미 요청해 둔 대상에 신호를 모으라고 말하는 셈입니다. 템플릿이 모든 페이지에 홈 캐노니컬을 박아 넣은 경우 — 실제로 흔한 버그입니다 — 사이트 전체가 하나의 문서라고 구글에 알리게 됩니다. 그리고 소스에는 올바르게 들어 있지만 스크립트나 렌더링 계층에 밀려 head까지 닿지 못한 캐노니컬은, 알아채기 가장 어려운 방식으로 망가져 있습니다. 확인하러 손이 가는 도구들이 하나같이 그 태그를 계속 보여 주기 때문입니다.

서치 콘솔에는 비슷해 보이지만 정반대를 뜻하는 두 상태가 있습니다. "적절한 표준 태그가 있는 대체 페이지"는 구글이 선언을 읽고 동의해 통합했다는 뜻으로, 중복에게는 건강한 종착점이지 쫓아다닐 오류가 아닙니다. "사용자가 선택한 표준 없는 중복 페이지"는 거의 같은 페이지를 찾았는데 쓸 만한 캐노니컬이 없어 구글이 대신 골랐다는 뜻입니다. 손대야 할 것은 후자이고, 가장 먼저 시험할 것은 태그가 가리키는 곳이 아니라 Googlebot이 그 태그를 받기는 하는지입니다.

구글이 우리 캐노니컬을 보지 못하게 됐을 때 배운 것

여기부터는 문서가 아니라 agentceres.com을 운영하며 얻은 이야기입니다. 2026년 8월, 서치 콘솔은 우리 사이트의 URL 88개를 사용자가 선택한 표준이 없는 중복으로 보고했습니다. 캐노니컬 태그는 그동안 내내 소스에 올바르게 들어 있었습니다. 원인은 두 겹 아래에 있었습니다. 마케팅과 법률 관련 라우트 열댓 개가 조용히 정적 프리렌더링에서 빠져 있었고, 우리 프레임워크는 동적으로 렌더링되는 페이지의 메타데이터를 스트리밍으로 내보냅니다. 그래서 제목과 robots 지시문, 캐노니컬, hreflang이 문서 시작에서 약 1.5KB 지점에 이미 닫힌 head보다 뒤, body 안으로 나가고 있었습니다. head 밖의 캐노니컬 링크는 캐노니컬 링크가 아니므로, 구글은 받은 그대로 기록했습니다. 아무것도 선언되지 않은 거의 동일한 페이지들로 보고 대신 골라 준 것입니다.

가장 많은 시간을 앗아간 대목이 전할 가치가 가장 큽니다. 서치 콘솔의 실제 URL 테스트는 크롤러와 다른 사용자 에이전트로 가져오는데, 그 에이전트가 우리 프레임워크에서 스트리밍 없이 완전한 메타데이터를 받는 봇 기본 목록에 들어 있었습니다. 반면 Googlebot은 의도적으로 들어 있지 않았습니다. 그래서 실제 URL 테스트는 실행할 때마다 head 안의 올바른 캐노니컬을 보여 준 반면, 정작 색인을 만드는 크롤은 아무것도 보지 못했습니다. 어떤 페이지가 중복으로 보고되면 어떤 라이브 테스트보다 색인된 결과와 원본 HTML을 믿으십시오. 소스 보기로 head가 어디서 닫히는지 찾으면 됩니다. 같은 사고의 더 단순한 절반도 본인 사이트에서 볼 만합니다. 우리 www 호스트가 모든 페이지를 리디렉션 없이 200으로 서빙하고 있어서, 구글이 www를 apex 도메인보다 위의 대표 호스트로 색인해 두었고 301 하나로 해결됐습니다. 이 규모의 수정은 서치 콘솔이 검증을 확정하기까지 보통 두어 주가 걸립니다. 캐노니컬 보고서가 아니라 트래픽 감소에서 거꾸로 짚어 가는 중이라면 내 웹사이트에 트래픽이 없는 이유가 이보다 앞선 점검을 다룹니다.