토픽 URL 내 각 답글의 /2, /3, /4 링크 제거

아니요, /8은 주제(topic)와 동일하지 않습니다. /8은 8번째 게시물을 가리키며, 타임스탬프도 8번째 게시물의 것과 일치합니다.

?page=2 변형을 실제 링크된 게시물과 비교하면 동일한 타임스탬프를 얻을 수 있습니다.
예를 들어:

wget -q -O - https://meta.discourse.org/t/topic-list-previews-legacy/101646/959|grep published_ti
<meta property="article:published_time" content="2020-05-09T04:29:46+00:00" />
wget -q -O - https://meta.discourse.org/t/topic-list-previews-legacy/101646/?page=2|grep published_ti
<meta property="article:published_time" content="2020-05-09T04:29:46+00:00" />

그렇습니다: Incorrect or failing oneboxes for links to other discourse instances - #14 by techAPJ

시간 정보를 제거하자는 것이 아니라, 상단 게시물에 대해서는 기계 가독성 있는 타임스탬프만 보내는 것이 더 낫다는 것입니다. 검색 결과에서 페이지를 랭킹하는 관점에서 보면, 포럼 토픽은 기본적으로 댓글이 달린 기사(상단 게시물)와 같습니다. 검색 엔진 입장에서는 댓글이 작성된 시점은 중요하지 않습니다.

수정: 댓글(페이지 전체가 아닌)에 대해 Google에 날짜를 전달하는 또 다른 방법은 schema.org 마크업입니다.

물론 /8은 8번째 게시물을 가리킵니다. 하지만 봇과 Google의 관점에서는 내용과 URL이 정확히 동일합니다. Google이 검색 결과에서 /8을 토픽과 정확히 같은 방식으로 취급하도록 하려면, 사이트가 두 페이지가 다르다는 의도적인 신호를 보내서는 안 될 것입니다. 타임스탬프가 다르다는 사실을 알아야 하는 것은 인간 사용자뿐이며, 그 정보는 페이지의 텍스트에 이미 인쇄되어 있습니다.

Google의 누군가가 사이트가 정의한 정준 URL(canonical URL)을 언제 무시할지에 대한 결정을 내려야 한다면, 그 예외 중 하나는 "의도된 메타데이터에 두 개의 서로 다른 타임스탬프가 있으면 다른 페이지라는 의미이므로 정준 URL을 무시한다"는 것일 수 있습니다.

프로그래머에게 모든 엣지 케이스를 생각하는 것은 쉽지 않은데, 이는 해당 상황을 경험해 본 적이 없기 때문입니다. 따라서 동일한 페이지에 두 개의 서로 다른 타임스탬프가 있을 수 있다는 것은 Google 프로그래머들에게는 상상하기 어려울 수 있습니다. 반면 Discourse 사용자에게는 왜 그런 일이 일어날 수 있는지 이해하기 쉽습니다.

저는 과거에 Google에서 사이트의 밴 해제 업무를 담당했던 적이 있습니다. (그들은 어떤 음모를 꾸민 것이 아니라, 단순히 기술적인 문제들이 있었습니다.) Google의 랭킹 기술이 정확히 어떻게 작동하는지 아무도 알지 못했고, 그 기술은 정기적으로 변경되었기 때문에, 시작점은 검색 엔지니어처럼 생각하고 기계에게 모호하거나 혼란을 줄 수 있는 모든 요소를 제거하는 것이었습니다. 정확히 어떤 조치가 효과가 있었는지 말하기는 어려웠지만, 그런 것들을 체계적으로 수정한 후에는 시간이 지나면 항상 효과가 있었습니다.

이 기능이 적용되었습니다. 이 실험적 기능을 활성화하려면 숨겨진 사이트 설정인 SiteSetting.allow_indexing_non_canonical_urls의 값을 변경해야 합니다.

결과를与我们 공유해 주세요.

저에게는 완벽하게 합리적인 의견입니다.

네, 네, 그리고 네. 매우 잘 설명하셨습니다.

참고

현재 구글은 정정 URL을 올바르게 사용하고 있습니다:
구글 검색 콘솔(Google Search Console)의 ‘인덱스’ → ‘커버리지’ → ‘적절한 정정 태그가 있는 대체 페이지’ 보고서를 통해 이를 확인할 수 있습니다.

적절한 정정 태그가 있는 대체 페이지에 대해:
“이 페이지는 구글이 정정(canonical)으로 인식하는 페이지의 중복 페이지입니다. 이 페이지가 정정 페이지를 올바르게 가리키고 있으므로 사용자가 조치할 사항은 없습니다.” :slight_smile:

각 답글에 대한 /X 링크가 SEO에 어떤 영향을 미치는지 정확히 모르겠고, 일반적으로 구글의 변덕에 맞추는 것을 피하려 합니다. 하지만 실용적인 관점에서 보면, 제 디스코urses 포럼의 장기 진행 중인 토픽에서 구글이 새 답글을 잘 인덱싱하지 않는 반면, 대부분의 새 토픽은 빠르게 인덱싱하는 것을 확인했습니다. 그리고 구글이 새 답글을 인덱싱할 때, 해당 링크는 특정 답글로 가지 않고 /XXXX?page=YY로 이동합니다. 이것이 SEO에 좋은지 모르겠지만, 특정 내용을 검색하는 인간 사용자에게는 분명히 좋지 않습니다.

