예전 URL을 전부 새 도메인 홈페이지로 리다이렉트해도 되나요?

안 됩니다. 구글은 홈페이지로 몰아넣는 대량 리다이렉트를 소프트 404와 비슷하게 취급해서, 예전 페이지의 순위가 넘어가지 않습니다. 예전 URL마다 새 도메인의 같은 내용 URL로 301 리다이렉트하세요.

예전 도메인과 리다이렉트는 얼마나 유지해야 하나요?

구글 안내는 가능한 한 오래, 일반적으로 최소 1년입니다. 도메인 등록은 계속 유지하세요. 만료되면 다른 사람이 등록해서 내 링크와 내게 오는 메일을 그대로 가져갈 수 있습니다.

서치 콘솔의 주소 변경 도구를 꼭 써야 하나요?

쓰세요. 이전이 의도된 사이트 전체 이동이라는 것을 구글에 알려 줍니다. 두 도메인 모두 서치 콘솔에서 소유 확인이 돼 있어야 하고, 예전 홈페이지가 새 홈페이지로 301 리다이렉트돼야 하며, 도메인이나 서브도메인 단위 이전에만 쓸 수 있습니다.

이전 전에 DNS TTL을 낮춰야 하나요?

네. 리다이렉트 서버처럼 새로운 곳을 가리키게 될 예전 도메인 레코드는 변경보다 최소한 예전 TTL 한 바퀴 이상 앞서 300초 정도로 낮추고, 안정되면 다시 올리세요.

도메인 이전 체크리스트: 리다이렉트, DNS, 메일, 검색 순위 지키기

이 글이 다루는 것

웹사이트를 한 도메인에서 다른 도메인으로, 즉 old.example에서 new.example로 옮기면서 검색 순위, 다른 사이트에서 오는 링크, 그리고 도메인으로 메일을 쓰고 있다면 메일까지 지키는 방법입니다. 같은 도메인을 새 호스팅으로 옮기는 것은 전혀 다르고 훨씬 작은 일입니다. 그건 대부분 DNS와 TTL 계획으로 끝납니다.

먼저 의견 하나. 가능하다면 도메인 이전을 리뉴얼이나 URL 구조 변경과 함께 하지 마세요. 이전 뒤 유입이 줄어들면(이전 중에는 대개 한동안 출렁입니다) 무엇 때문인지 알아야 합니다. 먼저 옮기고, 구조는 그다음에 바꾸세요.

시작 전에: 중요한 URL을 모두 목록으로

도메인 이전의 핵심은 리다이렉트 매핑, 즉 예전 URL 하나하나가 어디로 가는지의 표입니다. 예전 URL 목록 없이는 만들 수 없고, 사이트맵만으로는 부족합니다. 다음을 합치세요.

현재 XML 사이트맵
지난 1년간 분석 도구의 방문 시작 페이지
서버 로그에 나오는 URL, 아직 요청이 들어오는 예전 URL 포함
서치 콘솔의 상위 페이지와 링크 보고서(다른 사이트가 링크하는 페이지)
사람들이 직접 링크하는 PDF, 이미지 같은 파일

새 도메인을 중고로 샀다면 확정하기 전에 이력을 보세요. 예전에 무슨 사이트였는지는 웨이백 머신으로, 소유 확인을 한 뒤에는 서치 콘솔의 직접 조치와 보안 문제 메뉴로 확인합니다. 스팸 이력이 있는 도메인은 멀쩡한 사이트를 옮겨 갈 곳이 아닙니다.

몇 주 전: 새 도메인 준비

DNS, 인증서, 사이트

새 도메인의 DNS를 설정하고, 쓸 이름 전부(최소한 루트와 www)를 담은 인증서를 발급받고, 사이트를 배포합니다. SSL 점검으로 이름마다 유효한 인증서가 나오는지 확인하세요. Go-Live 점검은 DNS, 전파, 인증서, HTTP, 등록 정보를 한 번에 확인하므로 곧 트래픽을 받을 도메인에 딱 맞습니다.

noindex 없이 비공개로 두기

