www non-www 리디렉션: 두 호스트가 모두 200일 때 생기는 SEO 문제

www non-www 리디렉션이 빠진 사이트에서는 https://www.example.com/page와 https://example.com/page가 모두 같은 콘텐츠를 보여주면서 200으로 응답할 수 있습니다. 방문자는 차이를 거의 느끼지 못합니다. 서버도 요청을 정상 처리했으니 문제가 없어 보입니다.

검색엔진에는 두 개의 URL입니다. 구글은 내용이 같다고 판단하면 두 URL을 하나의 중복 그룹으로 묶고 대표 URL을 선택하지만, 그 선택을 사이트가 원하는 방향으로 보장하지는 않습니다. 외부 링크, 내부 링크, 사이트맵, canonical 선언이 서로 다른 호스트를 가리키면 검색엔진은 어느 쪽이 대표인지 계속 다시 판단해야 합니다.

www.example.com의 www는 하위 도메인이고, example.com은 흔히 non-www라고 부르는 도메인 루트입니다. 사람에게는 같은 사이트를 적는 두 방식처럼 보여도 호스트 이름은 서로 다릅니다.

이 상태를 중복 콘텐츠 페널티라고 부르는 것은 정확하지 않습니다. 실제 문제는 검색 신호를 한 URL로 모으는 과정이 불명확해지고, 같은 문서를 두 호스트에서 수집하며, 보고서와 운영 설정도 두 갈래로 나뉜다는 데 있습니다.

200 응답과 대표 URL은 다른 문제다#

HTTP Semantics 표준에서 200은 요청이 성공했다는 뜻입니다. 서버가 해당 호스트와 경로의 문서를 정상적으로 돌려주었다는 뜻일 뿐, 그 URL을 검색 결과의 대표로 사용해야 한다는 의미는 없습니다.

다음 두 요청이 모두 200이면 검색엔진은 두 문서에 접근할 수 있습니다.

request: https://www.example.com/products/a
status: 200

request: https://example.com/products/a
status: 200

본문과 주요 요소가 같다면 구글은 두 URL을 중복 그룹으로 묶고 하나를 canonical로 선택할 수 있습니다. 구글의 canonical 설명에 따르면 사이트가 선호 URL을 제시해도 구글은 여러 신호를 바탕으로 다른 URL을 선택할 수 있습니다. HTML의 canonical은 사이트의 선언이고, 구글이 선택한 canonical은 검색 시스템의 결과입니다.

따라서 점검 질문은 “두 주소에서 페이지가 열리는가”에서 끝나지 않습니다. “어느 주소가 200이어야 하고, 다른 주소는 그곳으로 영구 이동하는가”까지 확인해야 합니다.

두 호스트를 200으로 남겨둘 때 생기는 문제#

대표 URL 신호가 엇갈릴 수 있다#

가장 흔한 충돌은 두 호스트가 각각 자신을 canonical로 선언하는 상태입니다. www 페이지는 www URL을, non-www 페이지는 non-www URL을 대표라고 말합니다. 여기에 사이트맵은 www를 담고 내부 링크가 상대 경로나 non-www로 걸리면 한 콘텐츠에 대한 선호 신호가 갈립니다.

구글은 리디렉션과 rel="canonical", 사이트맵, 내부 링크 등 여러 단서를 사용해 대표 URL을 정합니다. 이 과정에서 사이트가 선택한 형식과 다른 URL이 검색 결과에 남거나, 재수집 뒤 선택이 바뀔 수 있습니다. URL 검사에서 사용자 선언 표준 URL과 Google 선택 표준 URL이 다른 이유를 태그 한 줄만으로 설명하기 어려워집니다.

링크 신호 통합을 검색엔진의 해석에 맡기게 된다#

외부 사이트가 www와 non-www에 각각 링크할 수 있습니다. 대표 URL 관계가 명확하게 처리되면 구글은 중복 URL의 링크 같은 신호를 선호 URL로 통합할 수 있습니다. 구글 canonical 가이드도 신호 통합을 canonical 지정의 이유로 설명합니다.

