curl -sS -D - -o /dev/null "$OLD_URL"

리디렉션을 따라가며 각 단계의 응답 헤더 확인

curl -sS -L -D - -o /dev/null "$OLD_URL"

결과를 기록하기 쉽도록 최종 상태와 최종 주소 출력

curl -sS -L -o /dev/null
-w 'status=%{http_code} final=%{url_effective}\n' "$OLD_URL"

검수 기록에는 최초 응답, 대상 주소, 최종 응답, 페이지 콘텐츠를 함께 보관해야 합니다. 영구 이전에 사용할 규칙 유형은 기술 책임자가 실제 배포 환경에 맞춰 확인해야 하며, 브라우저에서 “이동한 것처럼 보인다”는 것만으로 결론을 내려서는 안 됩니다.

불필요한 연속 리디렉션, 기존 주소로 되돌아가는 현상, 테스트 도메인으로 이동하는 현상, 대상 페이지가 존재하지 않는 상황은 출시 차단 항목으로 지정하세요. 특히 홈페이지 규칙만 확인하고 게시글이나 제품 상세 페이지를 빠뜨리지 않도록 주의해야 합니다.

## 5. 페이지 콘텐츠와 canonical은 어떻게 함께 검수해야 할까?

주소가 열린다는 것은 최소 요건일 뿐입니다. 각 페이지 템플릿에서 대표 페이지를 추출하여 제목, 주 제목, 본문, 이미지 대체 텍스트, 내부 링크, 문의 버튼이 온전한지 확인하세요. 가져오기 이후 페이지 틀만 남는 상황을 방지해야 합니다.

canonical은 대표 URL 점검 항목으로 활용할 수 있지만, 모든 마이그레이션 문제를 해결하는 대안으로 취급해서는 안 됩니다. 검수할 때 페이지가 선언한 대표 URL을 기록하고, 프로젝트에서 정한 정식 페이지와 일치하는지 확인하세요. 특히 여전히 기존 도메인, 미리보기 도메인, 관련 없는 페이지를 가리키는 경우를 점검해야 합니다.

다국어 웹사이트는 언어 버전 간 대응 관계도 추가로 확인해야 합니다. 중국어 제품 페이지가 일괄 치환 때문에 영어 홈페이지로 연결되어서는 안 됩니다. 언어 전환, 바닥글 링크, 본문의 추천 링크를 모두 실제로 클릭하여 테스트하세요.

마이그레이션 전후의 핵심 정보도 비교하세요. 가격 조건, 서비스 범위, 사례의 근거, 연락처가 템플릿 교체 과정에서 의도치 않게 삭제되어서는 안 됩니다. 영업 활동에 중요한 페이지는 개발 담당자의 기술 응답 점검에만 맡기지 말고 비즈니스 책임자도 검수에 참여하도록 하는 것이 좋습니다.

## 6. 사이트맵에서는 무엇을 확인해야 할까? 먼저 정식 페이지 목록과 대조하기

먼저 “공개하고 검색을 통해 발견되도록 할 정식 페이지 목록”을 정리한 뒤 생성된 사이트맵과 대조하는 것이 좋습니다. “XML 파일이 생성되었다”는 사실을 점검 완료로 간주하지 마세요.

다음 사항을 중점적으로 확인하세요.

- 사이트맵의 주소가 정식 도메인과 운영 환경에 속하는지 확인합니다.
- 마이그레이션 후의 새 경로가 계획대로 포함되어 있는지 확인합니다.
- 삭제된 주소, 여전히 리디렉션되는 주소, 아직 공개할 준비가 되지 않은 주소가 섞여 있는지 확인합니다.
- 사이트맵에 나열된 페이지가 해당 페이지에서 선언한 대표 URL과 일치하는지 확인합니다.
- 다국어 디렉터리, 게시글 페이지네이션, 제품 카테고리에서 유형 전체가 누락된 경우가 있는지 확인합니다.
- 사이트맵 업데이트와 재게시 담당자가 명확한지 확인합니다.

사이트맵 항목 수가 달라지면 그 이유를 확인해야 합니다. 콘텐츠를 계획적으로 통합한 결과인지, 가져오기 과정의 누락이나 필터 조건 오류 때문인지 살펴보세요. 항목별 비교를 위해 마이그레이션 전후 파일의 사본을 보관하는 것이 좋습니다.

사이트맵은 마이그레이션 검수의 일부일 뿐입니다. 제출을 완료한 뒤에도 개별 페이지의 접속, 콘텐츠, 이후 상태를 확인해야 하며, 사이트맵 제출만으로 색인 생성, 순위, 트래픽 성과를 약속할 수는 없습니다.

## 7. Search Console에서는 출시 전후에 각각 무엇을 확인해야 할까?

