직접 제작 사이트를 빌더로 옮길 때의 주의 사항

기존 설정의 목록과 이전 범위

직접 제작 사이트는 개발자가 서버 설정, 템플릿, 별도 파일로 처리한 항목이 많아 담당자 손에 목록이 없는 경우가 흔합니다. 구글의 사이트 이동 안내는 옛 URL을 모으는 방법으로 사이트맵, 서버 로그나 분석 소프트웨어의 상위 방문 URL, 서치 콘솔의 사이트로 연결되는 링크 기능, 콘텐츠 관리 시스템의 URL 목록을 듭니다. 같은 안내는 이미지·동영상·JavaScript·CSS 파일의 URL도 이동 계획에 포함하라고 설명합니다. 다만 병원은 진료 안내, 의료진 소개, 예약 안내처럼 문의로 이어지는 페이지를 따로 표시해 이전 범위의 우선순위를 정하는 편이 업무에 맞습니다.

새 도구의 구현 가능성

빌더마다 주소 규칙, 이동 규칙, 문서별 지시 지정 방식이 다르므로 같은 이름의 기능이 있다고 같은 방식으로 동작한다고 단정할 수 없습니다. 관리 화면에서 직접 지정되는 항목, 공식 자료에는 있으나 시험이 필요한 항목, 어디에서도 근거를 찾지 못한 항목으로 구분해 두면 이전 범위를 정하기 쉽습니다. 근거를 찾지 못한 항목은 지원된다고 가정하지 말고 대체 작업의 대상으로 올립니다.

구글의 표준화 문제 해결 안내는 일부 콘텐츠 관리 시스템이나 플러그인이 표준 요소를 잘못 사용해 외부 웹사이트의 URL을 가리키는 경우가 있다고 설명합니다. 이 안내는 브라우저 개발자 도구에서 HTML을 확인하라고 하며, 표준 URL 환경설정이 예상과 다르면 canonical이나 3xx 이동을 잘못 사용한 것일 수 있으니 제공업체에 오류를 신고하라고 합니다. 다만 병원은 빌더가 이 설명의 CMS와 같은 제품이라고 단정하지 말고, 빌더가 자동으로 출력하는 canonical도 같은 방법으로 검수 조건에 넣어야 합니다.

구글의 사이트 이동 안내는 새 URL마다 자체 참조 rel=canonical 링크 태그가 있어야 한다고 설명합니다. 그러므로 빌더가 자동으로 만드는 canonical은 문서마다 자기 자신의 새 주소를 가리키는지가 기준입니다. 담당자는 대표 문서 몇 개를 골라 페이지 소스를 열고, 관리 화면의 주소와 canonical 값을 나란히 놓고 대조합니다. 값이 다르면 빌더의 주소 설정이나 추가 기능부터 따지고, 해결되지 않으면 제공업체에 알립니다.

주소 규칙의 차이와 이동 순서

빌더는 주소를 자동으로 만들거나 정해진 폴더 구조를 요구하는 경우가 있어, 옛 주소를 그대로 유지할 수 있는지부터 시험해야 합니다. 시험 페이지를 몇 개 만들어 폴더 깊이, 파일 확장자, 끝의 슬래시, 한글 주소 처리가 옛 주소와 같은지 대조합니다. 주소를 유지할 수 없으면 구글 안내대로 이전 URL마다 새 URL을 정하는 매핑이 필요하며, 매핑은 데이터베이스나 URL 재작성 규칙 같은 형태로 저장합니다.

실행 순서는 다음과 같습니다.

1. 담당자가 옛 URL 목록과 방문이 많은 주소, 외부 연결이 있는 주소를 한 문서에 모읍니다.
2. 시험 페이지로 빌더가 만드는 새 주소를 파악하고 옛 주소와 짝을 짓습니다.
3. 서버 측 영구 이동을 쓸 수 있는지 호스팅 업체나 서버 관리자에게 묻습니다.
4. 새 문서마다 자신을 가리키는 canonical, 공개 지시, 내부 링크를 새 주소로 맞춥니다.
5. 새 주소를 담은 사이트맵과 옛 주소 목록을 따로 보관합니다.