그러므로 “링크 가치가 정확히 절반으로 나뉜다”는 표현은 피해야 합니다. 더 정확한 문제는 사이트가 한 번에 정리할 수 있는 관계를 검색엔진의 중복 판정과 대표 선택에 맡긴다는 것입니다. 호스트별 콘텐츠나 canonical이 배포 과정에서 조금이라도 달라지면, 신호가 하나로 합쳐진다는 전제부터 흔들립니다.

같은 콘텐츠를 다시 수집하고 처리한다#

두 호스트가 전체 경로에서 200을 반환하면 크롤러가 발견할 수 있는 URL 수도 최대 두 배로 늘어납니다. 구글은 중복 페이지를 대표 페이지보다 덜 자주 수집할 수 있지만, 중복을 발견하고 비교하는 과정 자체가 먼저 필요합니다.

구글의 크롤링 가이드는 중복 콘텐츠를 정리해 고유한 URL보다 고유한 콘텐츠 수집에 집중하도록 권고합니다. 페이지가 적은 사이트에서는 이 비용이 당장 눈에 띄지 않을 수 있습니다. 상품, 필터, 언어 경로가 많은 대규모 사이트라면 호스트 중복이 기존 URL 변형과 곱해져 점검 범위를 빠르게 키웁니다.

측정과 운영에서 하나의 페이지가 두 행으로 남는다#

검색엔진이 대표 URL을 잘 선택하더라도 조직의 데이터가 자동으로 모두 합쳐지는 것은 아닙니다. 호스트를 포함해 집계하는 웹 분석과 서버 로그, CDN 캐시, 크롤 결과에서는 같은 경로가 별도 행으로 남을 수 있습니다. 사이트맵 생성기, 구조화 데이터, hreflang, 공유 URL이 서로 다른 호스트를 출력하면 수정 뒤에도 중복 URL이 다시 발견됩니다.

운영 차이도 생깁니다. 한 호스트만 새 배포를 받거나 보안 헤더, 캐시 정책, 자바스크립트 설정이 다르게 적용되면 처음에는 같았던 두 문서가 점차 달라집니다. 이때 문제는 단순한 중복을 넘어 어느 버전이 최신인지 알기 어려운 색인 상태로 바뀝니다.

canonical 태그와 리디렉션은 역할이 다르다#

canonical 태그는 접근 가능한 여러 URL을 유지해야 할 때 대표 URL을 제시하는 장치입니다. 상품 정렬 파라미터나 인쇄용 보기처럼 중복 URL을 완전히 없애기 어려운 상황에서 유용합니다. 반면 www와 non-www 가운데 하나를 사용할 이유가 없다면, 두 번째 호스트를 계속 200으로 제공할 필요도 없습니다.

구글의 canonical 신호 문서는 리디렉션과 rel="canonical"을 강한 신호로, 사이트맵 포함은 약한 신호로 구분합니다. 접근 경로를 하나로 합칠 수 있는 중복 페이지에는 영구 리디렉션을 사용할 수 있습니다.

권장 상태는 단순합니다. 다음 예시는 non-www를 남기는 경우입니다.

request: https://www.example.com/products/a?color=black
status: 308
location: https://example.com/products/a?color=black

request: https://example.com/products/a?color=black
status: 200
canonical: https://example.com/products/a?color=black

301과 308은 모두 영구 이동을 나타냅니다. 구글도 두 상태 코드를 영구 리디렉션으로 처리해 목적지 URL이 canonical이어야 한다는 신호로 사용합니다. 302와 307은 임시 이동을 위한 코드이므로, 호스트 선택을 계속 유지할 계획이라면 기본 선택으로 맞지 않습니다.

