흩어진 우리 회사를 하나로 묶으려면?

구조화 데이터 편에서 @id와 sameAs를 "반드시 포함하라"고 적고 설명은 짧게 지나갔습니다. 이 글이 그 두 줄의 실행편입니다.

먼저 무엇을 푸는 문제인지부터 정리하겠습니다.

정보가 없는 게 아니라 흩어져 있습니다

AI에게 회사를 물었을 때 아무 말도 못 하는 상태의 원인은 대개 정보 부족이 아닙니다. 같은 회사인 줄 모르는 것입니다.

한 회사가 이렇게 존재합니다.

사람은 한눈에 같은 회사라고 압니다. 기계는 네 개의 서로 다른 존재로 봅니다. 그래서 어느 쪽에 좋은 내용을 쌓아도 한 곳에 모이지 않습니다.

엔티티 정리는 이 흩어진 표기를 하나로 모으고, 그 사실을 기계가 읽는 형식으로 선언하는 작업입니다.

콘텐츠를 아무리 쌓아도 그게 누구 것인지 특정되지 않으면 브랜드에 쌓이지 않습니다. 순서상 콘텐츠보다 이게 먼저입니다.

1단계 — 표준 표기를 하나로 정합니다

가장 지루하고 가장 많이 건너뛰는 단계인데, 여기가 틀리면 나머지가 전부 어긋납니다. 정할 것은 다섯 개입니다.

"주식회사 ○○"와 "(주)○○"는 기계에게 다른 문자열입니다. 사람에게는 같지만, 대조하는 쪽은 사람이 아닙니다.

2단계 — 어긋난 곳을 찾습니다

정한 표기를 들고 실제 노출된 곳을 대조합니다. 흔히 NAP(Name·Address·Phone) 정합이라고 부릅니다.

봐야 할 곳은 대개 이 정도입니다.

□ 홈페이지 푸터
□ 홈페이지 회사소개·오시는 길
□ 사업자정보 표기 (통신판매업 신고 포함)
□ 네이버 플레이스
□ 카카오맵
□ 구글 비즈니스 프로필
□ 인스타그램·유튜브 등 공식 계정 소개란
□ 블로그 프로필
□ 채용공고 사이트
□ 협회·조합 회원사 목록

마지막 두 개가 자주 새는 곳입니다. 예전에 올린 채용공고의 옛 주소, 협회 명부의 옛 전화번호가 그대로 살아 있는 경우가 많습니다. 사이트 밖 정보가 어긋나면 사이트 안을 아무리 정리해도 확인이 안 됩니다 — 사이트 밖 근거가 왜 점수에 들어가나 편에서 다룬 이야기입니다.

3단계 — @id로 회사를 하나로 못 박습니다

여기부터가 선언입니다. 회사에 URL 형태의 고유 식별자를 하나 부여하고, 사이트 전체가 그것을 참조하게 만듭니다.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://example.co.kr/#organization",
  "name": "주식회사 대한기공",
  "alternateName": ["대한기공", "DAEHAN ENG"],
  "url": "https://example.co.kr",
  "telephone": "+82-31-000-0000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "○○로 12",
    "addressLocality": "화성시",
    "addressRegion": "경기도",
    "postalCode": "00000",
    "addressCountry": "KR"
  }
}

두 가지만 짚겠습니다.

• @id는 실제로 열리는 주소일 필요가 없습니다. #organization 같은 조각을 붙여 쓰는 게 관례입니다. 목적은 접속이 아니라 식별입니다.
• alternateName이 흩어진 표기를 흡수합니다. 네이버에 "대한기공"으로, 인스타에 "DAEHAN ENG"로 올라가 있다면 그 표기들을 여기에 적어 둡니다. 표기를 바꾸라는 게 아니라 같은 회사임을 알리는 것입니다.

이 @id를 정해 두면 다른 스키마가 회사를 다시 설명할 필요 없이 참조만 하면 됩니다.

{
  "@type": "Product",
  "name": "방습 포장재 DH-200",
  "brand": { "@id": "https://example.co.kr/#organization" }
}

페이지마다 회사 정보를 새로 적으면 페이지 수만큼의 회사가 생깁니다. 참조로 바꾸면 하나가 됩니다.

4단계 — sameAs로 채널을 묶습니다

