#05
AEO 입문 시리즈
AEO 입문: AI에게 읽히는 기술 | ⑤ canonical 태그와 중복 콘텐츠
목록으로

canonical 태그 | 검색 순위 분산을 막는 법

skimar 2026. 04. 30 3 min read

이 글은 "AEO 입문: AI에게 읽히는 기술" 시리즈의 다섯 번째 글입니다.
1편에서는 크롤링과 인덱싱의 차이를, 2편에서는 봇이 HTML을 어떤 순서로 읽는지를, 3편에서는 robots.txt를, 4편에서는 sitemap.xml을 다뤘습니다.

이번 글에서는 canonical 태그를 다룹니다.
같은 상품인데 URL이 여러 개라면?
봇은 그걸 전부 다른 페이지로 인식합니다.

검색엔진 평가가 분산되고, AI 크롤러는 어떤 URL을 신뢰해야 할지 혼란에 빠집니다.
canonical 태그는 이 문제를 해결하는 한 줄짜리 선언입니다.

같은 상품, 다른 URL — 왜 문제인가

커머스 사이트에서는 하나의 상품에 여러 URL이 생기는 일이 매우 흔합니다.

카페24 기반 자사몰을 예로 들어보겠습니다.
브랜드 A의 "제품 B"라는 상품이 있다고 가정하면, 아래처럼 다양한 경로로 접근할 수 있습니다.

# 상품 직접 URL
https://brand-a.co.kr/product/제품B/123

# 카테고리 경유 URL
https://brand-a.co.kr/category/건강식품/product/제품B/123

# 사이트 내 검색 결과 경유
https://brand-a.co.kr/product/제품B/123?search=건강식품

# 광고 추적 파라미터
https://brand-a.co.kr/product/제품B/123?utm_source=naver

# 정렬/필터 파라미터
https://brand-a.co.kr/product/제품B/123?sort=price

사람 눈에는 전부 같은 상품 페이지입니다. 하지만 봇 입장에서는 URL이 다르면 별개의 페이지입니다. 5개 URL이면 같은 콘텐츠가 5개 페이지에 중복 존재하는 셈입니다.

중복 URL이 만드는 세 가지 문제

검색엔진 평가 분산

외부 블로그에서 이 상품 페이지로 링크를 걸었다고 가정해보겠습니다.
어떤 블로거는 URL A로, 어떤 블로거는 URL B로 링크했습니다.
원래 한 페이지로 합쳐져야 할 신뢰 점수가 여러 URL로 쪼개집니다.
데이터베이스에 비유하면, 같은 데이터에 대한 투표수가 여러 레코드에 나뉘어 저장되는 것과 같습니다.

검색 결과 URL 혼란

봇이 여러 URL 중 어떤 것을 검색 결과에 보여줄지 임의로 결정합니다.
내가 원하는 깔끔한 URL이 아니라, ?utm_source=naver&utm_medium=cpc 같은 파라미터가 덕지덕지 붙은 URL이 노출될 수도 있습니다.

크롤링 예산 낭비

봇이 사이트를 방문할 때 무한히 크롤링하는 게 아니라, 사이트별로 할당된 크롤링 예산이 있습니다.
같은 콘텐츠를 5번 크롤링하면 새로운 페이지를 발견할 기회가 그만큼 줄어듭니다.

canonical 태그 없이 중복 URL이 발생하는 상황과 평가 분산을 보여주는 다이어그램

canonical 태그 — "원본은 이거야"

canonical은 <head> 영역에 한 줄을 추가해서, 여러 URL 중 "이게 원본이다"라고 봇에게 선언하는 태그입니다.

<!-- 모든 중복 URL의 <head>에 동일하게 삽입 -->
<link rel="canonical" href="https://brand-a.co.kr/product/제품B/123">

카테고리 경유 URL이든, utm 파라미터가 붙은 URL이든, 봇이 이 태그를 읽으면 "이 페이지의 원본은 /product/제품B/123이구나"라고 인식합니다.
분산되어 있던 신뢰 점수가 원본 URL 하나로 합쳐지고, 검색 결과에도 원본 URL만 노출됩니다.

페이지 유형별 처리 전략

모든 중복 URL을 canonical 하나로 해결할 수 있는 건 아닙니다. 페이지 유형에 따라 접근 방식이 달라집니다.

상품 상세 페이지 — canonical로 통일

가장 단순한 케이스입니다. 파라미터가 뭐가 붙든 기본 상품 URL을 canonical로 지정합니다.

<!-- ?utm_source=naver 페이지의 <head> -->
<link rel="canonical" href="https://brand-a.co.kr/product/제품B/123">

카테고리 페이지 — 정렬/필터 변형 처리

카테고리 페이지도 같은 문제가 생깁니다. 정렬 옵션을 바꿀 때마다 URL이 달라지니까요.

