콘텐츠로 건너뛰기
Help centers and docs

트래픽 손실 없이 헬프 센터를 마이그레이션하는 방법

검색 트래픽 손실 없이 헬프 센터를 새 플랫폼으로 이전하세요: URL 인벤토리, 301 리다이렉트 맵, DNS 전환, 출시 점검 및 주의 사항.

Berkay Akpolat읽는 시간 13분
오래된 오두막에서 새 집으로 이어지는 길을 따라 책 상자를 옮기는 이사 업체 직원들과 화살표 표지판을 박는 세 번째 직원의 점토 일러스트

트래픽 손실 없이 헬프 센터를 마이그레이션하려면 기존 URL을 모두 유지해야 합니다. 기존 헬프 센터의 모든 주소를 나열하고, 각각을 새 페이지에 매핑한 다음, 해당 호스트네임을 새 플랫폼으로 이동하여 기존 호스트네임에서 영구(301) 리다이렉트를 제공하세요. 그런 다음 한가한 시간에 전환을 수행하고, 모든 리다이렉트를 테스트하고, 직접 관리하는 링크를 업데이트하고, 몇 주 동안 Search Console을 모니터링하세요.

2026년 11월 3일 업데이트. Zendesk Guide, Intercom Articles, Help Scout Docs, Document360, GitBook 또는 유사한 도구에서 이전하는 지원 및 문서 담당자를 위한 가이드입니다. Google의 지침은 해당 날짜 기준 Search Central에서 인용되었습니다.

헬프 센터 이전 시 트래픽이 손실되는 이유는 무엇인가요?

아티클을 복사하는 것은 쉬운 부분입니다. 트래픽은 그 사이의 공백에서 손실됩니다:

문제점 독자와 Google이 보는 것 해결책
아티클 주소가 변경되었으나 리다이렉트가 없음 404 페이지 발생; 해당 페이지가 색인에서 제외됨 모든 이전 URL에 301 설정 (2단계)
기존 도구와 함께 이전 호스트네임이 사라짐 모든 이전 링크가 즉시 실패함 호스트네임을 유지하고 새 호스트로 이동 (3단계)
모든 페이지가 새 홈페이지로 리다이렉트됨 Google이 이를 소프트 404로 처리할 수 있음 가장 가까운 페이지로 1대1 리다이렉트 설정
번역본이 남겨지거나 hreflang이 여전히 이전 URL을 가리킴 비영어권 페이지가 로컬 검색 결과에서 제외됨 각 언어별로 이동하고 hreflang 업데이트
이미지와 첨부 파일이 여전히 이전 도구에서 로드됨 계정 종료 시 스크린샷 및 다운로드 깨짐 파일을 복사하고 첨부 파일 URL도 매핑
제품, 매크로, 이메일 링크가 이전 URL을 가리킴 추가 홉 발생, 리다이렉트 제거 시 404 발생 직접 관리하는 링크 업데이트 (5단계)
새 사이트가 noindex와 함께 출시되거나 robots.txt이 이전 경로를 차단함 페이지가 색인에서 제외됨; Google이 301을 확인하지 못함 출시 점검 (7단계)

URL 변경이 포함된 사이트 이전에 대한 Google 가이드는 맵 작성으로 시작합니다: "기존 사이트의 URL을 새 사이트의 URL로 매핑하는 것이 중요합니다." Google은 영구적인 서버 측 리다이렉트(301 또는 308)를 권장합니다.

이것이 중요한 이유: 헬프 센터는 사용자가 올바른 페이지를 찾을 때만 문의를 줄일 수 있습니다. Gartner의 5,728명 고객 대상 설문조사(2024년 8월 발표)에 따르면, 서비스 문제의 14%만이 셀프 서비스로 완전히 해결되었으며, 실패 사례의 43%는 고객이 자신의 문제와 관련된 콘텐츠를 찾지 못한 경우였습니다. 독자를 404 페이지에 머물게 하는 마이그레이션은 이 수치를 높일 뿐입니다. 더 많은 수치는 고객 셀프 서비스 통계에서 확인할 수 있습니다.

