대표 주소 표시와 방문자 이동의 차이
canonical과 리디렉션은 대표 주소를 알리는 것만 필요한지, 방문자도 다른 주소로 이동시켜야 하는지로 구분합니다. 중복 주소를 더 이상 사용하지 않을 때는 영구 리디렉션을 선택합니다. 사이트 운영자는 주소를 통일하고 싶다는 요청에 앞서 기존 주소에서도 콘텐츠를 계속 제공할 필요가 있는지 정해야 합니다.
네이버 서치어드바이저는 동일한 콘텐츠에 여러 주소로 접근할 수 있을 때 선호하는 대표 주소를 지정하도록 안내합니다. 운영자가 기존 주소의 이용 경로를 유지하면서 검색엔진에 선호 주소를 전달하려는 경우에는 canonical을 검토할 수 있습니다. 대표 주소를 정했다는 이유만으로 방문자의 이동까지 요청한 것으로 처리하면, 유지하려던 이용 경로가 달라질 수 있습니다.
구글 검색 센터는 리디렉션을 기존 주소와 새 주소를 연결하여 방문자와 검색에 페이지 위치의 변경을 알리는 방법으로 설명합니다. 또한 중복 페이지를 더 이상 사용하지 않는 경우에 영구 리디렉션을 사용하도록 안내합니다. 개발 담당에게는 대표 주소의 이름뿐 아니라 기존 주소로 접속했을 때 남아 있어야 하는지, 이동해야 하는지도 전달해야 합니다.
| 판단 질문 | 대표 주소 지정 검토 | 리디렉션 검토 |
|---|---|---|
| 기존 주소에서 콘텐츠를 계속 제공합니까? | 유지할 필요가 있는 동일 콘텐츠 주소 | 기존 주소의 콘텐츠 제공을 종료할 때 |
| 방문자의 접속 주소를 유지해야 합니까? | 기존 주소에서 이용을 이어가야 할 때 | 선호 목적지로 이동해야 할 때 |
| 중복 주소를 앞으로도 사용합니까? | 유지 목적이 명확할 때 | 더 이상 사용하지 않을 때 영구 이동 검토 |
| 메인 페이지의 여러 접속 경로가 혼동을 줍니까? | 대표 주소 표시만으로 충분한지 판단 | 방문자에게 같은 목적지를 안내할 때 |
이 표는 사이트 전체에 같은 처리를 적용하기 위한 표가 아닙니다. 동일한 콘텐츠를 제공하는 주소 묶음마다 답을 작성하고, 유지 여부를 결정하지 못한 묶음은 개발 요청에서 보류합니다. 콘텐츠가 서로 다르다면 대표 주소 선택에 앞서 각각의 페이지가 필요한 이유부터 정리합니다.
기존 주소를 계속 제공할 이유
주소를 유지할 이유는 현재 그 주소가 존재한다는 사실보다 구체적이어야 합니다. 운영 담당자는 해당 주소에서 이용자가 수행하는 작업과 그 경로를 관리하는 부서를 기재합니다. 다른 주소로 이동해도 같은 작업을 이어갈 수 있는지는 해당 업무의 담당자가 판단하도록 요청합니다.
예전에 만든 주소라는 이유만으로 폐기를 결정해서는 안 됩니다. 반대로 외부에서 접속할 가능성이 있다는 이유만으로 기존 콘텐츠 제공을 계속할 필요도 없습니다. 기존 접속을 받아 다른 주소로 보낼 계획인지, 기존 화면 자체를 유지할 계획인지 결정 내용에 명시합니다.
콘텐츠 대조부터 처리 선택까지
실행 순서는 콘텐츠의 동일성 판단, 기존 주소의 사용 목적 조사, 처리 방식 선택으로 진행합니다. 마케팅 담당자는 방문 경로와 운영 목적을 준비하고, 콘텐츠 담당자는 본문의 차이를 설명하며, 개발 담당자는 요청한 동작을 구현할 수 있는지 검토합니다. 주소 목록만 전달하면 개발 담당자가 운영 목적까지 추정해야 하므로 판단 근거를 함께 작성합니다.
- 콘텐츠 담당자는 대상 주소에 접속해 제목뿐 아니라 본문, 주요 안내, 이용자가 수행할 작업을 대조합니다. 주소가 비슷해도 내용의 목적이 다르면 같은 묶음으로 처리하지 않습니다.
- 운영 담당자는 기존 주소를 사용하는 안내물, 캠페인 자료, 업무 연결 경로를 조사합니다. 각 경로를 계속 사용할 이유와 변경 여부를 결정할 책임자를 기록합니다.
- 마케팅 담당자는 방문자가 기존 화면에서 이용을 이어갈지, 다른 주소로 이동할지 기재합니다. 이동을 원한다면 도착할 콘텐츠와 그곳에서 이어갈 작업을 함께 지정합니다.
- 개발 담당자는 앞에서 정한 기준에 따라 대표 주소 지정 또는 리디렉션 처리안을 작성합니다. 유지 목적이 미정이거나 도착할 콘텐츠가 확정되지 않은 항목은 구현 대상과 분리합니다.
자료에는 현재 상태와 요청 상태를 별도로 기록합니다. 현재 접속이 이동으로 처리되는지와 앞으로 어떤 동작을 원하는지를 같은 칸에 섞으면 변경할 부분을 가리기 어렵습니다. 화면 캡처를 첨부할 때는 어느 주소에서 어떤 이용 조건으로 얻은 화면인지 설명합니다.
개발 담당에게 전달할 처리 목록
개발 요청서는 주소 유지 목적과 방문 동작을 연결해서 작성합니다. 아래 표의 대상 주소 칸에는 실제 작업 목록의 식별명을 사용하고, 상세 주소는 별도 관리 자료에 기록합니다. 처리 요청은 기능 이름만 쓰지 말고 작업 후 기대하는 상태까지 설명합니다.
| 대상 주소 | 계속 제공할 이유 | 방문자에게 원하는 동작 | 개발 담당에게 요청할 처리 |
|---|---|---|---|
| 유지할 동일 콘텐츠 주소 | 기존 이용 경로 유지 | 현재 주소에서 이용 계속 | 선호 대표 주소 지정 |
| 사용을 종료할 중복 주소 | 별도 제공 목적 없음 | 지정한 목적지로 이동 | 영구 리디렉션 적용 |
| 메인 페이지의 다른 접속 주소 | 접속 경로별 필요 기록 | 운영자가 정한 메인 주소로 이동 | 방문자 혼동을 줄일 이동 처리 검토 |
| 유지 여부가 미정인 주소 | 담당 부서의 결정 필요 | 결정 전 변경 보류 | 처리 확정 항목에서 제외 |
요청서에는 목적지 선정 책임자와 처리 승인 담당자도 기재합니다. 주소를 관리하는 부서와 콘텐츠를 관리하는 부서가 다르면 양쪽의 결정을 받은 뒤 개발 담당에게 전달합니다. 의견이 다를 때는 기술 방식부터 정하지 말고 이용자가 계속해야 할 작업을 기준으로 합의합니다.
작업 완료 후에는 요청서의 방문 동작과 실제 접속 결과를 대조합니다. 이동을 요청한 항목은 도착한 화면에서 필요한 내용을 이용할 수 있는지 확인하고, 유지를 요청한 항목은 기존 경로의 작업이 가능한지 시험합니다. 구현 완료 표시와 운영 담당자의 수락 기록은 별도로 작성합니다.
메인 페이지에 필요한 추가 판단
메인 페이지는 콘텐츠가 같다는 판단에 더해 방문자가 사이트의 시작 주소를 혼동하는지도 따져야 합니다. 네이버 서치어드바이저는 메인 페이지에서 선호 주소 표시보다 리디렉션을 사용해 방문자의 혼동을 줄이는 방식을 권고합니다. 운영자는 서로 다른 접속 경로에서 회사 소개, 메뉴, 주요 안내로 이어지는 이용 흐름을 기록합니다.
구글 검색 센터도 여러 주소로 홈페이지에 접근하는 경우 선호 목적지를 선택하고 다른 주소의 방문을 그곳으로 보내는 방식을 안내합니다. 이 안내를 모든 하위 페이지에 일괄 적용하는 규칙으로 확대해서는 안 됩니다. 메인 페이지의 시작 주소를 정하는 결정과 개별 콘텐츠의 유지 여부를 정하는 결정은 따로 작성합니다.
혼동 여부는 담당자의 취향보다 이용자가 받는 안내를 근거로 판단합니다. 같은 사이트를 안내하는 자료들이 서로 다른 시작 주소를 사용하고 있는지, 이동 뒤에도 안내받은 메뉴를 찾을 수 있는지 조사합니다. 시작 주소가 달라도 업무상 유지할 필요가 있다면 그 사유와 해결할 이용 문제를 개발 요청에 함께 남깁니다.
설정 완료와 운영 완료의 차이
개발 작업이 끝났다는 보고만으로 주소 정리 업무를 종료하지 않습니다. 마케팅 담당자는 승인한 요청서와 접속 시험 결과를 연결하고, 예상과 다른 동작이 발생한 항목을 처리 방식별로 기록합니다. 기록에는 접속 출발점, 기대한 동작, 실제 도착 화면, 재작업 담당자를 포함합니다.
대표 주소 지정 항목과 이동 항목은 완료를 판단하는 자료가 다릅니다. 전자는 개발 담당의 적용 내역과 기존 이용 경로의 시험 기록을 받고, 후자는 실제 이동 결과와 도착 화면의 이용 가능 여부를 기록합니다. 검색결과에서 주소가 변경되었다는 관찰만으로 방문 동작 시험을 대신하지 않습니다.
처리 후 운영 목적이 달라지면 이전 승인 내용을 그대로 재사용하지 않습니다. 관련 부서는 변경된 이용 요구를 기록하고 대상 항목의 유지 여부부터 다시 결정합니다. 기존 결정의 사유를 남겨야 이후 담당자가 기술 설정만 보고 폐기 의도를 추정하는 일을 줄일 수 있습니다.
자주 묻는 질문
검색에서 제외하려는 목적에도 canonical을 사용합니까?
검색 제외가 목적이라면 대표 주소 지정과 별도의 요구로 작성해야 합니다. 네이버 서치어드바이저는 noindex를 해당 페이지를 검색결과에서 제외하는 명령으로 설명합니다. 운영자는 검색 제외 요청을 주소 통일 요청에 섞지 말고, 제외할 콘텐츠와 그 이유를 개발 담당에게 전달합니다.
리디렉션 출발 페이지의 메타 설정만 전달해도 됩니까?
도착 페이지에 필요한 설정도 함께 전달해야 합니다. 네이버 서치어드바이저는 이동 기능만 있는 페이지에서는 메타 태그가 제대로 반영되지 않을 수 있으며, 이동 대상 페이지에도 동일한 설정을 적용하도록 권고합니다. 검색 접근에 관한 요구가 있다면 도착 페이지의 담당자에게도 요청 내용을 공유합니다.
관리 도구에 이동 기능이 없으면 선택을 변경해야 합니까?
관리 화면에 기능이 없다는 이유만으로 운영 결정을 변경할 필요는 없습니다. 개발 담당에게 현재 사이트에서 해당 동작을 구현할 수 있는지 먼저 묻습니다. 구현이 어렵다면 대체 처리의 제약과 이용자가 겪을 차이를 설명받고 운영 책임자가 수락 여부를 결정합니다.
처리 요청을 승인할 때 개인정보 자료도 필요합니까?
이용 목적을 설명하는 데 개인별 접속 정보가 반드시 필요한 것은 아닙니다. 담당자는 안내 경로, 수행할 작업, 원하는 화면 동작을 중심으로 자료를 작성합니다. 화면 캡처에 계정 정보나 입력 내용이 포함되어 있다면 공유 전에 해당 내용을 제거합니다.
외부에 배포한 안내 자료도 모두 다시 제작해야 합니까?
재제작 여부는 자료의 사용 상태와 수정 가능성에 따라 결정합니다. 마케팅 담당자는 새로 배포할 자료와 수정하기 어려운 기존 자료를 나누어 관리하고, 새 자료에 사용할 안내 주소를 승인받습니다. 수정할 수 없는 자료는 별도 목록으로 기록해 이후 운영 변경 때 참고합니다.