언어

웹사이트 호스팅 마이그레이션 SEO

URL을 바꾸지 않고 웹사이트를 새 호스트, CDN, DNS 제공업체로 옮기는 준비, 전환, 검증, 모니터링, 롤백 절차입니다.

최초 게시: 2026년 7월 18일 · 최근 업데이트: 2026년 8월 9일 · Advanced
언어
AI작성자AI
이 페이지의 근거 신호 1개

호스팅 마이그레이션은 공개 URL을 유지하며 사이트 인프라를 바꾸는 작업입니다. 전환 전에 DNS TTL을 낮추고 새 원본과 CDN의 사용자·크롤러 응답을 입증하세요. 기존·신규 인프라를 함께 운영하며 응답과 렌더링 페이지, 두 로그를 비교하고 기존 호스트 트래픽이 없어진 뒤에만 종료합니다. 진정한 같은 URL 이동에는 리디렉션 맵이나 Change of Address가 필요 없습니다.

요약 — 같은 URL의 호스팅·CDN·DNS 이동을 응답 동등성과 트래픽 라우팅 프로젝트로 다루세요. 모든 호스트명과 의존성을 목록화하고 출시 전 DNS TTL을 낮추며 새 원본과 엣지를 구성합니다. 인증서와 보안 제어를 검증하고 현실적인 크롤러·사용자 부하를 테스트하며 원시·렌더링 응답을 비교하세요. DNS 전파 중 기존·신규 인프라를 함께 운영하고 두 로그, DNS 응답, 오류, 지연, 캐시, 크롤, Search Console을 관찰합니다. 사전 합의한 인프라 실패가 발생할 때만 이전 라우팅으로 롤백하세요.

정말 같은 URL 마이그레이션인지 판단하기

같은 URL 호스팅 마이그레이션은 정확한 공개 URL 문자열을 유지하며 인프라만 바꿉니다. 스킴, 호스트명, 포트, 경로, 쿼리 처리, 후행 슬래시 동작이 모두 안정적으로 유지됩니다.

계획 전에 프로젝트를 분류하세요.

변경같은 URL 호스팅 이동?추가 마이그레이션 작업
새 원본 IP, 같은 URL예응답 동등성, DNS, 용량, 로그
새 CDN, 같은 URL예엣지 규칙, 캐시, TLS, 방화벽, 원본 라우팅
새 권한 DNS 제공업체보통영역 동등성, 위임, DNSSEC, 메일·서비스 레코드
www.example.com에서 example.com아니요URL 매핑과 영구 리디렉션
HTTP에서 HTTPS아니요프로토콜 마이그레이션과 URL별 리디렉션
경로 또는 CMS 생성 URL 변경아니요URL 마이그레이션과 플랫폼 QA

URL 변경 프로젝트를 “호스팅뿐”이라고 부르게 두지 마세요. 배포 계획에는 실제 출시되는 모든 마이그레이션 유형이 포함돼야 합니다.

인프라 인벤토리 구축

인프라 인벤토리는 숨은 의존성이 출시 당일의 놀라움이 되는 것을 막습니다. 다음을 기록하세요.

  • 자산, 이미지, API, 국제 호스트, 레거시 별칭을 포함한 모든 공개 호스트명
  • A, AAAA, CNAME, NS, SOA, CAA, MX, TXT와 관련 SRV 레코드
  • 인증서 발급자, 검증 방식, Subject Alternative Names, 만료일
  • 원본 주소, 포트, 상태 확인, 로드 밸런서, 장애 조치 동작
  • CDN 캐시 키, 캐시 규칙, 리디렉션, 변환, 워커, 삭제 방식
  • WAF, 봇, 속도 제한, 지역, 인증, IP 허용·차단 규칙
  • 응답 헤더, 압축, 쿠키 동작, 보안 헤더
  • 로그 목적지, 보존, 샘플링, 필드, 시간대
  • Search Console과 분석 검증 방식
  • 타사 콜백, 웹훅, 결제 흐름, 피드, 허용 목록 IP

