커뮤니티 게시글을 구글에 노출하는 법: DiscussionForumPosting 실전 가이드

커뮤니티에 좋은 글과 댓글이 쌓이는데 왜 Google 검색에서는 평범한 문서처럼만 보일까요? 사람은 화면만 보고도 ‘회원이 쓴 원문과 댓글이 이어지는 토론’임을 알지만, 검색엔진에는 그 관계를 기계가 읽을 수 있는 형태로 알려주는 편이 유리합니다.

한 줄 결론: 회원이 작성한 일반 토론 글에는 DiscussionForumPosting, 질문 하나에 답변이 모이는 페이지에는 QAPage, 운영사가 직접 쓴 칼럼에는 Article을 사용하세요. 스키마를 넣는다고 순위가 자동으로 오르지는 않지만 Google이 온라인 토론을 식별하고 ‘Discussions and forums’ 같은 검색 기능에 활용할 수 있는 기반을 만듭니다.

쉬운 비유: 구조화 데이터는 도서관 책등의 분류표와 같습니다. 책의 내용이 좋아지는 것은 아니지만, 이것이 소설인지 사전인지 토론 기록인지 사서가 더 정확히 이해하게 합니다. 잘못된 분류표를 붙이거나 책 안에 없는 내용을 적으면 오히려 신뢰할 수 없는 표지가 됩니다.

목차

1. DiscussionForumPosting은 무엇인가
2. Article·QAPage와 구분하는 법
3. 필수·권장 속성
4. 게시글과 댓글 JSON-LD 예제
5. 대댓글·페이지 분할·삭제 처리
6. 와플보드 현재 구조에 적용한다면
7. 검증·배포·Search Console 측정
8. 자주 하는 실수와 체크리스트
9. 참고자료

1. DiscussionForumPosting은 무엇인가

Google 공식 문서는 이 마크업을 사람들이 직접 경험과 관점을 함께 나누는 포럼형 사이트를 위한 구조화 데이터라고 설명합니다. 올바르게 추가하면 Google이 웹의 온라인 토론을 더 잘 식별하고 검색의 토론 관련 기능에 사용할 수 있습니다.

여기서 중요한 단어는 ‘사용자 생성 글’입니다. 운영사 직원이 쓴 블로그 글이나 상품 리뷰에 이 타입을 붙이는 것은 Google의 콘텐츠 가이드라인과 맞지 않습니다. 게시판이라는 화면 모양이 아니라 누가 어떤 목적으로 원문을 작성했는지로 판단해야 합니다.

2. Article·QAPage와 어떻게 구분할까

댓글이 있다는 이유만으로 모든 글을 포럼 타입으로 바꾸면 안 됩니다. Google은 운영사나 대리인이 주로 작성한 글에는 DiscussionForumPosting을 사용하지 말라고 명시합니다. 반대로 실제 회원 토론을 모두 Article로만 표시하면 문법상 오류는 아닐 수 있어도 토론 특성을 충분히 설명하지 못합니다.

실제 페이지 6개를 분류해보면

빠른 판정 질문: “이 페이지에서 검색 사용자가 가장 먼저 얻으려는 것은 편집자가 정리한 설명인가, 한 질문의 정답 후보인가, 여러 사람의 관점인가?” 이 답이 각각 Article, QAPage, DiscussionForumPosting을 가르는 출발점입니다.

3. 필수 속성과 권장 속성

Google 검색 기능의 대상이 되려면 원문 게시글에 다음 항목이 필요합니다.

• author와 author.name: 작성자 정보
• datePublished: ISO 8601 형식의 작성 시각
• text, image, video 중 하나: 실제 게시물 내용

댓글도 작성자, 작성 시각, 그리고 텍스트·이미지·영상 중 하나가 필요합니다. 화면에 댓글 전문이 보인다면 마크업에도 전문을 넣어야 합니다. 숨겨진 댓글이나 다른 페이지의 내용을 현재 페이지에 있는 것처럼 넣어서는 안 됩니다.

