웹사이트 마이그레이션: SEO 전략 및 모범 사례

게시 됨: 2021-07-14

특정한 이유로 웹사이트/비즈니스를 마이그레이션해야 할 수도 있습니다. SEO로서 우리는 이것을 "마이그레이션" 또는 "사이트 이동"이라고 부릅니다. 부적절하게 준비된 마이그레이션으로 인해 유기적 트래픽이 크게 감소할 수 있습니다. 이 가이드에서는 사이트 마이그레이션 프로세스를 가장 원활하게 진행하는 방법을 공유합니다.

웹사이트를 마이그레이션해야 하는 이유는 무엇입니까? 여기에는 하나 이상의 이유가 있을 수 있습니다.

먼저 마이그레이션 유형을 살펴보겠습니다.

  1. 도메인 변경:
    x.com 사이트를 y.com으로 이동할 수 있습니다.
  2. URL 구조 변경:
    사이트의 콘텐츠 및 구조와 관련된 단어가 포함된 URL은 사이트를 탐색하는 방문자에게 더 친숙합니다. 사이트의 URL이 SEO 친화적이지 않은 경우 변경할 수 있습니다.
  3. HTTP > HTTPS 마이그레이션:
    보안은 Google의 최우선 과제입니다. 사이트를 HTTP에서 HTTPS로 마이그레이션하는 경우 Google은 이를 URL 변경이 있는 사이트 이동으로 처리합니다. 이는 일시적으로 일부 트래픽 수치에 영향을 미칠 수 있습니다.
  4. 플랫폼 변경:
    사이트 플랫폼은 우리 사이트가 구축된 것입니다. WordPress, Shopify, Wix 또는 기타 플랫폼에서 웹사이트를 만들 수 있습니다. 또한 개발 팀에서 만든 사용자 지정 사이트를 가질 수 있습니다. 더 나은 플랫폼으로 전환하고 싶을 수도 있습니다. 사이트가 구축된 플랫폼을 변경할 때 새 플랫폼의 SEO 기능을 테스트해야 합니다.
  5. 구조 및 계층 변경:
    귀하의 웹사이트는 완전히 다른 영역에서 서비스를 시작할 수 있습니다. 또는 사이트의 URL 및 카테고리 구조가 SEO 친화적이지 않을 수 있습니다. 이유에 관계없이 완전히 새로운 사이트에서 작업을 시작할 수 있습니다.
  6. 서버 변경:
    서버 마이그레이션은 주로 페이지 로드 속도 측면에서 위험을 나타냅니다. 사이트 속도는 SEO 순위 요소이지만 더 중요한 것은 사용자 경험 및 전환율 문제입니다. 새 서버에 준비 사이트를 설정하고 페이지 속도를 테스트할 수 있습니다. 또한 리디렉션이 예상대로 작동하는지 확인하는 것을 잊지 마십시오.
  7. 별도의 모바일 사이트 마이그레이션:
    Google은 구현 및 유지 관리가 가장 쉬운 디자인 패턴으로 반응형 웹 디자인을 권장합니다. 따라서 m-dot 버전을 기본 반응형 버전으로 리디렉션할 계획을 세울 수 있습니다. 리디렉션을 수행하는 것은 절대적으로 옳은 일입니다. 이것은 상당히 간단해야 하고 수행하기 매우 쉬워야 합니다.

전체 구조가 그대로이고 도메인만 바뀌면(1차 마이그레이션 유형) 우리 일이 쉽다고 할 수 있습니다. 다른 마이그레이션 유형이나 둘 이상의 마이그레이션 유형이 결합된 경우 상황이 더 복잡해질 수 있습니다.

마이그레이션하는 동안 막대한 트래픽 손실을 경험한 수십 가지 예가 있습니다.

사이트를 이동할 때 트래픽 손실을 일으키는 몇 가지 오류:

  1. 계획 부족
  2. 낮은 SEO 및 UX 지식
  3. 낮은 예산
  4. 리디렉션 문제
  5. URL 매핑 오류
  6. 크롤링 오류
  7. 즉각적인 오류를 방해하지 마십시오

이러한 문제가 발생하지 않도록 기사의 계속에서 올바른 계획 전략과 고려해야 할 사항을 찾을 수 있습니다.