1단계: 헬프 센터의 모든 URL을 나열하려면 어떻게 해야 하나요?

기존 주소당 한 행씩 포함된 스프레드시트를 하나 만드세요. 각 소스마다 누락되는 정보가 있을 수 있으므로 여러 소스를 사용하세요:

  • 사이트맵. 대부분의 호스팅형 헬프 센터는 sitemap.xml을 게시하며, 종종 언어별로 파일이 하나씩 있습니다. 지금 모든 사이트맵 파일을 다운로드하세요: DNS가 이동하면 이전 플랫폼은 더 이상 해당 호스트네임에서 파일을 제공하지 않습니다.
  • Search Console. 페이지 및 실적 보고서를 내보내세요(가장 긴 기간 설정). 내보내기는 1,000개 행에서 중단되므로, 더 큰 헬프 센터의 경우 Search Console API나 목록 모드의 크롤러를 사용하세요. 지금 헬프 센터 호스트네임을 확인하여(도메인 속성은 모든 하위 도메인을 포함함) 이전 전 기준 데이터를 확보하세요.
  • 플랫폼의 API 또는 내보내기. 아티클 ID, 섹션 ID 및 모든 언어 정보를 제공합니다. Zendesk는 Help Center API, Intercom은 REST API(내보내기 버튼 없음), Help Scout는 Docs API, Document360은 Markdown, HTML 또는 JSON 형식의 ZIP 내보내기를 지원합니다.
  • 첨부 파일 및 포함된 파일. 아티클에 첨부된 PDF 및 다운로드 파일에도 백링크가 포함되어 있습니다. 해당 URL을 목록에 추가하세요.
  • 분석 및 백링크. 가장 많이 방문하는 랜딩 페이지와 다른 사이트에서 링크된 페이지는 절대 깨져서는 안 되는 페이지입니다.

아티클 ID, 언어, 월간 클릭 수, 백링크, 새 URL 및 "테스트 완료" 열을 추가하세요. 클릭 수 기준으로 정렬하세요.

2단계: 리다이렉트 맵은 어떻게 만드나요?

각 플랫폼마다 고유한 URL 패턴이 있습니다. 아티클 ID를 사용하면 이전 페이지와 새 페이지를 쌍으로 연결할 수 있습니다:

플랫폼 아티클 URL 패턴 매핑 대상
Zendesk Guide (현 Zendesk Knowledge) /hc/en-us/articles/360001234567-Reset-your-password 섹션 및 카테고리 페이지, 첨부 파일, 모든 로케일(/hc/de/…)
Intercom Articles /en/articles/1234567-reset-your-password 컬렉션 페이지 및 기타 언어 접두사
Help Scout Docs /article/123-reset-your-password 카테고리 및 컬렉션 페이지
Document360 /docs/reset-your-password 또는 /v1/docs/… 카테고리 페이지 및 언어 경로
GitBook, Mintlify, Docusaurus 페이지 트리를 따르는 경로 이전 버전 및 이동한 페이지

패턴은 2026년 11월 3일 기준 각 공급업체의 헬프 센터 또는 문서에 나타난 형태이며, 사용자가 커스터마이징한 경우 다를 수 있습니다.

