캐노니컬 태그를 잘못 설정하면 생기는 일

캐노니컬 태그는 중복 콘텐츠 지우개가 아닙니다

캐노니컬 태그는 여러 URL이 동일하거나 상당히 유사한 콘텐츠를 담고 있을 때 어떤 URL을 선호하는지 검색엔진에 알려줍니다. 일반적인 HTML 버전은 다음과 같습니다.

<link rel="canonical" href="https://example.com/preferred-page/">

HTTP 헤더 버전도 있으며, 주로 PDFs 같은 비 HTML 파일에 유용합니다.

Link: <https://example.com/preferred-file.pdf>; rel="canonical"

간단해 보입니다. 문제는 팀이 캐노니컬 태그를 어색한 모든 것을 정리하는 안전한 방법처럼 다룰 때 시작됩니다. 패싯 내비게이션, 추적 매개변수, 인쇄용 페이지, 거의 중복인 제품 페이지, 페이지네이션, 스테이징 URL, 오래된 캠페인 페이지가 여기에 해당합니다.

캐노니컬 태그는 삭제 버튼이 아닙니다. 리디렉션도 아닙니다. 정보 구조를 대신할 수도 없습니다. 그리고 반드시 준수된다는 보장도 없습니다.

검색엔진은 캐노니컬을 강한 힌트로 사용합니다. 검색엔진은 캐노니컬 태그를 다른 신호와 비교합니다. 리디렉션, 내부 링크, 사이트맵 URL, hreflang 주석, 콘텐츠 유사도, HTTP 상태 코드, 사용자와 크롤러가 실제로 만나는 URL이 그 신호입니다. 이러한 신호가 충돌하면 검색엔진은 캐노니컬을 무시하거나 완전히 다른 캐노니컬 URL을 선택할 수 있습니다.

그래서 캐노니컬을 잘못 설정하면 매우 혼란스러울 수 있습니다. 브라우저에서 마크업은 올바르게 보이지만, 검색 결과에는 잘못된 페이지가 나타나거나 올바른 페이지가 사라집니다.

캐노니컬이 잘못된 URL을 가리키면 생기는 일

검색엔진이 중복 또는 거의 중복인 URL을 보면, 보통 이를 하나의 클러스터로 묶고 그중 하나의 URL을 캐노니컬로 선택합니다. 선택된 캐노니컬은 색인되고 검색 결과에 표시될 가능성이 가장 높은 버전입니다. 중복 URL의 신호는 선택된 URL로 통합될 수 있습니다.

캐노니컬 태그가 잘못된 페이지를 가리키면 여러 일이 생길 수 있습니다.

1. 잘못된 URL이 색인됩니다

다음 두 URL이 있다고 가정해 보겠습니다.

• /mens-running-shoes/
• /sale/mens-running-shoes/

세일 페이지가 주요 카테고리 페이지를 캐노니컬로 지정한다면, 콘텐츠가 거의 동일하고 세일 URL이 단지 필터링된 버전일 경우에는 괜찮을 수 있습니다. 하지만 세일 페이지에 고유한 문구, 고유한 제품, 자체 검색 수요가 있다면 캐노니컬이 그 페이지를 억제할 수 있습니다.

그 페이지는 여전히 크롤링될 수 있습니다. 사용자도 여전히 접근할 수 있습니다. 하지만 검색엔진은 당신이 다른 URL을 선호 버전이라고 알려주었기 때문에 이를 별도로 색인하지 않기로 결정할 수 있습니다.

이것이 가장 흔한 캐노니컬 실패입니다. 극적인 기술 장애가 아니라, 색인에서 조용히 사라지는 일입니다.

2. 순위 신호가 잘못된 곳으로 통합됩니다

캐노니컬은 링크와 중복 콘텐츠 변형 같은 신호를 통합하는 데 자주 사용됩니다. 중복 페이지가 정말로 동등할 때는 유용합니다. 그렇지 않을 때는 위험합니다.

블로그 글에 다음과 같은 추적 URL이 있다면:

• /guide-to-canonical-tags/?utm_source=newsletter
• /guide-to-canonical-tags/?utm_source=linkedin

둘 다 /guide-to-canonical-tags/로 캐노니컬 처리하는 것은 합리적입니다.