권장 항목으로는 headline, 게시글의 대표 url, dateModified, comment, commentCount, 이미지, 공유 콘텐츠, 조회·좋아요·댓글 수를 표현하는 interactionStatistic 등이 있습니다. 작성자 프로필이 공개돼 있다면 author.url도 연결할 수 있습니다.

Google의 원칙: 가능한 속성을 전부 채우는 것보다 적더라도 완전하고 정확한 속성을 제공하는 편이 중요합니다.

4. 게시글과 댓글 JSON-LD 예제

다음 예시는 자유게시판 원문 하나와 댓글 두 개가 같은 페이지에 보이는 상황입니다. 값은 설명용이며 실제 페이지의 데이터로 교체해야 합니다.

{
  "@context": "https://schema.org",
  "@type": "DiscussionForumPosting",
  "headline": "새 커뮤니티 오픈 전에 무엇을 준비할까요?",
  "url": "https://example.com/free/open-checklist",
  "datePublished": "2026-08-01T09:00:00+09:00",
  "dateModified": "2026-08-01T10:20:00+09:00",
  "author": {
    "@type": "Person",
    "name": "초보운영자",
    "url": "https://example.com/users/17"
  },
  "text": "다음 주 오픈 전 확인할 항목을 알려주세요.",
  "commentCount": 2,
  "comment": [
    {
      "@type": "Comment",
      "url": "https://example.com/free/open-checklist#comment-31",
      "datePublished": "2026-08-01T09:12:00+09:00",
      "author": { "@type": "Person", "name": "운영경험자" },
      "text": "가입, 신고, 백업 흐름부터 실제 계정으로 시험하세요."
    },
    {
      "@type": "Comment",
      "url": "https://example.com/free/open-checklist#comment-32",
      "datePublished": "2026-08-01T09:25:00+09:00",
      "author": { "@type": "Person", "name": "서버지기" },
      "text": "예상 최대 사용 패턴으로 부하테스트도 진행하세요."
    }
  ],
  "interactionStatistic": {
    "@type": "InteractionCounter",
    "interactionType": "https://schema.org/ViewAction",
    "userInteractionCount": 384
  }
}

보안 주의: 비공개 실명, 이메일, IP 주소처럼 화면에 공개하지 않은 정보를 구조화 데이터에 추가하지 마세요. 마크업은 검색로봇이 읽을 수 있는 공개 정보입니다.

잘못된 예와 수정 방법

Rich Results Test가 문법 오류를 잡지 않았더라도 내용이 화면과 다르거나 타입이 관련 없으면 품질 가이드라인을 위반할 수 있습니다. Google은 이런 경우 리치 결과 자격을 잃거나 구조화 데이터 수동 조치가 발생할 수 있다고 안내합니다. 수동 조치는 리치 결과 자격에 관한 것이며 일반 웹 검색 순위 자체를 직접 낮추는 조치와는 구분됩니다.

5. 대댓글·페이지 분할·삭제 글은 어떻게 처리할까

대댓글

댓글에 다시 답글이 달리는 구조라면 해당 Comment 안에 또 다른 comment를 넣어 트리 관계를 표현할 수 있습니다. 일렬 댓글이라면 모두 원문 게시글의 comment 배열 아래에 화면 순서대로 넣습니다.

여러 페이지로 나뉜 긴 글

Google은 뒤쪽 페이지에서도 원문 게시글을 표시하고 url은 첫 페이지의 대표 URL을 가리키는 방식을 안내합니다. 현재 페이지에 보이는 댓글만 포함하고, canonical과 페이지 이동 구조도 일관되게 유지해야 합니다.

삭제됐지만 대화 맥락상 남겨둔 글

삭제 문구가 화면에 남아 대댓글 맥락을 유지한다면 creativeWorkStatus를 Deleted로 설정할 수 있습니다. 삭제된 원문을 마크업에 몰래 보존하는 뜻은 아닙니다. 화면에서 사라진 개인정보나 본문을 구조화 데이터에 남겨서는 안 됩니다.

AI·자동 작성 콘텐츠

Google 문서는 기계 생성 콘텐츠를 구분할 때 digitalSourceType을 사용할 수 있다고 안내합니다. 학습 모델이 만든 글은 TrainedAlgorithmicMediaDigitalSource, 단순 알고리즘 생성은 AlgorithmicMediaDigitalSource를 검토할 수 있습니다.

