렌더링 SEO: Google이 콘텐츠를 소화하는 방법

이것은 Bartosz Goralewicz, Google의 Martin Splitt 및 Jason Barnard 간의 대화 녹취록입니다. 그들은 실용적인 측면에서 렌더링 SEO에 대해 논의하기 위해 웨비나를 주최했습니다. 여기에서 웨비나 녹화를 볼 수 있지만 정보가 너무 많기 때문에 이 스크립트도 도움이 되길 바랍니다!

Bartosz: 오늘은 Chrome에서 보는 것과는 약간 다른 Google의 관점에서 렌더링을 살펴보겠습니다. 따라서 Martin은 이 어두운 바다에서 우리를 안내하기 위해 왔습니다.

간단히 말해서, 우리 연구에서, 이것은 Martin에서 나온 것이 아닙니다. 우리는 2011년경 Google 특허에서 렌더링 및 레이아웃에 대한 첫 번째 언급을 보기 시작했습니다. 그리고 제 개인적인 이론은 이것이 Google Panda 콘텐츠 품질 업데이트와 그 모든 멋진 것들에 대한 이유입니다. 그 날짜 즈음에 일어나기 시작했습니다.

그리고 많은 새로운 발견이 있습니다. 이것은 Google이 레이아웃과 렌더링을 모두 보는 방식에 대한 상당히 새로운 분야이며, 여기에서 Martin과 조금 더 친근하게 만들 수 있기를 바랍니다. 그래서 이것이 오늘날의 목표입니다 – 이것을 가능한 한 간단하고 사용 가능하며 실용적으로 만드는 것입니다.

내가 언급했듯이 이 주제와 관련하여 얻은 대부분의 Google 특허는 이것이 실제로 시작된 방식이며 레이아웃에 중점을 둡니다.

레이아웃이 상당히 중요한 것 같습니다. 예를 들어 스크롤 없이 볼 수 있는 부분에 표시되는 텍스트가 더 중요하며 페이지의 일부 요소가 다음과 약간 다른 역할을 한다고 알려 주는 많은 특허가 있습니다. , 스크롤 없이 볼 수 있는 부분에 있는 광고 또는 텍스트.

이것이 하나입니다. 우리는 Jason이 언급한 것처럼 JavaScript SEO에 몇 년 동안 초점을 맞추었습니다. 그리고 더 깊이 들어가면 JavaScript SEO가 대부분 "Google에서 귀하의 콘텐츠를 제대로 볼 수 있습니까, JavaScript를 HTML로 변경할 수 있습니까?"와 같은 것이라는 것을 깨달았습니다. 하지만 조금 더 깊이 파고들자 이것이 빙산의 일각에 불과하다는 것을 알았습니다.

Google이 콘텐츠를 렌더링하는 방식과 레이아웃을 보는 방식의 많은 측면은 크롤링, 렌더링 및 인덱싱의 초기 단계 이후에 발생하는 대부분의 SEO에 영향을 미칩니다.

그래서 우리는 에이전시로서 JavaScript SEO 분야에서 조금 벗어나 훨씬 더 복잡하고 흥미로운 Rendering SEO에 뛰어들었습니다. 그래도 오늘은 간단하게 하려고 합니다. 제이슨, 당신이 경비원이 되어야 합니다.

매우 흥미로운 것들이 많이 있습니다. 우리는 Martin으로부터 정확한 답변을 얻지 못할 것입니다. 그는 이 슬라이드를 싫어합니다. 죄송합니다. Martin.

Google에서 스크립트를 방해할 것이라고 언급한 내용이 있습니다. 흥미롭고 펑키한 작은 부분이 많이 있습니다. 하지만 기술 SEO에 익숙하지 않은 모든 사람들을 위해 레이아웃 및 렌더링 SEO가 중요한 이유를 알려드리기 위한 것입니다. 때때로 Google은 귀하가 게시한 전체 페이지를 선택하지 않습니다.

따라서 URL의 색인이 생성된 것을 보고 있다고 해서 Google이 전체 색인을 생성했다는 의미는 아닙니다. 이것은 렌더링, 품질, 기술로 인한 것일 수 있으므로 매우 다채롭고 흥미진진합니다.

오늘 이야기할 때 언급하고 싶은 것은 웹사이트의 네 가지 음영이 있다는 것입니다. 우리 중 많은 사람들이 콘텐츠를 은폐합니다. 콘텐츠가 이제 모바일에서 JavaScript가 있는 경우와 없는 경우가 다르기 때문입니다. 이는 오늘날 대부분의 웹사이트에 적용됩니다. 따라서 React 또는 Angular 기반 웹사이트뿐만 아니라 WordPress도 마찬가지입니다. , Wix, 아마도 Duda, 그리고 대부분의 단순한 프레임워크. 데스크탑에서도 동일한 문제가 있습니다. 따라서 콘텐츠와 상호 작용할 수 있는 다양한 방법이 있으며 이는 대부분 렌더링 때문입니다. 이 코드가 최종 장치에서 어떻게 렌더링되는지입니다.

더 이상 고민하지 않고 시작하겠습니다. 마틴이 여기 있으니 시간을 너무 많이 들이지 않겠습니다.

어떻게 든 시작하기 위해 첫 번째 질문이 있습니다. Martin, SEO 렌더링이 순위를 높이는 데 도움이 될까요? 나는 이것이 모든 사람의 머리에 있는 첫 번째 질문이라고 가정합니다.

실용적입니까? 트래픽, 리드, 재미있고 멋진 모든 것을 얻을 수 있습니까?

Martin: 제 말은, 저는 보통 순위 질문에 답하지 않습니다. 여기서는 예외로 하겠습니다.

일반적으로 말해서 – 아닙니다. 그러나 구체적으로 말하면, 무언가가 렌더링을 깨고 콘텐츠가 표시되지 않는 문제가 있는 경우 Googlebot이 콘텐츠를 보지 않거나 제대로 보지 못한다면 실제로 다음과 같은 의미에서 당신에게 해를 끼칠 수 있습니다. , 내용을 볼 수 없습니다.

따라서 페이지의 색인을 생성하지 않을 수 있습니다. 또는 페이지의 색인을 생성하지만 관심 있는 콘텐츠에 대한 순위는 지정하지 않을 수 있습니다. 예, 결국에는 차이를 만들고 영향을 미칠 수 있습니다. 물론 그렇습니다.

Bartosz: 청중의 질문에 대해 알아보기 전에 한 가지 하고 싶은 것은 여기에서 렌더링이 전체 시나리오에 포함됩니까?