시작하기 전에 몇 가지 사항에 대해 경고하고 싶습니다.

  • ! Google은 디자인과 URL 구조를 동시에 변경하는 것을 권장하지 않습니다. 가능하면 이 두 가지 이상의 마이그레이션 유형을 서로 다른 시간에 단계별로 수행하는 것이 좋습니다.
  • ! 사이트를 다른 도메인으로 이동하는 경우 새 도메인 주소의 기록을 조사해야 합니다. Archive.org, "yoursite.com" 검색 쿼리 및 감사 도구가 작동합니다. 도메인 등록이나 이전에 구축된 사이트가 있는 경우 재검토가 필요합니다. 스팸 링크 또는 해킹과 같은 문제에 노출되었거나 완전히 다른 주제에 서비스를 제공하여 Google에 브랜드 엔터티가 있는 도메인을 설치하면 트래픽의 상당 부분이 손실됩니다.
  • ! 경우에 따라 마이그레이션 계획 및 구현이 문제 없이 완료되더라도 유기적 트래픽이 15% 이상 감소할 가능성이 있습니다. 사이트에 중요한 구조 변경이 있기 때문에 Google은 각 페이지를 하나씩 다시 학습하고 평가합니다. 이 기간은 일반적으로 몇 주이지만 대규모 사이트의 경우 더 오래 걸릴 수 있습니다. 모든 것이 순조롭게 진행된다면, 당신의 유기적 트래픽은 이 평가 후 아주 짧은 시간 안에 긍정적인 추진력을 얻게 될 것입니다.
  • ! 마이그레이션 중 또는 마이그레이션 전에 사이트를 사용자에게 닫으면 안 됩니다. 디자인이나 구조를 변경해야 하는 경우 간단한 방법으로 이 정보를 청중에게 미리 알릴 수 있습니다. (캐러셀, 이메일, SMS, 푸시 알림 등) 다른 상태 코드 또는 경고 메시지가 있는 페이지는 Googlebot에 의해 부정적으로 해석될 수 있습니다.
  • ! 마이그레이션(새 구조 시작) 시점은 웹사이트에서 트래픽이 가장 적은 시간대에 있어야 합니다. 이러한 방식으로 원하지 않는 문제가 발생하는 경우 영향을 받는 청중의 수는 최소 수준으로 유지됩니다. 또한 서버 부하가 낮은 이 시간 동안 Googlebot은 새 사이트를 더 빠르게 크롤링하고 색인을 생성합니다.

[사례 연구] 재설계가 SEO에 불이익을 주지 않도록 하십시오.

웹사이트 재설계 1년 후, EasyCash는 곧 그들이 바라던 성능이 거기에 없다는 것을 깨달았습니다. 그들은 몇 가지 SEO 장애물을 식별하고 해결했습니다.
사례 연구 읽기

계획 및 데이터 수집

이동의 어떤 단계도 건너뛰지 않는 프로젝트 계획은 작업이 오류 없이 진행되도록 합니다. 작업 계획이 결정되면 작업 분배가 명확해질 것입니다. 이 계획은 마이그레이션하기 최소 30일 전에 이루어져야 합니다.

현재 방문자 데이터를 유지하는 것이 중요합니다. 웹 프로젝트의 크기에 따라 트래픽이 가장 높은 페이지와 쿼리를 그룹화해야 합니다.

팁: 마이그레이션 날짜 45일 전에 로그 파일을 보관하면 Googlebot의 동작을 분석하고 차이가 있는 경우 즉각적인 조치를 취할 수 있습니다.

테스트 사이트 생성 및 허용 안함

마이그레이션 프로세스는 SEO용 와이어프레임으로 시작됩니다. 와이어프레임을 생성하는 동안 와이어프레임을 확인하고 SEO 주석을 작성하면 테스트 사이트에서 변경해야 할 사항이 줄어듭니다. 이를 통해 프로젝트를 더 빠르게 진행할 수 있습니다. 이것은 또한 UX/UI 디자이너의 작업을 더 쉽게 만듭니다.

테스트 사이트에 대한 봇 액세스를 끄는 것도 중요합니다. 그렇지 않으면 매우 짧은 시간에 새 페이지가 Google 색인에 포함되는 것을 경험할 수 있습니다.

robots.txt 파일로 검색 엔진 봇을 허용하지 않는 방법은 무엇입니까?

robots.txt 파일 만들기 : test.example.com/robots.txt라는 파일을 만들고 다음 명령을 실행할 수 있습니다.

——

사용자 에이전트: *
허용하지 않음: /
# 이 명령은 모든 봇이 내 웹사이트에 액세스하는 것을 차단합니다.

——

사용자 에이전트: OnCrawl
허용하다: /
# 이 명령은 "OnCrawl 봇이 내 웹사이트에 액세스할 수 있도록 합니다.

