[2026 최신] 스키마 마크업을 통한FAQ 페이지 구조화 데이터 구현 방법 완벽 가이드 | 테라그로스

FAQ 스키마 이거, 솔직히 몇 년 사이에 위상이 확 바뀐 영역이에요. 2022년만 해도 블로그 글 하나에 FAQPage 마크업 박아두면 검색 결과에 아코디언 형태로 질문-답변이 쫙 펼쳐지면서 클릭 영역을 두세 배로 키울 수 있었거든요. 근데 지금은 사정이 많이 달라졌습니다. 우리가 여러 계정 굴리면서 직접 데이터로 확인한 변화를, 2026년 기준으로 처음부터 끝까지 정리해볼게요.

FAQ 스키마, 2026년엔 뭐가 달라졌나

먼저 가장 중요한 팩트부터 짚고 갈게요. 과거에는 어떤 사이트든 FAQPage 마크업만 제대로 넣으면 검색 결과에 리치 스니펫이 떴습니다. 근데 구글이 2023년 8월에 FAQ 리치 결과 노출 범위를 대폭 축소했어요. 지금 2026년 기준으로도 그 정책이 유지되고 있고, FAQ 리치 결과는 공신력 있는 정부 사이트와 의료/보건 관련 사이트에만 제한적으로 표시됩니다.

이 사실을 모르고 일반 기업 블로그에 FAQPage 스키마 잔뜩 박아놓고 “왜 리치 스니펫 안 떠요” 하고 문의 주시는 분들이 아직도 많아요. 우리가 운영하는 일반 상업 도메인 계정들에서도 FAQ 마크업은 검증은 통과하지만 SERP에 아코디언 형태로 노출되진 않습니다. 그게 정상이에요. 버그 아닙니다.

그럼 일반 사이트는 FAQ 스키마를 아예 버려야 하느냐. 그건 또 아니에요. 노출 방식이 바뀌었을 뿐, 마크업 자체의 가치는 오히려 다른 방향으로 커졌습니다. 이 부분이 2026년 SEO의 핵심 변화라서 뒤에서 따로 다룰게요.

구조화 데이터가 뭔지부터 – 5분 정리

구조화 데이터(structured data)는 쉽게 말해 페이지 내용을 검색엔진이 기계적으로 읽을 수 있게 라벨을 붙여주는 작업이에요. 사람 눈엔 그냥 “질문 – 답변”으로 보이지만, 크롤러는 이게 질문인지 답변인지 가격인지 평점인지 구분을 못 합니다. 그걸 schema.org 어휘로 명시해주는 거죠.

형식은 세 가지가 있는데 – JSON-LD, Microdata, RDFa. 구글이 공식 문서(support.google.com/google/aio 및 search 도움말)에서 명확하게 권장하는 건 JSON-LD예요. 우리도 신규 작업할 땐 무조건 JSON-LD로 갑니다. HTML 본문과 분리돼 있어서 디자인 건드릴 일도 없고, 유지보수가 압도적으로 편해요. 옛날 사이트들이 Microdata로 본문 태그마다 itemprop 박아놓은 거 보면 솔직히 한숨부터 나옵니다.

FAQPage 스키마는 그중에서도 구조가 단순한 편이에요. 최상위에 FAQPage 타입을 두고, 그 안에 Question 타입 여러 개를 배열로 넣고, 각 Question 안에 acceptedAnswer로 Answer를 물려주는 식입니다. 중첩이 깊지 않아서 입문용으로도 좋아요. 근데 단순하다고 대충 넣으면 검증에서 잘 터집니다. 그 얘긴 잠시 후에.

FAQPage 스키마 실제 코드로 구현하기

말로만 하면 와닿지 않으니까 바로 코드로 갈게요. 아래가 우리가 실제 현장에서 쓰는 표준 FAQPage JSON-LD 골격이에요. 페이지 head나 body 어디든 script 태그로 넣으면 됩니다.

구현할 때 반드시 지켜야 하는 규칙 몇 가지를 우리 경험으로 정리하면 이렇습니다. 첫째, 마크업에 넣은 질문과 답변은 페이지에 사용자가 실제로 볼 수 있는 형태로 똑같이 존재해야 해요. 화면엔 없는데 스키마에만 박힌 숨겨진 콘텐츠, 이거 구글이 스팸으로 봅니다. 둘째, answer의 text 안에는 링크 같은 간단한 HTML은 허용되지만 외부 광고나 프로모션 문구를 끼워넣으면 안 돼요. 셋째, 한 도메인 안에서 같은 FAQ를 여러 페이지에 중복으로 마크업하지 마세요.

그리고 인코딩 사고가 의외로 자주 납니다. 따옴표를 한글 큰따옴표로 잘못 넣거나, 답변 안에 영문 큰따옴표를 escape 안 하고 그냥 넣어서 JSON 파싱이 깨지는 경우. 워드프레스에서 비주얼 에디터로 붙여넣다가 따옴표가 자동 변환돼서 통째로 무효 처리된 사례를 우리도 여러 번 겪었어요. JSON-LD는 무조건 텍스트 에디터나 전용 플러그인으로 관리하는 걸 추천합니다.