닭과 달걀 중 첫 번째 시나리오에 빠르게 들어갈 수 있지만 Google이 항상 대기열을 만든 다음 크롤링하고 렌더링하고 선택적으로 페이지의 색인을 생성한다는 사실을 이해했습니다. 너무 단순화한 것입니까?

Martin: 그것은 약간 지나치게 단순화하지만 근본적으로 사실입니다. 그래서 우리는 많은 URL을 얻었고 너무 많은 URL을 얻었기 때문에 명백한 이유로 동시에 모든 것을 크롤링할 수 없었습니다. 좋아, 나는 명백한 이유로 말하지 말아야 한다. 대역폭 문제로 인해 모든 URL을 항상 동시에 크롤링할 수는 없으므로 사용할 수 있는 인터넷 대역폭이 너무 많습니다.

온라인 상점이 있고 내일 새로운 온라인 상점 웹사이트로 온라인에 접속하고 백만 개의 제품 URL이 있는 경우 이 모든 URL을 동시에 크롤링하면 서버가 다운될 수 있으므로 시간을 두고 이를 확산해야 합니다. , 따라서 URL을 발견하는 것과 실제로 크롤링되는 URL 사이에 대기열이 있습니다.

이 대기열은 URL이 마지막으로 크롤링된 시간을 Search Console에 표시하고 서버에서 알려주는 방식으로 투명하다는 점에서 상대적으로 투명합니다. Googlebot 사용자 에이전트 및 IP에서 이 URL에 대한 마지막 요청이 언제인지 확인할 수 있으므로 매우 투명한 대기열입니다.

그런 다음 크롤링되면 수신한 HTML과 HTTP 상태를 확인할 수 있습니다. 404 상태이면 처리가 거의 여기서 끝납니다. noindex라는 로봇 메타 태그가 있으면 여기에서 작업도 끝납니다.

그러나 많은 HTML 콘텐츠를 얻고 이를 처리하고 파이프라인의 나머지 부분을 계속 진행할 수 있다면 JavaScript 실행을 위해 페이지를 대기열에 추가합니다. 이를 "렌더링"이라고 합니다. 두 번째 대기열은 매우 불투명합니다. 어떤 의미에서는 렌더링하는 데 시간이 얼마나 걸리는지 실제로 알 수 없습니다. 렌더링할 때 렌더링할 때 알지 못합니다. 이론적으로 우리는 이 모든 것을 트랜잭션 프로세스로 봅니다. 입수에는 우리가 발견한 URL이 있고 그 결과는 색인이 생성된 문서 또는 색인이 생성되지 않은 문서입니다. 여기에서 일어날 수 있는 일입니다.

그리고 대기열 위치를 변경하거나 무엇을 렌더링하거나 무엇을 렌더링해야 하는지 파악하는 측면에서 렌더링에 대해 할 수 있는 일은 많지 않습니다. Search Console에서도 크롤링된 페이지 보기 를 보면 렌더링 결과가 무엇인지 알 수 있습니다. 따라서 건너뛴 추가 대기열이 없으며 단순화된 모델이 반드시 적용되지 않을 수 있는 몇 가지 복잡한 문제가 더 있습니다. 그러나 흐름이 일반적으로 검색, 크롤링, 큐잉, 렌더링, 인덱싱 및 나중에 잠재적으로 순위 지정을 수행한다고 가정할 수 있습니다.

제이슨: 정말 명확합니다.

Bartosz: 온라인에서 이 주제가 다루기 전에 페이지를 렌더링하고 JavaScript도 언급했지만 이전 대화에서 얻은 것은 렌더링이 단순히 자바스크립트.

마틴 : 아, 맞아요.

Bartosz : 따라서 JavaScript 라인이 없고 외부 스크립트에 대한 참조가 없는 것처럼 Javascript가 아닌 웹 사이트가 있더라도 렌더링에 대해서도 고려해야 합니다.

Jason: 저는 질문 을 하려고 했습니다. 우리 중 얼마나 많은 사람들이 렌더링에 대해 걱정하고 있습니까? 그 개념, JavaScript 전용이라는 생각, 우리 모두가 걱정하기 때문입니다...?

마틴 : 네. 모든 웹사이트가 렌더링되고 있고 여러분 모두가 어느 정도 우려하고 있습니다. 그렇습니다. 맞습니다. 맞습니다.

Jason : 기본적으로 JavaScript가 없으면 전혀 걱정할 필요가 없나요?

Martin : 걱정할 필요는 없지만 여전히 영향을 받고 있습니다. 렌더링의 잠재적인 의미는 여전히 있습니다.

제이슨 : 좋아, 훌륭해.

Martin : 그것은 이전에 Bartosz가 말한 것과 관련이 있습니다. 예를 들어 스크롤 없이 볼 수 있는 부분 위의 텍스트나 Google에서 귀하의 주요 콘텐츠가 어디에 있다고 생각하는지 등입니다.

제이슨 : 맞아요. 어느 것이 훌륭합니다. 기본적으로 렌더링의 일부는 페이지의 각 청크가 수행하는 역할을 이해하는 것입니다. Bartosz는 일부는 인덱싱되지 않았고 일부는 광고이고 일부는 머리글이고 일부는 바닥글인 스크린샷을 보여주었습니다. 렌더링은 Google이 페이지의 각 부분이 수행하는 역할을 결정하는 지점이므로 Bartosz가 말한 것과 관련하여 색인을 생성할지 여부와 우선 순위를 지정할지 여부에 대해 이 결정을 내릴 수 있습니다. 이것이 주요 콘텐츠입니까?

Bartosz : 맞습니다.

Jason : 하지만 기본적으로 어떻게 결정되나요?

Martin : 그렇다면 렌더링이 실제로 무엇인지에 대해 조금 이야기해야 할까요? 모든 사람들이 그 의미를 알고 있는지 확신할 수 없기 때문입니다. 맞죠? 그렇게 해야 할까요?

Bartosz : 죄송합니다, Martin. 지금은 시청 중인 모든 사람들이 당신이 지금 이해하지 못하는 모든 단일 항목에 대해 모든 질문을 할 수 있는 아주 좋은 시간입니다.

마틴 : 네!

Bartosz : Martin과 어느 시점에서 청중을 잃게 될지는 알 수 없지만 완전히 투명하게 처리하려고 하는 것은 이전 대화의 피드백이 때때로 너무 괴상하고 너무 괴상하다는 것이었습니다. , 그래서 우리는 이것을 정말 간단하게 만들고 싶습니다.

제이슨 : 훌륭하게 말했다. 렌더링 정의, 그것이 무엇이며, 프로세스는 무엇입니까?