하지만 스페인어 버전, 추가 콘텐츠가 있는 인쇄용 버전, 또는 의도가 다른 제품 변형이 같은 캐노니컬을 가리킨다면, 분리되어야 할 신호를 합치고 있을 수 있습니다. 그 결과 모든 페이지의 관련성이 약해질 수 있습니다.

캐노니컬 태그는 동등성에 관한 것입니다. 두 페이지가 서로 다른 검색 의도를 충족한다면, 서로를 캐노니컬로 지정해서는 안 될 가능성이 큽니다.

3. 검색엔진이 태그를 무시합니다

캐노니컬은 명령이 아닙니다. 캐노니컬 대상이 리디렉션되거나, 404를 반환하거나, 차단되어 있거나, noindex가 있거나, 매우 다른 콘텐츠를 담고 있다면 검색엔진은 이를 무시할 수 있습니다.

어떤 의미에서는 좋은 일입니다. 잘못된 캐노니컬이 항상 색인을 망가뜨리지는 않기 때문입니다. 하지만 이는 태그가 당신이 생각한 대로 작동한다고 가정할 수 없다는 뜻이기도 합니다. 페이지는 하나의 캐노니컬을 선언하지만 Google은 다른 것을 선택할 수 있습니다.

이는 내부 링크, 사이트맵, 캐노니컬이 서로 맞지 않을 때 특히 흔합니다. 모든 내부 링크가 /product를 가리키고, 사이트맵은 /product/를 나열하며, 캐노니컬은 https://www.example.com/product?ref=main을 가리킨다면, 당신은 자신의 신호들 사이에 작은 논쟁을 만든 것입니다.

검색엔진은 그 논쟁을 잘 해결합니다. 하지만 항상 당신이 의도한 방식으로 해결하지는 않습니다.

4. 디버깅이 불필요하게 어려워집니다

잘못된 캐노니컬은 대개 크게 실패하지 않습니다. 다른 SEO 문제처럼 보이는 증상을 만들어냅니다.

• “Discovered, currently not indexed” 또는 이에 준하는 색인 대기 상태
• 특정 쿼리에서 잘못된 URL이 순위를 얻음
• 보고서에 매개변수 URL이 나타남
• 크롤링 가능한데도 카테고리 페이지가 나타나지 않음
• 국제 페이지가 잘못된 언어 버전으로 접힘
• 새 템플릿 출시 후 예상보다 적은 페이지가 색인됨

그래서 캐노니컬 디버깅에는 원본 HTML, 렌더링된 HTML, HTTP 헤더, 리디렉션, 사이트맵 항목이 포함되어야 합니다. 이미 리디렉션 체인이나 일치하지 않는 헤더를 조사하고 있다면 같은 습관이 적용됩니다. 프로덕션에서 리디렉션과 HTTP 헤더를 디버깅하는 작은 툴킷에 관한 가이드에 있는 실용적인 HTTP 검사 워크플로는 보통 CMS 필드를 들여다보는 것보다 캐노니컬 모순을 더 빨리 찾아냅니다.

가장 비용이 큰 캐노니컬 실수

모든 것을 홈페이지로 캐노니컬 처리하기

이 일은 여전히 일어납니다. 템플릿 필드가 비어 있고, 플러그인이 사이트 루트로 되돌아가며, 갑자기 수백 개의 페이지가 홈페이지를 캐노니컬로 선언합니다.

콘텐츠가 명백히 다르기 때문에 검색엔진은 이를 무시할 수 있습니다. 하지만 충분히 많은 신호가 엉켜 있다면 일부 페이지가 제외되거나 잘못 클러스터링될 수 있습니다. 최소한 모든 페이지에서 쓸모없고 모순된 힌트를 보내고 있는 셈입니다.

홈페이지가 내부 페이지의 캐노니컬인 경우는 거의 없습니다.

페이지네이션된 페이지를 1페이지로 캐노니컬 처리하기

오랫동안 일부 사이트는 /category/page/2/, /page/3/ 등을 1페이지로 다시 캐노니컬 처리했습니다. 의도는 중복 카테고리 페이지를 피하는 것이었습니다.

