Googlebot용 feature detect 비활성화 또는 우회 (크롤러에게 JS 앱 서빙 시)

stance455 · 5월 9, 2022, 2:44오후

Discourse가 Googlebot에 JS 앱을 완전히 서빙하도록 하려고 시도하고 있으며, 거의 성공했습니다.

@pfaffman의 도움으로 아래 코드(rails console에서 실행)를 실행한 결과, Chrome에서 User Agent를 googlebot 또는 googlebot smartphone으로 위장할 때 JS 앱이 표시되도록 만들 수 있었습니다.

그러나 Google 모바일 친화도 도구 (또는 Google 검색 콘솔의 URL 검사)로 테스트하면 아래 HTML과 함께 빈 스크린샷이 표시됩니다.

Bing은 유사하지만, Bing의 경우 콘텐츠가 표시됩니다. Bing의 크롤러가 "모바일"이 아니기 때문에 콘텐츠가 표시된다고 생각합니다. @sam의 관련 게시물을 참조하세요.

@david와 이 게시물에 따르면 "feature detect"가 원인으로 보입니다.

간단한 우회 방법이 있을 것이라고 조심스럽게 낙관하고 있습니다. 도구를 사용할 때 10~20회 중 1회꼴로 Googlebot이 앱을 올바르게 렌더링합니다.

제 가설은 다음과 같습니다. Googlebot은 페이지에 액세스할 때 모든 리소스를 다운로드하지 않는 것으로 악명 높기 때문에, feature detect를 포함하고 재귀를 유발하는 특정 JS가 로드되지 않아 페이지가 정상적으로 보이는 것입니다.

결론적으로, Googlebot(또는 더 쉽게 말해 모든 크롤러/봇)에 대해 feature detect를 비활성화하려면 어떻게 해야 합니까?

수정 용어가 잘못되었을 수 있으므로, meta에서 언급되는 "feature detect"가 브라우저 감지를 가리키는 것입니까? (예: browser-detect.js 및 기타 의존성 파일)

아니면 "feature detect"는 Discourse가 앱에 액세스하려는 기술을 이해하려고 할 때 수행하는 작업에 대한 광범위한 표현입니까?

j127 · 5월 10, 2022, 5:33오후

Googlebot에게 JS 버전을 제공하려는 특별한 이유가 있습니까? Google은 페이지네이션이 적용된 목록 뷰를 발견하지 못할 가능성이 높습니다. 여기에는 페이지네이션이 적용된 홈 페이지와 특정 개수 이상의 게시물을 가진 주제도 포함됩니다. 봇 뷰에서는 주제 목록이 크롤링할 수 있지만, Googlebot이 끝없는 스크롤을 트리거하지는 않을 가능성이 큽니다.

stance455 · 5월 10, 2022, 6:58오후

좋은 질문을 해주셔서 감사합니다. 네, 이것이 제 구글 "소프트 페널티"의 원인이라고 생각합니다.

자세히 설명드리겠습니다.

2019년 9월/10월경에 매우 부주의한 사이트 업데이트를 진행했는데, 바로 그 시점에 메인 사이트의 순위가 급락했습니다.

그 후로 회복되지 않았습니다. SEO 측면에서 사이트가 그 어느 때보다 좋아졌다고 할 수 있습니다. 완벽하지는 않지만 경쟁사 중 일부와는 비교할 수 없을 정도로 앞서 있습니다. 수년 전의 이미지와 텍스트를 사용하는 사이트들이 페이지 단위로 우리보다 높은 순위를 차지합니다. 우리는 3페이지에 있고, 그들은 아마도 2페이지 상단에 있을 것입니다.

무수히 많은 SEO 블로그, 영상, 포스트를 살펴보고 심지어 존 뮬러 (Reddit에서) 와도 몇 번 주고받았습니다.

그에게서 얻을 수 있었던 것은 "품질 문제"일 수 있다는 것이 전부였습니다. 올해 1월 1일부터 메인 사이트를 크게 개선했습니다. 하지만 유기적 트래픽에 변화가 전혀 없습니다.

Discourse: 2013년에 설치해 두었다가 잊어버렸습니다. 트래픽을 거의 확인하지 않았습니다.

메인 사이트 분석 도구를 보면 차트의 후반부에 급격한 하락이 보입니다. 이것은 제가 Discourse 작업을 시작할 때입니다.

Discourse에서 prerender.io를 시도했을 때 메인 사이트의 순위는 매우 불안정했습니다. 하룻밤 사이에 10~15위까지 뛰어올랐다가 다시 내려가는 식이었습니다. (메인 메뉴, 로그인 등을 렌더링하지 못해 이후 prerender를 중단했습니다.)

