웹사이트 리뉴얼 SEO 요구사항 문서는 어떻게 작성할까요? 마이그레이션 및 검수 핵심 체크리스트

웹사이트 리뉴얼에서 프로젝트 일정과 검색 트래픽을 어떻게 함께 고려할 수 있을까요? “cahier des charges seo refonte d'une site”와 같은 웹사이트 리뉴얼 SEO 요구사항 문서를 작성할 때 프로젝트 책임자가 실제로 해결해야 할 과제는 최적화 제안을 몇 가지 더 작성하는 것이 아닙니다. 마이그레이션 범위, 업무 책임, 검수 기준에 대해 디자인·개발·콘텐츠·마케팅 팀이 합의하도록 하는 것입니다. 페이지가 열리는 것은 시작에 불과합니다. 기존 트래픽이 새 사이트의 올바른 페이지를 찾을 수 있는지가 출시 시 가장 쉽게 간과되는 부분입니다.

작업을 시작하기 전에 기존 사이트 자산과 리뉴얼 범위를 명확히 정리하세요

요구사항 문서를 “새 홈페이지를 더 보기 좋게 만들기”로 시작하지 마세요. 이번에 변경하는 것이 디자인, 콘텐츠 관리 시스템, 도메인, 디렉터리 구조 중 무엇인지, 또는 여러 항목을 함께 변경하는지 먼저 확인하세요. 도메인과 경로를 그대로 유지하는 리뉴얼이라면 페이지 콘텐츠와 기술 구현이 주요 검토 대상일 수 있습니다. 도메인을 바꾸고 다국어 디렉터리 구조도 조정한다면 마이그레이션 테스트와 출시 후 모니터링 기간을 별도로 계획해야 합니다.

기존 사이트 목록에는 최소한 현재 URL, 페이지 유형, 제목, 상태 코드, 표준 URL, 자연 검색 유입이나 문의에 기여한 페이지를 포함해야 합니다. 사이트 크롤링 결과, Google Search Console, 웹 분석 도구, 영업팀 기록을 함께 확인해 데이터를 대조할 수 있습니다. 최근 트래픽만 살펴보지 마세요. 계절성 제품이나 구매 주기가 긴 기술 자료도 보존할 가치가 있을 수 있습니다.

삭제할 페이지는 삭제 사유와 처리 방법을 요구사항 문서에 기록해야 합니다. 예를 들어 단종 제품에 대체 모델이 있다면 관련 페이지로 연결할 수 있습니다. 대응되는 콘텐츠가 없다면 오류를 없애기 위해 일괄적으로 홈페이지로 리디렉션하는 것은 바람직하지 않습니다. 영업 책임자는 대체 관계를 확인하고, SEO 담당자는 검색에 미칠 영향을 검토하며, 개발 담당자는 이를 구현해야 합니다. 출시 당일이 되어서야 누가 결정할지 논의하는 상황을 방지할 수 있습니다.

마이그레이션 표를 출시 직전의 임시 첨부물이 아니라 인도 산출물로 관리하세요

마이그레이션 표에는 기존 URL, 새 URL, 페이지 유형, 처리 방법, 담당자, 테스트 결과를 각 항목별로 기재하는 것이 좋습니다. 유지할 페이지는 가능한 한 기존 경로를 유지하세요. 경로를 반드시 변경해야 한다면 기존 주소에서 가장 관련성이 높은 새 주소로 301 영구 리디렉션을 설정해 여러 번 리디렉션되지 않도록 하고, 서로 다른 의도를 가진 기존 페이지를 모두 홈페이지로 일괄 연결하지 마세요.

요구사항 문서에는 URL 규칙도 명시해야 합니다. 대소문자, 슬래시, 매개변수, 페이지네이션, 표준 URL을 어떻게 처리할지 정하세요. 리디렉션, 사이트 내부 링크, 표준 태그, 사이트맵은 일관된 대상 주소를 가리켜야 합니다. 영구 삭제되었고 적절한 대체 콘텐츠가 없는 페이지는 404 또는 410 상태 코드를 반환할 수 있습니다. 구체적인 선택은 실제 유지관리 방식에 따라 결정해야 하며, 모든 404를 오류로 간주할 필요는 없습니다.

해외용 웹사이트라면 언어별 페이지도 별도로 확인해야 합니다. 중국어, 영어 또는 기타 언어의 대응 페이지를 각각 매핑해야 하며, 이전 버전의 제품 상세 페이지를 새 사이트의 다른 언어 홈페이지로 일괄 연결해서는 안 됩니다. hreflang을 사용하는 경우 언어 및 지역 코드, 페이지 간 대응 관계, 최종 URL을 확인하세요. 해당 번역 페이지가 없다면 대응 주소를 임의로 만들어서는 안 됩니다. 다국어 경로가 확정되면 번역팀과 개발팀에 전달해 병행 작업을 진행하세요. 재작업을 크게 줄일 수 있습니다.