마틴 : 맞아. HTML을 조리법으로 생각하고 거기에 모든 재료가 있으면 텍스트, 이미지, 물건이 잔뜩 있습니다. 하지만 레시피에는 실제로 포함되어 있지 않습니다. 레시피에는 만드는 방법에 대한 모든 지침이 포함된 종이 한 장이 있습니다.

웹 사이트의 리소스는 CSS, JavaScript 파일 및 비디오 이미지와 같은 구성 요소이며 실제로 페이지를 나중에 보이는 방식으로 만들기 위해 로드하는 모든 것입니다.

당신이 알고 있고 브라우저에서 사용하는 웹사이트가 당신의 브라우저에 보이는 것, 그것이 마지막 요리입니다.

렌더링은 거의 요리, 준비 과정입니다.

크롤링은 기본적으로 큰 조리법 책으로 들어가 조리법이 포함된 페이지를 꺼내어 우리 영역에 넣습니다. 기본적으로 우리는 여기 식탁에 서서 요리가 시작되기를 기다리고 있습니다. 크롤링은 기본적으로 우리에게 조리법을 건네주십시오.

그런 다음 렌더링은 렌더링이 진행되는 프로세스입니다. "아하, 재미있다! 크롤러, 저기, 이 10가지 재료를 가져다 줄 수 있습니까?” 그리고 크롤러는 편리하게 "예, 당신이 필요한 이 10가지 재료를 얻었습니다."라고 말하고 우리는 요리를 시작합니다. 그것이 렌더링입니다.

따라서 렌더링은 HTML을 구문 분석합니다. 양식 크롤링과 관련하여 기본적으로 HTML은 편리한 형식의 텍스트 묶음에 불과합니다.

실제로 웹사이트인 시각적 표현으로 만들기 위해서는 렌더링해야 합니다 . 즉, 모든 리소스를 가져와야 하고 텍스트가 말하는 내용을 근본적으로 이해해야 합니다.

예. 오, 여기 헤더가 있습니다. 자, 그럼 거기에 이미지가 있고, 이미지 옆에 많은 텍스트가 있고, 이미지 아래에 또 다른 제목이 있습니다. 더 작은 제목, 더 낮은 수준의 제목이 기본적으로 들여쓰기되어 있습니다. 콘텐츠의 구조, 그 다음에는 비디오가 있고, 비디오 아래에는 더 많은 텍스트가 있고 텍스트에는 여기, 여기, 여기로 가는 3개의 링크가 있습니다.

그리고 이 모든 조립 프로세스, 이것이 무엇인지 이해하고 브라우저 창 내에서 상호 작용할 수 있는 시각적 표현으로 조립하는 것, 즉 렌더링입니다.

그리고 렌더링의 일부로 첫 번째 단계에서 JavaScript를 실행합니다.

JavaScript는 기본적으로 조리법 내의 조리법이기 때문에 JavaScript는 "이제 양파를 자르십시오"와 같을 수 있습니다. 그래서 양파인 원재료가 있습니다. 하지만 양파를 접시에 통째로 넣지 않고 잘라냅니다. 이것이 JavaScript가 필요한 것입니다.

따라서 JS를 실행하지 않고 리소스를 가져오기만 하면 실제로 양파를 자르거나 계란을 깨서 깨서 무언가에 휘젓는 단계를 실제로 수행하지 못할 수 있습니다.

내가 방금 저녁을 먹었고 지금 정말 배고프다고 말할 수 있습니까? 정말 죄송합니다!

그리고 JavaScript 실행은 렌더링의 일부일 뿐이지만 JavaScript 실행이 완료되거나 JavaScript 실행이 없는 경우에도 괜찮습니다. 하지만 그런 다음에는 이러한 비트와 조각과 필요한 방법을 조합하여 파악하고 있습니다. 예를 들어, 페이지에 그것들을 조합하면 레이아웃 트리라고 불리는 것으로 이어지며, 레이아웃 트리는 우리에게 그것들이 얼마나 큰지, 페이지의 어디에 있는지, 그것들이 보이는지 보이지 않는지, 한 가지가 다른 것 뒤에 있는지 알려줍니다. .

이 정보는 JavaScript를 실행하는 것만큼이나 우리에게도 중요합니다. JavaScript는 서버에서 전달된 초기 HTML에 없는 내용을 변경, 삭제 또는 추가할 수 있기 때문입니다.

간단히 말해서 렌더링입니다. "HTML이 있습니다."에서 "화면에 잠재적으로 많은 픽셀이 있습니다." 렌더링입니다.

Bartosz : Martin이 Google에서 일하기 때문에 말하지 않을 몇 가지를 추가하고 싶습니다. 기술적인 SEO 측면에서 볼 때 렌더링은 비용이 많이 듭니다. 렌더링이 Google에 정확히 어떤 영향을 미치는지는 큰 미스터리이며 이것은 우리가 계속 연구하는 부분이며, 이를 수행하는 도구인 별도의 회사를 출범시키기까지 했습니다. 간단히 말해서 렌더링은 모바일 장치의 경우 Google에 상당히 비쌉니다. Alcatel 1X와 같은 구형 전화기, 아마도 더 저렴한 전화기를 가지고 있다면 많은 JavaScript를 제공하는 BBC, The Guardian과 같은 웹사이트와 어려움을 겪을 것입니다. 이는 구글이 고군분투할 부분이기도 하다. 그러나 간단히 말해서 렌더링은 비용이 많이 듭니다. 그리고 경험상 일부 스크립트, 일부 웹사이트는 Google에 최적으로 렌더링되지 않으며 여러 가지 이유로 인해 제대로 선택되지 않습니다.

여기에서 Rendering SEO가 필요합니다. 여기 에서 이 주제에 대한 경험이 있는 개발자 팀이나 기술 SEO 팀과 이야기할 수 있습니다. 그리고 당신은 그들에게 아마도 내 페이지가 내가 원하는만큼 빨리 선택되지 않을 것이라고 말하고 있습니다.

렌더링과 인덱싱 모두에 대한 문제의 징후로 자주 보게 되는 것은 매우 동적인 웹사이트가 있고 자바스크립트가 많고 콘텐츠가 매우 느리게 선택되는 것입니다. 예를 들어, 부동산 웹사이트에 새 목록을 게시하고 Google은 3주 후에 이를 선택하고 경쟁업체는 하루 후에 선택하는 것을 볼 수 있습니다. 그리고 그것은 우리가 앉아서 여기서 무슨 일이 일어나고 있는지 살펴보는 시나리오입니다. 왜 Google은 이 측면에서 고군분투하고 있습니까?