온라인에서 읽은 바로는, 이것은 구글이 사이트를 어디에 배치해야 할지 모르는 징조라고 합니다. 그들은 조금만 “더” 하면 알고리즘의 좋은 쪽으로 넘어갈 수 있다고 말합니다.

지난 3년간 우리가 해온 어떤 조치도 SERP에서 이러한 변동성을 유발하지 않았습니다.

(구글 디스어우 도구 사용, 코드 정리, 깔끔한 URL, 사이트 구조, 내부 링크, 소셜, 콘텐츠 등)

“왜 2018년에 구글이 페널티를 부과하지 않았느냐?” (당시에도 서브도메인에 discourse가 있었습니다)라고 주장할 수 있을 것입니다.

음, 사이트 고유의 요인, 역사, 링크 프로필 등 여러 요인이 복합적으로 작용하여 2019년 말에 순위가 급락했다고 생각합니다. 구글이 사이트 순위를 재배치하고, 아마도 discourse URL에 이전보다 더 많은 가중치를 부여한 것 같습니다.

그리고 중요한 것은 … 저는 Discourse를 정말 좋아합니다. 특히 meta를 더 많이 사용하게 되면서, 존재하는지도 몰랐던 멋진 플러그인과 기능들(위키, 구독 결제, 목차, 그리고 이제 채팅까지!)을 알게 되었습니다.

따라서 Discourse를 떠나기는 현실적으로 불가능합니다. 이 시점에서는 이미 너무 많은 것을 투자했기 때문입니다.

이 점도 고려했고, 운을 걸어보려 합니다. 완벽하지는 않겠지만, 제가 읽고 본 자료들에 따르면 구글은 최근 JS를 이해하는 데 매우 능숙해졌습니다.

그들은 심지어 AJAX 크롤링 스킴을 폐기하기도 했습니다.

시대가 변했습니다. 오늘날, Googlebot이 JavaScript 또는 CSS 파일 크롤링을 차단하지 않는 한, 우리는 일반적으로 모던 브라우저처럼 웹 페이지를 렌더링하고 이해할 수 있습니다.

참고: Discourse에는 AJAX 크롤링 설정이 있습니다. 아마도 결국 이것이 제거되어야 할 것입니다.

따라서 계획은 Google에게 앱을 서빙하고, 발생할 수 있는 SEO 문제를 최대한 수정한 후 트래픽 급증을 즐기는 것입니다.

그 후 meta에서 결과를 보고하고, Discourse가 Google을 위해 JS를 최적화해야 한다는 주장을 펼칠 수 있습니다.

예를 들어, 이것(구글 블로그에서 가져온 것)과 같은 것이 페이지네이션과 스크롤 관련 우려를 해결하는 데 도움이 될 수 있습니다.

그리고 구형 브라우저를 위해 비-크롤러 버전은 유지하겠습니다.

stance455 · 5월 12, 2022, 7:16오후

허락이 된다면…

JS 버전을 구글에 전송하기 전에 이미 직접 테스트를 해보고 있었습니다.

대략 4월 초경에 JS 버전을 구글에 전송해 보았습니다. 기억이 정확하진 않지만, 대부분 결과가 반환되었습니다(보기엔 깨져 보였지만요). 구글 모바일 도구를 사용했습니다.

이 커밋 때문인 것 같다고 생각했습니다. 코드 수정 후 재시작을 했지만 동일한 동작을 보였습니다.

지난 몇 달간 브라우저 및/또는 크롤러 감지를 변경했을 수 있는 PR이나 커밋을 기억하시는 분이 있을까요?

수정 업데이트가 많아 죄송합니다. 정보가 많을수록 좋죠, 그렇죠?

지난달 프리렌더(prerender)를 시도했을 때, 구글이 포럼 커버리지에 2,000개의 URL을 추가했습니다. ( 대부분이 이 URL들 )

모든 페이지가 0.005초 만에 서빙되었습니다. 프리렌더가 URL들을 캐시에 저장해 두어 구글봇이 접근할 준비가 되어 있었기 때문입니다. 그래서 구글이 빠르게 모두 수집했습니다.

즉, 크롤러가 JS가 없는 상태에 “매우 익숙해져” 그 2,000개 페이지를 가져오기 위해 리소스를 투입했을 수 있다는 것입니다.

그래서 지금은 상황이 파악될 때까지(그리고 JS를 더 많이 사용해야 할 때까지) 이런 방식으로 사이트를 접근하고 있는 것으로 보입니다. 그냥 추측일 뿐이지만요.

j127 · 5월 13, 2022, 2:01오후

