단계별 완료 조건과 일정 구분
리뉴얼 일정에는 시안 단계의 보존 문서 결정, 개발 단계의 URL 매핑, 공개 전 새 사이트 시험, 공개 시 리디렉션 적용, 공개 후 URL별 관찰을 순서대로 넣습니다. 각 단계는 날짜와 함께 완료 조건을 정하고, 구현 완료일과 검색 색인 진행을 분리해 관리합니다. 검색 안정화 날짜를 프로젝트 납기와 같게 약속해서는 안 됩니다.
먼저 이번 리뉴얼에서 주소가 바뀌는지 구분합니다. 도메인이나 페이지 경로가 달라지면 기존 주소와 새 주소의 대응 관계가 필요합니다. URL을 유지한 채 호스팅이나 CDN만 바꾸는 작업은 URL 변경 없는 이전에 해당합니다. 디자인 변경만으로 모든 프로젝트에 주소 변경 알림 도구를 배정할 이유는 없습니다.
일정표의 완료 조건은 작업자가 제출할 결과와 다음 단계로 넘어갈 기준을 함께 담아야 합니다. 예를 들어 시안 승인만으로 개발을 시작하기보다 보존할 페이지와 삭제할 페이지의 처리가 정해졌는지 판단합니다. 이러한 일정 운영 방식은 병원 홈페이지 업무에 적용하는 제안이며, Google이 정한 계약 납기나 인력 배치 의무는 아닙니다.
시안 단계의 보존 범위
시안에서는 새 메뉴 구성과 함께 기존 콘텐츠의 유지·통합·삭제 범위를 결정합니다. 검색 유입이나 외부 링크가 있는 페이지가 새 구조에서 빠지는지, 이미지와 PDF 같은 다운로드 자료가 이동 대상인지도 포함합니다. 실제 유입 자료가 없다면 중요도를 임의로 수치화하지 않고, 확보할 자료와 결정이 필요한 항목을 구분합니다.
페이지를 통합한다면 기존 내용에 대응하는 새 페이지가 무엇인지 정합니다. 관련 없는 여러 주소를 새 홈페이지 하나로 보내는 방식은 사용자에게 혼란을 주고 soft 404로 처리될 수 있습니다. 반면 여러 페이지의 콘텐츠를 실제로 한 페이지에 통합했다면 그 통합 페이지로 연결할 수 있습니다. 대체 콘텐츠 없이 삭제하는 URL은 404 또는 410 응답 대상으로 분류합니다.
단계별 선행 자료와 완료 기준
| 단계 | 선행 자료 | 완료 조건 |
|---|---|---|
| 시안 | 기존 문서·메뉴 목록 | 유지·통합·삭제 범위 결정 |
| 개발 | 확정 구조와 URL 목록 | 새 주소 대응과 예외 처리 구현 |
| 공개 전 | 새 사이트와 시험 결과 | 이동 경로·색인 허용 설정 시험 완료 |
| 공개 | 확정 매핑과 전환 순서 | 리디렉션 적용과 새 사이트맵 제출 |
| 관찰 | 옛·새 속성과 로그 | URL별 오류와 색인 진행 기록 |
각 행에는 담당 업무와 미완료 항목도 연결합니다. 앞 단계의 결과가 바뀌면 영향을 받는 다음 작업을 다시 배정합니다. 특히 시안 승인 이후 주소 체계가 달라졌다면 개발 완료 표시를 그대로 유지하지 않고 매핑과 시험 범위를 갱신해야 합니다.
개발 단계의 주소 매핑
개발 일정에는 URL 매핑을 별도 항목으로 넣습니다. 복잡한 이전은 사이트맵, CMS 목록, 서버 로그, 분석 자료와 링크 정보로 기존 주소를 모읍니다. 계절별 방문 차이가 있으므로 짧은 기간의 유입만으로 보존 대상을 제외하지 않습니다.
매핑에는 이동하는 이미지·동영상·JavaScript·CSS와 다운로드 주소도 포함합니다. 콘텐츠의 대응 관계에 따라 목적지를 정하고 유지·리디렉션·삭제 응답 대상을 구분합니다. 도메인만 변경되고 경로가 동일한 단순 이전은 개별 목록 없이 일반 리디렉션 규칙을 사용할 수도 있습니다.
내부 링크는 새 URL을 직접 가리키도록 변경하고, 각 새 URL에는 자체 참조 canonical을 설정합니다. 다국어 페이지에 hreflang을 사용한다면 해당 주소도 갱신합니다. 개발 완료 조건에는 사이트맵과 페이지 설정이 확정된 매핑을 반영했는지도 포함합니다.
공개 전 시험과 차단 해제 준비
공개 전에는 기존 주소가 의도한 새 페이지에 도착하는지, 목적지가 존재하는지, 삭제 대상이 올바른 오류 응답을 반환하는지 시험합니다. 가능하면 서버 측 영구 리디렉션을 사용하고, 중간 주소를 여러 번 거치기보다 최종 페이지로 직접 연결합니다.
개발 중 크롤링을 막았다면 공개 시 변경할 robots.txt 규칙을 정합니다. 임시 noindex를 사용했다면 이를 제거할 공개 대상 URL 목록을 준비합니다. 검색에 공개할 콘텐츠와 계속 제한할 콘텐츠를 구분하며, 화면이 열리는 것만으로 검색 접근 조건이 충족됐다고 판단하지 않습니다.
Search Console 소유권 인증이 전환 후에도 유지되도록 사용 중인 인증 방식을 새 CMS나 사이트 사본에 반영하고 시험합니다. 분석 설정과 서버 용량도 준비합니다. 이전 주소의 크롤링이 새 사이트로 이어져 요청량이 일시적으로 늘어날 수 있기 때문입니다.
겹치는 변경의 순서와 기록
Google은 도메인 이전, CMS 변경, 레이아웃 변경을 하나씩 처리하도록 권장합니다. 새 위치에서도 기존 구조를 유지하면 신호 전달에 도움이 됩니다. 콘텐츠와 URL 구조를 이전과 함께 재설계하면 개별 페이지를 다시 학습하고 평가해야 할 수 있어 일부 트래픽 손실 가능성이 있습니다.
변경이 겹친다면 주소 전환, 콘텐츠 통합, 메뉴 개편, CMS 교체의 적용 시점과 대상 URL을 각각 기록합니다. 동시 변경을 권장하는 조치가 아니라 원인 추적을 위한 운영 제안입니다. 기록만으로 유입 변화의 원인을 확정할 수는 없으므로 URL 상태와 로그도 비교합니다.
공개 시 전환 순서
공개 시에는 확정된 매핑에 따라 리디렉션을 적용하고 새 주소의 canonical과 색인 허용 설정을 시험합니다. 이어 새 URL의 사이트맵을 Search Console에 제출합니다. 제출은 주소 발견을 돕지만 모든 페이지의 색인 완료를 뜻하지는 않습니다.
가능하면 반복적으로 트래픽이 적은 때에 공개합니다. 영향을 받는 사용자 수를 줄이고 서버 자원을 확보하는 데 도움이 될 수 있다는 권장사항입니다. 모든 병원에 동일한 요일이나 시간을 적용하지 않고 실제 방문 패턴과 서버 운영 조건에 따라 전환 시간을 정합니다.
주소 변경 알림의 적용 조건
| 변경 유형 | 도구 적용 | 일정에 넣을 조건 |
|---|---|---|
| 다른 도메인·하위 도메인으로 이동 | 사용 대상 | 이전과 리디렉션 후 요청 |
| HTTP에서 HTTPS로 변경 | 사용하지 않음 | URL 변경 이전 절차 적용 |
| 동일 도메인의 경로 변경 | 사용하지 않음 | 리디렉션과 필요한 사이트맵 갱신 |
| 동일 도메인의 www 전환 | 사용하지 않음 | 표준 태그 지정 또는 리디렉션 |
| URL 변경 없는 호스팅·CDN 변경 | 사용하지 않음 | URL 변경 없는 이전 절차 적용 |
주소 변경 알림 도구는 사전 이전 작업 후 사용합니다. 동일한 Google 계정이 양쪽 속성의 소유자여야 하며, 요청을 시작하는 속성은 경로 수준이 아닌 도메인 수준이어야 합니다. 중요한 사전 이동 시험에 실패하면 문제를 수정해야 요청을 계속할 수 있습니다.
한 도메인의 요청이 모든 하위 도메인을 자동으로 옮기지는 않습니다. 도메인 이전에서는 사용하지 않는 변형도 포함해 이전 도메인의 www 및 하위 도메인 변형을 모두 인증하고 각각 요청합니다. 여러 사이트를 통합한다면 한 사이트씩 옮기고 트래픽이 안정화된 뒤 다음 사이트를 이동합니다.
공개 후 관찰과 후속 작업
관찰 단계에서는 이전·새 사이트의 Search Console 데이터와 서버 로그를 비교합니다. URL별로 리디렉션 목적지, 예상 밖 오류 응답, 크롤링 차단, 색인 진행을 구분해 기록합니다. 전체 방문량만으로는 일부 페이지의 잘못된 연결을 놓칠 수 있으므로 이상이 있는 URL부터 조사합니다.
Google의 이전 처리는 URL별로 이루어지며 정해진 크롤링 빈도는 없습니다. 중간 규모 사이트도 새 URL이 점진적으로 표시되는 데 몇 주 이상 걸릴 수 있고, 대형 사이트는 더 오래 걸릴 수 있습니다. 처리 속도는 URL 수와 서버 속도 등에 따라 달라지므로 개별 사이트의 회복 기한이나 순위를 보장하지 않습니다.
구현 기록에는 전환 설정과 시험 결과를, 관찰 기록에는 남은 오류와 색인 변화를 담습니다. Google 안내상 이동 완료로 간주하려면 Googlebot이 이전·새 사이트의 모든 URL을 한 번 이상 방문해야 합니다. 리디렉션은 일반적으로 최소 1년 유지하도록 권고되며, 주소 변경 도구의 180일 작동 기간이 리디렉션 종료일을 뜻하지는 않습니다.
자주 묻는 질문
SEO 작업은 시안 승인 뒤에 시작하나요?
보존할 문서와 주소 변경 범위는 시안 단계부터 정하는 편이 좋습니다. 승인 뒤 기존 페이지의 통합·삭제 처리가 바뀌면 URL 매핑과 개발 범위도 달라집니다. 시안 완료 조건에 콘텐츠 처리 결정을 포함하고, 미결정 항목은 다음 단계의 선행 과제로 연결합니다.
개발 완료일을 색인 완료일로 잡아도 되나요?
두 날짜는 분리해야 합니다. 개발 완료는 구현과 시험 결과로 판단할 수 있지만, Google의 크롤링과 색인 처리는 URL별로 진행되며 고정된 완료 기한이 없습니다. 납기에는 구현 완료 조건을 명시하고, 공개 이후의 오류 대응과 색인 관찰을 별도 작업으로 배정합니다.
주소 변경 알림은 공개 전에 제출하나요?
사이트를 이전하고 리디렉션한 후 사용합니다. 대상은 다른 도메인이나 하위 도메인으로의 이동이며, 동일 계정의 양쪽 속성 소유권과 도메인 수준 속성 등의 요건이 필요합니다. 공개 전에는 요건을 준비하고, 공개 뒤 중요한 사전 이동 시험을 통과한 후 요청합니다.
여러 사이트의 통합 날짜를 같게 잡나요?
주소 변경 알림을 사용하는 여러 사이트의 통합은 한꺼번에 진행하지 않는 것이 권장됩니다. 한 사이트를 새 위치로 옮긴 뒤 트래픽이 안정화될 때까지 기다렸다가 다음 사이트를 이동합니다. 일괄 공개 날짜보다 사이트별 전환 순서와 다음 이전을 시작할 판단 조건을 정합니다.
소규모 사이트도 일부만 먼저 옮기나요?
Google은 중소형 사이트의 모든 URL을 동시에 이동하는 방식을 권장합니다. 대형 사이트는 기술적으로 가능하다면 일부를 먼저 옮겨 영향을 시험할 수 있습니다. 다만 일부 구간의 결과가 전체 이전을 대표하지는 않습니다. 사이트 규모와 구현 조건에 맞춰 공개 범위를 결정합니다.