$ cd /blog

검색 결과에 FAQ·별점을 띄우는 법 — 구조화 데이터(JSON-LD) 실전 (60페이지 적용기)

구글·빙 검색 결과에 FAQ 펼침과 앱 정보가 리치 스니펫으로 뜨는 원리를 정리하고, 실제 도구 사이트 60페이지에 JSON-LD 3종을 적용하며 배운 핵심 원칙을 공유합니다.


안녕하세요. Jay입니다!

검색하다 보면 어떤 결과는 그냥 파란 제목 한 줄인데, 어떤 결과는 별점이 붙어 있거나 자주 묻는 질문(FAQ)이 펼쳐지고 단계별 안내가 미리 보이죠. "저건 어떻게 하는 거지?" 궁금하셨던 적 있으실 겁니다. 오늘은 그 정체인 구조화 데이터(JSON-LD) 가 무엇인지, 그리고 제가 직접 운영하는 도구 사이트60개 페이지에 적용하며 배운 것을 정리해 보겠습니다.

🔍 구조화 데이터가 뭔가요

검색 엔진은 사람처럼 화면을 "보는" 게 아니라 HTML을 읽어서 이 페이지가 무슨 내용인지 추측합니다. 이때 "이 페이지는 앱이고, 이런 FAQ가 있고, 사용법은 이 순서예요"라고 기계가 읽을 수 있는 형식으로 명시해 주는 게 구조화 데이터입니다.

표기 방법은 여러 가지지만, 구글이 공식적으로 권장하는 방식이 JSON-LD입니다. HTML 본문을 건드리지 않고 <script type="application/ld+json"> 태그 안에 JSON으로 정보를 넣어두면 되기 때문에, 마크업과 분리돼 관리가 편합니다.

이게 잘 심어지면 검색 결과가 단순 링크에서 리치 스니펫(rich snippet) 으로 승격됩니다. FAQ가 접었다 펴지고, 별점·가격·단계가 미리 노출되니 클릭률이 올라가는 효과가 있습니다.

🛠 제가 쓴 3종 스키마 조합

도구 페이지 하나에 저는 세 가지 스키마를 결합해 넣었습니다. 각자 노리는 검색 노출이 다릅니다.

  • SoftwareApplication — "이 페이지는 웹 앱/도구다"라고 알려줍니다. 앱 이름·카테고리·요금(무료) 정보를 담습니다.
  • FAQPage — 자주 묻는 질문 6개를 질문·답변 쌍으로 넣습니다. 검색 결과에서 FAQ가 펼쳐지는 그 부분입니다.
  • HowTo — "이 도구를 이렇게 쓰세요"를 단계별로 넣습니다. 사용법이 번호 스텝 미리보기로 노출될 수 있습니다.

세 개를 각각 심어도 되지만, 저는 배열로 묶어 한 번에 emit하도록 헬퍼 함수(combineJsonLd)를 만들어 페이지마다 재사용했습니다. 60페이지 × 3종을 손으로 관리하면 반드시 어긋나거든요.

⚠️ 가장 중요한 원칙 — 화면과 스키마가 일치해야 한다

여기서 제가 가장 강조하고 싶은 게 있습니다. JSON-LD에만 FAQ를 넣고 화면에는 안 보여주면, 오히려 위반입니다.

구글과 빙 모두 "구조화 데이터에 담은 내용은 실제 페이지에도 사용자가 볼 수 있어야 한다"는 정책을 둡니다. FAQ 스키마에 질문 6개를 넣었다면, 화면에도 그 6개 Q&A가 그대로 렌더링돼 있어야 합니다. 안 그러면 리치 스니펫을 안 주거나, 심하면 스팸으로 판단합니다.

그래서 저는 스키마용 데이터와 화면용 FAQ를 같은 소스에서 뽑아 쓰도록 만들었습니다. 하나만 고쳐도 둘이 자동으로 맞춰지니, 사람이 실수로 어긋나게 둘 일이 없습니다.

📈 60페이지에 적용하며 배운 것

3페이지에 먼저 적용해 보고 전체 60페이지로 확대했는데, 대량 적용에서 얻은 교훈이 몇 가지 있습니다.

① 공통 컴포넌트로 반복을 없애라 — 처음엔 페이지마다 FAQ를 손으로 그렸는데, 곧 공통 FaqList 컴포넌트를 만들어 데이터만 넘기는 방식으로 바꿨습니다. 60페이지에 같은 UI를 붙일 땐 복붙이 아니라 컴포넌트화가 답입니다.

② 카테고리(타입) 일치성을 점검하라 — 유틸리티 도구인데 스키마 카테고리를 GameApplication으로 잘못 넣어둔 페이지들이 있었습니다. 검색 의도와 어긋나면 오히려 손해라, UtilityApplication으로 바로잡았습니다.

③ 키워드 변형을 본문에 자연스럽게 녹여라 — "팀 짜기 / 팀 나누기 / 조 편성 / 순서 정하기"처럼 사람들이 실제로 검색하는 표현은 조금씩 다릅니다. FAQ 질문과 H2에 이런 변형을 자연스럽게 넣으면 매칭 범위가 넓어집니다. (단, 억지로 나열하면 스팸이니 문장 안에 녹이는 게 핵심입니다.)

결과적으로 60페이지에서 수백 개의 FAQ와 HowTo 단계가 JSON-LD로 방출됐고, 검색 엔진이 재크롤링하며 리치 스니펫 후보로 반영되기 시작했습니다.

🤔 주의할 점 · 안 맞는 경우

솔직하게 한계도 적어둡니다. 구조화 데이터는 랭킹(순위) 자체를 올려주는 마법이 아닙니다. 같은 순위에서 검색 결과를 더 눈에 띄게 만들어 클릭을 유도하는 장치에 가깝습니다. 도메인 신뢰도나 콘텐츠 품질이 낮으면 스키마만으로 상위 노출되지는 않습니다.

또 리치 스니펫은 넣는다고 100% 노출되는 게 아닙니다. 구글이 페이지·검색어 상황을 보고 표시 여부를 판단하니, "적용했는데 안 뜬다"고 바로 되돌리지 말고 시간을 두고 지켜봐야 합니다. 적용 후엔 구글 서치 콘솔의 리치 결과 테스트로 스키마가 유효하게 인식되는지 꼭 확인하세요.

결론

구조화 데이터의 핵심은 "화면에 있는 것을, 기계가 읽게 한 번 더 명시하는 것"입니다.

JSON-LD로 SoftwareApplication·FAQPage·HowTo를 결합하고, 무엇보다 화면과 스키마를 일치시키세요. 페이지가 많다면 공통 컴포넌트와 헬퍼 함수로 반복을 없애는 게 대량 적용의 관건입니다. 다음에도 유익한 포스팅으로 찾아오겠습니다. 감사합니다!

📚 참고 / 출처

#JSON-LD#구조화데이터#SEO#리치스니펫#schema.org

$ ls related/

더 많은 IT·AI 활용법이 궁금하다면?

매주 새로운 실전 가이드가 업데이트됩니다.

전체 글 보기