문제는 페이지네이션된 페이지가 중복이 아니라는 점입니다. 이 페이지들은 서로 다른 항목을 담고 있으며 크롤러가 더 깊은 콘텐츠를 발견하도록 돕습니다. 모두 1페이지로 캐노니컬 처리하면 검색엔진이 뒤쪽 페이지를 충분히 처리할 가능성이 낮아질 수 있습니다.

일반적으로 페이지네이션된 페이지는 통합해야 할 구체적인 이유가 없는 한 자기 참조 캐노니컬을 가져야 합니다.

검색 의도를 확인하지 않고 필터링된 페이지를 캐노니컬 처리하기

패싯 내비게이션은 어려운 선택을 만듭니다. 어떤 필터 URL은 쓸모없습니다.

• ?sort=price_ascending
• ?view=grid
• ?sessionid=123

다른 URL은 가치 있는 랜딩 페이지일 수 있습니다.

• /sofas/blue/
• /laptops/16gb-ram/
• /hotels/paris/pet-friendly/

일괄적인 캐노니컬 규칙은 쓸모없는 매개변수 잡음과 함께 유용한 검색 페이지도 지워버리는 경우가 많습니다. 필터링된 페이지를 캐노니컬 처리하기 전에, 그 필터 페이지에 안정적인 콘텐츠, 내부 링크, 검색 수요, 뚜렷한 사용자 니즈가 있는지 물어보세요.

대답이 예라면, 그 페이지는 자기 참조 캐노니컬을 가진 색인 가능 페이지가 될 자격이 있을 수 있습니다.

리디렉션되거나 차단된 URL을 캐노니컬 대상으로 지정하기

캐노니컬 대상은 깨끗하고, 색인 가능하며, 200 OK를 반환해야 합니다. 리디렉션되거나, 오류를 반환하거나, 쿠키가 필요하거나, robots.txt로 차단되어 있거나, noindex를 가진 URL을 캐노니컬로 지정하지 마세요.

이는 자동화하기 가장 쉬운 점검 중 하나입니다. 사이트를 크롤링하고 깨끗한 200 응답을 반환하지 않는 캐노니컬 대상을 표시하세요.

캐노니컬과 noindex를 같은 의미처럼 섞어 쓰기

rel="canonical"과 noindex는 서로 다른 문제를 해결합니다.

중복이 존재하고 신호를 선호 URL로 통합하고 싶을 때 캐노니컬을 사용하세요. 페이지가 전혀 색인되지 않기를 원할 때 noindex를 사용하세요.

둘을 함께 사용하면 어색한 메시지를 보냅니다. “이 페이지는 색인하지 말되, 다른 페이지를 위한 중복 신호로도 사용해 달라”는 뜻이 됩니다. 검색엔진은 종종 이를 처리할 수 있지만, 깔끔한 지시는 아닙니다. 페이지가 중복이라면 캐노니컬 처리하세요. 검색에 나타나서는 안 되고 유용한 중복 관계도 없다면 noindex를 고려하세요.

실용적인 캐노니컬 감사

많은 캐노니컬 문제를 찾는 데 거창한 SEO 플랫폼이 필요하지는 않습니다. 크롤링, 몇 개의 URL 샘플, 스프레드시트로 시작하세요.

각 중요 템플릿에 대해 다음을 확인하세요.

1. 페이지에 정확히 하나의 캐노니컬 태그가 있습니까? 여러 캐노니컬 태그는 모호성을 만듭니다.
2. 캐노니컬이 절대 URL입니까? 프로토콜과 호스트명을 포함한 전체 URL을 사용하세요.
3. 캐노니컬 대상이 200 OK를 반환합니까? 리디렉션, 차단, 오류 대상은 피하세요.
4. 캐노니컬 대상이 색인 가능합니까? noindex가 없고, robots 차단이 없으며, 인증 요구가 없어야 합니다.
5. 콘텐츠가 정말로 동등합니까? 유사하다고 해서 항상 동등한 것은 아닙니다.
6. 내부 링크가 일치합니까? 가능하면 캐노니컬 URL 형식으로 링크하세요.
7. 사이트맵이 일치합니까? 사이트맵은 일반적으로 캐노니컬이면서 색인 가능한 URL을 나열해야 합니다.
8. hreflang 태그가 일치합니까? 국제 페이지에는 일관된 캐노니컬 및 hreflang 관계가 필요합니다.
9. 렌더링된 HTML이 원본 HTML과 일치합니까? JavaScript가 태그를 변경하거나 삽입할 수 있습니다.
10. 검색엔진은 어떤 캐노니컬을 선택했습니까? 검사 도구는 선언한 캐노니컬과 선택된 캐노니컬이 다를 때 이를 보여줄 수 있습니다.

