사용자가 선택한 표준이 없는 중복 페이지 해결 방법

'사용자가 선택한 표준이 없는 중복 페이지'(Duplicate without user-selected canonical)는 Google이 어떤 URL을 다른 페이지의 사본으로 판단했고, 그 URL에서 선언된 표준 URL을 찾지 못해 검색에 보여 줄 버전을 스스로 골랐다는 뜻입니다. 표시된 URL이 추적 매개변수가 붙은 사본이나 HTTP 사본처럼 아무도 들어오지 않아야 할 변형이고 Google이 귀하가 선호하는 페이지를 골랐다면, 이는 의도된 결과이며 조치가 필요 없습니다. 고쳐야 하는 것은 Google이 검색결과에 나오기를 원하지 않는 URL을 골랐을 때, 또는 표시된 URL이 바로 순위에 올리려던 페이지일 때입니다.

Google이 설명하는 이 상태의 의미

이 상태는 페이지 색인 생성 보고서의 '페이지의 색인이 생성되지 않은 이유' 아래에 있습니다. Google의 페이지 색인 생성 보고서 문서(2026년 10월 확인)에 따르면 이 페이지는 "다른 페이지의 중복이지만 선호하는 표준 페이지를 나타내지 않습니다." 같은 항목에서 Google은 표시된 URL을 검색에 제공하지 않을 것이라고 하고, 이를 오류가 아니라 의도한 대로 작동하는 것이라고 설명하며, 2가지 해결책을 제시합니다. Google이 잘못된 URL을 골랐다면 표준 URL을 명시적으로 지정하고, 실제로 중복 페이지가 아니라면 콘텐츠를 상당히 다르게 만들라는 것입니다.

'중복'은 Google이 비슷한 페이지를 하나의 클러스터로 묶은 뒤 내린 판단입니다. '사용자가 선택한 표준이 없는'은 표시된 URL이 Google이 읽을 수 있는 표준 URL을 하나도 제공하지 않았다는 뜻이며, 이 점이 이 상태를 인접한 2가지 상태와 구별합니다.

Google의 표준화 문서는 선언된 표준 URL이 "규칙이 아니라 힌트"라고 덧붙입니다. Google은 결정하기 전에 리디렉션, 사이트맵 항목, HTTPS 여부도 함께 따집니다.

중복 URL은 어디서 생기는가

표시된 URL은 거의 모두 하나의 페이지가 여러 주소로 접근 가능한 경우입니다. Google의 URL 구조 문서는 Google의 URL 처리가 대소문자를 구분한다고 밝히며, 후행 슬래시에 관한 Google 검색 센터 블로그 글(2010년 4월)은 Google이 /shoes와 /shoes/를 2개의 별개 URL로 취급한다고 설명합니다(사이트 루트는 예외). 아래의 차이 하나하나가 같은 콘텐츠에 새 URL을 만듭니다.

• 선호하는 페이지에 표준 태그가 없음. 페이지가 표준 URL을 선언하지 않으면 그 변형들에도 표준 URL이 없으므로, Google이 찾는 모든 사본이 이 상태에 들어옵니다. 예를 들어 WordPress 코어는 개별 글과 페이지에만 표준 태그를 출력하며, 아카이브, 카테고리, 태그, 블로그 홈 화면에는 테마나 플러그인이 추가하지 않는 한 표준 태그가 없습니다.
• 프로토콜 및 호스트 변형. http://와 https://, 또는 www와 루트 도메인이 하나의 주소로 리디렉션되지 않고 모두 상태 200으로 응답하는 경우입니다.
• 후행 슬래시와 대소문자. /shoes, /shoes/, /Shoes/가 같은 페이지를 제공하는 경우입니다.
• 매개변수와 대체 보기. ?utm_source= 같은 추적 태그, 정렬·필터 옵션, 세션 ID, 같은 콘텐츠의 인쇄용 보기나 그리드 보기입니다.
• 실수로 생긴 사본. Google 문서가 원인으로 꼽는, 크롤러에 열려 있는 사이트 데모 버전, 스테이징 호스트, 여전히 같은 페이지를 제공하는 옛 도메인입니다.
• Google이 읽을 수 없는 표준 태그. Google은 <head> 안의 rel="canonical"만 인정하며, 페이지 메타데이터 문서에 따르면 iframe이나 img 같은 유효하지 않은 요소가 head 안에 있으면 Google은 head가 끝났다고 보고 그 뒤의 내용을 무시합니다. 그런 요소 뒤에 놓인 표준 태그는 사실상 없는 것과 같습니다.
• 귀하가 별개라고 생각하는 페이지. 설명이 똑같은 제품 색상별 페이지, 도시 이름을 빼면 모든 문장이 같은 지점 페이지입니다.