—–

테스트할 봇을 결정하고 robots.txt 파일을 통해 사용자 에이전트에 대한 추적을 정의할 수 있습니다. Oncrawl에는 작업을 훨씬 쉽게 해주는 기능이 있습니다.

IP 제한 : 회사 웹사이트의 마이그레이션 계획에 참여하는 경우 새 프로젝트가 노출되는 것을 방지하기 위해 회사 IP에 대한 액세스만 공개하고 다른 모든 IP에 대한 액세스를 비활성화할 수 있습니다. 이 경우 함께 일하는 대행사 또는 컨설턴트(있는 경우)에게 사설 IP 액세스 권한을 부여해야 합니다. IP 제한을 하여도 robots.txt 파일로 봇을 허용하지 않아야 합니다.

비밀번호 보호 : 시험장 입장 시 아이디와 비밀번호 조합을 생성할 수 있습니다. Oncrawl과 같은 크롤링 응용 프로그램에는 암호 액세스 기능이 있습니다.

Noindex 태그 : Google에서 테스트 사이트 페이지의 색인을 생성하는 것을 방지하기 위해 모든 페이지의 헤드 섹션에 noindex 메타 태그를 추가할 수 있습니다.

팁 : 가장 흔한 실수 중 하나는 새 웹사이트로 마이그레이션한 후 noindex 태그를 제거하는 것을 잊는 것입니다. 태그가 인덱싱되도록 업데이트되었는지 확인하고 마이그레이션할 때 따라야 합니다.

Google Analytics를 통한 성능 추적

성능 추적의 가장 중요한 포인트 중 하나는 데이터 손실 없이 동일한 Google Analytics 계정에서 계속하는 것입니다. 따라서 기존 GA 및 GTM 코드는 마이그레이션과 함께 새 사이트에서 활성화되어야 합니다.

새 GA 코드를 생성하면 웹 성능을 측정하기가 더 어려워집니다.

이사 당일 Google 애널리틱스 대시보드에 알림을 추가하면 나중에 실적을 더 쉽게 비교할 수 있습니다.

기존 URL 목록 생성

나는 내 기사의 시작 부분에서 도메인 이름만 변경하면 작업이 쉽다고 언급했습니다. 다음 또는 유사한 코드를 사용하여 .htaccess 파일에서 일괄적으로 적용할 수 있습니다.

* .htaccess 파일은 Apache 서버에 있는 구성 파일입니다.

RewriteCond %{HTTP_HOST} ^oldsitee\.com$에서 RewriteEngine [또는]
RewriteCond %{HTTP_HOST} ^www\.newsite\.com$
RewriteRule(.*)$ https://newsite.com/$1 [R=301,L]

이 규칙 세트는 URL이 oldsite.com 또는 www.oldsite.com에 도달할 때 도메인 주소가 자동으로 https://newsite.com으로 리디렉션되도록 301합니다.

그러나 잘못된 URL 구조를 수정하는 것이 작업이라면 여기에서 상황이 복잡해집니다. 이 상황은 기사 뒷부분에서 설명했습니다.

이제 우리는 마이그레이션 프로세스의 가장 중요한 지점 중 하나에 있습니다. 현재 사이트에 대한 중요한 URL의 전체 목록을 얻는 것이 중요합니다. 방문자가 많고 PageRank가 높은 URL을 잊어버리고 마이그레이션에서 제외하는 경우 유기적 트래픽 감소에 대비하십시오.

팁 : 둘 이상의 소스에서 URL을 내보내어 URL이 누락되지 않도록 할 수 있습니다.

XML Sitemap으로 시작하는 것은 항상 올바른 단계입니다. XML 파일의 URL을 스프레드시트로 간단히 전송하려면 여기에서 링크를 복사하고 첫 번째 줄에 https://www.sinanyesiltas.com/post-sitemap.xml 대신 고유한 사이트맵 URL을 작성할 수 있습니다.

  • Search Console에서 노출이 있는 모든 URL,
  • Google Analytics를 통한 페이지뷰가 있는 모든 URL,
  • Oncrawl로 크롤링하여 얻은 모든 URL,
  • 여러 타사 크롤링 도구를 사용하여 앞으로 나아가면 작업이 명확해집니다. 각 크롤링 응용 프로그램의 다양한 기능을 활용하여 URL이 누락되지 않도록 하는 것이 중요합니다.
  • 여기에 이미 링크를 얻은 페이지를 포함하는 것이 중요합니다. 이를 위해서는 Search Console, Ahrefs, Semrush 및 Majestic 도구를 통해 링크된 페이지를 찾아 동일한 문서에 추가해야 합니다.

