웹사이트 URL 이전 전에 리디렉션 맵을 만드는 방법

웹사이트 URL을 이전할 때 가장 먼저 만들 문서는 리디렉션 맵입니다. 기존 URL, 새 URL, 전환 방식, 검증 상태를 한 행에 기록하면 방문자가 오래된 링크를 눌렀을 때 올바른 새 문서로 이동하고, 운영자는 누락과 무한 리디렉션을 발견할 수 있습니다. 디자인과 CMS 이전은 이 표의 범위가 확정된 뒤 진행하는 편이 안전합니다.

핵심은 모든 주소를 홈페이지로 보내는 것이 아닙니다. 내용이 같은 주소는 301 또는 서버가 지원하는 영구 이동으로 대응하고, 대응 문서가 없는 주소는 관련성이 있는 대체 문서나 정직한 404를 선택해야 합니다. Google의 사이트 이동 안내도 URL 변경 시 서버 측 영구 리디렉션과 오래된 주소의 매핑을 권장합니다.사이트 이동 기본 가이드를 기준으로 아래 절차를 적용합니다.

기존 URL 인벤토리와 이동 범위를 고정한다

목록에는 현재 사이트맵, 서버 로그, 분석 도구의 유입 URL, 외부에서 링크된 주요 주소를 합칩니다. URL을 소문자화하거나 슬래시를 제거하는 정규화 규칙도 별도 열로 적습니다. 관찰된 목록과 아직 확인하지 못한 목록을 섞지 말고 수집일과 출처를 기록해야 리디렉션 후 누락을 설명할 수 있습니다.

• old_url: 현재 공개된 정규 주소와 변형 주소

• new_url: 동일 의도의 새 정규 주소 또는 빈 값

• decision: 301, 유지, 404, 수동 검토 중 하나

• evidence: 상태 코드와 최종 URL을 확인한 날짜

매핑 예외와 최종 주소를 행 단위로 판정한다

경로 패턴이 완전히 같은 경우에만 와일드카드 규칙을 사용합니다. 상품·문서 구조가 바뀌어 의미가 달라졌다면 행 단위 매핑이 더 안전합니다. 여러 단계의 301을 이어 붙이면 크롤러와 브라우저가 최종 주소를 찾는 비용이 늘고, 중간 주소의 규칙이 서로 충돌할 수 있습니다. 목표는 기존 주소에서 최종 정규 주소까지 한 번에 도착하는 것입니다.

샘플: 이동 맵에서 판정을 읽는 법

예시 입력은 /guide/old-cache, /guide/legacy-cache 두 주소와 새 문서 /blog/cache-control-after-web-deploy입니다. 결정은 첫 주소를 301로 연결하고, 두 번째 주소는 내용이 중복되어 첫 주소로 301을 연결하는 것입니다. 중간 산출물은 old_url·new_url·status·reason 열을 가진 CSV이며, 기대 결과는 각 주소가 최종 문서까지 한 번의 이동으로 도착하고 새 문서의 canonical과 일치하는 것입니다.

컷오버 전후에 이동 맵과 탐색 경로를 검증한다

배포 전에는 모든 old_url에 결정이 있는지, 같은 old_url에 서로 다른 규칙이 없는지, new_url이 실제로 존재하는지 확인합니다. 배포 후에는 HTTP 클라이언트로 상태 코드와 최종 주소를 확인하고, 새 사이트맵과 canonical이 새 주소를 가리키는지 확인합니다. Search Console의 주소 변경 도구를 쓸 수 있는 상황인지도 함께 검토하되, 도구가 서버 규칙을 대신하지는 않습니다.

누락 주소를 모니터링하고 복구 기준을 남긴다

실패 사례는 삭제된 모든 글을 홈페이지로 보내는 방식입니다. 사용자는 찾던 내용을 잃고, 검색엔진도 관련성 낮은 대체를 정상적인 이동으로 해석하지 않을 수 있습니다. 복구는 로그에서 반복 유입되는 주소를 분류해 관련 문서가 있으면 행 단위 301을 추가하고, 없으면 안내가 있는 404 또는 410으로 되돌리는 것입니다. 리디렉션 체인이 발견되면 최종 주소를 직접 가리키도록 규칙을 합칩니다.

완료 조건

완료 조건은 맵의 모든 관찰 URL에 판정과 근거가 있고, 대표 URL과 변형 URL이 의도한 최종 주소로 한 번에 이동하며, 새 사이트맵·canonical·내부 링크가 새 구조만 가리키는 상태입니다. 이 결과를 CSV와 HTTP 검증 로그로 기록하고, 새로 발견된 주소는 임의 수정 대신 맵에 추가한 뒤 재검증해야 URL 이전을 완료했다고 말할 수 있습니다.