제작 업체에 사이트 구조 개편을 요청하는 방법

메뉴 그림과 구현할 변경의 구별

실제 병원의 문서 목록과 공개할 안내가 있어야 이 구분을 적용할 수 있습니다. 진료 안내를 통합할지, 다른 문서로 대체할지 또는 그대로 제공할지는 원고의 목적과 실제 정보를 읽고 결정하는 편집 업무입니다. 병원 자료가 없는 상태에서 메뉴 이름이나 문서의 폐지 여부를 임의로 정하지 않습니다. 제작 작업을 의뢰한다고 해서 제공되지 않은 병원 정보를 새 사실로 채울 수 있는 것은 아닙니다.

Google의 사이트 이동 안내는 이전 URL 목록을 만든 뒤 각 주소를 리디렉션할 위치를 정한다고 설명합니다. 매핑을 저장하는 방법은 서버와 이동 방식에 따라 달라 데이터베이스나 일반 패턴의 URL 재작성 규칙을 사용할 수 있다고 안내합니다. 업체에는 실제 환경에서 어떤 방식으로 주소 대응을 구현할 수 있는지 설명을 요청할 수 있습니다. 모든 CMS가 같은 설정 화면이나 같은 수정 권한을 제공한다고 가정하지 않습니다.

업체가 다룰 수 있는 설정 범위

Google은 WordPress, Wix, Blogger 같은 CMS에서 HTML을 직접 수정하지 못할 수도 있다고 설명합니다. 대신 검색엔진에 표준 URL을 알리는 설정 페이지나 다른 메커니즘이 있을 수 있으므로 해당 CMS에서 페이지의 head를 수정하는 안내를 찾도록 합니다. 병원에서 실제 사용하는 플랫폼과 업체의 접근 권한을 바탕으로 어느 설정을 바꿀 수 있는지 요청할 근거입니다.

요청할 변경을 모두 화면 디자인으로 표현하면 주소 대응을 구현하는 작업과 표준 주소를 선언하는 작업의 차이가 드러나지 않을 수 있습니다. Google은 표준 URL을 알리는 여러 방법을 설명하면서 이를 지정하지 않아도 사이트는 정상적으로 작동하고 Google이 적합한 버전을 식별한다고 안내합니다. 화면이 열리는지와 선호 주소를 알리는 구현이 있는지는 다른 조사 조건입니다.

따라서 납품 조건은 실제 요청한 구현을 대상으로 제안합니다. 변경한 메뉴가 정해진 문서로 연결되는지, 이전 주소의 요청이 지정한 새 문서로 이어지는지처럼 직접 조사할 대상을 선정할 수 있습니다. 이를 특정 검색 순위나 실제 병원의 유입 결과와 같은 조건으로 바꾸지 않습니다. 계약 책임, 비용과 작업 일정은 실제 협의 자료에 따라 정할 사항입니다.

변경 요청에 쓰는 실제 주소 대응 양식

대응표에 따라 바꿀 내부 연결과 주석

Google의 이동 안내는 URL 매핑을 정의한 뒤 새 사이트의 내부 링크를 이전 URL에서 새 URL로 변경하도록 설명합니다. 업체에 전달한 대응표는 메뉴의 목적지뿐 아니라 원고 안의 연결을 찾고 갱신하는 데에도 사용할 수 있습니다. 새 문서가 존재하는 상태와 출발 문서의 링크가 그 주소를 가리키는 상태를 다른 구현 항목으로 구분하는 요청입니다.

공식 안내는 각 페이지의 HTML 또는 사이트맵 항목에서 새로운 URL을 가리키도록 주석을 업데이트하고 새 URL마다 자체 참조 표준 링크를 제공하도록 설명합니다. 주소 이동 요청에 페이지가 알리는 주소 정보의 갱신도 포함할 근거입니다. 이전 주소의 이동 처리만 구현했는데 새 페이지의 주석에는 이전 값이 남아 있는지 조사할 수 있습니다.

개발하는 동안 새 사이트의 페이지에 noindex를 적용했다면 이동을 시작할 때 삭제할 규칙을 준비하라는 설명도 있습니다. 공개할 대체 문서의 개발 지시를 어떻게 처리할지는 업체가 다룰 구현 범위에 포함할 수 있습니다. 실제 설정이 제공되지 않은 상태에서 특정 병원의 페이지에 이 지시가 있다고 단정하지 않습니다. 공개 대상과 개발 중 임시 지시의 관계를 조사하는 조건입니다.

영구 이동을 구현하는 요청의 조건

