도메인 마이그레이션 SEO: 웹 전문가를 위한 체크리스트
게시 됨: 2019-05-22
웹사이트를 마이그레이션하는 데에는 여러 가지 이유가 있습니다.
- 일부 기업의 경우 보안 문제입니다. 좋은 예는 https 도메인으로 이동해야 하는 http 도메인입니다.
- 다른 사람들에게는 콘텐츠 관리 시스템과 같은 것을 변경하면서 정리 하는 문제입니다. 예를 들어 Joomla에서 Drupal로 이동하는 경우 여전히 중요한 콘텐츠를 마이그레이션하고 이에 대한 계획을 세우는 것이 좋습니다.
- 일부 조직의 경우 인수 문제입니다. 인수되는 회사는 때때로 "어머니" 도메인으로 접혀야 합니다.
- 일부 회사의 경우 브랜드 변경 이 필요한 시점이며 도메인 이름은 변경해야 할 사항 중 하나입니다.
마이그레이션의 이유가 무엇이든 모든 도메인 마이그레이션에는 약간의 위험 이 따르며 일부는 무해하고 다른 일부는 웹사이트 트래픽을 방해한다는 점을 이해해야 합니다.
신중하게 계획된 마이그레이션은 이러한 위험을 완화합니다. 또한 웹사이트 소유자는 이미 존재하는 검색 엔진 추천을 유지하거나 전체 웹사이트 트래픽을 실제로 개선할 수 있는 더 나은 기회를 제공합니다.
이사 전 벤치마킹

마이그레이션의 보다 기술적인 측면을 계획하기 전에 다양한 도구를 사용하기 위해 조사해야 할 사항이 많이 있습니다 . 이것은 장거리 운전을 하기 전에 타이어를 발로 차는 것과 비슷합니다. 준비된 마이그레이션 프로젝트에 들어가는 것이 좋습니다.
웹사이트마다 다르지만 아래 항목의 변형이 필요할 수 있습니다.
- Google Search Console 에서 1년치의 Google 노출수, 클릭률 및 게재순위를 내보냅니다. 이렇게 하면 이동 후 충족해야 하는 검색 엔진 존재의 기준선이 설정 됩니다.
- 웹사이트 분석 도구 (예: WebTrends 또는 Google Analytics)에서 유기적 트래픽, 총 방문수, 평균 404 오류 수, 이탈률 및 전환에 대한 월별 통계를 내보냅니다. 이것도 최소 1년은 받으십시오. 도구에 실시간 기능이 있는 경우 평일 동시 트래픽을 파악하여 출시 후 새 도메인과 비교할 수도 있습니다.
- ForeSee 또는 Qualaroo와 같은 설문 조사 도구 가 있는 경우 만족도와 필요한 것을 찾을 수 있는 사람들의 비율을 내보내십시오.
- 전환이 구매가 아닌 양식 제출인 경우 마케팅 자동화 도구 및/또는 CRM(고객 관계 관리) 에서 이를 내보내십시오.
이러한 통계는 비교할 수 있는 질적 및 양적 통계를 혼합하여 제공합니다. 마이그레이션에 대한 다양한 통계를 수집할 때의 장점 중 하나는 문제가 발생하는 경우 삼각 측량을 통해 문제가 무엇인지 상당히 빠르게 분리 할 수 있다는 것입니다.
일부 마이그레이션에는 이동하는 부분이 많을 수 있으며 대부분의 팀은 이동하는 동안 매우 바쁠 것입니다. 이미 바쁜 팀에 너무 많은 부담을 주지 않도록 문제를 식별하고 격리하는 데 걸리는 시간을 최적화하고 싶을 것입니다. 이러한 방식으로 데이터 위기는 모든 팀이 확장될 가능성이 있는 출시일보다는 준비 단계 동안입니다.
문제를 분리하기 위해 기준 통계를 수집하는 것은 웹사이트 마이그레이션을 계획하는 경우 모든 마케터가 수행해야 하는 작업입니다.
다양한 유형의 웹사이트 마이그레이션 계획

