301 Moved Permanently는 대상 리소스에 새로운 영구 URL이 부여되었으며(Location 헤더로 전달), 앞으로는 그 URL을 사용해야 한다고 클라이언트에 알립니다. 브라우저는 즉시 이를 따라가며, 북마크 관리자나 링크 검사기처럼 링크를 수정할 수 있는 클라이언트는 링크를 업데이트할 것으로 기대됩니다.
301은 기본적으로 캐시할 수 있습니다. 브라우저는 영구 리디렉션을 저장하며, Cache-Control 헤더가 없으면 오랫동안 보관하는 경우가 많고, 이후 방문할 때는 예전 URL에 다시 묻지 않고 곧바로 새 URL로 이동합니다. 그래서 잘못 설정한 301은 되돌리기 어렵습니다. 먼저 짧은 Cache-Control: max-age로 테스트하거나, 이전이 확정될 때까지는 임시 리디렉션을 사용하세요.
역사적인 이유로 사용자 에이전트는 301을 따라갈 때 메서드를 POST에서 GET으로 바꿀 수 있으며, 주요 브라우저는 모두 그렇게 합니다. API나 폼 엔드포인트처럼 리디렉션된 POST가 POST로 유지되어야 한다면 대신 308 Permanent Redirect를 사용하세요.
응답 예시
HTTP/1.1 301 Moved Permanently
Date: Fri, 06 Nov 2026 10:15:32 GMT
Server: nginx
Content-Type: text/html
Content-Length: 154
Connection: keep-alive
Location: https://www.example.com/new-page
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>SEO 및 리디렉션 검사
301은 검색 노출을 잃지 않고 콘텐츠를 옮기는 표준 방법입니다. Google은 301을 대상 URL이 표준 URL이 되어야 한다는 강력한 신호로 취급하므로, 시간이 지나면서 검색결과에서 새 URL이 예전 URL을 대체합니다. 또한 Google은 3xx 리디렉션으로 PageRank가 손실되지 않는다고 밝혔습니다. 도메인 이전, HTTP에서 HTTPS로의 전환, www 정규화, 슬러그 변경, 페이지 병합에는 301을 사용하세요. 예전 URL은 홈페이지가 아니라 가장 가까운 대응 페이지로 리디렉션하세요. 홈페이지로 보내면 Google이 소프트 404로 처리할 수 있습니다.
체인은 짧게 유지하세요. 홉이 하나 늘 때마다 왕복이 한 번 더 필요하며, Googlebot은 최대 10홉까지만 따라간 뒤 리디렉션 오류를 보고합니다. 내부 링크와 사이트맵은 최종 URL을 직접 가리키게 하고, http:// → https:// → https://www. → /new-page 같은 체인은 피하세요. 301 리디렉션 검사 도구는 모든 홉이 영구 리디렉션인지 보여 주며, HTTP 리디렉션 상태 코드 정리 글에서는 301을 302, 307, 308과 비교합니다.
주요 원인과 사용 사례
- 사이트를 HTTPS나 새 도메인으로 옮겼고, 예전 URL이 모두 새 URL의 대응 페이지로 리디렉션됩니다.
www와www가 없는 호스트, 또는 후행 슬래시 유무에 따른 변형을 하나의 표준 형태로 통일합니다. HTTPS 리디렉션 검사와 후행 슬래시 검사 도구로 테스트하세요.- 페이지 이름이 바뀌었거나 다른 페이지에 병합되었습니다.
- 실수로 301을 설정했고 브라우저가 캐시된 리디렉션을 계속 사용합니다. 서버를 수정한 뒤 브라우저 캐시를 지우거나 시크릿 창에서 테스트하세요.