이 마틴에 대해 어떻게 생각하세요?

Martin : 나는 여기서 흥미로운 순간 을 만들기 때문에 질문을 좋아합니다 .

생각해보면 이 경우 Google 검색은 실제 사용자와 똑같은 어려움을 겪고 있기 때문입니다. 실제 사용자의 경우 최신 전화를 사용하고 정말 빠르고 환상적이며 비싼 전화를 사용하더라도 더 많은 실행은 항상 더 많은 전력 소비를 의미하기 때문입니다.

자바스크립트를 인터넷의 CO2라고 부르는 사람들이 있었습니다. 나는 그것이 완전히 잘못된 것이라고 생각하지 않습니다. 아주 훌륭하고 적절한 비교입니다.

여기 Google 검색이 있으며 실제로 귀하의 웹사이트를 사용하는 사용자가 있습니다. 우리는 같은 배를 타고 있습니다. 비용이 많이 들수록 경험이 더 나빠집니다. Google 검색은 크게 신경쓰지 않고 필요한 리소스에 투자하기만 하면 되며 가능한 한 적은 시간과 에너지를 낭비하지 않도록 많은 최적화를 수행합니다. 그러나 분명히, 최적화하는 경우 좋은 부작용은 사용자가 배터리가 덜 필요하기 때문에 더 행복해질 것이고, 이전 휴대전화는 귀하가 제공한 것과 여전히 잘 작동하며 소비할 수 있다는 것입니다. 귀하의 웹 콘텐츠는 귀하의 경쟁자가 아닐 수도 있습니다. 귀하의 경쟁자는 관심을 갖지 않고 실제로 휴대전화에서 사용하기에 덜 편리한 무언가를 생산하기 때문입니다. 따라서 이것은 Google과 UX를 비교하는 것이 아니라 동일한 문제 또는 동일한 도전과제이며 Google 검색을 포함하여 우리 모두가 직면하고 있으므로 좋은 것입니다.

Jason : 내 관점에서 보면 최적화, Google이 더 쉽게 만들 수 있도록 하는 것입니다. Google이 우리에게 제공하는 보상은 무엇입니까? 단순히 더 빨라서 동시에 더 많은 작업을 수행할 수 있습니까?

Martin : 그렇지 않습니다. 렌더링은 외부에서 발생하기 때문에 렌더링은 비동기식입니다. 즉, 렌더링이 발생할 때까지 기다렸다가 처리하는 것이 아니라 기본적으로 최대한 많은 병렬 작업을 수행하려고 합니다. 예를 들어, 구조화된 데이터가 초기 HTML에 있는 경우 크롤링 직후에 렌더링이 진행되는 동안 이를 선택할 수 있으므로 거기에서 약간의 이점을 얻을 수 있습니다. 실제로 더 큰 이점을 얻을 수 있습니다.

콘텐츠가 지속적으로 변경되는 경우 프로세스에서 가능한 한 빨리 이를 사용할 수 있도록 하고 표준, 제목, 메타 설명, 구조화된 데이터도 마찬가지이며 가능한 한 빨리 선택하는 것이 좋습니다. 더 자주 또는 더 빠르게.

Jason : 예, 빠를수록 픽업할 확률이 높아집니다. 도착하기 전에 내릴 확률은 낮아집니다.

그리고 당신은 스키마 마크업에 대해 언급했고 레이아웃 트리에 대해 이야기하고 있었습니다. 그리고 이 레이아웃 트리가 들어오고 스키마 마크업이 잠재적으로 해당 레이아웃 트리의 일부이고 기본적으로 이것이 스키마라고, 이것이 바로 이것이다 광고, 이것이 헤더입니다. 맞습니까? 스키마가 그 일부입니까?

Martin : 스키마는 시각적 요소가 아니기 때문에 레이아웃 트리의 일부가 아닙니다. 따라서 시각적으로 또는 잠재적으로 보이는 모든 것은 레이아웃 트리의 일부입니다. 스키마 마크업은 절대 표시되지 않습니다.

많은 나무가 관련되어 있으며 모두를 혼란스럽게 만들고 싶지 않습니다. 기본적으로 텍스트가 있는 첫 번째 순간에 이를 개별 요소로 나누고 문서 개체 모델을 생성합니다. 이것이 바로 사람들이 참조하는 DOM입니다. DOM은 기본적으로 브라우저가 말하는 방식입니다. 그래서 나는 이 제목을 가지고 있습니다. 그 안에 텍스트가 있고, 그것은 이 트리의 또 다른 노드입니다. 그런 다음 여기에 이 ​​텍스트 블록이 있습니다. 그리고 텍스트 블록 내부에 텍스트가 있는 링크가 있습니다. 링크, 그리고 여기 이미지가 있습니다. 이것이 페이지에 있는 모든 것입니다. 여기에는 스키마 마크업과 모든 메타 태그, 제목 및 모든 것이 포함됩니다.

메타 정보, 스키마, JavaScript 및 CSS와 같이 보이지 않는 모든 것은 레이아웃 트리의 일부가 아닙니다. CSS는 그 효과에 의해 간접적으로 트리로도 구문 분석됩니다. 좋은 측정을 위해 CSSOM도 있으며 이는 HTML의 경우와 정확히 같지만 CSS의 경우입니다. 그리고 DOM에 매핑하여 CSS에서 스타일을 지정한 DOM 요소, HTML 요소의 모양을 만듭니다. 그러나 그 자체로는 레이아웃 트리에 표시되지 않습니다.

Jason : Bartosz, 인덱싱되지 않은 요소를 표시하고 있었습니다. 그리고 그것은 아마도 레이아웃 트리일 것입니다. 인덱싱 단계에 도달하기 전에 결정을 내리는 것입니다. "우리는 그것을 원하지 않습니다. 흥미롭지 않거나 너무 길거나 너무 가볍지 않습니다." Bartosz는 그렇게 이해하고 있습니까?

Bartosz : 콘텐츠의 일부가 인덱싱되지 않는 데에는 여러 가지 이유가 있습니다. 항상 렌더링의 잘못은 아니며 염두에 두어야 할 핵심 사항입니다.

때로는 부분적으로 렌더링의 잘못입니다. 데스크톱에서는 보이지만 모바일에서는 보이지 않는 콘텐츠를 보면 렌더링 때문이지만, 문제는 Google에서 이를 잘못된 방식으로 렌더링한 것이 아니라 데스크톱과 모바일에서 동일한 콘텐츠를 표시하지 않는다는 것입니다. 예를 들어 전자 상거래 상점과 같이 매우 자주 발생하는 모바일의 경우.

