- 01먼저 볼 곳홈페이지의 WebSite 구조화 데이터가 이름 환경설정의 중심 수단입니다.
- 02함께 맞출 곳<title>·og:site_name·제목 요소의 이름도 하나로 맞춥니다.
- 03그래도 안 될 때대체 이름 → 소문자 도메인 백업 → 도메인을 name으로 순서로 바꿔 시도합니다.
구글 검색 결과의 사이트 이름 자리에 회사명 대신 도메인이나 다른 문구가 나오는 경우가 생깁니다. 먼저 홈페이지 WebSite 구조화 데이터의 name을 통용되는 짧은 회사명으로 통일합니다. <title>·og:site_name도 같은 이름으로 정리합니다. 사이트 이름은 검색 결과마다 출처를 알리는 표시이며, Google이 자동으로 정합니다. 소유자가 직접 바꿀 수는 없고, 원하는 이름을 구조화 데이터로 알릴 수 있습니다. 이 글은 Google 검색 센터 문서를 기준으로 점검 순서를 정리합니다. 네이버 등 다른 검색 서비스의 기준은 다루지 않습니다.
사이트 이름과 검색 결과 제목은 무엇이 다른가요?
사이트 이름은 사이트 전체에 붙는 이름이고, 제목 링크는 페이지마다 다른 제목입니다.
「Google 검색에 사이트 이름 제공」 문서가 둘을 구분합니다. 제목 링크는 각 웹페이지에만 적용되고, 사이트 이름은 전체 사이트에 적용됩니다.
Google 검색 센터 문서 기준으로 넥스트티가 정리했습니다.
| 요소 | 적용 범위 | 정하는 곳 |
|---|---|---|
| 사이트 이름 | 사이트 전체 | 홈페이지 WebSite 데이터 |
| 제목 링크 | 페이지 하나 | 페이지별 <title> 등 |
| 파비콘 | 호스트 이름 전체 | 홈페이지 아이콘 링크 |
「검색결과에서 시선을 끄는 제목 링크 작성」에는 둘이 이어지는 대목도 나옵니다. 검색결과에 이미 표시되는 사이트 이름이 제목에서 반복되면 제목 링크에서 그 이름이 생략될 수 있습니다. 다만 홈페이지 <title>은 사이트 이름을 정할 때도 고려됩니다.
Google은 사이트 이름을 어디에서 가져오나요?
Google은 홈페이지 콘텐츠와 웹에서 그 사이트를 가리키는 표현을 함께 보고 이름을 정합니다.
사이트 이름은 모두 자동으로 생성됩니다. 시스템은 og:site_name, <title>, 제목 요소, 홈페이지의 다른 텍스트를 고려합니다. 그중 이름 환경설정을 알리는 중심 수단으로 WebSite 구조화 데이터를 꼽습니다.
「Google 검색에 사이트 이름 제공」 문서에 나온 항목입니다.
구조화 데이터의 이름은 홈페이지 다른 소스의 이름과 일치해야 합니다. 넥스트티는 이 일치 여부를 원인 점검의 출발점으로 봅니다. 네 곳의 표기가 서로 다르면 Google이 어느 쪽을 택할지 예상하기 어렵기 때문입니다.
WebSite 구조화 데이터는 어떻게 넣나요?
홈페이지 한 곳에 name과 url 두 속성을 담은 WebSite 데이터를 넣습니다.
필수 속성은 name과 url 두 가지입니다. url에는 도메인이나 하위 도메인의 표준 홈페이지 주소가 들어갑니다. 이 마크업은 모든 페이지가 아니라 홈페이지에만 넣으면 됩니다.
문서 예시 형식의 JSON-LD로, script 태그 안에 넣습니다. 이름과 주소는 자사 값으로 바꿉니다.
{
"@context":
"https://schema.org",
"@type": "WebSite",
"name": "회사명",
"url":
"https://www.example.com/"
}- 페이지 소스에서 "WebSite"를 검색해 기존 블록이 있는지 먼저 찾습니다. CMS가 이미 출력하고 있을 수 있습니다.
- 기존 WebSite 데이터가 있으면 같은 노드에 name을 중첩합니다. 가능하면 블록을 새로 만들지 않는 편이 좋습니다.
- http·https, www 유무처럼 중복 홈페이지가 있으면 모두 같은 데이터가 들어가야 합니다.
- 홈페이지가 robots.txt·noindex·로그인으로 막혀 있으면 안 됩니다. 접근이 막히면 이름을 생성할 수 없습니다.
마크업 오류를 찾는 방법은 구조화 데이터 디버깅 안내에서 다룹니다.
어떤 이름을 골라야 선택될 가능성이 커지나요?
간결하고 널리 알려진 이름을 고르고, 홈페이지 어디에서나 같은 표기로 씁니다.
「사이트 이름 선택하기」 절의 내용을 넥스트티가 표로 옮겼습니다.
| 기준 | 문서의 설명 |
|---|---|
| 간결한 이름 | 법인 표기보다 통용되는 짧은 이름 |
| 일반 명칭 회피 | 널리 알려진 브랜드가 아닌 일반 명칭은 선택 가능성 낮음 |
| 일관된 표기 | 구조화 데이터와 다른 소스의 이름 일치 |
| 대체 이름 준비 | 약어·짧은 이름을 alternateName에 입력 |
문서의 예는 「Google, Inc」 대신 「Google」입니다. 길이 제한은 없으나 긴 이름은 일부 기기에서 잘려 보일 수 있습니다. 「아이오와 주 최고의 치과 의사」 같은 설명형 이름은 선택될 가능성이 작다고 합니다.
소유자가 원하는 이름이 늘 쓰이지는 않습니다. Google 시스템은 성격이 광범위한 서로 다른 두 사이트에 같은 이름을 쓰지 않습니다. 전체 이름보다 약어로 더 알려졌다고 판단하면 약어를 택하기도 합니다.
넣었는데도 다른 이름이 나오면 무엇을 점검하나요?
구조화 데이터, 사이트 범위, 리디렉션, 여러 버전의 표기를 차례로 점검합니다.
1. 이름과 오류 점검
WebSite 데이터의 이름이 원하는 이름인지, 구문 오류는 없는지 스키마 마크업 검사기로 살핍니다.
2. 다른 소스 대조
홈페이지의 <title>·og:site_name·제목 요소에 같은 이름이 쓰였는지 비교합니다.
3. 사이트 범위 점검
/blog 같은 하위 디렉터리에 별도 이름을 지정했다면 효과가 없습니다. 지원 단위는 도메인과 하위 도메인입니다.
4. 리디렉션 점검
Googlebot이 리디렉션 대상에 접근하는지 봅니다. 이름에는 대상 페이지가 반영됩니다.
5. 여러 버전 대조
http·https 등 여러 버전에서 같은 이름을 쓰는지 대조합니다.
리치 결과 테스트는 사이트 이름을 지원하지 않습니다. 구문은 스키마 마크업 검사기로, 접근 여부는 URL 검사 도구로 점검합니다. 하위 도메인 홈페이지에 데이터가 없으면 도메인 수준의 이름이 대신 쓰이기도 합니다.
점검 뒤에도 안 바뀌면 어떻게 하나요?
대체 이름을 먼저 넣고, 그래도 안 되면 소문자 도메인을 백업으로 더합니다. 도메인을 name으로 쓰는 일은 마지막 수단입니다.
「원하는 사이트 이름을 선택하지 않은 경우 해결 방법」 절의 순서입니다.
대체 이름 추가
소문자 도메인 백업
도메인을 name으로
1단계로 해결되지 않을 때 2단계를 더한 모습입니다. 대체 이름은 중요도 순으로 넣고, 소문자 도메인은 배열 끝에 둡니다.
{
"@context":
"https://schema.org",
"@type": "WebSite",
"name": "회사명",
"alternateName": [
"약칭",
"example.com"
],
"url":
"https://www.example.com/"
}도메인을 백업으로 넣을 때는 모두 소문자로 씁니다. 「Example.com」이 아니라 「example.com」처럼 써야 환경설정으로 감지됩니다. 도메인을 name에 넣으면 시스템이 일반적으로 그 이름을 고릅니다. 문서도 최후의 수단으로만 쓰라고 합니다.
- 사이트 이름 문서는 재크롤링과 처리에 며칠에서 몇 주까지 걸릴 수 있다고 적었습니다.
- URL 검사 도구로 홈페이지의 색인 생성을 요청합니다. 요청해도 색인이 보장되지 않고, 하루 요청 수에는 제한이 있습니다.
- 홈페이지에 이름이 반영된 뒤에도 내부 페이지는 다시 크롤링될 때까지 기다립니다.
사이트 이름 옆의 아이콘은 파비콘 문서에서 다룹니다. 설정 방법은 파비콘 등록 글을 참고하세요. 파비콘도 하위 디렉터리 단위로는 지정할 수 없습니다.
참고 자료
- Google 검색 센터 — Google 검색에 사이트 이름 제공
- Google 검색 센터 — 검색결과에서 시선을 끄는 제목 링크 작성
- Google 검색 센터 — 검색결과에 표시할 파비콘 정의하기
- Search Console 고객센터 — URL 검사 도구
