JSON-LD @id 하나로 회사가 둘이 되는 문제: #org와 #organization
형제 앱 스무 개의 구조화 데이터(JSON-LD)를 모아 보다가 회사가 두 개인 것을 발견했습니다. 여섯 곳은 발행자를 이렇게 가리켰습니다.
"publisher": { "@id": "https://duolabs.co.kr/#org" }네 곳은 이렇게 가리켰습니다.
"publisher": { "@id": "https://duolabs.co.kr/#organization" }그리고 다섯 곳은 회사를 아예 가리키지 않았습니다. 한 회사가 만든 사이트들인데, 기계가 읽는 층에서는 회사가 둘이었고 몇몇 사이트는 주인이 없었습니다.
@id는 아무 문자열이나 넣어도 되는 이름표라는 오해
JSON-LD의 @id는 대충 쓰기 쉬운 값입니다. 화면에 보이지도 않고, 틀려도 에러가 나지 않습니다. 구조화 데이터 검사 도구도 둘 다 통과시킵니다. #org든 #organization이든 문법적으로는 올바른 URL이기 때문입니다.
그런데 @id는 이름표가 아니라 식별자입니다. schema.org의 데이터 모델에서 같은 @id를 가진 노드는 같은 대상이고, 다른 @id를 가진 노드는 다른 대상입니다. https://duolabs.co.kr/#org와 https://duolabs.co.kr/#organization은 글자 몇 개 차이지만, 기계에게는 서로 다른 두 조직입니다.
갈라진 경위
원인은 단순했습니다. 먼저 만든 앱들은 #org를 썼습니다. 나중에 만든 몇 앱은 다른 예제를 참고했고, 그 예제가 #organization을 썼습니다. 둘 다 흔한 관례라 누구도 틀렸다고 느끼지 않았습니다. 앱마다 JSON-LD를 따로 쓰고 있었기 때문에, 한쪽을 고쳐도 다른 쪽은 알 수 없었습니다.
회사를 가리키지 않은 다섯 곳은 더 단순합니다. 앱 소개 구조화 데이터를 넣을 때 발행자 칸을 빼먹었거나, 구조화 데이터 자체를 넣지 않았습니다.
검색엔진이 알아서 합쳐 줄까
검색엔진이 이름과 주소가 같으니 같은 회사로 합쳐 줄 수도 있습니다. 저는 그 가능성에 기대지 않기로 했습니다. 합쳐 줄지 말지는 검색엔진이 정하는 일이고, 문서로 보장된 동작이 아닙니다. 확실한 것은 제가 한 식별자만 쓰면 합칠 필요 자체가 없어진다는 것입니다.
AI 검색이 인용할 출처를 고를 때도 비슷합니다. 같은 회사가 쓴 글들이 한 발행자로 묶여 있으면 그 회사에 대한 신호가 한곳에 모입니다. 두 발행자로 나뉘어 있으면 신호도 나뉩니다. 이 차이가 순위를 얼마나 바꾸는지는 저도 모릅니다. 다만 나뉘어서 얻는 이득은 없습니다.
식별자 하나를 정본으로
고친 방법은 이렇습니다. 본진의 Organization 노드가 정본이고, 그 식별자는 https://duolabs.co.kr/#org 하나입니다. 형제 앱들은 회사 정보를 다시 적지 않고 이 식별자만 가리킵니다. #organization을 쓰던 네 곳을 #org로 바꿨고, 회사를 가리키지 않던 곳은 앱 구조화 데이터에 발행자 참조를 넣기로 했습니다.
{
"@type": "WebApplication",
"name": "…",
"url": "https://….duolabs.co.kr",
"publisher": { "@id": "https://duolabs.co.kr/#org" }
}회사 이름, 로고, 연락처는 본진 한 곳에만 있습니다. 형제 앱이 회사 정보를 각자 복사해 두면, 회사 주소가 바뀌는 날 스무 곳을 고쳐야 하고 그중 하나는 반드시 빠집니다.
한 번 고치고 끝나지 않게
같은 일이 다시 생기지 않으려면 새 앱이 처음부터 올바른 식별자로 태어나야 합니다. 앱을 만드는 공통 스타터에 발행자 참조가 들어간 구조화 데이터를 넣고, 공개 호스트를 돌며 JSON-LD의 발행자 식별자가 #org인지 확인하는 점검을 두기로 했습니다.
JSON-LD를 직접 문자열로 만들어 <script> 안에 넣을 때 <를 이스케이프하는 것도 같은 스타터에 넣었습니다. 값 안에 </script>가 들어가면 스크립트 태그가 거기서 끝나 버리기 때문입니다. 구조화 데이터는 화면에 안 보여서 대충 다루기 쉽지만, 페이지에 들어가는 코드라는 점은 다른 코드와 같습니다.
함께 읽기
- 구글·네이버·Bing·다음 웹마스터 도구 비교: 서브도메인이 많을 때 갈리는 것서브도메인 열세 개를 검색엔진에 등록하는 데 구글은 DNS 레코드 한 줄이었고, 네이버는 같은 일을 열세 번 반복해야 했습니다. 두 도구의 기능 목록은 비슷합니다. 사이트맵을 받고, 소유를 확인하고, 수집 현황을 보여 줍니다. 갈리는 것은 무엇을 사이트 하나로 세는가였습니다.
- 네이버 서치어드바이저 서브도메인 등록: 사이트맵·RSS·수집 요청이 하는 일서브도메인 사이트맵을 본진 사이트에 넣었더니 네이버가 받지 않았습니다. https://duolabs.co.kr 로 등록해 둔 사이트의 사이트맵 제출 칸에 https://cdn.duolabs.co.kr/sitemap.xml 을 넣고 확인을 누르자, 화면 아래에 빨간 띠가 떴습니다.
- robots.txt의 AI 봇 구분: 학습을 막으려다 ChatGPT 검색에서 빠진 두 앱듀오랩스 이름으로 운영하는 형제 앱 스무 개의 robots.txt를 하나씩 열어 본 적이 있습니다. 그중 두 곳에 이런 줄이 있었습니다.
- 구조화 데이터 점검: 화면에는 있는데 기계에는 없던 것들저희 홈페이지 맨 아래에는 전화번호가 적혀 있습니다. 코드에도 상수로 들어 있어서 여러 화면이 같은 값을 가져다 씁니다.
- 형제 서비스 스무 개의 llms.txt: 본진을 허브로, 앱은 가리키기만듀오랩스 본진의 llms.txt를 다시 읽어 봤습니다. AI가 사이트를 이해하도록 요약해 두는 파일입니다. 서비스 상세로는 웹 개발 페이지 하나가 올라 있었습니다. 그런데 듀오랩스 이름으로 돌아가는 형제 앱은 스무 개입니다. 업무 시스템, AI 자동화, 3D, ERP 같은 데모까지, AI가 "듀오랩스는 무엇을 만드나"를…