수행하려는 마이그레이션 유형에 따라 계획해야 하는 작업이 다릅니다. 결정해야 할 몇 가지 사항이 있습니다.
- 도메인만 변경 대 URL 경로 변경
- 동일한 내용 또는 다른 내용
- 새로운 콘텐츠 관리 시스템(CMS) 또는 동일한 CMS
- 새로운 도구 또는 동일한 도구
차이점을 감안할 때 계획해야 할 사항에 대해 알아보겠습니다.
도메인만 변경 대 URL 경로 변경
도메인만 이동 해도 최상위 도메인 이후의 문자열은 변경되지 않습니다 . (이것은 "경로" 또는 "URL 경로"입니다.)
예를 들어 /products/product1 또는 /about/company 와 같은 모든 문자열이 변경되지 않지만 도메인이 domain.com에서 new-domain.com으로 변경되는 경우 도메인만 변경됩니다.
도메인 변경
- www.domain.com/path1 에서 www.new-domain.com/path1 로
- www.domain.com/path2 에서 www.new-domain.com/path2 로
- www.domain.com/path3 에서 www.new-domain.com/path3 으로
http에서 https로의 리디렉션도 도메인 전용 이동으로 간주됩니다.
대조적으로, URL 경로 변경을 통한 마이그레이션은 도메인 이후의 문자열 변경을 의미합니다.
도메인 및 URL 경로 변경
- www.domain.com/path1 에서 www.new-domain.com/new-path1 로
- www.domain.com/path2 에서 www.new-domain.com/new-path2 로
- www.domain.com/path3 에서 www.new-domain.com/newfolder/newstringsfornewpath3 로
URL 경로가 변경되지 않는 마이그레이션의 경우 일반적으로 웹 사이트의 모든 페이지에 대해 하나의 리디렉션을 작성하지 않고 리디렉션에 대한 도메인 문자열을 자동으로 변경하는 기술적인 방법이 있습니다.
URL 경로가 실제로 변경되는 마이그레이션의 경우 일부 페이지 수준 301 리디렉션을 작성해야 합니다. 이것은 확실히 더 복잡합니다.
수천, 수천 페이지가 있는 사이트에 정보 아키텍처가 변경되는 경우 모든 것에 대해 페이지 수준 리디렉션을 작성하는 것은 실현 가능하지 않을 수 있습니다. 트래픽 임계값을 결정 해야 할 수도 있습니다. 예를 들어 검색 엔진 및 총 트래픽 순위를 기반으로 전체 175,000페이지 대신 상위 5,000페이지만 리디렉션할 수 있습니다.
동일한 내용 또는 다른 내용
새 도메인에서 이전 도메인과 동일한 콘텐츠를 효과적으로 사용할 수 있다면 내부 연결, 콘텐츠 그룹이 여전히 의미가 있는지 확인하는 등 고려해야 할 사항이 많지 않습니다.
그러나 상당한 양의 콘텐츠를 추가하거나 제거하는 경우 신중하게 매핑해야 합니다.
- 변경할 카테고리가 있습니까? 그 과정에서 페이지를 "고아"로 만들 것입니까? 해당 페이지는 새 집을 찾거나 다른 페이지로 접어야 할 수 있습니다. 그것은 당신의 계획의 일부가 되어야 합니다.
- 새 콘텐츠를 고려할 때 기본 메뉴가 여전히 의미가 있습니까? 이동 후 접근하기 더 어려운 중요한 페이지가 있는 섹션이 있는 경우 콘텐츠가 변경된 후 추가 경로를 제공하는 것이 좋습니다.
새 CMS 또는 동일한 CMS
www.example.com 에서 www.new-example.com 으로 이동하고 CMS를 변경하지 않는 경우 콘텐츠의 실제 마이그레이션은 매우 간단해야 합니다.
한 CMS에서 다른 CMS로 전환하는 경우 동일한 이동이 간단한 작업이 아닐 수 있습니다. 다음을 수행해야 합니다.
- 이전 사이트의 레이아웃과 템플릿이 새 시스템에서 합리적으로 지원되는지 확인하십시오.
- CMS 콘텐츠를 새로운 콘텐츠 관리 시스템에서 수용할 수 있는 형식으로 내보낼 수 있는 방법이 있는지 확인합니다(100%가 아니더라도 콘텐츠 마이그레이션의 부분 자동화가 도움이 될 수 있음).
- CMS 변경으로 인해 수동이 될 콘텐츠 마이그레이션 부분에 시간을 할애하십시오.
새로운 도구 또는 동일한 도구
실제 도구와 도구를 배포하는 방법은 이전 도메인과 새 도메인에서 다를 수 있습니다.
몇 가지를 생각해야 합니다.
- 새 시스템에는 독립적으로 또는 태그 관리 도구의 일부로 도구에 필요한 마스터 페이지 또는 플러그인 스크립트와 유사한 것이 있습니까? 아니면 사이트 전체에서 스크립트를 여러 번 연결해야 합니까? 후자라면 충분한 시간을 확보하십시오.
- 도구별 구현에서 Google 태그 관리자와 같은 태그 관리 도구로 전환하는 경우 이 시나리오를 테스트할 충분한 시간이 있는지 확인하세요. 태그 관리 도구는 유용하지만 익숙해지는 데 시간이 걸릴 수 있으며 이는 도메인 전환 일정에 반영되어야 합니다.
- 도구를 추가하는 경우 회귀 테스트 를 위한 시간이 있는지 확인하십시오. 새 도구는 이전 도구와 즉시 잘 작동하지 않을 수 있으며 디버그하는 데 시간이 필요합니다.
사이트 마이그레이션 계획 완료