6. 일반 커뮤니티에 적용하는 안전한 순서

특정 솔루션의 내부 코드를 그대로 복사하기보다, 어떤 게시판에서도 적용할 수 있는 데이터 흐름부터 정하는 편이 안전합니다.

1. 콘텐츠 분류표 작성: 운영사 글, 일반 토론, Q&A, 상품후기를 구분합니다.
2. 공개 데이터 정의: 제목·본문·작성자 표시명·작성일·댓글·조회수 중 검색로봇에게 제공할 항목을 정합니다.
3. 예외 규칙 결정: 익명, 탈퇴, 삭제, 숨김, 신고 대기, 비밀글, 차단 회원을 어떻게 표시할지 문서화합니다.
4. 템플릿 분기: 페이지 종류별로 Article, QAPage, DiscussionForumPosting 생성기를 나눕니다.
5. 샘플 적용: 오래 안정적으로 노출된 공개 글 5~20개로 먼저 시험합니다.
6. 검증 후 확대: 치명적 오류와 화면 불일치를 해결한 뒤 게시판 단위로 확대합니다.

범용 구현 의사코드

if (page.isPublisherArticle) {
  schema = buildArticle(page)
} else if (page.isSingleQuestion && page.usersCanAnswer) {
  schema = buildQAPage(page)
} else if (page.isUserGeneratedDiscussion) {
  schema = buildDiscussionForumPosting({
    post: page.visiblePost,
    comments: page.visibleComments,
    canonicalUrl: page.threadUrl
  })
}

return renderJsonLd(schema)

위 코드는 특정 제품의 실제 소스가 아니라 분기 원리를 보여주는 예시입니다. 핵심은 visiblePost와 visibleComments처럼 사용자에게 현재 보이는 공개 데이터만 넣는 것입니다.

Google은 포럼처럼 긴 원문과 댓글을 JSON-LD에 반복하지 않도록 Microdata나 RDFa를 권장하지만, JSON-LD도 완전히 지원합니다. 사이트 구조, 렌더링 방식, 유지보수 난이도를 비교해 선택하세요.

7. 검증·배포·Search Console 측정법

1. Rich Results Test: 샘플 URL과 코드를 검사하고 치명적 오류부터 수정합니다.
2. 실제 URL 검사: 로그인 없이 Googlebot이 본문과 댓글을 볼 수 있는지 확인합니다.
3. 소수 페이지 배포: 템플릿 전체가 아니라 대표 글 몇 개부터 적용합니다.
4. URL Inspection: Google이 렌더링한 HTML에서 마크업이 보이는지 확인합니다.
5. 사이트맵과 재크롤링: 변경 URL을 사이트맵에 유지하고 필요한 경우 색인 생성을 요청합니다.
6. Search Console 추적: 유효 항목, 오류, 노출, 클릭, 검색어 변화를 기록합니다.

측정 원칙: Google은 구조화 데이터가 없는 안정적인 페이지 일부를 골라 적용 전후를 비교하고, URL별 Search Console 성과를 몇 달간 기록하는 방식을 안내합니다. 단기 28일 점검은 오류와 초기 방향을 보는 용도이며 효과 판단은 더 긴 관찰이 필요할 수 있습니다.

노출이 늘었다고 모두 스키마 덕분이라고 단정할 수 없고, 변화가 없다고 즉시 제거할 이유도 없습니다. 구조화 데이터는 콘텐츠 품질, 내부링크, 크롤링과 색인을 대신하지 않습니다.

오류가 나왔을 때 순서

1. 필수 속성 누락 같은 치명적 오류부터 수정합니다.
2. 경고는 실제 제공 가능한 데이터인지 판단해 보완합니다.
3. Rich Results Test의 코드 검사와 실제 URL 검사를 둘 다 수행합니다.
4. 배포된 HTML에 데이터가 존재하고 화면 내용과 같은지 확인합니다.
5. Search Console에서 수정 검증을 요청하고 재크롤링 시간을 기다립니다.

