URL이 변경되는 사이트 이동

이 도움말에서는 Google 검색결과에 대한 영향을 최소화하면서 사이트의 기존 페이지 URL을 변경하는 방법을 설명합니다. 이러한 사이트 이전의 예는 다음과 같습니다.

HTTP에서 HTTPS로 URL 변경
도메인 이름 변경(예: example.com에서 example.net으로) 또는 여러 도메인이나 호스트 이름 병합
URL 경로 변경(예: example.com/page.php?id=1에서 example.com/widget으로 또는 example.com/page.html에서 example.com/page.htm으로)

개요

사이트 이동에 관한 기본 정보를 검토합니다. 예상되는 결과라든지 사용자 및 순위에 미칠 수 있는 영향을 파악합니다. HTTP에서 HTTPS로 이동하는 경우 HTTPS 권장사항을 검토합니다.
새 사이트를 준비하고 꼼꼼히 테스트합니다.
현재 URL에서 이에 상응하는 새 형식으로 URL 매핑을 준비합니다.
이전 URL에서 새 URL로 리디렉션하도록 서버를 설정하여 사이트 이동을 시작합니다.
이전 URL과 새 URL 모두의 트래픽을 모니터링합니다.

URL이 변경되는 사이트 이전 관련 자주 묻는 질문

Google에서는 모든 것을 함께 이동하는 것을 추천하나요, 아니면 섹션별로 이동해도 괜찮은가요?
섹션별로 이동해도 괜찮습니다.
얼마나 많은 페이지의 색인이 생성되었는지 테스트하려면 어떻게 하나요?
Search Console에서 각 속성의 데이터를 개별적으로 확인합니다. 전반적인 정보는 색인 상태 보고서를 참고하세요. 사이트맵 보고서에서 사이트맵에 제출된 URL 중 색인이 생성된 URL 수를 확인할 수 있습니다.
Google이 URL 변경을 인식하는 데 시간이 얼마나 걸리나요?
정해진 크롤링 빈도는 없습니다. 사이트의 크기와 가능한 크롤링 속도에 따라 다릅니다. 이동은 URL별로 이루어집니다.
새로운 URL로 리디렉션하면 링크 크레딧을 잃게 되나요?
아니요. 301 또는 302 리디렉션으로 인한 PageRank 손실은 없습니다.

HTTP에서 HTTPS로 이전

HTTPS 권장사항을 검토합니다.
HTTPS 속성을 Search Console에 추가했는지 확인합니다. Search Console에서는 HTTP와 HTTPS를 별개로 처리하며, 속성 관련 데이터를 공유하지 않습니다. 즉 두 프로토콜에 모두 페이지가 있다면 프로토콜마다 Search Console 속성을 분리해야 합니다.

HTTP에서 HTTPS로 이전 관련 FAQ

HTTPS 이전이 순위에 영향을 미치나요?

어떠한 이전이든 이전 중에는 순위 변동이 발생하기도 합니다. 하지만 HTTPS 관련 실수를 피하려면 HTTPS 페이지 권장사항 정보를 검토하세요.

HTTPS 사이트에 약간의 순위 상승이 있더라도 눈에 띄는 변화는 발생하지 않습니다. HTTPS를 사용하면 Google에서 사이트 순위가 향상될 수 있습니다. 이외에도 다양한 요인이 사이트 순위에 영향을 미치는데, 현재로서는 HTTPS 사용보다 사이트 콘텐츠 품질이 더 큰 영향을 미칩니다. HTTPS로 이동한다고 해서 단기적으로 유의미한 검색엔진 최적화 효과를 기대해서는 안 됩니다. 향후 Google에서 HTTPS로의 이동 효과를 강화할 수도 있습니다.

일부 페이지만 HTTPS로 이동해도 괜찮나요?

예, 괜찮습니다. 일부만 이동을 시작해 보고 테스트한 다음 원하는 속도로 이동을 진행하면 됩니다.

사이트 일부를 HTTP에서 HTTPS로 이전하고 있고 스테이징된 URL 색인이 미리 생성되지 않도록 하려면 리디렉션보다 rel=canonical을 사용하는 것이 좋습니다. 리디렉션을 사용하면 리디렉션된 페이지를 테스트할 수 없습니다.

`rel=canonical` 태그가 사용되면 HTTP URL의 색인이 생성된 것인가요?