당시 Discourse의 크롤링 방식을 변경하는 작업, 예를 들어 prerender를 적용하려는 시도를 하고 있었나요?

GA의 랜딩 페이지 보고서를 확인해 보면 사이트의 어떤 부분이 영향을 받았는지에 대한 단서를 얻을 수 있나요?

주요 사이트의 경우, John Muller가 품질 문제가 있다고 제안했다면, 그들의 품질 문서를 검토해 보시고 해당 사항이 있는지 스스로 점검해 보시는 것이 좋습니다.

간단히 살펴본 결과, 2019년 사이트에서 오는 리다이렉트 체인이 Google이 크롤링할 수 있는 길이보다 길 수 있습니다.

갑작스러운 패널티의 원인으로 추정되는 것 중 하나는 2019년 사이트의 URL이 6번의 리다이렉트를 거치는데, Google은 이를 "5회 미만"으로 유지해야 한다고 권고하며 그렇지 않을 경우 리다이렉트를 따르지 않을 수 있다는 점입니다. 이로 인해 Google이 구 페이지가 웹에서 사라진 것으로 인식했을 가능성이 있습니다.

예시:

curl -sSL -D - http://flynumber.com/virtual-phone-number/united-states_alexandria_1-318 -o /dev/null -H 'User-Agent: header_bot'

리다이렉트는 아마도 가장 쉽게 수정할 수 있는 부분일 것입니다. 이렇게 처리하는 대신:

/a → /b → /c → /d → /e → /final-destination

이렇게 처리하는 것이 좋습니다:

/a → /final-destination
/b → /final-destination
/c → /final-destination
/d → /final-destination
/e → /final-destination

(또한 도어웨이 페이지와 자동 동의어 치환도 있는 것 같지만, 이 문제가 충분할 수 있으므로 더 간단한 문제를 먼저 수정해 보시는 것을 권합니다.)

stance455 · 5월 13, 2022, 7:48오후

조시, 피드백 감사합니다.

좋은 지적입니다. 실행 방식은 다소 미흡했고 몇 달이 걸렸지만, Google은 결국 각 페이지가 무엇을 의미하는지 파악한 것 같습니다.

즉, 시간이 지나면서 구 페이지에 사용되었던 키워드에 대해 301 리다이렉트를 설정한 페이지들이 점점 더 많이 노출되기 시작했습니다.

이것은 매우 타당하며, 어떻게 구현할지 알아보겠습니다. 현재 검색 콘솔에서는 크롤러가 301 리다이렉트에 너무 자주 도달하는 것으로 나타나지 않습니다. 순위가 좋아지면 더 많은 301을 따를 것 같습니다. 인과관계가 아닌 상관관계일 수도 있겠네요.

Discourse에 대한 비판이 전혀 아닙니다. "수천 명의 Discourse 사용자들이 훌륭한 유기적 트래픽을 얻고 있다"는 말로 쉽게 설득되지는 않습니다.

Google도 우리에게 명확히 알려주지 않을 것입니다.

Google이 알고리즘이라는 점을 항상 기억해야 합니다. 그들은 인간의 시각이 아니라 알고리즘의 시각으로 이것을 보고 있습니다.

두 버전 모두 유사한 콘텐츠를 공유하고 있으며, Google이 이것이 악의적인 클로킹이 아니라는 것을 알고 있지만, 여전히 순위를 조정해야 합니다.

한 버전은 훨씬 더 좋아 보이고, 더 잘 작동하며, 내부 링크 구조에 대한 일정한 느낌을 줍니다. 다른 버전은 화려하게 꾸며진 RSS 피드에 불과합니다.

Google은 제가 이 세련된 포럼을 가지고 있다는 사실을 전혀 모릅니다. 이 포럼은 모든 [최신] 기기에서 작동하고, 진정한 담론을 장려하며, 인터넷이 만들어낸 가장 멋진 것 중 하나입니다.

크롤러 버전에는 “Powered by discourse” do-follow 링크를 항상 사용합니다. (그냥 쉽기 때문입니다.)

