도메인 이전 SEO 체크리스트, 순위 안 잃고 옮기는 법

도메인을 통째로 바꾸는 이전은 URL 구조만 정리하는 리뉴얼과 완전히 다른 위험도를 가진다. URL 경로만 바뀌는 개편은 리다이렉트와 사이트맵 갱신이면 충분하지만, 도메인 자체가 바뀌면 구글이 사이트 전체의 신뢰도를 처음부터 다시 확인한다. 이 차이를 모르고 리뉴얼과 똑같은 방식으로 접근하면 순위가 예상보다 훨씬 크게, 오래 흔들린다.

브랜드명을 바꾸거나 .co.kr에서 .com으로 옮기는 결정 자체는 문제가 아니다. 문제는 준비 없이 도메인부터 바꾸고 SEO 작업을 나중으로 미루는 순서다. 도메인 이전은 되돌리기가 어렵다는 점도 리뉴얼과 다르다. URL 구조 개편은 잘못되면 다시 예전 구조로 되돌릴 수 있지만, 도메인을 두 번, 세 번 옮기면 그때마다 구글이 다시 신뢰도를 확인하는 절차를 거치므로 손실이 누적된다.

이 글은 이전 전 준비, 서치콘솔 주소 변경 알림 도구 사용법, DNS 전환 타이밍, 이전 당일 순서, 실제 회복까지 걸리는 기간을 실무 순서 그대로 정리했다. 이미 도메인 이전을 결정했다면 아래 순서를 그대로 체크리스트로 써도 된다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• 도메인 이전은 구글 서치 콘솔의 주소 변경 알림 도구를 반드시 거쳐야 한다 — 단순히 새로 등록만 해서는 신호가 이어지지 않는다
• 이 도구는 도메인 단위 속성에서만 쓸 수 있고, 하위 폴더 속성이나 서브도메인에는 자동 적용되지 않는다
• 구글은 옛 도메인과 새 도메인의 이전 관계를 약 180일만 인식한다 — 그 안에는 301 리다이렉트를 반드시 유지해야 한다
• DNS는 전환 24–48시간 전에 TTL(캐시 유지 시간)을 300초로 낮춰야 전환 중 끊김을 줄일 수 있다
• 실제 트래픽 회복까지는 평균 3–12개월이 걸린다는 점을 미리 각오해야 한다 — 1,052건 분석 기준 회복 중앙값은 304일이었다

도메인 이전과 URL 구조 개편, 뭐가 다른가?

도메인이 바뀌면 구글은 사이트 전체를 사실상 새로 평가한다는 점이 가장 큰 차이다. URL 경로만 바뀌는 개편(예: /category/product → /shop/product)은 같은 도메인 안에서 신호가 그대로 이어지므로 회복이 비교적 빠르다. 반면 도메인 자체가 바뀌면(oldsite.co.kr → newsite.com) 도메인 등록 이력, 그동안 쌓인 백링크의 신뢰도, 오랜 기간 축적된 브랜드 신호까지 전부 새 주소로 다시 이어 붙어야 한다.

도메인은 검색엔진 입장에서 하나의 '신원'과 같다. 오래된 도메인일수록, 꾸준히 양질의 콘텐츠를 발행해 온 도메인일수록 구글은 더 높은 신뢰도를 부여한다. 이 신뢰도는 도메인이라는 주소 자체에 쌓이기 때문에, 콘텐츠와 디자인이 100% 동일하더라도 주소만 바뀌면 그 신뢰도를 처음부터 다시 증명해야 하는 구조다. 이 사실을 모른 채 "내용은 똑같으니 순위도 똑같이 유지되겠지"라고 기대하면 실제 결과와 크게 어긋난다.

경영진이나 마케팅 담당자 입장에서는 "도메인 이름만 바꾸는 건데 왜 이렇게 절차가 복잡하냐"고 되물을 수 있다. 하지만 실무 담당자라면 이 질문에 정확히 답할 수 있어야 한다. 겉으로는 주소 하나만 바뀌는 것처럼 보여도, 검색엔진 입장에서는 그동안 쌓아 온 신뢰의 이력서를 통째로 새로 제출하는 것과 같다. 이 관점을 이해관계자와 미리 공유해 두면, 이전 후 일시적인 트래픽 하락을 두고 성급하게 판단을 내리는 상황을 막을 수 있다.

