토론 포럼 스키마 개선

안녕하세요. 현재 Google Search Console에서 이 메시지를 받고 있습니다. 정확히 어떤 의미인지 잘 모르겠습니다. 이 문제에 대해 좀 더 명확한 설명을 받을 수 있을까요? 해결 방법이 있을까요? 또한, 플랫폼에서 여러 테마를 사용해 보았지만 동일한 오류가 계속되고 있음을 말씀드립니다.

안녕하세요, hiccup!

구조화 데이터(Structured Data)는 기본적으로 검색 엔진에 더 많은 맥락을 제공하는 데 도움이 됩니다.

Google 검색에서는 해당 토픽에서 선택 사항인 url 필드를 찾지 못합니다.
validator.schema.org에서 경고 없이도 완벽하게 유효하다는 것을 확인할 수 있습니다.

걱정할 필요가 없습니다.
그럼에도 불구하고, Google 검색에서 이 필드를 강조 표시한다면, Discourse에 이를 추가할 만한 타당한 이유가 될 것입니다.

@Arkshine가 위에서 설명했듯이, 이것은 버그가 아니라 스키마에 선택 필드를 추가하라는 Google의 제안입니다. 확인해 보겠습니다.

다른 스레드에서:

그러므로, 네, "url"은 선택 사항이지만, 여기에는 실제로 존재하는 오류들도 있습니다.

itemprop="url"은 동일한 주제에 속하지만 다른 URL에 있는 여러 Comment 블록을 Google이 결합하는 데 도움이 됩니다.

Google Rich Results Test에서 메타 토픽을 테스트하여 사용자가 보고 있는 오류를 재현해 보았지만, 오류가 보이지 않습니다.

Google에서 오류가 표시되는 해당 토픽의 링크를 제공해 주시겠습니까?

가장 먼저 주목해야 할 점은, 당신이 보여준 링크가 Discussion Forum 스키마를 가지고 있지 않다는 것입니다. 해당 링크에는 “Breadcrumbs” 스키마만 있을 뿐, “Discussion Forum” 스키마는 전혀 없습니다. 이는 링크를 “데스크톱” 모드가 아닌 “스마트폰” 모드로 테스트하고 있기 때문입니다.

https://search.google.com/test/rich-results/result?id=TlLcA6saLMo3BrxbQYnFuw

링크를 데스크톱 테스트로 전환하면 “Discussion Forum” 스키마가 나타나고, “url 필드 누락” 문제가 표시됩니다.

치명적인 오류를 재현하려면, 다음과 같은 긴 스레드를 ?page=2 URL 파라미터와 함께 테스트해야 합니다:

한 가지 짚어둘 점이 있습니다. 제 생각에는 스키마가 스마트폰 모드에서 표시되지 않는 것이 Discourse의 중요한 버그라고 봅니다. 구글은 존재하는 스키마 내의 오류만 플래깅하기 때문에 이를 자동으로 감지하지 못할 것입니다. 그러나 구글의 경우 몇 년 전부터 스마트폰 크롤링 및 색인이 기본 설정으로 되어 있으므로, 스키마가 스마트폰 모드 그리고 데스크톱 모드 모두에서 표시되는 것이 중요합니다.

첫 번째 게시물에서 설명된 문제와 몇 가지 다른 문제가 이 커밋에서 수정되었습니다:

여기의 제안에 대해 @rrit님께 감사드립니다. :+1:

이는 크롤러 보기에서 두 번째 페이지부터 첫 번째 게시물이 포함되지 않기 때문에 발생하는 문제입니다. @sam, 스키마 문제를 해결하기 위해 크롤러 보기의 모든 페이지에 첫 번째 게시물을 포함해야 할까요? :thinking:

아니요, 그렇게 생각하지 않습니다. 콘텐츠 중복은 좋은 결과를 가져오지 못하거든요. 다른 옵션이 있나요?

다른 옵션은 마이크로데이터 스키마를 JSON-LD로 교체하는 것입니다(이는 구글이 권장하는 방식이기도 합니다). 이를 통해 렌더링된 데이터와 구조화된 데이터를 분리할 수 있으며, 모바일에서도 작동하게 됩니다(단이 위에서 지적했듯이).

우리는 이미 solved 플러그인에서 JSON-LD 스키마를 사용하고 있습니다.

네, 이 해결책이 훨씬 더 정확해 보입니다.

후속 페이지에 첫 번째 게시글의 데이터/텍스트를 포함하지 말고, 항상 첫 번째 페이지를 가리키는 itemprop="url"을 추가하세요:

