시작 전 권한과 대상 범위
병원 홈페이지 소유권 인증에는 Google 계정 접근권한과 선택한 방식의 요구 권한이 필요합니다. 파일·태그·DNS를 새로 반영한다면 수정 권한이나 작업 요청 경로도 확보합니다. 인증할 사이트·호스트 범위도 분명해야 합니다. 외부업체 개인 계정만 소유자로 등록되어 있다면 병원 관리 계정으로 소유권을 증명할 수 있는 경로도 마련해야 합니다.
Search Console 접근권한과 홈페이지 수정 권한은 서로 다릅니다. 검색 데이터를 읽을 수 있어도 서버에 파일을 올리거나 홈페이지 HTML을 수정할 수 있다는 뜻은 아닙니다. 반대로 사이트를 편집하는 업체가 병원의 Search Console 속성까지 관리할 권한을 가진다고 단정할 수도 없습니다.
먼저 병원 담당자가 사용할 계정과 실제 변경을 실행할 담당자를 연결합니다. 병원이 직접 수정하지 않는 구조라면 업체의 작업 가능 범위, 요청 절차, 인증 자료의 유지 책임을 함께 정합니다.
병원 관리 계정의 사용은 운영상 제안입니다. Google이 병원 명의 계정을 별도로 요구한다는 뜻은 아닙니다. 담당자 퇴사나 업체 계약 종료 뒤에도 병원이 계정 접근을 이어갈 수 있도록 계정 관리 책임과 인수 방법을 정하는 데 목적이 있습니다.
사이트와 호스트의 적용 범위
권한 요청서에는 인증할 속성의 종류와 주소 범위를 먼저 기록합니다. 도메인 속성은 모든 프로토콜과 하위 도메인 변형을 포함하며 DNS 방식이 필요합니다. URL 접두사 속성을 대상으로 한다면 파일이나 태그 등 해당 속성에서 지원하는 방식을 선택할 수 있습니다.
대표 홈페이지와 별도 하위 도메인이 있는 경우에는 병원이 관리하려는 범위와 실제로 수정할 수 있는 범위를 구분합니다. 루트 도메인을 DNS로 인증하면 하위 도메인도 포함되지만, 하위 도메인 인증만으로 상위 도메인의 소유권까지 증명되지는 않습니다.
홈페이지 운영업체와 도메인 관리업체가 다를 수도 있습니다. 사이트 제작 관리자만 확보한 상태에서 도메인 속성을 신청하면 DNS 작업 단계에서 멈출 수 있습니다. 속성 종류를 정한 뒤 필요한 관리 서비스와 담당자에게 접근권한을 요청하는 순서가 적절합니다.
인증할 대상과 병원이 관리하는 대상을 문서에 연결하면 업체가 다른 호스트에 작업하는 혼선을 줄일 수 있습니다. 대표 주소라는 설명만 전달하기보다 프로토콜, 호스트, 필요한 경로 범위를 구체적으로 기록하는 편이 안전합니다.
인증 방식별 접근권한
방식은 병원이 확보할 수 있는 권한을 기준으로 정합니다. 표의 관리 항목은 병원 운영 제안이며, 접근권한과 설치 조건은 Search Console 도움말의 요구사항입니다.
| 방식 | 필요한 접근·수정 권한 | 병원 측 관리 항목 |
|---|---|---|
| HTML 파일 | 지정된 루트 위치에 파일을 업로드하고 게시할 권한 | 파일을 발급받은 Google 계정과 서버 작업 담당자 |
| HTML 태그 | 실제 홈페이지 HTML의 head 영역을 수정할 권한 | 태그 발급 계정과 템플릿 변경 담당자 |
| DNS 레코드 | 도메인 관리 페이지 접근 및 필요한 DNS 레코드 추가 권한 | 도메인 관리 계정과 레코드 유지 담당자 |
| Google 애널리틱스 | 사이트에 사용된 애널리틱스 계정의 수정 권한 | 동일한 Google 계정 사용과 추적 코드 유지 책임 |
| Google 태그 관리자 | 사이트에 사용된 컨테이너의 게시 또는 관리자 권한 | 동일한 Google 계정 사용과 스니펫 유지 책임 |
파일 방식은 URL 접두사 속성용입니다. 지정된 루트 위치의 파일이 로그인 없이 열려야 하며, 발급된 이름과 내용을 그대로 유지해야 합니다. 업로드 권한만으로 이 조건이 충족되지는 않습니다.
태그 방식도 URL 접두사 속성용입니다. 공개 홈페이지의 head 영역에 개인별 인증 태그를 넣고 실제 게시 페이지에 반영해야 합니다. 태그는 HTML 파일의 2MB 미만 범위에 포함되어야 하며, 스크립트 등 외부 리소스는 크기 계산에서 제외됩니다.
DNS 방식은 도메인 관리 페이지 로그인과 레코드 추가 권한이 필요합니다. 직접 입력할 때는 Search Console 발급값과 공급업체 안내를 따릅니다. 사이트 편집 권한이 DNS 변경 권한까지 포함하지는 않습니다.
기존 분석 도구 이용 조건
애널리틱스 코드가 설치되어 있어도 보고서 열람 권한만으로는 인증할 수 없습니다. 사이트에서 사용하는 애널리틱스 계정의 수정 권한이 필요하며, 해당 도구와 Search Console에서 동일한 Google 계정을 사용해야 합니다.
로그인하지 않은 홈페이지의 head 영역에 analytics.js 또는 gtag.js 스니펫이 원형대로 있어야 합니다. URL 접두사 속성에만 사용할 수 있고 코드는 HTML 파일의 2MB 미만 범위에 포함되어야 합니다. 스크립트 등 외부 리소스는 크기 계산에서 제외됩니다.
태그 관리자는 해당 컨테이너의 게시 또는 관리자 권한이 필요합니다. 동일한 Google 계정으로 Search Console을 사용하며, 로그인 없이 열리는 홈페이지에 올바른 스니펫이 있어야 합니다. 컨테이너 열람 권한만으로는 부족합니다.
태그 관리자 코드도 원형을 유지하고 HTML 파일의 2MB 미만 범위에 포함되어야 합니다. 외부 리소스는 크기 계산에서 제외됩니다. noscript 부분은 body 시작 직후에 배치하며, 그 사이에는 HTML 주석 이외의 항목이 없어야 합니다. 도메인 속성에는 사용할 수 없습니다.
설치 위치를 수정할 권한이 없다면 다른 방식을 선택합니다. 권한 확대 전에는 파일·태그·DNS 작업 가능성과 비교합니다.
외부업체에 요청할 권한과 책임
외부업체 개인 계정만 인증된 소유자라면 병원이 사용할 Google 계정과 인증 작업의 실행 주체부터 정합니다. 직접 인증할 수 없는 동안에는 현재 소유자에게 속성 접근권한을 요청할 수 있지만, 이 권한만으로 사이트나 DNS를 수정할 수 있는 것은 아닙니다.
권한 요청은 서비스별 담당자에게 전달합니다. Search Console은 현재 소유자, 파일과 HTML은 사이트 운영 담당자, DNS는 도메인 관리 담당자가 요청 대상입니다. 같은 업체가 맡더라도 각 작업을 실행할 계정과 권한 수준을 구분하는 편이 명확합니다.
업체에는 로그인 가능 여부보다 필요한 작업의 실행 가능 여부를 묻습니다. 파일 게시 위치, 홈페이지 head 편집, DNS 항목 추가 중 선택한 방식에 필요한 항목을 지정하고 병원 계정에서 발급한 인증 자료를 반영할 수 있는지 답변을 받습니다.
병원 계정의 토큰을 추가할 때는 다른 소유자의 토큰을 덮어쓰지 않아야 합니다. 이전 소유자 토큰을 제거하는 인수 작업은 병원 계정의 소유권 증명이 선행되어야 합니다. 삭제 절차를 시작하기 전에 새 토큰을 추가할 권한부터 확보합니다.
직접 수정 권한을 받기 어렵다면 업체의 작업 담당자, 요청 창구, 게시 결과 전달 방법을 문서화합니다. 이는 병원이 인증 자료의 반영과 변경을 요청할 경로를 확보하기 위한 운영 제안입니다.
권한 인수 기록과 실행 책임
토큰이 계속 존재하고 유효해야 인증이 유지되므로, 시작 전부터 이를 수정하는 서비스와 담당자를 연결합니다. 아래 기록 항목은 병원이 확보한 권한과 업체가 실행할 작업을 구분하기 위한 운영 제안입니다.
| 인수 기록 | 남길 내용 | 다음 행동 |
|---|---|---|
| 속성 범위 | 속성 종류와 관리 대상 호스트·경로 | 요청한 범위와 등록 대상을 비교 |
| 계정 책임 | 병원 관리 계정과 권한 부여 담당자 | 병원 담당자의 실제 접근 가능 여부 확인 |
| 작업 권한 | 파일 게시, HTML 편집 또는 DNS 추가 범위 | 선택한 방식의 작업 가능 여부 회신 요청 |
| 실행 책임 | 직접 수정할 담당자와 업체 요청 창구 | 직접 접근이 어려운 항목의 실행 주체 지정 |
| 인수 결과 | 부여받은 권한과 아직 업체가 맡는 작업 | 미확보 항목의 처리 담당자 연결 |
권한을 받았다는 답변과 필요한 작업을 실행할 수 있다는 답변은 구분합니다. 파일을 저장해도 외부에 게시할 수 없거나 편집 화면에서 head 영역을 수정할 수 없다면 선택한 방식에 필요한 권한이 확보된 것은 아닙니다.
인증 자료의 유지 책임도 작업 권한과 함께 기록합니다. 병원이 직접 관리하는 항목인지, 업체에 보존을 요청해야 하는 항목인지 구분하고 개편·이전·계약 종료 때 요청을 받을 담당자를 정합니다. 권한 인수에서 빠진 서비스를 찾는 데 목적이 있습니다.
자주 묻는 질문
업체가 비밀번호 공유만 제안하면 어떻게 하나요?
서비스가 지원하는 계정별 권한 부여 방법을 먼저 파악합니다. 직접 권한을 받기 어렵다면 업체가 실행할 작업과 병원의 요청 창구를 문서화하는 방식도 가능합니다. 운영 기록에는 공유 로그인 여부만 남기기보다 권한 회수 담당자와 계정 접근을 인수할 절차를 함께 기재하는 편이 좋습니다.
빌더의 인증 플러그인은 바로 설치해도 되나요?
플랫폼 도움말에서 지원 기능을 먼저 찾고, 플러그인을 설치할 권한과 그 과정에서 필요한 계정 접근을 구분합니다. Google 도움말에서 공식 지원 대상으로 명시한 플러그인은 Site Kit뿐입니다. 다른 플러그인은 설치 전 관련 정보를 조사하고, 업체에는 설치 대상과 필요한 권한의 설명을 요청합니다.
홈페이지가 다른 경로로 이동하면 어떻게 하나요?
태그 방식에서는 로그인하지 않은 방문자가 속성 주소에서 이동한 최종 페이지가 대상입니다. 편집 권한도 그 페이지의 HTML에 적용되어야 합니다. 파일 방식에 같은 조건을 그대로 적용하지 말고 인증 화면이 지정한 파일 위치를 기준으로 게시 권한을 확보합니다.
DNS에 TXT만 추가할 수 있어도 충분한가요?
원문은 사이트 구성에 따라 TXT 또는 CNAME을 사용하도록 안내합니다. CNAME이 있고 대상 값이 입력한 도메인의 상위 도메인이라면 CNAME 안내를 따라야 합니다. TXT 추가 권한만 요청하기 전에 사용할 레코드 유형을 정하고, 필요한 이름과 값을 입력할 권한이 있는지 담당자에게 묻습니다.
게시 권한을 받았다는 답변에는 무엇을 남기나요?
운영 제안으로, 권한이 적용되는 서비스·사이트 범위와 실제 게시 담당자를 기록합니다. 로컬 파일 수정만 가능한지, 공개 페이지에 반영할 수 있는지도 구분합니다. 병원이 직접 실행하지 않는 작업은 요청 접수 담당자와 반영 결과를 전달받을 방법까지 합의하면 권한 인수의 미완료 항목을 구별할 수 있습니다.