변경 유형	예시	주소 변경 알림 도구 필요 여부	예상 난이도
URL 경로만 변경	같은 도메인, /old → /new	불필요	낮음
서브도메인 변경	blog.a.com → a.com/blog	별도 처리 필요	중간
도메인 자체 변경	a.co.kr → a.com	필수	높음

URL 경로만 바꾸는 리뉴얼은 웹사이트 리뉴얼 SEO 체크리스트에서 따로 다뤘다. 이 글은 도메인 자체가 바뀌는, 더 큰 변화에 집중한다.

도메인 이전을 SEO 때문에 해도 될까?

아니다. 단순히 "SEO에 더 좋아 보여서" 도메인을 옮기는 것은 권하지 않는다. 이미 순위와 트래픽이 안정적으로 나오는 도메인이 있다면, 그 신뢰도는 시간을 들여야만 쌓이는 자산이다. .com이 .co.kr보다 검색 순위에서 본질적으로 유리하다는 근거는 없다. 확장자 자체는 순위 요인이 아니고, 콘텐츠 품질과 사용자 경험, 백링크가 순위를 좌우한다.

도메인 이전은 사업적으로 반드시 필요한 이유(리브랜딩, 인수합병, 법인 통합 등)가 있을 때만 진행하는 것이 맞다. 이유가 애매하다면 지금 도메인을 그대로 유지하면서 콘텐츠와 기술적 SEO를 개선하는 쪽이 훨씬 안전하고 빠르게 성과로 이어진다.

도메인 이전이 필요한 경우는 어떤 때인가?

실무에서 도메인을 통째로 바꾸는 경우는 크게 세 가지로 나뉜다. 어떤 이유든 "일단 옮기고 보자"는 없다 — 이전 전 준비 기간을 충분히 확보하는 것이 순위를 지키는 첫걸음이다.

• 리브랜딩(사명·서비스명 변경): 회사명이 바뀌어 도메인도 그에 맞춰 바꿔야 하는 경우다. 예를 들어 "OO컴퍼니"에서 "OO랩스"로 사명을 바꾸면서 oocompany.com을 oolabs.com으로 옮기는 식이다. 이 경우는 콘텐츠는 그대로 두고 주소만 옮기는 것이 가장 안전하다.
• 확장자 변경(.co.kr → .com 등): 해외 진출이나 브랜드 통일을 위해 국가 도메인에서 일반 도메인으로 옮기는 경우다. 국내 검색 노출에는 확장자 자체가 큰 영향을 주지 않지만, 도메인이 바뀐다는 사실 자체는 동일하므로 절차는 똑같이 챙겨야 한다.
• 인수합병·사업 통합: 여러 브랜드 사이트를 하나의 도메인으로 합치는 경우다. 예를 들어 A사가 B사를 인수해 B사의 제품 페이지들을 A사 도메인 아래로 옮기는 경우가 여기에 해당한다. 이 경우는 단순 이전이 아니라 콘텐츠 통폐합까지 함께 일어나므로 변수가 가장 많고, 매핑 작업에 특히 더 신경 써야 한다.

세 경우 모두 공통점이 있다. 이전 사유와 무관하게, 준비 절차와 리다이렉트 원칙은 동일하게 적용된다는 것이다. "이번엔 작은 변경이니까 대충 해도 되겠지"라는 예외는 없다.

도메인을 처음 정할 때 어떤 확장자·이름을 고를지 고민이라면 도메인 선택 가이드를 먼저 참고하는 것이 좋다.

이전 전에 무엇부터 준비해야 하나?

이전을 시작하기 전, 지금 사이트의 상태를 통째로 기록해 두는 것이 가장 먼저 할 일이다. 나중에 무엇이 잘못됐는지 비교할 기준이 없으면 문제를 찾을 수도, 해결할 수도 없다.