여기서 Lighthouse도 도움이 될 수 있지만, 한계 안에서만 그렇습니다. 일부 크롤링 가능성 및 문서 문제를 표시할 수는 있지만, 당신의 상업적 의도나 캐노니컬 전략을 이해하지는 못합니다. 판정이 아니라 하나의 입력값으로 다루세요. 유용한 발견과 잡음을 차분히 구분하는 방법이 필요하다면, 당황하지 않고 Lighthouse 보고서를 읽는 방법을 참고하세요.

자기 참조 캐노니컬은 보통 좋은 기본값입니다

모든 중요한 색인 가능 페이지는 보통 자신을 캐노니컬로 선언해야 합니다. 검색엔진이 태그 없이 이를 알아낼 수 없기 때문은 아닙니다. 자기 참조 캐노니컬은 매개변수, 추적 링크, 복사된 URL, CMS의 특이한 동작이 같은 콘텐츠로 가는 대체 경로를 만들 때 모호성을 줄여주기 때문입니다.

깨끗한 제품 페이지라면 보통 다음이 맞습니다.

<link rel="canonical" href="https://example.com/products/linen-shirt/">

추적 URL의 경우, 캐노니컬은 보통 깨끗한 버전을 다시 가리켜야 합니다.

<link rel="canonical" href="https://example.com/products/linen-shirt/">

진정으로 다른 제품 변형이라면 답은 상황에 따라 달라집니다. 빨간 셔츠, 파란 셔츠, 검은 셔츠가 같은 설명을 가지고 있고 색상만 다르다면 하나의 캐노니컬 제품 페이지로 충분할 수 있습니다. 각 변형에 별도의 수요, 리뷰, 이미지, 재고, 내부 링크가 있다면 별도의 색인 가능 페이지가 의미 있을 수 있습니다.

변형에 대한 보편적인 캐노니컬 규칙은 없습니다. 오직 질문만 있습니다. 이 페이지들은 검색자에게 서로 대체 가능한가?

캐노니컬 태그는 사이트의 실제 URL 정책과 일치해야 합니다

대부분의 캐노니컬 버그는 더 깊은 URL 정책 문제의 증상입니다. 사이트가 후행 슬래시의 의미, 대문자 URL 처리, 매개변수 허용 여부, HTTP에서 HTTPS로의 리디렉션 여부, www를 캐노니컬로 볼지 여부를 결정하지 않은 것입니다.

각 URL의 깨끗한 버전을 하나 선택하고 전체 시스템이 이에 맞게 하세요.

• 선호하지 않는 URL 버전을 선호 버전으로 리디렉션하세요.
• 내부적으로 선호 버전에 링크하세요.
• XML 사이트맵에 선호 버전을 넣으세요.
• 선호 페이지에는 자기 참조 캐노니컬을 사용하세요.
• 진짜 중복만 선호 URL로 캐노니컬 처리하세요.

이 모든 신호가 같은 방향을 가리키면 캐노니컬 태그는 지루해집니다. 그것이 목표입니다.

핵심 정리

캐노니컬 태그는 색인과 신호 통합에 영향을 주기 때문에 강력합니다. 같은 이유로 위험하기도 합니다.

잘못된 캐노니컬이 항상 페이지를 검색에서 제거하는 것은 아닙니다. 검색엔진이 무시할 수도 있습니다. 하지만 나쁜 신호를 검색엔진이 구해주리라고 기대하는 것은 전략이 아닙니다. 더 안전한 접근은 캐노니컬 처리를 진짜 중복에만 사용하고, 대상을 깨끗하고 색인 가능하게 유지하며, 내부 링크, 리디렉션, 사이트맵, 캐노니컬이 같은 이야기를 하도록 만드는 것입니다.

캐노니컬은 지저분한 구조를 숨기는 곳이 아닙니다. 정리되었음을 확인하는 곳입니다.