인스턴스에 "window.prerenderReady" 구현 필요 [유료 작업]

저는 prerender.io를 사용하여 크롤러에게 사이트의 “application/JS” 버전을 제공하고 있습니다(저의 인스턴스는 숨겨진 설정을 통해 크롤러에게 JS 버전을 제공합니다).

잘 작동하고 있지만, discourse가 이 범주에 해당할 것 같습니다 …

그러나 일부 웹 페이지는 사용자 정의 로딩 플로우나 지속적인 폴링을 사용하여 Prerender의 로직을 혼란스럽게 할 수 있으며, 이로 인해 페이지가 준비되었는지 여부를 판단하지 못합니다.

prerender가 discourse URL에 처음 접근할 때 타임아웃(20초, prerender 설정)이 발생합니다.

페이지는 정상적으로 렌더링되지만, prerender.io가 페이지가 완전히 로드되었는지 알지 못하여 20초가 될 때까지 페이지 렌더링을 계속 시도하다가, 그 후 HTML 버전을 제공합니다.

크롤러가 해당 페이지를 다시 요청하면, 캐시에 해당 URL의 HTML 버전이 있으므로 약 1초(오차 범위 있음) 안에 페이지를 제공합니다.

…하지만 수천 개의 URL이 있고, 각 URL에 대해 처음 접근할 때 20초가 걸리는 것은 현실적이지 않습니다.

따라서 <head> 태그 바로 아래에 아래 코드를 추가하고(페이지가 완료되면 변수를 true로 설정해야 합니다)

<script> window.prerenderReady = false; </script>

이것이 사이트 전체에서 작동하기를 바랍니다. 그러면 작업이 더 쉬워지리라 생각합니다.

이것이 무엇을 포함하는지 정확히 모르겠지만, 제 이해가 틀렸다면 알려주세요 - 300달러? 400달러?

이 부분에 대해 피드백 주실 분 계신가요?

그동안 수정할 수 있는 핵심 파일(core file)이 있을까요?

그렇게 하려면 어떤 코드를 사용하시는지, 해당 코드를 어디선가 공유하실 수 있으신가요?

1개의 좋아요

JS 버전을 서빙하기 위한 코드요?

(@pfaffman) 님이 활성화/조정을 도와주신 숨겨진 사이트 설정 " crawler_user_agents "였습니다.

수정 위의 목록에서 “bots”, “crawlers”, "spiders"를 제거했습니다.

prerender.io는 어떻게 관련되어 있나요? Discourse는 언제 태그를 포함해야 하는지 어떻게 알 수 있나요?

아, prerender가 기존 <head> 태그를 가리키는 거죠?

기존 <head> 태그 바로 아래에 <script> window.prerenderReady = false; </script>를 추가해야 한다는 말씀이신 건가요?

수정 코드 자체가 head 태그 안에 있어야 하는지, 아니면 head 태그가 닫힌 뒤에 있어야 하는지도 확실하지 않습니다.

prerender를 설치하여 미리 렌더링된 페이지를 서빙하도록 설정한 방법은 무엇인가요? How to Install Prerender in 3 Easy Steps 에 세 가지 방법이 나열되어 있습니다. 그중 하나를 사용하셨나요?

1개의 좋아요

네, Cloudflare 미들웨어를 사용했습니다.

즉, Cloudflare가 봇에서 오는 모든 요청을 prerender로 전달합니다.

그렇다면, 다음에서 원하는 true/false 값을 반환하도록 prerender를 위한 API 호출을 제공할 수 있나요?

 <script> window.prerenderReady = false; </script>
1개의 좋아요

아, 그렇군요. API에 대해 조금 읽어보았습니다만, 제 수준을 좀 벗어난 것 같습니다(하지만 이 정도면 작업이 좀 더 쉬워지길 바랍니다).

기본적으로 이 작업에는 예산이 좀 부족한 편입니다. 크롤러에게 제공되는 내용을 수정하는 것은 생각보다 더 까다로울 수 있습니다. 다양한 문제가 발생할 수 있습니다.

개인적으로는 애초에 이 작업을 하는 것이 현명한지에 대해 다소 회의적이지만, 당신에게는 당신만의 이유가 있으실 거라고 생각합니다.

제이가 말한 것은 discourse 클라이언트 API를 의미하는 것 같습니다. 이를 테마 컴포넌트를 통해 사용하여 Discourse가 완전히 렌더링된 시점을 알 수 있습니다.

당신은 소프트웨어 개발에 대해 어느 정도 익숙해 보이시네요. 저는 지난 해 discourse 테마 개발 입문 과정을 만들었는데, 여기에는 테마에서 API를 사용하는 방법에 대한 논의도 포함되어 있습니다. 무료이며 오픈소스입니다. 여기에서부터 읽어보실 수 있습니다:

페이지가 렌더링될 때 트리거되는 프론트엔드 이벤트를 사용해야 할 가능성이 높습니다. 이 과정에서 첫 번째 자바스크립트 유닛에 도달하면 그 사용 예시를 몇 가지 확인할 수 있습니다.

2개의 좋아요

답장 주셔서 감사합니다, Angus.

그것이 필요한 작업인지 확실하지 않습니다. Crawlers는 이미 제 discourse 인스턴스의 HTML 버전을 받고 있으니까요.

아직 단정하기는 이르지만 꽤 낙관적입니다. 단순히 SEO 정리 작업일 뿐이며, Google은 완전히 새로운 사이트를 크롤링하고 있습니다. Google이 JS가 없는 crawler용 사이트 버전을 실제 사용자 경험과 동일한 랭킹을 부여한다고 상상할 수조차 없습니다.

가장 먼저 해야 할 일은 해당 코드를 <head>에 배치하는 것입니다.

그 다음에는 prerender.io에 따라 이 부분을 구현하는 것입니다.

페이지가 완전히 렌더링되고 Prerender가 콘텐츠를 가져오기 안전한 상태일 때만 이 변수를 true로 설정하도록 하세요. 이는 페이지에서 매우 늦게 실행되는 비동기 호출을 통해 가능합니다. 그러면 Prerender.io는 모든 호출이 완료되었는지 확인하기 위해 잠시 기다린 후 페이지를 저장합니다.

제공해 주신 문서를 살펴볼 예정입니다. 감사합니다.

1개의 좋아요

무엇을 보고 계신지 정확히 모르겠지만, 저희 경험에 따르면 크롤러 뷰는 사이트 랭킹을 꽤 잘 수행해 왔습니다. 커뮤니티가 메인 사이트보다 높은 순위를 차지했다는 고객들의 보고를 받은 적도 있습니다.

2개의 좋아요

단순히 해당 사이트에 매우 가치 있는 콘텐츠가 있고, 알고리즘이 "나쁜 부분"을 무시하고 있는 것일 수도 있습니다. 각 사례는 다릅니다.

(일반적인 의미에서) 구글이 크롤러 버전을 JS 버전인 것처럼 랭킹하는 것은 합리적이지 않습니다.

크롤러 버전에는 메뉴, 추천 주제, 사이드바 링크, noindex가 설정된 사용자 프로필/배지 페이지, 그리고 크롤러 버전에서는 사용할 수 없는 수많은 다른 기능이 없습니다.

결과가 나오면 새로운 주제로 업데이트하겠습니다. 지금까지 SERP에서의 위치는 매우 불안정했습니다.

수정 사용자 프로필/배지 페이지는 헤더를 통해 noindex가 설정되어 있습니다