순위를 유지하기 위한 규칙:

  1. 기존 URL 1개당 새 URL 1개. 각 아티클을 고유한 새 페이지로 연결하세요. Google은 많은 이전 URL을 홈페이지와 같은 단일 페이지로 보내는 것은 "소프트 404 오류로 처리될 수 있다"고 경고합니다.
  2. 트래픽이 발생하는 변형을 포함하세요. 이전 링크에는 종종 이전 슬러그가 포함되어 있거나 아예 없을 수 있습니다(Zendesk는 슬러그 없이 /hc/en-us/articles/360001234567도 제공함). 새 플랫폼이 패턴 또는 와일드카드 리다이렉트를 지원하는 경우 ID를 기준으로 매칭하세요. 정확한 경로만 일치하는 경우, Search Console, 분석 및 백링크에 실제로 나타나는 변형에 대한 행을 추가하세요.
  3. 언어당 한 행. /hc/de/articles/…은 영어 페이지가 아닌 독일어 페이지로 연결되어야 합니다.
  4. 체인 금지. Google 크롤러는 최대 10개의 홉을 따라가지만, 가이드에서는 체인을 피하고 최종 페이지로 직접 리다이렉트할 것을 권장합니다. 이전에 마이그레이션한 적이 있다면 해당 이전 리다이렉트도 업데이트하세요.
  5. 의도적으로 페이지 폐기. 아티클이 삭제되어 대체 페이지가 없는 경우 404 또는 410을 반환하도록 하세요. Google의 크롤링 오류 가이드에 따르면 페이지가 "이동했거나 명확한 대체 페이지가 있는 경우" 301을 반환해야 합니다.

플랫폼을 선택하기 전에 개수를 확인하세요. 아티클 수 × 언어 수, 여기에 섹션, 카테고리, 첨부 파일 및 슬러그 변형을 더하세요. 3개 언어로 된 300개 아티클의 헬프 센터는 다른 작업을 수행하기 전에 약 900개의 아티클 리다이렉트가 필요합니다. 일부 플랫폼은 요금제별로 사이트당 리다이렉트 수를 제한하며, 일부는 가져오기 실패 없이 제한을 초과하는 리다이렉트를 건너뜁니다.

3단계: 동일한 헬프 센터 도메인을 유지해야 하나요?

가능하다면 항상 유지하세요. 리다이렉트는 요청에 응답하는 호스트네임에서만 실행됩니다. 헬프 센터가 help.yourcompany.com에 있는 경우 해당 호스트네임을 유지하고, 전환 시 DNS 변경(일반적으로 CNAME)을 통해 새 플랫폼을 가리키도록 하세요. 그러면 새 플랫폼이 이전 경로에 대해 301로 응답하므로 기존 링크, 북마크 및 검색 결과가 계속 작동합니다.

URL이 동일하게 유지되면 Google은 이를 URL 변경이 없는 사이트 이전으로 처리합니다. 동일한 호스트네임에서 경로만 변경되는 경우 301 맵은 필요하지만 Search Console의 주소 변경 도구는 필요하지 않습니다.

기존 고객 센터 위치 조치 사항
자체 서브도메인 (help.yourcompany.com) 유지하세요. 새 플랫폼에 리디렉션 맵을 로드한 다음, 전환 시점에 서브도메인을 이동하세요(6단계).
Zendesk의 공급업체 주소만 사용 (yourcompany.zendesk.com/hc/…) Guide가 활성화되어 있는 동안, Zendesk의 Redirect Rules API를 사용하여 404를 반환하는 문서 URL을 전체 외부 URL로 보낼 수 있습니다. Guide Lite Legacy를 제외한 모든 Guide 플랜에서 브랜드당 최대 50,000개의 규칙을 지원하며, 보관되거나 삭제된 문서에 적용됩니다. 즉, 리디렉션을 유지하는 동안에는 Guide를 계속 활성화해야 합니다.
Intercom의 공급업체 주소만 사용 (intercom.help/yourcompany) Intercom의 리디렉션은 동일한 고객 센터 내부로만 연결됩니다. 우회 방법: 먼저 Intercom에 자체 서브도메인을 연결한 다음(기존 intercom.help 링크를 해당 도메인으로 리디렉션), 해당 서브도메인을 새 플랫폼으로 이동하세요. 그 이후에도 intercom.help 링크가 계속 리디렉션되는지는 문서화되어 있지 않으므로 테스트가 필요합니다.
Help Scout의 공급업체 주소만 사용 Help Scout Docs 리디렉션은 외부 주소로 연결할 수 있습니다. curl -I를 사용하여 상태 코드를 확인하세요. 관련 내용은 문서화되어 있지 않습니다.
의도적으로 새 호스트 이름 사용 (support.에서 help.로) 이전 호스트 이름은 계속 301 리디렉션을 제공해야 합니다. Search Console에서 두 호스트 이름을 모두 확인하고 주소 변경 도구를 사용하세요. 이 도구는 도메인 또는 서브도메인 수준에서 작동하며(경로 이동은 불가), 이전 홈페이지에서 새 홈페이지로의 301 리디렉션이 필요합니다.