• 전체 URL과 상태 코드 목록: 크롤링 도구로 현재 사이트의 모든 URL을 수집해 둔다. 페이지 수가 많은 사이트일수록 이 목록이 곧 매핑 작업의 원본 데이터가 된다.
• 핵심 키워드 순위: 상위 50–100개 키워드의 현재 순위를 기록해 둔다. 이전 후 순위 변화를 비교할 기준이 없으면 "정상적인 흔들림"인지 "실수로 인한 손실"인지 구분할 수 없다.
• 최근 12개월 트래픽·전환 데이터: 서치콘솔·애널리틱스 데이터를 미리 내려받는다. 특히 페이지별·유입경로별 트래픽은 리다이렉트 우선순위를 정하는 데 쓰인다.
• 백링크 목록: 어떤 페이지가 외부 링크를 많이 받고 있는지 확인해, 그 페이지들의 매핑을 특히 신경 쓴다. 백링크가 많은 페이지의 매핑이 잘못되면 그동안 쌓은 링크 자산을 그대로 날리는 셈이다.
• 구조화 데이터 문서화: Organization, Article, FAQ 등 현재 적용된 스키마를 정리해 둔다. 새 도메인 템플릿에서 스키마 코드가 누락되는 실수가 의외로 흔하다.

새 도메인 쪽에서도 미리 준비할 것이 있다. 새 도메인의 서치콘솔 속성을 미리 등록하고 소유권 확인까지 끝내 둬야 한다. SSL 인증서 발급, robots.txt 초안 준비도 이전 당일이 아니라 사전에 끝내는 것이 안전하다. 새 도메인의 이메일(회사 메일 계정)도 함께 옮겨야 한다면, MX 레코드 전환 일정까지 같은 계획표 안에 넣어야 실수 없이 진행된다.

새 도메인 속성은 이전 최소 몇 주 전에 미리 만들어 소유권 확인까지 마쳐 둬야 한다. 이전 당일에 부랴부랴 등록하면 인증 지연 때문에 전체 일정이 밀린다.

팀 안에서 역할도 미리 나눠 둬야 한다. 개발자는 리다이렉트 규칙 구현과 DNS 전환을, SEO 담당자는 매핑 시트 작성과 서치콘솔 재설정을, 콘텐츠 담당자는 내부 링크와 이미지 경로 점검을 맡는 식으로 책임을 명확히 해야 "누군가 하겠지"라는 이유로 놓치는 작업이 없다.

리다이렉트 매핑은 어떻게 만들어야 하나?

모든 기존 URL이 새 도메인의 대응 URL로 1대1 301 리다이렉트되도록 매핑 시트를 만드는 것이 이전 작업의 핵심이다. 301과 302의 차이, 리다이렉트 체인 같은 기본 개념은 301 리다이렉트 가이드에서 자세히 다뤘으므로, 여기서는 도메인 이전에 특화된 매핑 원칙만 짚는다.

• 나쁜 예: 대응 페이지를 찾기 귀찮아 여러 페이지를 전부 새 도메인의 홈으로만 리다이렉트한다. 302로 임시 연결해 두고 몇 달째 방치한다. 예전 사이트맵을 그대로 새 도메인에 제출한다.
• 좋은 예: 페이지 단위로 1대1 매핑하고, 대응 페이지가 없어졌다면 가장 관련성 높은 카테고리 페이지로 연결한다. 처음부터 301로, 체인 없이 한 번에 최종 목적지로 보낸다. 새 도메인의 sitemap.xml을 새로 생성해 제출한다.

매핑 시트는 아래처럼 기존 URL, 신규 URL, 트래픽 규모를 한 줄씩 정리한 표로 만드는 것이 가장 다루기 쉽다. 이 표가 곧 개발자에게 전달할 리다이렉트 규칙의 설계도가 된다.

기존 URL(oldsite.co.kr)	신규 URL(newsite.com)	리다이렉트	월 트래픽
/product/a	/products/a	301	320
/product/b, /product/c	/products/master	301(다대일)	180
/about-us	/company	301	90
/event/2024-summer	/promotions(관련 카테고리)	301	12

대응 페이지를 전부 홈으로 몰아 리다이렉트하는 것은 사실상 리다이렉트를 안 한 것과 같은 결과를 낸다. 구글은 이런 패턴을 "소프트 404"에 가깝게 취급해, 옛 페이지가 쌓아 온 신호를 새 페이지로 넘겨주지 않는다.

모든 URL을 다 리다이렉트해야 하나?

아니다. 트래픽도 없고 백링크도 없는 낡은 페이지까지 억지로 리다이렉트할 필요는 없다. 오래전에 종료된 이벤트 페이지, 품절된 지 오래된 단종 상품 페이지처럼 더 이상 가치가 없는 URL은 리다이렉트 대신 새 도메인에서 자연스럽게 404(페이지 없음)로 처리해도 무방하다.

