검색엔진최적화 대표 주소 통일, http·www 섞인 주소 정리 순서

http와 https, www가 있는 주소와 없는 주소가 섞여 열리면 검색엔진최적화 관점에서 같은 페이지가 주소 네 개로 중복된 상태입니다. 해법은 대표 주소 통일입니다. 대표 주소 하나를 정하고, 나머지 세 조합은 서버 측 영구 리다이렉트(301 또는 308)로 같은 경로에 한 번에 보냅니다.

그다음 표준 태그·내부 링크·사이트맵을 대표 주소로 맞춥니다. 마지막으로 Search Console에서 Google이 고른 표준 주소가 대표 주소와 같은지 확인하면 정리가 끝납니다.

Google 문서는 HTTP와 HTTPS 버전을 중복 콘텐츠의 한 유형인 프로토콜 변형으로 설명합니다. Google은 내용이 같거나 매우 비슷한 페이지를 묶고, 그중 하나를 표준(canonical, 검색 결과에 대표로 쓰이는 주소)으로 선택합니다. 신호가 어긋나면 Google이 운영자의 의도와 다른 주소를 고를 수 있습니다. 따라서 리다이렉트·표준 태그·내부 링크·사이트맵이 모두 같은 주소를 가리켜야 합니다.

1단계: 대표 주소로 삼을 조합은 무엇인가요?

프로토콜은 https로 정합니다. Google 문서는 같은 내용이면 HTTP 페이지보다 HTTPS 페이지를 표준으로 선호한다고 설명합니다. 다만 문제나 상충하는 신호가 있으면 예외가 생긴다고 안내하며, 다음과 같은 경우를 듭니다.

• HTTPS 페이지의 SSL 인증서가 유효하지 않은 경우
• HTTPS 페이지가 이미지가 아닌 리소스를 보안되지 않은 방식으로 불러오는 경우
• HTTPS 페이지가 HTTP 페이지로 리다이렉트하거나 HTTP를 거쳐 이동시키는 경우
• HTTPS 페이지의 표준 태그가 HTTP 페이지를 가리키는 경우

www 유무에는 정해진 정답이 없습니다. 어느 쪽을 고를지는 운영 상황에 달려 있으므로, 실무에서는 아래 세 가지를 비교해 정하는 방법을 권합니다.

세 번째 항목이 빠지면 인증서 오류로 이어집니다. 대표가 아닌 https 주소로 들어온 요청도 보안 연결이 먼저 성립해야 리다이렉트까지 갈 수 있습니다. 인증서가 한쪽 호스트만 포함하면 다른 쪽으로 들어온 방문자와 검색 로봇은 리다이렉트 대신 인증서 오류를 받습니다.

Google 문서는 인증서가 사이트의 전체 URL과 일치해야 하며, 잘못된 인증서가 있으면 Google이 HTTP를 매우 강하게 선호하게 된다고 설명합니다. 실무에서는 인증서가 www 있는 호스트와 없는 호스트를 모두 포함하는지 먼저 확인하는 방법을 권합니다.

완료 기준: 아래와 같은 결정 기록이 한 줄로 남아 있고, 인증서가 두 호스트를 모두 포함합니다.

대표 주소: https, www 없음 / 결정일: 2026-10-22 / 근거: 검색 노출 주소와 광고 도착 주소가 모두 www 없는 주소임 / 담당: 웹 담당자

2단계: 지금 네 주소의 응답은 어떤 상태인가요?

설정을 바꾸기 전에 현재 상태부터 기록합니다. 홈만 보지 않고 하위 페이지 하나와 매개변수(주소 물음표 뒤에 붙는 값)가 있는 주소 하나를 함께 확인합니다. 홈은 정리되었는데 하위 경로는 빠진 경우를 찾기 위해서입니다.

브라우저 개발자 도구의 네트워크 탭에서 로그 보존 옵션을 켜고 주소를 입력하면 응답 코드와 이동 경로가 차례로 보입니다. 예를 들어 가상의 ○○ 기업이 www 없는 https 주소를 대표로 정했다면, 홈 기록은 다음과 같을 수 있습니다.

완료 기준: 네 조합과 페이지 세 종류(홈, 하위 페이지, 매개변수가 있는 주소)를 곱한 12개 조합의 기록이 모두 채워져 있습니다.

3단계: 리다이렉트에 맞는 방식은 무엇인가요?