기술 요구사항은 검증 가능한 작업으로 작성하세요

“검색 엔진에 친화적인 페이지”라는 표현만으로는 검수할 수 없습니다. 요구사항 문서에는 중요한 콘텐츠와 링크에 접근할 수 있는지, 페이지가 올바른 상태 코드를 반환하는지, 페이지별 제목과 설명을 편집할 수 있는지, 표준 태그·구조화 데이터·사이트맵을 누가 생성하는지 명시해야 합니다. 개발 환경에서는 검색 엔진의 접근을 제한하고, 출시 시에는 유지할 필요가 없는 접근 제한, robots 규칙, noindex 태그를 항목별로 제거해야 합니다.

디자인 시안 승인 후에는 실제 페이지도 확인해야 합니다. 제품 사양, 사용 사례, 문의 진입 경로가 이미지에만 포함되어 있다면 사용자가 확인하기 어렵고 콘텐츠 관리도 불편합니다. 스크립트로 불러오는 핵심 콘텐츠는 검색 엔진이 가져올 수 있는지 테스트해야 합니다. 성능 요구사항을 단순히 “빠른 로딩”이라고만 쓰지 말고, 대표 페이지와 테스트 환경을 정한 뒤 출시 전후의 핵심 웹 지표를 기록하고 기준에 미달할 경우 누가 수정할지 명확히 하세요.

리뉴얼 과정에서 중국 본토 내 서버, 도메인 또는 접속 사업자가 변경된다면 ICP 등록 여부 확인도 일정에 포함해야 합니다. 등록, 변경 또는 접속 관련 절차가 필요한지는 웹사이트의 실제 상황과 관할 기관 및 접속 서비스 제공업체의 요구사항을 바탕으로 확인해야 합니다. 영업 목적의 사업은 관련 허가 요건도 별도로 확인해야 합니다. 자료 준비와 확인 절차에 대한 지원이 필요하다면 중국 본토 ICP 등록 서비스 번호를 확인할 수 있습니다. 다만 심사 기간을 고정된 출시 일정으로 단정해서는 안 됩니다.

검수는 두 차례 진행하세요. 출시 전에는 위험을 확인하고, 출시 후에는 실제 신호를 살펴봅니다

출시 전에는 홈페이지, 주요 카테고리, 핵심 제품, 콘텐츠 문서, 각 언어 템플릿을 최소한 표본 검사해야 합니다. 트래픽과 문의가 많은 페이지, 주요 리디렉션은 항목별로 확인해야 합니다. 화면 표시뿐 아니라 상태 코드, 제목, 표준 태그, 내부 링크, 양식 제출, 모바일 사용성도 점검하세요. 테스트 환경에서 통과한 결과가 운영 환경의 재검수를 대신할 수는 없습니다.

출시 후에는 업데이트된 사이트맵을 가능한 한 빨리 제출하고, 중요한 기존 URL이 마이그레이션 표에 따라 리디렉션되는지 확인하세요. 크롤링, 색인 생성, 자연 검색 실적도 지속적으로 살펴봐야 합니다. 요구사항 문서에는 모니터링 기간, 보고 주기, 이상 발생 시 에스컬레이션 절차, 롤백 조건을 미리 정해두는 것이 좋습니다. 예를 들어 핵심 페이지에 접근할 수 없거나 문의 양식이 작동하지 않을 때 누가 게시 중단을 결정하고 누가 복구를 담당하는지 정해야 합니다. 단기적인 순위 및 트래픽 변동을 곧바로 마이그레이션 실패로 간주해서는 안 되지만, 그렇다고 이상 징후를 무시할 이유로 삼아서도 안 됩니다.

마케팅 경로의 검수를 빠뜨리지 마세요. 기존 광고 랜딩 페이지, 소셜 미디어 링크, 이메일 링크, 분석 이벤트가 여전히 이전 주소를 가리킬 수 있습니다. 페이지 리디렉션이 정상적으로 이루어져도 양식의 유입 경로 추적이나 전환 통계가 끊길 수 있습니다. 웹사이트 구축, SEO, 광고 운영을 함께 진행하는 프로젝트라면 이잉바오와 같은 통합 서비스의 협업 방식을 참고해 URL 마이그레이션, 광고 링크, 문의 추적을 하나의 출시 체크리스트에 포함하세요. 트래픽 이상이 발생한 뒤 각각 따로 조사할 필요가 없습니다.

요구사항 문서를 확정하기 전에 개발 책임자, 콘텐츠 책임자, 마케팅 책임자에게 각각 실행 가능 여부, 누락 자료를 보완할 담당자, 지연 시 영향을 받는 작업을 확인받는 것이 좋습니다. 특히 마이그레이션 표와 롤백 계획은 설계 단계에서 충분히 시간을 들여 검토해야 합니다. 도메인을 전환하는 당일에 결정할 일로 남겨두지 마세요.