중복 호스트에 noindex를 넣거나 robots.txt로 막는 방법도 적절하지 않습니다. noindex는 해당 URL을 검색 결과에서 제외하는 지시이지 다른 URL로 신호와 사용자를 보내는 이동 규칙이 아닙니다. robots meta 태그 가이드에 따르면 robots.txt로 수집을 막은 URL에서는 크롤러가 페이지 안의 noindex를 읽을 수 없습니다. 구글의 canonical 가이드도 robots.txt를 canonical 정리 수단으로 사용하지 말라고 안내합니다.

www와 non-www 중 무엇을 남길지 결정한다#

www와 non-www 가운데 SEO 순위에 본질적으로 더 유리한 형식은 없습니다. 선택 기준은 철자가 아니라 현재 사이트가 이미 쌓은 상태와 인프라입니다.

먼저 검색 결과와 URL 검사에서 어떤 호스트가 주로 canonical로 선택되어 있는지 봅니다. 외부 링크와 자연 검색 노출이 어느 호스트에 더 많이 연결되는지도 같은 기준일로 살핍니다. canonical, 사이트맵, 내부 링크, 광고와 프로필 URL이 이미 한쪽으로 일관돼 있다면 그 형식을 유지하는 편이 변경 범위를 줄입니다.

인프라 조건도 따져야 합니다. www는 DNS와 CDN 구성을 분리하기 편한 경우가 있고, non-www는 주소가 짧다는 운영상 장점이 있습니다. 어느 쪽이든 선택할 수 있습니다. 기존 신호가 한쪽에 모여 있는데 주소 모양만 바꾸기 위해 반대쪽으로 옮기면 간단한 정리 작업이 사이트 이동에 가까운 일로 커집니다.

결정한 뒤에는 선호 호스트를 문서로 고정합니다. 배포 환경과 담당자에 따라 canonical과 사이트맵의 기본 호스트가 다시 달라지는 것을 막기 위해서입니다.

www non-www 리디렉션과 관련 신호를 함께 정렬한다#

첫째, 사용하지 않을 호스트의 HTML 경로를 선호 호스트의 같은 경로로 301 또는 308 리디렉션합니다. 경로와 필요한 쿼리 문자열을 보존하고 최종 목적지로 한 번에 보내야 합니다. www에서 non-www로 이동한 뒤 다시 HTTP에서 HTTPS로 이동하는 식의 연쇄는 피합니다.

source: http://www.example.com/category/item?id=7
final: https://example.com/category/item?id=7
redirect hops: 1

둘째, 선호 호스트의 모든 색인 대상 페이지가 자기 자신을 가리키는 절대 URL canonical을 출력하도록 합니다. 템플릿 일부가 이전 호스트를 남기거나 자바스크립트가 canonical을 바꾸지 않는지 원본 HTML에서 확인합니다.

셋째, 내부 링크와 사이트맵을 선호 호스트 기준으로 갱신합니다. 사이트맵에는 검색 결과에 남길 절대 URL만 포함합니다. 구조화 데이터의 url, @id, 이미지 URL과 다국어 사이트의 hreflang도 호스트가 일치하는지 점검합니다. 이 요소들이 모두 같은 방향을 가리킬 때 검색엔진이 대표 URL 관계를 더 빠르게 이해할 수 있습니다.

넷째, 사용하지 않는 호스트의 TLS 인증서와 리디렉션 서버는 유지합니다. HTTPS 연결은 HTTP 응답을 받기 전에 성립해야 하므로 인증서가 만료되면 리디렉션까지 도달하지 못합니다. 외부 링크와 오래된 북마크는 장기간 남습니다. 구글의 사이트 이동 가이드도 사용자 관점에서 리디렉션을 계속 유지하는 방안을 권고합니다.

배포 전후를 URL 쌍으로 검증한다#