아니요. 하지만 색인이 생성된 URL을 선택할 때 강력한 신호가 됩니다.

Google 검색의 경우 최신 브라우저에서 사용되는 모든 최신 인증서를 사용할 수 있습니다.

HTTPS로 이전한 후 검색 키워드가 변경되나요?

HTTPS에서도 달라지지 않습니다. 여전히 Search Console에서 검색어를 볼 수 있습니다.

얼마나 많은 페이지를 색인 생성할 수 있는지 테스트하려면 어떻게 하나요?

Search Console에서 HTTP와 HTTPS를 각기 확인하고 색인 생성 범위 보고서를 사용하여 색인이 생성된 페이지를 확인합니다.

HTTP에서 HTTPS로 이동하는 데 시간이 얼마나 걸리나요?

정해진 크롤링 빈도는 없습니다. 사이트의 크기와 가능한 크롤링 속도에 따라 다릅니다. 이동은 URL별로 이루어집니다.

Google에서는 robots.txt에서 HTTP 사이트맵을 참조합니다. robots.txt를 업데이트하여 새로운 HTTPS 사이트맵을 포함해야 하나요?

robots.txt 파일이 HTTPS 버전의 HTTPS 파일을 가리키도록 업데이트하는 것이 좋습니다. 또한 사이트맵에는 HTTPS URL만 나열하는 것이 좋습니다.

사이트의 각 URL을 HTTP에서 HTTPS로 리디렉션하는 경우에도 크롤러에 액세스할 수 있는 robots.txt 파일은 하나뿐입니다. 예를 들어 http://example.com/robots.txt가 https://example.com/robots.txt로 리디렉션되는 경우 HTTP 버전의 콘텐츠는 Google 및 다른 검색엔진에 표시되지 않습니다.

어떤 사이트맵이 HTTPS 체험용 섹션을 매핑해야 하나요?

사이트의 업데이트된 섹션에 대한 별도의 사이트맵을 생성할 수 있습니다. 이렇게 하면 체험용 섹션의 색인 생성을 좀 더 정확히 추적할 수 있습니다. 대신 다른 사이트맵에서 이러한 URL이 중복되지 않도록 주의하세요.

사이트에 리디렉션이 있는 경우 사이트맵에 어떤 URL을 나열해야 하나요(HTTP에서 HTTPS로, 또는 반대의 경우)?

사이트맵에 새 HTTPS URL을 전부 나열하고 이전 HTTP URL을 삭제하세요. 새 사이트맵을 만드는 것이 좋다면 새 HTTPS URL만 나열하세요.

HTTPS 버전의 robots.txt에 추가해야 할 다른 특별한 사항은 없나요?

없습니다.

HSTS를 지원해야 하나요?

HSTS를 활용하면 보안에는 도움이 되지만 롤백 전략이 복잡해집니다. 자세한 정보는 HTTPS 권장사항을 참고하세요.

전체 사이트에서 단일 Google 뉴스 사이트맵을 사용합니다. 사이트를 부분적으로 이전하는 경우 어떻게 해야 하나요?

새로운 HTTPS 섹션에 Google 뉴스 사이트맵을 사용하려면 뉴스팀에 문의하여 프로토콜 변경을 알린 다음, 사이트의 각 섹션을 HTTPS로 이전할 때 Search Console의 HTTPS 속성에서 새로운 Google 뉴스 사이트맵을 제출할 수 있습니다.

HTTPS 이전과 관련하여 Google 뉴스 게시자 센터의 구체적인 권장사항이 있나요?

Google 뉴스 게시자 센터는 HTTP를 HTTPS로 이동하는 작업을 투명하게 처리합니다. 뉴스 사이트맵을 사용하는 경우가 아니라면 일반적으로 Google 뉴스와 관련하여 별도로 취해야 할 조치는 없습니다. 뉴스 사이트맵을 사용하고 있다면 뉴스팀에 문의하여 변경사항을 알립니다. 또한, 섹션 변경사항도 뉴스팀에 알릴 수 있습니다. 예를 들어, HTTPS로 옮기는 경우 https://example.com/section에서 https://example.com/section으로 이동한다고 명시하면 됩니다.

새 사이트 준비

사이트 준비에 관한 세부정보는 사이트 이전마다 다르지만, 대개 다음 중 하나 이상의 작업을 실행합니다.