결론적으로, 가능하다면 호스트 이름 변경은 피하세요. SEO 에이전시 SALT.agency가 1,052건의 도메인 마이그레이션을 분석한 결과(2026년 6월), 마이그레이션 이전의 트래픽 수준을 회복하는 데 중앙값 기준 304일이 소요되었습니다. 이는 고객 센터 교체가 아닌 전체 도메인 이동 사례이지만, 기존 주소가 변경될 때 어떤 위험이 따르는지 잘 보여줍니다.

4단계: 콘텐츠 자체는 어떻게 이동하나요?

새 플랫폼에 기존 도구용 가져오기 기능이 있다면 이를 사용하세요. 그렇지 않다면 기존 도구의 API를 통해 내보낸 후 Markdown이나 HTML로 변환해야 합니다. Zendesk Guide에는 내보내기 버튼이 없습니다. Help Center API(문서, 섹션, 카테고리, 번역) 또는 마켓플레이스 앱을 통해 내보내야 합니다. 가져오기 후 다음 사항을 확인하세요:

  • 구조: 카테고리, 섹션 및 순서. 깊은 트리 구조는 평면화될 수 있습니다.
  • 이미지 및 첨부 파일: 이전 도구의 저장소에 핫링크를 거는 것이 아니라 새 플랫폼으로 복사되어야 합니다. 제한된 Zendesk 문서의 이미지는 인증된(API) 다운로드가 필요합니다.
  • 번역: 각 언어는 원본에 연결된 별도의 페이지로 도착합니다. 동시에 언어를 추가하는 경우 고객 센터와 동영상을 번역하는 방법을 참조하세요.
  • 내부 링크: 문서 간의 링크가 새 주소를 가리키도록 합니다.
  • 제한된 콘텐츠: 초안, 내부 메모 및 특정 사용자에게만 제한된 문서. 실수로 공개되는 항목이 없는지 확인하세요.

이 시점부터 전환 시점까지는 기존 도구의 편집을 중단하거나, 전환 직전에 변경 사항을 다시 가져오세요.

리디렉션은 외부 링크를 처리합니다. 직접 소유한 링크는 새 URL을 직접 가리켜야 합니다:

  • 제품 내부의 도움말 링크 및 툴팁
  • 저장된 답변, 매크로 및 상용구
  • 채팅 위젯의 추천 문서, 그리고 고객 센터를 기반으로 답변하는 모든 AI 에이전트나 챗봇(지식 소스를 새 사이트로 지정)
  • 온보딩 및 라이프사이클 이메일
  • 웹사이트 푸터, 상태 페이지 및 문서 링크
  • 고객 센터 주소를 보여주는 동영상 및 PDF

6단계: 중단 없이 전환하려면 어떻게 해야 하나요?