흔히 터지는 에러와 검증 방법

마크업 넣었으면 검증은 필수예요. 구글 리치 결과 테스트 도구(search.google.com/test/rich-results)랑 스키마 검증기(validator.schema.org) 두 개를 같이 돌립니다. 전자는 “구글이 이걸 리치 결과로 인식하느냐”를 보고, 후자는 “schema.org 문법상 유효하냐”를 봐요. 둘이 보는 관점이 달라서 우리는 항상 병행 검사합니다.

현장에서 제일 자주 마주치는 에러들을 꼽아보면 – acceptedAnswer 누락(Question만 있고 답이 없는 경우), text 필드 비어 있음, mainEntity를 배열이 아니라 객체로 넣은 케이스, 그리고 @type 철자 오류. FAQPage를 FaqPage나 FAQpage로 쓰면 그냥 인식 안 됩니다. 대소문자 정확히 FAQPage예요.

Search Console의 향상 보고서도 꼭 챙기세요. 도구로 단건 검증해서 통과해도, 실제 인덱싱 과정에서 구글이 다르게 판단하는 경우가 있어요. Search Console은 사이트 전체에서 잡힌 구조화 데이터 오류를 누적으로 보여주니까, 배포 후 며칠 지켜보면서 유효 항목 수가 정상적으로 올라가는지 확인하는 게 맞습니다. 근데 앞에서 말했듯 일반 사이트는 FAQ가 향상 보고서에 아예 카테고리로 안 잡힐 수 있어요. 그것도 정상이에요.

AI 검색 시대, FAQ 마크업의 진짜 가치

자 그럼 리치 스니펫도 안 뜨는데 왜 아직도 FAQ 스키마를 넣느냐. 여기가 2026년에 우리가 클라이언트들한테 가장 강조하는 포인트예요. 검색 환경이 통째로 바뀌었거든요.

지금은 구글 AI 개요(AI Overviews)나 생성형 검색이 답변을 직접 만들어서 보여주는 비중이 계속 커지고 있어요. 이런 AI 답변 엔진들은 페이지를 읽을 때 구조화 데이터를 우선적으로 참고합니다. 질문-답변 형태로 명확하게 라벨링된 콘텐츠는 AI가 “이건 명백히 이 질문에 대한 답이다”라고 신뢰하기가 훨씬 쉽거든요. 우리가 관리하는 도메인 중에 FAQ 마크업을 체계적으로 정비한 곳들이 AI 개요 인용 빈도에서 눈에 띄게 앞서가는 패턴을 보고 있어요.

그러니까 FAQ 스키마의 목적이 “SERP 아코디언 노출”에서 “AI 답변 엔진의 신뢰할 만한 출처로 인용되기”로 옮겨간 셈입니다. 노출 채널이 바뀐 거지 가치가 사라진 게 아니에요. 오히려 GEO(생성형 엔진 최적화) 관점에서 보면 FAQ 구조화는 지금이 더 중요해졌습니다.

한 가지 더. FAQ를 잘 정리해두면 페이지 안에서 사용자가 궁금해할 질문을 미리 해소해주니까 체류 시간이랑 만족도 지표도 같이 올라가요. 구조화 데이터는 부수 효과고, 본질은 “사용자가 진짜 묻는 걸 페이지에서 답해준다”는 거예요. 이 순서를 거꾸로 잡으면, 그러니까 스키마 점수 따려고 억지 질문 끼워넣으면, 그건 금방 티 납니다.

우리가 현장에서 정리한 체크리스트

마지막으로 실무에서 바로 쓸 수 있게 우리 내부 체크리스트를 풀어놓을게요. 새 페이지에 FAQ 구조화 데이터 작업할 때 이 순서대로 갑니다.

일단 사용자 의도부터 봐요. 실제 검색어와 문의 데이터에서 자주 나오는 질문 5개 안팎을 뽑습니다. 억지로 10개씩 채우지 마세요. 둘째, 그 질문-답변을 페이지 본문에 사람이 읽을 수 있게 먼저 배치해요. 셋째, 그다음에 JSON-LD를 본문과 1대1로 매칭해서 작성합니다. 넷째, 리치 결과 테스트 + 스키마 검증기로 더블 체크. 다섯째, 배포 후 Search Console 향상 보고서를 며칠 모니터링. 여섯째, AI 개요 인용 여부랑 페이지 체류 지표를 한 달 단위로 추적해서 효과를 봅니다.

이 흐름만 지켜도 어설프게 마크업 박아놓고 “왜 안 돼요” 하는 단계는 확실히 졸업해요. 근데 도메인 유형마다, 업종마다 최적 전략이 또 갈리거든요. 정부·의료가 아닌 일반 상업 사이트라면 FAQ 외에 어떤 구조화 데이터에 힘을 줘야 하는지가 더 중요한 질문일 수 있어요.