새 콘텐츠 관리 시스템(CMS)을 설정하고 여기에 콘텐츠를 추가합니다.
현재 호스팅하는 이미지와 다운로드를 전송합니다(예: PDF 문서).
이러한 이미지와 다운로드에 이미 Google 검색이나 링크를 통한 트래픽이 발생할 수 있으므로 Googlebot과 사용자에게 새 위치를 알리는 것이 좋습니다.
HTTPS로 이전하는 경우 서버에 필수 TLS 인증서를 받고 설정합니다.

새 사이트의 robots.txt 설정

사이트의 robots.txt 파일은 Googlebot이 크롤링할 수 있는 영역을 제어합니다. 새 사이트의 robots.txt 파일에 포함된 규칙이 크롤링을 차단하려는 부분을 올바로 반영하는지 확인해야 합니다.

일부 사이트 소유자는 개발 중 모든 크롤링을 차단하기도 합니다. 이렇게 하면 사이트 이전을 시작한 후 robots.txt 파일을 어떻게 변경할지 준비해야 합니다. 마찬가지로 개발 중에 noindex 규칙을 사용하는 경우 사이트 이전을 시작하면 noindex 규칙을 삭제할 URL 목록을 준비하세요.

삭제되거나 병합된 콘텐츠에 관한 오류 메시지 제공

이전 사이트에서 새 사이트로 전송되지 않는 콘텐츠가 있는 경우에는 이렇게 소속이 없는 URL이 HTTP 404 또는 410 오류 응답 코드를 제대로 반환하도록 해야 합니다. 새 사이트의 설정 패널에서 이전 URL에 오류 응답 코드를 반환하거나 새 URL로 이동하는 리디렉션을 만들고 HTTP 오류 코드를 반환하도록 할 수 있습니다.

올바른 Search Console 설정 확인

사이트 이전의 성공 여부는 Search Console을 최신 상태로 올바르게 설정하는 데 달려있습니다.

아직 확인하지 않았다면 Search Console에서 이전 사이트와 새 사이트를 모두 소유하고 있는지 확인합니다. 이전 사이트와 새 사이트의 변형을 모두 확인하세요. 예를 들어 www.example.com과 example.com을 확인하고 HTTPS URL을 사용하는 경우 HTTPS 및 HTTP 사이트 변형을 모두 포함해야 합니다. 이전 사이트와 새 사이트 모두 해당됩니다.

Search Console 확인 검토

사이트를 이동한 후에도 Search Console 확인이 계속 작동하는지 확인하세요. 다른 확인 방법을 사용하는 경우 URL을 변경했을 때 확인 토큰이 다를 수 있습니다.

HTML 파일을 이용하는 방법을 사용하여 Search Console에서 사이트 소유권을 확인하는 경우 현재 확인 파일을 사이트의 새 사본에 포함해야 합니다.

마찬가지로, meta 태그를 참조하는 include 파일 또는 Google 애널리틱스를 사용하여 소유권을 확인한다면 새 CMS 사본에도 이를 포함해야 합니다.

Search Console 설정 검토

Search Console에서 이전 사이트의 일부 설정을 변경했다면 이러한 변경사항을 반영하도록 새 사이트의 설정도 업데이트해야 합니다. 예:

크롤링 속도: Search Console에서 이전 URL과 새 URL 모두를 대상으로 Googlebot의 크롤링 속도를 제한하지 않는 것이 좋습니다. 또한 크롤링 속도 설정을 구성하지 않는 것을 권장합니다. 사이트에서 Googlebot의 크롤링 양을 처리할 수 없음이 확실한 경우에만 이를 설정합니다. 이미 이전 사이트를 대상으로 Googlebot의 크롤링 속도를 제한했다면 삭제하는 것이 좋습니다. Google에는 사이트 이전이 구현되었음을 자동으로 감지하는 알고리즘이 있으며 Google 색인에 사이트 이전을 신속하게 반영하도록 Googlebot의 크롤링 동작을 변경합니다.
거부된 백링크: 이전 사이트의 링크를 거부하는 파일을 업로드했다면 새 사이트의 Search Console 계정을 사용하여 이 파일을 다시 업로드하는 것이 좋습니다.

최근에 구매한 도메인 정리

새 사이트가 최근에 구매한 도메인에 있는 경우 이전 소유자와 관련된 남은 문제가 정리되었는지 확인할 수 있습니다. 다음 설정을 확인하세요.

