워드프레스 서버 이전은 새 서버에서 홈페이지가 정상적으로 열리는 것만으로 끝나지 않는다. 기존에 사용하던 Google Site Kit, AdSense, ads.txt, Search Console, 사이트맵과 GA4까지 새 서버에서 정상적으로 이어지는지 확인해야 검색·광고·분석 환경까지 이전이 제대로 마무리됐다고 볼 수 있다.
이번에는 Cloudways에서 ChemiCloud로 웹호스팅 서버만 변경했고 도메인과 기존 게시글 URL은 그대로 유지했다. 따라서 Google 서비스를 처음부터 새로 등록하는 것이 아니라 기존 설정과 데이터가 새 서버에서도 정상적으로 이어지는지를 확인하는 것이 핵심이다.
실제 점검 과정에서는 Site Kit에서 다른 관리자가 이미 설정했다는 안내가 나타났고 네이버 웨일에서 Google 계정 인증이 정상적으로 끝나지 않는 문제도 발생했다. 같은 WordPress 사이트와 Google 계정을 Chrome 시크릿 창에서 다시 인증하자 해결됐으며, PageSpeed Insights에서는 Performance 96점과 함께 Site Kit 관련 JavaScript 콘솔 오류도 발견했다.
이 글에서는 서버 이전 후 확인해야 할 Google 서비스와 실제 오류 해결 과정을 순서대로 정리한다.
※ 아래 도메인은 실제 운영주소 대신 가상의 예시 주소로 표기한다.
mywpblog.invalid
ed.mywpblog.invalid
he.mywpblog.invalid
서버 이전 후 가장 먼저 Google Site Kit을 확인한다
WordPress에서 Google Site Kit을 사용했다면 기존 Google 서비스가 그대로 연결돼 있는지 먼저 확인한다. 서버 이전만 했는데 Search Console이나 GA4를 새로 만드는 것부터 시작하면 기존 데이터 흐름을 오히려 복잡하게 만들 수 있다. WordPress 관리자에서는 다음 경로로 들어간다.
Site Kit → Settings → Connected Services
여기에서 기존에 연결했던 Search Console, Analytics, AdSense 등의 상태를 확인한다.
Site Kit에서 다른 관리자가 설정했다는 안내가 나타났다
이번 서버 이전 후 Site Kit에 접속했을 때 다음 안내가 나타났다.
Site Kit has already been configured by another admin of this site.
이 메시지는 다른 WordPress 관리자 계정이 이미 Site Kit을 설정했다는 의미다. 기존 Site Kit 설정이 사라졌거나 서버 Migration에 실패했다는 뜻은 아니며, 현재 관리자도 해당 사이트의 Google 서비스에 접근할 수 있는 자신의 Google 계정으로 인증하면 된다.
따라서 이 메시지만 보고 Site Kit을 바로 Reset하거나 삭제할 필요는 없다. Site Kit Reset은 플러그인이 배치한 코드와 설정을 다시 구성해야 할 수 있으므로 먼저 계정 권한과 인증 환경을 확인하는 편이 안전하다.
네이버 웨일에서는 Google 인증이 정상적으로 끝나지 않았다
네이버 웨일에서 Google 계정 인증을 진행했지만 로그인 이후 WordPress Site Kit으로 정상적으로 돌아오지 않고 Google 계정 화면에 머무는 현상이 반복됐다. 처음에는 서버 이전 과정에서 인증 정보에 문제가 생긴 것인지 의심했지만 같은 사이트와 Google 계정을 다른 브라우저 환경에서 다시 테스트했다.
Chrome 시크릿 창에서 다시 인증하자 해결됐다
Chrome → 새 시크릿 창 → WordPress 관리자 로그인 → Site Kit → Sign in with Google
기존 Search Console과 Analytics에 접근할 수 있는 Google 계정으로 로그인하자 인증 후 Site Kit으로 정상적으로 돌아왔다. 같은 ChemiCloud 서버와 같은 WordPress 사이트에서 Chrome 시크릿 창에서는 인증이 성공했기 때문에 이번 증상만으로 서버 이전 자체를 원인이라고 단정하기는 어려웠다.
이 경우 기존 브라우저의 로그인 세션, 쿠키, 개인정보 보호 설정이나 확장 프로그램 등 브라우저 환경을 먼저 확인할 수 있다. 서버 이전 후 Site Kit 로그인이 정상적으로 끝나지 않는다면 바로 Reset하기보다 다른 브라우저나 Chrome 시크릿 창에서 재인증해보는 것이 우선이다.
사이트 목적은 Monetize content를 선택했다
Google 계정 인증이 끝난 뒤 Site Kit에서 사이트의 주된 목적을 묻는 화면이 나타났다. 실제 화면에는 Sell products, Provide services, Monetize content, Publish a blog, Publish news content 등의 선택지가 표시됐다.
이번 사이트는 검색 콘텐츠를 운영하면서 AdSense 광고수익을 얻는 것이 주요 목적이므로 Monetize content를 선택했다. 이 질문은 Site Kit이 사이트 목적에 맞는 Key Metrics를 추천하기 위한 설정으로 검색 순위나 AdSense 승인 여부를 결정하는 항목은 아니다.
Connected Services에서 기존 서비스 연결을 확인한다
Site Kit → Settings → Connected Services
Search Console, Analytics, AdSense 등 서버 이전 전에 사용하던 서비스가 Connected 상태인지 확인한다. Analytics의 세부 Property와 Measurement ID는 뒤의 GA4 점검에서 다시 확인한다.
AdSense 사이트 상태와 ads.txt를 확인한다
Site Kit 다음에는 Google AdSense를 점검한다. 같은 도메인을 그대로 사용하면서 호스팅만 변경했다면 기존 AdSense 사이트를 삭제하거나 다시 추가하는 것보다 기존 사이트의 승인 상태와 ads.txt가 정상적으로 유지되는지를 먼저 확인한다.
AdSense에서 기존 사이트 상태를 확인한다
Google AdSense에 로그인한 뒤 다음 경로로 이동한다.
AdSense → 사이트
이번 확인에서는 기존 사이트가 Site Kit by Google에 연결됨, 사이트 상태는 준비됨, ads.txt는 승인됨으로 표시됐다. 준비됨은 사이트가 광고를 게재할 준비가 된 상태이고, 승인됨은 ads.txt에서 해당 게시자 ID가 확인된 상태다.
ads.txt는 브라우저에서 직접 열어본다
새 서버에서 ads.txt가 정상적으로 제공되는지도 직접 확인한다.
https://mywpblog.invalid/ads.txt
정상이라면 404 페이지가 아니라 ads.txt 내용이 표시돼야 한다. Google AdSense용 항목은 일반적으로 다음과 같은 형식이다.
google.com, pub-게시자번호, DIRECT, f08c47fec0942fa0
실제 Publisher ID는 자신의 AdSense 계정 값을 사용하며 공개 글이나 캡처 이미지에서는 가리는 것이 좋다. AdSense 사이트 메뉴에서도 ads.txt 상태를 확인하고 승인됨 또는 Authorized라면 해당 사이트의 ads.txt에서 게시자 ID가 확인된 상태다.
실제 게시글의 광고도 확인한다
관리자 화면만 확인하고 끝내지 않고 기존에 광고가 정상적으로 표시되던 대표 게시글 몇 개를 직접 연다. 메인 페이지와 게시글에서 광고 영역이 깨지지 않았는지, 실제 광고가 표시되는지도 확인한다.
한 번 광고가 보이지 않는다고 바로 서버 이전 문제로 판단하지 않는다. AdSense 사이트 상태, ads.txt, 광고 코드와 브라우저 환경을 함께 확인해야 원인을 구분하기 쉽다.
Search Console은 새로 등록하지 않고 기존 상태를 확인한다
이번 작업은 Cloudways에서 ChemiCloud로 호스팅 인프라만 변경했고 사용자에게 표시되는 도메인과 게시글 URL은 그대로 유지했다. Google은 이런 작업을 URL 변경 없는 호스팅 이전으로 구분한다.
따라서 Search Console 주소 변경 도구를 사용하거나 기존 속성을 버리고 새 속성을 만드는 방식이 아니다. 기존 Search Console 소유권과 사이트맵, 주요 URL의 크롤링 상태가 정상적으로 유지되는지 확인하는 것이 핵심이다.
Search Console 소유권이 유지되는지 확인한다
Google Search Console에 접속하면 먼저 왼쪽 위의 ☰ 메뉴 버튼을 누른다.
왼쪽 사이드바가 열리면 상단의 속성 선택 영역에서 기존에 등록한 사이트를 선택한다. 이번 사례에서는 https://mywpblog.invalid/ 형태의 URL-prefix 속성을 선택했다.
사이트 속성을 선택하면 개요, 실적, URL 검사, 색인 생성 등의 메뉴가 나타난다. 왼쪽 메뉴를 아래로 내려 설정을 누른 뒤 소유권 인증으로 들어간다.
☰ 메뉴 → 기존 사이트 속성 선택 → 설정 → 소유권 인증
이번 실제 확인에서는 화면 상단에 ‘인증된 소유자입니다’라고 표시됐고, 기존에 사용한 확인 방법인 HTML 태그와 도메인 이름 공급업체가 모두 ‘확인이 완료되었습니다’ 상태였다. 따라서 서버 이전 후에도 기존 Search Console 소유권 인증이 정상적으로 유지되고 있음을 확인할 수 있었다.
도메인 이름 공급업체 방식도 확인 완료로 표시됐다면 DNS 인증에 사용한 확인 레코드가 현재 DNS 환경에서도 정상적으로 유지되고 있다는 것을 확인하는 데 도움이 된다. 기존 HTML 태그나 DNS 확인 레코드는 특별한 이유 없이 삭제하지 않는 것이 좋다.
URL-prefix 속성만 사용하는 경우 Search Console에서 Domain 속성을 추가하라는 안내가 나타날 수 있다. 이는 서버 이전 오류가 아니라 모든 프로토콜과 하위도메인을 하나의 속성에서 관리할 수 있도록 권장하는 안내이므로 기존 소유권 확인과는 구분한다.
서버 이전만 했다면 주소 변경 도구는 사용하지 않는다
예를 들어 기존 게시글 주소가 다음과 같았다면
https://mywpblog.invalid/example-post/
Search Console의 주소 변경 도구는 도메인이나 하위도메인 주소 자체가 다른 주소로 변경되는 경우에 사용하는 기능이다. 이번처럼 공개 URL은 그대로 두고 호스팅 업체만 변경했다면 사용할 필요가 없다.
중요한 것은 새 서버에서 기존 URL이 정상적으로 열리고 Googlebot이 접근할 수 있는지를 확인하는 것이다.
기존 사이트맵 상태를 확인한다
기존 사이트맵의 상태가 성공인지 확인한다.
사용하는 WordPress SEO 플러그인에 따라 주소는 다르지만 예를 들면 다음과 같은 형태다.
https://mywpblog.invalid/sitemap_index.xml
브라우저에서도 사이트맵 URL을 직접 열어보고 Search Console에서도 정상 상태인지 확인한다. 기존 사이트맵 주소가 그대로이고 Google이 정상적으로 읽고 있다면 서버를 변경했다는 이유만으로 기존 사이트맵을 삭제한 뒤 다시 제출할 필요는 없다.
대표 URL 몇 개를 실제 URL 테스트한다
모든 게시글에 다시 색인 생성 요청을 할 필요는 없다. 홈페이지, 최근 게시글, 검색 유입이 많은 기존 게시글, 오래된 게시글과 하위도메인은 해당 하위도메인의 Search Console 속성을 선택하거나, 하위도메인을 포함하는 Domain 속성이 있는 경우 그 속성에서 검사한다.
Search Console 상단 검색창에 전체 URL을 입력하면 Google이 현재 알고 있는 색인 정보를 확인할 수 있다. 서버 이전 직후 현재 페이지 상태를 확인하려면 실제 URL 테스트를 실행해 Google이 새 서버의 페이지에 접근할 수 있는지도 살펴본다.
실시간 테스트가 정상이라고 해서 Google 검색 노출이나 색인이 보장되는 것은 아니다. 이 검사는 현재 페이지를 Google이 가져오고 색인 가능 여부를 검사할 수 있는지를 확인하는 용도로 사용하는 것이 정확하다.
새롭게 발생한 서버 오류와 404를 확인한다
Search Console 소유권과 사이트맵이 정상이라면 서버 이전 이후 기존 게시글에서 새로운 404나 서버 오류가 발생하지 않았는지 확인한다.
Google Search Console → 왼쪽 위 ☰ 메뉴 → 기존 사이트 속성 선택 → 색인 생성 → 페이지
페이지 보고서의 ‘페이지가 색인되지 않는 이유’를 확인하면 찾을 수 없음(404), 서버 오류(5xx), robots.txt 차단, noindex 등 색인되지 않은 원인을 살펴볼 수 있다. 다만 404나 noindex가 있다고 해서 모두 서버 이전 문제는 아니다. 삭제된 게시글이나 의도적으로 검색 노출을 막은 페이지도 포함될 수 있기 때문이다.
중요한 것은 서버 이전 전까지 정상적으로 열리고 검색되던 주요 게시글에서 새롭게 404나 5xx 오류가 발생했는지를 확인하는 것이다. 문제가 의심되는 URL이 있다면 Search Console 상단의 URL 검사에 전체 주소를 입력한 뒤 ‘실제 URL 테스트’를 실행해 현재 새 서버에서 Google이 해당 페이지에 접근할 수 있는지 확인한다.
GA4는 기존 Property를 유지하고 실시간 데이터까지 확인한다
사이트가 정상적으로 열려도 Google Analytics 측정 코드가 작동하지 않으면 방문자 통계는 수집되지 않는다. 서버 이전 후에는 새로운 GA4 Property를 만드는 것보다 기존 Site Kit에 연결돼 있던 Analytics 설정이 유지되는지 먼저 확인하고, Google Analytics에서도 같은 Property와 데이터 스트림을 사용하는지 점검한다.
Site Kit과 GA4 연결 정보를 서로 비교한다
먼저 WordPress 관리자에서 Site Kit에 연결된 Analytics 정보를 확인한다.
여기에서 Analytics가 Connected 상태인지 확인하고 Property ID, Measurement ID(G-로 시작), Code Snippet 상태를 확인한다. 기존에 Site Kit이 Analytics 코드를 삽입하고 있었다면 별도의 GA4 태그를 추가하지 않고 기존 설정이 유지되는지부터 확인한다.
다음으로 Google Analytics에 접속해 Site Kit에서 확인한 것과 같은 Property를 선택한다. Property가 여러 개 있다면 이름보다 숫자로 된 Property ID를 기준으로 찾는 것이 정확하다.
Google Analytics → 같은 Property 선택 → 관리자 → 데이터 수집 및 수정 → 데이터 스트림 → 웹 → 해당 사이트 스트림 선택
웹 스트림 세부정보에서 사이트 주소와 Measurement ID를 확인한다. Site Kit과 Google Analytics에서 같은 Property와 데이터 스트림을 사용하고 있는지 비교하면 된다. 값이 다르다면 바로 새 Property나 태그를 만들지 말고 Site Kit에 실제로 연결된 Analytics 설정과 웹 데이터 스트림을 다시 확인한다.
마지막으로 Google Analytics → 보고서 → 실시간에서 실제 방문 데이터가 들어오는지 확인한다. Site Kit에서 로그인 사용자를 Analytics에서 제외하도록 설정돼 있다면 Chrome 시크릿 창에서 WordPress에 로그인하지 않은 상태로 사이트에 접속하고 게시글 1~2개를 열어본다. 실시간 보고서에 활성 사용자나 페이지 조회가 나타난다면 새 서버에서도 GA4 데이터 수집이 작동하는지 확인할 수 있다.
PageSpeed Insights에서 속도와 콘솔 오류를 함께 확인한다
Google 서비스 연결을 확인한 뒤 PageSpeed Insights에서 메인 사이트를 측정했다. 이번 측정에서 Performance 점수는 96점으로 나타나 기본적인 페이지 성능은 양호한 편이었다.
하지만 Performance 점수만 보고 끝내지 않고 Best Practices와 진단 내용도 확인했다. 그 과정에서 Google Site Kit의 sign-in-with-google 관련 JavaScript에서 다음 콘솔 오류가 발견됐다.
Error: Google identity services not found.
Performance 96점이어도 별도의 오류가 있을 수 있다
PageSpeed Insights의 Performance 점수가 높더라도 JavaScript 콘솔 오류가 별도로 존재할 수 있다. 반대로 콘솔 오류 하나가 발견됐다고 서버 Migration 전체가 실패했다는 의미도 아니다.
오류가 나타나면 메시지만 보는 것이 아니라 어떤 파일이나 플러그인에서 발생했는지 함께 확인한다. 이번에는 Site Kit 관련 JavaScript가 오류 출처로 표시됐기 때문에 해당 기능을 별도로 살펴봤다.
Site Kit 관리자 인증과 Sign in with Google 서비스는 구분한다
앞에서 Chrome 시크릿 창으로 해결한 것은 WordPress 관리자가 Site Kit에 자신의 Google 계정을 인증하는 과정이다. 반면 Site Kit의 Sign in with Google은 WordPress 사용자가 기존 아이디와 비밀번호 대신 Google 계정으로 사이트에 로그인할 수 있도록 제공하는 별도의 기능이다.
Site Kit → Settings → Connected Services 또는 Connect More Services → Sign in with Google
이름은 비슷하지만 용도가 다르므로 PageSpeed에서 발견된 sign-in-with-google JavaScript 오류와 네이버 웨일에서 발생한 Site Kit 관리자 인증 문제를 같은 원인이라고 단정하지 않는다. 실제로 Sign in with Google 기능을 사용한다면 해당 오류를 추가로 확인하고, 사용하지 않는다면 오류 출처와 해당 기능의 필요성을 먼저 구분해서 판단한다. PageSpeed의 오류 한 줄만 보고 Site Kit을 삭제하거나 서비스를 무작정 끄는 것은 피한다.
메인 도메인과 하위도메인은 각각 확인한다
이번 서버에는 메인 WordPress와 두 개의 하위도메인 WordPress가 각각 독립적으로 운영되고 있다.
mywpblog.invalid
ed.mywpblog.invalid
he.mywpblog.invalid
메인 사이트가 정상이라고 세 WordPress 설치가 모두 정상이라고 볼 수는 없다. 각 사이트에서 서버 이전 전에 실제로 사용하던 Site Kit, Search Console, Analytics, AdSense와 사이트맵 상태를 각각 확인한다.
세 사이트의 Google 서비스 구성이 반드시 동일할 필요는 없다. 새로운 서비스를 억지로 동일하게 맞추기보다 서버 이전 전에 사용하던 구성이 새 서버에서도 정상적으로 이어지는지를 기준으로 확인하면 된다.
검색 유입과 Googlebot 크롤링은 며칠간 추이를 본다
호스팅 이전 직후에는 Googlebot의 크롤링이나 Search Console 통계가 일시적으로 변할 수 있으므로 하루의 수치만 보고 검색 순위가 떨어졌다고 판단하지 않는다.
Search Console → 기존 사이트 속성 선택 → 실적 → 검색 결과
클릭수, 노출수, CTR과 평균 게재순위의 서버 이전 전후 흐름을 살펴보고, 페이지 색인과 대표 URL 검사 결과도 함께 확인한다. 특히 이전까지 정상적으로 검색되던 주요 게시글에서 새로운 404나 서버 오류가 발생하지 않았는지가 중요하다.
하루의 숫자보다 서버 이전 전후 며칠 동안의 검색 유입과 크롤링 흐름, 오류 발생 여부를 함께 살펴보는 것이 좋다.
Google 서비스가 정상이어도 Cloudways는 바로 삭제하지 않는다
Site Kit, AdSense, Search Console과 GA4가 정상적으로 보인다고 그 순간 기존 Cloudways 서버를 바로 삭제하지 않는다. DNS 변경 후에는 사용자와 Googlebot이 새 서버에서 정상적으로 콘텐츠를 받고 있는지 일정 기간 확인하는 편이 안전하다.
새 ChemiCloud 서버에서 사이트와 Google 서비스가 안정적으로 작동하고 이전 호스팅을 사용할 필요가 없다는 것을 확인한 뒤 기존 Cloudways 서버를 종료한다. 이번 4편에서는 검색·광고·분석 환경까지 정상적으로 이어지는지를 확인하고 실제 Cloudways 해지는 마지막 단계로 남겨둔다.
워드프레스 서버 이전 후 최종 점검 순서
1. Site Kit Google 계정 인증과 Connected Services 확인
2. 인증 오류가 있으면 다른 브라우저 또는 Chrome 시크릿 창에서 재확인
3. AdSense 사이트의 준비됨 상태와 ads.txt 승인 상태 확인
4. ads.txt 직접 접속과 실제 게시글 광고 확인
5. Search Console 소유권 인증과 기존 사이트맵 확인
6. 대표 URL 실제 URL 테스트와 새로운 404·5xx 오류 확인
7. Site Kit과 GA4의 Property ID·Measurement ID 비교
8. GA4 실시간 데이터 수집 확인
9. PageSpeed Insights Performance와 콘솔 오류 확인
10. 메인 도메인과 하위도메인별 Google 서비스 점검
11. 며칠간 Search Console 검색 유입과 크롤링 추이 확인
12. 안정화 확인 후 기존 Cloudways 서버 정리
서버 이전 후 핵심은 Google 서비스를 처음부터 다시 만드는 것이 아니다. 도메인과 기존 URL이 그대로라면 Search Console, AdSense, GA4와 Site Kit의 기존 설정이 새 호스팅 환경에서도 정상적으로 이어지는지를 확인하는 것이 우선이다.
하나의 오류를 발견했다고 전체 Migration 실패로 단정할 필요도 없다. 이번 Site Kit 인증 문제처럼 브라우저 환경을 바꾸자 해결될 수도 있고 PageSpeed의 JavaScript 오류처럼 특정 기능만 별도로 점검해야 하는 경우도 있다. 서버, DNS, SSL에 이어 검색·광고·분석 환경까지 확인한 뒤 기존 서버를 정리하면 WordPress 서버 이전도 마무리 단계에 들어간다.
FAQ
서버를 바꾸면 Search Console을 새로 등록해야 하나?
도메인과 기존 URL을 그대로 유지한 호스팅 이전이라면 기존 Search Console 속성을 계속 사용하는 것이 기본이다. 주소 변경 도구도 사용할 대상이 아니다.
서버 이전 후 사이트맵을 다시 제출해야 하나?
기존 사이트맵 URL이 그대로이고 Search Console에서 정상적으로 읽히고 있다면 서버를 변경했다는 이유만으로 삭제한 뒤 다시 제출할 필요는 없다.
모든 게시글을 다시 색인 생성 요청해야 하나?
그럴 필요는 없다. 대표 URL을 실제 URL 테스트로 확인하고 사이트맵과 페이지 색인 상태를 모니터링하는 것이 우선이다. 여러 페이지의 크롤링은 사이트맵을 활용하는 것이 적절하다.
Site Kit에서 다른 관리자가 이미 설정했다고 나오면 문제가 생긴 것인가?
다른 WordPress 관리자 계정이 이미 Site Kit을 구성한 경우 나타날 수 있다. 현재 관리자 역시 해당 Google 서비스에 접근 권한이 있는 자신의 Google 계정으로 인증하면 된다.
Site Kit Google 로그인이 끝나지 않으면 어떻게 하나?
이번 사례에서는 네이버 웨일에서 인증이 끝나지 않았지만 같은 사이트와 Google 계정을 Chrome 시크릿 창에서 인증하자 해결됐다. Site Kit을 Reset하기 전에 다른 브라우저와 시크릿 창부터 테스트해볼 수 있다.
서버 이전 후 GA4 Property를 새로 만들어야 하나?
도메인과 측정 구성을 그대로 유지한다면 기존 GA4 Property와 Web Data Stream을 계속 사용하는 것이 기본이다. 실시간 보고서에서 실제 데이터 수집 여부를 확인한다.
PageSpeed에서 Google identity services not found가 나오면 서버 이전 실패인가?
이 오류 하나만으로 서버 이전 실패라고 볼 수 없다. 이번에는 Site Kit의 sign-in-with-google 관련 JavaScript에서 발견됐으므로 해당 기능과 오류 출처를 별도로 확인해야 한다.
공식 출처·확인처
Google Search Central - URL 변경 없는 호스팅 이전
Google Search Console - 사이트 소유권 확인
Google Search Console - URL 검사 도구
Google Search Console - 사이트맵 관리
Google Site Kit - Sign in with Google
Google Analytics - 실시간 페이지 보고서
Chrome for Developers - Lighthouse 브라우저 콘솔 오류
함께 보면 좋은 글
1화 클라우드웨이즈 케미클라우드 이전 방법｜워드프레스 호스팅 비용 줄이기 실제 과정
2화 Cloudways 서버 정보 확인 및 워드프레스 무료 마이그레이션 신청 방법
3화 워드프레스 마이그레이션 후 해야 할 일｜네임서버 변경·DNS·SSL 설치
다음 5편에서는 Cloudways와 ChemiCloud의 실제 비용과 속도, 관리 편의성을 비교하고 새 서버가 안정적으로 운영되는 것을 확인한 뒤 기존 Cloudways 서버를 정리하는 과정까지 이어간다.