시기 조치 사항
1주일 전 DNS 레코드의 TTL을 몇 시간 단위로 낮추세요(Google의 호스트 이동 가이드는 최소 1주일 전에 수행할 것을 권장합니다). 기존 사이트맵을 저장하세요. Search Console 액세스 권한을 확인하세요.
전날 기존 도구의 편집을 중단하고 변경 사항을 다시 가져오세요. 새 플랫폼의 임시 주소에서 리디렉션 맵 전체를 테스트하세요(해당 주소에서 리디렉션을 제공하는 경우).
전환 시점(한가한 시간대) CNAME을 변경하세요. 대부분의 호스팅 플랫폼은 DNS가 해당 플랫폼을 가리킨 후에만 HTTPS 인증서를 발급하므로, 몇 분 정도 소요될 수 있습니다. 일부 플랫폼은 프록시나 CNAME 플래트닝 없이 일반 CNAME이 필요합니다.
직후 전체 리디렉션 테스트를 실행하세요(7단계).
향후 30일간 모니터링을 수행하세요(아래 참조).

7단계: 출시 당일 무엇을 확인해야 하나요?

  • 샘플이 아닌 맵의 모든 행을 테스트하세요. 목록 모드의 크롤러나 체크리스트 아래의 짧은 루프를 사용하면 몇 분 안에 완료됩니다. 각 이전 URL은 302가 아닌 301(또는 308)을 반환하고 한 번의 홉으로 새 URL에 도달해야 합니다.
  • 모든 언어에서 가장 많이 방문한 이전 URL 20개를 수동으로 열어 올바른 페이지인지 확인하세요.
  • 각 새 페이지에는 자체 참조 canonical 태그가 있어야 하며, 언어 버전은 새 URL에서 hreflang으로 서로 연결되어야 합니다.
  • robots.txt은 이전 경로(예: /hc/)를 포함하여 크롤링을 허용하므로 Google이 301 리디렉션을 확인할 수 있습니다. 실수로 noindex이 포함된 페이지가 없어야 합니다.
  • Search Console에 새 사이트맵을 제출하세요. Google은 리디렉션을 다시 크롤링할 수 있도록 이전 사이트맵도 제출할 것을 권장합니다. 더 이상 호스팅할 수 없는 경우 URL 검사 도구를 사용하여 상위 이전 URL을 확인하세요.
  • 새 사이트에서 검색, AI 어시스턴트, 피드백 및 문의 양식이 작동하는지 확인하세요.

이 루프는 한 줄에 이전 URL과 새 URL이 포함된 파일을 읽고, 각 이전 URL의 상태 코드와 리디렉션 위치를 출력합니다:

while read old new; do
  curl -s -o /dev/null -w "%{http_code} %{redirect_url} $old\n" "$old"
done < map.tsv

리디렉션을 얼마나 오래 유지해야 하나요?

Google의 답변: "리디렉션은 가능한 한 오래, 일반적으로 최소 1년 이상 유지하세요." 실제로는 고객 센터를 운영하는 동안 계속 유지하는 것이 좋습니다. 이전 링크는 포럼 답변, 지원 이메일 및 기타 사이트에서 수년간 살아남으며, 리디렉션을 유지하는 데는 비용이 들지 않습니다.

첫 몇 주 동안 무엇을 지켜봐야 하나요?

Google은 "이동 중 사이트 순위의 일시적인 변동을 예상"해야 하며 "소규모에서 중규모 웹사이트의 경우 대부분의 페이지가 이동하는 데 몇 주가 걸릴 수 있다"고 말합니다. 매주 다음 사항을 확인하세요:

  • Search Console, 페이지: 새로운 "찾을 수 없음(404)" 항목은 누락된 리디렉션을 가리킵니다.
  • Search Console, 실적: 이전 URL의 클릭이 감소함에 따라 새 URL의 클릭이 증가해야 합니다.
  • 리디렉션 히트: 어떤 이전 URL이 여전히 트래픽을 발생시키는지, 어디에서 발생하는지 확인하세요.
  • 새 고객 센터의 검색 결과 없음: 독자들이 무엇이 누락되었는지 알려줍니다. 고객 센터 콘텐츠 격차에 대한 가이드를 통해 이를 해결하는 방법을 확인하세요.

Clevera는 고객 센터 마이그레이션을 어떻게 처리하나요?