2026년 5월부터 10월 사이에 SEOReport가 감사한 외부 웹사이트 45곳 중 14곳(31%)은 서버가 반환한 HTML에 표준 태그가 없는 홈페이지를 제공했고, 1곳은 표준 태그가 2개 이상이었습니다. 같은 표본에서 45곳 중 2곳(4%)은 HTTP를 HTTPS로 리디렉션하지 않았습니다.

문제인가요? 고칠지, 둘지, 지켜볼지

판단은 Google이 어떤 URL을 선택했는지, 그리고 표시된 URL이 검색에 나오기를 원하는지에 달려 있습니다.

flowchart TD
    A["표시된 URL: 사용자가 선택한 표준이 없는 중복 페이지"] --> B["URL 검사에서 Google이 선택한 표준 URL 확인"]
    B --> C{"Google이 고른 URL이 검색에 나오기를 원하는 URL인가요?"}
    C -->|예| D{"링크나 사이트맵이 표시된 URL을 가리키나요?"}
    D -->|아니요| E["그대로 둠: 사본이 의도대로 걸러지고 있음"]
    D -->|예| F["링크와 사이트맵이 선호하는 URL을 가리키도록 수정"]
    C -->|아니요| G{"콘텐츠가 정말 같은가요?"}
    G -->|아니요| H["페이지 내용을 상당히 다르게 만들기"]
    G -->|예| I["선호하는 URL을 선언: 표준 태그, 리디렉션, 링크, 사이트맵"]
    F --> J["실시간 URL 테스트 후 수정 결과 확인"]
    H --> J
    I --> J

어떤 원인인지 확인하는 방법

