검색 순위를 떨어뜨리지 않고 도메인을 이전하는 방법

도메인 변경은 기술적으로 작은 실수가 매우 빠르게 눈에 띄는 문제로 번질 수 있는 몇 안 되는 SEO 프로젝트 중 하나입니다. 누락된 리디렉션, 차단된 크롤링 경로, 잊힌 canonical 하나가 단순한 리브랜딩을 몇 주간의 순위 변동으로 바꿀 수 있습니다.

어느 정도의 움직임은 정상입니다. 검색 엔진은 기존 URL을 크롤링하고, 리디렉션을 발견하고, 신호를 처리한 뒤, 새 도메인을 색인에 안착시키는 데 시간이 필요합니다. 목표는 모든 하락을 피하는 것이 아닙니다. 목표는 이전을 지루하게 만드는 것입니다. 하나의 기존 URL이 동등한 하나의 새 URL을 가리키고, 서버가 명확하게 응답하며, 중요한 것이 사라지지 않게 하는 것입니다.

리디렉션 규칙이 아니라 인벤토리부터 시작하세요

가장 흔한 이전 실패는 이를 서버 설정 작업으로 취급하는 것입니다. 그렇지 않습니다. 이는 서버 설정으로 끝나는 정보 아키텍처 작업입니다.

DNS를 건드리기 전에 중요한 URL 목록을 만드세요:

• 자연 검색 트래픽을 받는 URL
• 외부 백링크가 있는 URL
• 전환을 만들거나, 리드를 생성하거나, 캠페인을 지원하는 URL
• 현재 XML sitemap에 있는 canonical URL
• 외부에서 링크된 PDF, 이미지, 다운로드 가능한 파일
• 현재 내비게이션에는 나타나지 않을 수 있는 고가치 레거시 URL

각 기존 URL에 대해 새 도메인의 목적지를 지정하세요. 대부분의 경우 그 목적지는 동일한 의도를 가진 동일한 페이지여야 합니다. /pricing이 https://newdomain.com/pricing이 된다면 간단합니다. 기존 제품 페이지 세 개가 하나의 새 가이드로 병합된다면, 그 결정을 의도적으로 문서화하세요.

게으른 패턴은 피하세요. 모든 것을 새 홈페이지로 리디렉션하는 방식입니다. 편리하지만 관련성을 버리는 일입니다. 검색 엔진과 사용자는 모두 목적지가 원래 URL과 같은 필요에 답하기를 기대합니다.

가능하면 URL 구조를 보존하세요

경로가 안정적으로 유지될 때 도메인 이전은 더 쉬워집니다. oldsite.com/blog/example에서 newsite.com/blog/example로 이동하는 것은 도메인, CMS, slug, 폴더 구조, 콘텐츠를 동시에 바꾸는 것보다 훨씬 깔끔합니다.

때로는 리디자인이나 CMS 이전 때문에 URL 변경이 불가피합니다. 그렇다면 결정을 분리하세요:

1. 도메인이 바뀌기 때문에 무엇이 변경되는가?
2. 사이트 구조가 바뀌기 때문에 무엇이 변경되는가?
3. 무엇이 삭제, 병합, 또는 다시 작성되는가?

변수를 많이 도입할수록 나중에 문제를 진단하기가 더 어려워집니다. 이전이 중요하고 현재 사이트가 잘 작동하고 있다면, 먼저 도메인을 옮기고 리디자인은 나중에 하는 것을 고려하세요.

영구적인 원홉 리디렉션을 사용하세요

진정한 도메인 이전에는 기존 URL에서 새 대응 URL로 서버 측 301 또는 308 리디렉션을 사용하세요. 임시 리디렉션은 임시 상황을 위한 것입니다. JavaScript 리디렉션, meta refresh, soft redirect는 더 약한 신호이며 깨지기 쉽습니다.

리디렉션 목표는 간단합니다:

• 모든 중요한 기존 URL이 영구 리디렉션을 반환합니다.
• 각 리디렉션은 최종 목적지로 직접 이동합니다.
• HTTP가 HTTPS로 깔끔하게 리디렉션됩니다.
• www와 non-www 변형이 일관되게 처리됩니다.
• 필요하지 않다면 리디렉션이 취약한 query-string 동작에 의존하지 않습니다.

나쁜 체인은 다음과 같습니다:

http://oldsite.com/page → https://oldsite.com/page → https://www.oldsite.com/page → https://newsite.com/page → https://www.newsite.com/page

결국 올바른 페이지에 도착할 수는 있지만, 느리고, 크롤링하기 더 어렵고, 실수를 숨길 가능성이 더 큽니다. 모든 기존 변형에서 최종 새 URL까지 한 번의 홉을 목표로 하세요.

