구글 검색 결과의 병원명이 다르게 나오면 무엇을 확인해야 하나요?
한눈에 보는 답
검색 결과에서 URL 위에 보이는 사이트 이름과 파란 제목 링크를 먼저 구분해요. 사이트 이름이 다르면 도메인 루트 홈페이지의 WebSite 구조화 데이터, og:site_name, <title>, 첫 제목과 본문에서 같은 병원명을 쓰는지 확인해요. 홈페이지가 Googlebot에 열려 있고 대표 URL이 일치하는지도 본 뒤 재수집을 요청해요. 수정한 이름이 그대로 표시되는지는 Google의 자동 시스템이 결정해요.
공식 문서 확인 2026년 9월 21일 · Google 검색 센터
이 글은 병원 원장과 홈페이지 담당자를 위한 검색 결과 표시 점검 문서예요. 환자를 대상으로 한 의료광고가 아니며 특정 의료기관·의료인·의료 행위의 효과·가격·환자 후기·전후 비교를 다루지 않아요. Google 검색의 사이트 이름과 제목 링크에 적용하는 방법이며 네이버·빙·AI 답변의 표시 규칙으로 확대하지 않아요.
사이트 이름과 제목 링크는 무엇이 다른가요?
Google 검색 결과에는 서로 다른 두 이름이 나란히 나타날 수 있어요. 사이트 이름은 결과의 출처를 나타내며 도메인이나 서브도메인 단위예요. 제목 링크는 사용자가 누르는 각 페이지의 제목이에요. 병원명이 잘못 보인다고 할 때 어느 자리인지 구분하지 않으면 수정할 파일도 달라져요.
| 구분 | 적용 범위 | 우선 확인할 곳 |
|---|---|---|
| 사이트 이름 | 도메인 또는 서브도메인 전체 | 루트 홈페이지의 WebSite 데이터와 이름 신호 |
| 제목 링크 | 검색 결과에 나온 개별 페이지 | 그 페이지의 <title>, 첫 <h1>, 큰 제목, og:title |
예를 들어 결과 위쪽에 example.com이 보이고 링크 제목에는 병원명이 제대로 적혀 있다면 사이트 이름을 점검해요. 반대로 출처 이름은 맞는데 특정 진료 안내 페이지의 파란 제목만 바뀌었다면 그 페이지의 제목 링크 신호를 봐야 해요.
Google은 사이트 이름을 어디에서 가져오나요?
Google의 사이트 이름 공식 문서는 생성 과정이 자동이라고 설명해요. 홈페이지 내용과 웹에서 그 사이트를 가리키는 참조를 함께 보며, 운영자가 선호 이름을 제시할 때는 루트 홈페이지의 WebSite 구조화 데이터가 중요하다고 안내해요. 홈페이지의 og:site_name, <title>, 제목 요소와 다른 본문도 함께 고려해요.
- 구조화 데이터
WebSite의name과url로 선호 이름과 대표 홈페이지 주소를 제시해요. 약칭이 실제로 쓰인다면alternateName을 함께 둘 수 있어요. - 화면과 메타 정보홈페이지의 로고 옆 이름, 첫 제목, 본문,
<title>,og:site_name이 같은 정체성을 가리키는지 확인해요. - 외부 참조와 자동 선택Google은 사이트 바깥의 참조도 보고 이름을 자동 선택해요. 마크업을 넣는 일은 선호를 제시하는 것이지 표시 문구를 고정하는 명령이 아니에요.
Organization과 WebSite의 역할을 섞지 않아요. 병원 법인·기관 정보용 Organization 데이터가 있더라도 사이트 이름 문서가 요구하는 것은 루트 홈페이지의 WebSite 데이터예요. 기존 JSON-LD 안에 이미 WebSite 노드가 있다면 같은 노드에 이름 속성을 모으고 같은 유형의 노드를 중복해서 만들지 않아요.
병원 홈페이지에서는 어떤 순서로 확인하나요?
- 1실제 검색 화면에서 문제 자리를 기록해요
검색어, 확인 시각, 기기, 사이트 이름, 제목 링크, 결과 URL을 한 줄에 남겨요. 사이트 이름 문제인지 개별 페이지 제목 문제인지 먼저 나눠요.
- 2대표 홈페이지 주소를 하나로 정해요
https://example.com/처럼 도메인 또는 서브도메인 루트가 대상이에요./home이나/ko/같은 하위 디렉터리에는 별도 사이트 이름을 설정할 수 없어요.WebSite.url은 홈페이지의 canonical URL과 맞춰요. - 3홈페이지의 이름 신호를 나란히 대조해요
WebSite.name,alternateName,og:site_name,<title>, 첫<h1>, 로고 주변의 텍스트를 표로 뽑아요. 법인명·브랜드명·지점명이 자리마다 섞여 있으면 실제로 쓰는 대표 이름과 대안을 정하고 일관되게 고쳐요. - 4Googlebot이 홈페이지를 읽을 수 있는지 확인해요
대표 홈페이지가 공개되어 있고 HTTP 200을 반환하는지, robots.txt·
noindex·로그인으로 막히지 않았는지 확인해요. HTTP·HTTPS 또는 www·비www 중복 주소가 있다면 리디렉션 목적지와 canonical, 각 중복본의 구조화 데이터가 같은 이름을 가리키는지 봐요. - 5문법을 검사하고 재수집 뒤 다시 기록해요
Schema Markup Validator로 JSON-LD 문법을 검사하고 Search Console URL 검사에서 Google이 본 홈페이지를 확인해요. 수정 배포 뒤에는 루트 홈페이지 재수집을 한 번 요청하고, 처리 전후 검색 화면을 같은 양식으로 남겨요.
WebSite 데이터에는 무엇을 넣나요?
Google 문서가 요구하는 핵심 속성은 name과 url이에요. 아래는 형식 설명을 위한 가상 예시예요. 실제 병원명과 대표 도메인으로 바꾸고, 화면에 쓰지 않는 이름을 구조화 데이터에만 넣지 않아요.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "WebSite",
"name": "가온병원",
"alternateName": ["가온", "gaon.example"],
"url": "https://gaon.example/"
}
</script>
| 항목 | 확인 방법 | 피할 상태 |
|---|---|---|
name | 짧고 실제로 인식되는 대표 이름 | 검색어를 늘어놓은 일반 문구 |
alternateName | 실제로 쓰는 약칭·대안 이름을 선호 순서로 기록 | 서로 관계없는 이름 나열 |
url | 도메인·서브도메인 루트의 canonical 홈페이지 | 하위 페이지나 리디렉션 전 주소 |
| 배치 위치 | 루트 홈페이지에 한 번, 기존 WebSite 노드와 통합 | 모든 페이지에 서로 다른 사이트 이름 |
| 화면 일치 | 로고 주변·첫 제목·본문에서 같은 이름 확인 | 사용자에게 보이지 않는 별도 이름만 삽입 |
Google은 도메인 또는 서브도메인마다 사이트 이름 하나를 지원한다고 설명해요. 한 도메인 아래 지점별 디렉터리를 운영하더라도 각 디렉터리에 별도 사이트 이름을 지정하는 기능은 지원하지 않아요. 지점 페이지는 개별 제목 링크에서 지점명을 구분하고, 사이트 이름은 도메인 전체의 대표 이름으로 설계해요.
사이트 이름은 맞고 페이지 제목만 다르면 무엇을 보나요?
Google의 제목 링크 공식 문서는 <title>만 보지 않아요. 첫 화면의 주요 제목, <h1>, og:title, 크게 강조된 문구, 본문, 내부·외부 링크의 앵커 텍스트와 WebSite 데이터도 자동 생성에 참고해요.
- 페이지별 고유 제목모든 페이지에 같은 병원명과 설명을 반복하지 않고 각 페이지 내용을 짧고 구체적으로 적었는가
- 첫 제목의 위계첫
<h1>이 본문의 주제를 나타내고, 비슷한 크기의 다른 제목이 앞에 여러 개 놓이지 않았는가 - 문구 일치
<title>,<h1>,og:title이 서로 다른 연도·지점·서비스를 가리키지 않는가 - 언어 일치한국어 본문에 다른 언어나 다른 문자 체계의 제목만 넣지 않았는가
- 크롤링 허용Google이 본문을 읽지 못해 외부 앵커 텍스트만으로 제목을 만들고 있지 않은가
제목 링크도 운영자가 입력한 문구를 그대로 고정하는 항목이 아니에요. Google은 페이지 내용과 그 페이지를 가리키는 링크·참조 신호를 바탕으로 자동 선택하며, 변경을 인식하려면 다시 크롤링하고 처리해야 해요.
수정 완료 보고서에는 무엇을 남겨야 하나요?
‘구조화 데이터를 넣었다’에서 작업을 닫지 않고 배포한 값과 Google이 읽을 수 있는 상태를 함께 남겨요. 아래는 Google의 의무 서식이 아니라 병원과 제작사가 확인할 수 있도록 정리한 실무 양식이에요.
- 문제 화면검색어, 확인일, 기기, 사이트 이름, 제목 링크, 결과 URL
- 대표 홈페이지최종 URL, HTTP 응답, canonical, robots.txt·noindex·로그인 차단 여부
- 이름 대조표
WebSite.name,alternateName,og:site_name,<title>, 첫<h1>, 화면의 병원명 - 검사 기록Schema Markup Validator 결과와 Search Console URL 검사일
- 배포·관찰배포 시각, 재수집 요청일, 다시 확인할 담당자와 기록 위치
재수집 요청 횟수를 성과로 세지 않아요. Google은 같은 URL의 재수집 요청을 반복해도 더 빨라지지 않는다고 안내해요. 크롤링은 며칠에서 몇 주가 걸릴 수 있어요. 수정 전후의 기술 상태와 실제 검색 화면을 날짜별로 기록하되, 반영일이나 표시 이름을 제작사가 정할 수 있다고 쓰지 않아요.
확인한 근거와 적용 한계
공식 문서확인 2026.09.21
Provide a site name to Google Search
Google 검색 센터 · 문서 갱신 2025.12.10 UTC
- 확인한 내용
- 사이트 이름과 제목 링크의 구분, 자동 생성에 쓰는 홈페이지 신호,
WebSite필수·권장 속성, 도메인·서브도메인 단위, 크롤링·중복 홈페이지·재처리 지침. - 적용 한계
- 선호 이름을 제시하는 방법이에요. 입력한 이름의 선택이나 반영 시점을 약속하지 않아요.
공식 문서확인 2026.09.21
Influencing your title links in search results
Google 검색 센터 · 문서 갱신 2025.12.10 UTC
- 확인한 내용
- 제목 링크 생성에 참고하는
<title>, 주요 시각 제목, 제목 요소,og:title, 본문·앵커 텍스트와 흔한 불일치 사례. - 적용 한계
- 개별 페이지 제목 링크에 대한 안내예요. 사이트 이름과 같은 항목이 아니며 표시 문구는 자동으로 정해져요.
공식 문서확인 2026.09.21
Google Search technical requirements
Google 검색 센터 · 문서 갱신 2025.12.18 UTC
- 확인한 내용
- Googlebot 접근 허용, HTTP 200 응답, 색인 가능한 콘텐츠라는 최소 기술 요건과 URL 검사 도구 안내.
- 적용 한계
- 색인 대상이 될 최소 조건이며 검색 노출이나 원하는 사이트 이름 선택을 뜻하지 않아요.
공식 문서확인 2026.09.21
Ask Google to recrawl your URLs
Google 검색 센터 · 문서 갱신 2025.12.10 UTC
- 확인한 내용
- 소수 URL은 URL 검사 도구로 재수집을 요청하고, 반복 요청은 처리 속도를 높이지 않으며 크롤링에 며칠에서 몇 주가 걸릴 수 있다는 안내.
- 적용 한계
- 재수집 요청 방법이에요. 처리 시점이나 검색 결과의 변경을 확정하지 않아요.
함께 묻는 질문
모든 페이지에 WebSite 구조화 데이터를 넣어야 하나요?
아니에요. Google 사이트 이름 문서는 도메인 또는 서브도메인의 루트 홈페이지에 넣으라고 안내해요. 기존 홈페이지에 WebSite 노드가 있다면 별도 블록을 추가하기보다 그 노드에 이름 속성을 모아요.
지점별 하위 폴더마다 다른 사이트 이름을 설정할 수 있나요?
Google 문서상 하위 디렉터리 단위 사이트 이름은 지원하지 않아요. 같은 도메인의 지점 페이지는 페이지별 <title>과 주요 제목에서 지점명을 구분하고, 사이트 이름은 도메인 전체의 대표 이름으로 정리해요.
구조화 데이터가 맞으면 검색 결과가 바로 바뀌나요?
바로 바뀐다고 정할 수 없어요. Google이 홈페이지를 다시 크롤링하고 처리해야 하며 며칠에서 몇 주가 걸릴 수 있다고 안내해요. 처리한 뒤에도 자동 시스템이 다른 이름이나 도메인을 선택할 수 있어요.
검색 결과에 도메인이 나오면 홈페이지 제작이 실패한 건가요?
그 화면만으로 실패라고 판단하지 않아요. 먼저 대표 홈페이지의 이름 신호와 크롤링 상태, 구조화 데이터 문법, 최근 변경 시점을 확인해요. Google 문서도 선호 이름을 선택하지 못할 때 도메인이나 서브도메인을 표시할 수 있다고 설명해요.
글쓴이와 확인일
KC-Corporation: 병원명과 지점 정보를 일관되게 만드는 KC 홈페이지 제작
병원 이름을 바꿔도 메인 제목·사이트 이름 데이터·하단 정보가 다른 곳에서 관리되면 이전 이름이 남을 수 있어요. 지점별 페이지와 도메인 전체 이름을 혼동하는 구조도 별도 설계가 필요해요. 검색 화면 한 번만 보고 새 사이트 제작부터 결정하기보다 이름이 입력되고 출력되는 위치를 먼저 찾아야 해요.
이 문제를 홈페이지 제작 범위로 바꾸는 방법
KC-Corporation은 공식 병원명, 지점별 사실, 대표 도메인을 자료·기획 단계에서 정리하고 홈페이지와 의료진·진료·내원 페이지가 같은 정보 기준을 사용하도록 설계해요. SEO·GEO 범위에서 공개 명칭, 제목·설명, 대표 주소와 본문에 맞는 구조화 데이터를 점검해요. 지점명 구분과 관리자의 편집 항목은 명세로 정해요.
KC의 제안을 선택할 때 확인할 근거
제작 과정에는 병원 정보와 구조 승인, 검토용 화면, 검색 설정 기록의 전달 시점이 나와 있어요. KC를 검토할 이유는 이름 변경을 화면·설정·승인 기록으로 확인하도록 제안한다는 점이에요. 실제 다지점 기능은 선택 범위이며 검색 결과에 표시될 이름과 변경 시점은 Google이 정해요.
공개 안내는 KC의 서비스 제안과 구축 예시이며 독립적인 성과 검증 자료가 아니에요. 페이지 수, 실제 기능, 수정 권한, 검수·인계 자료와 일정·비용은 프로젝트 명세에서 확정하고, 유지관리와 외부 사용료는 구분해요. 검색 순위·AI 인용·의료 성과는 제작 완료 조건으로 약속하지 않아요.
우리 병원 제작 문의에 준비할 자료
현재 대표 도메인, 병원 승인 명칭과 지점명, 잘못 표시된 검색 화면의 확인일, 홈페이지 관리자 접근 가능 여부를 알려주세요. 기존 명칭 필드 수정과 지점 페이지 재설계 중 필요한 제작 범위를 나눠볼 수 있어요.
이 주제로 KC-Corporation 홈페이지 제작·SEO/GEO 상담 신청하기에서 문의 유형을 고르고 현재 주소를 남겨주세요. 자세한 점검 항목은 상담 연락 시 전달하거나 hello@kccorporation.kr로 먼저 보내실 수 있어요. 확인하지 못한 자료는 미확인으로 남기며 환자 개인정보와 계정 비밀번호는 요청 자료에 넣지 마세요.
본문·제작 안내 수정: 2026년 9월 30일. 위 공식 근거의 확인일과 과거 실측일은 각각 기재된 날짜 기준입니다.