구글 안내는 중소형 사이트라면 모든 URL을 한 번에 이동하는 편이 좋다고 설명합니다. 다만 병원은 빌더에서 구현되지 않는 항목이 있으면 그 항목의 대체 작업을 먼저 정한 뒤 이동 시점을 정해야 합니다. 이동을 마친 뒤 쓸 목록도 미리 정해 둡니다. 구글 안내는 최종 이동을 위해 새 URL을 담은 사이트맵 파일과 이전 URL로 연결되는 사이트 목록을 저장하라고 설명하며, 후자는 서치 콘솔의 사이트로 연결되는 링크에서 볼 수 있습니다. 담당자가 이 목록을 보관하면 이동 뒤에 빠진 연결을 찾기 쉽습니다.

리소스와 메타 정보 이관

아래 표는 이전 전에 항목별로 채우는 대조표입니다. '새 도구 지원' 칸에는 제품 공식 자료나 관리 화면에서 확인한 내용만 기재하고, 확인하지 못했으면 미확인으로 남깁니다.

리소스는 페이지 안에 삽입된 이미지, 스타일 파일, 스크립트, 내려받는 문서를 가리킵니다. 빌더에 업로드하면 파일 주소가 달라지는 일이 많아, 옛 주소가 다른 문서의 링크나 외부 사이트에 남아 있으면 누락이 생깁니다. 구글 안내는 이런 삽입 콘텐츠의 URL도 다른 콘텐츠와 같은 방법으로 이동해야 한다고 설명합니다. 제목과 설명 문구는 직접 제작 때 템플릿에서 관리했을 가능성이 크므로, 담당자가 원본을 문서별로 내려받아 빌더에 다시 입력합니다.

공개 전에 자주 틀리는 경우

빌더로 이전한 사이트에서 검색 설정이 어긋나는 경우는 대개 시험 환경과 공개 환경의 차이, 또는 화면과 응답의 차이에서 생깁니다. 담당자가 공개 전에 아래 경우를 실제 응답으로 대조합니다.

1. 시험용 주소가 canonical에 남은 경우입니다. 빌더가 시험 도메인을 기준으로 주소를 만들었다면 공개 주소로 변경한 뒤에도 일부 문서에 남을 수 있으므로, 페이지 소스의 canonical 값이 해당 문서의 새 주소인지 읽습니다.
2. 이동은 되지만 목적지가 맞지 않는 경우입니다. 정상 응답이 나와도 도착 문서가 새 홈이거나 내용이 비어 있으면 옛 문서를 대신하지 못하므로, 옛 URL마다 최종 도착한 내용을 읽습니다.
3. 화면은 정상인데 공개 지시가 어긋난 경우입니다. 시험 기간에 색인을 막은 설정이 공개 뒤에도 남을 수 있어 페이지 소스, 응답 헤더, robots 파일을 함께 읽습니다.
4. 리소스가 옛 주소로 남은 경우입니다. 새 문서 안의 이미지나 스타일 파일이 옛 서버를 가리키면 옛 서버를 종료할 때 화면이 깨집니다.

구글의 표준화 안내는 URL 검사 도구로 구글이 표준으로 간주하는 페이지를 확인하라고 설명합니다. 병원은 공개 직후 방문이 많은 주소부터 표본을 정해 검사하고, 어느 주소에서 무엇을 읽었는지 기록으로 남깁니다.

이전 범위를 줄이는 판단 기준

구현할 수 없는 항목이 모든 페이지에 걸린 규칙이면 이전 범위를 줄이기보다 빌더 선택을 다시 검토하는 편이 안전합니다. 옛 URL 이동 규칙이 대표적입니다. 반대로 특정 페이지의 공개 지시를 지정하지 못하는 것처럼 문서 단위 항목이라면 그 페이지만 이전을 보류하고 옛 문서를 유지할 수 있습니다. 구글 안내는 중소형 사이트에 모든 URL의 동시 이동을 권하므로, 보류 페이지가 늘어 이동이 여러 시기로 흩어지지 않게 목록 크기를 관리합니다.

관련 주제

관련 안내를 이어 읽으려면: 병원 리브랜딩.