맞습니다. 제 경우에도 모든 토론이 구글에 의해 재작성된 후 검색 결과에서 사라졌습니다.
저도 잘 모르겠습니다. 현재 제 사이트에서는 다음과 같은 메시지가 표시됩니다:
“이 장치 유형에 대해 지난 90일 동안 사용 데이터가 부족합니다.”
새로운 콘텐츠와 업데이트된 토론이 항상 있음에도 불구하고 하락세는 계속되고 있습니다.
오류는 보고되지 않지만, 분명히 뭔가 문제가 생긴 것 같습니다!
2개의 좋아요
최신 버전의 Discourse를 사용하고 계신가요?
3개의 좋아요
현재 2.8.0.beta11이 설치되어 있으며, 2.9.0.beta4를 설치해야 하는 것으로 보입니다.
3개의 좋아요
.beta6가 나왔네.. 업그레이드해야겠다! 
2개의 좋아요
플러그인을 이용해 사이트맵을 만든 적은 없었는데, 이제 네이티브로 지원되고 최신 버전에서 여러 가지 수정 사항이 적용된 지 약 한 달 정도 지났더니 색인 처리에 눈에 띄는 변화가 있었습니다. 일부는 거의 즉시 색인 처리가 되었죠. 트래픽 증가에 도움이 되는지는 확신할 수 없지만, 색인 활동이 활발해진 것은 분명 환영할 만한 일입니다.
2개의 좋아요
매우 초기 2.x 버전에서 최신 2.9로 업그레이드한 이후 현재 커버리지는 다음과 같습니다. 이 상승 곡선이 시작되기까지 약 12일이 걸렸습니다. "2"는 최신 버전이 적용된 대략적인 시점을 나타냅니다.
과거의 추세는 유효한 링크의 색인이 감소하는 것이었으나, 이제 그 추세가 반전되어 전반적으로 색인 활동이 증가하는 효과가 나타나고 있습니다.
유효한 링크가 순증으로 약 15K 증가했습니다.
위 그래프에서 완전히 명확하지는 않지만, 업그레이드 직후 무효한 링크가 약간 증가했으나 이후 다시 감소하는 추세로 돌아섰습니다.
재디렉션으로 인해 무효 처리된 페이지가 무효 그룹 중 가장 크고 주요한 부분이었는데, 지난 1개월 동안은 느리지만 감소하는 추세를 보이고 있습니다.
크롤링은 줄고, 이제 더 많은 페이지가 사이트맵을 통해 직접 소싱되고 있습니다. 사이트맵 적용 전후의 매우 명확한 효과를 볼 수 있습니다:
또 다른 전후 비교로, 브레드크럼(그리고 사이트링크도 비슷한 채택률을 보였습니다)입니다.
솔직히 말해, 버전이 크게 뛰어넘은 점과 몇 가지 오류(foyers) 이후 사이트맵이 없었던 상태에서 사이트맵을 갖춘 상태로 전환된 점을 고려하여, 모든 것이 어떻게 전개될지 확인하기 위해 최소 3개월은 더 시간을 주려고 합니다. 그 사이 업그레이드 진행에 맞춰 발을 맞춰가 보겠습니다.
여기서도 눈에 띄는 개선이 있습니다. 잠시 이상한 현상이 있었지만, 현재 상태는 전반적으로 더 많은 핵심 웹 메트릭(vitals)에서 개선된 것으로 보입니다:
PG13 DB와 Discourse 코드베이스에 따른 프로그램matic한 개선 위에 속도에 도움이 될 수 있는 유일한 기술적 개선 사항은 HD가 NVMe인 점과 매우 최신 버전의 Docker를 사용하고 있다는 것입니다. 전반적인 성능과 속도 테스트(구글 페이지스피드 사용)가 매우 좋아졌음을 확실히 체감하고 있습니다.
전반적으로 구글 콘솔의 부정적 추세에 대한 일반적인 우려 사항들은 2.9.beta4-6 버전에서 느리지만 반전되는 양상을 보이고 있습니다.
4개의 좋아요
또한 최근에 추가된
이 도움이 될 것입니다 
6개의 좋아요
구글 페이지에서 검색어 링크를 클릭한 사람이 우리가 분석하고 있는 디스커스(Discourse) 포럼의 토론에서 원하는 것을 찾지 못했을 가능성이 큽니다 
무엇이 바뀌었는지 모르겠어요. 업데이트 때문일 수도 있지만, 10월 초부터 갑자기 Google이 데스크톱용 GOOD URL을 인덱싱하기 시작했어요.
Discovery가 갑자기 10월 1일부터 3일 사이에 시작되었고, 10월 25일前后的 곡선의 급격한 상승은 위의 플립과 일치해요. 이게 Google이 제대로 보고 있는 건지, 아니면 인덱싱 가능성을 개선하는 업데이트 때문인지는 모르겠어요.
모바일에서는 여전히 인덱싱이 안 돼요.
이 배포는 완전히 최신 버전(2.9.0.beta10 [f7a4fd1f49])과 몇 개의 커밋 차이밖에 안 나요.
1개의 좋아요
그렇지 않습니다. Poor URLs은 인덱싱이 되지 않는 것과 전혀 다른 문제입니다.
1개의 좋아요
이런 일이 일어났습니다: Discourse Splash 소개 - 사이트 자산이 로드되는 동안 표시되는 시각적 프리로더
좋은 지적입니다. @agemo 님은 "인덱싱"과 구글의 “좋음/보통/나쁨” Web Vitals 점수를 혼용하고 있는데, 이는 절대 같은 것이 아닙니다. 후자가 랭킹에 영향을 미칠 수는 있지만요.
3개의 좋아요
그 점을 교조적으로 지적해 주시니 재미있네요. 그리고 그것은 기술적인 문제이지만, 실질적인 전체적인 요지를 놓치고 있습니다. 왜냐하면 언어 문제가 실제로는 제가 게시하지 않은 인덱싱 활동 증가와 일치하기 때문입니다. 그러므로 저는 인덱싱 서비스에서 파생된 모든 것이므로, 파생된 문제에 대해 장황하게 서술하고 있는 셈입니다…
1개의 좋아요
음, 그건 이해가 안 되는데 7월쯤이었고, 위 스크린샷에서 보듯 Google이 좋은 URL을 인식하기까지 3개월이 걸렸거든요. 이 배포는 초기 출시 며칠 안에 스플래시 화면 커밋이 있었기 때문에 더 빨리 반영되길 바랐습니다.
제가 배너용( CSS/HTML)으로 사용하던 아주 단순하지만 오래된 커스텀 모드를 제거하고 대신 versatile banner 컴포넌트를 사용하도록 되돌린 것이 문제의 원인이었던 것 같습니다. 다만 10월 초에 좋은 URL이 나타나는 현상은 설명하지 못하지만, 10월의 급증은 설명할 수 있을 것 같습니다.
저는 CLS 문제를 줄이려는 것이 목표였고, 그래서 페이지가 더 잘 렌더링되고 표시되는 것 같습니다. 어쩌면 더 근본적인 문제를 해결한 것일지도 모릅니다. 기억이 맞다면 versatile banner는 모바일 뷰에서는 사용되지 않는다고 합니다.
1개의 좋아요
또 다른 한 가지, 그리고 처음부터 다시 자세히 살펴보기 시작한 이유는, 인덱싱되지 않은 페이지의 발견 수가 증가하기 시작한 것과 동시에 인덱싱 수가 감소하기 시작했다는 점입니다. 음… 이 모든 것이 마치 동시에 시작되는 것처럼 10월 마지막 주경에 걸쳐 일어난 일이었죠.
인덱싱되지 않은 페이지/404 오류를 살펴본 결과, 최근 인덱싱되지 않은 페이지 수 증가의 주요 원인으로 보이며, 현재 약 10,000개에 육박하고 있습니다. 예를 들어 다음과 같이 나타납니다:
Login | HSTS Redirection Community
Login | HSTS Redirection Community
?page=123 부분을 제거하면 URL이 올바르게 해석되므로 페이지는 존재합니다. 구글은 어디서 이런 잘못된 링크 형식을 가져오고 있는 걸까요? 
phpBB 가져오기 오류나 기타 영구 링크(퍼머링크) 유물/잘못된 설정, 또는 다른 어떤 문제 때문인 것 같다고 생각했습니다.
2개의 좋아요
데스크톱의 페이지 경험은 정상적으로 작동하고 있고, 검색 콘솔에서도 통계가 나오고 있습니다.
하지만 모바일의 페이지 경험은 전혀, 정말로, 노출이 0건입니다.
무슨 일이 일어나고 있는 건가요?
1개의 좋아요
저도 같은 상황입니다. 9월부터 시작되었고, 저는 아무런 변경 사항도 적용하지 않았으며 플러그인을 설치한 적도 없습니다.
필요할 때만 Discourse를 업데이트했을 뿐입니다.
원인은 CLS 문제라고 생각합니다.
AdSense 배너와 플로팅 Google GDPR 동의 배너를 모두 삭제했지만, 오랜 시간이 지나도 아무런 변화가 없습니다.
1개의 좋아요
CLS는 검색 결과와 전혀 무관합니다.
정말 이해가 안 됩니다. 검색 결과와 아무런 관련이 없는 완전히 부차적인 지표들을 왜 보는 건가요?
1개의 좋아요
이 링크(Google May 4th Core Update impact on Discourse forums)와 같은 메타 사이트에서 코어 웹 바이탈(Core Web Vitals)이 구글 검색 랭킹에 미치는 영향에 대해 논의하는 글들이 있습니다. 로딩 스플래시 스크린(Introducing Discourse Splash - A visual preloader displayed while site assets load)을 도입한 주된 이유는 Discourse 사이트 초기 로드 시 FCP(First Contentful Paint) 측정치가 좋지 않았기 때문이었습니다(이 업데이트를 위해 Discourse 팀에게 감사드립니다).
검색 랭킹에 관한 많은 부분은 불분명하지만, CLS(Cumulative Layout Shift)와 같은 바이탈이 실제로 중요하다는 점은 분명해 보입니다. 저는 같은 주제 안에서 이전에 CLS 문제를 겪었으나(Sudden drop in traffic - #35 by piffy) 이후 이를 수정했습니다.
기본적인 Discourse 사이트에는 CLS 문제가 나타나지 않는 것 같습니다. 메타 사이트에서도 이를 확인할 수 있습니다(https://pagespeed.web.dev/report?url=https%3A%2F%2Fmeta.discourse.org%2F). 이 PageSpeed 사이트는 사이트의 실제 사용자 통계를 보여주는 데 유용하지만, 웹사이트의 크롤러 버전을 사용하기 때문에 라이브 뷰로 사이트를 분석하는 “성능 문제 진단” 섹션은 유용하지 않습니다. 저는 CLS 문제를 조사할 때 이 사이트(https://gtmetrix.com/)가 유용하다는 것을 발견했습니다.
여기서도 메타 사이트에는 CLS 문제가 없다고 표시됩니다.
제 문제는 모든 페이지 상단에 표시되도록 작성한 커스텀 배너 플러그인이었는데, 높이를 미리 지정하지 않아 일관된 레이프트 시프트(레이아웃 이동)가 발생했습니다(너무 빠르게 일어나서 눈으로 알아채기 어려울 정도였지만요). 저는 이미지를 가져오기 전에 브라우저가 높이를 수용할 수 있도록 높이를 미리 지정하는 방식으로 이를 해결했습니다.
제가 얻은 통찰 중 하나는 수정 사항이 반영되는 데 매우 오랜 시간이 걸린다는 것입니다. 이는 실제 사용자 방문을 통해 수집된 통계에 기반하기 때문입니다. 제 경우에도 1개월 이상 걸렸습니다. 검색 콘솔에서 “수정 사항 검증” 옵션을 사용할 수 있으며, 28일 이내에 알림을 받을 수 있습니다. 수정 사항을 테스트하고 피드백을 받는 사이에 약 1개월의 공백이 있다는 점은 다소 답답합니다.
어쨌든, 이 정보가 도움이 될지는 모르겠지만 제 경험을 공유해 보았습니다.
6개의 좋아요