Google structured data for forums and profile pages - #9 by rrit 참고하세요.

예외가 없는 규칙은 없습니다: DiscussionForumPosting의 경우 Google은 JSON-LD가 아닌 Microdata 사용을 권장합니다.

Discussion Forum (DiscussionForumPosting, SocialMediaPosting) Schema Markup | Google Search Central  |  Documentation  |  Google for Developers 를 참고하세요.

기술 가이드라인

  • 일반적인 구조화된 데이터 선호도와 달리, DiscussionForumPosting 마크업은 가능한 경우 Microdata(또는 RDFa)로 제공하도록 권장합니다. 이를 통해 마크업 내에서 큰 텍스트 블록을 중복할 필요가 없기 때문입니다. 그러나 이는 단지 권장 사항일 뿐이며, JSON-LD도 여전히 완전히 지원됩니다.

이것이 이미 meta.discourse.org에 적용되었나요?

github에 남긴 제 댓글을 확인해 주세요:

이 전체 link 태그는 post.is_first_post에 대해서만 정의되어야 합니다. 각 Comment 항목마다 동일한 URL로 반복할 필요가 없습니다.

현재 meta.discourse.org에서는 따옴표가 깨져 있습니다:
<link itemprop=&#39;mainEntityOfPage&#39; href="…">
Schema Markup Validator 를 참조하세요.

네, 이제 최근 커밋에 따라 그렇게 하고 있습니다. 하지만 해당 항목을 추가한 후에도 후속 페이지(?page=2)에서 필수 필드(author, datePublished, text)가 여전히 누락되고 있습니다.

좋은 지적이었습니다! 이 PR에서 수정했습니다:

아, 맞습니다. @rrlevering 님도 여기서 확인해 주셨습니다:

따라서 후속 페이지에서 콘텐츠가 중복되지 않도록 주의하면서 마이크로데이터 스키마를 개선해야 할 것 같습니다.

mainEntityOfPage 속성에 대한 수정 감사합니다.

그리고 meta 태그와 link 태그에 대한 좋은 지적입니다. :+1:
<link itemprop='url' content='<%= @topic_view.absolute_url %>'>

더 나은 방법:
<link itemprop='url' href='<%= @topic_view.absolute_url %>'>

참고:
– 이 링크는 오래되었지만, YouTube는 여전히 <link itemprop='url' href='…'>를 사용하고 있습니다. –
https://stackoverflow.com/questions/17893223/using-the-link-tag-instead-of-the-meta-tag-in-semantic-markup-when-the-value-is/17901758#17901758

“[HTML5에서] URL을 제공하려면, […] [link 태그의 경우] href 속성을 사용하세요”
“meta 요소의 content 속성 값으로 URL을 사용하면, 그것은 URL이 아닌 URL처럼 보이는 문자열(looking like a URL)을 나타냅니다.”


구글이 제공하는 DiscussionForumPosting: 속성 문서를 다시 확인했습니다:

필수 속성:

  • author
  • author.name
  • datePublished
  • text 또는 image 또는 video 중 하나

특별 참고 사항: text 또는 image 또는 video

→ *"포럼의 후속 페이지나 포럼 카테고리 페이지처럼 **외부 url*을 가진 다른 페이지에 게시물을 나타내고 있는 경우, 이것은 필수적이지 않습니다." ←

권장 속성

  • url
  • […]

특별 참고 사항: url

“토론의 정준 URL(canonical URL)입니다. 다중 페이지 스레드인 경우, 이 속성을 첫 번째 페이지 URL로 설정하십시오. 단일 토론인 경우, 보통 현재 URL입니다.”

따라서 다음과 같이 결론을 내립니다:

  • page=2+에서 text를 다시 추가할 필요가 없습니다. (완료)
  • 선택 속성인 url을 추가해야 합니다 - 특히 page=2+에서. (완료)

추가 조사가 필요한 사항:

  • author, author.name, datePublished와 같은 "필수 속성"들이 page=2+에서 정말로 필요한지, 아니면 반복하지 않아도 되는지?
    → validator.schema.org는 page=2+에서 속성이 누락된 것에 대해 경고하지 않습니다. (완료)
    → 이미 구현된 수정 사항이 라이브로 배포된 후 몇 시간 정도 지나면 "Google Search Console → 리포트: 강화(Enhancements) → 토론 포럼(Discussion forum)"에서 새로운 라이브 데이터를 확인하고 기다리기. (TODO)

구조화 데이터: 도구 및 리소스

스키마

schema.org

