조합별 요청표를 만듭니다
새 apex의 HTTP·HTTPS, 새 www의 HTTP·HTTPS, 옛 호스트의 HTTP·HTTPS를 나눕니다. 각 호스트에 홈과 주요 상세 경로를 하나 이상 넣습니다. 경로가 바뀐 레거시 문서도 별도 표본으로 둡니다. 단순 도메인 포워딩 화면을 보고 판단하지 말고 실제 URL 요청이 어떤 응답을 받는지 기록합니다.
모든 계층의 목적지를 확인합니다
HTTPS 전환, 대표 호스트 전환, 옛 경로 이동이 다른 규칙에 분산돼 있는지 봅니다. 예를 들어 옛 HTTP 주소를 먼저 옛 HTTPS 주소로 보낸 뒤 www 새 주소를 경유해 apex로 이동시키는 구성은 각각의 규칙만 읽어서는 길어 보이지 않을 수 있습니다. 최종 목적지가 이미 정해졌다면 옛 호스트 규칙에서 직접 대응하는 새 문서로 이동할 수 있는지 검토합니다.
순서와 범위를 함께 고칩니다
- 대표 주소 정책을 문서로 고정합니다. apex인지 www인지 임의로 바꾸지 않습니다.
- 특별한 레거시 경로의 새 목적지를 먼저 정의합니다.
- 호스트별 일반 이동과 경로 예외의 적용 순서를 확인합니다.
- 다른 사이트와 서브도메인이 같은 규칙에 잡히지 않도록 호스트 범위를 제한합니다.
가정한 예로 옛 /services/search/가 새 /services/seo/로 바뀌었다면 최종 새 도메인의 /services/seo/를 직접 목적지로 둡니다. 옛 경로를 새 도메인에 먼저 전달한 후 다시 경로 이동을 시키는 것은 줄일 수 있는 경유인지 검토합니다. 반면 보안 장비나 플랫폼의 필수 동작이 있다면 그 제약을 기록합니다.
최종 검사에서 볼 항목
최초 응답부터 최종 200까지의 상태·주소·쿼리를 남깁니다. TLS 오류가 없는지, 캠페인 값이 유지되는지, 최종 페이지의 canonical과 사이트맵이 같은 주소를 사용하는지도 봅니다. 새로운 호스트가 준비되기 전에 기존 호스트를 이동 전용으로 바꾸지 않도록 전환 순서와 복구 조건을 정합니다.
운영 기록에 남길 한계
검사한 조합과 도구를 적고 DNS 전파 중인지 안정된 이후인지 구분합니다. 특정 PC의 캐시된 DNS 결과만으로 전체 전환을 완료 처리하지 않습니다. 경유를 줄인 결과는 기술적인 정리이며 실제 검색 색인·노출 변화는 이후 검색도구에서 별도로 확인합니다.
자주 묻는 질문
- 두 번 이동하면 검색 이전이 실패한 것인가요?
- 이동 횟수 하나로 성공·실패를 단정하지 않습니다. 다만 불필요한 경유는 진단과 운영을 어렵게 하므로 줄이고, 최종 목적지·경로·쿼리·응답 상태가 의도와 맞는지 함께 확인합니다.
- 옛 도메인의 인증서도 유지해야 하나요?
- HTTPS로 들어오는 기존 링크를 처리하려면 요청이 이동 응답을 받기 전 연결 단계도 정상이어야 합니다. 이전 계획에 기존 호스트의 인증서와 유지 책임을 포함하고 만료 여부를 점검합니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.