따라서 여러 가지 이유가 있을 수 있으며 Martin이 확인하거나 부인해야 하는 이유가 여러 가지 있을 수 있습니다. 우리는 Google이 콘텐츠와 관련이 없거나 실제로 중요하지 않은 페이지 요소를 건너뛴다고 가정합니다. 따라서 콘텐츠가 있는 경우 이것이 지난번에 Martin이 개에 대해 이야기한 내용이라고 생각합니다. 아래에는 "유사한 항목"과 같은 자전거 광고가 많이 있지만 Google에서 선택하지 않는 경우가 많습니다. 그리고 이것이 일어나는 이유는 아마도 Martin이 조금 더 많은 지식을 가지고 있기 때문일 것입니다.

Martin : 그건 렌더링이 아니라 우리가 콘텐츠를 분석하는 것뿐입니다. 우리가 이에 대해 공개적으로 말한 것이 무엇인지 모르지만 팟캐스트 에피소드 중 하나에서 언급한 것 같습니다 . 예를 들어 중심 주석이라는 것이 있고 우리가 보는 곳에 몇 가지 다른 주석이 있습니다. 시맨틱 컨텍스트와 잠재적으로 레이아웃 트리에서.

그러나 기본적으로 우리는 이미 HTML의 콘텐츠 구조에서 그것을 읽고 알아낼 수 있습니다. "여기에 있는 전체 텍스트 콘텐츠에 대해 수행한 모든 자연어 처리에서 볼 수 있듯이 주로 주제 A인 개 사료에 관한 것 같습니다. 그리고 여기에 관련 링크로 보이는 다른 것이 있습니다. 제품이지만 실제로 중심 부분이 아니며 여기에서 실제로 주요 콘텐츠가 아니며 추가 항목인 것 같습니다. 그런 다음 많은 상용구가 있습니다." 그래서 우리는 메뉴가 이 모든 페이지에서 거의 동일하게 보인다는 것을 알아냈습니다. 이것은 이 도메인의 다른 모든 페이지에 있는 메뉴와 같거나 이전에 본 적이 있습니다.

우리는 실제로 도메인이나 "아, 이것은 메뉴처럼 보입니다."라고 말하지 않습니다. 우리는 상용구처럼 보이는 것과 가중치가 다르게 적용되는 것을 알아냅니다.

따라서 나머지 콘텐츠의 주요 주제와 관련이 없는 콘텐츠가 페이지에 있는 경우 생각만큼 고려하지 않을 수 있습니다. 우리는 여전히 해당 정보를 링크 검색 및 사이트 구조 파악 및 그 모든 것에 사용하지만 귀하의 페이지에 개 사료에 대한 10000단어가 있고 자전거에 2000-3000단어가 포함되어 있다면 이는 아마도 자전거에 좋은 콘텐츠가 아닐 것입니다.

Jason: Semantic HTML5가 어떤 식으로든 도움이 됩니까?

Martin : 그것은 우리에게 도움이 되지만 우리가 찾는 유일한 것은 아닙니다. 그렇습니다.

제이슨 : 맞아요. 그것은 약간의 도움이 되지만 추측할 수 있기 때문에 전체 사이트를 재구축해야 하는 중요한 것은 아닙니다.

마틴 : 네.

Bartosz : 따라서 이 주제를 닫고 앞으로 나아가기 위해 때로는 관련 항목과 같은 해당 콘텐츠의 일부도 볼 수 있습니다. 이는 종종 JavaScript에 의존합니다. 많은 JavaScript에서 매우 자주 사용됩니다.

다시 한 번 경험상 비슷한 항목의 캐러셀과 같이 요소가 매우 무거워 페이지 가치에 전혀 도움이 되지 않는 경우가 있습니다. 렌더링해야 할 작업이 많고 결국 가치가 없기 때문입니다.

당신은 또한 합니까, 때때로 무게를 측정합니까, 당신이 가지고 있습니까, 이것은 대답하기 매우 어려운 질문이 될 것입니다, 당신은 괜찮다고 말할 알고리즘이 있습니까? 이것은 렌더링하는 데 많은 비용이 들지만 그렇게 하지는 않습니다 많은 가치가 있으므로 건너뛰어야 합니다. 얘기할 수 있는 일인가요? 이것이 우리가 피해야 하는 질문인지 잘 모르겠습니다.

Martin : 피해야 할 질문이 아니라 흥미로운 질문입니다.

내가 말할 수 있는 한, 아니요. 우리는 "오, 이것은 렌더링하기에 무거우며, 많은 가치를 추가하지 않기 때문에 건너뛸 것입니다."라고 생각하는 것은 흥미로운 경험적 방법이 될 수 없지만 지금으로서는 그렇게 하지 않는다고 생각합니다. 그러나 우리가 하는 일은 결국, 그리고 결국은, 매우 구체적이고 명확하지 않은 컷오프 순간이 없기 때문에 여기서 의도적으로 모호하게 말하는 것입니다. 사람들이 이치에 맞지 않는 일에 집중하는 것을 원하지 않습니다.

우리가 "좋아, 이것은 충분히 오랫동안 렌더링되어 왔으며 우리가 좋다고 생각합니다."라고 말하는 순간이 있습니다. 다시 많은 경험적 방법이 있지만 기본적으로 실제 사용자가 "이것은 너무 길다"라고 생각한다면 우리도 너무 길다고 생각할 것입니다.

그래.

Bartosz : 청중들에게 상당히 강조해야 할 점은 웨비나 이전에 우리가 이야기한 것인데, 당신이 리소스에 대해 꽤 많이 언급했다는 것입니다. Google의 삶을 더 쉽게 만들려면 어떤 리소스에 대해 걱정해야 할까요?

Martin : 솔직히 말해서 JavaScript 파일에 대해 주로 걱정할 것입니다.

Bartosz : 아니요, 서버 리소스와 같은 리소스입니다. 지난번에 설명을 아주 잘 해주셔서 관객들에게 가치를 줄 것 같아요.

마틴: 그때 내가 뭐라고 했습니까?

Bartosz: 예를 들어 CPU에 대해 걱정하는 것처럼 RAM에 대해서는 그다지 신경 쓰지 않는다고 말씀하셨습니다. 스토리지에 대해 말씀하신 내용은 기억나지 않지만 대화의 어딘가에 있었습니다. 그러나 내 가정에 따르면 CPU는 지금 조심해야 할 핵심 요소이므로 웹 사이트에서 렌더링하는 데 많은 CPU 시간이 필요한 경우 검토해야 할 사항이고 최적화해야 할 사항입니다. 그게 맞을까요?

