canonical이 뭔데 내 페이지 색인을 날렸을까 — 개념과 실제 버그 사례

안녕하세요, 천상나타입니다.

지난 글에서 제 사이트 색인 상태를 전수 검사한 이야기를 했는데요, 그 결과에서 가장 골치 아팠던 게 바로 canonical 문제였습니다. 한국어 페이지는 96% 색인됐는데 다국어 페이지는 17~32%밖에 안 됐거든요. 원인을 파고들다 보니 canonical 버그였고, 개념 정리 + 실제 사고 사례로 정리해봅니다.

canonical이 뭔가요?

같은 내용의 페이지가 여러 주소로 존재할 수 있습니다. mysite.com/page와 mysite.com/page?utm=ad처럼요. 이때 검색엔진에 "이 중에서 이 주소가 대표야"라고 알려주는 게 canonical(표준 주소)입니다.

<link rel="canonical" href="https://www.mysite.com/page">

이 선언이 왜 중요하냐면, 검색엔진은 비슷한 페이지들을 하나로 묶어서 관리해요. 표준 주소가 정해지면 나머지는 "사본" 취급이 되고, 검색 노출도 표준 주소로 몰립니다. 즉 canonical이 잘못되면 엉뚱한 주소가 대표가 되거나, 아예 색인이 안 되는 사태가 벌어져요.

핵심은 "내 선언" vs "구글의 판단"

URL 검사 결과에는 두 개의 canonical이 나옵니다.

• 사용자 선언 표준 URL (userCanonical) — 내 페이지의 link rel=canonical이 가리키는 주소
• Google이 선택한 표준 URL (googleCanonical) — 구글이 실제로 대표로 인정한 주소

이 둘이 같으면 정상이고, 다르면 뭔가 꼬인 겁니다. 구글은 선언을 무조건 따르지 않아요. 선언이 이상하거나, 신호(내부 링크·리디렉션·사이트맵)와 모순되면 자기 마음대로 표준을 골라버립니다.

실제 버그 사례: 다국어 페이지가 엉뚱한 주소를 표준으로 선언

제 사이트에서 발견된 실제 케이스입니다(도메인은 가명 처리). 다국어 지원 사이트인데, 일본어 페이지의 검사 결과가 이랬어요.

| 항목 | 값 |

|---|---|

| 검사한 URL | mysite.com/ja/text/ad-copy (일본어 페이지) |

| 사용자 선언 표준 | mysite.com/ja/ai/ad-copy ← 엉뚱한 페이지 |

| Google 선택 표준 | mysite.com/ja/text/ad-copy |

페이지가 "나는 다른 페이지의 사본이야"라고 엉뚱한 주소를 선언하고 있던 거죠. 원인은 canonical 생성 코드의 버그였습니다 — 다국어 페이지를 만들 때 경로를 잘못 조합해서 /ja/text/... 페이지가 /ja/ai/...를 표준으로 가리키게 된 거예요.

다행히 이 케이스는 구글이 "선언이 이상한데?" 하고 무시하고 실제 주소를 표준으로 골라줬습니다. 하지만 31개 URL에서 이런 불일치가 발견됐고, 구글이 선언을 그대로 믿어버린 경우엔 페이지가 사본 취급돼서 색인이 날아갔어요. 다국어 색인률이 떨어진 주범이 이거였습니다.

서치콘솔에서 확인하는 법

URL 검사 결과의 "색인생성" 섹션을 펼치면 사용자 선언 표준 URL과 Google 선택 표준 URL이 나란히 보입니다.

여기서 둘이 다르면, coverageState가 "중복 페이지, Google에서 사용자와 다른 표준을 선택함"으로 뜹니다.

• robotsTxtState — 크롤링 차단 여부 (여기선 ALLOWED)
• indexingState — noindex 여부 (INDEXING_ALLOWED면 의도적 차단 아님)
• pageFetchState — 페이지를 가져올 수 있는지
• googleCanonical / userCanonical — 위에서 본 그 두 값

canonical이 꼬이는 전형적 패턴

1. 생성 코드 버그 — 템플릿에서 URL을 잘못 조합 (제 사례)
2. 도메인 이전 — 구 주소가 신 주소를 표준으로 선언 → 의도된 통합이면 OK, 아니면 사고
3. www vs non-www — www.mysite.com과 mysite.com이 따로 놀면 구글이 임의 선택
4. 선언 없음 — 비슷한 페이지가 여러 개인데 아무 신호도 없으면 구글 마음대로
5. http/https 혼용 — 내부 링크·canonical·사이트맵이 서로 다른 스킴을 가리킴

정리

• canonical은 "이 주소가 대표입니다"라는 선언이고, 구글은 안 맞으면 무시하고 직접 고릅니다
• URL 검사에서 userCanonical ≠ googleCanonical이면 무조건 확인해야 할 신호예요
• 제 사례처럼 페이지가 엉뚱한 곳을 표준으로 선언하는 버그는 수동으론 못 찾습니다 — URL 전수 검사가 필요했던 이유예요
• 한 가지 다행인 건, 구글이 대부분 알아서 바로잡아 준다는 것. 하지만 그 "판단"에 맡기는 것보다 선언을 바로잡는 게 정석입니다

다음 글에서는 이 검사를 돌린 API 인증의 기초인 서비스 계정과 OAuth를 정리해볼게요.