다양한 유형의 사이트 마이그레이션을 처리했으면 사이트 마이그레이션 계획을 설정할 차례입니다.
필요하지 않은 부분만 제거할 수 있도록 상당히 복잡한 시나리오에 대한 예제를 작성해 보겠습니다.
이전 CMS에서 새 CMS로 마이그레이션한다고 가정해 보겠습니다. 그리고 새 사이트의 정보 아키텍처는 약간 다를 것입니다. 일부 URL 경로는 새 위치로 이동됩니다.
리디렉션 관점에서 초기에 수행해야 하는 몇 가지 작업은 다음과 같습니다.
1. 페이지 수준 301 리디렉션을 처리하는 방법이 있는지 확인합니다.
"수동" 페이지 수준 리디렉션을 설정하는 방법에는 여러 가지가 있습니다. 그 중 일부는 구성 파일 편집을 포함하고, 다른 일부는 모듈에 XML을 삭제하는 것과 관련되며, 다른 일부는 여전히 이를 처리하는 기본 CMS 기능을 가지고 있습니다(이전 CMS에 계속 액세스할 수 있다고 가정). 어떤 길을 택할지 조기에 결정하면 골치 아픈 일을 피할 수 있습니다.
2. 와일드카드 또는 조건부 리디렉션을 처리할 수 있는지 확인
.htaccess 파일 또는 유사한 구성 파일을 조정할 수 있는 경우 각 리디렉션을 개별적으로 설정하는 대신 조건을 통해 일부 리디렉션을 관리할 수 있습니다. 이렇게 하면 시간이 절약됩니다.
3. 이전 사이트의 상위 페이지 내보내기
순위를 결정하는 요소로 총 트래픽과 유기적 트래픽 중에서 선택하십시오. (유기적 트래픽은 이에 매우 적합하므로 마이그레이션 전에 실제로 검색 엔진 추천을 유도하는 페이지를 리디렉션할 것임을 알고 있습니다.)