다시 말하지만, 악의적이지는 않지만 Google의 시각으로 봐야 합니다. FlyNumber(https://community.cloudflare.com/ 가 아닙니다)는 일반 브라우저에는 보이지 않는 외부 링크를 포함하여 우리에게 이 크롤러 버전을 제공하고 있습니다.

알고리즘이 무슨 일이 일어나고 있는지 감지하고, Cloudflare 도메인에 대한 외부 링크를 무시할 수 있다고 충분히 상상할 수 있습니다. (Cloudflare은 그만큼 권위가 높기 때문입니다.)

Google이 Cloudflare에 적용하는 것이 나에게도 적용되는 것은 아닙니다.

누군가 일반 사용자에게는 보여주고 싶지 않지만 봇에게는 보여주는 이 외부 링크를 위해 당신에게 돈을 지불했나요? 이것은 그들이 사이트를 어떻게 볼 수 있는지에 대한 문제입니다. 이것이 그 원인이라고 말하는 것은 아니지만, 제거하고 싶은 가능성 중 하나입니다.

가장 단순한 말로, 크롤러 버전에는 메뉴나 실제 구조가 없습니다.

그것이 알고리즘이 최종 사용자에게 제공하기를 원한다고 생각하는 콘텐츠입니다.

매우 일반적인 관점에서 보면, 알고리즘이 그것을 보상한다고 보기 어렵습니다.

크롤러 버전에 대한 진정한 개편을 고려할 때가 된 것 같습니다. 최소한 메인 메뉴와 하단의 추천 주제 정도는 추가해야 합니다.

흥미로운 업데이트 Google이 제 discourse 인스턴스의 크롤링 통계 "파일 유형"에 "JSON"을 추가했습니다. "Javascript"는 별도의 "파일 유형"입니다.

이 부분을 주의 깊게 지켜볼 것이지만, 여전히 Google 도구에서 이것이 제대로 렌더링되기를 바랍니다.

stance455 · 5월 16, 2022, 3:59오후

제 논리가 처음부터 잘못되었을 수도 있다는 생각이 듭니다. 아무도 답변하지 않은 이유를 설명할 수 있죠 - 어쩌면 아무 문제가 없는 것일지도 모릅니다.

Google이 스크린샷에서 흰색 페이지를 표시하는 것이 정상이라는 최신 기사를 공유합니다.

이제 홈페이지의 “crawled” HTML을 볼 수 있습니다. 이는 "Live test"가 아닌 인덱싱된 버전이며, 전체 페이지가 표시됩니다. 참고로 Google은 전체 JS 앱을 서빙하는 동안 이 문제를 파악했습니다.

흥미로운 점은, 인덱싱이 홈페이지의 약 27번째 게시물까지 내려갔다는 것입니다. 즉, 무한 스크롤 기능은 Google이 이해하고 있는 것 같습니다.

도움이 되었는지 확실하지 않지만, 관리자 설정에서 ajax 설정을 해제했습니다. 이로 인해 Google이 아래와 같은 URL을 발견하게 되었고 (크롤러 버전을 서빙함) - 해제한 후, 이제 해당 URL은 JS 버전을 표시합니다.

https://discuss.flynumber.com/t/japan-phone-numbers-disconnect-notice/2351?_escaped_fragment_=

이제 알아야 할 것은, 사용자가 페이지에 대해 Discourse가 생성하는 추가 캐노니컬 URL들을 어떻게 정리할 수 있는지입니다.

stance455 · 6월 14, 2022, 4:12오후

SPA(완전한 JS 버전)의 discourse를 한 달 이상 제공해 본 후, 크롤러 버전으로 돌아왔습니다.

제 과거 게시물을 참고하시면 아시겠지만, 구글이 JS 버전을 더 잘 이해하고 크롤러 버전보다 더 높은 순위를 매길 것이라고 주장했었습니다. 제 생각이 틀렸습니다.

@j127 님, 말씀이 맞았습니다! (곧 DM을 보내겠습니다, 존경하는 분)

구글은 사이트를 파악하긴 한 것 같지만, 순위는 거의 동일하거나(아니면 약간 더 낮거나) 비슷했습니다.

크롤러 버전도 4월/5월에 링크 색상, 형식 등이 업데이트되었으므로 그 부분은 도움이 됩니다.

개인적인 의견으로는 크롤러 버전에 간단한 메뉴와 "추천 주제"를 추가하면 모두의 SEO에 좋은 차이가 생길 것 같습니다.

그 외에는 혹시 궁금해하시는 분이 있을까 봐 이 글을 올렸습니다.

좋은 작업 하셨습니다!

글		댓글	조회수
Googlebot is getting non-javascript version of the site Development	16	1805	3월 9, 2024
[Paid work] Allow search engines to crawl the production JS-version Marketplace	5	1069	4월 4, 2022
Can we have a conversation about SEO? Development	2	908	4월 4, 2022
How difficult would it be to make Discourse JS google compliant? Development	3	923	4월 5, 2022
Google May 4th Core Update impact on Discourse forums Community Building	102	10538	7월 5, 2022

Googlebot용 feature detect 비활성화 또는 우회 (크롤러에게 JS 앱 서빙 시)

Related topics