/category/건강식품/                     ← 기본
/category/건강식품/?sort=price          ← 가격순
/category/건강식품/?sort=newest         ← 최신순
/category/건강식품/?filter=organic      ← 유기농 필터

상품 목록은 같은 건데 봇은 각각 별개의 페이지로 인식합니다.
정렬과 필터 조합이 많아지면 같은 카테고리에서 URL이 수십 개로 불어날 수 있습니다.
이때는 정렬/필터가 붙은 모든 URL에서 기본 카테고리 URL을 canonical로 지정합니다.

<!-- ?sort=price 페이지의 <head> -->
<link rel="canonical" href="https://brand-a.co.kr/category/건강식품/">

카테고리 페이지 — 페이지네이션은 다르다

?page=2, ?page=3은 실제로 다른 상품이 표시되므로 완전한 중복이 아닙니다.
이걸 1페이지로 합치면 2페이지 이후의 상품이 검색에서 사라질 수 있습니다.
페이지네이션은 각 페이지가 자기 자신을 canonical로 가리키는 self-canonical이 올바른 처리입니다.

<!-- ?page=2 페이지의 <head> -->
<link rel="canonical" href="https://brand-a.co.kr/category/건강식품/?page=2">

내부 검색 결과 페이지 — canonical보다 noindex

사이트 내부 검색 결과 페이지(예: ?search=서리태)는 검색어 조합이 사실상 무한대입니다.
canonical로 묶는 것보다 아예 인덱싱을 차단하는 편이 낫습니다.

<!-- 내부 검색 결과 페이지의 <head> -->
<meta name="robots" content="noindex, follow">

noindex는 "이 페이지는 검색 결과에 포함하지 마"이고, follow는 "그래도 이 페이지 안의 링크는 따라가"라는 뜻입니다.
검색 결과 페이지 자체는 인덱싱하지 않되, 거기에 나열된 상품 링크는 봇이 따라가서 개별 상품 페이지를 크롤링할 수 있게 하는 조합입니다.

페이지 유형별 canonical 처리 전략을 한눈에 정리한 표 형태 인포그래픽

카페24에서는 어떻게 적용하는가

"그러면 대상 URL을 전부 찾아서 하나하나 작업해야 하나요?"
아닙니다. 템플릿 1곳에 로직을 넣으면 자동 처리됩니다.

카페24는 페이지 유형별로 스킨 템플릿 파일이 나뉘어 있습니다.
카테고리 페이지를 담당하는 템플릿 파일의 <head> 안에, 현재 URL에서 파라미터를 제거하고 기본 URL만 canonical로 지정하는 로직을 넣으면 됩니다.
원리를 워드프레스 PHP로 먼저 보겠습니다.

<?php
  // 현재 URL에서 ? 이후 파라미터를 전부 제거
  $canonical = strtok($_SERVER['REQUEST_URI'], '?');
?>
<link rel="canonical" href="https://brand-a.co.kr<?php echo $canonical; ?>">

이 코드 한 줄이면 어떤 파라미터가 붙든 canonical은 항상 기본 URL을 가리킵니다.

/category/건강식품/?sort=price          → canonical: /category/건강식품/
/category/건강식품/?sort=newest&filter=organic → canonical: /category/건강식품/
/category/건강식품/                      → canonical: /category/건강식품/ (self-canonical)

카페24는 PHP 대신 자체 스킨 문법(치환 코드)을 사용하지만 원리는 같습니다.
스마트디자인 편집기에서 카테고리 레이아웃 파일의 <head> 영역에 치환 코드를 이용해 canonical 태그를 삽입하면, 해당 유형의 전체 페이지에 일괄 적용됩니다.
고도몰과 아임웹도 각 플랫폼의 템플릿 시스템에서 레이아웃 파일 1곳만 수정하면 동일한 효과를 얻을 수 있습니다.

워드프레스라면 Yoast SEO나 Rank Math 같은 플러그인이 이 canonical 처리를 자동으로 해줍니다.
카페24는 SEO 관련 앱이 있긴 하지만 기본 제공 범위가 제한적이라 스킨을 직접 수정해야 하는 경우가 많습니다.
이 지점이 카페24 SEO 컨설팅에서 실무 작업이 발생하는 부분입니다.

AEO 관점에서 canonical이 중요한 이유

Google 봇은 20년 넘게 발전해서 중복 URL을 어느 정도 자체적으로 처리할 수 있습니다.
하지만 AI 크롤러(Perplexity, ChatGPT 웹검색 등)는 다릅니다.
AI 크롤러는 텍스트의 구조와 명시적 선언에 더 의존합니다.

canonical이 없는 상태에서 AI가 같은 상품을 서로 다른 URL에서 수집하면, 해당 정보의 출처를 하나로 특정하기 어렵습니다.
"이 상품을 추천해줘"라는 질문에 AI가 답변을 구성할 때, 출처 URL이 불확실하면 아예 언급하지 않을 수도 있습니다.
canonical 태그는 AI에게 "이 정보의 정식 주소는 여기다"라고 알려주는 역할을 합니다.