시험하는 동안 새 도메인은 noindex가 아니라 비밀번호나 IP 허용 목록으로 막으세요. 시험 때 넣은 noindex가 남는 것은 이전이 잘못되는 가장 흔한 경로 중 하나입니다. 리다이렉트가 모든 사람을 구글이 색인하지 말라고 들은 사이트로 보내게 됩니다. noindex를 쓴다면 전환 당일 할 일 목록에 “noindex 제거”를 크게 적어 두고, X-Robots-Tag 가이드로 확인하세요. 같은 이유로 robots.txt도 보세요. 스테이징에서 따라온 Disallow: / 한 줄이 전부를 막습니다.

서치 콘솔

두 도메인 모두 소유 확인을 합니다. DNS TXT 레코드로 확인하는 ‘도메인’ 속성은 모든 서브도메인과 프로토콜을 한 번에 포함합니다. 나중에 쓸 주소 변경 도구도 두 도메인 모두의 확인된 소유자여야 쓸 수 있습니다.

예전 도메인이 박혀 있는 모든 곳

이 목록이 깔끔한 이전을 일주일짜리 문의 대응으로 바꿉니다.

구글, GitHub, 마이크로소프트, 사내 인증 시스템에 등록한 OAuth·SSO 리다이렉트 URI
결제 대행사의 웹훅과 결제 후 돌아올 URL
CORS 허용 목록과 Content-Security-Policy 출처
쿠키. 쿠키는 도메인 단위라서 새 도메인에서는 모두가 로그아웃됩니다. 감수할지 정하세요.
데이터베이스에 저장된 절대 URL: CMS 본문, 이미지 경로, 메일 템플릿
분석 도구, 태그 매니저, 광고·제휴 설정
예전 호스트명을 호출하는 모바일 앱과 API 클라이언트

메일: 도메인으로 메일을 보내거나 받는다면

예전 도메인의 메일 주소도 옮긴다면, 누군가 새 도메인으로 메일을 보내기 한참 전에 새 도메인의 메일 설정을 끝내세요.

새 도메인의 MX 레코드를 메일 서비스로 지정합니다.
새 도메인에 SPF, DKIM, DMARC를 설정합니다. DMARC는 p=none과 보고 수신으로 시작해서, 누가 내 이름으로 보내는지 확인한 뒤 조이세요. 메일 점검이 전부 보여 주고, 각각 무엇이 필요한지는 MX·SPF·DMARC 점검에 정리돼 있습니다.
새 도메인에는 발송 평판이 없다고 보세요. 첫날 뉴스레터를 전량 보내지 말고 발송량을 점차 늘리세요.

예전 도메인은 오랫동안 메일을 받아서 새 주소로 전달하게 두세요. 사람들은 몇 년 동안 예전 주소로 메일을 보냅니다.

리다이렉트 매핑

URL 하나에 목적지 하나, 301

예전 URL마다 새 도메인의 같은 내용 URL로 영구 리다이렉트(301 또는 308)합니다. 경로가 그대로라면 규칙 하나로 됩니다. 경로가 바뀌는 곳은 하나씩 명시합니다.

전부 새 홈페이지로 보내지 마세요. 구글은 이를 소프트 404와 비슷하게 취급하고, 예전 페이지가 쌓은 평가는 넘어가지 않습니다. 대응하는 페이지가 없다면 실제로 관련 있는 가장 가까운 페이지로 보내거나, 솔직하게 404나 410을 돌려주세요. 리다이렉트는 서버에서 하세요. meta refresh와 자바스크립트 리다이렉트는 더 약한 신호입니다.

경로와 쿼리 문자열을 유지

예전 도메인의 nginx:

server {
    listen 80;
    listen 443 ssl;
    server_name old.example www.old.example;
    # 예전 이름들의 ssl_certificate / ssl_certificate_key

    location /.well-known/acme-challenge/ {
        root /var/www/acme;
    }

    location / {
        return 301 https://new.example$request_uri;
    }
}

$request_uri에는 경로와 쿼리 문자열이 함께 들어 있습니다. 경로가 바뀌는 페이지는 http 블록에 map을 두고 일괄 리다이렉트보다 먼저 확인합니다.