이 토픽이 꽤 오랫동안 조용했습니다. 궁금한 점이 있습니다: 이 실험적 기능을 테스트해 보신 분이 계신가요? 2년이 넘게 지났으니, 이것이 여전히 실험 단계로 간주되는지, 아니면 문제가 해결된다고 확인해 주실 수 있는지가 궁금합니다.

@RGJ가 2021년 11월에 했던 것과 유사하게, Discourse를 사용하는 대형 공개 포럼(Python)을 찾아보았습니다. 그리고 해당 포럼에서 답변이 많은 특정 토픽에 대한 Google 검색을 수행하여, 같은 토픽의 개별 답변들이 대량으로 표시되는지 확인해 보았습니다.

기쁘게도, Google 검색 결과에 개별 답변들의 긴 목록이 표시되지 않았습니다! 검색 결과에는 토픽 자체와 그 토픽이 포함된 카테고리만 표시되었습니다! 이는 매우 좋은 징조입니다!

다만, @RGJ가 2021년 11월에 수행했던 동일한 검색을 제가 수행했을 때, 그 특정 검색에서는 여전히 문제가 존재했습니다.

또한 이 Discourse 커뮤니티 포럼의 다른 토픽으로 새로운 테스트 검색을 수행해 보니, 같은 토픽에서 나온 여러 검색 결과가 있는 유사한 문제를 발견했습니다.

이 문제가 모든 Discourse 포럼에서 항상 발생하는 것은 아니라는 것을 볼 수 있어 좋습니다… 하지만 왜 Python 포럼에서는 문제가 해결되었는데 Discourse 포럼에서는 여전히 존재하는지 이해가 되지 않습니다.

이 문제를 해결하는 방법에 대해 아이디어가 있는 분이 계신가요?

기존 포럼을 NodeBB에서 Discourse로 이전하는 것을 고려하고 있지만, 이전을 진행하기 전에 도메인에 SEO 재앙을 초래하지 않도록 문제를 해결할 수 있는지 알아야 합니다.

해당 검색은 주제 내 링크를 소수로 반환하지만, 해당 주제에는 58개의 게시물이 있으므로 /nn URL이 모두 인덱싱되었다면 58개의 개별 결과를 기대할 수 있습니다. 스파이더가 다른 게시물 내의 해당 주제 게시물 링크를 보고 그 개별 페이지를 인덱싱하는 것일 수도 있습니다.

그러나 /nn을 끄는 것은 제 포럼에게는 악몽이 될 것입니다. 문제를 해결하는 방법에 대한 긴 토론이 자주 이루어지며, 여기에는 '이것이 작동한다’는 내용이 여러 개 포함될 수 있고, 몇 개의 게시물 뒤에 '아니, 작동하지 않는다’는 게시물이 따라옵니다. 나중에 누군가가 같은 문제를 겪을 때 실제 ‘해결책’ 게시물을 참조하는 경우가 많습니다. 답변이 어딘가에 포함된 페이지로만 사람들을 안내할 수 있고, 그 페이지에는 잘못된 해결책이 포함되어 있을 수도 있다면 그것은 누구에게도 도움이 되지 않을 것입니다.

그리고, 네, 디스코커스에 해결책을 강조하는 방법이 있을 수 있습니다. 예를 들어 Solved 플러그인 등이 있죠. 하지만 제 포럼에는 22년치 게시물이 있으며, 그중 최근 12개월분만 디스코커스에서 작성되었습니다.

세스, 안녕!
현재 제 프로젝트에서도 같은 문제를 겪고 있습니다.
페이지가 페이지네이션되어 있어 하나의 페이지에 대해 여러 URL이 존재하는 상태입니다.

https://webmasters.stackexchange.com/questions/65643/redirect-all-paginated-pages-to-their-main-category-page

이 게시글이 도움이 될 것 같습니다.
이 코드를 사용하여 모든 페이지네이션된 페이지를 해당 정준 페이지로 리다이렉트하는 데 성공했습니다.

Discourse에서 페이지를 리디렉션하기 위해 그 코드를 .htaccess 파일에 넣으신 건가요?

Discourse는 Apache2를 사용하지 않습니다. Discourse의 앞단에서 리버스 프록시로 사용할 수는 있지만, 그 용도로는 최적이라고 할 수 없습니다.

그리고 이 주제를 전혀 이해하지 못하겠습니다. 해당 URL 구조는 SEO와 아무런 관련이 없습니다. 하지만 제가 이해하지 못해서 그런 것일 수도 있습니다. 제 포럼은 아직 SEO 가치가 꽤 높은데, 그것은 콘텐츠에서 비롯된 것입니다.

여기서 문제는 크롤 예산이라고 생각합니다.

아니, 그것도 아니야.