![7. Search Console에서는 출시 전후에 각각 무엇을 확인해야 할까?](https://we0-frontend.oss-cn-beijing.aliyuncs.com/growth-covers/3ae5ab5b-404e-4812-9473-4305e47b4bb6.png)

출시 전에는 먼저 팀이 관련 사이트 속성에 접근할 수 있는지, 기존 공급업체가 철수해도 담당자의 권한이 사라지지 않는지 확인하세요. 마이그레이션 이전의 주요 랜딩 페이지, 검색어, 클릭수, 노출 실적을 기록하고 관찰 날짜도 저장하여 이후 비교의 기준점으로 삼으세요.

출시 후에는 다음 순서로 점검하고 기록하는 것이 좋습니다.

1. **속성과 권한**: 현재 보고 있는 속성이 이번 마이그레이션 대상 사이트인지, 담당자가 여전히 접근 권한을 가지고 있는지 확인합니다.
2. **대표 URL**: 주요 페이지의 크롤링 상태, 색인 생성 상태, 대표 URL 정보를 확인하고 과거 기록과 이후 변화를 구분합니다.
3. **사이트맵**: 제출 대상, 처리 상태, 관련 안내를 확인하고, 이상이 있으면 실제 파일로 돌아가 원인을 조사합니다.
4. **페이지 문제**: 전체 개수만 보지 말고 디렉터리와 템플릿별로 이상을 정리합니다.
5. **실적**: 기존 페이지와 대응하는 새 페이지를 함께 보면서 검색어, 클릭수, 노출수를 비교합니다. 홈페이지만 비교해서는 안 됩니다.

도메인도 함께 변경한다면 주소 변경 관련 절차가 자신의 마이그레이션 상황에 적용되는지 별도로 확인해야 합니다. 동일 도메인에서 웹사이트 구축 도구를 바꾸는 작업과 도메인 간 마이그레이션을 혼동하지 마세요.

문제가 발견되면 페이지 주소, 표시된 안내, 관찰 시점, 재검증 결과를 하나의 작업 티켓에 함께 기록하세요. 단 한 번의 스크린샷만 보고 페이지를 삭제하거나 규칙을 반복해서 수정해서는 안 됩니다.

## 8. 출시 당일 검수와 롤백은 어떻게 준비해야 할까?

출시를 준비, 전환, 재검증, 관찰 단계로 나누는 것이 좋습니다. 준비 단계에서는 중요한 콘텐츠 변경을 동결하고 페이지 데이터와 설정을 백업하며, 기존 사이트에 필요한 접근 기능을 계속 유지할 수 있는지 확인하세요.

전환 후에는 기존 유입 경로로 진입하기, 제품 설명 읽기, 양식 제출, 알림 수신, 영업 후속 대응 등 핵심 비즈니스 흐름을 먼저 테스트하세요. SEO 점검과 잠재 고객 문의 점검을 동시에 진행하여 페이지는 열리지만 문의를 아무도 받지 못하는 상황을 방지해야 합니다.

출시 차단 조건은 미리 합의해야 합니다. 예를 들어 핵심 제품 페이지에 접속할 수 없거나, 다수의 기존 유입 경로에 예정된 연결 대상이 없거나, 정식 페이지가 여전히 테스트 환경의 제한을 받거나, 문의 절차가 작동하지 않는 경우입니다. 이러한 상황에서는 출시를 진행하면서 기준을 놓고 논쟁할 것이 아니라 책임자가 수정 또는 롤백을 결정해야 합니다.

롤백에도 작업 지침이 있어야 합니다. 누가 실행할 수 있는지, 어떤 설정을 복원해야 하는지, 복원 성공을 어떻게 확인할지 정해 두세요. 마이그레이션 당일에야 기존 사이트가 이미 삭제되었거나 이전 공급업체 계정의 권한이 만료되었다는 사실을 알게 되어서는 안 됩니다.

## 9. 마이그레이션 후 실적이 달라졌을 때 어떻게 체계적으로 조사해야 할까?

더 넓은 범위의 검색 실적을 논의하기 전에 반복 재현되는 기술 및 콘텐츠 문제부터 조사하는 것이 좋습니다. 페이지에 접속할 수 있는지, 기존 유입 경로의 연결 대상이 올바른지, 콘텐츠가 온전한지, 내부 링크가 업데이트되었는지, 사이트맵과 페이지의 선언 정보가 일치하는지 순서대로 살펴볼 수 있습니다.

데이터를 비교할 때는 같은 비즈니스 페이지의 기존 주소와 새 주소를 함께 보아야 합니다. 새 주소의 기록만 보면 마이그레이션 전 데이터를 놓치기 쉽고, 사이트 전체 합계만 보면 중요한 특정 디렉터리의 손실이 가려질 수 있습니다.

같은 기간의 광고 변경, 콘텐츠 삭제 및 수정, 계절성 캠페인, 분석 설정 조정도 기록하여 모든 변화를 플랫폼 변경 탓으로 돌리지 않도록 해야 합니다. 한 번에 명확한 문제 한 묶음만 수정하고 재검증 결과를 기록하면 여러 변경이 겹쳐 원인을 판단하기 어려워지는 상황을 줄일 수 있습니다.

모든 웹사이트에 공통으로 적용되는 회복 기한은 없습니다. 마이그레이션 검수를 위한 내부 재점검 주기는 정할 수 있지만, 이를 검색엔진의 처리 일정에 대한 약속처럼 제시해서는 안 됩니다.

## 10. AI 웹사이트 구축 플랫폼을 선택할 때 마이그레이션 역량은 어떻게 물어봐야 할까?

페이지 생성과 기존 사이트의 이전 수용은 서로 다른 두 가지 검수 작업입니다. [we0 공식 웹사이트](https://we0.ai/zh)는 자연어로 요구 사항을 설명하고, 여러 에이전트가 사이트를 구축하며, 시각적으로 수정하고, 도메인에 배포하는 과정을 소개합니다. 기업은 이를 바탕으로 구축 방식을 평가할 수 있지만, 기존 경로 유지, 리디렉션 설정, 마이그레이션 후 테스트 방법은 별도로 시연을 요청해야 합니다. 이러한 작업이 자동으로 완료될 것이라고 단정해서는 안 됩니다.

다른 유형의 제품을 참고하면, [Readdy 공식 웹사이트](https://readdy.ai/zh)는 코드 내보내기, 도메인 호스팅, SEO 및 GEO 관련 도구를 소개합니다. 구매할 때는 추가로 질문해야 합니다. 내보내기 후 배포 설정은 누가 유지·관리하는지, 경로 규칙은 누가 관리하는지, 이상이 발생하면 누가 조사하는지 확인하세요. 기능 이름이 프로젝트 책임 명세서를 대신할 수는 없습니다.

[알리바바 클라우드 개발자 커뮤니티의 완샤오즈 소개 글](https://developer.aliyun.com/article/1773673)은 대화형 웹사이트 구축과 배포 과정을 다루지만, 해당 페이지에는 사용자가 기여한 콘텐츠라고 명시되어 있습니다. 팀이 웹사이트 구축 시나리오를 이해하는 데는 적합하지만, 공급업체가 이 프로젝트의 마이그레이션 납품 범위를 약속한 것으로 간주해서는 안 됩니다.

구매와 출시 계획을 결정하기 전에 후보 플랫폼이나 구축 수행업체가 소수의 실제 기존 페이지를 사용해 시연하도록 하는 것이 좋습니다. 시연은 새 홈페이지 하나를 생성하는 데 그치지 않고 서로 다른 템플릿과 예외 상황까지 포함해야 합니다.

## 자주 묻는 질문

### 도메인은 그대로 두고 웹사이트 구축 플랫폼만 바꾸는 경우에도 마이그레이션 체크리스트가 필요한가요?

필요합니다. 경로, 본문, 페이지의 선언 정보, 내부 링크, 문의 절차가 일관되게 유지되는지 확인하는 것이 좋습니다. 도메인이 바뀌지 않았다고 해서 모든 배포 결과가 자동으로 원래 계획에 부합하는 것은 아닙니다.

### 모든 기존 페이지를 홈페이지로 보내도 되나요?

이를 기본 방안으로 삼는 것은 권장하지 않습니다. 먼저 각 기존 페이지를 이어받을 관련 새 페이지가 있는지 판단해야 합니다. 대체 콘텐츠가 없는 경우에도 홈페이지로 누락을 감추지 말고 처리 방식을 명확히 기록해야 합니다.

### 사이트맵을 제출하면 마이그레이션이 완료된 것인가요?

아닙니다. 기존 유입 경로 테스트, 주요 페이지 점검, 비즈니스 흐름 검수도 완료해야 하며, Search Console의 상태 변화를 계속 기록해야 합니다. 제출 작업은 실제 접속 테스트를 대신할 수 없습니다.

## 관련 도구

- **URL 매핑표**: 기존 경로, 새 경로, 처리 방식, 담당자를 관리합니다.
- **curl**: 응답 헤더, 리디렉션 과정, 최종 주소를 확인합니다.
- **Google Search Console**: 사이트 관련 상태와 검색 실적 점검 기록을 정리합니다.
- **브라우저 개발자 도구**: 페이지 로딩, 링크, 양식 요청을 재검증합니다.

## 관련 링크

- [we0: 웹사이트 구축, 페이지 수정, 배포 과정](https://we0.ai/zh)
- [Readdy: 웹사이트 구축, 코드 내보내기, 운영 도구 소개](https://readdy.ai/zh)
- [알리바바 클라우드 개발자 커뮤니티: 완샤오즈 AI 웹사이트 구축 시나리오 소개](https://developer.aliyun.com/article/1773673)

## 요약

웹사이트 구축 플랫폼을 변경할 때 검수해야 할 대상은 새 웹사이트만이 아니라, 기존 유입 경로에서 새 콘텐츠를 거쳐 문의 행동으로 이어지는 전체 경로입니다. 먼저 URL 매핑표를 작성하고, 리디렉션, 페이지 콘텐츠, 사이트맵, 비즈니스 흐름을 테스트한 뒤, Search Console을 활용해 지속적으로 문제를 조사하세요. 플랫폼의 역량은 실제 페이지 시연으로 확인해야 하며, 마이그레이션 책임과 롤백 조건은 출시 전에 명확히 문서화해야 합니다.