게시판에 아무리 정성껏 답변을 적어둬도 매일 똑같은 내용의 문의 전화가 빗발친다면, 그건 고객의 게으름 탓이 아니라 검색로봇과 소통이 단절된 사이트의 치명적인 결함 때문입니다.
핵심은 검색결과 창에서 곧바로 대답해 버리는 겁니다. 고객이 사이트 내부로 깊숙이 들어와서 게시물을 뒤지게 만들지 마세요. 검색로봇에게 우리가 자주 받는 질문과 명쾌한 해답을 통째로 떠먹여 주는 기술. 그게 바로 자주 묻는 질문(FAQPage) 데이터가 고객의 피로도를 낮추고 트래픽의 질을 높이는 진짜 이유입니다.
매일 울리는 CS 전화벨의 끔찍한 진실
가까운 지인이 맞춤형 원목 가구를 제작하는 공방을 운영합니다. 가구 퀄리티는 참 좋은데, 하루 종일 울려대는 전화 때문에 도무지 작업을 할 수가 없다고 하소연하더군요. 애널리틱스를 같이 들여다보니 상황이 꽤 심각했습니다. 전화 내용의 80%가 "쇼룸 위치가 어디예요?", "배송비는 얼마인가요?", "반품 규정 좀 알려주세요" 같은 아주 기초적인 질문들이었죠.
사실 지인도 바보가 아닙니다. 홈페이지 메인 화면에 아주 크고 예쁜 폰트로 'FAQ 게시판'을 만들어뒀고, 클릭하면 정말 상세한 답변이 나오도록 꽉꽉 채워 놨거든요. 그런데 왜 아무도 그걸 안 읽는 걸까요. 답은 아주 간단합니다. 네이버나 구글 검색결과를 통해 들어온 고객들은 자기가 원하는 답이 10초 안에 눈에 띄지 않으면 게시판 카테고리를 찾아다니는 대신 곧바로 화면을 끄거나 매장으로 전화를 걸어버리기 때문입니다. 진짜 환장할 노릇이죠.
반면에 잘나가는 대형 브랜드나 IT 기업들을 검색해 보세요. 사이트 이름 바로 밑에 질문들이 아코디언처럼 깔끔하게 접혀 있고, 누르면 즉석에서 답변이 주르륵 나옵니다. 지인은 그게 무슨 천문학적인 광고비를 내야만 네이버가 달아주는 VIP 전용 기능인 줄 알았다고 하더라고요. 뭐랄까, 완전한 착각이었습니다. 그건 누구나 검색엔진의 언어 규칙만 지키면 당장 심을 수 있는 공짜 마케팅 도구에 불과했습니다.
schema.org에서 규정한 FAQPage 마크업의 핵심은 아주 명확합니다. 1개의 질문에는 반드시 1개의 답변만 짝지어 구성해야 합니다. 두루뭉술한 안내문이 아니라, 마치 스무고개를 하듯 묻고 답하는 구조를 텍스트 덩어리로 만들어서 로봇의 뇌 구조에 완벽하게 꽂아주는 방식이죠.
복붙으로 끝내는 묻고 답하기 번역 작업
코딩의 'ㅋ' 자도 모르는 지인은 또다시 지레 겁을 먹었습니다. JSON-LD라느니 객체라느니 하는 말들이 외계어처럼 들렸을 테니까요. 하지만 원리를 찬찬히 뜯어보면 생각보다 허무할 정도로 단순한 작업입니다. 빈칸 채우기 게임이죠.
머리 아프게 생각할 것 없이, 아래 형태의 코드를 메모장에 펼쳐놓고 내 사이트의 진짜 질문과 답변으로 내용만 갈아 끼워주면 끝납니다.
"@context": "http://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "공방 쇼룸 주소는 어디인가요?",
"acceptedAnswer": {
"@type": "Answer",
"text": "경기 광주시 오포읍 123-4번지입니다."
}
}
]
· Question (name): 고객이 묻는 질문을 모호하지 않게 아주 구체적이고 명확한 문장으로 적습니다.
· Answer (text): 질문에 대한 직접적인 해답을 적습니다. 주절주절 긴 설명보다는 직관적인 팩트가 생명입니다.
과유불급이 불러온 태그 대참사
이렇게 세팅을 마치고 지인은 아주 신이 나서 며칠 동안 네이버 통합검색 화면만 새로고침을 해댔습니다. 드디어 내 공방 밑에도 멋진 FAQ 스니펫이 뜨겠지 기대하면서요. 하지만 일주일이 넘도록 결과는 처참했습니다. 네, 그래서 망했습니다.
화가 난 지인과 함께 도대체 어느 부분에서 로봇이 뱉어낸 건지 가이드라인을 이 잡듯 뒤져보기 시작했습니다. 그리고 지인이 멋대로 추가해 버린 아주 치명적인 실수를 하나 발견했죠.
네이버의 엄격한 태그 제한: 답변(text) 영역에는 오직 , ,
합니다. 표를 넣겠다고 ,