모든 URL을 얻은 후에는 단일 Excel 문서에서 아래와 유사한 그룹화된 데이터를 갖게 됩니다.

사용 가능한 URL이 포함된 다양한 Excel 시트가 있습니다. 이제 모두 하나의 파일로 결합하여 고유하게 만들 차례입니다. 일치하는 URL이 없고 현재 URL이 나열되며 중요한 URL이 누락되지 않은 문서를 계속 진행합니다. 이미지의 ALL 탭은 내가 말하는 영역을 나타냅니다.

URL 매핑(이전 – 새 URL 매핑)

URL 구조가 변경된 프로젝트에서는 기존 URL이 새 URL과 일치해야 합니다. 최선의 방법으로 이를 수행하는 SEO는 마이그레이션 프로세스가 손실 없이 원활하게 진행되도록 할 수 있습니다.

이전 단계에서 만든 문서의 기존 URL 각각에 대해 새 URL을 일치시켜야 합니다. 작성하게 될 이 문서를 IT 팀과 직접 공유하고 .htaccess 파일을 통해 리디렉션 식별을 요청할 수 있습니다. 또는 직접 할 수 있습니다.

이 단계에서 고려해야 할 중요한 사항이 있습니다.

  • 301 서버 측 리디렉션을 적용할 리디렉션에 사용해야 합니다. 이 리디렉션 유형은 페이지 X를 페이지 Y로 리디렉션하고 페이지 X의 모든 값이 페이지 Y로 전송되도록 합니다. 302, 307, JS, Meta 또는 기타 리디렉션 유형을 사용하는 것은 마이그레이션 프로세스에서 매우 중요한 실수입니다.
  • 방문자가 없고 콘텐츠가 좋지 않으며 크롤링 예산을 해치는 것으로 생각되는 URL을 URL 매핑 파일에 포함하지 마십시오. Google은 데이터 센터에 귀하의 사이트를 위한 공간을 예약했으며 귀하는 이 공간을 가장 효율적인 페이지에 사용해야 합니다. 불필요한 페이지 그룹을 식별한 경우 이 페이지가 410 상태 코드로 응답하도록 합니다.
    왜 410인가? 404와 달리 410 상태 코드는 이 페이지가 이제 삭제되었으며 다시 활성화되지 않을 것이라고 말합니다. 404 상태 코드를 사용하는 경우 Googlebot이 서버를 방문하여 동일한 페이지가 다시 활성화되는지 확인합니다. 이러한 방문을 제거함으로써 410은 크롤링 예산을 효율적으로 사용하는 중요한 솔루션입니다.
  • 여러 페이지를 한 페이지로 일괄 리디렉션하지 마십시오. 이는 사용자와 봇 모두에게 혼란을 야기합니다. 사용하지 않고 비생산적인 것으로 판명된 페이지에 대량 301을 적용하는 대신 솔루션 410을 검토하십시오.
  • 수천 페이지가 있는 전자 상거래 사이트의 마이그레이션 프로세스에 있는 경우 각 URL에 대해 일대일 매핑을 준비할 수 없습니다. 이 경우 패턴을 준비하여 IT 팀을 안내할 수 있습니다.

이미지 리디렉션

이미지는 사이트 마이그레이션 및 리디렉션 매핑에도 포함됩니다. 가장 흔한 실수 중 하나는 이미지 방향이 마이그레이션에 포함되지 않는다는 것입니다. 구글 이미지에서 획득한 순위와 값을 잃지 않기 위해서는 이미지에 대한 별도의 URL 매핑을 준비하는 것이 중요하다. 마이그레이션 작업은 페이지 기반이 아니라 URL 기반으로 봐야 합니다.

수행하는 방법?

  1. Oncrawl로 이미지 파일을 크롤링하십시오.
  2. Ahrefs, Semrush 및 Majestic으로 백링크를 얻는 이미지 소스를 분석할 수 있습니다.
  3. Search Console > 검색 유형 > 이미지를 통해 이미지가 있는 페이지를 구문 분석할 수 있습니다.
  4. 페이지에 대해 수행한 것과 동일한 Excel 형식으로 얻은 모든 URL을 수집하고 중복을 제거하고 매핑 설정을 완료하십시오.

(도메인이 변경되는 경우) Google 주소 변경 도구