DNS 검토에는 비웹 레코드도 포함해야 합니다. MX, SPF, DKIM, DMARC, 서비스 레코드가 깨지면 순위를 직접 바꾸지 않더라도 보호하려던 비즈니스가 중단될 수 있습니다.

응답 동등성 기준선 만들기

응답 동등성은 둘 다 200인지 확인하는 수준이 아니라 같은 요청 URL에 대해 기존·신규 시스템을 비교하는 것입니다.

템플릿과 동작을 대표하는 집합에서 다음을 수집하세요.

  • 상태와 리디렉션 체인
  • 최종 URL과 프로토콜 협상
  • 제목, 캐노니컬, robots 지시문, hreflang, 구조화 데이터
  • 원시 HTML과 브라우저 렌더링 주 콘텐츠
  • Content-Type, Cache-Control, Vary, 압축, 보안 헤더
  • 이미지, 글꼴, JavaScript, CSS, PDF, 미디어 자산
  • 쿠키, 로그인·개인화 변형
  • 모바일·데스크톱 동작
  • 지연, time to first byte, 오류율

쌍으로 된 페이지 확인에는 스테이징과 프로덕션 SEO 비교를 사용하세요. 더 큰 인벤토리는 전체 크롤러와 스크립트 요청 모음으로 검사해야 합니다.

새 원본 준비

원본 준비는 콘텐츠와 구성 동등성에서 시작합니다. 현재 콘텐츠, 템플릿, 미디어, robots 규칙, 리디렉션, 오류 처리, 검증 파일을 복사하세요. 쓰기를 동결하거나 동기화해 오래된 데이터베이스로 출시하지 않게 합니다.

통제된 호스트명, 로컬 hosts 파일 재정의, 제공업체 미리보기 방식으로 원본을 직접 테스트하세요. 가상 호스트, 애플리케이션 라우팅, 인증서, 캐노니컬, 절대 링크가 의존할 수 있으므로 프로덕션 Host 헤더를 유지해야 합니다.

새 원본은 전환 후 부하도 감당해야 합니다. 애플리케이션과 데이터베이스를 예열하고 연결 풀과 자동 확장을 확인하며 캐시되지 않은 수요를 부하 테스트하세요. 출시 직후 CDN 캐시 미스가 원본에 트래픽을 집중시킬 수 있습니다.

CDN을 별도 시스템으로 구성하기

CDN 이동은 지리적 위치 이상을 바꿉니다. 기존·신규 엣지 동작을 명시적으로 비교하세요.

  • 쿼리 문자열, 쿠키, 헤더, 기기 변형을 포함한 캐시 키 구성
  • 캐시 가능한 상태 코드와 파일 유형
  • 브라우저 TTL, 엣지 TTL, 오래된 응답 제공, 재검증, 원본 실딩
  • 리디렉션, 재작성, 헤더 변환, 엣지 함수
  • 계정, 장바구니, 검색, 개인화 페이지의 캐시 우회
  • 압축과 이미지 최적화
  • 삭제 범위와 전파
  • WAF, 봇 관리, 속도 제한, 원본 보호

예를 들어 현재 Cloudflare 문서는 기본 캐싱이 원본 Cache-Control 헤더를 존중할 수 있지만 엣지 규칙으로 재정의할 수 있다고 설명합니다. 새 원본을 강제로 가져오기 위한 선택·전체 삭제도 제공합니다. 동작은 제공업체마다 다르므로 같은 이름의 설정이 같은 결과를 낸다고 가정하지 말고 구성을 내보내 비교하세요. Cloudflare 캐시 문서를 참고하세요.

캐시 동등성을 콘텐츠 동등성으로 다루기

캐시 설정은 잘못된 페이지를 빠르고 정상적으로 제공할 수 있습니다. 익명, 인증, 현지화, 모바일, 쿼리 문자열 변형을 테스트하세요. 중요한 쿠키나 헤더를 캐시 키에서 빼면 개인 콘텐츠가 유출될 수 있고 모든 추적 매개변수를 포함하면 캐시가 조각나 원본에 과부하를 줍니다.

출시 계획에 따라 중요 자산과 페이지를 삭제하거나 예열하세요. 결과적인 미스 폭주를 원본이 감당하는지 테스트하지 않았다면 피크 시간에 무작정 전체 삭제하지 마세요.

