rel=”canonical” 태그는 검색 엔진에게 “어떤 URL이 이 콘텐츠의 표준 버전인가”를 알려주어 가중치 분산을 방지합니다.
Google SEO에서 페이지의 <head>에 <link rel=”canonical” href=”표준URL”>을 추가하여 사용합니다.
데이터에 따르면, 올바르게 Canonical 태그를 배포한 전자상거래 웹사이트의 제품 목록 페이지 색인 생성률은 평균 28% 증가했으며, 중복 URL에 대한 크롤러 크롤링 횟수는 40%-60% 감소했습니다.
뉴스 사이트에서는 표준 태그를 통해 유사 기사를 통합한 후, 핵심 콘텐츠의 검색 클릭량이 평균 19% 증가했습니다.
하지만 실제 조사 결과, 31%의 웹사이트만이 해당 태그를 100% 올바르게 사용하고 있음이 발견되었습니다 (일반적인 오류에는 잘못된 URL 지정, 프로토콜/도메인 간 비표준, 다중 태그 중첩 등이 포함됩니다).
Canonical 태그를 사용해야 하는 이유
Google 검색 엔진의 일상적인 크롤링에서, 65% 이상의 웹사이트가 URL 구조 설계의 불합리성으로 인해 중복 콘텐츠 문제를 겪고 있습니다.
구체적인 예시:
- 동일한 기사가 매개변수가 있는 URL(예: ?utm_source=xxx)을 통해 표시될 수 있습니다.
- 디렉터리 접미사(예: /page/ 및 /page/index.html)가 포함될 수 있습니다.
- 다른 서브도메인(예: www 및 non-www)이 포함될 수 있습니다.
Google의 John Mueller는 공식 Q&A에서 검색 엔진이 “여러 URL이 매우 유사하거나 완전히 동일한 콘텐츠를 표시하는 경우”에 “어떤 URL에 가중치를 할당해야 하는지” 판단하기 어렵다고 여러 번 언급했습니다.
전자상거래 제품 페이지는 색상 필터링, 정렬 매개변수 등으로 인해 십여 개의 다른 URL을 생성할 수 있으며, 하나의 뉴스 기사는 여러 섹션에 배포되어 여러 진입 링크를 형성할 수 있습니다.
canonical 태그를 사용하면 검색 엔진에 명확하게 알릴 수 있습니다: “이 콘텐츠가 여러 URL을 통해 표시되더라도, 가중치와 순위는 내가 지정한 이 URL에 집중해 주세요.”
중복 콘텐츠가 SEO에 미치는 영향
중복 콘텐츠 자체는 직접적으로 검색 엔진 패널티를 유발하지 않지만(Google은 “단순한 콘텐츠 중복으로 웹사이트를 처벌하지 않는다”고 명확히 밝혔음), 가중치 분산을 초래합니다.
동일한 콘텐츠가 여러 URL을 통해 액세스될 때, 검색 엔진은 이 URL들을 “**서로 다른 페이지**”로 간주하여 개별적으로 처리합니다.
예를 들어, 하나의 오리지널 기사가 다음 4개의 URL을 통해 표시됩니다:
https://example.com/articlehttps://example.com/article?source=newsletterhttps://example.com/article#commentshttps://www.example.com/article(www 버전)
표준 식별이 없으면, 검색 엔진은 이 4개의 URL을 동시에 크롤링하고 각각에 대해 색인 가중치를 계산할 수 있습니다.
하지만 사용자의 검색 요구는 본질적으로 하나의 답변만을 필요로 합니다. 결과적으로 이 4가지 버전의 순위가 모두 낮을 수 있으며 (가중치가 분산되었기 때문에), 심지어 그 중 하나만 우연히 색인되고, 다른 버전은 장기간 “색인되지 않음” 또는 “낮은 순위” 상태에 머무를 수 있습니다.
전자상거래 웹사이트에서는 매개변수(예: ?size=XL, ?color=red)로 인해 생성된 중복 URL이 평균 8~12개에 달할 수 있으며, 이 페이지들의 크롤러 크롤링 비중이 전체 크롤링 양의 15%-20%를 차지할 수 있습니다 (이는 더 가치 있는 새 페이지에 할당되어야 합니다).
뉴스 사이트에서는 콘텐츠가 여러 섹션(예: “최신 뉴스”, “산업 동향”, “인기 추천”)에 배포되어 단일 기사에 대해 3~5개의 다른 진입 URL이 생성될 수 있습니다.
더 구체적인 사례: 한 중형 전자상거래 웹사이트는 URL을 표준화하기 전에 제품 목록 페이지의 색인 생성률이 62%에 불과했습니다 (즉, 100개 페이지 중 62개만 Google에 색인되어 순위 경쟁에 참여할 수 있었음).
매개변수가 있는 목록 페이지(예: ?category=shoes&sort=price)에 canonical 태그(매개변수가 없는 기본 URL, 예: /shoes를 가리킴)를 추가한 후, 3개월 만에 색인 생성률이 81%로 증가했으며 해당 제품의 자연 검색 트래픽이 17% 증가했습니다.
“중복 삭제”가 아닌, “권위 있는 버전 지정”
많은 웹마스터들이 canonical 태그를 “중복 페이지를 삭제하는 데 사용되는 것”으로 오해하고 있습니다.
실제로는 “동일한 콘텐츠를 표시하는 여러 URL 중에서, 어떤 URL을 우선적으로 색인하고, 순위를 부여해야 하는 버전으로 지정할지” 검색 엔진에게 알려주는 것이 핵심 기능입니다.
어떤 페이지의 <head> 부분에 다음 코드를 추가할 때:
<link rel=“canonical” href=“https://example.com/표준URL” />
당신은 검색 엔진에게 명확한 신호를 전달하는 것입니다: “비록 이 페이지(예: 매개변수가 있는 /article?source=email)로도 콘텐츠에 액세스할 수 있지만, 해당 페이지의 가중치와 순위 기회를 https://example.com/표준URL 이 주소에 집중해 주십시오.”
Google 공식 문서 및 실제 크롤링 데이터 관찰에 따르면:
- 크롤링 측면: 검색 엔진은 여전히 모든 버전의 페이지(매개변수 포함, 디렉터리 포함 URL 포함)를 크롤링하지만, canonical 태그를 참조하여 이러한 페이지에 대한 “중요도”를 조정합니다. 예를 들어, 매개변수가 있는 URL은 크롤링될 수 있지만, 크롤러는 표준 버전처럼 자주 재방문하거나 깊이 색인하지 않습니다.
- 색인 측면: 여러 URL의 콘텐츠가 매우 유사한 경우(중복률 80% 초과), 검색 엔진은 일반적으로 표준 버전을 색인 라이브러리에 포함하고, 다른 버전은 개별적으로 색인을 생성하지 않거나, 색인되더라도 핵심 순위 경쟁에 참여하지 않을 수 있습니다.
- 가중치 측면: 외부 링크가 중복 버전의 URL 중 어느 하나를 가리킬 때, 검색 엔진은 canonical 태그의 지시에 따라 해당 외부 링크 가중치를 표준 버전으로 “**이전**” 또는 “**연결**”합니다 (100% 완전히 이전되는 것은 아니지만, 대부분의 경우 효과는 유사합니다).
실제 시나리오 예시: 한 블로그 웹사이트의 기사가 “**홈페이지 추천**”과 “**기술 칼럼**” 두 섹션에 동시에 게시되어 두 개의 URL이 생성되었습니다:
https://example.com/home/recommend/123(홈페이지 추천 진입로)https://example.com/tech/article/123(기술 칼럼 진입로)
두 콘텐츠는 완전히 동일하지만, 홈페이지 추천 URL은 트래픽이 더 많아 일부 외부 링크를 유치했습니다.
canonical 태그가 없으면, 검색 엔진은 이 두 페이지를 독립적인 콘텐츠로 간주할 수 있으며, 홈페이지 추천 URL은 외부 링크가 있더라도 섹션 포지셔닝이 충분히 수직적이지 않아(홈페이지 추천은 일반적으로 종합 콘텐츠) 기술 칼럼보다 순위 잠재력이 낮을 수 있습니다.
기술팀이 두 페이지 모두에 canonical 태그를 추가하여 콘텐츠 주제에 더 적합한 https://example.com/tech/article/123을 가리키게 하면, 검색 엔진은 명확하게 알게 됩니다: “이 콘텐츠의 권위 있는 버전은 기술 칼럼의 URL이다.” 그리고 홈페이지 추천의 외부 링크 가중치도 이쪽으로 연결하여, 해당 페이지의 “기술 관련 키워드” 순위 경쟁력을 높입니다.
Canonical 태그를 사용하지 않으면 어떻게 되는가
크롤러 크롤링 예산 낭비
검색 엔진이 각 웹사이트에 할당하는 “일일 크롤링 횟수”는 제한적이며 (“크롤링 예산”이라고 함), 중요한 페이지(예: 홈페이지, 업데이트 빈도가 높은 콘텐츠 페이지)를 우선적으로 크롤링합니다.
웹사이트에 중복 URL이 많으면(예: 전자상거래 웹사이트의 상품 상세 페이지에 10가지 정렬 매개변수가 있어 1,000개 이상의 다른 URL이 생성됨), 크롤러는 이 “콘텐츠는 같지만 URL이 다른” 페이지에 예산의 일부를 소모하게 되어, 실제로 크롤링되어야 할 새 페이지(예: 방금 출시된 상품, 업데이트된 정보)의 크롤링 빈도가 저하됩니다.
데이터에 따르면, 한 의류 전자상거래 웹사이트의 크롤러 로그 분석 결과, 매개변수가 있는 중복 상품 페이지(예: ?size=M, ?color=blue)가 전체 크롤링 양의 22%를 차지했으며, 이 페이지들의 이탈률은 85%에 달했습니다 (사용자는 특정 상품을 검색하며, 매개변수 URL을 통해 진입하지 않음).
해당 웹사이트가 상품 상세 페이지에 canonical 태그(매개변수가 없는 기본 URL을 가리킴)를 통일적으로 추가한 후, 핵심 상품 페이지에 대한 크롤러 크롤링 빈도가 30% 증가했으며, 새 상품의 색인 생성 시간이 평균 7일에서 3일로 단축되었습니다.
색인 버전 혼란, 불안정한 순위
표준 식별이 없을 때, 검색 엔진은 임의의 URL을 “기본 표시 버전”으로 선택할 수 있지만, 이 선택은 고정적이지 않습니다.
예를 들어, 사용자가 특정 키워드를 검색할 때, 어떤 때는 www 버전(https://www.example.com/page)을 보기도 하고, 어떤 때는 www 없는 버전(https://example.com/page)을 보기도 하며, 심지어 매개변수가 있는 버전(https://example.com/page?from=social)을 볼 수도 있습니다.
사례: 한 지역 서비스 웹사이트의 “연락처” 페이지는 https://example.com/contact와 https://example.com/contact-us 두 버전이 동시에 존재하며(콘텐츠는 완전히 동일), canonical 태그가 설정되지 않았습니다. Google은 서로 다른 시점에 이 두 URL을 각각 색인하여, 사용자가 “XX 도시 수리 서비스 연락처”를 검색할 때, 어떤 때는 첫 번째 버전의 순위가 높고, 어떤 때는 두 번째 버전의 순위가 높은 결과를 초래했습니다.
사용자가 클릭 후 비주요 버전(예: contact-us)으로 진입하면, 페이지 탐색 디자인 차이로 인해 전환율이 감소할 수 있습니다 (예: 온라인 예약 버튼 누락).
이후 해당 웹사이트는 두 버전에 모두 canonical 태그를 추가하여 https://example.com/contact를 가리키게 했으며, 3개월 후 해당 페이지의 순위가 향상되었고, 검색 클릭률(CTR)이 11% 증가했습니다.
외부 링크 가중치 분산
여러 중복 버전의 URL이 외부 웹사이트에 의해 링크되는 경우(예: 누군가 콘텐츠를 전재할 때 매개변수가 있는 URL을 사용했거나, 섹션 페이지 배포 시 새 링크가 생성됨), 이 외부 링크들이 서로 다른 주소를 가리키며 분산되면, 검색 엔진은 가중치를 자동으로 병합할 수 없습니다.
데이터 비교: 한 교육 웹사이트의 “대학원 입시 전략” 기사가 5개의 외부 사이트에 전재되었으며, 그 중 3개는 매개변수가 없는 버전(https://example.com/guide/kaoyan)으로, 2개는 매개변수가 있는 버전(https://example.com/guide/kaoyan?from=partner)으로 링크되었습니다.
canonical 태그를 설정하지 않았을 때, 검색 엔진은 이 5개의 외부 링크를 각각 다른 URL에 연결했습니다. 해당 웹사이트가 모든 버전에 canonical 태그(매개변수가 없는 버전을 가리킴)를 추가한 후, 6개월 이내에 해당 페이지의 자연 검색 트래픽이 24% 증가했습니다.
Canonical 태그의 기본 구문과 작성 방법
약 32%의 페이지가 canonical 태그를 <body> 부분(필수적인 <head> 영역이 아님)에 배치했으며, 19%의 href 속성 값은 전체 프로토콜이 누락되었고(예: https://example.com이 아닌 example.com만 작성), 15%의 페이지는 여러 중복 URL에서 서로 다른 “표준 버전”을 가리켰습니다(검색 엔진 혼란 유발).
기술적 구현 측면에서 canonical 태그는 본질적으로 간단한 HTML 링크 태그이지만, 태그 위치(반드시 <head> 내), 구문 형식(HTML 표준 엄격 준수), 가리키는 URL(실제 콘텐츠와 완전히 일치하고 액세스 가능해야 함)이 중요합니다.
데이터에 따르면, canonical 태그가 표준 작성법에 따라 배포될 때(<head> 상단에 배치, 완전한 HTTPS 프로토콜 사용, 유일하고 정확한 표준 URL을 가리킴), 검색 엔진이 해당 태그를 올바르게 식별하고 적용할 확률은 95%를 초과합니다.
작성법이 잘못된 페이지의 경우, 약 60%의 표준 의도가 검색 엔진에 채택되지 않아 중복 콘텐츠 문제가 여전히 존재했습니다.
예를 들어, 한 전자상거래 웹사이트가 상품 상세 페이지(예: 매개변수 ?color=red 버전)에 canonical 태그를 추가할 때, 프로토콜 헤더를 누락하여(//example.com/product 또는 example.com/product로 작성) Google이 대상 URL을 올바르게 파싱할 수 없었습니다.
표준 구문 구조
canonical 태그의 완전한 구문은 한 줄의 HTML 코드입니다: <link rel=“canonical” href=“https://www.example.com/표준_페이지의_완전한_URL” />
이 코드는 3개의 핵심 부분으로 구성되며, 빠져서는 안 되며 순서가 고정되어 있습니다:
태그 유형: <link>
- 이는 HTML에서 문서와 외부 리소스의 관계를 정의하는 데 사용되는 태그이며, canonical 태그는 “링크 관계”의 한 종류로,
<link>를 기본 구조로 사용해야 합니다.
속성: rel="canonical"
rel은<link>태그의 필수 속성이며, 현재 링크와 현재 문서의 관계를 설명하는 데 사용됩니다. 값이canonical로 설정되면, 검색 엔진에게 명확하게 알립니다: “이 태그는 현재 페이지 콘텐츠의 표준(권위 있는) 버전을 정의합니다.”
속성: href="URL"
href는<link>태그의 또 다른 필수 속성이며, 표준 버전의 구체적인 웹 주소를 지정하는 데 사용됩니다. 이 URL은 완전하고 액세스 가능해야 하며, 프로토콜(http 또는 https), 도메인(www 또는 non-www), 경로 및 매개변수(필요한 경우)를 포함해야 합니다.
예시:
- 올바른 작성:
href="https://www.example.com/products/shoes" - 잘못된 작성 1(프로토콜 누락):
href="//www.example.com/products/shoes"(브라우저는 자동 완성할 수 있지만, 검색 엔진은 정확하게 파싱하지 못할 수 있음) - 잘못된 작성 2(도메인 누락):
href="/products/shoes"(상대 경로, 검색 엔진은 구체적으로 어떤 웹사이트의 페이지인지 알 수 없음) - 잘못된 작성 3(오타):
href="https://www.exaple.com/products/shoes"(도메인 철자가 틀려 존재하지 않는 페이지를 가리킴)
기타 세부 사항:
- 이 태그는
/로 끝나야 합니다 (URL 자체가 끝 슬래시를 필요로 하는 경우). 하지만 대부분의 경우 최신 검색 엔진은 슬래시 포함 여부에 대한 허용도가 높습니다 (표준만 통일하면 됨). - 태그는 한 줄에 작성되어야 합니다 (줄 바꿈은 일부 파싱 도구에 오류를 유발할 수 있지만, 검색 엔진은 일반적으로 자동 수정 가능).
- 태그의 닫는 부분은
/>입니다 (자체 닫기 태그, HTML5 표준은 마지막/를 생략할 수 있지만, 호환성을 위해 유지하는 것이 좋습니다).
왜 반드시 <head> 안에 있어야 하는가
검색 엔진의 크롤러 프로그램은 페이지를 크롤링할 때, <head> 영역의 내용(특히 메타 정보, 제목, 표준 태그와 같은 “제어 명령”)을 우선적으로 파싱한 다음, <body>의 실제 내용을 처리하기 때문입니다.
canonical 태그가 실수로 <body> 내부(예: 기사 단락 또는 푸터 코드 내부에 중첩)에 배치되면, 검색 엔진은 <body> 내의 <link rel="canonical"> 태그를 무시합니다.
기타 보충:
- 한 페이지에는 하나의 canonical 태그만 있어야 합니다 (여러 개가 나타나면 검색 엔진은 일반적으로 첫 번째만 식별하고 나머지는 무시합니다).
- 이 태그는 다른 태그 내부에 중첩될 수 없습니다 (예:
<div>또는<script>안에 배치할 수 없습니다). - 동적으로 생성되는 페이지(예: PHP, Python 등 백엔드 언어를 통해 출력되는 페이지)의 경우, 템플릿 엔진이 HTML을 출력할 때 canonical 태그를
<head>영역에 올바르게 삽입하도록 해야 합니다 (일반적으로 템플릿 변수를 통해 제어).
가장 흔한 5가지 오류
오류 1: 잘못된 URL 지정 (표준 버전이 실제 요구 사항과 일치하지 않음)
- 현상: canonical 태그를 콘텐츠가 완전히 일치하지 않거나(또는 아예 다른 콘텐츠) 않는 URL로 지정합니다. 예를 들어, 상품 상세 페이지(빨간색 신발 표시)의 canonical이 흰색 신발 페이지를 가리킵니다.
- 결과: 검색 엔진은 잘못된 지침에 따라 가중치를 관련 없는 페이지에 집중시켜 핵심 콘텐츠의 순위가 하락합니다.
- 수정: 현재 페이지의 실제 콘텐츠를 확인하여, href의 URL이 “**완전히 동일한 콘텐츠**”를 표시하는 표준 버전(예: 매개변수가 없는 기본 URL 또는 사용자 검색 의도에 가장 적합한 섹션 페이지)을 가리키는지 확인합니다.
오류 2: 프로토콜 헤더 누락 (도메인만 작성하거나 상대 경로 사용)
- 현상: 코드를
href="//example.com/page"(프로토콜 상대 경로) 또는href="/page"(상대 경로)로 작성합니다. - 결과: 검색 엔진이 대상 URL의 완전한 주소를 정확하게 파싱하지 못할 수 있으며 (특히 프로토콜 간 또는 도메인 간의 경우), 표준 의도가 무효화됩니다.
- 수정: 항상 완전한 프로토콜 + 도메인 + 경로를 사용하며, 형식은
href="https://www.example.com/page"입니다 (보안을 위해 https 프로토콜 권장).
오류 3: 매개변수가 있는 URL과 표준 버전 충돌
- 현상: 한 상품 목록 페이지의 매개변수가 없는 버전(
https://example.com/products)이 표준 버전이지만, 매개변수가 있는 버전(예:https://example.com/products?sort=price)은 이를 올바르게 가리키지 않고, 오히려 다른 매개변수가 있는 URL(예:?sort=date)을 가리킵니다. - 결과: 여러 매개변수 버전이 서로 다른 “표준 버전”을 상호 가리키며 “순환 표준” 또는 가중치 분산을 형성합니다.
- 수정: 모든 매개변수가 있는 URL의 canonical이 매개변수가 없는 기본 버전(또는 가장 일반적으로 사용되는 정렬/필터링 버전)을 가리키도록 통일하고, 모든 변형 버전이 동일한 표준 주소를 가리키도록 보장합니다.
오류 4: 태그가 <body> 내부에 배치됨
- 현상: CMS 백엔드에서 페이지를 편집할 때, 실수로 canonical 코드를 기사 내용 영역(<body> 부분)에 붙여넣고 웹사이트 템플릿의 <head> 영역에는 붙여넣지 않았습니다.
- 결과: 검색 엔진 크롤러가 해당 태그를 무시하여 중복 페이지가 올바르게 표준화되지 않습니다.
- 수정: 기술팀에 연락하여 템플릿 파일(예: WordPress의 header.php, Shopify의 theme.liquid)을 확인하고, canonical 태그가 HTML의 <head> 태그 내부에 출력되도록 합니다.
오류 5: 다중 canonical 태그 중첩
- 현상: 템플릿 오류 또는 수동 추가로 인해, 한 페이지에 여러 개의
<link rel="canonical">태그가 나타났습니다 (예: /page와 /page/를 동시에 가리킴). - 결과: 검색 엔진은 일반적으로 첫 번째 태그만 식별하고, 이후 태그는 무시되어 표준 의도가 혼란스러워질 수 있습니다.
- 수정: 코드를 확인하고, 불필요한 canonical 태그를 삭제하여 각 페이지에 하나의 표준 지침만 있도록 합니다.
canonical과 다른 태그 (예: noindex, 301 리디렉션)의 차이점
canonical 태그는 “**동일한 콘텐츠의 권위 있는 버전 지정**”(모든 URL을 유지하되, 가중치를 집중)이며, noindex 태그는 “**현재 페이지의 검색 엔진 색인 금지**”(크롤링은 허용하지만 표시는 안 함)이고, 301 리디렉션은 “**오래된 URL을 새 URL로 영구적으로 전환**”(트래픽 및 가중치 완전히 이전)입니다.
표준, 금지, 전환의 본질적 차이
canonical 태그 (표준 태그): “**동일한 콘텐츠의 다중 URL 시나리오**”에 사용되며, 검색 엔진에게 “이 페이지들의 콘텐츠는 사실 동일하지만, 내가 지정한 이 URL(표준 버전)에만 집중하고 여기에 가중치를 집중해 주세요”라고 알리는 것이 목적입니다.
- 일반적인 시나리오: 전자상거래 상품 상세 페이지에 매개변수가 있는 경우(예: ?color=red 및 ?color=blue), 뉴스 기사가 여러 섹션에 배포된 경우(예: “최신 뉴스” 및 “산업 동향”), 모바일과 PC가 독립된 URL을 가지지만 콘텐츠가 동일한 경우.
noindex 태그 (색인 금지 태그): “**크롤링은 허용하지만 표시는 금지하는 시나리오**”에 사용되며, 검색 엔진에게 “이 페이지를 크롤링할 수는 있지만, 검색 결과 색인 라이브러리에는 넣지 마세요”라고 알립니다.
- 일반적인 시나리오: 내부 관리 페이지(예: 로그인 페이지, 관리자 통계 페이지), 임시 이벤트 페이지(이벤트 종료 후 순위 유지 불필요), 낮은 가치 콘텐츠 페이지(예: 인쇄 버전, 간/번체 변환 페이지).
301 리디렉션 (영구 전환): “**콘텐츠가 영구적으로 이전된 시나리오**”에 사용되며, 서버 설정(예: .htaccess 파일 또는 Nginx 규칙)을 통해 사용자 및 검색 엔진을 오래된 URL에서 새 URL로 자동 전환합니다. 오래된 URL의 가중치(순위, 외부 링크, 사용자 신뢰도 포함)는 새 URL로 점진적으로 이전되며, 최종적으로 오래된 URL은 더 이상 액세스되지 않을 수 있습니다 (단, 전환은 계속 유효).
- 일반적인 시나리오: 웹사이트 도메인 변경(예: example.com에서 newexample.com으로 마이그레이션), URL 구조 조정(예: /old-product/를 /products/new-product/로 변경), 여러 오래된 페이지를 하나의 새 페이지로 병합.
| 도구 | 크롤링 허용 여부 | 색인 허용 여부 | URL 변경 여부 | 핵심 목적 |
|---|---|---|---|---|
| canonical | ✅ 허용 | ❌ 색인 비권장 (단, 여전히 색인될 수 있음) | ❌ 변경 안 함 | 여러 동일 콘텐츠의 가중치를 표준 버전에 집중 |
| noindex | ✅ 허용 | ❌ 금지 | ❌ 변경 안 함 | 페이지가 검색 결과에 나타나지 않도록 차단 |
| 301 리디렉션 | ❌ 자동 전환 | ❌ 오래된 URL은 색인 안 됨 | ✅ 새 URL로 전환 | 오래된 URL의 가중치와 트래픽을 새 주소로 이전 |
4가지 일반적인 시나리오에서 용법 비교
시나리오 1: 동일 콘텐츠에 여러 URL이 있는 경우 (예: 매개변수가 있는 상품 페이지)
- 문제: 상품 상세 페이지가
https://example.com/product와https://example.com/product?color=red를 통해 액세스 가능하며, 콘텐츠는 완전히 동일합니다. - 올바른 도구: canonical. 매개변수가 있는 URL(
?color=red)에 canonical 태그를 추가하여 매개변수가 없는 기본 URL(https://example.com/product)을 가리키게 하여, 검색 엔진에게 “이 콘텐츠의 권위 있는 버전은 매개변수가 없는 페이지”라고 알립니다. - noindex/301을 선택하지 않는 이유: noindex는 매개변수가 있는 페이지가 색인되지 않도록 하지만(크롤링은 될 수 있음), 사용자가 해당 링크를 통해 진입할 수 있으며, 검색 엔진은 여전히 어떤 것이 주요 버전인지 판단해야 합니다. 301 리디렉션은 사용자 및 크롤러를 강제로 전환해야 하지만, 사용자는 다른 매개변수를 통해 액세스해야 할 필요가 있을 수 있으므로(예: 다른 색상 비교), 강제 전환에는 적합하지 않습니다.
시나리오 2: 페이지가 더 이상 검색 결과에 나타날 필요가 없는 경우 (예: 만료된 이벤트 페이지)
- 문제: 특정 프로모션 이벤트 페이지(
https://example.com/promo)가 종료되었지만, 사용자가 북마크 또는 외부 링크를 통해 여전히 액세스할 수 있으며, 순위가 필요하지 않습니다. - 올바른 도구: noindex. 이벤트 페이지의
<head>에<meta name="robots" content="noindex">태그를 추가하여(또는 CMS 설정을 통해), 검색 엔진이 페이지를 크롤링하도록 허용하되(예: 이벤트 기록 확인), 색인 라이브러리에는 넣지 않도록 합니다. - canonical/301을 선택하지 않는 이유: canonical은 “페이지가 나타나지 않도록 하는” 문제를 해결할 수 없습니다(단지 가중치를 집중시킴). 301 리디렉션은 새 URL을 지정해야 하지만(이벤트 페이지에는 해당하는 새 주소가 없음), 사용자는 여전히 원래 페이지에 액세스하여 과거 정보를 확인해야 할 수 있습니다.
시나리오 3: 웹사이트 도메인 변경 또는 URL 구조 조정 (예: 오래된 제품 페이지 이전)
- 문제: 오래된 제품 페이지(
https://old.example.com/item1)가 새 주소(https://new.example.com/products/item1)로 영구적으로 이전되었으며, 기존의 외부 링크 가중치와 사용자 액세스 습관을 유지해야 합니다. - 올바른 도구: 301 리디렉션. 서버 설정(예: Apache의 .htaccess 파일)을 통해 설정합니다: 사용자 또는 크롤러가 오래된 URL에 액세스할 때, 새 URL로 자동 전환됩니다. 오래된 URL의 순위 및 외부 링크 가중치는 새 URL로 점진적으로 이전됩니다.
- canonical/noindex를 선택하지 않는 이유: canonical은 트래픽 전환을 구현할 수 없습니다(사용자는 여전히 오래된 URL에 머무름). noindex는 오래된 URL이 색인되지 않도록 하지만, 외부 링크 가중치가 이전되지 않으며, 사용자는 오래된 링크를 통해 새 콘텐츠에 액세스할 수 없습니다.
시나리오 4: 모바일과 PC가 독립된 URL을 가지는 경우 (예: m.example.com과 www.example.com)
- 문제: 동일한 콘텐츠가 모바일(
https://m.example.com/page)과 PC(https://www.example.com/page)에서 각각 독립된 URL을 가지며, 콘텐츠는 완전히 동일합니다. - 올바른 도구: canonical 우선 사용 (PC URL을 가리킴), 또는 반응형 디자인을 통해 URL을 통일. 모바일 버전이 필수 진입로인 경우(예: 사용자가 m.example.com을 통해 액세스하는 습관), 모바일 페이지에 canonical 태그를 추가하여 PC 표준 URL을 가리키게 하고, 동시에 301 리디렉션을 통해 일부 오래된 모바일 링크를 PC로 전환할 수 있습니다 (선택 사항).
- noindex를 선택하지 않는 이유: noindex는 모바일 또는 PC 버전 중 하나가 색인되지 않도록 하여, 일부 사용자의 검색 요구(예: 모바일 사용자가 적합한 콘텐츠를 보지 못함)를 충족하지 못할 수 있습니다.
코드는 어떻게 작성해야 하는가? 적용 논리는 어떻게 다른가?
canonical 태그: HTML 코드, 검색 엔진 파싱에 의존
- 코드 작성: 표준화해야 하는 페이지의
<head>부분에<link rel="canonical" href="https://표준URL" />을 추가합니다 (앞 장에서 설명한 바와 같이).
적용 논리: 검색 엔진이 페이지를 크롤링할 때, 해당 태그를 읽고 “이 페이지의 표준 버전은 XXX”라고 기록하며, 이후 순위 계산 및 가중치 할당 시 표준 버전을 우선적으로 고려합니다. 하지만 다른 버전의 페이지도 여전히 크롤링될 수 있습니다 (다른 제한이 없는 한).
noindex 태그: HTML 메타 태그 또는 HTTP 응답 헤더, 크롤러 규칙 준수에 의존
- 코드 작성: 일반적으로 페이지의
<head>에<meta name="robots" content="noindex">를 추가하거나 (대부분의 경우 적용), 서버를 통해 HTTP 응답 헤더X-Robots-Tag: noindex를 반환합니다 (동적 페이지에 적용).
적용 논리: 검색 엔진이 페이지를 크롤링할 때 해당 지침을 감지하고, 페이지가 noindex 조건에 부합한다고 확인되면 (예: 스팸 페이지가 아닌 경우), 색인 라이브러리에 추가하지 않습니다. 하지만 페이지는 여전히 크롤링될 수 있으며 (robots.txt로 크롤링을 차단하지 않는 한), 사용자는 직접 링크를 통해 액세스할 수 있습니다.
301 리디렉션: 서버 설정, 강제 트래픽 전환
코드 작성: 서버 기술을 통해 구현합니다, 예를 들어:
- Apache 서버: .htaccess 파일에
Redirect 301 /old-page https://example.com/new-page를 추가합니다. - Nginx 서버: 구성 파일에
return 301 https://example.com/new-page;를 추가합니다. - CMS 시스템(예: WordPress): 플러그인(예: Redirection)을 통해 전환 규칙을 설정합니다.
적용 논리: 사용자 또는 검색 엔진이 오래된 URL에 액세스할 때, 서버가 자동으로 301 상태 코드를 반환하고 새 URL로 전환하며, 브라우저 주소 표시줄에 새 주소가 표시됩니다. 오래된 URL의 가중치는 새 URL로 점진적으로(일반적으로 몇 주에서 몇 달) 이전되며, 최종적으로 오래된 URL은 더 이상 직접 액세스되지 않을 수 있습니다 (단, 전환 기능은 유지).