8. 자주 하는 실수와 최종 체크리스트

• 운영사가 쓴 블로그 글을 사용자 토론으로 표시하지 않았는가?
• 질문·답변 중심 페이지에 포럼 타입을 억지로 사용하지 않았는가?
• 원문과 댓글 전문이 실제 화면 내용과 일치하는가?
• 작성자명, 작성일, 수정일, 대표 URL이 정확한가?
• 댓글 수와 실제 공개 댓글 수의 의미가 일치하는가?
• 숨김·삭제·비공개·차단 회원의 정보가 노출되지 않는가?
• 페이지가 robots.txt, noindex, 로그인으로 Google에 막혀 있지 않은가?
• Rich Results Test와 실제 URL 검사를 모두 통과했는가?
• 배포 뒤 Search Console 오류와 유효 항목을 정기 점검하는가?

자주 묻는 질문

구조화 데이터를 넣으면 검색 순위가 오르나요?

보장되지 않습니다. Google은 올바른 마크업도 검색 기능 표시를 보장하지 않는다고 명시합니다. 다만 페이지 의미를 명시적으로 설명하고 관련 검색 기능의 대상이 될 기반을 제공합니다.

JSON-LD와 Microdata 중 무엇이 더 좋은가요?

Google의 일반 지침은 유지보수가 쉬운 JSON-LD를 권장합니다. 다만 포럼 문서에서는 긴 원문과 댓글의 중복을 피하기 위해 Microdata나 RDFa를 권장하며 JSON-LD도 완전히 지원한다고 설명합니다. 팀이 정확하게 유지할 수 있는 방식을 고르세요.

댓글이 하나도 없는 글도 사용할 수 있나요?

원문 게시글이 사용자 생성 토론 글이고 필수 속성을 갖췄다면 댓글이 반드시 있어야 한다고 규정되지는 않습니다. 없는 댓글을 만들거나 commentCount를 부풀리면 안 됩니다.

익명 게시글의 작성자는 어떻게 하나요?

페이지에 공개된 표시명만 사용합니다. ‘익명’처럼 화면에 보이는 이름을 넣을 수 있지만 내부 회원 ID, IP, 실명 등 비공개 식별정보를 추가하면 안 됩니다.

리치 결과 테스트에 통과했는데 Search Console에 안 보입니다.

아직 재크롤링·재색인이 되지 않았거나, Google이 해당 검색 기능을 표시하지 않았을 수 있습니다. URL Inspection으로 Google이 실제 마크업을 읽었는지 확인하고 며칠 이상 기다리며 오류 보고서를 점검하세요.

결론: 검색엔진에 ‘토론의 구조’를 설명하세요

DiscussionForumPosting은 상위노출을 보장하는 편법이 아닙니다. 회원이 만든 원문, 작성자, 댓글과 상호작용을 Google이 오해하지 않도록 설명하는 표준 언어입니다. 타입을 정확히 고르고 화면과 동일한 데이터만 제공한 뒤 소수 페이지에서 검증하는 것이 핵심입니다.

와플보드는 게시판, 회원, 댓글, 검색과 관리자 기능을 함께 운영할 수 있습니다. 커뮤니티 구축 기능은 기능 안내, 실제 국내 커뮤니티 흐름은 커뮤니티 순위, 제작 상담은 가격 안내에서 확인할 수 있습니다.

참고자료

• Google Search Central — Discussion forum structured data: 적용 대상, 필수·권장 속성, 댓글·페이지 분할·검증 지침.
• Google Search Central — Q&A structured data: 질문·답변형 페이지의 적용 기준.
• Google Search Central — General structured data guidelines: 화면 내용 일치, 품질 및 기술 가이드라인.
• Google Rich Results Test: 구조화 데이터 코드와 URL 검증 도구.
• Schema.org — DiscussionForumPosting: 타입 정의와 상속 속성.

확인일: 2026년 8월 1일. Google 검색 기능과 지원 속성은 변경될 수 있으므로 실제 적용 시 최신 공식 문서를 다시 확인하세요. 본문은 검색 노출이나 순위를 보장하지 않습니다.