canonical 태그 하나로 사이트 전체가 검색에서 빠지는 원리와 회복 기간

결론부터: canonical이 홈으로 고정되면 생기는 일

결론부터 말씀드립니다. 사이트의 모든 페이지가 canonical(대표 주소 표식)로 홈 주소를 가리키면, Google은 나머지 페이지를 홈의 '복사본'으로 판단해 검색 결과에서 뺄 수 있습니다. canonical은 명령이 아니라 힌트라서 반드시 그렇게 된다고 단정할 수는 없지만, 실제로 그렇게 처리된 사례가 있습니다. 이 글에서는 복사본 판정의 원리, Search Console(구글 검색 관리 도구)로 확인하는 순서, 고친 뒤 회복까지 걸리는 기간의 현실적인 범위를 정리합니다.

저희가 이 주제를 기록하게 된 계기는 한 사이트의 점검이었습니다. 진료 안내, 의료진 소개, 칼럼 등 성격이 전혀 다른 페이지가 여러 개 있었는데, 페이지 소스를 열어 보니 모든 페이지의 canonical 값이 똑같이 홈 주소로 적혀 있었습니다. 검색에서 사이트 이름으로 찾으면 홈은 잘 나왔지만, 개별 칼럼이나 진료 안내 페이지는 좀처럼 보이지 않았습니다. 운영자분은 콘텐츠가 부족해서라고 생각하고 글을 더 쓰고 계셨습니다. 문제는 글이 아니라 머리말(head) 영역의 태그 한 줄이었습니다.

비슷한 공개 기록도 있습니다. 한 개발 블로그는 GitHub 이슈 기록에 Search Console 실측 결과 클릭의 93%가 글 1개에 몰렸고, 14개 URL이 '발견됨 - 색인 안 됨' 상태였다고 남겼습니다. 원인은 목록 페이지(/?page=N)의 canonical이 홈을 가리켜, 2페이지 이후 글로 가는 경로가 sitemap(사이트 지도 파일) 말고는 없었던 것이었습니다.

정리하면, 이 문제는 콘텐츠 품질 문제처럼 보이지만 실제로는 '이 페이지의 원본은 홈입니다'라는 잘못된 신고가 사이트 전체에 반복된 상태입니다.

업계 분석 중에는 모든 것을 홈으로 canonical 하는 경우가 가장 피해가 크고 거의 항상 실수로 생기며, 보통 플러그인이나 테마 설정 오류가 원인이라고 보는 글도 있습니다(WebYes). 다만 이는 업계의 관찰이며 Google이 공식으로 확인한 표현은 아니라는 점을 함께 적어 둡니다.

Google은 어떤 기준으로 '복사본'을 판정하나

Google 공식 문서에 따르면 사이트에 중복 콘텐츠가 있으면 Google이 그중 하나를 canonical URL(대표로 색인할 주소)로 고릅니다. 사이트 운영자가 rel=canonical을 쓰는 이유는 여러 URL에 흩어진 신호, 예컨대 외부 링크 같은 평가 요소를 하나의 선호 URL로 모으기 위해서입니다(Google 검색 센터: 중복 URL 통합).

여기서 중요한 점은 canonical이 '명령'이 아니라 '힌트'라는 것입니다. 같은 문서는 리디렉션(자동 이동)과 rel=canonical을 강한 신호로, 사이트맵 등재를 약한 신호로 구분하면서도 어느 방법도 Google의 선택을 강제하지는 못한다고 설명합니다. 공식 트러블슈팅 문서도 canonical을 명시해도 콘텐츠 품질이나 기술 신호 때문에 Google이 다른 canonical을 고를 수 있다고 적고 있습니다.

그렇다면 왜 힌트에 불과한 태그가 사이트 전체를 흔들 수 있을까요. 이유는 rel=canonical이 '강한' 신호이기 때문입니다. 모든 페이지가 일관되게 홈을 가리키면, Google 입장에서는 운영자가 일부러 홈 하나만 대표로 삼겠다고 선언한 것으로 읽을 여지가 생깁니다. Google은 2013년 글 5 common mistakes with rel=canonical에서 2페이지 이후 목록이 1페이지를 canonical로 가리키는 것을 잘못된 사용으로 들며, 그러면 2페이지 이후 콘텐츠가 아예 색인되지 않을 수 있다고 했습니다. '모든 페이지 → 홈' 상황에 가장 가까운 공식 근거입니다.

한편 Google이 서로 내용이 다른 페이지의 홈 canonical을 '무시'하는지, 그대로 따르는지에 대한 명확한 공식 설명은 저희가 확인하지 못했습니다. 그래서 '태그 하나로 반드시 사라진다'가 아니라 '사라질 수 있고, 그런 사례가 있다'고 쓰는 것이 정확합니다.