다만 판단 기준은 명확해야 한다. 트래픽, 백링크, 순위 중 하나라도 남아 있는 페이지라면 리다이렉트 대상에 포함한다. 판단이 애매한 페이지는 일단 리다이렉트 대상에 넣어 두는 것이 안전하다. 리다이렉트를 과도하게 많이 만드는 것보다, 가치 있는 페이지를 놓치는 실수의 대가가 훨씬 크기 때문이다.

모든 URL을 홈페이지 하나로 리다이렉트하는 것은 "리다이렉트를 아예 안 만든 것"과 결과가 비슷하다는 점을 다시 한번 기억해야 한다. 개별 페이지의 관련성을 살려 매핑하는 것이 핵심이다.

리다이렉트가 제대로 걸렸는지는 어떻게 확인하나?

브라우저 개발자 도구의 네트워크 탭이나 명령줄의 curl -I 명령으로 응답 상태 코드를 직접 확인하는 것이 가장 정확하다. 눈으로 페이지가 잘 열리는 것만 확인하고 넘어가면, 실제로는 200(정상)이 아니라 200으로 위장된 오류 페이지이거나, 301이 아니라 302로 걸려 있는 경우를 놓치기 쉽다.

• 좋은 예: 매핑 시트의 URL을 하나씩 curl -I로 확인해, 응답 헤더에 HTTP/1.1 301 Moved Permanently와 정확한 Location 값이 찍히는지 확인한다.
• 나쁜 예: 브라우저로 몇 개만 클릭해 보고 "잘 열리네"라며 전체가 정상이라고 넘겨짚는다. 브라우저는 리다이렉트 체인을 자동으로 따라가 최종 화면만 보여 주므로, 중간에 체인이 몇 번 걸렸는지는 눈으로 구분되지 않는다.

리다이렉트 체크 전용 무료 도구(브라우저 확장 프로그램, 온라인 리다이렉트 체커)를 쓰면 상태 코드와 체인 경로를 한눈에 볼 수 있어 대량의 URL을 검증할 때 특히 유용하다.

구글 서치 콘솔 주소 변경 알림 도구는 어떻게 쓰나?

주소 변경 알림 도구(Change of Address tool)는 같은 구글 계정으로 옛 도메인과 새 도메인 속성을 모두 소유·인증했을 때만 쓸 수 있다. 이 도구는 도메인 단위 속성에서만 동작하며, 하위 폴더 속성에는 적용되지 않는다. 또한 지정한 도메인만 처리하므로 www와 비www, 블로그 서브도메인 등은 각각 별도로 처리해야 한다.

절차는 다음 순서로 진행한다.

1. 새 도메인 속성을 서치콘솔에 등록하고 소유권을 확인한다.
2. 301 리다이렉트를 실제로 적용 완료한 뒤 진행한다. 리다이렉트가 아직 안 된 상태면 도구가 진행을 막는다.
3. 옛 도메인 속성 설정에서 "주소 변경" 메뉴로 들어가 새 속성을 선택한다.
4. 구글의 사전 점검(리다이렉트 확인 등)을 통과하면 이전이 확정된다.

서치콘솔 기본 화면 구성이나 다른 메뉴 사용법이 낯설다면 구글 서치 콘솔 가이드를 먼저 살펴보는 것이 도움이 된다.

진행 도중 흔히 막히는 부분은 두 가지다. 첫째는 리다이렉트가 일부 URL에만 적용돼 있어 사전 점검을 통과하지 못하는 경우, 둘째는 새 속성의 소유권 확인 방식(HTML 태그, DNS 레코드 등)이 예전 속성과 달라 인증이 지연되는 경우다. 두 문제 모두 이전 며칠 전에 미리 확인해 두면 당일에 당황하지 않는다.

구글은 이전 관계를 약 180일 동안만 인식한다. 그 기간이 지나면 두 사이트의 연관성을 더 이상 참고하지 않으므로, 최소 180일은 301 리다이렉트를 반드시 유지해야 한다.

주소 변경 알림 도구는 신호를 더 빨리, 더 명확하게 옮겨주는 보조 장치이지 리다이렉트를 대신하는 도구가 아니다. 301 리다이렉트 없이 도구만 실행하면 효과가 없다.