Martin : 예, 이제 질문이 어디로 가고 있는지 알았습니다. 도움을 주셔서 대단히 감사합니다. Bartosz.

예, 원래 말했듯이 브라우저와 Google 검색에서 렌더링은 대략 화면의 픽셀로 텍스트를 가져옵니다.

마지막 부분은 Google 검색에 해당되지 않습니다. 실제로 렌더링되는 Google 검색의 일부인 Google Web Rendering Service는 픽셀에 대해 신경 쓰지 않으므로 실제 픽셀을 그리지 않습니다. 따라서 페인트가 매우 비싼 것을 본다면 기꺼이 설명하겠습니다. 혼란을 야기합니다. 페인트 비용이 매우 많이 드는 것이 있는 경우에는 이에 대해 걱정할 필요가 없습니다. 실제 GPU를 사용하여 실제로 픽셀을 페인트하는 것이 아니므로 페인트와 관련된 것은 전혀 신경쓰지 않기 때문입니다.

비싼 레이아웃은 까다롭습니다. 레이아웃이란 특히 메인 스레드에서 발생하는 레이아웃 작업을 의미합니다. 그 이유는 CPU 시간과 CPU 시간이 가장 중요하기 때문입니다. 내가 오늘날의 웹사이트에서 알 수 있는 한 그렇게 중요하지 않은 스토리지와 메모리는 CPU 리소스를 차지하기 때문에 대부분 비쌉니다.

Jason : 여기서도 한 가지 질문은 다음과 같습니다. 특정 유형의 사이트를 더 많이 볼수록 렌더링이 더 쉬워지나요? 아니면 Duda나 WordPress와 같은 플랫폼을 사용해도 결과가 없을까요? 그것이 도움이 됩니까? 아니면 완전히 상자 밖에 있습니까?

마틴 : 도움이 될 수도 있고 안 될 수도 있습니다. 그 이유는 이론적으로 플랫폼의 좋은 점은 실제 플랫폼을 최적화할 때마다 이 최적화를 무료로 얻을 수 있다는 것입니다. 그것에 대해 실제로 아무 것도 할 필요가 없으므로 좋습니다. 자신만의 것을 구축하는 경우 최적화 작업을 수행해야 하며 일부 최적화가 마술처럼 당신의 무릎에 떨어지는 일은 결코 없으며 상황이 점점 좋아지고 있습니다. 그러나 이는 거의 모든 사전 제작, 오픈 소스, 공유, 공개적으로 사용되는 CMS 또는 플랫폼에 해당됩니다. 반면에 플랫폼은 너무 광범위하고 일반적이기 때문에 일부 웹사이트에서 특정 기능을 사용하고 있을 수 있기 때문에 종종 많은 비중을 차지합니다. 여전히, 그리고 그것은 좋지 않을 수 있습니다.

Jason : 웹마스터나 개발자로서 저에게 방해가 되지 않도록 단순히 무게를 제거하는 것이 아니라도 무게를 제거하는 것이 중요합니까?

Martin : 죄송합니다. 다시 저를 지나칠 수 있습니까?

제이슨 : 자중을 말씀하시는 거군요. 제거할 수 있다면 저에게 경이적인 승리가 되는 것입니까?

Martin: 예, 하지만 플랫폼의 문제는 일반적으로 할 수 없다는 것입니다...

Bartosz : 따라서 언급한 크롤러 예산으로 조금 더 뒤로 물러설 수 있다고 생각합니다. 따라서 렌더링과 관련하여 한 가지 예를 들면 크롤러 예산을 볼 때 고려하지 않고 SEO로서 주요 HTML 파일에 관한 것이 아니라 JavaScript가 있는 경우 확장될 파일이 처리되고 10개 더 많은 파일을 요청할 것입니다. 이 파일은 모두 크롤러 예산에 들어가는 것입니다.

따라서 요청 수를 줄이는 데는 상당한 가치가 있습니다. 분명히 이것은 요청 수를 줄이고 하나의 거대한 파일을 만드는 것보다 조금 더 복잡하지만 코드, 요청 수 및 무게(기본적으로 렌더링 비용)를 단순화하는 데 많은 가치가 있습니다.

언급했듯이 Martin, 웹 사이트 중 일부는 진정한 guzzler입니다. 따라서 이러한 작업을 수행하려면 많은 리소스가 필요합니다. 그리고 그 리소스는 내가 보고 있는 것처럼 렌더링에 관한 것만이 아닙니다. 또한 수백 개의 요청이 있으며 한 파일이 다른 파일을 변경합니다. 이것은 규모로도 렌더링하기 어려울 것입니다.

Martin : 좋은 점은 웹 렌더링 서비스가 크롤링 인프라를 사용하여 리소스를 가져오기 때문에 규모에 맞게 웹을 크롤링하도록 특별히 구축된 인프라를 사용한다는 것입니다.

따라서 네트워크 부분은 최악이 아닙니다. 까다로운 점은 순서대로 하는 것입니다.

여기에 또 다른 문제 또는 또 다른 문제가 있습니다. 바로 타이밍과 규모의 문제입니다.

컴퓨터 프로그램을 작성하는 경우 프로그램은 CPU에 종속되거나 IO에 종속되는 두 가지 작업 중 하나를 수행하는 경향이 있습니다. 그게 무슨 뜻이야?

숫자 처리만 수행하는 프로그램이 있는 경우 두 개의 숫자를 입력하면 작동합니다. 파이를 가능한 한 정확하게 계산하려고 하기 때문에 파이의 1조 번째 자릿수에 도달하려고 한다고 가정해 보겠습니다.

이는 CPU에서 숫자 처리만 필요한 작업입니다. CPU는 숫자 처리를 위해 만들어졌기 때문에 매우 빠를 것이지만 우리 프로그램은 CPU 바운드라고 하는 것이 될 것입니다.

이것은 프로그램이 얼마나 빨리 실행되고 프로그램이 작업을 수행하는 데 걸리는 시간이 얼마나 많은 CPU 리소스를 던질 수 있는지에 따라 달라지며 일반적으로 IO에 종속된 것보다 더 예측할 수 있음을 의미합니다.

IO-bound은 무슨 뜻인가요?

IO 바운드는 "내 하드 드라이브, 이 CD-ROM 또는 USB 드라이브에 있는 모든 파일을 나열하는 프로그램을 작성해 주세요."라고 말하는 경우를 의미합니다.

이 프로그램은 더 이상 CPU를 통해 실행할 필요가 없으며 기본적으로 CPU에 숫자를 뒤집습니다. 그러나 이제는 실제로 내 프로그램이 외부 하드웨어, 즉 CPU 외부를 의미합니다.