map $uri $moved_to {
    default          "";
    /about-us        /about;
    /blog/2019/hello /blog/hello;
}
# location / 안, 일괄 return보다 앞에:
#   if ($moved_to) { return 301 https://new.example$moved_to; }

Apache:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
RewriteRule ^ https://new.example%{REQUEST_URI} [R=301,L]

mod_rewrite는 새 쿼리 문자열을 쓰지 않는 한 원래 쿼리 문자열을 그대로 넘깁니다.

Cloudflare에서는 경로를 유지하고 “Preserve query string”을 켠 Redirect Rule(명시적 목록이라면 Bulk Redirects)을 씁니다. 예전 호스트명의 DNS 레코드는 프록시로 켜져 있어야 합니다. 그래야 규칙이 실행되는 Cloudflare 엣지로 트래픽이 갑니다.

인증서 검증 경로는 리다이렉트하지 않기

두 예시에 들어 있는 acme-challenge 예외를 보세요. 예전 도메인의 인증서를 Let’s Encrypt HTTP-01 방식으로 갱신한다면, CA는 리다이렉트를 따라갑니다. 검증 요청을 새 도메인으로 보내면 거기엔 토큰이 없으므로 갱신이 실패하고, 몇 달 뒤 예전 도메인으로 들어오는 모든 HTTPS 링크에 인증서 오류가 뜹니다. 그 경로를 예외로 두거나, 예전 도메인의 갱신을 DNS-01 방식으로 바꾸세요.

목록 전체를 시험

목록의 예전 URL을 모두 파일에 넣고 각각 어디에 도착하는지 확인합니다.

while read -r url; do
  printf '%s -> ' "$url"
  curl -s -o /dev/null -L -w '%{http_code} after %{num_redirects} redirect(s): %{url_effective}\n' "$url"
done < old-urls.txt

모든 줄이 200 after 1 redirect(s)이고 목적지가 맞아야 합니다. 리다이렉트가 두 번 이상이면 체인(예전 http → 예전 https → 새 www → 새 루트)입니다. 예전 URL마다 최종 주소로 바로 가도록 줄이세요. URL 하나씩은 HTTP 점검으로 단계별 상태 코드를 볼 수 있습니다. 상태 코드는 301과 302 리다이렉트에, 두 도메인이 같은 CDN 뒤에 있을 때 가끔 생기는 문제는 리다이렉트 루프 진단에 있습니다.

며칠 전: TTL 낮추기

리다이렉트를 위해 예전 도메인의 레코드를 다른 서버로 돌려야 한다면, 그 레코드의 TTL을 미리 300초 정도로 낮추세요. 변경보다 최소한 예전 TTL 한 바퀴 이상 앞서야 하므로, 86400인 레코드는 하루보다 일찍 낮춰야 합니다. 이유와 권한 서버에서 확인하는 법은 TTL 가이드에 있습니다.

새 도메인에서는 만들기 전의 호스트명을 미리 조회하지 마세요. 리졸버는 “없다”는 응답을 SOA 레코드의 부정 TTL 동안 캐시하므로, 성급한 시험 조회 때문에 레코드를 만든 뒤에도 NXDOMAIN이 나올 수 있습니다.

전환 당일

예전 도메인에서 리다이렉트를 켭니다.
새 도메인의 비밀번호, IP 제한, noindex를 없애고, robots.txt가 크롤링을 허용하는지 확인합니다.
canonical 태그를 새 URL로 바꿉니다. 새 도메인의 절대 URL로. canonical이 여전히 예전 도메인을 가리키면 예전 URL이 진짜라고 구글에 말하는 셈이고, 리다이렉트와 정반대 신호가 됩니다.
각 언어 묶음의 모든 대체 URL이 새 도메인을 쓰도록 hreflang을 고칩니다.
새 URL만 담은 사이트맵을 게시하고, 새 도메인의 서치 콘솔 속성에 제출합니다.
내부 링크를 새 도메인으로 직접 바꿉니다. 내 페이지끼리 리다이렉트에 기대지 마세요.
예전 도메인의 서치 콘솔 속성에서 주소 변경 도구를 실행합니다. 예전 홈페이지가 새 홈페이지로 301 리다이렉트되는지 확인합니다. 도메인과 서브도메인 단위 이전 전용이라, http에서 https로 바꾸거나 디렉터리를 옮기는 데는 쓸 수 없습니다.
Bing 웹마스터 도구에도 사이트 이전 도구가 따로 있고, 네이버 서치어드바이저에는 새 사이트를 등록하고 사이트맵을 제출해야 합니다.
바깥에서 확인합니다. 예전 도메인에서 바꾼 레코드는 전파 확인으로, 예전·새 URL 표본은 HTTP 점검과 SSL 점검으로 봅니다.