- 사이트의 크기를 감안할 때 합리적인 임계값을 선택하십시오. 상위 100개 페이지는 대부분의 트래픽이 상위 80개 페이지에 대한 URL이 500개 정도 있는 사이트에 최적일 수 있습니다. 그러나 수만 개의 URL이 있는 사이트의 경우 상위 5,000페이지가 필요할 수 있습니다.
4. 상위 페이지를 새 위치에 매핑
이것은 시간을 절약하기 위해 수행할 수 있는 수동 단계입니다. 스프레드시트의 상위 페이지 목록을 정렬하고 이전 URL로 표시한 다음 옆에 새 URL을 추가합니다. (XML 파일과 같이) 무엇을 빌드할지 알면 시작할 수 있는 파일이 생깁니다.
301 리디렉션의 이점
새 도메인으로 이동할 때 가장 중요한 페이지로 301(또는 "영구") 페이지 수준 리디렉션을 추가하면 두 가지 작업이 완료됩니다.
- 사용자 경험(UX) 이점 을 위해 사용자를 올바른 페이지로 보냅니다.
- SEO 이점 을 위해 검색 엔진 스파이더에게 이동에 대해 알려줍니다.
사이트의 일부만 정보 아키텍처가 변경된 경우 일반적으로 여전히 동일한 URL 경로를 갖는 사이트 부분에서 조건부 또는 와일드카드 리디렉션을 수행할 수 있으며 더 작은 경우에는 하나씩 페이지 수준 리디렉션만 사용할 수 있습니다. 절대적으로 필요한 사용 사례의 수.
예를 들어, /product/ 아래의 모든 것이 새 사이트에서 /product/ 로 변경될 수 있습니다. 와일드카드 바꾸기를 사용하여 이동의 해당 부분을 처리할 수 있습니다. 그러나 /about/ 아래의 모든 항목이 새로운 "경로"를 가져오기 때문에 /about/ 이후의 실제 문자열이 변경된다고 가정해 보겠습니다. /about/ 아래의 모든 항목에 대해 이전 URL을 새 URL에 매핑하고 301 페이지 수준 리디렉션을 추가해야 합니다.
이렇게 하면 리디렉션을 관리하는 팀에 부담을 주지 않으면서 이전 도메인에서 링크 자산 전송의 이점을 얻을 수 있습니다.
일반적인 함정 피하기