동작을 검증할 때는 브라우저에 표시되는 내용을 믿기보다 실제 HTTP 응답을 검사하세요. 프로덕션에서 리디렉션과 HTTP 헤더를 디버깅하는 작은 도구 모음에 대한 저희 가이드가 여기서 유용합니다. 브라우저는 너무 친절해서 체인을 따라가고 지저분한 부분을 숨기기 때문입니다.

출시 전에 DNS와 인증서를 준비하세요

DNS가 순위를 직접 이전하지는 않지만, 잘못된 DNS는 이전이 망가진 것처럼 보이게 만들 수 있습니다. 변경 사항이 더 예측 가능하게 전파되도록 출시 기간 전에 TTL 값을 낮추세요. 새 도메인에 웹 트래픽, 이메일, 필요한 하위 도메인에 대한 올바른 레코드가 있는지 확인하세요.

두 도메인 모두에 유효한 TLS 인증서도 필요합니다. 이는 놓치기 쉽습니다. 이전 후에도 기존 도메인은 여전히 HTTPS 리디렉션을 제공해야 합니다. 인증서가 만료되면 사용자와 크롤러가 새 사이트에 도달하기도 전에 브라우저 경고를 만날 수 있습니다.

이전이 이메일에 영향을 준다면, 이를 나중에 생각할 일로 취급하지 마세요. 도메인 변경은 종종 SPF, DKIM, DMARC, MX records, tracking links, transactional mail을 깨뜨립니다. 중요한 레코드를 다시 확인하려면 MX, SPF, DKIM, DMARC에 대한 개발자 친화적인 가이드를 참고하세요.

canonical, 내부 링크, sitemap을 확인하세요

출시 후 새 도메인은 마치 처음부터 콘텐츠의 canonical 홈이었던 것처럼 동작해야 합니다.

즉:

• Canonical tags는 기존 도메인이 아니라 새 URL을 가리킵니다.
• 내부 링크는 새 도메인 또는 root-relative paths를 사용합니다.
• XML sitemaps에는 최종적이고 색인 가능한 새 URL만 포함됩니다.
• hreflang annotations를 사용하는 경우 새 URL을 참조합니다.
• Open Graph, structured data, alternate links가 업데이트됩니다.
• Robots.txt가 중요한 섹션을 차단하지 않습니다.

기존 URL로 가득 찬 sitemap을 게시한 뒤 리디렉션이 정리해 주기를 기대하지 마세요. sitemap은 색인되기를 원하는 URL 목록이어야 합니다. 이전 후에는 새 도메인의 최종 URL을 의미합니다.

canonical의 모순도 주의하세요. 기존에서 새 도메인으로 리디렉션되는 페이지가 canonical을 다시 기존 도메인으로 가리키고 있다면 혼합 신호를 보냅니다. 검색 엔진은 보통 어느 정도의 불일치는 처리할 수 있지만, 그렇게 하도록 요구해서는 안 됩니다.

출시일에 모든 것을 바꾸지 마세요

이전만으로도 이미 충분히 큰 이벤트입니다. 가능하다면 대규모 콘텐츠 정리, template rewrites, 내비게이션 변경, JavaScript rendering 변경, 새로운 성능 프로필과 결합하지 마세요.

이는 미신이 아닙니다. 디버깅 규율입니다. 출시 후 순위가 떨어진다면 원인이 리디렉션 매핑인지, 크롤링 접근성인지, 변경된 콘텐츠인지, 느려진 렌더링인지, 누락된 structured data인지, 또는 다른 무엇인지 알아야 합니다.

초기 출시는 가능한 한 기존 사이트에 가깝게 유지하세요. 새 도메인이 안정된 뒤 더 큰 편집 및 디자인 변경을 작은 묶음으로 진행하세요.

검색 엔진에 무엇이 바뀌었는지 알리세요

Google Search Console에서 기존 도메인과 새 도메인을 모두 확인하세요. 그런 다음 이동이 도메인 수준의 변경이고 콘텐츠가 새 도메인으로 이동하는 경우 Change of Address 도구를 사용하세요. 출시 후 새 sitemap을 제출하세요.

이것이 리디렉션을 대체하지는 않습니다. 이를 보조합니다. 검색 엔진은 URL 수준 매핑을 이해하기 위해 여전히 크롤링 가능한 지속적 리디렉션이 필요합니다.

Bing 및 기타 검색 엔진의 경우, 사용 가능한 webmaster tools를 활용하세요. 또한 직접 관리하는 위치도 업데이트하세요. 소셜 프로필, 비즈니스 목록, 광고 목적지, 이메일 푸터, 문서, 파트너 링크, syndication 콘텐츠의 canonical references가 여기에 포함됩니다.

외부 링크가 모두 업데이트되지는 않을 것이며, 그래도 괜찮습니다. 하지만 가장 중요한 링크는 업데이트되어야 합니다. 주요 파트너, app marketplace, documentation portal, press page가 기존 도메인으로 링크하고 있다면 업데이트를 요청하세요.