이전 스팸에 관한 직접 조치: Google에서는 스팸 정책을 준수하지 않는 사이트에 관해 사이트 순위를 내리거나 Google 검색결과에서 완전히 삭제하는 등의 직접 조치를 취합니다. Search Console의 직접 조치 페이지를 확인하여 새 사이트에 직접 조치가 적용된 적이 있는지 확인하고 페이지에 표시된 다른 문제가 있으면 재검토 요청을 제출하기 전에 문제를 해결하세요.
삭제된 URL: 이전 소유자에게 삭제해야 하는 URL, 특히 사이트 전체 URL이 남아 있지 않은지 확인합니다. 또한 콘텐츠의 URL 삭제 요청을 제출하기 전에 URL 삭제 도구를 사용하지 않아야 하는 경우를 파악해야 합니다.

웹로그 분석 도구 사용

사이트를 이동하는 동안 이전 사이트와 새 사이트의 사용 정보를 분석하는 것이 중요합니다. 웹로그 분석 소프트웨어를 사용하면 손쉽게 분석할 수 있습니다. 일반적으로 웹로그 분석 설정은 페이지에 삽입된 자바스크립트 조각으로 구성됩니다. 다양한 사이트의 추적 세부정보는 분석 소프트웨어 및 로깅, 처리, 필터링 설정에 따라 다릅니다. 도움이 필요하면 분석 소프트웨어 제공업체에 문의하시기 바랍니다. 또한 분석 소프트웨어 설정을 변경할 계획이 있다면 지금 변경하세요. Google 애널리틱스를 사용하는 경우 콘텐츠 보고서에서 새 사이트를 확실히 구분할 수 있도록 새 프로필을 만드는 것이 좋습니다.

서버에 충분한 컴퓨팅 리소스가 있는지 확인

이전 후 Google에서는 평소보다 훨씬 많이 새 사이트를 크롤링합니다. 이는 이전 사이트에서 새 사이트로 트래픽을 리디렉션하기 때문이며 이전 사이트의 모든 크롤링은 다른 크롤링과 함께 새 사이트로 리디렉션됩니다. 새 사이트에 Google로 인해 증가한 트래픽을 처리할 정도로 충분한 용량이 있는지 확인하세요.

데이터 하이라이터 업데이트

데이터 하이라이터로 이전 페이지를 매핑했다면 다시 새 사이트를 매핑해야 합니다.

앱 링크 업데이트

HTTPS 페이지가 준비되면 Google 검색결과에 표시될 때 앱에서 열게 할 웹페이지의 앱 링크를 업데이트하세요. 새 HTTPS URL을 가리키도록 링크를 업데이트해야 합니다. 앱 링크에서는 리디렉션이 작동하지 않으며 앱 링크 처리를 업데이트하지 않는 한 모바일 브라우저를 클릭하면 앱에서 열리는 대신 브라우저에서 페이지가 열립니다.

이전 사이트의 URL을 새 사이트의 URL로 매핑하는 것이 중요합니다. 이 섹션에서는 두 사이트의 URL을 알맞게 평가하고 매핑을 촉진하기 위해 할 수 있는 여러 일반적인 방법을 설명합니다. 매핑을 생성하는 방법에 관한 정확한 세부정보는 현재 웹사이트 인프라와 사이트 이동 세부정보에 따라 다릅니다.

URL 매핑 준비

이전 URL 확인하기

가장 간단한 사이트 이동의 경우 이전 URL의 목록을 생성할 필요가 없을 수도 있습니다. 예를 들어, 사이트의 도메인을 변경한다면(예: example.com에서 example.net으로 변경) 와일드 카드 서버 측 리디렉션을 사용해도 됩니다.

좀 더 복잡한 사이트 이동의 경우 이전 URL 목록을 생성한 다음 새 도착 URL에 매핑해야 합니다. 이전 URL 목록을 생성하는 방법은 현재 웹사이트의 설정에 따라 다릅니다. 다음은 몇 가지 간단한 도움말입니다.