CPU는 데이터를 얻기 위해 하드 드라이브, CD-ROM 드라이브, 펜 드라이브에 상관없이 요청해야 하며 데이터를 CPU가 액세스할 수 있는 장소에 넣어야 하며 CPU는 이를 읽고 찾은 데이터를 기반으로 결정합니다.

기본적으로 첫 번째 디렉토리를 읽고 디렉토리에서 첫 번째 파일을 찾아서 읽고 파일이 다시 돌아와서 이제 두 번째 파일을 읽어야 합니다. 이것이 바로 IO(입출력) 경계입니다.

The choking factor, the thing that determines how fast something can be done here is no longer the CPU, it's the input-output, how long does this take.

The fastest is… if you talk to what is called a CPU cache, that memory that's usually inside what we would call the CPU, the central processing unit, the second fastest is if you read from local memory, from RAM. The next fastest would be a local SSD drive. And so on and so forth.

Network, unfortunately, is thousands and thousands of times slower than any of these local file accesses and these are a thousand times slower than memory access, and that's thousands of times slower than the access of the cache in the CPU.

And be careful, when I say cache, I mean a very specific tiny type of memory chip.

There is another cache, which we are using because we are IO-bound, as you can imagine, we have to fetch the resources. So it's not about the CPU or executing the JavaScript.

What takes a lot of time is going to the network and fetching the JavaScript from your server and getting that back, that is always going to be thousands of times slower than having it stored somewhere on a, let's say, hard drive, on an SSD drive somewhere in our data center.

So, we have a completely different cache, not the cache I mentioned earlier, that's a CPU internal bit and piece and we don't care about that.

We have a cache where basically whenever our crawler infrastructure fetches a resource, we store it on a drive inside our data center. So we are reducing these thousands of thousands of seconds down to a few seconds. And the problem is that if you split up your application across lots of files, let's say, a dozen files, a dozen of JavaScript files specifically, then we have to fetch all of these, now we only have to fetch these once probably and we can cache them.

But what if these files constantly change? Then we can't cache them. What's worse is, you may think “Oh, that's just one big file and all of it is in one file and that's better to cache!” No!

Because if you split it up the right amount, let's say instead of dozens of files, you now have 4 files, and from these 4 files only 2 change on a daily basis or on a weekly basis, then we can use the cache for at least the other files that never change. Good job.

But if you have all of this in one big file and it will constantly change and we can never make use of our cache. So we always have to go through the much slower network – that's a consideration that's very tricky to navigate.

And I can't give you hard and fast rules or numbers for it either.

It's a case-by-case basis, you wanna figure out how much of the stuff really has to change a lot, what other stuff is kind of stable and doesn't change as much, you wanna separate these two things.

Jason : Does that also mean that the network, the slowness of the network if you're pulling in files from different sites? That also?

Martin : Yes.

Jason : Which brings us to the question from Simox Cox, which is aimed at you, Martin: what can we do to help render Google's own scripts, analytics, and fonts?

Martin : You don't have to worry about analytics, because as far as I'm aware we are skipping analytics, with fonts, I think we are skipping them as well.

Jason: So we don't have to worry about them from the rendering perspective.

Martin: No, not from the rendering perspective, let's stick with that.

Bartosz : Just to add to that, one thing, at least to my knowledge, that you don't have to worry about with that is image fetches. That's why it's worth having image dimensions in the code because WRS – Web Rendering Service – also doesn't request images.

If you think about that, if you have a lean website of just HTML, CSS, like a lean JavaScript file, this does the trick. In our experience, this can improve rendering, indexing, crawling quite a bit just by cleaning up, a little bit of code-housekeeping, let's call it that.

Jason : You said about images though, it's very interesting because from a rendering, and getting the layout tree perspective, setting the size of the image or specifying is phenomenally important, and most lazy developers like myself don't bother doing it.

Bartosz : So, if you do that, according to my knowledge, Google doesn't have to request those files. So that's quite cool because you also cut the time of those requests, and you make Google's job a bit easier. Let's go to other questions.

Jason : Johann had a question: Is the rendering stage mandatory for a page to get indexed or could it be considered for indexing without the rendering stage?

Martin : It could hypothetically happen, but in practice it normally doesn't.

Jason: So all pages need rendering, with 1 or 2 exceptions, but none of us are likely to be concerned by that specific exception.

Bartosz: So I'm assuming this comes from those two waves of indexing. So Martin, what's the status on that right now? It's complicated as far as I can remember.

Martin : So I joined Google in April 2018, I remember that. Once I did my onboarding, Google onboarding, all of that lovely, cuddly nice time that you get when you get onboarded at Google, once that was over I sat down at my desk, and then I talked to John, Maria, Tom, and eventually, they were like, “We're prepping for Google I/O” and I saw the slide deck and I looked at two waves of indexing and I said to John, “Are you sure we wanna go with that?”, and he's like, “Yes, I think that makes it clearer, what happens”, and I'm like, “Yes, okay, I can see that it's a nice and easy explanation.”

And at least I, I know that John wasn't surprised, but I was surprised by the conclusions people drew from that.

And I was like oh God, okay, lesson learned here, that was an oversimplification. It was making what happens behind the scenes to simple and it implied a bunch of stuff that were not meant to be implied, for instance there's like “Yeah, things get indexed without the rendering happening, and then the rendering happens afterwards and changes the indexing.”

Jason: But that isn't the case?

Martin: It can be in certain cases, but it's very rare. It's also my fault because I looked at it and I said, okay, that's good.

Bartosz: To be fair, we saw, and everyone in the community dealing with JavaScript saw, quite often JavaScript would change metadata. Why you'd do that is beyond me.

Anyhow, sometimes you have one title, or one meta description with JavaScript disabled, without rendering, and you have a different one when Google renders.

And we saw websites when different pages were indexed differently. And that's why many people in the SEO community were like, okay, this page is waiting for the second wave of indexing.

Anyhow, Jason, let's go with another question.

Jason: No, right, the question you were asking there, people rewriting titles, for example, people do it with Google Tag Manager because they can't get their hands on their titles because they can't get the access to it.

That is a phenomenal problem for you guys. I mean, what you're saying is, from what I understand, sometimes you pick up the original one, sometimes you pick up the one inserted by Google Tag Manager.

Martin: Yeah, yeah.

Bartosz: And this goes beyond just meta title and description. You will see JavaScript rewriting the links, rewriting the whole structure, breadcrumbs, and with this happening, this must be really difficult to index that page and crawl that page quickly and efficiently.