Google 문서는 주소를 영구히 바꿀 때 가능하면 서버 측 영구 리다이렉트를 쓰라고 권합니다. 301과 308은 영구, 302·303·307은 임시 리다이렉트로 분류됩니다. 문서는 영구 리다이렉트를 도착 주소가 표준이 되어야 한다는 강한 신호로 설명합니다. 반면 임시 리다이렉트는 출발 주소가 검색 결과에 계속 표시되는 경향이 있다고 설명합니다.

서버 설정을 바꿀 수 없는 환경이라면 지연 없는 메타 새로고침을 씁니다. Google은 이를 영구 리다이렉트로 해석합니다. 자바스크립트 리다이렉트는 서버 측 방식과 메타 새로고침을 모두 쓸 수 없을 때만 쓰라고 안내합니다. 렌더링이 실패하면 Google이 리다이렉트를 보지 못할 수 있기 때문입니다.

HTTPS에서 HTTP로 보내는 리다이렉트는 만들지 않습니다. 1단계에서 본 대로 이런 리다이렉트가 있으면 Google이 HTTP를 매우 강하게 선호하게 됩니다. 설정 규칙은 다음 다섯 가지입니다.

1. 대표가 아닌 세 조합을 모두 리다이렉트 대상에 넣습니다.
2. 응답 코드는 301 또는 308로 합니다.
3. 경로와 매개변수를 그대로 유지해 같은 페이지로 보냅니다. 모든 주소를 홈으로 보내지 않습니다.
4. 중간 단계 없이 한 번에 대표 주소로 도착하게 합니다.
5. 대표 주소 자체는 리다이렉트 없이 200으로 응답하게 합니다.

네 번째 규칙이 어긋나면 이동이 두 번 이상 일어납니다. http·www 있음 요청이 https·www 있음을 거쳐 다시 www 없음으로 가는 식입니다. Search Console 페이지 색인 생성 보고서는 지나치게 긴 리디렉션 체인과 리디렉션 순환을 리디렉션 오류로 분류합니다. 실무에서는 웹서버, CDN, 호스팅 관리 화면 가운데 한 곳에서만 리다이렉트를 관리해 규칙이 겹치지 않게 하는 방법을 권합니다.

완료 기준: 2단계 양식을 다시 채웠을 때 대표가 아닌 9행은 모두 301 또는 308, 1회 이동, 같은 경로로 표시됩니다. 대표 주소 3행은 200입니다.

4단계: 표준 태그·내부 링크·사이트맵을 맞추는 기준은 무엇인가요?

리다이렉트만으로 끝내지 않고 사이트 안의 신호도 대표 주소로 맞춥니다. Google 문서는 표준 태그(rel=canonical 링크 요소)를 강한 신호로, 사이트맵을 약한 신호로 설명합니다. 이 방법들은 함께 쓰면 효과가 쌓인다고도 안내합니다. 사이트 안에서 링크할 때는 중복 주소가 아니라 표준 주소로 걸라고 설명합니다.

Google 문서는 표준 페이지 자체에도 표준 태그를 넣으라고 안내하며, 이를 자기 참조 표준 태그라고 부릅니다. 상대 경로가 아니라 절대 경로로 쓰라고도 설명합니다. 상대 경로로 쓰면 http로 열린 페이지에서 표준 주소가 http로 해석될 수 있으므로 절대 경로가 안전합니다.

Google 문서는 같은 페이지에 서로 다른 방법으로 서로 다른 표준 URL을 지정하지 말라고 안내합니다. HTML 요소와 HTTP 헤더가 다른 주소를 가리키는 경우가 여기에 해당합니다.

완료 기준: 위 표의 다섯 가지 확인 결과가 모두 충족되고, 사이트맵 파일의 수정 날짜가 정리 작업일 이후입니다.

5단계: Search Console에서 끝났다고 볼 기준은 무엇인가요?

먼저 속성 유형을 확인합니다. Search Console 도움말에 따르면 URL 접두어 속성은 지정한 접두어로 시작하는 주소만 포함합니다. 따라서 http와 https, www 유무가 다르면 서로 다른 속성으로 나뉩니다. 도메인 속성은 모든 프로토콜과 www·m 등 모든 하위 도메인을 포함하며 DNS 레코드로 소유권을 확인합니다. 네 조합을 한 화면에서 보려면 도메인 속성이 편리합니다.

확인 순서는 다음과 같습니다.

1. 대표 주소만 담은 사이트맵을 제출합니다.
2. 주요 페이지를 URL 검사 도구로 열어 사용자가 선언한 표준 URL과 Google이 선택한 표준 URL을 비교합니다. Google이 선택한 값은 색인된 데이터에서만 결정되며 실시간 테스트로는 예측할 수 없으므로, 재크롤링 뒤에 다시 확인합니다.
3. 페이지 색인 생성 보고서에서 상태를 확인합니다. 대표가 아닌 주소가 리디렉션이 포함된 페이지로 분류되면 정상입니다. 도움말은 이 상태의 주소가 색인되지 않는다고 설명합니다.
4. 중복 페이지, Google에서 사용자와 다른 표준 URL을 선택함 상태가 남아 있으면 4단계 표의 신호 가운데 어긋난 곳을 다시 확인합니다.