DNS 전환은 언제, 어떻게 해야 안전한가?

전환 24–48시간 전에 DNS의 TTL(캐시 유지 시간)을 낮춰 두는 것이 안전한 전환의 핵심이다. TTL은 각 인터넷 서비스 제공자와 브라우저가 도메인의 주소 정보를 얼마나 오래 캐시(임시 저장)해 둘지 정하는 값이다. 값이 길면(예: 3600초, 1시간) 전환 직후에도 일부 방문자에게는 예전 서버 주소가 한동안 남아 있을 수 있다.

• 전환 24–48시간 전: TTL을 300초(5분) 수준으로 낮춘다.
• 전환 당일: 새 서버를 가리키도록 DNS 레코드를 변경한다.
• 전환 확인 후(며칠 뒤): 문제가 없는 것을 확인하고 TTL을 다시 3600초 이상으로 복원한다.

전환 직전에 TTL을 낮추는 것은 효과가 없다. 기존의 긴 TTL 값이 여러 캐시 서버에서 완전히 만료되려면 시간이 필요하기 때문에, 반드시 며칠 여유를 두고 미리 낮춰 둬야 한다.

DNS 전환은 도메인 등록기관(레지스트라)과 실제 DNS 호스팅(네임서버)이 다른 경우가 많다는 점도 미리 확인해야 한다. 도메인을 새로 구매했다면 네임서버 설정부터 완료해야 그 뒤에 개별 레코드(A, CNAME, MX 등)를 옮길 수 있다. 네임서버 변경은 전체 반영까지 최대 24–48시간이 걸릴 수 있으므로, TTL 조정과 별개로 여유 있게 준비해야 한다.

이전 당일 순서는 어떻게 진행해야 하나?

당일에는 정해진 순서를 그대로 따르는 것이 실수를 줄이는 가장 확실한 방법이다. 순서를 뒤바꾸면 리다이렉트가 안 걸린 상태로 색인 요청을 하는 식의 실수가 생긴다.

1. DNS 전환이 정상 반영됐는지 확인한다. 여러 지역·통신사 회선에서 접속해 새 서버로 연결되는지 점검한다.
2. 주요 URL 여러 개를 직접 클릭해 301 리다이렉트가 최종 목적지까지 한 번에 연결되는지 검증한다. 중간에 다른 URL을 거치는 체인이 생기지 않았는지 특히 확인한다.
3. 새 도메인에 robots.txt를 배포하고 차단 규칙이 잘못 남아 있지 않은지 확인한다. 개발·스테이징 환경에서 쓰던 Disallow: / 규칙이 그대로 남아 있으면 사이트 전체가 크롤링을 거부당한다.
4. 새 sitemap.xml을 생성해 서치콘솔에 제출한다. 새 도메인의 URL만 담긴, 최신 상태의 사이트맵이어야 한다.
5. 서치콘솔에서 주소 변경 알림 도구를 실행한다. 리다이렉트 검증이 끝난 뒤에 진행해야 사전 점검을 통과한다.
6. 트래픽이 많은 주요 페이지 위주로 URL 검사 도구를 이용해 색인을 요청한다. 전체 페이지를 한 번에 요청할 필요는 없고, 홈페이지·주요 상품·서비스 페이지부터 우선순위를 둔다.

당일 작업이 끝났다고 바로 손을 떼면 안 된다. 최소 1–2주는 매일 서치콘솔의 크롤링 통계 보고서와 URL 검사 도구를 확인해, 새 도메인이 정상적으로 크롤링되고 있는지 지켜봐야 한다. 이 기간에 오류가 발견되면 회복 기간이 훨씬 짧아진다.

이전 후 트래픽은 얼마 만에 회복되나?

생각보다 오래 걸린다는 것을 미리 각오해야 한다. SALT.agency가 1,052건의 도메인 이전 사례를 분석한 결과, 새 도메인의 트래픽이 이전 수준을 회복하기까지 걸린 기간은 다음과 같이 나타났다.

회복 기간	비율
0–30일	5%
31–90일	18%
91–180일	13%
181–365일	24%
1–2년	24%
2년 이상	16%

90일 안에 회복된 경우는 전체의 약 23%뿐이었고, 1년 안에 회복된 비율을 합쳐도 58%에 그쳤다. 회복 기간의 중앙값은 304일, 평균은 489일로 나타났는데 평균이 중앙값보다 훨씬 큰 것은 아주 오래 걸리는 소수의 사례가 전체 평균을 끌어올렸기 때문이다.