도메인 마이그레이션이 실패할 수 있는 방법에는 여러 가지가 있습니다.
다음은 주의해야 할 몇 가지 일반적인 사항입니다.
1. 사용할 수 있는 리디렉션 도구가 스위치에 대해 충분히 강력하지 않습니다.
- 일부 리디렉션 도구는 http URL만 관리하고 https URL은 처리할 수 없습니다. 따라서 https URL을 처리하는 다른 방법을 찾아야 합니다.
- 일부 리디렉션 도구는 CMS의 기본 부분이며 설정하는 데 시간이 많이 걸립니다. 수백 또는 수천 개의 URL이 있을 때 문제가 됩니다.
- 일부 리디렉션 도구는 와일드카드를 처리할 수 없으므로 수동 리디렉션을 계획해야 합니다. 그리고 필요한 추가 시간을 고려해야 합니다.
성공적인 웹사이트 마이그레이션은 마케팅 담당자가 사용할 수 있는 리디렉션 도구를 완전히 이해하고 가능한 것만 계획하는 데 달려 있습니다.
위에 나열된 것과 같은 설명을 사용하여 초기에 개발자와 함께 사용할 수 있는 항목을 명확히 시작하세요.
출시일 이전에 제한 사항에 유의하십시오. 수동 단계가 많은 경우 해당 단계를 처리할 시간을 충분히 확보하십시오.
이렇게 하면 전환하는 날이 왔을 때 이 영역에서 놀라운 일이 발생하지 않습니다.
2. 팀은 성공 또는 실패를 적절하게 평가할 수 없습니다.
팀이 충족할 벤치마크(사이트 순위, 총 유기적 트래픽, 총 방문, 사이트의 만족도 및 성공률 등)를 설정하지 않은 경우 마이그레이션이 원활하게 진행되었는지 여부를 말하기가 매우 어려울 수 있습니다.
전체 트래픽은 거의 같을 수 있지만 성공률은 급락하기 시작했습니다. 만족도 점수는 같을 수 있지만 사이트 순위가 매겨지는 검색어가 적고 유기적 트래픽이 떨어졌습니다.
보고 있는 수치의 범위가 없다면 웹사이트가 실제로 타격을 받는 동안 도메인 전환이 순조롭게 진행된 것처럼 보일 수 있습니다. 실적이 저조하고 잘하고 있다고 생각하는 것보다 실적이 좋지 않고 그것을 인식하는 것이 더 낫습니다.
이 문제를 방지하려면 사이트의 여러 측면에 대한 벤치마크가 있는지 확인하세요.
3. 팀은 마이그레이션할 중요한 페이지를 놓쳤습니다.
정보 아키텍처가 변경된 도메인의 경우 검색 엔진에 순위가 매겨지거나 여러 소스에서 상당한 양의 트래픽을 얻는 페이지를 쉽게 잃을 수 있습니다.
모든 페이지가 마이그레이션되도록 하기 위해 상위 페이지를 내보내는 작업을 수행한 사람이 없는 경우 일반적으로 팀은 이동 후 트래픽이 감소하는 것을 보게 됩니다.
이런 일이 발생하면 팀은 보고서를 함께 섞어 새 도메인으로 가져오거나 트래픽 손실을 감수할 수 있도록 이전 콘텐츠가 여전히 파일 어딘가에 있는지 확인해야 합니다. 이러한 유형의 계획 실패는 전체 트래픽에 실제로 해를 끼칠 수 있습니다.
리디렉션 트리거를 풀기 전에 분석 도구를 살펴보고 상위 페이지를 내보냈는지, 콘텐츠 계획이 양호한지 확인해야 합니다.
4. 팀이 처리하기에는 작업량이 너무 많습니다.
도메인 마이그레이션에 필요한 작업의 양을 변경할 수 있는 여러 가지가 있습니다.
사이트에는 상대 링크가 아닌 절대 링크가 있을 수 있으며 원래 예상했던 것보다 훨씬 더 많은 내부 링크 조정을 수행해야 합니다.
리디렉션 도구에는 와일드카드를 지원하는 기능이 없을 수 있으며 계획한 것보다 더 많은 수동 리디렉션을 관리해야 합니다.
사이트 내 검색에 대한 추천 결과와 같이 새 CMS로 이전해야 하는 페이지 콘텐츠가 아닌 항목이 있을 수 있으며 출시 후에는 이에 시간을 할애해야 합니다.
일반적으로 전환이 발생할 때 사이트에 추가 리소스를 할당하는 것이 가장 좋으므로 일이 계획대로 정확하게 진행되지 않을 때 흔들림의 여지가 있습니다.
전환 당일 작업 관리