주소 변경 도구는 이 작업에 쓰지 않습니다. Google 사이트 이전 문서는 이 도구가 도메인이나 하위 도메인을 옮길 때 필요하다고 설명합니다. 주소 변경 도구 도움말은 HTTP에서 HTTPS로의 변경에는 이 도구를 쓰지 않는다고 안내하고, 같은 도메인의 www 전환은 표준 태그나 리다이렉트로 처리하라고 설명합니다.

네이버 서치어드바이저를 함께 운영한다면 실무에서는 등록 사이트와 제출 사이트맵도 대표 주소 기준으로 맞추는 방법을 권합니다.

완료 기준: 표본으로 고른 주요 페이지 모두에서 사용자가 선언한 표준 URL과 Google이 선택한 표준 URL이 같은 대표 주소로 표시됩니다.

정리 뒤에 유지하고 지켜볼 것은 무엇인가요?

리다이렉트는 지우지 않습니다. Google 사이트 이전 문서는 리다이렉트를 가능한 한 오래, 일반적으로 최소 1년 유지하라고 안내하고, 사용자 관점에서는 무기한 유지도 고려하라고 설명합니다. 대표 주소 통일은 되돌릴 일이 거의 없는 변경이므로 실무에서는 기간을 정하지 않고 유지하는 방법을 권합니다.

Google 리다이렉트 문서는 사용자의 검색어가 옛 주소를 더 신뢰할 것으로 보이면 옛 주소가 대체 이름으로 검색 결과에 나타날 수 있다고 설명합니다.

Google 문서는 HTTPS 선호를 확실히 하는 방법 가운데 하나로 HSTS(브라우저가 항상 https로 접속하게 하는 응답 헤더)를 듭니다. 다만 잘못된 인증서나 HTTPS에서 HTTP로 가는 리다이렉트가 만든 HTTP 선호는 HSTS로도 뒤집을 수 없다고 설명합니다. HSTS는 브라우저가 기억해 되돌리기 어려우므로, 3단계와 4단계 결과가 안정된 뒤에 적용합니다.

정리가 끝난 뒤에는 새로 생기는 주소가 다시 갈라지지 않게 막습니다. 아래 문안을 사내 웹 운영 규칙에 넣어 씁니다.

새 페이지, 캠페인 도착 주소, 보도자료와 외부 배포 링크에는 대표 주소(https, www 없음)만 씁니다. 다른 조합의 주소를 발견하면 웹 담당자에게 알립니다.

분기마다 2단계 기록 양식을 다시 채워 리다이렉트가 유지되는지 확인합니다. 서버 이전, CDN 교체, 인증서 갱신 직후에는 분기와 관계없이 바로 다시 확인합니다.

정리

1. https와 www 유무 가운데 대표 조합 하나를 정하고, 인증서가 두 호스트를 모두 포함하는지 확인한 뒤 결정 근거를 기록합니다.
2. 네 조합과 페이지 세 종류의 응답 코드, 도착 주소, 이동 횟수를 양식에 기록합니다.
3. 대표가 아닌 세 조합을 서버 측 301 또는 308로 같은 경로의 대표 주소에 한 번에 보냅니다.
4. 표준 태그, 내부 링크, 사이트맵, 리소스 주소를 대표 주소로 바꿉니다.
5. Search Console 도메인 속성에서 사이트맵을 제출하고, URL 검사로 두 표준 URL이 대표 주소로 같은지 확인합니다.

참고 자료

• How to specify a canonical URL with rel=canonical and other methods (Google Search Central, 확인일 2026-10-22)
• Redirects and Google Search (Google Search Central, 확인일 2026-10-22)
• What is URL canonicalization (Google Search Central, 확인일 2026-10-22)
• Site moves with URL changes (Google Search Central, 확인일 2026-10-22)
• Change of Address tool (Google Search Console 도움말, 확인일 2026-10-22)
• Search Console에 웹사이트 또는 플랫폼 속성 추가하기 (Google Search Console 도움말, 확인일 2026-10-22)
• URL 검사 도구 (Google Search Console 도움말, 확인일 2026-10-22)
• 페이지 색인 생성 보고서 (Google Search Console 도움말, 확인일 2026-10-22)