Jason: So maybe we can change that to the question about, when a page changes overtime with the JavaScript even as it's loading which is the case with the meta title I just gave, how much of a problem is that for Google, so we're turning that into a more general question?

Martin: Sorry, can you run that past me again?

Jason: The fact that as the page, the page loads and things change before the users even interact with it, because you coded the things in to override because you're not very good at your job. How much of a problem does that cause?

Martin: Unless you have proof that it really is a problem for you, I wouldn't worry about it.

Normally it shouldn't be that much of a problem because normally, the clearly better content and information should definitely be there after rendering and might or might not be there previous to rendering.

What is tricky is when that's not the case, one, and the other thing is coming back to what I said earlier, the earlier you can get us data, the better, and I'll append to that.

Because when you think about it, if we were having a conversation, and I tell you oh, by the way, the restaurant to the left is terrible and the restaurant on the right is really, really good, but then 10 seconds later I'm like, no, actually, the restaurant on the left is amazing, the restaurant on the right I wouldn't bother with.

What do you do with that? That's kind of the same, if I have a title and a canonical at the beginning of the process and then that changes, then which one is the right one? How do we find out?

Bartosz: One thing to remember is, if you're leaving that decision to crawlers, and I'm not only talking about Google, because that also goes to Twitter, Facebook, Bing, all the other creatures of the web, if you leave that decision to Google, you create like a layer of chaos in your structure.

Because you don't know which pages are gonna be picked up which way, and even if just some of them won't be picked up properly, which again, sorry Martin, probably I'm not helping, but we're seeing a lot of cases where the signals from your end, so you have one version with HTML, one version with JavaScript – oversimplifying – then we're seeing different artifacts when this website is being crawled and rendered and indexed.

And I think this is proper development, this is something we need to, that's why we try to talk about these topics with Martin quite a bit, because this is something in the gray area between SEOs and devs.

Because, you know, it's a very difficult topic right now, is this something that technical SEOs should focus on? Not all companies have the luxury of technical SEOs in-house. Or is it something that the dev team should worry about? I guess the main topic is to look into that.

We have a tool – What Would JavaScript Do? – and if you google the tool, you can see, okay, which elements of the page are being changed with JavaScript. So this is very simple, just do that, look into those elements, just match those two and you're good. Even if you have to depend on JavaScript.

Martin: To be the devil's advocate for the developers, if all you have is client-side rendering and there are situations where you might for some reason have to do that, then it's not super easy to provide something server-side first, like in the initial HTML, and then updating something that is missing or that's very generic into something more specific and more high-quality, with JavaScript, is still a good thing over not doing it at all.

I'm not saying it's good, I'm not saying it's optimal and I absolutely 100% agree with Bartosz that you should make it match, but if you really can't, it is a way of doing things, it's just more shaky and error-prone than if you can avoid that.

Jason : One question many people are asking is, do authoritative sites get more “rendering” resources from Google or it doesn't matter?

Martin: No. You have to have this one meta tag, meta cheese=”” and then your favorite cheese, if it's the right kind of cheese and it changes weekly, then you get more rendering resources from John personally.

Bartosz: To support Martin's statement, being 100% serious right now, we're seeing websites, like home pages of newspapers, of huge eCommerce stores where you'd see main content not being picked up and we're seeing small websites indexed properly with similar technological stack, so I have to confirm, we're also not seeing like huge websites or heavily linked websites having some kind of benefit.

(…)

Bartosz : In general, something that we talked about with Martin. Rendering is so crucial with all the websites pushing so much JavaScript right now. And I guess, Martin, what would be…

Is there any way we can make rendering more interesting, more sexy in a way as SEO community?

I think this is something we talked about it so many times. We both know that rendering is so important and for the first time Google is not that black box anymore, we have so much data, Martin is available with all the answers, just… Not too many people seem to care about it.

We launched the Rendering SEO manifesto like June last year, I was thinking this would change the industry, I was thinking, this was gonna be this explosion within the industry, but this is not being picked up. And Martin, is there anything we as SEOs can do to push the envelope on this one?

Martin : That's again a tricky one because technically, I spoke to the rendering team about this, and they're like, “We like that rendering is not sexy”, and I'm like “Yeah, but there are people very worried about it and there is a bunch of stuff where you can miss out.”

I would just love people to experiment more. There are a few people in the community that are experimenting a lot, Giacomo Zecchini being one of them, I know that Dave Smart is experimenting a lot. And it's just really, really cool to see people experimenting and telling me what they're observing and checking in why what they're observing is what they're observing.

아주 간단한 예를 들어 드리겠습니다. Adam Gent는 이전에는 지원되지 않았던 JavaScript 렌더링에서 Googlebot이 지원하는 기능을 보고 있음을 공개적으로 지적한 첫 번째 사람이었습니다. 매우 기쁘다. 많은 사람들이 그것이 언제 오는지 물었고, 발표가 시간을 되돌릴 수 있거나 그것에 문제가 있을 수 있기 때문에 우리가 무언가를 분명히 미리 발표할 수 없기 때문에 나는 정말로 말할 수 없습니다. 그러나 누군가가 "이봐 Martin, 우리는 이것을보고 있습니다. 여기에서 무슨 일이 일어나고 있는 겁니까?”라고 물으면 바로 지금 이것이 일어나고 있다고 말할 수 있습니다. 우리는 항상 지속되는 Googlebot을 사용하는 렌더의 비율을 높이고 있습니다. 그리고 방금 거기에 있던 이 페이지는 실제로 항상 새로운 Googlebot을 본 페이지였습니다.

웹 작업자의 이상한 행동을 포착한 사람은 Giacomo Zecchini라고 생각합니다. 이것은 렌더링 팀과 오랫동안 이에 대해 이야기해 왔으며 "아무도 사용하지 않습니다. 그것!" 이제 사람들이 그것을 사용하기 시작했고 저는 우리가 그것을 조사해야 한다고 생각합니다.

일반적으로 중요하지 않은 흥미롭고 작은 놀라움이 많이 있습니다. 순위나 인덱싱 등의 측면에서 큰 영향을 미치지는 않지만 이를 관찰하는 것은 흥미롭습니다.

그리고 더 많은 괴짜들이 우리와 함께 하고 놀고 탐험하기를 원합니다.

Jason: 그것은 SEO의 모든 측면에 해당됩니다. 더 많이 실험하고 탐색하고 공유하면 할수록 커뮤니티에서 더 많이 배우게 되지만, 우리가 이 문제에 접근하는 방법과 우리가 스스로를 도울 수 있는 방법에 대해서도 더 많이 알게 됩니다.