빌더에서 직접 제작으로 바꿀 때 주의할 점

기존 빌더에서 가져올 자료

Google의 사이트 이동 문서는 새 CMS를 설정하고 기존 사이트의 콘텐츠를 가져오는 일을 준비 단계로 설명합니다. 이때 이전과 같은 CMS를 사용하는 것이 좋다는 권고도 있지만, 모든 사이트에서 같은 시스템을 유지해야 한다는 필수 조건은 아닙니다. 빌더를 떠나기로 했다면 그 권고를 이미 충족한 것으로 간주하는 대신, 새로운 시스템에서 보존할 내용과 달라지는 구현을 구체적으로 정할 필요가 있습니다.

본문 텍스트만 이전 대상으로 생각하면 다운로드나 삽입 자원이 빠질 수 있습니다. 공식 안내는 호스팅하는 이미지와 PDF 같은 다운로드를 전송하고 사용자와 Googlebot에게 새 위치를 알리도록 설명합니다. 이미 검색이나 링크를 통한 트래픽이 생기는 자원일 수 있기 때문입니다. 기존 자료의 실체가 없는 상태에서 병원의 파일 수나 유입량을 임의로 계산하지 않습니다.

주소 목록을 얻는 방법도 하나로 고정되지 않습니다. 이동 문서는 CMS에서 목록을 받을 수 있는 경우를 설명하고 기존 사이트맵, 서버 로그, 분석 자료, 내부·외부 링크가 있는 주소도 자료로 제시합니다. 따라서 빌더가 어떤 형식으로 목록을 제공하는지 실제 도움말이나 관리 화면으로 읽어야 합니다. 새 시스템이 자유롭게 구현된다는 사실은 이전 서비스의 자료를 모두 내보낼 수 있다는 뜻과 다릅니다.

소유권을 검증하는 자료는 콘텐츠 파일과 역할이 다릅니다. Search Console의 HTML 파일 방식은 현재 검증 파일을 새 사이트 사본에 포함해야 한다는 안내가 있습니다. 메타태그를 참조하는 include 파일이나 Google 애널리틱스를 이용하는 방법도 새 CMS 사본에 포함하도록 설명합니다. 어느 방식이 실제로 사용되는지에 따라 이관할 항목이 달라지므로 한 종류의 파일만 복사하고 끝낼 수는 없습니다.

새 주소와 자동 출력 검사

새 직접 구현에서 주소 규칙이 달라지는 문서는 기존 URL과 새 URL을 대응시켜야 합니다. Google은 매핑을 정의한 다음 새 주소를 가리키도록 주석과 내부 링크를 갱신하는 단계를 제시합니다. 주소가 그대로인 페이지와 경로가 달라진 페이지를 같은 변경으로 취급하지 않습니다. 실제 URL 대응표를 읽은 뒤 각 페이지가 어디로 이동할지를 정하는 범위입니다.

이동 안내에 따르면 새 URL마다 자신을 참조하는 canonical 태그가 있어야 합니다. 다국어나 다국적 페이지에 hreflang 주석을 사용하고 있었다면 그 주석도 새 URL로 바꾸어야 합니다. 다국어 구성이 없는 병원에 같은 설정을 새로 추가해야 한다고 확대하지 않습니다. 기존 주석이 존재하는지와 새 구현에서 출력하는 값이 무엇인지를 각각 읽어야 합니다.

표준화 문제 안내는 일부 CMS나 플러그인이 표준 요소를 잘못 사용해 외부 웹사이트의 URL을 가리킬 수 있다고 설명합니다. 브라우저 개발자 도구에서 HTML을 읽으면 이 문제가 발생하는지 검사할 수 있습니다. 사용자가 원하는 표준 주소와 다르다면 canonical이나 3xx 리디렉션을 잘못 사용한 경우일 수 있으며, 공식 문서는 해당 CMS 제공업체에 오류를 알리도록 안내합니다.

표준화 안내는 악의적인 공격이 3xx를 반환하는 코드를 사용하거나 HTML의 head 또는 헤더에 교차 도메인 canonical 주석을 넣는 경우도 설명합니다. 이런 주석은 일반적으로 악성·스팸 콘텐츠를 호스팅하는 주소를 가리키며 Google이 공격당한 사이트 대신 그 URL을 선택할 수도 있습니다. 단순한 구성 실수와 구분할 문제 후보이므로 실제 출력의 변경 내용을 읽어야 하며, 낯선 표준 주소 하나만으로 병원이 해킹당했다고 확정하지 않습니다.