중요한 URL부터 시작합니다. 중요한 URL을 찾으려면 다음을 따르세요.
- 가장 중요한 URL은 Search Console에 사이트맵으로 제출되었을 가능성이 높으므로 사이트맵을 살펴봅니다.
- 서버 로그나 분석 소프트웨어에서 트래픽이 가장 많이 발생하는 URL을 확인합니다.
- Search Console의 사이트로 연결되는 링크 기능에서 내부 링크와 외부 링크가 있는 페이지를 확인합니다.
콘텐츠 관리 시스템을 사용합니다. 이 시스템을 사용하면 일반적으로 콘텐츠를 호스팅하는 모든 URL의 목록을 손쉽게 생성할 수 있습니다.
서버 로그에서 최근에 한 번 이상 방문된 URL을 확인합니다. 계절에 따른 트래픽 변화를 염두에 두고 사이트에 적합한 기간을 선택합니다.
이미지와 동영상을 포함합니다. 삽입된 콘텐츠(동영상, 이미지, 자바스크립트, CSS 파일)의 URL을 사이트 이동 계획에 포함해야 합니다. 이러한 URL은 웹사이트의 다른 모든 콘텐츠와 동일한 방법으로 이동해야 합니다.

이전 URL에서 새 URL로 매핑 생성하기

이전 URL 목록을 만들면 각 URL을 리디렉션할 위치를 결정합니다. 이러한 매핑을 저장하는 방법은 서버 및 사이트 이동에 따라 다릅니다. 데이터베이스를 사용하거나 시스템에 일반 리디렉션 패턴에 관한 URL 재작성 규칙 일부를 설정할 수 있습니다.

모든 URL 세부정보 업데이트하기

URL 매핑을 정의하고 나면 다음 3가지 작업을 진행하여 이동을 위한 준비를 합니다.

각 페이지의 HTML 또는 사이트맵 항목에서 새로운 URL을 가리키도록 주석을 업데이트합니다.
1. 각 도착 URL에 자체 참조 rel="canonical" <link> 태그가 있어야 합니다.
2. 이동한 사이트에 rel-alternate-hreflang 사이트설정을 사용하는 다국어 또는 다국적 페이지가 있다면 새 URL을 사용하도록 사이트설정을 업데이트해야 합니다.
3. 이동한 사이트에 해당하는 모바일 사이트가 있다면 rel-alternate-media 사이트설정을 업데이트해야 합니다. 스마트폰 웹사이트 가이드라인에서 자세히 알아보기
내부 링크를 업데이트합니다.
새 사이트의 내부 링크를 이전 URL에서 새 URL로 변경합니다. 이전에 생성한 매핑을 사용하여 필요에 따라 링크를 찾고 업데이트할 수 있습니다.
최종 이동을 위해 다음 목록을 저장합니다.
- 매핑에 새 URL을 포함하는 사이트맵 파일. 사이트맵 작성 문서를 참고하세요.
- 이전 URL로 연결되는 사이트 목록. Search Console에서 사이트로 연결되는 링크를 확인할 수 있습니다.

`301` 리디렉션 준비하기

매핑을 생성하고 새 사이트가 준비되면 다음으로 매핑에 지정한 대로 이전 URL에서 새 URL로 서버에 HTTP 301 리디렉션을 설정합니다.

다음 사항에 유의하세요.

HTTP 301 리디렉션을 사용합니다. Googlebot에서는 여러 리디렉션 종류를 지원하지만, 가능하면 HTTP 301 리디렉션을 사용하는 것이 좋습니다.
체인 리디렉션을 사용하지 않습니다. Googlebot은 여러 리디렉션 체인(예: 1페이지 > 2페이지 > 3페이지)에서 최대 10개의 홉을 지원할 수 있으나 최종 도착 페이지로 리디렉션하는 것이 좋습니다. 한 번에 리디렉션할 수 없는 경우 체인의 리디렉션 수를 적게 유지합니다. 3개 이하가 적당하며 5개를 넘지 않도록 합니다. 체인 리디렉션을 사용하면 사용자의 지연 시간이 늘어나며 일부 사용자 에이전트와 브라우저에서는 긴 리디렉션 체인을 지원하지 않습니다.
리디렉션을 테스트합니다. URL 검사 도구를 사용하여 URL을 하나씩 테스트하거나 명령줄 도구 또는 스크립트를 사용하여 다수의 URL을 테스트합니다.

사이트 이전 시작

URL 매핑이 정확하며 리디렉션이 작동하면 이동할 준비가 완료된 것입니다.

