구글 중복 페이지 처리 방식: 클러스터링과 캐노니컬, 오류 페이지 블랙홀

중복 페이지는 페널티 대상이 아닙니다. 정리가 필요할 뿐이고, 중복 주소가 너무 많으면 구글봇의 크롤링이 늦어질 수 있습니다. 저는 중복 페이지는 페널티를 받는다고 알고 있었습니다.

마틴 스플릿의 SEO Made Easy 중복 콘텐츠 편(2024년 11월12일)과 구글 검색팀 팟캐스트 87회(2024년 12월 5일)의 설명을 함께 정리했습니다. 87회에는 구글 중복 처리 팀의 앨런 스콧이 나왔습니다.

결론: 중복 콘텐츠는 페널티가 아니라 정리할 일이다

마틴 스플릿은 중복 콘텐츠가 구글의 사이트 품질 평가에 영향을 주지 않는다고 못 박았습니다. 다만 불편이 세 가지 생깁니다. 페이지 성과를 추적하기 어렵고, 비슷한 페이지끼리 경쟁합니다. 규모가 크면 크롤링도 늦어질 수 있어 정리할 만하다고 했습니다.

저는 기사가 매일 쌓이는 언론사라면 세 번째가 가장 큰 문제라고 봅니다. 같은 기사가 모바일 주소나 파라미터가 붙은 주소로 여러 개 생기면 구글봇이 같은 내용을 여러 번 가져가게 됩니다. 그만큼 새 기사를 가져가는 일이 밀릴 수 있습니다.

서치 콘솔의 ‘사용자가 선택한 표준이 없는 중복 페이지’나 ‘중복 페이지, Google에서 사용자와 다른 표준 URL을 선택함’도 문제가 아닙니다. 같은 내용을 다른 주소로 색인했다는 뜻이라 콘텐츠는 검색에 있습니다.

• 대표 주소 지정 : HTML의 canonical 태그나 HTTP 헤더로 알립니다. 구글은 이를 힌트로만 봅니다.
• 링크와 리디렉션 정리 : 내부 링크를 대표 주소로 바꾸고, 외부 링크로 들어오는 주소는 301로 넘깁니다.
• 비슷한 페이지 합치기 : 중복 판정이 아니어도 합치면 찾기 쉽고 서치 콘솔 보고서도 깔끔해집니다.

중복을 정리할 때 맞출 신호: 한 방향으로, 오류는 오류 코드로

앨런 스콧은 캐노니컬 문제로 들어오는 신고 대부분이 사실은 클러스터링 문제라고 했습니다. 서로 다른 페이지가 한 묶음에 들어간 것이 먼저 잘못됐다는 뜻입니다. 정리할 때 맞출 것은 두 가지로 모입니다.

상황	구글의 처리	운영자가 할 일
301과 rel=canonical이 서로 다른 주소	강한 신호끼리 부딪혀 사이트맵 같은 약한 신호로 결정	리디렉션, canonical, 사이트맵을 같은 주소로
200으로 응답하는 오류 페이지	내용이 같아 한 묶음으로 뭉침(블랙홀)	404, 403, 503 같은 오류 코드로 응답
메뉴 같은 틀만 번역한 언어판	한 묶음으로 합침	본문까지 번역해야 따로 검색됨
본문 전체를 번역한 언어판	서로 다른 묶음	hreflang으로 연결
빈 rel=canonical	사이트 첫 페이지(/)로 해석될 수 있음	템플릿 점검

저는 언론사도 이 블랙홀과 무관하지 않다고 봅니다. 삭제한 기사에 ‘없는 기사입니다’ 문구만 보여 주며 200으로 응답하는 경우가 그렇습니다. 봇 차단 화면이 검색엔진에 보일 때도 같은 일이 생길 수 있습니다.

앨런 스콧이 답한 중복 페이지 질문

클러스터링과 캐노니컬 선택은 무엇이 다른가요?

클러스터링은 같다고 보는 페이지를 한 묶음으로 모으는 일입니다. 캐노니컬 선택은 그 묶음에서 검색에 보여 줄 가장 좋은 주소를 고르는 일입니다. rel=canonical은 두 단계에 모두 쓰이는 신호입니다.

캐노니컬 신호는 몇 개인가요?