Clevera는 화면 녹화를 내레이션이 포함된 사용 방법 동영상, 단계별 도움말 문서, 그리고 74개 언어로 제공되는 호스팅 고객 센터 페이지로 변환하는 AI 플랫폼입니다. 모든 플랜에서 현재 사용 중인 도구로부터 고객 센터를 무료로 가져올 수 있습니다.

Clevera의 새 고객 센터 마법사: 다른 도구에서 가져오기 선택 및 플랫폼 목록에서 Zendesk 선택됨
가져오기를 통해 새 고객 센터 시작하기
  • 가져오기 도구: Zendesk, Intercom, Help Scout, Document360, GitBook, ReadMe, Mintlify, Docusaurus, Notion, Confluence 또는 기타 공개 문서 사이트나 Markdown/HTML 압축 파일. 플랫폼에 따라 API 토큰, 공개 사이트, Git 저장소 또는 압축 파일을 통해 연결합니다. Intercom은 공개 사이트에서만 읽어오므로 비공개 Intercom 문서는 가져올 수 없습니다. Zendesk나 Document360 토큰을 사용하면 사이트에 추가한 언어별 번역본도 함께 가져옵니다. Zendesk Guide에서 가져오기, Intercom Articles, Help Scout, Document360 가이드를 참조하세요.
  • 기존 주소 리디렉션: 소스에 웹 주소가 있는 경우 기존 주소에서 리디렉션 생성이 기본적으로 켜져 있으며, Help Scout 자체 리디렉션도 함께 가져옵니다. 이는 사용자의 도메인이 Clevera를 가리키면 작동합니다. 리디렉션은 정확한 경로와 일치해야 하므로(와일드카드 미지원), 여전히 클릭이 발생하는 슬러그 변형은 수동 리디렉션으로 추가하세요.
  • 사전 검토: 페이지 선택 해제 미리보기, 경고 보고서, 그리고 가져온 페이지를 게시하기 전까지 사용할 수 있는 가져오기 취소 기능을 제공합니다. 소스에서 공개되지 않은 것으로 표시된 페이지는 제한됨으로 표시되며 선택 해제된 상태로 시작됩니다.
  • 트래픽 유지 여부를 결정하는 제한 사항:
    • 리디렉션에는 사용자 고유 도메인이 필요하며, 이는 Starter 요금제 이상에서 지원되므로 Free 요금제에서는 기존 링크가 리디렉션되지 않습니다.
    • 가져오기 시 생성되는 리디렉션은 요금제의 수동 리디렉션 제한에 포함되며, 제한을 초과하는 항목은 건너뜁니다: Starter는 사이트당 500개, Pro는 2,000개입니다. 사이트당 최대 2,000개까지 가능합니다.
    • 사이트당 게시 가능한 언어: Starter는 5개, Pro는 전체.
    • 가져오기당 2,000페이지 제한.
    • 페이지 이름을 변경하거나 이동할 때 Clevera가 나중에 추가하는 리디렉션은 자동이며 제한에 포함되지 않습니다.
Clevera 헬프 센터의 리디렉션 화면: 이전 경로와 새 주소, 자동 또는 수동 여부, 301 또는 302 상태, 조회수
리디렉션 조회수를 통해 여전히 트래픽이 발생하는 이전 링크를 확인할 수 있습니다

이전 후에는 검색 기능, 게시된 페이지를 바탕으로 출처와 함께 독자의 질문에 답하는 Ask AI 어시스턴트, 사이트맵, llms.txt(문서를 AI에 최적화하는 방법 참고), 그리고 검색 결과가 없었던 검색어에 대한 인사이트를 이용할 수 있습니다. 언제든지 사이트 전체를 HTML 또는 Markdown으로 내보낼 수 있습니다. Pro 및 Custom에서는 Autopilot이 릴리스를 확인하고 영향을 받는 문서와 동영상의 업데이트를 계획하면, 이를 검토하고 승인할 수 있습니다.