사이트 이동 방식을 결정합니다. 모두 한 번에 이동할지 또는 섹션별로 이동할지를 정합니다.
- 중소형 사이트: 한 번에 한 섹션씩 이동하지 않고 사이트의 모든 URL을 동시에 이동하는 것이 좋습니다. 이렇게 하면 사용자들이 새로운 형식에서 사이트와 상호작용하고 Google 알고리즘이 사이트 이동을 감지하고 색인을 신속하게 업데이트하는 데 도움이 됩니다.
- 대형 사이트: 규모가 더 큰 사이트는 한 번에 한 섹션씩 이동할 수 있습니다. 이렇게 하면 신속하면서도 간편하게 문제를 모니터링하고 감지하고 해결하기에 좋습니다.
robots.txt 파일을 업데이트합니다.
- 이전 사이트에서 robots.txt 규칙을 모두 삭제합니다. 이렇게 하면 Googlebot이 새 사이트로 연결되는 모든 리디렉션을 식별하고 색인을 업데이트할 수 있습니다. 리디렉션을 사용 설정하면 크롤러가 이전 robots.txt 파일의 콘텐츠를 볼 수 없습니다.
- 새 사이트에서 robots.txt 파일이 모든 크롤링을 허용하는지 확인합니다. 여기에는 이미지, CSS, 자바스크립트 및 기타 페이지 애셋의 크롤링이 포함되며, 크롤링을 원치 않는다고 특정한 URL은 제외됩니다.
URL 매핑을 토대로 사용자와 Googlebot을 새 사이트로 리디렉션하도록 이전 웹사이트를 설정합니다.
Search Console에서 이전 사이트에 관한 주소 변경 알림을 제출합니다.
HTTP에서 HTTPS로 사이트를 이전하는 경우 주소 변경 알림 도구를 사용할 필요가 없습니다.
리디렉션을 최대한 오랫동안 유지합니다. 일반적으로 최소 1년입니다. 이 기간이 확보되어야 Google은 이전 URL로 연결되는 다른 사이트의 링크를 다시 크롤링하고 재할당하는 등 모든 신호를 새 URL에 전송할 수 있습니다.

사용자 측면에서는 리디렉션을 무기한 유지하는 것이 좋습니다. 그러나 사용자에게는 리디렉션이 느리기 때문에 자체 링크 및 다른 웹사이트로 연결되는 대용량 링크가 새로운 URL에 연결되도록 업데이트해 보세요.
Search Console에서 새 사이트맵을 제출합니다. Google에서 새 URL을 학습하는 데 도움이 됩니다. 이후 Google에서 새 사이트맵을 사용하므로 이 시점에서 이전 사이트맵을 삭제할 수 있습니다.

Googlebot과 Google 시스템에서 사이트 이동에 포함된 모든 URL을 찾아서 처리하는 데 걸리는 시간은 서버 속도 및 포함된 URL 수에 따라 다릅니다. 대개 중형 웹사이트에서 대부분의 페이지를 이동하는 데 몇 주가 걸릴 수 있으며 대형 사이트 이동은 더 오래 걸립니다. Googlebot과 Google 시스템에서 이동한 URL을 발견하고 처리하는 속도는 URL 수와 서버 속도에 따라 다릅니다.

수신 링크 업데이트

사이트 이동이 시작된 직후에는 가능한 한 많은 수신 링크를 업데이트하여 사용자 환경을 개선하고 서버 로드를 줄이시기 바랍니다. 예를 들면 다음과 같습니다.

외부 링크: 현재 콘텐츠로 연결되는 사이트의 저장된 목록에 있는 사이트에 연락하여 링크를 새 사이트로 업데이트해 달라고 요청합니다. 각 링크의 인바운드 방문수를 기준으로 작업 우선순위를 정하는 것이 좋습니다.
Facebook, Twitter, LinkedIn 등의 프로필 링크
새로운 방문 페이지를 가리키는 광고 캠페인

트래픽 모니터링

사이트 이동을 시작했다면 사용자와 크롤러의 트래픽이 새 사이트 및 이전 사이트에서 어떻게 변하는지 모니터링합니다. 새 사이트의 트래픽은 증가하는 한편, 이전 사이트의 트래픽은 감소하는 것이 이상적입니다. Search Console 및 다른 도구를 사용하여 사이트에서 사용자와 크롤러의 활동을 모니터링할 수 있습니다.

Search Console을 사용하여 트래픽 모니터링

다양한 Search Console 기능은 다음과 같이 사이트 이동의 모니터링을 돕습니다.