회복이 느리다고 반드시 잘못된 것은 아니다. 다만 "한 달이면 되겠지"라는 기대로 예산과 일정을 짜면 반드시 어긋난다. 최소 3개월, 넉넉하게는 1년까지 회복 기간을 예산에 반영해야 한다.

회복 속도를 가르는 요인은 대체로 정해져 있다. 리다이렉트를 체인 없이 깔끔하게 적용했는지, 새 도메인이 기존 백링크의 신뢰도를 그대로 이어받았는지, 이전과 동시에 콘텐츠를 얼마나 많이 바꿨는지가 회복 속도를 좌우한다. 콘텐츠 변경을 최소화할수록 구글이 "같은 콘텐츠가 주소만 옮겼다"고 빠르게 판단해 회복이 앞당겨진다.

반대로 회복을 늦추는 요인도 명확하다. 옛 도메인과 새 도메인의 신뢰도 격차가 크거나(예: 새 도메인이 완전히 신규 등록 도메인인 경우), 이전과 함께 사이트 구조·카테고리 체계까지 대대적으로 바꾸거나, 리다이렉트·색인 관련 기술적 오류가 뒤늦게 발견되는 경우 회복은 1년을 훌쩍 넘기기도 한다. 이전 계획을 세울 때는 "언제 끝날까"보다 "어떻게 하면 늦어지지 않을까"에 초점을 맞추는 편이 현실적이다.

애널리틱스와 전환 추적은 어떻게 이어가야 하나?

도메인이 바뀌어도 애널리틱스 데이터의 연속성은 최대한 유지해야 한다. 도메인 변경만으로는 애널리틱스 속성 자체를 새로 만들 필요가 없는 경우가 많지만, 데이터 스트림에 등록된 도메인 주소는 새 도메인으로 갱신해야 정상적으로 이벤트가 수집된다.

• 전환 추적 태그: 광고 플랫폼의 전환 추적 코드가 특정 URL 패턴을 기준으로 동작한다면, 새 도메인의 URL 구조에 맞춰 조건을 함께 수정해야 한다.
• 교차 도메인 추적: 이전 기간 동안 옛 도메인과 새 도메인이 동시에 트래픽을 받는 상황이 발생할 수 있으므로, 두 도메인을 하나의 세션으로 인식하도록 교차 도메인 추적 설정을 임시로 켜 두는 것이 데이터 왜곡을 줄이는 방법이다.
• 목표·이벤트 재확인: 회원가입, 문의하기, 구매 완료처럼 URL 기반으로 설정된 목표·이벤트가 새 도메인에서도 정상 작동하는지 이전 직후 반드시 테스트한다.

이 부분을 놓치면 이전 자체는 성공적이었는데도 "전환이 갑자기 0으로 찍힌다"는 오해가 생겨, 실제로는 존재하지 않는 문제를 찾느라 시간을 낭비하게 된다.

옛 도메인은 언제까지 유지해야 하나?

최소 180일, 안전하게는 1년 이상 옛 도메인을 그대로 유지해야 한다. 구글이 이전 관계를 인식하는 기간이 약 180일이라는 점도 있지만, 더 중요한 이유는 따로 있다. 옛 도메인을 만료시키거나 방치하면 제3자가 그 도메인을 구매해 스팸 사이트로 악용할 위험이 있고, 여전히 옛 주소로 유입되는 외부 백링크와 즐겨찾기, 직접 방문 트래픽이 존재하기 때문이다.

• 최소 180일은 301 리다이렉트를 유지한다.
• 도메인 등록은 최소 1년, 가능하면 그 이상 갱신해 둔다.
• 옛 도메인을 아예 판매하거나 만료시키는 결정은 트래픽이 새 도메인으로 충분히 옮겨 왔다고 확인된 뒤에만 한다.

옛 도메인의 이메일 계정도 마찬가지다. 거래처나 고객이 옛 도메인의 이메일 주소로 계속 연락할 수 있으므로, 이메일 서비스는 도메인 등록 유지 기간과 같거나 더 길게 살려 두는 것이 안전하다. 명함이나 계약서에 남아 있는 옛 이메일 주소로 온 메일을 놓치면 실제 사업상 손실로 이어질 수 있다.

