지점 문서마다 본원 안의 실제 목적지 정하기
지점 사이트를 본원 사이트에 합칠 때에는 기존 문서마다 그 정보를 이어서 읽을 수 있는 새 목적지를 정합니다. 관련 없는 본원 홈페이지로 모든 주소를 보내는 방식은 피해야 합니다. Google은 관련성이 낮은 한 도착 URL로 옛 주소들을 일괄 리디렉션하면 사용자에게 혼란을 주고 soft 404로 처리될 수 있다고 설명합니다.
실제로 여러 페이지의 콘텐츠를 하나의 새 문서에 통합한 경우에는 여러 옛 URL을 그 문서로 보낼 수 있습니다. 주소의 개수가 같아야 한다는 규칙이 아니라 목적지에 실제 콘텐츠가 통합됐는지가 조건입니다. 지점 안내를 본원 사이트의 문서로 옮기는 계획에서는 원래 문서의 내용을 어디에서 읽을 수 있는지 먼저 정해야 합니다.
지점 고유 정보와 본원의 공통 설명 구별하기
지점 문서에서 보존할 내용은 실제 공개된 자료를 바탕으로 정합니다. 지점의 위치·방문 안내와 본원 공통 설명을 구분해 새 목적지의 내용을 설계하는 편집 제안입니다. 웹사이트 통합을 이유로 실제 지점이 폐쇄됐다고 추정하거나, 다른 지점의 안내를 같은 정보로 바꾸어 작성하지 않습니다.
Google의 사이트 이동 준비에는 콘텐츠를 새 CMS로 가져오고 이미지·다운로드 자료를 전송하는 작업이 포함됩니다. 따라서 지점 안내 본문과 함께 사용하던 파일이 있는지도 조사해야 합니다. 본원 안의 페이지가 생성됐다는 사실만으로 해당 지점 안내에 필요한 자료까지 모두 옮겨졌다고 판단하지 않습니다.
지점별 문서의 실제 대응을 채우는 빈 양식
| 지점 문서 | 보존할 실제 정보 | 본원 안의 목적지 |
|---|---|---|
| 실제 기존 문서 입력 | 실제 지점 고유 안내 입력 | 실제 새 문서 주소 입력 |
| 실제 공통 내용 문서 입력 | 실제 통합할 설명 입력 | 실제 통합 문서 입력 |
| 실제 첨부 자료 입력 | 실제 유지할 파일 입력 | 실제 파일 위치 입력 |
페이지 밖의 주소도 매핑에 포함하기
이전 계획에는 페이지 본문뿐 아니라 삽입된 이미지, 동영상, JavaScript, CSS 같은 리소스의 주소도 포함해야 합니다. 본원 사이트에 본문을 옮겼어도 옛 지점 서버의 리소스를 계속 불러오는 구조일 수 있습니다. 실제 화면을 구성하는 자료가 어느 주소에서 제공되는지 조사해 이전 대상과 남은 의존 관계를 구별합니다.
기존 URL을 모으는 자료로는 사이트맵, 서버 로그와 분석, 내부·외부 링크, CMS가 안내돼 있습니다. 어느 한 자료에 주소가 없다는 이유만으로 이전할 문서가 없다고 확정하지 않습니다. 실제 지점 사이트에서 조사한 자료를 이용해 본원 안의 대응 문서와 연결해야 합니다.
본원 사이트의 서버 용량도 이전 준비에 포함됩니다. Google 안내는 이전 뒤 옛 사이트의 크롤링이 새 사이트로 보내져 새 환경을 일시적으로 더 많이 크롤링할 수 있다고 설명합니다. 기존 본원 사이트의 요청과 지점에서 이동하는 요청을 처리할 수 있는 자원인지 조사해야 합니다. 실제 서버 환경의 자료 없이 필요한 용량을 임의의 수치로 계산하지 않습니다.
대응 관계를 구현 자료로 만들기
Google은 기존 URL과 새 URL의 매핑을 만들도록 설명합니다. 저장 방식은 서버와 이전 조건에 따라 달라질 수 있으며 데이터베이스나 URL 재작성 규칙을 사용할 수 있습니다. 본원 사이트의 서버가 어떤 방식으로 이전 관계를 읽을 수 있는지와 문서 내용의 대응을 함께 정해야 합니다.
새 주소 목록이 들어 있는 사이트맵과 옛 URL로 연결되는 사이트 목록을 저장하는 준비도 안내에 있습니다. 이 자료는 이전의 대상 주소를 실제로 조사하는 데 사용할 수 있습니다. 작업 전 정한 목적지와 실제 적용된 목적지가 같은지 읽을 수 있는 자료이며, 목록만 만들어졌다고 이동 응답까지 적용된 상태는 아닙니다.
되돌리지 않을 이동에는 영구 응답 사용하기
지점 문서의 주소를 본원 안의 새 주소로 영구 이동한다면 서버 측 영구 리디렉션을 사용하도록 Google은 권장합니다. 리디렉션 안내에서 301과 308은 영구 이동이며, 대상 URL이 표준이어야 한다는 신호가 됩니다. 새 페이지가 열리는 결과뿐 아니라 실제 응답이 영구 이동을 표현하는지도 조사해야 합니다.
서버 측 리디렉션을 설정하려면 서버 구성 파일에 접근하거나 서버 측 스크립트로 헤더를 설정할 수 있어야 합니다. 사용하는 서버와 백엔드 언어에 따라 구현 방법이 달라집니다. 콘텐츠 편집 권한이 있는 작업자가 서버 설정도 변경할 수 있다고 가정하지 않고 실제 환경에서 가능한 방식을 조사합니다.
리디렉션은 가능한 최종 도착 페이지로 직접 연결하는 것이 좋습니다. 이동 지침은 연결을 여러 번 거치는 체인이 사용자 지연 시간을 늘릴 수 있고 일부 사용자 에이전트나 브라우저가 긴 체인을 지원하지 않는다고 설명합니다. 본원 안의 임시 주소를 차례로 거친다는 구조와 지점 안내의 최종 문서로 바로 이동하는 구조는 구분해야 합니다. 실제 여러 단계를 거쳐야 한다면 체인의 이동 횟수를 적게 유지하도록 계획합니다.
서버 방식이 어려운 환경의 새로고침 해석
| 대안 | Google의 해석 | 구별할 조건 |
|---|---|---|
| 즉시 meta refresh | 영구 리디렉션으로 해석 | 페이지 로드 직후 이동 |
| 지연 meta refresh | 임시 리디렉션으로 해석 | 설정된 시간 뒤 이동 |
JavaScript 이동은 렌더링 조건까지 고려하기
Google은 서버 측 리디렉션이나 meta refresh를 실행할 수 없을 때에만 JavaScript 방식을 사용하도록 설명합니다. JavaScript 리디렉션은 웹 렌더링 서비스를 이용해 처리되며, 렌더링이 실패하면 이동을 발견하지 못할 수 있습니다. 사용자의 브라우저에서 본원 문서로 이동했다는 한 결과로 검색 처리까지 확정하지 않습니다.
중간 주소와 최종 문서의 내용을 나눠 검사하기
HTTP 상태 코드 안내에 따르면 Google은 리디렉션 주소에서 받은 콘텐츠를 무시하고 최종 대상 URL의 콘텐츠를 대신 처리합니다. 옛 지점 페이지에 설명을 남겨 두었더라도 실제 이동 목적지에 해당 내용이 없으면 최종 문서의 상태는 다릅니다. 원래 안내가 최종 대상에 있는지 조사해야 하는 기술적인 이유입니다.
서버가 200으로 응답하면 수신한 내용이 다음 처리 단계로 전달됩니다. 그러나 콘텐츠가 빈 페이지나 오류 메시지라면 Search Console에 soft 404가 나타날 수 있습니다. 정상 응답 코드 하나만으로 지점 안내가 제대로 보존됐다고 판단하지 않고 최종 내용의 실제 제공 상태를 읽어야 합니다.
200 응답과 검색 색인 생성도 같은 결과는 아닙니다. Google의 안내는 색인 시스템이 콘텐츠를 색인할 수도 있지만 그 결과가 확정되는 것은 아니라고 설명합니다. 문서 이전의 구현 검사 결과를 특정 검색 노출이나 병원 방문 결과로 확대해서 해석하지 않습니다.
본원 안의 링크와 표준 지정도 새 주소로 연결하기
매핑이 준비되면 새 URL마다 자체 참조 canonical을 지정하고 내부 링크를 새 주소로 갱신하는 단계가 이동 안내에 있습니다. 지점 안내 문서로 연결하는 본원 안의 링크가 실제 새 목적지를 가리키는지 조사해야 합니다. 옛 주소의 리디렉션을 설치한 결과와 새 사이트 안에서 사용하는 주소의 상태를 구별하는 작업입니다.
새 페이지의 HTML과 사이트맵 항목에 쓰는 URL 주석도 새 주소에 맞춰야 합니다. 실제 다국어나 국가별 버전에 언어·지역 주석을 사용했다면 그 주석에도 새 URL을 사용합니다. 존재하지 않는 언어 버전을 임의로 만드는 조건이 아니라 원래 이런 구성이 있던 문서를 이전할 때의 조건입니다.
옛 URL별 이동 시험에서 잘못된 목적지 찾기
Google의 이동 지침은 저장한 URL 매핑을 바탕으로 리디렉션을 시험하도록 설명합니다. URL 검사 도구로 개별 URL을 시험하거나 명령줄 도구·스크립트로 여러 URL을 시험하는 방법이 있습니다. 본원 홈페이지 한 곳이 열리는 시험을 지점의 모든 문서가 올바른 위치로 이동하는 시험으로 대신하지 않습니다.
HTTP 안내는 Search Console이 4xx·5xx 응답과 실패한 리디렉션에 대한 오류 메시지를 생성한다고 설명합니다. 실제로 옛 주소를 요청했을 때 어떤 이동 응답이 나오고 최종 문서가 어떤 응답을 제공하는지 나눠 읽어야 문제의 위치를 파악할 수 있습니다. 통합 계획의 목록과 실제 요청 결과를 같은 완료 증거로 보지 않습니다.
자주 묻는 질문
최종 문서가 204로 응답하면 본문이 처리되나요?
Google은 204 응답에서 콘텐츠를 수신할 수 없어 처리할 수 없다고 설명합니다. 본원 안에 문서의 주소가 있다는 사실과 콘텐츠가 전달되는 결과는 다릅니다.
304 응답은 새 내용 전달을 뜻하나요?
Google 크롤러는 콘텐츠가 마지막 크롤링 때와 같다고 다음 처리 시스템에 알립니다. Google 검색의 색인 시스템이 URL 신호를 다시 계산할 수는 있지만 이 상태 코드가 새 콘텐츠의 전달을 뜻하지는 않습니다.
429도 일반적인 문서 부재와 같은 상태인가요?
Google은 429를 서버가 과부하 상태라는 신호로 취급하며 서버 오류로 취급합니다. 다른 4xx 응답이 설명하는 콘텐츠 부재와 같은 원인으로 처리하지 않습니다.
401이나 403으로 크롤링 속도를 조절해도 되나요?
공식 HTTP 안내는 크롤링 속도를 제한하기 위해 401과 403을 사용하지 않도록 설명합니다. 접근 제한 응답을 사이트 통합 후의 크롤링 속도 조절 수단으로 사용하지 않습니다.
CMS의 자체 리디렉션 기능을 사용할 수도 있나요?
일부 플랫폼에는 리디렉션 솔루션이 내장돼 있을 수 있다고 Google은 안내합니다. 실제 사용하는 플랫폼의 도움말을 조사해야 하며 모든 CMS가 같은 기능이나 수정 권한을 제공한다고 가정하지 않습니다.