Clevera가 적합하지 않은 경우: 기존 헬프 센터의 리디렉션할 주소가 2,000개를 초과하는 경우, 메인 사이트의 폴더 내에 위치해야 하는 경우(example.com/help; Clevera는 서브도메인만 연결 가능), 티켓팅 도구 내부에 유지해야 하는 경우, 또는 사용자 지정 사용자 세그먼트와 같은 Zendesk 전용 기능에 의존하는 경우입니다. SaaS를 위한 최고의 헬프 센터 소프트웨어 및 Zendesk Guide 대안 비교 자료에서 다른 옵션을 확인하고, 지식 베이스 구축 방법에서 목표로 할 구조를 확인하세요.

이동 전 가져오기 테스트

헬프 센터 사본을 무료 Clevera 헬프 센터로 가져와 결과를 검토하세요. 결정하기 전까지는 기존 도구나 DNS에 아무런 변경 사항이 없습니다.

전체 단계는 문서 사이트 가져오기 및 내보내기에 있으며, 헬프 센터 소프트웨어 페이지에서 이동 후 제공되는 기능을 확인할 수 있습니다.

FAQ

헬프 센터 소프트웨어를 변경하면 Google 순위가 떨어지나요?

모든 이전 URL이 일치하는 페이지로 리디렉션되고 콘텐츠가 동일하게 유지된다면 보통 잠시 동안만 영향을 받습니다. Google은 "일시적인 변동"이 있을 수 있다고 언급합니다. 지속적인 순위 하락은 주로 404 오류, 홈페이지로의 리디렉션, 또는 응답하지 않는 이전 호스트 이름으로 인해 발생합니다.

URL을 정확히 그대로 유지할 수 있나요?

거의 불가능합니다. 대부분의 플랫폼은 고유한 URL 패턴을 사용하므로 /hc/en-us/articles/…을 재현할 수 없습니다. 선택하기 전에 문의하세요. 전체 301 맵을 사용하여 호스트 이름을 유지하면 독자와 검색 엔진에 동일한 결과를 제공할 수 있습니다.

헬프 데스크 마이그레이션과 헬프 센터 마이그레이션의 차이점은 무엇인가요?

헬프 데스크 마이그레이션은 일반적으로 마이그레이션 서비스를 통해 지원 도구 간의 티켓, 연락처, 매크로를 이동합니다. 헬프 센터 마이그레이션은 독자가 검색에서 찾는 공개 문서를 이동하므로 URL, 리디렉션 및 도메인 작업이 핵심입니다. 각각 별도로 진행할 수 있습니다.

티켓도 함께 이동해야 하나요?

아니요. 헬프 센터는 받은 편지함, 티켓 기록, 채팅을 그대로 둔 채 독립적으로 이동할 수 있습니다. 위젯, 매크로, AI 에이전트를 새 헬프 센터로 연결하기만 하면 됩니다.

301 리디렉션을 사용해야 하나요, 302 리디렉션을 사용해야 하나요?

301 또는 308을 사용하세요. Google은 이를 영구적인 것으로 간주하고 새 페이지를 표준(canonical) 페이지로 사용합니다. 302는 이동이 일시적임을 의미합니다.

헬프 센터 마이그레이션은 얼마나 걸리나요?

가져오기 자체는 몇 분이면 완료됩니다. URL 인벤토리, 검토 및 테스트에 며칠, DNS TTL을 위한 일주일의 준비 기간, 그리고 이후 몇 주간의 모니터링 계획을 세우세요.

기존 도구의 AI 답변은 어떻게 되나요?

기존 도구에 그대로 남습니다. 새 플랫폼이 문서에서 독자에게 답변을 제공하는지, 어떤 요금제에 포함되어 있는지, 답변당/해결당 비용이 청구되는지 혹은 월간 허용량 내에 포함되는지 확인하세요.