예전 도메인의 남은 일

예전 도메인의 일은 전환 당일에 끝나지 않습니다. 몇 년 동안 할 일이 있습니다.

등록을 계속 유지하세요. 무기한으로. 자동 갱신을 켜고 등록기관의 결제 수단을 최신으로 두세요. 예전 도메인이 만료되면 다른 사람이 등록해서 남은 링크를 가져가고, 예전 주소로 오는 메일을 받고, 그 이름을 기억하는 사람들에게 나인 척할 수 있습니다.
리다이렉트를 계속 돌리세요. 구글 안내는 가능한 한 오래, 일반적으로 최소 1년입니다. 도메인을 갖고 있는 한 멈출 이유가 별로 없습니다.
예전 호스트명 전부에서 HTTPS를 유효하게 유지하세요. 예전 도메인으로 가는 HTTPS 링크는 리다이렉트가 일어나기 전에 먼저 유효한 인증서가 필요합니다. 예전 도메인이 HSTS를 보냈다면 그걸 기억하는 브라우저는 일반 HTTP로 물러서지 않습니다. HSTS 프리로드 목록에 올라가 있다면 모든 브라우저에, 그리고 프리로드는 includeSubDomains가 필수이므로 모든 서브도메인에 적용됩니다. HSTS 프리로드 체크리스트를 보세요.
예전 도메인을 robots.txt로 막지 마세요. 구글이 예전 URL을 크롤링해야 리다이렉트를 봅니다.
더는 메일을 보내지 않는다면 잠그세요. 예전 도메인으로 다시는 메일을 보내지 않는다면 v=spf1 -all과 p=reject DMARC 정책을 게시해서 누구도 그 도메인으로 그럴듯하게 메일을 보내지 못하게 합니다. 잊고 있던 시스템이 예전 주소로 메일을 보내고 있지 않다는 확신이 선 뒤에만 하세요.

이전 뒤: 지켜볼 것

서치 콘솔, 두 속성 모두. 새 속성에서는 색인된 페이지가 늘고, 예전 속성에서는 구글이 다시 크롤링하면서 “리디렉션이 포함된 페이지”(Page with redirect)가 늘어야 합니다. 구글 문서는 중간 규모 사이트의 대부분 페이지가 옮겨지는 데 몇 주, 큰 사이트는 더 오래 걸리고 그동안 순위가 출렁일 수 있다고 설명합니다.
새 도메인의 404. 대부분 리다이렉트 매핑의 잘못된 항목입니다. 페이지만 고치지 말고 매핑을 고치세요.
예전 도메인의 로그. 일괄 규칙에 걸리는 요청은 목록에서 빠뜨린 URL을 보여 주고, 그중에는 따로 매핑할 가치가 있는 것도 있습니다.
메일. 새 도메인의 DMARC 집계 보고서와 첫 발송들의 반송률.
TTL. 되돌릴 일이 없다고 확신하면 낮췄던 값을 다시 올립니다.
중요한 외부 링크. 유입을 가장 많이 보내 주는 사이트에 링크를 바꿔 달라고 요청하세요. 리다이렉트도 링크를 넘겨주지만, 직접 링크는 영원히 한 단계가 짧습니다.

내 도메인에서 바로 확인

무료, 가입 불필요. 이 가이드가 다루는 항목을 바로 검사하고 조치 방법을 알려드립니다.