때마다 오르내리지만 40개 안팎이라고 했습니다. HTTP와 HTTPS를 가리는 기준도 여럿입니다. 원칙은 HTTPS로 보여 준 페이지가 실제로 안전해야 한다는 것입니다. HTTP를 거쳐 다른 HTTPS로 넘어가는 리디렉션이면 HTTP 주소가 대표로 뽑힐 수 있습니다.

‘짧은 주소로 리디렉션’이라는 기준은 HTTP와 HTTPS 판단을 흐려 없앴다고 했습니다. 글자 하나 차이로 HTTP 쪽이 유리해졌기 때문입니다.

신호가 서로 다르면 어떻게 되나요?

301 리디렉션과 rel=canonical이 서로 다른 주소를 가리키는 경우가 가장 흔합니다. 강한 신호끼리 부딪히면 사이트맵이나 페이지랭크 같은 약한 신호로 결정합니다. 사람도 정답을 알 수 없는 상황이라 시스템도 판단하지 못한다는 설명입니다.

언어판과 나라별 페이지는 어떻게 묶이나요?

메뉴 같은 틀만 번역한 페이지는 한 묶음으로 합쳐 신호를 모으고, 언어별로 다 크롤링하지 않습니다. 본문 전체를 번역한 페이지는 다른 검색어에 걸리므로 따로 둡니다. 가격만 다른 나라별 페이지도 따로 두려 하지만 가장 어려운 경우라고 했습니다.

hreflang은 별도 시스템으로 검색 결과의 주소를 나라와 언어에 맞게 바꿔 줍니다. 앨런 스콧은 사이트의 hreflang을 얼마나 믿을지 검증해 더 많이 쓰는 작업이 진행 중이라고 했습니다(2024년 12월 기준).

x-default도 신호인가요?

그렇습니다. x-default는 묶음을 만드는 데가 아니라 대표 주소를 고르는 데 쓰입니다. 쓰는 사이트는 대체로 잘 쓰지만 더 많이 썼으면 좋겠다고 했습니다. 구글의 중복 URL 통합 문서는 hreflang을 신호로 다루지만 x-default는 아직 없습니다(2026년 10월 확인).

오류 페이지는 왜 블랙홀이 되나요?

200으로 응답한 오류 페이지는 내용이 같아 한 묶음으로 뭉칩니다. 크롤러는 중복으로 판정된 페이지를 다시 크롤링하려 하지 않아 빠져나오기 어렵습니다. 99.9%로 안정적인 사이트도 천 번에 한 번은 오류를 냅니다. 자바스크립트 파일을 못 받아 렌더링이 깨지거나, CDN의 봇 차단 화면이 구글봇에 보일 때도 생깁니다.

블랙홀은 어떻게 피하나요?

404, 403, 503처럼 맞는 상태 코드를 보내면 됩니다. 묶음에 들어가는 것은 200으로 응답한 페이지뿐입니다. 상태 코드를 바꿀 수 없는 자바스크립트 앱이라면 누가 봐도 오류인 문구를 보여 줍니다. 마틴 스플릿이 권한 대로 404를 돌려주는 주소로 자바스크립트 리디렉션해도 됩니다. 구글의 자바스크립트 SEO 기본 문서에도 같은 방법이 있습니다.

일시적인 오류에는 noindex를 쓰지 말라고 했습니다. 오류 코드는 색인에서 빼기 전에 유예 기간을 주지만, noindex는 바로 뺍니다.

잘못 묶인 뒤 rel=canonical을 고치면 바로 풀리나요?

언제 다시 크롤링할지는 크롤링 팀이 정합니다. rel=canonical이 가리키는 주소는 크롤링 팀에 신호로 전달합니다. 하지만 이미 묶인 페이지를 다시 살피는 코드는 따로 없다고 했습니다. 다시 크롤링하기 전에는 바뀐 신호를 알 수 없기 때문입니다.

rel=canonical에서 본 이상한 사례는 무엇인가요?

스크립트가 변수를 채우지 못해 모든 canonical이 ‘사이트주소/$변수명’을 가리킨 경우가 있었습니다. 칸을 비워 두면 사이트 첫 페이지(/)로 해석될 수 있어, 사이트 전체를 지워 달라는 말과 같다고 했습니다. 구글이 잘못된 canonical을 걸러 내는 장치는 있지만 완벽하지 않습니다.

참고한 자료

• Search Off the Record – Handling Dupes – Same Same or Different? (87회)
• Google 검색 센터 – HTTP 상태 코드, 네트워크 및 DNS 오류
• 서치 콘솔 고객센터 – 페이지 색인 생성 보고서