모든 리디렉션이 예상대로 정확하게 작동한다고 가정해 보겠습니다.
이동하려는 모든 콘텐츠가 이동되었습니다. 404 오류 스파이크가 발생하지 않고 모든 도구가 이전과 같이 실행되고 페이지 콘텐츠가 아닌 모든 구성이 올바르게 이동합니다.
좋은 시작이지만 아직 출시일에 SEO 작업에 대한 몇 가지 작업이 남아 있습니다.
1. robots.txt에서 허용하지 않는 조건을 바로 잡기
robots.txt 파일은 검색 엔진 스파이더에게 사이트에서 크롤링해야 하는 항목과 크롤링하지 말아야 하는 항목을 알려줍니다.
robots.txt 파일이 구성되어 있는지 개발자 및 SEO에 확인하고 해당 파일을 옮기십시오. 없는 경우 최소한 robots.txt 파일이 다음과 같이 읽히지 않는지 확인하십시오.
- 사용자 에이전트: *
- 허용하지 않음: /
이 조합은 Google 및 기타 검색 엔진에 웹사이트에서 색인을 생성하지 않도록 지시합니다. 피해야 할 시나리오입니다.
2. 새 Google Search Console 계정 생성 및 확인
새 도메인이 설정되면 Google Search Console에 등록하고 도메인을 소유하고 있음을 증명해야 합니다. Google이 루트에서 인식할 파일을 삭제하는 것부터 Google 태그 관리자를 사용하는 것까지 다양한 방법을 사용하여 이 작업을 수행할 수 있습니다.
- 폴더에 대한 Google Search Console 계정 설정. 도메인이 확인되면 사이트 섹션을 추가 속성으로 추가할 수 있습니다. 이렇게 하면 "제품" 섹션 또는 "회사 소개" 섹션(있는 경우)으로 이어지는 검색을 보는 것과 같은 작업을 수행할 수 있습니다. 이렇게 하면 유기적 트래픽이 도메인 마이그레이션에서 살아남았는지 확인하기 위한 추가 레이어가 제공됩니다.
3. 사이트맵 제출
콘텐츠 관리 시스템에 따라 CMS, 크롤링 도구 또는 메모장을 통해 수동으로 URL 목록을 사용하여 사이트 맵을 생성할 수 있습니다.
여기에서 할 수 있는 한 가지는 사이트의 각 섹션에 대해 별도의 사이트 맵을 생성하는 것입니다("제품" 섹션에 대한 하나의 사이트 맵, "회사 소개"에 대한 하나의 사이트 맵 등). Google이 제품 페이지의 90%를 인덱싱하는 경우 하지만 정보 페이지의 5%만 색인이 제대로 생성되지 않은 섹션만 수정하면 됩니다. 웹 사이트의 섹션별로 별도의 사이트 맵이 있는 경우에만 해당 문제가 표시됩니다.
여러 웹사이트 섹션에 대한 사이트 맵을 생성한 후에는 Search Console을 통해 Google에 제출해야 합니다.
4. Google에 도메인 전환에 대해 알리기
이것은 일부 노련한 마케터도 놓치는 단계입니다. Google Search Console에는 "주소 변경"을 선언할 수 있는 도구가 있습니다. 이를 사용하려면 이전 및 새 도메인에 대한 Google Search Console 속성을 확인한 다음 Google Search Console에 나열된 단계를 따라야 합니다.
출시 후 통계 모니터링
지금까지 이 게시물의 조언을 따랐다면 비교할 양적 및 질적 벤치마크를 갖게 될 것입니다.
- 측량 도구 데이터. 만족도가 크게 떨어지고 필요한 것을 찾는 사람들의 능력은 사이트의 새로운 구조가 방문자에게 혼란을 줄 수 있음을 의미할 수 있습니다. 새로운 아키텍처를 다시 생각 해야 합니다.
- Google Search Console 및 분석 도구 데이터. 일부 순위 손실 및 유기적 트래픽 감소와 결합된 404 오류의 급증은 일반적으로 최소한 일부 리디렉션이 실패했음을 의미합니다. 리디렉션 방법을 조사 해야 합니다.
- 분석 도구 데이터. 검색 엔진 트래픽이 크게 감소하지 않으면서 총 및 추천 트래픽이 크게 감소했다면 다른 웹사이트가 링크하는 콘텐츠로 이동하지 않았다는 의미일 수 있습니다. 해당 콘텐츠를 다시 방문해야 합니다 .
트래픽의 실시간 모니터링도 여기에서 도움이 될 수 있습니다. 사이트의 동시 방문자 수가 출시 전 수치보다 현저히 낮다면(예: 절반 미만), 뭔가 잘못되었다는 것을 알게 될 것이며 더 깊이 파고들 필요가 있습니다.
도메인 마이그레이션에 과도한 준비 같은 것은 없습니다.
도메인을 이동하는 것은 고통스러운 과정일 수 있습니다.
프로세스가 귀하의 사이트에 좋지 않은 방식으로 진행될 수 있는 방법이 많이 있습니다. 그리고 완전한 성공으로 가는 길은 거의 없습니다.
도메인을 변경해야 하는 경우 과도하게 준비하는 것이 가장 좋습니다. 만약 너라면 …
- 리디렉션 도구가 초기에 무엇을 할 수 있는지 알아보십시오.
- 빈틈이 보이지 않을 때까지 콘텐츠 계획에 집착하고,
- 데이터를 사용하여 전환 관리
… 새 도메인으로 원활하게 이동할 수 있는 더 나은 기회가 있습니다.
특정 유형의 이동의 경우 계획에 집착하면 전환 후 트래픽과 전환이 증가할 수도 있습니다.