출시 후 올바른 항목을 모니터링하세요

이전 후 처음 며칠은 축하가 아니라 적극적인 모니터링 기간이어야 합니다.

확인할 항목:

• 기존 및 새 도메인에서의 크롤링 활동에 대한 서버 로그
• 404 및 예상치 못한 5xx 오류
• 리디렉션 체인과 루프
• Search Console의 색인 상태
• Sitemap 발견 및 처리
• 자연 검색 랜딩 페이지와 쿼리 패턴
• 기존 URL에 의존하는 전환 경로
• Analytics filters와 referral exclusions

보고상의 노이즈를 예상하세요. 일부 analytics tools는 제대로 설정하지 않으면 새 도메인을 새 속성으로 취급합니다. 일부 대시보드는 기존 도메인 트래픽과 새 도메인 트래픽을 비교해 이전이 실제보다 더 나빠 보이게 만듭니다.

검색 가시성은 몇 주 동안 변동할 수 있습니다. 원하지 않는 것은 고가치 기존 URL이 반복적으로 크롤링되지만 제대로 리디렉션되지 않거나, 새 페이지가 발견되지만 기존 도메인의 중복으로 표시되는 패턴입니다.

성능도 무시해서는 안 됩니다. 새 도메인이 더 무거운 템플릿, 깨진 캐싱, 최적화되지 않은 asset으로 출시되면 사용자는 이전을 속도 저하로 느낄 수 있습니다. 점검의 일부로 Lighthouse를 사용한다면 우선순위를 염두에 두고 읽으세요. 당황하지 않고 Lighthouse 보고서를 읽는 방법에 대한 저희 글은 의미 있는 문제와 노이즈를 구분하는 방법을 설명합니다.

기존 도메인을 오랫동안 유지하세요

이전이 “작동한다”고 해서 기존 도메인을 만료시키지 마세요. 가능한 한 오래 등록을 유지하고, 인증서를 유효하게 유지하며, 리디렉션을 계속 실행하세요. 실제로는 수년을 의미하는 경우가 많습니다.

기존 링크는 블로그 게시물, 북마크, 문서, PDF, 이메일, 소셜 게시물에 계속 남아 있습니다. 리디렉션은 그 역사적 흔적과 새 도메인 사이의 다리입니다. 너무 일찍 끄면 사용자의 경로가 끊기고 축적된 신호가 낭비됩니다.

또한 리디렉션 맵과 출시 메모의 사본을 보관하세요. 6개월 뒤 누군가 레거시 URL이 왜 특정 방식으로 동작하는지 묻는다면, 문서화해 둔 것을 다행으로 여기게 될 것입니다.

<!-- tool-cta:start -->

💡 이것을 시도해 보세요: 전환 후 Redirect Checker를 통해 기존 URL을 추적하여 각 URL이 올바른 새 페이지로 단일 301 홉만에 해석되는지 확인하세요.

<!-- tool-cta:end -->

합리적인 이전 체크리스트

출시 전:

• Search Console에서 두 도메인을 모두 확인합니다.
• 현재 사이트를 크롤링하고 중요한 URL을 내보냅니다.
• 일대일 리디렉션 맵을 만듭니다.
• DNS TTL을 낮춥니다.
• 기존 및 새 도메인용 TLS 인증서를 준비합니다.
• canonical, 내부 링크, hreflang, structured data, sitemap을 업데이트합니다.
• staging 또는 통제된 환경에서 리디렉션을 테스트합니다.

출시일:

• 리디렉션을 배포합니다.
• HTTP에서 HTTPS로의 동작을 확인합니다.
• 모든 template type에서 중요한 URL 샘플을 테스트합니다.
• 새 sitemap을 제출합니다.
• 적절한 경우 Change of Address 도구를 사용합니다.
• 서버 오류, 리디렉션 루프, 차단된 리소스를 관찰합니다.

출시 후:

• 크롤링 오류와 색인 보고서를 모니터링합니다.
• 가능한 곳에서 중요한 외부 링크를 업데이트합니다.
• 단순한 도메인 합계가 아니라 랜딩 페이지 의도별로 트래픽을 비교합니다.
• 리디렉션을 무기한 유지합니다.
• 이전이 안정될 때까지 관련 없는 리디자인이나 콘텐츠 실험을 미룹니다.

도메인 이전은 위험이 전혀 없는 작업은 아니지만, 관리할 수 있습니다. 순위는 보통 이전이 불명확한 신호를 보낼 때 타격을 받습니다. 누락된 리디렉션, 변경된 콘텐츠, 모순되는 canonical, 차단된 크롤러, 잊힌 기존 도메인이 그 예입니다. 검색 엔진과 사용자에게 깔끔한 지도를 제공하면, 이전은 훨씬 덜 극적인 일이 됩니다.