왜 모든 페이지의 canonical이 홈을 가리키게 되나요?

운영자가 일부러 홈을 canonical로 거는 경우는 거의 없습니다. 대부분은 사이트를 만든 도구나 템플릿(디자인 틀)의 설정에서 생깁니다. 저희가 보아 온 유형과 공식 문서에 나온 유형을 묶으면 다음과 같습니다.

1. 테마·플러그인 기본값 오류: canonical 값이 '현재 페이지 주소'가 아니라 '사이트 기본 주소'로 채워지는 설정입니다. 앞서 소개한 업계 분석도 플러그인이나 테마 설정 오류를 주된 원인으로 꼽습니다.
2. 템플릿 복사: Google 2013년 글에는 사이트 소유자의 페이지들이 템플릿 제작자의 사이트를 canonical로 가리키게 된 사례가 소개돼 있습니다. 홈페이지 제작 시 시안 사이트의 head 영역을 그대로 가져오면 비슷한 일이 생깁니다.
3. 목록 페이지 처리: 게시판의 2페이지, 3페이지가 1페이지나 홈을 가리키게 만든 경우입니다. 앞의 공개 사례가 여기에 해당합니다.
4. JavaScript로 덮어쓰기: 원본 HTML에는 홈 canonical이 들어 있고, 화면이 그려진 뒤 JavaScript가 올바른 주소로 바꾸는 구조입니다. 화면에서는 정상으로 보여도 검색엔진이 원본 단계에서 먼저 홈을 읽을 수 있습니다.

4번은 최근 문서 변경과도 관련이 있습니다. 업계 매체 PPC Land에 따르면 Google은 2025년 12월 17일 JavaScript 관련 문서에 canonical 모범 사례를 추가했습니다. 핵심은 canonical 판정이 렌더링(화면 그리기) 전과 후에 모두 일어나므로 canonical URL을 최대한 분명하게 해야 한다는 것입니다. 원본 HTML과 렌더링 후 값이 서로 다르면 그 자체가 혼란 신호가 됩니다.

또 하나 흔한 실수는 신호끼리 어긋나는 것입니다. Google 공식 문서는 한 페이지에 대해 기법마다 다른 URL을 지정하지 말라고 합니다. 예를 들어 사이트맵에는 칼럼 주소를 올려 두고 canonical은 홈으로 걸어 두면, 약한 신호와 강한 신호가 반대를 말하는 셈입니다. 2013년 글은 canonical 선언이 한 페이지에 여러 개 있으면 Google이 그 힌트를 모두 무시할 가능성이 크다고도 적었습니다. 플러그인 두 개가 각각 canonical을 출력하는 사이트에서 자주 보이는 상태입니다.

내 사이트도 그런지 확인하는 진단 순서

진단은 어렵지 않습니다. 개발 지식이 없어도 아래 순서로 대부분 확인할 수 있습니다. 저희가 점검할 때도 같은 순서를 씁니다.

1. 원본 HTML 확인: 브라우저에서 페이지 소스 보기를 열고 rel='canonical'을 검색합니다. 홈이 아닌 페이지 서너 개를 골라, canonical 값이 각자 자기 주소인지 확인합니다. 모두 홈 주소라면 거의 확실한 신호입니다.
2. 개수 확인: 같은 페이지에 canonical 줄이 두 개 이상 있는지 봅니다. 여러 개면 Google이 모두 무시할 수 있습니다.
3. 렌더링된 HTML 확인: Search Console의 URL 검사 도구에서 '크롤링된 페이지 보기'로 렌더링된 HTML을 확인합니다. 업계 매체 PPC Land도 이 방법으로 초기 HTML과 JavaScript 실행 후 상태의 차이를 찾을 수 있다고 설명합니다.
4. Google이 고른 canonical 확인: 같은 URL 검사 결과에서 '사용자가 선언한 표준'과 'Google이 선택한 표준'을 비교합니다.
5. 색인 보고서 확인: 색인 생성 > 페이지 메뉴에서 색인되지 않은 이유 목록을 봅니다.

5번에서 자주 마주치는 상태 이름과 의미는 다음과 같습니다.

첫 번째 상태의 의미는 Onely의 해설을 참고했습니다. 주의할 점은 이 상태가 곧 오류는 아니라는 것입니다. 인쇄용 페이지나 정렬 옵션이 붙은 주소처럼 의도한 중복이라면 정상입니다. 반대로 진료 안내, 칼럼 같은 핵심 페이지가 이 목록에 홈을 대상으로 올라와 있다면 문제입니다. 상태 이름보다 '무엇을 가리키는가'를 보시면 됩니다.

canonical을 고치면 검색 회복까지 얼마나 걸리나요?