실제 이전은 어떤 흐름으로 진행되나?

가상의 사례로 전체 흐름을 정리하면 이해가 빠르다. 인테리어 시공 업체 "OO스튜디오"가 oostudio.co.kr에서 브랜드 확장을 위해 oostudio.com으로 도메인을 이전한다고 가정해 본다.

시점	진행 내용
D-30일	새 도메인 구매, 서치콘솔 속성 등록·소유권 확인, 전체 URL·순위·트래픽 백업
D-14일	리다이렉트 매핑 시트 완성, 개발팀에 전달, 새 도메인에서 스테이징 테스트
D-2일	DNS TTL을 300초로 낮춤
D-day	DNS 전환, 301 리다이렉트 검증, robots.txt·sitemap.xml 배포, 주소 변경 알림 도구 실행
D+7일	주요 페이지 크롤링·색인 상태 매일 점검, 오류 발견 시 즉시 수정
D+30일	핵심 키워드 순위 변화 점검, 예상 범위 안의 흔들림인지 확인
D+180일	구글의 이전 인식 기간 만료 시점 — 이 시점까지는 301 리다이렉트 유지 필수

OO스튜디오의 경우 이전 후 첫 3주 동안 유기 검색 트래픽이 약 20% 줄었지만, 매핑을 꼼꼼히 해 둔 덕분에 8주 차에 이전 수준을 회복했다고 가정할 수 있다. 이는 SALT.agency 통계에서 상대적으로 빠른 축에 속하는 사례로, 리다이렉트 정확도와 콘텐츠 유지가 회복 속도에 실제로 영향을 준다는 점을 보여 준다. 반대로 매핑을 대충 하거나 콘텐츠를 대폭 바꿨다면 같은 조건에서도 회복이 훨씬 늦어졌을 것이다.

고객·직원에게는 언제, 어떻게 알려야 하나?

이전 전에 미리 공지하는 것이 이전 당일 문의를 줄이는 가장 확실한 방법이다. 특히 이메일 뉴스레터 구독자, 자주 방문하는 재구매 고객에게는 도메인 변경 사실과 예상 시점을 사전에 안내해 두는 것이 좋다. 갑자기 낯선 주소로 연결되면 피싱 사이트로 오인해 이탈하는 경우도 실제로 발생한다.

• 웹사이트 상단 배너: 이전 2주 전부터 "곧 새 주소로 이전합니다" 안내 배너를 노출한다.
• 이메일·SNS 공지: 이전 시점과 새 도메인 주소를 명확히 안내한다.
• 명함·인쇄물·간판: 온라인 채널만 바꾸고 오프라인 접점의 주소는 그대로 두면 혼선이 생기므로, 교체 일정을 함께 관리한다.
• 협력사·거래처: 계약서, 인보이스, API 연동 등에 옛 도메인이 하드코딩돼 있다면 별도로 갱신을 요청해야 한다.

내부적으로도 고객센터·영업팀에는 이전 일정과 예상되는 일시적 혼선(느린 로딩, 일부 링크 오류 가능성)을 미리 공유해 두면, 실제로 문의가 들어왔을 때 당황하지 않고 응대할 수 있다.

도메인 이전에서 자주 하는 실수는 무엇인가?

• 리다이렉트 적용 전에 주소 변경 알림 도구부터 실행한다. 도구가 진행을 막거나, 통과되더라도 신호 이전 효과가 없다.
• 서브도메인을 깜빡한다. 블로그나 쇼핑몰이 별도 서브도메인으로 운영 중이라면 메인 도메인과 별도로 각각 처리해야 한다.
• 이전과 동시에 대대적인 콘텐츠 개편까지 진행한다. 변수가 많아지면 문제가 생겼을 때 원인을 특정하기 어려워진다. 도메인 이전만으로도 변수가 충분히 많으므로, 콘텐츠 개편은 별도 일정으로 나눠 진행하는 편이 안전하다.
• 180일이 되기 전에 옛 도메인을 만료시켜 방치한다. 신호 이전이 끝나기도 전에 연결 고리가 끊기고, 방치된 도메인을 제3자가 사들여 스팸 사이트로 악용하는 사례도 실제로 있다.
• 302로 전환해 두고 "나중에 301로 바꾸면 되지"라고 미룬다. 302가 유지되는 동안은 구글이 이전을 임시로 판단해 신호를 넘기지 않는다.
• 회복 기간을 너무 낙관적으로 잡아 마케팅·광고 예산 계획과 어긋난다. 회복이 3–12개월 걸릴 수 있다는 점을 미리 관련 부서와 공유하지 않으면, 트래픽이 잠시 줄어든 시점에 성급하게 원인을 잘못 진단하고 추가로 손을 대다가 상황을 더 악화시키기도 한다.

