해당 URL들이 실제로 중복인지 판단하기
정규화(canonical) URL은 중복 또는 거의 중복된 페이지의 대표 주소입니다. canonical 링크 관계(rel=canonical)는 대상이 참조 페이지의 콘텐츠를 중복하거나 포함하는 상위집합(superset)일 때 적절합니다. 서로 다른 제품, 유용한 필터, 기사, 로케일을 숨기기 위한 수단이 아닙니다.
방문자가 이 URL이 후보 URL로 대체될 때 중요한 콘텐츠, 선택권 또는 작업 완료를 잃게 되는가를 물어보세요. 그렇다면 별도로 유지하고 콘텐츠나 현지화(localization)를 개선하세요. 아니라면 하나의 안정적 URL을 선택하고 프로토콜, 호스트, 경로, 트레일링 슬래시, 매개변수 규칙을 문서화하세요.
명시된 대표 인덱스 가능 HTML 페이지마다 자기 참조 canonical을 추가하세요. 오늘 당장 중복이 명백하지 않아도 적용합니다.
분석 매개변수 경로처럼 필요한 중복이 있다면, 두 페이지가 같은 주요 콘텐츠를 반환할 때만 그 중복을 선호 URL로 가리키세요.
이전 URL이 사라져야 할 때는 리디렉트 사용
이전 경로, 폐기된 호스트 또는 HTTP 버전이 더 이상 방문자나 크롤러의 목적지가 되어서는 안 될 때는 서버 측 영구 리디렉트(예: 301)를 사용하세요. Google은 중복을 제거할 때 리디렉트를 강한 canonical화 신호로 처리하며 이를 권장합니다.
둘 다 콘텐츠로 응답해야 하지만 그중 하나만 검색에서 클러스터를 대표해야 할 경우 rel=canonical을 사용하세요. 태그는 방문자의 주소를 변경하거나 다른 경로를 제거하지 않습니다. 대상은 성공 응답이어야 하며, 다른 곳으로 리디렉트되거나 다시 canonicalize하지 않아야 합니다.
레거시 HTTP URL을 최종 HTTPS URL로 바로 보내고 그 HTTPS URL을 다른 모든 곳에서 사용하세요.
robots.txt, URL 제거 요청, noindex는 선호 중복을 표현하지 않습니다. noindex는 대신 페이지를 검색에서 차단합니다.
명확한 주석 하나만 발행하기
HTML의 경우 head에 절대 rel=canonical 주석을 한 개만 넣으세요. CMS 설정뿐 아니라 전달된 소스(delivered source)를 검토하세요: 테마, 플러그인, 엣지 규칙, 또는 JavaScript가 값을 대체할 수 있습니다. Google은 HTML 소스에 제공하고 JavaScript가 이를 변경하지 않도록 권고합니다.
PDF 같은 비 HTML 문서에는 적절할 경우 HTTP Link 응답 헤더에 canonical을 사용하세요. HTML과 헤더 값이 충돌하지 않도록 주의하세요. 대상은 접근 가능해야 하고 4xx 응답이 아니어야 하며 리디렉트되거나 연쇄된 URL이어서는 안 됩니다.
리소스당 하나의 canonical 대상만 발행하세요; 다중 대상은 선호가 불분명해집니다.
템플릿, CDN, CMS, 또는 라우팅 변경 후 샘플 페이지와 헤더를 가져와 최종 대상을 확인하세요.
보조 신호들을 일치시키기
네비게이션, 브레드크럼, 본문 링크, 생성된 피드에서 내부적으로 선호 URL로 연결하세요. 검색에 보여주고 싶은 URL만 사이트맵에 넣으세요. 사이트맵 포함은 약한 신호이지만 리디렉트 및 주석과 일치할 때 선택을 보강합니다.
사이트맵 URL은 canonical과 동일한 호스트, 프로토콜, 슬래시 스타일을 사용해 완전한 자격을 갖춘(fully qualified) URL로 생성하세요. 리디렉트되는 중복과 매개변수화된 중복을 제거하세요. 퍼머링크, 도메인, 언어, 전자상거래 변경 후 자동 생성된 사이트맵을 테스트하세요.
추적, 레거시, 또는 대체 호스트 URL에 대한 링크를 선택한 canonical로 교체하세요.
HTTPS 리디렉트, canonical 대상, 사이트맵, 링크를 일관되게 유지하세요; 인증서 문제나 HTTPS→HTTP 오류는 상충 신호를 발생시킵니다.
목적별로 매개변수, 페이지네이션, 언어 처리하기
매개변수는 자동으로 중복이 아닙니다. 분석 매개변수는 콘텐츠를 변경하지 않을 수 있지만 필터와 정렬은 결과 집합을 변경할 수 있습니다. 대표 조합들을 테스트하세요. 카트, 로그인, 동의, 구성에 필요한 매개변수는 보존하세요; canonical은 방문자 흐름을 깨뜨리면 안 됩니다.
모든 페이지를 무조건 1페이지로 canonicalize하지 마세요: 이후 페이지는 보통 1페이지에 없는 콘텐츠를 포함합니다. 언어 또는 국가별 URL의 경우 같은 언어 페이지가 존재하면 그 페이지를 canonical로 지정하고 대체 버전에는 hreflang을 사용하세요. canonical은 현지화 설계를 대체하지 않습니다.
어떤 필터가 별도의 랜딩 페이지인지, 어떤 것이 중복된 재정렬인지 문서화해 제품·엔지니어링 변경 시 정렬을 유지하세요.
실제 사용 가능한 콘텐츠의 상위집합일 때만 하나를 사용하세요; 선택 전에 로드와 내비게이션을 테스트하세요.
색인된 증거와 실시간 증거로 충돌 디버그하기
Search Console에서 영향을 받는 URL을 검사하고 Google이 색인한(선택한) canonical과 사용자가 선언한 값을 비교하세요. 후보 대상도 검사하세요. 색인 보고서는 Google이 마지막으로 처리한 내용을 반영합니다; 실시간 테스트는 현재의 fetch, 렌더링된 페이지, 헤더 및 리소스를 보여주지만 최종 canonical 선택을 예측하지는 못합니다.
값이 다르면 Google이 더 나은 대표를 선택했는지 고려하세요. 그렇지 않다면 리디렉트, HTML 및 HTTP-헤더 주석, 렌더링된 출력, 링크, 사이트맵 항목, hreflang, 콘텐츠 유사성을 추적하세요. 불일치를 수정하고 변경을 기록한 뒤 재평가 시간을 주세요.
템플릿, 헤더, 호스트 라우팅, 보안 변경을 확인하세요. 설명할 수 없는 교차 도메인 canonical이나 리디렉트는 보안 조사를 요구합니다.
전달된 소스와 헤더를 CMS 설정과 비교하세요; 플러그인 또는 플랫폼 규칙이 다른 값을 내보낼 수 있습니다.
SIU (Status Is UP) 릴리스 하드닝에 정규화 검사 추가하기
도메인, HTTPS, CDN, CMS, 템플릿, 또는 카탈로그 릴리스 전에 홈페이지, 콘텐츠·제품 페이지, 매개변수 경로, 로케일, 레거시 URL, 게시 문서 등 샘플을 추출하세요. 상태, 최종 URL, canonical 대상, 사이트맵 포함 여부, 내부 링크 예시를 기록하세요.
수정을 되돌릴 수 있도록 하세요: 현재 매핑을 캡처하고 규칙 세트를 하나씩 변경하며 영향을 받는 경로를 검증하고 롤백 계획을 유지하세요. 이는 변경 시 안정적인 공개 경로를 보호해 사전 대응적 가동시간 최적화를 지원합니다; 장애 감지나 색인을 보장하지는 않습니다.
마케팅과 엔지니어링 간에 canonical 규칙을 할당하고 각 업데이트 뒤에 있는 템플릿, 리디렉션, 사이트맵, 또는 플랫폼 변경을 로그로 남기세요.
릴리스 티켓에 소규모의 변경 전후 URL과 헤더 샘플을 첨부해 빠른 복구를 가능하게 하세요.