사용자→엣지와 엣지→원본 TLS 검증

CDN이 HTTPS를 종료할 때 TLS 검증은 브라우저→CDN과 CDN→원본 두 구간입니다. 호스트명 범위, 완전한 인증서 체인, 최신 프로토콜 지원, 갱신, 엄격한 원본 검증을 확인하세요.

원본 전용 인증서는 공개적으로 신뢰되지 않을 수 있습니다. Cloudflare는 프록시가 비활성화되거나 일시 중지되면 Origin CA 인증서가 브라우저 신뢰 오류를 낼 수 있다고 경고합니다. 엣지 전용 신뢰 모델의 원본으로 DNS 전용 롤백하면 사용자에게 실패할 수 있다는 뜻입니다. Cloudflare Origin CA 지침을 참고하세요.

와일드카드 가정과 드물게 쓰는 자산·지역 호스트를 포함해 모든 공개 호스트명을 테스트하세요. 유효한 루트 도메인 인증서가 모든 하위 도메인 범위를 입증하지는 않습니다.

이동 전에 DNS TTL 낮추기

TTL 계획은 전환 전에 시작합니다. Google은 이동 최소 한 주 전에 관련 TTL을 몇 시간 같은 보수적인 낮은 값으로 줄이라고 권합니다. DNS 제공업체가 다른 최솟값을 둘 수 있고 프록시 레코드는 고정값일 수 있습니다.

Cloudflare의 TTL 문서는 긴 값이 캐시 재사용을 늘리고 짧은 값이 레코드 변경을 더 빨리 반영한다는 절충을 설명합니다. 원래 TTL을 기록하고 새 인프라가 안정된 뒤에만 복원하세요.

분산 시스템에서 DNS 변경은 원자적이지 않을 수 있습니다. 전환 중 변경을 최소화하고 여러 공개 리졸버에서 응답을 확인하며 캐시된 답이 유효한 동안 기존 목적지를 유지하세요.

크롤러 접근과 보안 제어 검증

보안 동등성은 규칙 수의 동등성이 아닙니다. 다른 제공업체에서 복사한 WAF는 크롤러를 챌린지·차단하거나 쿼리 매개변수를 제거하고 응답을 재작성하거나 대량 크롤링의 속도 제한을 다르게 적용할 수 있습니다.

Google 호스팅 가이드는 방화벽과 서비스 거부 방어가 Googlebot의 DNS·호스팅 서버 접근을 막지 않게 하라고 합니다. 사용자 에이전트 문자열만 믿지 말고 Google의 공식 검증 방식으로 Googlebot을 확인하세요.

일반 크롤러 동작과 정상적인 버스트를 모두 테스트하세요. 위조 사용자 에이전트까지 보호를 해제하는 광범위 허용 목록은 피하세요. 차단 요청과 원본 실패를 구분할 수 있도록 보안 로그를 유지합니다.

이중 운영 계획

이중 운영은 DNS 전파 중 기존·신규 인프라가 모두 올바른 프로덕션 응답을 제공하는 상태입니다. 기존 환경도 사이트에 영향을 주는 콘텐츠·데이터 변경을 계속 받아야 합니다. 그렇지 않으면 캐시된 DNS로 기존 환경에 연결된 사용자가 오래된 재고, 끊긴 세션, 낡은 페이지를 봅니다.

동기화 전략을 선택하세요.

  • 두 스택이 공유하는 하나의 읽기·쓰기 데이터베이스
  • 지연과 충돌 정책을 이해한 복제 데이터
  • 전환 중 통제된 콘텐츠 동결
  • 주문, 양식, 사용자 쓰기를 위한 단방향 이벤트 복제

세션 상태, 업로드, 캐시 무효화, 백그라운드 작업도 같은 결정을 내려야 합니다. 상태가 갈라진다면 “서버 둘 다 켜짐”은 이중 운영 계획이 아닙니다.

The old environment is a rollback path only while it remains valid and synchronized. Retirement begins when logs prove the old path is no longer used. 출처: Website Hosting Migration SEO