2편에서 다뤘던 JSON-LD 구조화 데이터와도 연결됩니다.

JSON-LD에 담긴 상품 정보와 canonical URL이 일관되게 연결되어 있으면, AI 크롤러가 "이 URL이 이 상품의 공식 페이지"라고 확신을 갖게 됩니다.

3초 만에 canonical 진단하기

사이트를 처음 점검할 때, 브라우저 개발자 도구(F12)의 Console 탭에서 아래 한 줄이면 canonical을 바로 확인할 수 있습니다.

document.querySelector('link[rel="canonical"]')?.href

진단 방법은 간단합니다. 같은 상품을 세 가지 경로로 열어봅니다.

1. 카테고리 목록에서 클릭해서 접근
2. 상품 URL을 직접 주소창에 입력
3. 사이트 내 검색으로 접근

각 경로에서 위 콘솔 명령을 실행합니다.
세 결과가 전부 같은 URL을 가리키면 정상입니다.
결과가 제각각이거나 canonical 태그 자체가 없으면(undefined가 나오면) 중복 콘텐츠 문제가 있는 것입니다.

이전 편에서 다뤘던 h1 확인(document.querySelectorAll('h1')), meta description 확인(document.querySelector('meta[name="description"]')?.content)과 합치면, 콘솔 진단 세트가 세 개로 늘어났습니다.

// 1. h1 확인
document.querySelectorAll('h1')

// 2. meta description 확인
document.querySelector('meta[name="description"]')?.content

// 3. canonical 확인
document.querySelector('link[rel="canonical"]')?.href

브라우저 콘솔에서 canonical 태그를 진단하는 장면을 표현한 일러스트

self-canonical이라는 안전장치

한 가지 더 알아둘 개념이 있습니다. self-canonical은 페이지가 자기 자신의 URL을 canonical로 가리키는 것을 말합니다.

<!-- https://brand-a.co.kr/product/제품B/123 페이지의 <head> -->
<link rel="canonical" href="https://brand-a.co.kr/product/제품B/123">

"자기 자신을 가리키는 게 무슨 의미가 있지?"라고 생각할 수 있지만, 이건 봇에게 "이 URL이 원본이 맞다"고 명시적으로 확인해주는 역할을 합니다.
canonical 태그가 아예 없으면 봇이 "원본이 뭔지 모르겠다"는 상태가 되고, self-canonical이 있으면 "여기가 원본이다"라는 확인을 받는 상태가 됩니다.
Google 공식 문서에서도 중복이 없는 페이지라도 self-canonical을 넣을 것을 권장합니다.

canonical 태그의 한계

canonical은 강력한 도구이지만 만능은 아닙니다. 알아둬야 할 한계가 두 가지 있습니다.

첫째, canonical은 힌트(hint)이지 명령(directive)이 아닙니다.
Google은 canonical 태그를 참고하지만, 최종 판단은 자체 알고리즘으로 합니다.
canonical이 가리키는 URL과 실제 콘텐츠가 현저히 다르면 봇이 canonical을 무시할 수 있습니다.
예를 들어 완전히 다른 두 페이지를 canonical로 묶으려 하면 작동하지 않습니다.

둘째, HTTP와 HTTPS, www와 non-www 간의 차이도 중복으로 취급됩니다.
아래 네 개의 URL은 전부 별개로 인식될 수 있습니다.

http://brand-a.co.kr/product/123
https://brand-a.co.kr/product/123
http://www.brand-a.co.kr/product/123
https://www.brand-a.co.kr/product/123

이 문제는 canonical 태그만으로 해결하기보다, 서버 단에서 301 리다이렉트로 하나의 형식으로 통일하는 것이 근본적인 해결책입니다.
canonical과 301 리다이렉트를 함께 설정하면 가장 확실합니다.

정리

canonical 태그는 "이 콘텐츠의 원본 URL은 여기다"라고 봇에게 선언하는 한 줄짜리 코드입니다. 커머스 사이트에서는 같은 상품이 수십 개의 URL로 접근 가능한 경우가 흔하고, 이 중복이 검색엔진 평가 분산, 검색 결과 URL 혼란, 크롤링 예산 낭비를 일으킵니다. canonical 태그 하나로 이 문제를 잡을 수 있고, 카페24 같은 템플릿 기반 플랫폼에서는 템플릿 파일 1곳만 수정하면 전체 페이지에 일괄 적용됩니다.

다음 편에서는 meta title과 meta description 최적화 원칙을 다룰 예정입니다. 검색 결과에서 클릭을 결정짓는 두 줄의 텍스트를 어떻게 설계해야 하는지, 카페24에서 자동 생성되는 title의 문제점과 함께 살펴보겠습니다.