디스코urses 포럼에서 **캐노니컬 링크를 완전히 제거** 하는 방법이 있는지 궁금합니다.
여기서 말하는 것은 사용자가 페이지를 아래로 스크롤할 때 각 주제 URL에 나타나는 /2, /3, /4 등의 확장자입니다. 저는 주제 내의 모든 답변이 단순히 원래 URL을 참조하도록(방문자를 원래 URL로 리다이렉트하는 것이 아니라, 해당 경로가 아예 존재하지 않도록 완전히 제거하는 것) 설정하고 싶습니다.
처음에는 이것이 디스코urses의 멋진 기능이라고 생각했지만, 지난 1년 동안 제 사이트에서 NodeBB를 사용하여 유사한 포럼을 운영하면서(이 역시 각 답변에 동일한 캐노니컬 링크 기능을 사용함) 이 기능이 공개 포럼의 SEO에 재앙적인 결과를 초래할 수 있다는 것을 알게 되었습니다.
**왜 그런가요?** 이 /2, /3, /4 URL들이 [캐노니컬 링크](https://developers.google.com/search/docs/advanced/crawling/consolidate-duplicate-urls)임에도 불구하고, 구글은 결국 이 모든 것을 크롤링하여 인덱싱합니다. 즉, _주제 내의 모든 새로운 답변_이 구글 검색 결과에 나타날 수 있으며, 이들은 기본적으로 원래 주제 URL의 중복 버전이므로 이러한 추가 인덱싱된 페이지는 거의 방문을 받지 못합니다. 방문이 있더라도 방문자가 사이트에 몇 초 이상 머물지 않습니다.
구글이 많은 수의 추가 페이지를 인덱싱하고 이 페이지들이 활동이 적다면, 이는 도메인 전체가 [저품질 URL](https://searchfacts.com/signs-of-a-low-quality-website/)이 많다는 신호로 해석되어 도메인 건강 상태 전체에 해가 됩니다(우리도 그랬습니다). 공개 포럼을 출시한 이후 약 40%의 트래픽을 잃었고, 그 주요 원인 중 하나가 바로 이러한 추가 URL이었습니다(12개월 동안 각 주제에 남겨진 답변들 때문에 사이트맵에 30,000개 이상의 저품질 URL이 추가되었습니다).
만약 사설 포럼을 운영 중이라면 **이 모든 것은 중요하지 않습니다.** 사설 포럼은 인터넷에서 완전히 숨겨져 있어 어떤 형태의 SEO에서도 이점을 얻지 못하기 때문입니다. 하지만 공개 포럼을 운영하며 자연 검색 트래픽을 확보하는 것이 목표라면, 이러한 추가 URL 문자열은 사이트 전체의 건강 상태에 **매우** 해로운 영향을 미칠 수 있습니다.
따라서, 주제 내 각 답변에 대해 이러한 추가 URL을 생성하지 않도록 디스코urses 포럼에 지시할 수 있는 설정을 조정하거나 플러그인을 만드는 방법이 있는지 궁금합니다.
우리는 NodeBB에서 디스코urses로 포럼을 이전하는 것을 고려하고 있지만, 이러한 추가 URL을 _생성하지 않도록_ 디스코urses 포럼을 설정할 수 있는 방법이 있을 때만 의미가 있을 것입니다.
---
이전에 이 문제에 대해 조금 언급된 적이 있습니다: [Google indexing same page multiple times: Issue with canonicals](https://meta.discourse.org/t/google-indexing-same-page-multiple-times-issue-with-canonicals/131366)
> [@SethWilliams](#):
>
> Google이 많은 추가 페이지를 인덱싱하고 이러한 페이지에 활동이 거의 없다면, 이는 도메인 전체에 [저품질 URL](https://searchfacts.com/signs-of-a-low-quality-website/)이 많다는 신호를 Google에 보내며, 결과적으로 도메인의 전반적인 건강 상태에 해를 끼칩니다(우리의 경우에도 그랬습니다). 공개 포럼을 출시한 이후 약 40%의 트래픽을 잃었고, 그 주요 원인 중 하나가 이러한 추가 URL이었습니다(12개월 동안 각 주제에 남겨진 답변들 때문에 약 30,000개 이상의 저품질 URL이 사이트맵에 추가되었습니다).
이것이 중요한 요인이라고 어떻게 판단하셨나요? 여기에서 작성된 많은 SEO 관련 게시물이 상당히 추측에 기반하고 있으므로, 증거가 있다면 매우 큰 도움이 될 것입니다!
저는 이 플러그인에 대한 경험이 없어 개인적으로 보증할 수는 없지만, 이전에 누군가가 플러그인을 사용하여 canonical 링크를 완전히 비활성화하려는 시도를 한 적이 있습니다: [Remove Canonical Link Plugin](https://meta.discourse.org/t/remove-canonical-link-plugin/160231)
---
> 이 문제는 이전에 약간 언급된 바 있습니다: [Google indexing same page multiple times: Issue with canonicals](https://meta.discourse.org/t/google-indexing-same-page-multiple-times-issue-with-canonicals/131366)
이 대화가 올바르게 이해되었다면, 이는 위에서 제가 언급한 문제와 약간 다른 문제를 가리키는 것 같습니다. 20개의 답변씩 묶어서 페이지를 나누고 고유한 메타 설명(page=2, page=3 등)을 가진 경우, 하나의 주제에 대해 여러 개의 canonical URL을 만드는 것은 문제가 되지 않습니다. 문제는 _주제 내의 개별 답변마다_ 새로운 URL(/2, /3, /4 등)이 생성될 때 발생합니다.
100개의 답변이 있는 주제의 경우, 전자의 경우 **주제당 5개의 URL** (20개의 배수로 묶인 100개의 답변)이 생성됩니다. 후자의 경우 **주제당 100개의 URL** (모든 개별 답변마다 새로운 고유 URL)이 생성되며, 이는 큰 SEO 문제를 일으킵니다.
> 이것이 상당한 기여 요인임을 어떻게 파악할 수 있었나요? 여기에 올라온 많은 SEO 관련 게시물이 상당히 추측에 기반하고 있으므로, 증거는 매우 중요합니다!
Google Search Console, SEMrush, Ahrefs와 같은 도구를 사용했습니다. 이 도구들은 모두 포럼 주제 답변에 의해 생성된 우리 사이트의 방대한 URL 수로 인해 발생한 경고와 오류를 강조했습니다. 이 URL들은 모두 실질적인 새로운 내용을 제공하지 않으면서도 Google에 의해 인덱싱되고 있었습니다. 포럼이 공개되어 있을 당시 건강 점수는 30~40점대였습니다. 이후 포럼 전체를 잠가 비공개로 전환(Google이 볼 수 없도록)하고 테스트를 다시 실행하자, 이 변경 사항만으로 건강 점수가 80점대로 올랐습니다.
> 이 플러그인에 대한 경험은 없으며 개인적으로 보증할 수는 없지만, 이전에 누군가가 플러그인을 사용하여 canonical 링크를 완전히 비활성화하려는 시도를 했습니다: [Remove Canonical Link Plugin](https://meta.discourse.org/t/remove-canonical-link-plugin/160231)
저도 이것을 찾았습니다. 불행히도, 이 플러그인은 상황을 _더 악화_시킵니다. canonical 태그를 완전히 제거하면서도 /2, /3 등의 페이지를 그대로 유지하기 때문에, 이러한 추가 URL은 여전히 저품질 중복 콘텐츠로 간주됩니다.
---
알아두면 좋은 정보네요. 올바른 방향으로 큰 한 걸음을 내딛는 것 같습니다.
참고로, 저희 현재 포럼(아직 공개되어 있을 때)에서 robots.txt 파일을 특정 하위 폴더에 추가했는데도 _Google이 여전히 크롤링을 진행한_ 사례를 몇 번 확인했습니다. 이는 매우 비정상적인 현상이라고 생각하지만, Google이 이 지시를 따르지 않는 경우가 일부 존재한다는 사실을 알게 되었습니다. 페이지가 인덱싱되지 않도록 100% 확실하게 하려면, 해당 페이지가 로그인 화면 뒤에 숨겨져 있거나 아예 _존재하지 않는_ 상태여야 합니다.
외부인의 시각에서 보면, Discourse에게 각 댓글마다 이러한 추가 URL을 생성하는 번거로운 과정을 _거치지 말라고_ 지시하는 것은 간단해 보입니다. 이렇게 하면 소프트웨어가 더 적은 작업을 수행하고 복잡성도 줄어들지 않을까요?
관리자 설정에서 이러한 추가 URL을 아예 끄는 기능을 제공하면 좋겠습니다.
---
여기서 무슨 일이 일어나고 있는지 정확히 이해하지 못하겠습니다.
> [@SethWilliams](#):
>
> 20개씩 묶어서 나열되고 고유한 메타 설명이 있는 경우(예: page=2, page=3 등), 주제별로 여러 개의 정준 URL(canonical URL)을 만드는 것은 문제가 되지 않습니다. 문제는 _주제 내 각 개별 답변_마다(/2, /3, /4 등) 새로운 URL이 생성될 때 발생합니다.
Discourse가 _실제로 전자의 방식을 취하고 있기 때문_입니다: 20개 답변 그룹에 대해 `?page=X` 정준 URL 메타 태그를 _실제로_ 생성합니다. 그리고 [여기](https://meta.discourse.org/sitemap_recent.xml)에서 볼 수 있듯이, 사이트맵 URL에는 게시글 번호가 절대 추가되지 않으며, `?page=X` URL만 포함됩니다.
따라서 문제가 없다고 말씀드릴 예정이었습니다.
하지만 [답변이 많은 주제에 대한 Google 검색](https://www.google.com/search?q=site:meta.discourse.org+%22Babble+-+A+Chat+Plugin%22)을 해보니, 검색 결과 2페이지에는 `?page=X` 링크로 가득 차 있지만, 상위 결과 중 일부는 실제로 번호가 매겨진 답변 링크를 사용하고 있었습니다.
그런데 왜 이런 일이 일어나는 걸까요? 해당 페이지에는 _정확한_ 정준 URL이 존재합니다.
```plaintext
rgj@labgate:~$ wget -q -O - "https://meta.discourse.org/t/babble-a-chat-plugin/87297/418"|grep -e "Babble - A Chat Plugin - #418 by HAWK - broken-plugin - Discourse Meta
```
---
> [@RGJ](#):
>
> 하지만 왜 이런 일이 일어나는 걸까요? 그 페이지에는 _정확한_ canonical URL이 있습니다.
브라질에서 블로그 중심 커뮤니티를 위해 Discourse를 사용하는 곳과 이 문제에 대해 긴 논의가 있었는데, 바로 그 경험이 저에게 해당 게시물 전용 페이지에 `noindex` 헤더를 보내는 새로운 접근법을 시도하도록 이끌었습니다. 다음 주에는 해당 PR을 정리하고 병합할 수 있을 것 같으며, 그때부터 실험을 시작할 수 있을 겁니다.
---
> 그런데 왜 이런 일이 일어나는 걸까요? 그 페이지에는 올바른 canonical URL이 _있는데_요.
맞습니다. (이론적으로는) 이런 일이 일어나서는 안 되는데 실제로는 일어나고 있습니다. 또한 우리 사이트에서 경험했듯이, 이는 도메인의 건강 점수에 상당한 피해를 줄 수 있으며, 궁극적으로 도메인 전체의 검색 랭킹에 큰 부정적 영향을 미칠 수 있습니다.
@pfaffman님이 말씀하신 내용에 대해,
> 제 추측은, 그런 링크들이 다른 곳에도 존재해서 인덱싱되는 것이 아닐까 하는 것입니다.
저도 처음에는 그렇게 생각했습니다… 하지만 우리 사이트에서 _수만 개_의 개별 답변이 절대적으로 아무것도 그 답변들을 링크하지 않고 있음에도 불구하고 Google에 의해 인덱싱되고 있다는 것을 확인했습니다. 꽤 기이한 일이며, 왜/어떻게 이런 일이 일어나는지는 이해한다고 할 수 없지만, 이는 포럼 관리자가 원할 경우 각 답변에 대한 /2, /3, /4 등의 URL을 끄는 기능을 가질 필요가 있음을 강조합니다.
궁금한 점이 있습니다. _Discourse에 이 기능을 추가하는 것이 어려운 건가요?_ 비개발자 입장에서 보면, 소프트웨어가 더 적은 작업을 하도록 지시하는 것이므로 간단할 것 같지만… 제가 이해하지 못하는 더 복잡한 부분이 있는 걸까요?
---
확신은 없지만, 해당 페이지에 `noindex`를 적용하는 것이 해가 될 수 있습니다. Discourse는 이미 [캐노니컬 URL](https://developers.google.com/search/docs/advanced/crawling/consolidate-duplicate-urls)을 사용하여 이를 올바르게 처리하고 있습니다.
`noindex`를 적용하면 해당 URL들이 모두 동일한 캐노니컬 URL을 가리키고 있기 때문에, 결과적으로 페이지 전체가 `noindex` 처리될 가능성이 있으며, 이는 재앙이 될 수 있습니다. 정확히 어떤 일이 일어날지는 모르겠지만, 구글은 종종 엣지 케이스를 예측 불가능하게 처리하며, 업데이트에 따라 그 처리 방식이 변할 수 있으므로 매우 신중해야 합니다. 캐노니컬 태그와 관련된 이상한 현상들을 여러 번 목격한 적이 있습니다.
랭킹 알고리즘이 정확히 어떻게 작동하는지는 불분명하고 시간이 지나면서 변하지만, 고려해야 할 또 다른 점은 랭킹이 인바운드 링크의 결과라는 것입니다. 외부 사이트가 `/number` URL로 링크를 걸고, 해당 URL이 `noindex` 헤더를 반환한다면, 구글이 인바운드 "링크 주스(link juice)"를 캐노니컬 URL로 전달하지 않을 가능성이 있으며, 이는 Discourse 사이트의 검색 랭킹에 불리하게 작용할 수 있습니다.
구글이 추가 업데이트를 진행하면서 다르게 처리될 수 있는 우회책을 생각해 내는 것보다, 널리 사용되는 CMS에서 캐노니컬 태그가 제대로 작동하지 않는다는 사실을 구글 검색 팀에 직접 알려주는 것이 훨씬 안전하다고 생각합니다.
---
> [@SethWilliams](#):
>
> 이것은 /2, /3, /4와 같은 기능을 단순히 끄는 권한을 포럼 관리자에게 부여할 필요가 있음을 강조합니다.
아니요, 이것은 _문제를 수정할_ 필요성을 강조합니다. 소프트웨어 엔지니어로서, 기능이 100% 올바르게 작동하지 않는다고 해서 그 기능을 제거하는 것은 매우 어렵습니다. 대신 우리가 도와서 이 문제의 근본 원인을 파악해 보겠습니다.
> [@SethWilliams](#):
>
> 12개월 동안 30,000개 이상의 저품질 URL이 사이트맵에 추가되었습니다.
정말 그런가요? 사이트맵에서 게시글 번호를 본 적이 없습니다.
---
> [@j127](#):
>
> 정확히 무슨 일이 일어날지 확신할 수 없습니다
[ ](https://www.youtube.com/watch?v=s88r_q7oufE)
그래서 사이트 설정에 포함될 것입니다.
---
> [@RGJ](#):
>
> > [@SethWilliams](#):
> >
> > 12개월 동안 약 30,000개 이상의 저품질 URL이 사이트맵에 추가되었습니다.
>
> 정말 그런가요? 사이트맵에서 게시물 번호를 본 적이 없습니다.
이 부분을 질문해 주셔서 감사합니다. "사이트맵"이라는 표현이 적절하지 않았습니다. 제가 말하고자 했던 것은, 이러한 번호가 매겨진 게시물들이 Google에 의해 크롤링되고 인덱싱되어 Google Analytics와 Search Console에서 개별 페이지로 표시되고, 이로 인해 우리 도메인에 저품질 페이지가 매우 많이 생성되고 있다는 것이었습니다.
만약 이러한 번호가 모든 답변에 단순히 추가되지 않았다면, Google은 원래 게시물 URL만 볼 수 있었을 것입니다.
---
> [@SethWilliams](#):
>
> 이 숫자들이 모든 답변에 단순히 추가되지 않았다면, 구글은 원래 게시물의 URL만 볼 수 있었을 것입니다.
네, 그리고 구글이 이 문제를 방지하기 위해 특별히 삽입된 `rel="canonical"` 메타 태그(구글이 만든 것!)를 존중했다면, 이는 문제가 되지 않았을 것이며 동시에 특정 게시물에 링크를 걸 수도 있었을 것입니다.
---
좋네요. 기본값으로 비활성화되어 있으면 이상적이겠습니다. 이 기능이 Google이나 다른 검색 엔진에서 주제 페이지가 사라지는 원인이 될 수도 있으니까요.
이미 언급되었는지 확실하지는 않지만, `noindex` 없이 문제를 해결하려면 게시물에 URL 단편(fragments)을 사용하는 방법이 있을 수 있습니다. 단편은 별도의 페이지로 계산되지 않으므로 말이죠.
```plaintext
/t/slug/id#13
```
---
> [@j127](#):
>
> 이미 언급된 것일지 모르겠지만, `noindex`를 사용하지 않고 문제를 해결하는 또 다른 방법으로는 포스트에 URL 단편을 사용하는 것이 있을 수 있습니다. URL 단편은 별도의 페이지로 계산되지 않아야 하니까요.
제안을 감사드립니다. 그 방법이 통할 것 같다는 생각이 들긴 합니다… 하지만 원래의 ‘올바른’ 방법조차 제대로 작동하지 않는 상황에서, 번호가 매겨진 답글을 완전히 제거하는 것 외에는 문제를 해결할 수 있는 것이 _아무것도_ 없다는 회의적인 마음이 듭니다.
물론 모든 Discourse 사용자가 번호 매김을 중단해야 한다고 말하는 것은 아닙니다. 사실, 구글이 멍청하지 않거나(그리고/또는) 우리가 포럼을 공개적이지 않고 비공개로 운영할 의도가 있었다면) 나는 이를 적극 지지했을 것입니다… 하지만 공개 포럼을 운영하면서 도메인의 전반적인 SEO 상태를 중요하게 생각하는 사람들에게는 답글의 자동 번호 매김을 끄는 옵션만 있어도 큰 도움이 될 것입니다.
---
> [@SethWilliams](#):
>
> 하지만 원래의 “정확한” 방법이 작동조차 하지 않는 상황이므로, 번호가 매겨진 답글을 완전히 제거하는 것 외에는 문제를 해결할 수 있는 방법이 거의 없다고 생각하게 됩니다.
그러면 특정 게시글에 링크를 걸 수 있는 기능이 사라집니다. 1,000개 게시글이 있는 주제에서 789번째 게시글에 링크를 걸 수 있는 방법이 없게 되며, 사용자들이 그까지 스크롤해야 하는 것은 번거로울 것입니다.
이상합니다. 제 포럼에서 게시글 ID URL이 인덱싱되고 있는지 확인하기 위해 Google을 검색해 보았는데, 확인한 모든 주제에서 정형(canonical) URL만 표시되고 있었습니다.
다른 대형 Discourse 사이트에서는 확인됩니다. 이 주제에서도 나타납니다. [[Google 검색 쿼리](https://www.google.com/search?q=site%3Ahttps%3A%2F%2Fmeta.discourse.org%2Ft%2Fremoving-the-2-3-4-etc-links-for-each-reply-within-a-topic-url%2F209648&filter=0)]
두 응답에 대해 다음과 같이 diff를 실행해 보았습니다:
```plaintext
curl -s https://meta.discourse.org/t/removing-the-2-3-4-etc-links-for-each-reply-within-a-topic-url/209648 > 1.html
curl -s https://meta.discourse.org/t/removing-the-2-3-4-etc-links-for-each-reply-within-a-topic-url/209648/8 > 2.html
vim -d 1.html 2.html
```
눈에 띄는 차이점 중 하나는 `article:published_time`이 다르다는 것입니다. 페이지는 거의 동일하므로 이 값은 동일해야 합니다. 이 메타태그가 Google이 정형 URL을 무시하도록 하는 원인일 수 있다고 생각합니다. Google 직원은 [여기](https://www.searchenginejournal.com/googles-john-mueller-explains-why-relcanonical-is-sometimes-ignored/288163/)에서 특정 경우 rel=canonical이 무시될 수 있다고 설명하고 있습니다.
```plaintext
```
또한, `ignore_canonical` 태그는 Discourse에만 고유한 것인지, 아니면 Google이 이를 따를 가능성이 있는 것인지 궁금합니다. HTML에서 확인했습니다.
```plaintext
```
---
> [@j127](#):
>
> 그러면 특정 게시물로 링크를 걸 수 있는 기능이 사라질 텐데요. 1,000개 게시물이 있는 주제에서 789번 게시물로 링크를 걸 방법이 없게 되고, 사용자들이 그만큼 스크롤을 내려야 하므로 번거로울 것입니다.
조금 더 번거로울 수는 있지만, page=2, page=3 등의 URL이 여전히 작동한다면(번호가 매겨진 답글처럼 SEO 문제를 일으키지는 않습니다) 적어도 대화 내에서 올바른 페이지로 사람을 연결할 수 있습니다. 사용자가 조금만 스크롤할 의사가 있다면 대부분 원하는 위치까지 도달할 수 있게 됩니다.
이 방식으로 작동하는 포럼 중 하나는 BiggerPockets입니다. 그들의 답글에는 개별 번호가 매겨진 URL이 없지만, 주제에는 다음과 같은 번호가 매겨진 페이지가 있습니다: [https://www.biggerpockets.com/forums/311-buying-selling-real-estate/topics/1000291-kids-throwing-rocks-at-windows-nearly-everyday-wont-stop?page=2](https://www.biggerpockets.com/forums/311-buying-selling-real-estate/topics/1000291-kids-throwing-rocks-at-windows-nearly-everyday-wont-stop?page=2) (각 주제와 페이지를 스크롤할 때 URL을 확인해 보세요).
그들의 포럼은 SEO 관점에서 사이트가 특별하고 성공적인 이유의 **핵심** 요소였기 때문에, 작동하는 방식의 좋은 예시가 됩니다.
> [@j127](#):
>
> 눈에 띄는 차이점 중 하나는 `article:published_time`이 서로 다르다는 것입니다. 페이지가 그렇지 않으면 거의 동일하기 때문에 원래는 같아야 할 텐데요. 이 메타태그가 Google이 canonical URL을 무시하도록 만드는 것이 아닐까 궁금합니다. Google 직원이 특정 경우 canonical URL이 무시될 수 있다고 [여기](https://www.searchenginejournal.com/googles-john-mueller-explains-why-relcanonical-is-sometimes-ignored/288163/)에서 언급했습니다.
흥미롭네요. 그것이 문제를 일으키는지는 정확히 모르겠지만, 일관성이 없으면 Google이 canonical URL을 무시하도록 혼란을 줄 수 있다는 점은 이해할 수 있습니다.
그럼에도 불구하고, 포럼이 작동하는 방식의 특성상 각 주제와 답글의 날짜와 시간선을 완전히 제거하지 않는 한 이 문제를 없앨 수 없지 않을까요? 각 게시물과 답글의 날짜와 시간을 고려하는 것은 포럼이 작동하는 방식의 핵심적인 부분이라고 할 수 있습니다.
[다음 페이지](https://meta.discourse.org/t/removing-the-2-3-4-etc-links-for-each-reply-within-a-topic-url/209648.md?page=2)