결론부터 말씀드리겠습니다. 이제 FAQPage 스키마로 Google의 FAQ 리치 결과를 얻기는 거의 어렵습니다. Google은 2023년 팔월부터 펼쳐 볼 수 있는 Q&A 스니펫을 축소하고 정부 및 의료·건강 웹사이트에만 제한적으로 제공하기로 했습니다. 하지만 같은 마크업은 AI 엔진에서 더 큰 가치를 발휘합니다. 답변을 ChatGPT, Perplexity, Google AI Overviews가 직접 추출하고 그대로 인용할 수 있는 단위로 나눠 주기 때문입니다. 이 글에서는 보기 좋은 마크업이 아니라, 실제로 올바르게 구현하는 방법을 설명합니다.
FAQPage 스키마로 마크업할 수 있는 콘텐츠와 없는 콘텐츠
FAQPage는 schema.org에서 정의한 유형입니다. JSON-LD로 페이지에 삽입해, 이 페이지에 자주 묻는 질문 모음이 있으며 각 질문에는 웹사이트가 제공하는 공식 답변이 하나씩 있다는 사실을 기계에 알립니다. 가장 자주 놓치는 제한은 사용자 댓글이나 여러 사람이 참여한 토론에서 나온 답변에는 사용할 수 없다는 점입니다. 그런 콘텐츠는 QAPage의 범위에 해당합니다. 포럼처럼 하나의 질문에 여러 답변이 달리는 콘텐츠를 FAQPage로 마크업하면 Google은 리치 결과 대상이 아닌 것으로 판단합니다. AI 엔진 역시 서로 충돌하는 답변을 읽게 되어 인용 품질이 떨어질 수 있습니다. 구분법은 간단합니다. 사이트가 공식적으로 확정한 문답이라면 FAQPage를, 다른 사용자가 답변할 수 있다면 QAPage를 사용하세요. 유형이 잘못되면 마크업이 아무리 깔끔해도 엔진이 받아들이지 않습니다.
올바른 JSON-LD 중첩 구조
정상적인 FAQPage 마크업은 세 단계로만 중첩됩니다. 다음 순서만 기억하면 실수를 줄일 수 있습니다.
- 최상위에는 FAQPage 유형의 객체를 두고, @context로 schema.org를 지정합니다.
- mainEntity는 배열입니다. 각 요소는 Question 유형의 객체이며, 질문 문구는 name 필드에 넣습니다.
- 각 Question 아래에는 Answer 유형의 acceptedAnswer를 둡니다. 실제 답변은 text 필드에 입력하며 기본적인 HTML 태그도 사용할 수 있습니다.
구체적인 예를 들어 보겠습니다. 한 페이지에 자주 묻는 질문을 다섯 개 배치한다면 FAQPage 객체 하나, mainEntity 배열 안의 Question 다섯 개, 그리고 각 Question에 연결된 acceptedAnswer가 필요합니다. 전체 태그는 페이지의 head나 body에 넣을 수 있습니다. 핵심은 마크업이 설명하는 질문과 답변이 실제로 해당 페이지에 표시되어야 한다는 점입니다. 다른 페이지에 있거나 클릭해야만 나타나는 팝업 안에만 있어서는 안 됩니다. 이후에 발생하는 대부분의 오류가 여기에서 시작됩니다.
답변은 추출 가능한 원자형 블록으로 작성해야 합니다
형식이 정확해도 답변이 마케팅 문구처럼 쓰여 있으면 인용되기 어렵습니다. AI 엔진은 질문 하나에 직접적인 답변 하나가 담기고, 40~60단어 길이이며, 첫 문장에 결론이 나오는 원자형 답변을 선호합니다. 고객사의 FAQ를 다듬을 때는 첫 문장에서 예, 아니요, 숫자 또는 명사로 분명히 답하고, 두 번째 문장에서 조건이나 예외를 덧붙인 뒤 마무리합니다. 80단어가 넘는 답변은 일부만 발췌될 때 앞부분만 추출되어 의미가 끊기는 경우가 많습니다. 독자도 AI도 원래 뜻을 온전히 복원하기 어렵습니다. 길게 설명하기보다 짧고 완결된 문장으로 써야 인용될 가능성이 높습니다.
- 첫 문장에서 질문에 바로 답하세요. “여러 요인에 따라 달라집니다”로 시작하지 마세요.
- 문장은 완결된 형태로 작성하세요. AI 엔진은 문장 전체를 떼어 가며, 사람처럼 빠진 맥락을 알아서 보충하지 않습니다.
- 질문 하나에서는 한 가지만 다루세요. 여러 내용을 묻는 복합 질문은 두 질문으로 나눠 각각 마크업합니다.
- 숫자, 단위, 기간을 구체적으로 쓰세요. “약 한 달”보다 “30일 이내”가 명확합니다.
FAQPage 스키마는 검색 순위를 높이는 기법이 아닙니다. 작성한 답변을 기계가 모호함 없이 인용할 수 있는 형식으로 바꾸는 작업입니다. 답변 자체에 근거가 없거나 내용이 성립하지 않는다면 형식이 아무리 깔끔해도 보완할 수 없습니다.
구현할 때 가장 자주 발생하는 다섯 가지 실수
- 한 답변에 너무 많은 내용을 넣습니다. 서너 개의 세부 질문을 같은 acceptedAnswer에 몰아넣으면 추출 과정에서 답변이 어색하게 잘립니다.
- 태그와 페이지 내용이 일치하지 않습니다. 스키마에는 A, 화면에는 B가 표시되면 숨겨진 콘텐츠로 판단될 수 있습니다.
- Q&A가 아닌 콘텐츠를 FAQPage로 마크업합니다. 기능 목록이나 제품 사양을 억지로 질문 형태로 바꾸면 스키마의 사용 목적에 어긋납니다.
- 한 페이지에 여러 FAQPage 그룹을 만듭니다. 페이지마다 FAQPage 객체는 하나만 있어야 하며, 여러 그룹을 두면 서로의 분석을 방해할 수 있습니다.
- 특수문자를 이스케이프 처리하지 않습니다. 답변의 따옴표나 줄바꿈을 잘못 처리하면 JSON-LD 전체의 파싱이 실패해 마크업이 통째로 건너뛰어질 수 있습니다.
게시 전후로 반드시 확인할 항목
- Google 리치 결과 테스트(Rich Results Test)에 URL이나 코드를 입력해 FAQPage가 인식되는지, 오류가 없는지 확인합니다.
- Schema.org Validator로 유형 이름과 필드의 철자가 정확한지 검사합니다.
- 게시 후에는 Search Console의 리치 결과 보고서에서 색인 반영 상태와 경고 발생 여부를 추적합니다.
- 가장 실용적인 방법은 질문의 원문 그대로 ChatGPT나 Perplexity에 물어보고, 작성한 답변 문구가 인용되는지 확인하는 것입니다.
이 마크업의 실질적인 성과는 AI 엔진에서 나옵니다
대부분의 B2B SaaS 웹사이트에서 FAQPage 스키마를 적용해도 Google의 시각적인 FAQ 요약 결과가 다시 나타나지는 않습니다. 먼저 이 사실을 인정해야 합니다. 다만 성과가 발생하는 무대는 달라졌습니다. 사용자가 ChatGPT에서 “이 도구는 SSO를 지원하나요?”라고 물을 때, 긴 글 속에 같은 문장을 묻어 두는 것보다 깔끔하게 마크업하고 원자형 답변으로 작성한 FAQ가 검색되고 그대로 인용되며 브랜드 출처까지 표시될 가능성이 높습니다. AI 가시성 모니터링과 같은 노출 추적이 실제로 확인하는 것도 이것입니다. 블루 링크에서 몇 위에 올랐는지가 아니라, AI 답변에 브랜드가 포함됐는지와 의도한 문장이 인용됐는지가 핵심입니다.
FAQ를 정확히 마크업하고 답변을 추출 가능한 원자형 블록으로 정리하는 작업은 한 번의 구축으로 높은 효과를 기대할 수 있습니다. 진짜 어려운 부분은 어떤 페이지에 적용할지, 어떤 질문을 마크업할 가치가 있는지, 현재 AI 엔진이 자사의 답변을 인용하고 있는지를 판단하는 일입니다. 웹사이트의 부족한 부분을 확인하고 싶다면 /contact에서 30분 GEO 진단을 예약하세요. 실제 FAQ 페이지를 대상으로 추출 테스트를 진행하고, 놓친 지점을 바로 알려드립니다.
