서버 이전할 때 SEO가 떨어지지 않게 하는 체크리스트
같은 도메인과 URL을 유지하는 서버 이전이라면 SEO 핵심은 새 서버가 기존 URL을 동일한 200/301 응답, canonical, robots, sitemap으로 제공하게 만드는 것입니다. DNS 전환 전후의 크롤러 접근과 오류 로그를 반드시 비교해야 합니다.
서버 이전 자체가 검색 순위를 떨어뜨리는 것은 아닙니다. 문제는 이전 과정에서 URL, 상태코드, robots, canonical, 속도가 바뀌는 경우입니다.
- 가능하면 도메인과 URL 구조를 그대로 유지합니다.
- DNS TTL을 미리 낮추고 구·신 서버를 겹쳐 운영합니다.
- robots.txt, sitemap, canonical, redirect가 이전 전후 동일한지 비교합니다.
- 전환 직후 404/5xx와 검색봇 로그를 집중 모니터링합니다.
이전 전 48시간
DNS TTL을 낮추고, DB·업로드·환경파일·cron·SSL 의존성을 목록화합니다. 특히 현재 사이트의 URL 목록과 상태코드를 저장해두면 이전 후 비교가 쉬워집니다.
새 서버 검증
DNS를 바꾸기 전에 hosts 파일이나 임시 도메인으로 새 서버를 확인합니다. 단 임시 도메인이 검색에 색인되지 않도록 주의하고, 최종 canonical은 실제 도메인을 가리키게 해야 합니다.
| 검증 | 이전 전 | 이전 후 |
|---|---|---|
| 핵심 URL 상태 | 200/301 기록 | 동일 여부 |
| canonical | 원본 도메인 | 동일 여부 |
| robots | 허용 정책 | 동일 여부 |
| sitemap | URL 수 | 동일/의도된 변화 |
DNS 전환
구 서버를 즉시 끄지 말고 일정 시간 겹쳐 운영하면 DNS 캐시가 남은 사용자와 크롤러도 정상 응답을 받을 수 있습니다. DB가 실시간 갱신되는 서비스라면 마지막 동기화 시점을 명확히 잡아야 합니다.
전환 후 모니터링
첫 24~72시간에는 404, 5xx, TLS 오류, 응답속도, 검색봇 접근 로그를 집중해서 봅니다. Search Console의 크롤링·색인 상태도 함께 확인합니다.
URL도 바뀌는 경우
도메인이나 URL 구조가 함께 바뀐다면 단순 서버 이전보다 복잡합니다. 각 구 URL을 가장 대응되는 새 URL로 301 리디렉션하고, 내부링크·canonical·sitemap을 새 URL 기준으로 갱신해야 합니다. 무조건 홈으로 보내는 일괄 리디렉션은 피하는 편이 좋습니다.
자주 묻는 질문
서버 IP가 바뀌면 SEO가 떨어지나요?
IP 변경 자체보다 크롤링 가능성, 응답 상태, 속도, URL·콘텐츠 유지 여부가 더 중요합니다.
DNS TTL은 언제 낮추나요?
이전 전에 충분한 시간 여유를 두고 낮춰 기존 캐시가 만료되도록 하는 것이 좋습니다.
구 서버는 바로 꺼도 되나요?
DNS 전파와 캐시를 고려하면 일정 기간 병행 운영하는 편이 안전합니다.
공식 출처
이 글의 사실 확인에 사용한 1차 자료입니다. 정책과 제품 기능은 바뀔 수 있으므로 적용 전 최신 문서를 다시 확인하는 것이 좋습니다.
문의는 텔레그램으로 받습니다.