sameAs는 "이 URL들도 전부 우리다" 라는 선언입니다. 흩어진 계정을 한 회사로 모으는 실마리가 여기입니다.

"sameAs": [
  "https://blog.naver.com/daehan_eng",
  "https://www.instagram.com/daehan_eng",
  "https://www.youtube.com/@daehan_eng",
  "https://map.naver.com/p/entry/place/0000000000"
]

넣을 것과 넣지 않을 것이 갈립니다.

마지막 줄이 흔한 실수입니다. sameAs는 "우리가 운영하는 곳" 이지 "우리를 언급한 곳"이 아닙니다. 남의 URL을 넣으면 소유 관계를 잘못 선언하는 셈이 됩니다.

관리가 안 되는 계정은 빼는 쪽이 낫습니다. 3년째 비어 있는 계정을 공식 채널로 선언하면, 확인하러 간 쪽이 보는 것은 빈 계정입니다.

5단계 — 확인합니다

세 가지를 봅니다.

① 문법이 맞는가

리치 결과 테스트와 스키마 마크업 검증기에 주소를 넣으면 파싱 결과가 나옵니다. Organization이 인식되는지, 넣은 필드가 다 잡히는지 봅니다.

② 원본 HTML에 있는가

스키마를 자바스크립트로 나중에 주입하면 크롤러가 못 봅니다. 구조화 데이터 편에서 다룬 그대로입니다.

curl -s https://example.co.kr | grep -c 'application/ld+json'

0이 나오면 원본 HTML에는 없다는 뜻입니다. 브라우저 개발자도구에서는 보였더라도 마찬가지입니다.

③ 페이지마다 같은 @id인가

for p in "" "/about" "/products" "/contact"; do
  printf "%-12s " "$p"
  curl -s "https://example.co.kr$p" | grep -o '"@id":"[^"]*#organization"' | head -1
done

빈 줄이 있으면 그 페이지는 회사와 연결되지 않은 상태입니다.

자가 점검

□ 국문·영문 상호를 각각 하나로 정했다
□ 전화·주소 표기 형식을 고정했다
□ 홈페이지 푸터와 네이버 플레이스의 상호가 글자 단위로 같다
□ Organization JSON-LD가 원본 HTML에 있다
□ @id가 있고, 모든 페이지가 같은 값을 쓴다
□ alternateName에 실제로 쓰이는 다른 표기를 넣었다
□ sameAs에 공식 채널만 들어 있다 (남의 URL 없음)
□ 옛 주소·옛 전화가 남은 외부 페이지를 찾아 고쳤다

여덟 개가 다 채워지면 기계가 회사를 하나로 인식할 조건은 갖춘 것입니다. 그 뒤부터 쌓는 콘텐츠는 흩어지지 않고 한 곳에 붙습니다.

자주 틀리는 것

마지막 항목이 핵심입니다. sameAs는 한쪽에서 하는 주장입니다. 상대 채널에서도 홈페이지를 가리키고 있으면 확인이 되고, 한쪽만 주장하면 확인되지 않은 주장으로 남습니다.

정리

• AI가 회사를 모르는 이유는 정보 부족이 아니라 흩어짐인 경우가 많습니다
• 표준 표기를 먼저 정합니다. 여기가 흔들리면 뒤가 전부 흔들립니다
• @id는 회사를 하나로 못 박고, sameAs는 채널을 묶습니다
• sameAs에는 우리가 운영하는 곳만 넣습니다
• 선언은 한쪽 주장이라, 양방향으로 가리킬 때 확인됩니다

직접 하기 어려운 규모(지점이 여럿이거나 외부 등록 정보가 많이 흩어진 경우)라면 GEO 컨설팅의 브랜드 엔티티 작업으로도 진행합니다. 표준 표기 정의서와 검증 리포트까지 산출물로 정리해 드립니다.

---

다음 단계 — 사이트 안에서 회사를 하나로 못 박았다면, 그다음은 사이트 밖에서 같은 말이 나오는지입니다.

• JSON-LD가 없으면 AI가 회사 정보를 못 읽나? — 이 글의 앞 단계
• 사이트 밖 근거가 왜 점수에 들어가나? — 사이트 밖 확인
• AI 가독성이란 무엇인가 — 8개 지표 전체 보기
• 무료 진단 받기 — 우리 사이트의 구조화 데이터 상태 확인