자주 묻는 질문

아래 질문들은 실제 도메인 이전을 진행하면서 가장 자주 받는 질문들이다. 본문에서 다룬 내용과 겹치는 부분도 있지만, 짧은 답으로 다시 한번 확인하고 넘어가는 것이 실수를 줄이는 데 도움이 된다.

서브도메인도 자동으로 함께 이전되나요?

아니다. 주소 변경 알림 도구는 지정한 도메인만 처리하고, 블로그·쇼핑몰 같은 서브도메인은 각각 별도 속성으로 진행해야 한다.

302로 먼저 전환한 뒤 나중에 301로 바꿔도 되나요?

권장하지 않는다. 302가 유지되는 동안은 구글이 이전을 "임시"로 판단해 순위 신호를 새 도메인으로 넘기지 않는다. 처음부터 301로 전환하는 것이 안전하다.

이전 후 색인이 잘 안 되는지는 어떻게 확인하나요?

서치콘솔의 URL 검사 도구로 개별 페이지의 색인 상태를 확인하고, 페이지 인덱싱 리포트로 전체 흐름을 살펴본다. 리포트 데이터 갱신이 지연되는 경우도 있으므로, 급할 때는 URL 검사 도구의 결과를 우선 참고하는 것이 좋다.

도메인만 바꾸고 콘텐츠는 그대로 두면 더 빨리 회복되나요?

그렇다. 콘텐츠 변경을 최소화할수록 구글이 같은 콘텐츠가 주소만 옮겼다고 빠르게 판단해 회복이 앞당겨진다는 것이 여러 사례에서 공통적으로 나타난다.

도메인 이전 중에는 광고(검색광고 등)도 영향을 받나요?

검색광고 자체는 별도의 심사·입찰 구조로 운영되므로 자연 검색 순위와는 직접적인 관계가 없다. 다만 랜딩 페이지 URL이 바뀌면 광고 쪽에서도 URL을 함께 갱신해야 하고, 랜딩 페이지 품질 평가가 다시 이뤄지는 경우가 있으므로 광고 담당자에게도 이전 일정을 미리 공유해야 한다.

소규모 사이트도 이렇게 꼼꼼히 준비해야 하나요?

페이지 수가 적은 소규모 사이트라면 매핑 시트 작성 자체는 훨씬 간단해진다. 다만 절차 자체를 생략해도 되는 것은 아니다. 페이지가 10개뿐이라도 리다이렉트가 하나라도 빠지면 그 페이지의 신호는 그대로 사라지므로, 규모와 무관하게 준비 순서는 동일하게 지키는 것이 안전하다.

여기까지 정리한 항목을 한 번에 훑고 싶다면 다음 다섯 가지만 다시 확인해도 충분하다. 하나, 리다이렉트 매핑을 페이지 단위로 끝냈는가. 둘, 301로 체인 없이 적용했는가. 셋, 주소 변경 알림 도구를 리다이렉트 이후에 실행했는가. 넷, DNS TTL을 며칠 전부터 낮춰 뒀는가. 다섯, 옛 도메인을 최소 180일 이상 유지할 계획을 세웠는가. 이 다섯 가지만 지켜도 도메인 이전에서 발생하는 대부분의 순위 손실을 막을 수 있다.

도메인 이전은 한 번 잘못되면 몇 달에서 길게는 1년 넘게 순위와 트래픽을 회복하지 못할 수 있는 작업입니다. 이루웹은 SEO를 처음부터 반영한 홈페이지 제작은 물론, 도메인 이전과 리뉴얼 과정의 리다이렉트 설계와 서치콘솔 재설정까지 함께 도와드리고 있습니다. 이전을 앞두고 계시다면 이루웹의 서비스를 살펴보시고 무료 상담을 통해 편하게 문의해 주시기 바랍니다.