Google은 매핑대로 이전 URL에서 새 URL로 서버 측 영구 리디렉션을 사용하는 방법을 권하며, 서버 관리자나 호스팅 업체에 기술적으로 사용할 수 있는 종류를 문의하도록 안내합니다. 영구 이동에는 301 또는 308을 설명합니다. 병원 제작 업체에 화면의 이동 버튼을 추가하는 일과 기존 URL 요청의 서버 측 이동을 구분해 설명을 요청할 근거입니다.

공식 안내는 리디렉션 체인을 피하고 최종 목적지로 직접 이동하도록 권합니다. 긴 체인이 이용자의 지연 시간을 늘리고 일부 사용자 에이전트나 브라우저에서 지원되지 않을 수 있기 때문입니다. 실제 주소 대응표의 도착지와 구현 경로의 마지막 문서가 같은지 조사할 수 있습니다. 경유 주소가 여러 개라는 사실을 납품 후에야 알게 되는 상황을 줄이는 요청 조건입니다.

관련성이 떨어지는 하나의 목적지로 많은 기존 URL을 보내는 선택도 구별해야 합니다. Google은 홈페이지로 일괄 리디렉션하는 예가 이용자에게 혼란을 주고 soft 404로 처리될 수 있다고 설명합니다. 반면 기존 여러 문서의 내용을 실제로 하나의 문서에 통합했다면 여러 이전 주소를 통합 문서로 보낼 수 있다고 안내합니다. 목적지의 수보다 실제 제공하는 내용의 대응 관계가 다른 판단 조건입니다.

납품 자료에서 실제 구현을 읽는 방법

Google은 리디렉션 테스트에 URL 검사 도구로 개별 URL을 조사하거나 명령줄 도구 또는 스크립트로 여러 URL을 테스트하는 방법을 설명합니다. 업체에는 실제 이전 주소와 도착 주소를 대상으로 어떤 경로를 조사했는지 설명을 요청할 수 있습니다. 요청안의 주소 대응과 공개된 주소의 실제 동작을 대조하는 납품 증거이며, 병원에서 사용하지 않는 도구를 이미 운영하고 있다고 가정하지 않습니다.

새 문서의 표준 주소도 관련 선언 사이에서 일관되게 읽어야 합니다. Google은 같은 페이지에 대해 사이트맵에서 한 URL을 지정하고 표준 링크에서 다른 URL을 지정하는 방식을 피하도록 설명합니다. 업체가 제출한 자료에서 두 선언이 같은 목적지를 알리는지 조사할 수 있습니다. 사이트맵을 제출했다는 보고만으로 페이지 안의 선언까지 모두 일치한다고 판단하지 않는 조건입니다.

표준 링크를 HTML 요소와 HTTP 헤더로 동시에 제공하는 방식은 지원되지만 오류가 발생하기 쉬워 한 가지 방법을 지속적으로 사용하는 것이 권장됩니다. Google은 두 방식에서 다른 URL을 제공하는 경우를 오류의 예로 설명합니다. 실제 구현 방식이 무엇인지 업체에 설명을 요청하고 해당 방식의 선언값을 읽을 수 있습니다. 사용하지 않는 방법까지 병원에 새로 추가해야 한다는 요구는 아닙니다.

소스와 실행 뒤 선언의 구별

Google은 JavaScript로 클라이언트 측 렌더링을 사용하는 경우 HTML 소스에서 표준 URL을 지정하고 JavaScript가 표준 링크 요소를 바꾸지 않도록 하는 방법이 가장 좋다고 설명합니다. HTML 소스에서 설정할 수 없는 경우에는 소스에 표준 URL을 두지 않고 JavaScript로만 설정하도록 안내합니다. 업체의 실제 렌더링 방식에 따라 어느 자료를 읽어야 하는지 구별할 조건입니다.

HTML 표준 링크 요소는 head 안에 포함될 때만 허용되므로 해당 부분이 유효한 HTML인지 조사하라는 안내도 있습니다. 납품 화면에서 문장이 자연스럽게 보이는 것과 페이지의 주소 선언이 이 위치 조건을 충족하는지는 다른 대상입니다. 소스에 특정 낱말이 있는지만 찾기보다 실제 선언의 위치를 업체가 설명할 수 있도록 요청할 근거입니다.

콘텐츠 형식에 따른 표준 선언 적용 범위

이어서 읽을 주제

광고비 없이 검색에 나오는 방법을 콘텐츠 운영에서 알아보려면 블로그 상위노출에서 이어서 읽을 수 있습니다.

사이트맵과 대표 주소의 정리 방법을 알아보려면 사이트맵과 정규 주소에서 이어서 읽을 수 있습니다.