가장 많이 받는 질문입니다. 솔직한 답은 '사이트 규모와 신호 상태에 따라 다르다'입니다. 다만 참고할 수 있는 기준은 몇 가지 있습니다.

첫 줄은 2026년 7월 Google 트러블슈팅 문서에 추가된 내용으로, 업데이트 날짜는 Digital Applied 등에서 2026년 7월 10일로 보도됐습니다. 문서는 문제를 고친 뒤에도 Google이 페이지를 최대 2주 동안 중복 클러스터에 둘 수 있으며, URL 검사의 '색인 생성 요청'으로 재평가를 요청할 수 있지만 할당량이 있으니 가장 중요한 URL에만 쓰라고 안내합니다.

여기서 오해하기 쉬운 점이 있습니다. '최대 2주'는 개별 페이지의 중복 판정 재평가에 관한 기준이지, 사이트 전체 회복 기한이 아닙니다. 모든 페이지가 홈을 가리키던 사이트라면 Google이 각 페이지를 다시 방문해야 하는데, Binatec Agency가 정리한 Illyes 발표 메모에는 이미 알려진 URL 재크롤링에 약 30일이 걸린다고 돼 있습니다. 이 표는 참석자 메모가 출처이며 Google 공식 문서로는 확인하지 못했습니다. 또 Mueller는 큰 사이트일수록 알고리즘이 사이트 변경에 맞춰지는 데 오래 걸리고 다시 크롤링·색인·처리하는 데 몇 달이 걸릴 수 있다고 말했습니다(Search Engine Roundtable).

사이트 전체 홈 canonical 오류를 고친 뒤 트래픽과 색인 수가 어떤 곡선으로 회복되는지 보여 주는 공개 데이터는 찾지 못했습니다. 그래서 저희는 고객께 '2주 안에 돌아온다'고 말씀드리지 않고, 첫 2주는 핵심 URL의 판정 변화를, 이후 한두 달은 색인 수 추이를 보자고 말씀드립니다. 네이버·Bing의 처리 방식과 기간은 이번에 확인하지 못했으며, 네이버는 서치어드바이저 공식 문서를 따로 보시길 권합니다.

수정 순서와 재발 방지 체크리스트

원인을 찾았다면 고치는 순서가 중요합니다. 급한 마음에 여러 설정을 동시에 바꾸면 무엇이 효과를 냈는지 알 수 없고, 신호가 더 엉킬 수 있습니다. 저희는 다음 순서를 권합니다.

1. canonical 출처 하나로 정리: 테마와 SEO 플러그인이 동시에 canonical을 출력한다면 한쪽을 끕니다. 한 페이지에 선언은 하나만 남깁니다.
2. 자기 참조로 수정: 각 페이지의 canonical이 자기 자신의 정식 주소를 가리키도록 바꿉니다. 목록 2페이지 이후도 각자 자기 주소를 쓰게 합니다.
3. 신호 일치: 사이트맵에 올린 주소, 내부 링크 주소, canonical 주소가 같은지 맞춥니다. 끝 슬래시 유무나 http·https 차이도 여기서 정리합니다.
4. 렌더링 전후 일치: JavaScript로 canonical을 바꾸는 구조라면 원본 HTML 단계부터 올바른 값이 나오도록 합니다.
5. 핵심 URL만 색인 요청: 할당량이 있으므로 진료 안내, 대표 칼럼처럼 중요한 페이지 몇 개만 URL 검사에서 요청합니다.
6. 기록하기: 수정 날짜, 바꾼 설정, 요청한 URL을 적어 두고 주 단위로 색인 보고서를 확인합니다.

공식 2013년 글이 권하는 기본 점검도 함께 보시면 좋습니다. 중복 페이지 내용의 상당 부분이 canonical 대상에도 실제로 있어야 하고, canonical 대상이 검색 결과에 대신 보이길 정말 원하는지 확인하라는 것입니다. 홈은 칼럼 본문을 담고 있지 않으니, 이 두 질문만 던져도 홈 canonical이 맞지 않다는 것이 드러납니다.

재발은 대개 사이트 개편, 테마 교체, 플러그인 업데이트 직후에 생깁니다. 그래서 개편 일정이 잡히면 오픈 전후로 canonical과 색인 보고서를 확인하는 단계를 체크리스트에 넣어 두시길 권합니다. 저희가 실제로 쓰는 점검 흐름은 진행 방식 페이지에 조사·실행·보고 단계로 정리해 두었습니다.

병원·전문직 사이트라면 페이지 문구 자체에 대한 광고 규정도 따로 살펴야 합니다. 이 글은 법률 자문이 아니며, 최신 규정은 해당 기관에서 확인하시기 바랍니다. 기술 점검이 부담스러우시면 서비스 소개를 참고하셔도 좋습니다.

자주 묻는 질문