홈페이지만 확인하면 경로 규칙의 누락을 찾기 어렵습니다. 홈페이지, 얕은 경로와 깊은 경로, 쿼리가 있는 URL, 끝 슬래시가 있는 URL과 없는 URL에서 www와 non-www를 한 쌍으로 검사합니다. 상품이나 게시물이 많은 사이트라면 템플릿별 표본을 뽑습니다.

응답은 curl로 빠르게 확인할 수 있습니다.

curl -I "https://www.example.com/products/a?color=black"
curl -I "https://example.com/products/a?color=black"

배포 직후에는 사용하지 않는 호스트가 301 또는 308을 반환하는지, Location이 같은 경로의 선호 호스트인지, 리디렉션이 한 번에 끝나는지 확인합니다. 선호 URL은 200이어야 하고 최종 HTML의 canonical도 자기 자신을 가리켜야 합니다. 존재하지 않는 경로를 모두 홈페이지로 보내는 규칙은 어느 페이지가 어디로 옮겨졌는지 알 수 없게 만들므로 피합니다.

그다음 자체 크롤 결과를 호스트, 상태 코드, canonical 기준으로 묶습니다. 사용하지 않는 호스트의 200 URL 수가 0인지, 사이트맵과 내부 링크에서 이전 호스트가 다시 발견되지 않는지 살핍니다. CDN과 애플리케이션 로그에서는 구글봇이 이전 호스트를 얼마나 다시 요청하는지 기간별로 봅니다.

서치콘솔 도메인 속성에서는 www와 non-www, HTTP와 HTTPS를 함께 볼 수 있습니다. 호스트를 비교해야 한다면 URL 접두어 속성을 별도로 추가하거나 성과 보고서의 페이지 필터를 사용합니다. 대표 URL 표본은 URL 검사에서 사이트가 선언한 canonical과 구글이 선택한 canonical을 함께 확인합니다. 수정 직후 두 값이 바로 바뀐다고 가정하지 않고, 구글이 이전 URL을 다시 수집한 뒤 같은 표본을 재검사합니다.

수정 우선순위는 영향 범위로 정한다#

두 호스트가 200인 모든 사이트가 검색 순위를 크게 잃는 것은 아닙니다. 페이지가 적고, canonical과 내부 링크가 이미 한 호스트를 일관되게 가리키며, 중복 호스트가 외부에서 거의 발견되지 않았다면 영향은 제한적일 수 있습니다. 그래도 접근 경로를 하나로 줄이면 이후 배포에서 신호가 갈라질 가능성을 없앨 수 있습니다.

반대로 두 호스트가 각각 자신을 canonical로 선언하거나 사이트맵이 섞여 있고, 호스트별 검색 노출과 외부 링크가 모두 존재한다면 우선순위를 높여야 합니다. URL 수가 많고 필터나 언어 변형까지 있는 사이트도 마찬가지입니다. 한 경로의 중복이 아니라 사이트 전체 URL 수를 배로 늘리는 설정이기 때문입니다.

해결 여부는 순위 변동 하나로 판단하지 않습니다. 사용하지 않는 호스트의 200 응답 제거, 리디렉션 목적지의 정확성, canonical과 사이트맵의 정렬, 구글이 선택한 canonical의 이동을 차례로 점검합니다. 검색 유입은 그 뒤에 관찰할 결과입니다.

www와 non-www 중 어떤 주소를 고르느냐보다 중요한 것은 한 주소만 200으로 남기는 일입니다. 서버의 영구 리디렉션과 페이지의 canonical, 내부 링크, 사이트맵이 같은 호스트를 가리키면 검색엔진은 중복 관계를 추측할 필요가 줄어듭니다. 팀도 하나의 URL을 기준으로 색인과 성과를 측정할 수 있습니다.

호스트 중복이 사이트의 다른 URL 변형과 얼마나 결합되어 있는지 확인하려면 전체 URL을 호스트, 응답 코드, canonical 기준으로 수집해야 합니다. 이 진단의 범위와 배포 후 검증 방식은 테크니컬 SEO 진단과 개선에서 확인할 수 있습니다.