1. 예시를 패턴별로 묶습니다. 예시 표는 최대 1,000행까지만 보여 주며 영향을 받은 URL을 모두 나열하지 않을 수 있으므로, 개수를 세기보다 패턴(모두 http://, 모두 ?utm_, 모두 대문자)을 찾으십시오.
2. 표시된 URL을 검사합니다. URL 검사에서 '사용자가 선언한 표준 URL'과 'Google이 선택한 표준 URL'을 비교합니다. 이 상태에서는 색인된 결과의 사용자가 선언한 표준 URL이 대개 '없음'으로 표시됩니다. '실시간 URL 테스트'에서 지금은 표준 URL이 보인다면, 그 URL을 Google이 마지막으로 크롤링한 뒤에 추가된 것입니다.
3. 2개의 URL을 한 글자씩 비교합니다. 프로토콜, 호스트, 대소문자, 후행 슬래시, 매개변수를 봅니다. 차이가 곧 원인입니다.
4. Google이 변형을 어디서 만났는지 찾습니다. 검사 결과의 '참조 페이지'는 Google이 그 URL을 발견하는 데 사용했을 수 있는 페이지를, '사이트맵'은 그 URL이 들어 있는 사이트맵을 보여 줍니다.
5. 크롤러처럼 변형을 직접 가져옵니다. 브라우저는 리디렉션을 숨기지만 원본 응답은 숨기지 않습니다.

# Status code and redirect target for each variant of one page
for u in http://example.com/shoes/ https://example.com/shoes/ \
         https://www.example.com/shoes https://www.example.com/Shoes/ \
         "https://www.example.com/shoes/?utm_source=newsletter"; do
  curl -s -o /dev/null -w "%{http_code} -> %{redirect_url}  $u\n" "$u"
done

# The canonical tag in the HTML the server returns, before any JavaScript runs
curl -s https://www.example.com/shoes/ | grep -io '<link[^>]*canonical[^>]*>'

모든 변형은 선호하는 URL로 301 응답을 하거나, 그 URL을 가리키는 표준 태그와 함께 200으로 응답해야 합니다. 표준 태그 없이 200으로 응답하는 변형은 계속 이 상태에 들어올 수 있습니다.

원인별 해결 방법

표준 태그 누락. 색인 가능한 모든 페이지에 절대 URL로 된 자기 참조 표준 태그를 넣되, 서버가 보내는 HTML의 <head> 앞부분에 둡니다. Google 문서는 자기 참조 방식과 절대 URL을 모두 권장합니다.

<head>
  <meta charset="utf-8">
  <link rel="canonical" href="https://www.example.com/shoes/">
  <title>Trail running shoes</title>
</head>

표준 URL은 요청된 URL이 아니라 페이지 자체의 선호 주소로 만들어야 합니다. 요청 URL을 그대로 출력하는 템플릿은 /shoes/?utm_source=newsletter를 자기 자신의 표준 URL로 만들어 버리며, 그러면 변형이 하나로 통합되지 않고 '중복 페이지, Google에서 사용자와 다른 표준 URL을 선택함'으로 옮겨 갈 수 있습니다.

프로토콜 및 호스트 변형. 경로와 쿼리 문자열을 유지하는 301 하나로 모든 변형을 리디렉션합니다. nginx에서 HTTP 쪽은 다음과 같으며, HTTPS 루트 도메인 서버 블록에도 같은 return 줄을 넣으십시오.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

Google은 유효하지 않은 인증서나 HTTPS에서 HTTP로 되돌아가는 리디렉션처럼 충돌하는 요소가 없다면 HTTPS 페이지를 표준 URL로 선호합니다. 각 변형은 한 번에 최종 주소로 보내십시오. 프로토콜, 호스트, 슬래시 규칙을 따로따로 추가하면 어떻게 체인으로 쌓이는지는 리디렉션 체인 가이드에서 보여 줍니다.

후행 슬래시와 대소문자. 한 가지 형식을 정하고 다른 형식은 그쪽으로 301 리디렉션하며, CMS가 그 형식으로 링크를 생성하도록 합니다. Google의 URL 가이드는 대소문자를 한 가지로 통일하라고 권장합니다.

매개변수와 대체 보기. 깔끔한 URL에 올바른 자기 참조 표준 태그가 있으면 추적 매개변수 문제는 해결됩니다. 태그가 붙은 모든 사본이 깔끔한 페이지를 가리키게 되기 때문입니다. 매개변수 URL로 내부 링크하지 말고, 세션 ID는 쿠키로 옮기고, 인쇄용 보기와 대체 보기에는 기본 페이지를 가리키는 표준 태그를 넣으십시오. robots.txt로 중복 페이지를 숨기지 마십시오. Google에 따르면 차단된 URL도 콘텐츠 없이 색인될 수 있고, Google은 가져올 수 없는 페이지의 표준 태그를 읽을 수 없습니다. Google은 또한 사이트 안에서 표준 URL을 정하는 데 noindex를 쓰지 말라고 권하며, URL 삭제 도구는 URL의 모든 버전을 숨깁니다.

실수로 생긴 사본. 스테이징 호스트는 로그인 뒤에 두고, 옛 도메인은 페이지 단위로 리디렉션합니다.

중복이 아닌 페이지. 각 페이지에 다른 페이지에 없는 콘텐츠, 즉 사양, 재고 여부, 지역 정보를 넣습니다. Google의 문제 해결 문서에 따르면 변경 후에도 최대 2주 동안 페이지가 중복 클러스터에 남아 있을 수 있습니다.

모든 신호를 맞춥니다. XML 사이트맵에는 선호하는 URL만 넣고, 내부 링크는 표준 태그가 가리키는 URL과 같은 URL로 연결합니다. Google은 사이트맵과 rel="canonical"에 서로 다른 URL을 적지 말라고 경고합니다. 그 밖의 충돌은 페이지와 어긋나는 사이트맵 분석과 표준 태그 가이드에서 다룹니다.

수정 결과를 확인하는 방법

1. 표시된 URL과 선호하는 페이지에서 '실시간 URL 테스트'를 실행합니다. 실시간 테스트는 사용자가 선언한 표준 URL을 보여 주지만, Google에 따르면 Google이 어떤 URL을 선택할지는 예측하지 못합니다.
2. 중요한 선호 페이지 몇 개에 '색인 생성 요청'을 사용합니다. 일일 한도가 있습니다.
3. 패턴의 모든 사례를 고친 뒤 해당 상태에서 '수정 결과 확인'을 클릭합니다. Google 문서에 따르면 확인에는 보통 최대 약 2주가 걸리고 때로는 훨씬 더 오래 걸리며, 남아 있는 사례가 발견되면 중단됩니다.
4. URL이 사라지기보다 다른 상태로 옮겨 갈 것으로 예상하십시오. 이제 리디렉션되는 변형은 '리디렉션이 포함된 페이지'로, Google이 받아들인 표준 태그가 있는 변형은 대개 '적절한 표준 태그가 포함된 대체 페이지'로 보고됩니다. 둘 다 사본에게는 정상적인 상태입니다.
5. 몇 주 뒤 선호하는 페이지를 다시 검사해 'Google이 선택한 표준 URL'이 귀하가 선언한 URL과 일치하는지 확인합니다.

Search Console은 Google이 어떤 URL을 사본으로 분류했는지 알려 줄 뿐, 어떤 사이트 전체 설정이 계속 사본을 만들어 내는지는 알려 주지 않습니다. SEOReport 전체 진단은 이런 사이트 전체의 원인을 외부에서 점검합니다. www와 루트 도메인이 둘 다 사이트를 제공하는 경우, HTTPS로 리디렉션되지 않는 HTTP, 사이트맵·표준 태그·hreflang URL 사이에서 섞여 있는 후행 슬래시 형식, 표준 태그가 없거나 2개 이상인 홈페이지를 확인합니다. 거의 같은 아티클도 짚어 냅니다. 매개변수 사본과 표준 태그가 없는 하위 페이지는 여전히 URL 검사와 위의 확인 방법이 필요합니다. 모든 템플릿의 변형을 확인하는 것은 사이트 전체에 걸친 작업이며, 그래서 AI 채팅 세션 하나로는 끝내기 어렵습니다.

자주 묻는 질문

이 상태가 순위에 악영향을 주나요?

Google은 이를 의도한 대로 작동하는 것이라고 하며, 어느 정도의 중복 콘텐츠는 정상입니다. 비용이 생기는 것은 Google이 검색결과에 나오기를 원하지 않는 URL을 선택할 때, 또는 크롤링 시간이 사본에 쓰일 때입니다. Google은 표준 페이지가 가장 정기적으로 크롤링되고 중복 페이지는 그보다 덜 자주 크롤링된다고 밝힙니다.

사이트에서 링크한 적 없는 URL이 왜 보고서에 나오나요?

Google은 외부 링크, 태그가 붙은 캠페인 URL, 오래된 사이트맵, 사이트의 이전 버전에서 URL을 발견합니다. 깔끔한 URL에 올바른 표준 태그가 있으면 이런 사본이 어디서 왔든 처리됩니다.

수정 후 중복 URL은 Search Console에서 사라져야 하나요?

확인 단계에서 설명했듯이 대개는 다른 상태로 계속 표시됩니다. 색인되지 않은 URL이 문제가 되는 것은 그 URL이 검색에 나오기를 원할 때뿐이며, 이는 크롤링됨 - 현재 색인이 생성되지 않음에 적용되는 기준과 같습니다.

이 상태는 다른 언어의 Search Console에서 어떻게 표시되나요?

Google의 언어별 도움말 페이지(2026년 10월 확인)에서는 독일어로 "Duplikat – vom Nutzer nicht als kanonisch festgelegt", 스페인어로 "Duplicada: el usuario no ha indicado ninguna versión canónica", 프랑스어로 "Page en double sans URL canonique sélectionnée par l'utilisateur"로 표시됩니다. 의미와 해결 방법은 모든 언어에서 동일합니다.