Prepare builds the new origin and edge path. Validate tests controlled routing, parity, certificates, and capacity. Dual run keeps old and new environments correct and synchronized. Cut over changes only the planned DNS or edge route. Drain observes old-host requests in separate logs while the old environment remains available. Retire occurs only when old-host traffic reaches zero and dependencies have moved. A rollback lane remains available before retirement when a pre-agreed infrastructure failure occurs and the old state is still valid.

© Patrick Stox LLC · CC BY 4.0 ·

전환 실행

호스팅 전환은 의도적으로 지루해야 합니다.

  1. 관련 없는 배포를 중지하고 변경 창을 확인합니다.
  2. 최종 동등성, 인증서, 용량, 백업 검사를 실행합니다.
  3. 새 프로덕션 경로의 임시 크롤·접근 차단을 제거합니다.
  4. 계획된 DNS 또는 CDN 라우팅 레코드만 변경합니다.
  5. 여러 리졸버에서 예상 응답을 확인합니다.
  6. 사용자와 크롤러로 보호된 페이지를 공개 경로에서 요청합니다.
  7. 엣지, 새 원본, 기존 원본의 로그 수집을 확인합니다.
  8. 오류, 지연, 캐시 미스, 원본 부하, 전환을 관찰합니다.

호스트만 옮길 때 Google의 Change of Address 도구를 사용하지 마세요. 공개 URL이 바뀌지 않았으므로 보고할 주소 변경이 없습니다.

이동을 입증하는 증거 모니터링

인프라 모니터링은 기존·신규 트래픽을 분리해야 합니다. 배포 마커를 사용하고 계절성이 중요하면 같은 요일·시간 기준선과 비교하세요.

다음을 관찰하세요.

  • DNS 응답과 리졸버 전파
  • 사용자·검증된 크롤러별 기존·신규 호스트 요청
  • 엣지·원본 상태 코드 분포
  • TLS, 연결, 시간 초과, 애플리케이션 오류
  • 지연 백분위수와 캐시되지 않은 원본 응답 시간
  • 캐시 적중률과 원본 요청량
  • Googlebot 요청, Crawl Stats, Page Indexing, 대표 URL Inspection
  • 지역·네트워크별 합성 검사
  • 분석, 전환, 핵심 비즈니스 거래

Google은 호스팅 변경 직후 Googlebot 크롤 속도가 일시적으로 떨어졌다가 며칠 동안 증가할 수 있다고 합니다. 예상 패턴 하나만으로 판단하지 말고 접근성과 오류 증거에 근거하세요.

출시 전 롤백 정의

롤백은 라우팅을 정상으로 알려진 인프라 상태로 되돌리는 일이며 막연한 “DNS를 되돌린다”는 약속이 아닙니다. 다음을 문서화하세요.

  • 복원할 정확한 레코드, 경로, 구성
  • 승인자와 실행자
  • 변경 콘텐츠, 세션, 양식, 주문, 업로드 조정 방식
  • 기존 인증서와 의존성의 유효성
  • 두 경로의 캐시 삭제 단계
  • 롤백을 발동할 실패 임계값
  • 최대 안전 의사결정 시간

롤백 조건은 지속적 가용성 실패, 중대한 전환 장애, 광범위한 잘못된 콘텐츠, 인증서 실패, 크롤러 차단, 창 안에 수정할 수 없는 용량 붕괴처럼 관찰 가능해야 합니다. 일시적 크롤 속도 변화만으로 롤백하지 마세요.

달력이 아니라 로그로 기존 인프라 종료하기

기존 호스트는 사용자와 크롤러가 더 이상 도달하지 않고 의존 서비스가 모두 이동했다는 로그 증거 후 종료합니다. Google도 트래픽이 없어진 뒤 기존 호스트를 끄라고 권합니다.

비즈니스 요구사항에 맞게 구성 내보내기, 로그, 롤백 산출물을 보관하세요. 안정성을 입증한 뒤 DNS TTL을 정상 값으로 복원하고 임시 방화벽 예외와 중복 예약 작업을 제거해 영구적인 유지보수 혼란을 남기지 마세요.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.