developers.google.com

검증기(Validators)

schema.org

  • 일반 검증기:
    https://validator.schema.org/
    이것은 구조화 데이터가 스키마 정의와 일치하는지, 그리고 마크업이 HTML/XML 규약을 준수하는지 확인합니다.
    → 검사되는 요구 사항은 Standard™에 따라 꽤 광범위하며 구체적이지 않습니다.
    → 발견된 모든 버그를 수정하는 것을 권장합니다.

Google Search Console

  • 리포트: 강화(Enhancements) → 토론 포럼(Discussion forum):
    https://search.google.com/search-console/r/discussion-forum?hl=en
    이것은 Google 크롤러에 의해 처리된 정보에 대한 직접적인 피드백을 제공합니다.
    → 이 리포트는 구글 SEO에 대해 어느 정도 구속력이 있는 단단한 사실입니다: 구글이 무언가가 잘못되었다고 발표하면, 실제로는 그렇지 않더라도 구글도 그것을 잘못되었다고 생각합니다.
    → 무언가가 “무효” 또는 "개선 필요"로 표시되면, 수정에 대해 먼저 생각해 보는 것을 권장합니다. 그리고 알려진 부작용이 없다면, 항상 수정을 구현해야 합니다.

Google: Rich Results Test

  • https://search.google.com/test/rich-results?hl=en
    이것은 시뮬레이션된 피드백만 제공하며, Google 크롤러가 아닙니다.
    제 의견: 사이트 소유자에게 "구조화 데이터에 대해 무언가를 하세요!"라고 말하는 구글 마케팅 도구입니다.
    → 이 도구는 구글에 의해 다소 방치되고 있으며, 구글 자체에서 제공하는 최신 기술 권장 사항과 항상 최신 상태를 유지하지는 않습니다.
    → Rich Results Test는 항상 Google Search Console과 동일한 결과를 제공하지는 않습니다 – 의심스러운 경우: Google Search Console을 더 신뢰하는 것이 좋습니다.

Search Console에 표시되는 현재 검사의 의사코드(pseudocode)를 작성해 보겠습니다. 이 스레드에서 큰 도움이 될 것 같습니다. ShEx나 SHACL을 보내드릴 수도 있지만, 이들은 사람이 읽기 훨씬 어렵습니다.

    if not (IsDeletedContent() OR IsExternalContent())
       then if not ("text" OR "articleBody" OR "sharedContent" OR "image" or "video")
         then report(OneOfThreeRequired("text", "image", "video"))
    if not ("author")
       then Report(Required("author"))
    if not("datePublished")
       then Report(Required("datePublished"))

핵심 아이디어는 DiscussionForumPosting/OP(첫 번째 게시글)의 콘텐츠가 현재 페이지에 있는 경우, 어떤 형태로든 콘텐츠 필드가 있어야 한다는 것입니다.

DiscussionForumPosting이 다른 페이지(예: 여러 페이지로 나뉜 콘텐츠의 원본 페이지)의 콘텐츠를 참조하는 경우, 스터브(stub)만 가지고 있으면 됩니다. 스터브에는 아무 내용(예: OP 주제 제목)이 들어가도 되며, 첫 번째 페이지 URL을 참조하면 됩니다. 이것이 IsExternalContent() 검사인데, 단순히 url != page URL인지 확인하는 것입니다.

문서의 두 번째 예시는 정확히 이 경우를 모델링하는 것이었습니다(14번째 페이지가 첫 번째 페이지의 스터브 게시글을 참조하는 경우).

author와 date는 현재 우리의 검증 규칙에서 무조건 필수입니다. 이는 주로 이 데이터를 찾기 위해 추가적인 홉(hop)을 방지하기 위함입니다. OP의 날짜를 알면 댓글이 얼마나 오래되었는지 이해하는 데 유용할 수 있다는 점을 생각해 볼 수 있습니다. 해당 데이터를 포함하는 메타 요소를 단순히 추가할 수는 없나요? 중복 데이터로 인해 페이지가 부풀어 오르는 문제에 대해서는 해당 필드에 대해 크게 걱정하지 않았습니다.

컨텍스트와 팁을 알려주셔서 감사합니다, Ryan!

완료했습니다. 이후 페이지(2페이지부터)의 메타데이터는 이제 잘 보입니다!

기본 robots.txt에 의해 경로가 차단된 상태에서 author URL을 추가하는 것이 여전히 의미가 있을까요? 이제 해당 URL을 홍보하고 있으므로, robots.txt에서 차단 설정을 제거해야 할까요?