모든 사전 작업을 완료하고 리디렉션을 활성화한 후 사이트를 Google로 이동하도록 지정하고 작업을 더 쉽게 만드는 도구가 있습니다. 바로 주소 변경 도구입니다. 이 도구에서 이전 사이트와 새 사이트를 선택한 후 신호가 더 짧은 시간에 처리됩니다.

  • Search Console 속성 소유권은 이전 사이트와 새 사이트 모두에 필요합니다.
  • 주소 변경은 도메인 변경에만 사용됩니다. 하위 폴더 URL 변경 또는 HTTP > HTTPS 마이그레이션에는 사용할 수 없습니다.
  • 이 변경 도구에서는 각 하위 도메인(있는 경우)을 별도로 처리해야 합니다.
  • 이러한 조건이 충족되면 Google 주소 변경 도구로 이전 사이트와 새 사이트를 선택하여 프로세스를 시작할 수 있습니다.

링크 업데이트

이제 웹사이트는 새로운 URL 구조를 갖게 됩니다. 이 경우 사이트의 모든 링크가 새 버전에서 작동해야 합니다. 사이트 내의 링크에서 이전 URL을 계속 사용하면 많은 무의미한 리디렉션이 작동합니다. 따라서 다음 링크를 확인해야 합니다.

  • 페이지 내의 모든 내부 링크
  • 표준 태그
  • -있는 경우- Hreflang 태그
  • -있는 경우- 대체 태그
  • -있는 경우- HTML Sitemap 링크
  • 소셜 미디어 프로필 링크
  • 광고 캠페인에 사용되는 방문 페이지 링크

팁 : 전체 URL 구조를 변경한 경우 XML 사이트맵 파일을 이전 URL로 한동안 유지하는 것이 좋습니다. 새 URL 구조로 별도의 XML 사이트맵을 만듭니다. 잠시 동안 Googlebot에 이전 URL을 계속 보내십시오. 이러한 방식으로 Googlebot은 이전 URL에서 리디렉션을 확인하고 색인을 생성하는 프로세스의 속도를 높입니다. 사이트 크기에 따라 XML 사이트맵 파일을 최소 1개월 이상 활성 상태로 유지하는 것이 좋습니다.

통제 수단

리디렉션이 적용된 후 이전에 얻은 이전 URL을 크롤링하여 각 URL의 상태 코드가 301인지 확인해야 합니다. 여기서 상태 코드가 301이 아닌 URL이 감지되면 빠른 조치를 취하는 것이 매우 중요합니다.

주의해야 할 기타 체크포인트:

  • Robots.txt 파일
  • 구글 애널리틱스 추적 코드
  • Search Console 확인 제어(도메인이 변경된 경우 이전 및 새 도메인의 2가지 다른 도메인으로 계속 유지되어야 함)
  • 메타 태그(NOINDEX, 팔로우)
  • 표준 태그

또한 다음 사항에 유의하십시오.

  • 가능하면 백링크 제공업체에 연락하고 기존 링크를 새 링크로 교체해야 합니다. 대규모 백링크 네트워크가 있는 경우 중요한 순서대로 계획을 세울 수 있으며 중요한 것만 연락할 수 있습니다./li>
  • 광고 캠페인에 사용된 랜딩 페이지를 검토하거나 관련 팀에 알려야 합니다.
  • 새 사이트를 크롤링하여 모든 링크가 원활하게 작동하는지 확인하고 사이트 내에서 리디렉션 루프가 발생하면 즉시 개입해야 합니다.
  • 소셜 미디어 프로필의 링크를 업데이트해야 합니다.
  • 새 페이지의 인덱싱을 따라야 합니다.
  • 키워드 실적을 모니터링해야 합니다.
  • 301 리디렉션은 곧 비활성화되어서는 안 되며 항상 활성 상태를 유지해야 합니다.
  • 도메인이 변경된 경우 기존 도메인은 최소 2년 이상 더 유지해야 합니다.
  • 오래된 데이터(URL, 로그, 키워드 실적 등)는 당분간 보관해야 합니다.
  • 거부 파일이 이전 사이트에 설치된 경우 새 도메인에도 업로드해야 합니다.

Google은 180일 동안 이전 사이트와 새 사이트 간의 라우팅 설정을 처리합니다. 180일의 기간이 지나면 이전 사이트와 새 사이트 간의 연결을 인식하지 못하고 이전 사이트가 여전히 존재하고 크롤링할 수 있는 경우 이전 사이트를 관련 없는 사이트로 취급합니다.