사이트맵: 매핑에서 이전에 저장한 두 사이트맵을 제출합니다. 처음에는 새 URL이 포함된 사이트맵에 페이지의 색인이 생성되지 않고 이전 URL의 사이트맵에는 여러 페이지의 색인이 생성됩니다. 시간이 지나면서 이전 URL 사이트맵에서 색인이 생성된 페이지 수가 0까지 줄어들고 이에 상응하여 새 URL의 색인이 증가합니다.
색인 생성 범위 보고서: 그래프에 사이트 이동이 반영되면서 이전 사이트의 색인 생성된 URL 수는 줄어들고 새 사이트의 색인 생성이 증가합니다. 예상치 않은 크롤링 오류가 있는지 정기적으로 확인합니다.
검색어: 새 사이트 페이지의 색인이 더 많이 생성되고 순위가 집계됨에 따라 검색어 보고서에 새 사이트에서 검색 노출수와 클릭수를 받는 URL이 표시되기 시작합니다.

다른 도구를 사용하여 트래픽 모니터링

서버 액세스와 오류 로그를 주시하여 특히 Googlebot의 크롤링, 예기치 않게 HTTP 오류 상태 코드를 반환하는 URL, 일반 사용자 트래픽을 확인합니다.

사이트에 웹로그 분석 소프트웨어를 설치했거나 CMS에서 분석을 제공하는 경우 이전 사이트에서 새 사이트로의 트래픽 진행 상황을 확인할 수 있도록 이 방법으로 트래픽을 검토하는 것이 좋습니다. 특히 Google 애널리틱스에서 제공하는 실시간 보고서는 사이트 이동 초기 단계에서 사용하기에 유용한 기능입니다. 이전 사이트의 트래픽은 줄어들고 새 사이트의 트래픽은 증가해야 합니다.

사이트 이동 관련 문제 해결

다음은 사이트를 이전하면서 URL을 변경(HTTP에서 HTTPS로 변경하는 경우 포함)할 때 놓치기 쉬운 몇 가지 일반적인 실수입니다. 이러한 실수로 인해 새 사이트의 색인이 완전히 생성되지 않을 수 있습니다.

흔히 발생하는 실수
`noindex` 또는 robots.txt 블록	이전용으로만 필요한 `noindex` 또는 robots.txt 블록을 삭제하는 것을 잊지 마세요. 사이트에 robots.txt 파일이 없는 경우에는 괜찮습니다. 하지만 robots.txt 파일이 요청되었으나 제공되지 않으면 적절한 `404` 오류를 신속하게 반환해야 합니다. 테스트 방법: HTTPS 사이트에서 robots.txt 파일을 살펴보고 변경해야 할 사항이 있는지 확인합니다. 새 사이트의 페이지 중 Google에서 누락된 것으로 보이는 페이지에 URL 검사 도구를 사용합니다.
잘못된 리디렉션	오래된 사이트에서 새 사이트로 연결되는 리디렉션을 확인합니다. 새 사이트에서 방문자가 잘못된(존재하지 않는) URL로 연결되는 경우가 자주 있습니다.
기타 크롤링 오류	색인 생성 범위 보고서를 살펴보고 이전 이벤트 동안 새 사이트에서 다른 오류가 급증했는지 확인합니다.
용량 부족	이전 후 Google에서는 평소보다 훨씬 많이 새 사이트를 크롤링합니다. 이는 이전 사이트에서 새 사이트로 트래픽을 리디렉션하기 때문이며 이전 사이트의 모든 크롤링은 다른 크롤링과 함께 새 사이트로 리디렉션됩니다. 새 사이트에 Google로 인해 증가한 트래픽을 처리할 정도로 충분한 용량이 있는지 확인하세요.
앱 링크를 업데이트하지 않음	앱에서 웹페이지를 열 때 이전 페이지에서 새 페이지로 연결되는 리디렉션을 구현하기 전에 앱 링크를 새 URL로 업데이트합니다. 그러지 않으면 Google에서 앱을 사용하여 검색결과의 새 URL을 열도록 권장하지 않고 사용자를 브라우저를 통해 웹사이트로 안내합니다.
사이트맵을 업데이트하지 않음	사이트맵을 새 URL로 모두 업데이트했는지 확인합니다.
데이터 하이라이터를 업데이트하지 않음	데이터 하이라이터로 이전 페이지를 매핑했다면 새 사이트도 데이터 하이라이터로 다시 매핑해야 합니다.