오프라인 매장을 열고 웹사이트 하단에 큼지막하게 주소를 적어뒀는데도, 막상 검색결과에 내 매장 위치 정보가 제대로 뜨지 않는다면 로봇이 전혀 알아들을 수 없는 외계어로 허공에 소리치고 있는 셈입니다.
핵심은 번역입니다. 네이버와 구글의 검색로봇은 인간처럼 문맥을 읽고 알아서 지도를 찾아주지 않습니다. 이들에게 홈페이지에 적힌 텍스트가 '단순한 글자'인지, 아니면 '실제 고객이 찾아올 수 있는 매장 주소'인지 정확히 떠먹여 주는 친절한 통역기. 그게 바로 구조화된 데이터가 존재하는 진짜 이유입니다.
막상 해보면 쉽습니다.
가까운 지인이 작은 스페셜티 커피 매장을 하나 열었습니다. 나름 직접 발품을 팔아 감성적인 웹사이트도 만들고, 찾아오시는 길 페이지에 주소도 아주 예쁘게 꽉꽉 채워 넣었죠. 근데 검색창에 브랜드명을 쳐보면 스니펫에 주소가 아예 안 뜨더라고요. 환장할 노릇이죠.
솔직히 옆에서 지켜보는 저조차 답답했습니다. 사실 커피 맛도 훌륭하고 사이트 디자인도 무척 예뻤습니다. 단지 네이버 검색로봇이 그 이미지와 텍스트 속에 담긴 '위치 정보'의 가치를 전혀 해석하지 못하고 자동 수집 단계에서 누락시키고 있었을 뿐입니다.
아무리 사람이 보기 편하게 적어놔도, 논리적으로 조직화해서 가공된 데이터로 만들지 않으면 로봇 입장에서는 그냥 까만 건 글씨고 하얀 건 바탕화면일 뿐이거든요. 관계형 데이터베이스를 떠올리면 쉽습니다. 엑셀 표처럼 칸을 나누고 정확한 이름표를 붙여줘야 비로소 로봇이 소화를 시작합니다.
웹 콘텐츠 속 정보를 명확하게 정의해 보자는 노력은 아주 오래전부터 있었습니다. 인터넷 커뮤니티와 여러 관련 업체들이 기초 작업을 꾸준히 해왔고, 그 결과물이 바로 schema.org라는 사이트를 통해 전파되고 있죠. 웹 표준 기구인 W3C 내에서 공식적으로 편입될 정도로 족보 있는 전 세계적인 약속입니다.
매장 주소에 JSON-LD 심어보기
개발 지식이 1도 없던 지인은 처음에 지레 겁을 먹었습니다. 마크업인가 먼가 하는 용어부터가 너무 낯설었으니까요. 언어 형식에는 크게 세 가지가 지원되는데, 네이버에서는 널리 쓰이는 Microdata나 JSON-LD를 권장합니다. 지인은 가장 직관적이고 덩어리째 넣기 편한 JSON-LD 형식을 선택했습니다.
복잡해 보이지만 그냥 빈칸 채우기 게임입니다. 아래와 같은 형태의 코드를 메모장에 복사해 놓고 내 매장 정보로 갈아 끼우기만 하면 됩니다.
"@context": "https://schema.org",
"@type": "Organization",
"name": "나만의 오프라인 매장명",
"address": {
"@type": "PostalAddress",
"postalCode": "13561",
"addressRegion": "경기",
"addressLocality": "성남시 분당구",
"streetAddress": "정자일로 95"
}
· postalCode (선택): 숫자 혹은 하이픈(-)으로 우편번호를 씁니다.
· addressRegion (선택): 주소 중 가장 큰 지역명, 예를 들면 '서울'이나 '경기'를 적어줍니다.
· addressLocality (선택): 그보다 작은 하위 지역인 시/구 단위를 적습니다.
· streetAddress (필수): 이 부분이 핵심입니다. 도로명을 포함한 아주 상세한 나머지 주소를 기입합니다.
네이버의 차가운 경고장, 그리고 진짜 승부
신나게 코드를 복사해서 사이트에 심어놓고, 친구는 매일같이 네이버 검색결과 창만 새로고침했습니다. 무언가 화려한 지도 스니펫이 뜰 줄 알았겠죠. 하지만 며칠이 지나도 묵묵부답이었습니다. 트래픽은 여전히 바닥. 진짜 이쯤 되면 포기하고 싶어지죠.
도대체 뭐가 문제일까 싶어 네이버의 기본 가이드라인 문서를 아주 꼼꼼히 다시 들여다봤습니다. 거기에 지인이 놓쳤던 아주 뼈아픈 조건이 하나 숨어 있더군요.
가이드라인 위반 주의: 사이트 공통 주소를 여러 페이지에 무의미하게 동일하게 반복해서 사용하지 마세요. 각 요소별로 적합한 내용을 최대한 자세하고 중복 없이 명확하게 입력해야만 정상적으로 수집되고 반영될 수 있습니다.
지인은 매장이 여러 개라 지점 안내 페이지를 여러 개 만들었는데, 실수로 모든 페이지에 본점 주소를 똑같이 복붙해 둔 겁니다. 로봇 입장에서는 스팸이나 혼란스러운 정보로 인식하기 딱 좋았던 거죠. 껍데기만 화려하게 포장한다고 로봇이 속아 넘어가는 시대가 아닙니다.
오류를 먼저 잡는 자가 살아남는다
지인은 다시 마음을 다잡고 근본적인 뼈대부터 수정하기 시작했습니다. 각 지점 페이지마다 정확하고 고유한 PostalAddress를 다시 세팅했죠. 그리고 마지막으로 한 일은 본인이 작성한 코드를 검증하는 거였습니다. schema.org에서 공식적으로 제공하는 '구조화된 데이터 테스팅 도구'를 띄워놓고 돌려봤습니다.
아니나 다를까, 필수 속성인 streetAddress에 오타를 낸 걸 테스팅 도구가 기가 막히게 잡아내더라고요. 이렇게 작은 누락이나 중복을 찾아내는 작업. 이건 올바로 적용되었는지 확인하기 위한 생존의 필수 요건입니다.
테스팅 도구로 꼼꼼하게 교정하고, 각 페이지별 주소 정보가 정확히 독립성을 띠기 시작한 시점. 어느 날 갑자기 지인의 매장 검색결과 하단에 그토록 원하던 주소 정보가 명확하게 노출되기 시작했습니다. 단순한 웹사이트 링크가 아니라, 실제 손님이 찾아갈 수 있는 살아있는 정보로 말이죠.
글만 길게 쓰고 예쁜 사진만 올린다고 알아서 손님이 찾아와 주는 낭만적인 시대는 끝났습니다. 검색엔진의 언어를 이해하고, 그들이 가장 소화하기 좋은 형태로 명확한 주소표를 내미는 사람. 오직 그 사람만이 텅 빈 검색결과 속에서 돋보이는 나만의 매장을 쟁취할 수 있습니다. 지금 바로 내 사이트의 번역 상태를 점검해 보세요.