같은 키워드로 검색했을 뿐인데 어떤 가게는 별점과 리뷰 수, 영업시간, 약도까지 큼직하게 펼쳐진다. 반면 우리 가게는 파란 제목 한 줄과 회색 설명문이 전부다. 손님의 눈길이 어디로 향할지는 굳이 따져볼 것도 없다. 이 차이는 광고비를 더 쓴 결과가 아니라, 검색엔진이 페이지를 사람처럼 읽지 못한다는 사실에서 출발한다. 화면 속 '02-1234-5678'이 전화번호인지 가격인지 기계는 알 수 없다. 그래서 '이건 전화번호, 이건 영업시간'이라고 따로 알려주는 표식이 필요한데, 그것이 바로 구조화 데이터(structured data)다.
1. 검색엔진이 읽는 '숨은 설명표'를 먼저 이해한다
구조화 데이터는 손님 눈에는 보이지 않지만 검색엔진만 읽는 일종의 설명표다. 상호, 주소, 전화번호, 영업시간 같은 정보를 검색엔진이 알아듣는 약속된 형식으로 정리해 두면, 검색 결과에 별점·위치·영업시간이 함께 노출되는 리치 결과(rich result)로 보상받는다. 표준은 전 세계 검색엔진이 함께 쓰는 Schema.org 어휘를 따른다. 거창한 기술이 아니라, 이미 화면에 있는 정보에 '이름표'를 붙이는 작업이라고 생각하면 된다.
2. 화면이 아닌 코드에 JSON-LD로 심는다
구조화 데이터를 넣는 방법은 여러 가지지만, 구글이 공식적으로 권장하는 방식은 JSON-LD다. 본문 디자인을 건드리지 않고 페이지 안에 작은 스크립트 한 덩어리로 따로 심을 수 있어 유지보수가 쉽기 때문이다. HTML 태그 사이사이에 표식을 끼워 넣는 옛 방식과 달리, 정보를 한 곳에 모아두니 나중에 영업시간이 바뀌어도 한 군데만 고치면 된다. 작은 회사일수록 '고치기 쉬운 구조'가 곧 비용 절감이다.
3. 업종에 맞는 타입을 정확히 고른다
Schema.org에는 수백 가지 타입이 있지만 작은 회사가 챙길 것은 많지 않다. 오프라인 매장이라면 LocalBusiness(지역 비즈니스)를 기본으로 삼고, 식당은 Restaurant, 상점은 Store, 변호사·세무사 같은 전문 서비스는 ProfessionalService처럼 더 구체적인 타입으로 좁히면 된다. 블로그 글에는 Article, 자주 묻는 질문 영역에는 FAQPage를 더할 수 있다. 타입이 구체적일수록 검색엔진이 페이지의 정체를 또렷하게 파악한다.
4. 화면에 보이는 정보와 반드시 일치시킨다
가장 흔한 실수는 구조화 데이터에는 '연중무휴'라고 적어 두고 정작 화면에는 '일요일 휴무'가 떠 있는 식의 불일치다. 검색엔진은 숨은 표식과 실제 화면이 어긋나면 신뢰할 수 없는 정보로 보고 리치 결과에서 제외하거나, 반복되면 불이익을 준다. 표식은 어디까지나 화면에 실제로 존재하는 정보를 설명하는 보조 수단이어야 한다. 보이지 않는 곳에만 별점을 채워 넣는 식의 꼼수도 금물이다.
5. 발행 후 테스트 도구로 반드시 검증한다
구조화 데이터는 눈에 보이지 않으니 '넣었다고 믿는 것'과 '제대로 작동하는 것'은 전혀 다르다. 발행 직후 구글의 리치 결과 테스트나 스키마 검사기에 주소를 넣어 오류와 경고를 확인하는 습관을 들이자. 검색 결과에 실제로 반영되기까지는 며칠에서 몇 주가 걸리므로, 한 번 심어두고 검색 콘솔에서 노출 변화를 천천히 지켜보면 된다.
보이지 않는 한 줄이 만드는 차이
구조화 데이터는 디자인을 화려하게 바꾸지도, 글을 더하지도 않는다. 다만 검색엔진에게 우리 가게를 또렷하게 소개해, 같은 검색 결과 안에서 손님의 눈에 먼저 들어오게 만든다. 코드 몇 줄의 차이가 클릭률을 가르는 셈이다. CYAN은 작은 회사 웹사이트를 만들 때 화면에 보이는 디자인만큼이나 이런 '보이지 않는 기초'를 함께 챙긴다. 검색 결과에서 우리 가게가 옆집보다 흐릿하게 보인다면, 한 번쯤 페이지의 숨은 설명표부터 들여다볼 때다.