호스팅 구성이 잘못된 경우에는 한 도메인의 요청에 다른 도메인의 콘텐츠가 반환될 수 있다는 안내도 있습니다. 관련 없는 두 서버가 Google이 오류 페이지로 식별하지 못한 같은 soft 404를 반환하는 상황도 설명하며 호스팅 업체에 문의하도록 권고합니다. 이 문제는 본문을 가져오는 기능과 별도로 서버가 어떤 요청에 어떤 자료를 반환하는지의 문제입니다.

표준화 문제를 보려면 먼저 URL 검사 도구로 Google이 표준으로 간주하는 페이지를 읽을 수 있습니다. 명확한 표준 페이지를 지정했어도 품질이나 기술 신호 등 여러 이유로 다른 페이지가 선택될 수 있다는 설명이 있습니다. 내가 소유하지 않은 Search Console 속성에 표준 URL이 있으면 중복 페이지 관련 트래픽을 볼 수 없다는 한계도 함께 읽어야 합니다.

변경을 나누고 공개 조건 준비

Google의 이동 지침은 도메인, CMS, 레이아웃을 한 번에 모두 바꾸기보다 하나씩 처리하도록 권고합니다. 새 도메인으로 옮긴 다음 레이아웃을 바꾸는 순서를 예로 제시합니다. 빌더에서 직접 제작으로 전환할 때에도 실제 계획에서 주소·시스템·화면 중 무엇이 바뀌는지 구별할 수 있습니다. 어떤 병원에 얼마의 추가 기간이 필요하다는 계산으로 이 권고를 바꾸지 않습니다.

규모가 큰 사이트라면 기술적으로 가능한 경우 일부만 먼저 옮겨 검색 색인과 트래픽에 미치는 영향을 시험한 뒤 나머지를 옮기는 방법이 안내됩니다. 중소형 사이트는 모든 URL을 한꺼번에 옮기는 것이 좋다는 설명도 있으므로 단계적 이전이 어느 규모에서나 유일한 방식은 아닙니다. 전환 방법은 실제 사이트의 규모와 부분 이전 가능성에 맞추어 검토할 대상입니다.

새 시스템을 개발하는 동안 수집을 막아 두는 구성도 공개 전에 다룰 일입니다. 이동 문서는 개발 중 모든 크롤링을 차단했다면 이동 시작 후 robots 파일을 어떻게 바꿀지 준비하도록 설명합니다. noindex를 사용했다면 공개할 때 그 규칙을 삭제할 URL 목록을 준비해야 합니다. 접근을 막는 설정과 색인 제외 지시가 같은 항목이라고 보고 한쪽만 바꾸지 않습니다.

HTTPS로 이전한다면 필수 TLS 인증서를 받아 서버에 설정하는 과정이 안내됩니다. Search Console에서는 이전·새 사이트와 www 유무, HTTP·HTTPS 같은 변형도 검증 대상으로 설명합니다. 주소 변경 시 사용하는 방법에 따라 검증 토큰이 달라질 수 있다는 조건이 있으므로 새 주소의 결과를 기존 속성의 기록으로 대신하지 않습니다.

이전 후에는 사용자와 Googlebot의 접근이 늘어 서버가 이를 감당할 자원도 필요할 수 있습니다. 특히 사이트 이동이 리디렉션을 통한 새 사이트 수집과 함께 진행된다는 공식 설명이 있습니다. 직접 구현의 자유도를 선택한 일과 서버의 실제 처리 능력이 충분하다는 판단은 다른 문제이므로, 현재 응답과 오류 자료를 읽기 전에는 용량이 충분하다고 단정하지 않습니다.

이동 전략은 기존 주소를 새 목적지로 직접 연결하는 방향으로 준비할 수 있습니다. 공식 문서는 매핑에 따른 서버 측 영구 리디렉션을 권고하고 기술적으로 어떤 종류를 사용할 수 있는지 서버 관리자나 호스팅 업체에 문의하도록 안내합니다. 빌더에서 쓰던 기능 이름이 새 시스템에도 그대로 있다는 전제 대신, 새 구현이 제공하는 실제 이동 처리를 검토해야 합니다.

이어서 읽을 주제

이름이나 이미지를 바꾸는 결정은 다음 주제로 이어집니다.

병원 리브랜딩

위치나 이름이 바뀌는 상황은 별도 질문으로 읽을 수 있습니다.

병원 이전 명칭 변경