SEO 업무 시간, 2022년 2월 18일

2022년 2월 18일 John Mueller 와 함께한 Google SEO Office Hours 에서 가장 흥미로운 질문과 답변을 요약한 것입니다 .

제품 리뷰 업데이트의 영향을 받는 웹사이트 유형

4:03 “[…] 제 질문은 제품 리뷰 업데이트 […]에 관한 것입니다. Google에서 페이지 또는 사이트가 제품 리뷰와 관련되어 있는지 여부를 식별하는 방법을 알고 싶었습니다. [...] 예를 들어, 전자 상거래 사이트 [...]가 있고 자신의 제품을 검토하는 블로그도 있습니다. 그들은 제품의 장단점에 대해 글을 쓰고 다른 제품을 비교합니다. [...] Google에서 [...] 이것도 제품 리뷰이며 제품 리뷰 업데이트로 분석할 수 있다고 말할까요? […]”

John이 설명했듯이 "[...] 제품 리뷰에 대한 권장 사항은 [...] 일종의 제품 리뷰와 관련이 있습니다. 따라서 Google에서 내 사이트가 제품 리뷰 사이트인지 여부를 확인하려고 하지는 않습니다. […] 그러나 오히려 이러한 모범 사례가 콘텐츠에 적용될 것이라고 생각한다면 해당 모범 사례를 실행하십시오[...]”.

인덱싱 API 사용

6:53 “[…] [Google 문서]에 Indexing API 는 채용 공고 또는 방송 이벤트와 같은 페이지에 사용해야 한다고 언급되어 있습니다. 일부 뉴스 기사나 블로그 콘텐츠와 같은 다양한 유형의 콘텐츠에 이 API를 사용할 수 있습니까?”

존은 “사람들이 시도합니다. 그러나 본질적으로 우리가 문서화한 것은 API를 사용하는 것입니다. 해당 카테고리에 해당하는 콘텐츠가 없다면 API가 도움이 되지 않을 것입니다."

EAT 및 Google의 알고리즘

10:54 “[…] EAT 는 [ Quality Rating Guidelines ] 에 언급되어 있지만 실제 알고리즘에도 작성자의 전문 지식과 같은 EAT 요소가 [포함]되어 있는지 알고 싶습니다.”

John은 다음과 같이 말했습니다. [… ] 품질 테스터가 이러한 사항을 다시 확인하도록 안내할 수 있도록 지침에 이를 넣었습니다. 그리고 그것이 중요한 것이라고 생각한다면 검색 품질 측면의 사람들도 더 알고리즘적인 방식으로 이를 이해하려고 노력할 것이라고 가정합니다.

그러나 나는 EAT 점수가 있을 것이라고 보지는 않을 것입니다. 그리고 당신은 그것에 대해 5점이나 그와 비슷한 것을 얻어야 합니다. 웹에 있는 콘텐츠의 컨텍스트를 이해하려고 하는 것이 더 중요합니다."

연결되지 않은 브랜드 언급 및 사용자 생성 콘텐츠

12:01 “[…] 사람들이 연결되지 않은 브랜드 언급[…]에 대해 말하는 것을 봅니다. [Google의] 알고리즘 […]에도 중요하다고 생각하십니까?”

링크되지 않은 브랜드 언급이란 다른 사이트에서 귀하의 브랜드를 언급하지만 귀하의 웹사이트에 대한 링크는 포함하지 않은 상황을 언급한 것입니다.

John은 다음과 같이 말했습니다: “[...] 우리는 문맥이 무엇인지 알지 못하기 때문에 그것이 다소 까다롭다고 생각합니다. 사용자가 해당 언급을 통해 귀하의 웹사이트를 찾을 수 있다면 그것은 항상 좋은 일이기 때문에 그것이 사용자에게 나쁜 일이라고 생각하지 않습니다. 하지만 누군가가 귀하의 웹사이트 이름을 언급하는 위치를 알아내려고 하는 일부 [...] SEO 요소가 있다고 가정하지는 않습니다 .”

12:58 “[...] 사용자 리뷰나 댓글은 어떻습니까? 그것이 기사나 제품의 순위 요소이기도 하다고 생각합니까?”

John은 "[...] 종종 사람들은 자신의 말로 페이지에 대해 글을 쓰며 검색 결과에 이 페이지를 표시하는 방법에 대한 정보를 조금 더 얻을 수 있습니다. 그런 면에서 댓글은 페이지에 좋은 것 같아요. 분명히, 합리적인 방법으로 그것들을 유지하는 방법을 찾는 것은 때때로 사람들이 그 댓글을 스팸하기 때문에 까다롭습니다 [...]. 웹 페이지에서 댓글을 유지하는 방법을 찾을 수 있다면 컨텍스트가 조금 더 제공되고 다양한 방법으로 검색하는 사람들이 귀하의 콘텐츠를 찾는 데 도움이 됩니다."

Googlebot 및 무한 스크롤링

24:00 "[...] Googlebot이 아직 무한 스크롤을 처리할 수 있을 만큼 충분히 발전했는지 , 아니면 최소한 콘텐츠가 계속해서 무언가를 쌓아가는 수준인지 알고 있습니까?"

존은 “ 조금 […].

페이지를 렌더링할 때 발생 하는 일은 화면이 정말 긴 경우와 같이 상당히 높은 표시 영역을 사용 하고 페이지에 표시되는 내용을 보기 위해 페이지를 렌더링하는 것입니다. 일반적으로 무한 스크롤을 트리거하는 데 사용하는 JavaScript 방법에 관계없이 무한 스크롤이 어느 정도 트리거됩니다. 거기에 로드되는 것이 무엇이든 그것이 우리가 인덱싱할 수 있는 것입니다.

[...] 무한 스크롤을 구현하는 방법에 따라 인덱스에 이 더 긴 페이지가 있을 수 있습니다. 해당 페이지에 맞는 모든 것이 있을 수는 없습니다. 무한 스크롤을 실행하는 방법에 따라 다음 페이지를 로드하는 중일 수도 있습니다. 그러면 무한 스크롤로 한 페이지에 이러한 페이지 중 2~3개를 로드할 수 있지만 전부는 아닙니다. [...] [URL] 검사 도구 를 사용하여 테스트하고 Google에서 얼마나 많은 정보를 얻을 수 있는지 확인하는 것이 좋습니다.”

크롤링 통계 보고서의 새로고침 및 검색 데이터

33:32 “Search Console [ 크롤링 통계 ] 보고서에서 크롤러 요청의 97%는 새로 고침이고 3%만 검색입니다. 이를 최적화하고 Google에서 더 많은 페이지를 검색하도록 하는 방법은 무엇입니까?”

John은 다음과 같이 응답했습니다. “[...] 더 오래되고 확립된 웹사이트에 많은 새로 고침 크롤링이 있는 것은 정상입니다 . 우리가 알고 있는 페이지의 양이 시간이 지남에 따라 증가하기 때문입니다. 그리고 들어오는 새 페이지의 양은 상당히 안정적인 경향이 있습니다. 특히 일종의 확립되고 이제 막 천천히 성장하는 웹 사이트의 경우 이와 같은 균형을 유지하는 것은 매우 일반적입니다. 대부분의 크롤링은 검색 크롤링이 아니라 새로 고침 크롤링에 있습니다.

새로운 기사가 ​​많이 들어오고 이전 콘텐츠가 매우 빠르게 관련이 없는 웹사이트가 […] 있다면 다를 것입니다 . 그러면 우리는 발견에 더 집중하는 경향이 있다고 생각합니다. […] 전자 상거래 사이트와 같은 콘텐츠가 있고 콘텐츠의 양이 천천히 늘어나고 있고 대부분의 오래된 콘텐츠가 유효하다면 [...] 새로 고침 크롤링의 양은 아마도 […] 좀 더 높아."

웹사이트 크롤링 감소

35:09 “지난 몇 주 동안 크롤링 통계가 하루에 700개에서 50개로 크게 감소한 것을 확인했습니다. Search Console 보고서에서 이 감소의 원인이 무엇인지 이해할 수 있는 방법이 있습니까? 소스 페이지 로드가 가능합니까? 크롤링 요청 분석을 올바르게 읽으려면 어떻게 해야 합니까?”

John은 Google이 웹사이트를 크롤링하는 방법과 크롤링에 영향을 미치는 요인에 대해 다음과 같이 자세히 설명했습니다. “[...] 우리가 수행하는 크롤링의 양에 몇 가지 요소가 있습니다.

[...] 우리는 검색 결과에서 최신 정보와 유용한 정보를 유지하기 위해 웹사이트에서 얼마나 크롤링해야 하는지 알아 내려고 노력 합니다. 그리고 그것은 웹사이트의 품질, 웹사이트의 변화에 ​​대한 이해에 달려 있습니다. 이를 크롤링 수요 라고 합니다.

반면에 웹사이트에서 크롤링할 수 있는 양과 관련하여 귀하의 서버, […] 웹사이트, […] 네트워크 인프라 에서 볼 수 있는 제한 사항이 있습니다. 우리는 이 둘의 균형을 맞추려고 노력합니다.

그리고 제한 사항은 두 가지 주요 사항에 연결되는 경향이 있습니다. [...] 요청에 대한 전체 응답 시간

웹사이트에 대한 […] 크롤링 중에 표시되는 […] 서버 오류의 수. 서버 오류가 많이 발생하면 크롤링 속도가 느려집니다 [...]. 서버가 느려지는 것을 확인하면 크롤링도 느려집니다 [...].

속도 측면의 어려움은 속도를 보는 두 가지 […] 다른 방법이 있다는 것입니다. 크롤링 속도를 보면 혼란스러울 때가 있습니다. 특히 크롤링 속도의 경우 서버에서 URL을 얼마나 빨리 요청할 수 있는지 살펴봅니다.

그리고 속도의 또 다른 측면은 Core Web Vitals 에 대한 모든 것과 브라우저에서 페이지가 로드되는 속도입니다. 브라우저에서 걸리는 속도는 웹사이트에서 개별 URL을 가져오는 데 걸리는 속도와 직접적인 관련이 없는 경향이 있습니다. 브라우저에서는 JavaScript를 처리하고 이러한 모든 외부 파일을 가져와 콘텐츠를 렌더링하고 페이지의 모든 요소 위치를 다시 계산해야 하기 때문입니다. URL을 가져오는 것과는 다른 시간이 걸립니다.

[...] 크롤링 속도의 변화를 진단하려는 경우 페이지가 렌더링되는 데 걸리는 시간을 확인하지 마십시오. [...] 서버에서 해당 URL을 가져오는 데 걸리는 시간을 순수하게 살펴보십시오.

다른 […]은 […] 웹사이트가 호스팅되는 위치를 이해하려고 노력한다는 것입니다 […]. 웹사이트가 한 서버에서 다른 서버로 호스팅을 변경하고 있음을 인식하면(즉, 다른 호스팅 제공업체로, […] CDN으로 이동하거나, CDN 변경 […] 문제를 일으키지 않을 것이라는 것을 알고 있는 안전한 비율을 단계적으로 다시 증가시킵니다.

웹사이트 호스팅을 더 크게 변경할 때마다 크롤링 속도가 떨어질 것이라고 가정합니다. 그런 다음 앞으로 몇 주 동안 웹 사이트에서 안전하게 크롤링할 수 있다고 생각되는 모든 항목으로 돌아갑니다. 그것은 당신이 여기에서보고있는 것일 수 있습니다.

다른 점은 웹사이트와 서버를 분류하는 방법을 결정하는 알고리즘이 때때로 업데이트될 수 있다는 것입니다. [...] 호스팅 인프라에서 아무것도 변경하지 않더라도 우리 알고리즘은 이 웹사이트가 이 서버에서 호스팅되고 이 서버가 자주 과부하되는 서버인지 알아내려고 합니다. 문제가 발생하지 않도록 이 웹사이트를 크롤링할 때 더욱 주의해야 합니다. 그것은 또한 시간이 지남에 따라 자동으로 해결되며 일반적으로 몇 주에 걸쳐 […]

[…] [Google] Search Console에서 크롤링 속도 […]를 지정할 수 있습니다. 그러면 웹사이트에 대한 특정 설정 […]이 있다는 것을 이해하는 데 도움이 되며 이를 고려하도록 노력할 것입니다. 크롤링 속도 설정의 어려움은 최대 설정이라는 것입니다. 그만큼 크롤링해야 한다는 표시가 아니라 사용자가 지정한 만큼만 크롤링해야 한다는 신호입니다. 일반적으로 이 설정은 크롤링 양을 늘리고 싶은 경우가 아니라 크롤링 양을 줄여야 하는 경우에 더 유용합니다 .

[...] 또한 할 수 있는 한 가지는 Search Console의 도움말 센터에 Googlebot 관련 문제 보고에 대한 링크가 있다는 것입니다. 웹사이트의 크롤링이 예상한 범위를 벗어나는 것을 발견하면 해당 링크를 통해 Googlebot의 문제를 보고할 수 있습니다 [...]”.

Google이 페이지에서 타겟팅하는 국가를 식별하는 방법

56:25 "[...] 지역 타겟팅에 관해서는 hreflang을 사용하는 것 외에 Google은 이 특정 웹사이트나 특정 하위 디렉토리를 대상으로 [국가]를 어떻게 파악합니까?"

John의 응답은 다음과 같습니다. “ 예를 들어 하위 도메인 또는 하위 디렉토리별로 […] 인식할 수 있는 명확한 패턴으로 URL을 그룹화하려고 합니다. 경로의 더 높은 위치에 있는 하위 디렉토리에 국가가 있는 경우 이 경로 아래의 모든 것은 이 국가를 위한 것이고 이 다른 경로 아래의 모든 것은 다른 국가를 위한 것이라고 말하는 것이 훨씬 쉽습니다.

Search Console […]에서 개별 경로를 확인할 수도 있습니다. 그러면 우리가 조금 더 쉽게 할 수 있습니다. 실제로, 나는 이것이 큰 차이를 만든다는 사람들로부터 많은 피드백을 듣지 않습니다.

[...] URL에 명확한 경로를 사용하여 개별 URL과 관련이 있는 국가를 가능한 한 [...] 명확하게 하려고 합니다. 마지막에 국가를 URL 매개 변수로 사용하는 것에 대해 누군가 제출 한 질문이 있었던 것 같습니다. 이론적으로는 그렇게 할 수 있습니다[…]. 우리 시스템의 경우 어떤 URL이 어느 국가에 속하는지 인식하기가 훨씬 더 어렵습니다 [...]. hreflang을 사용하는 경우 URL별로 이를 수행할 수 있으므로 문제가 되지 않습니다."

발견된 것으로 표시된 많은 수의 URL – 현재 인덱싱되지 않음

58:25 “[…] 우리는 거대한 전자 상거래 사이트이며 크롤링 보고서를 확인한 결과 [ 발견됨 – 현재 색인이 생성되지 않은 섹션] […]에 엄청난 양의 URL이 있음을 발견했습니다. 이것은 [우리 사이트의] [...] 문제를 나타내는 것입니까?”

John은 다음과 같이 말했습니다 . [...] 우리는 웹에서 모든 종류의 URL을 발견하고 이러한 URL 중 많은 부분을 크롤링하고 색인을 생성할 필요가 없습니다. 아마도 우리가 이미 알고 있는 URL의 변형일 수도 있고 [...] 임의의 포럼이나 스크레이퍼일 수도 있기 때문입니다. 스크립트가 귀하의 웹사이트에서 URL을 복사하여 잘못된 방식으로 포함시켰습니다. [...] 웹 전반에 걸쳐 URL의 소스가 매우 다양하기 때문에 크롤링되고 인덱싱되지 않거나 검색되고 크롤링되지 않는 URL이 많이 있는 것은 매우 정상 입니다.

[...] 샘플 […]을 다운로드하여 개별 예제를 보고 […] 해당 URL 중 관심 있는 URL과 무시할 수 있는 […] URL을 분류합니다.

[...] 당신이 관심을 갖고 있는 것들, 그것은 내부 연결과 같은 것들과 관련하여 웹사이트에서 이것들을 더 잘 묶기 위해 당신이 무엇을 할 수 있는지 알아 내려고 노력하는 것입니다. 따라서 이러한 항목이 검색되지 않는 개별 제품 또는 범주인 경우 이러한 모든 URL이 서로 더 잘 연결되도록 체계적으로 수행할 수 있는 작업을 파악하십시오. [...] 특히 더 큰 전자 상거래 사이트에서는 모든 URL을 항상 개별적으로 볼 수 없기 때문에 까다로울 수 있습니다.

그러나 때때로, 당신이 말하는 곳에서 할 수 있는 트릭이 있습니다. 첫 번째 수준 범주인 모든 것이 내 홈 페이지에서 링크됩니다. 그리고 제 첫 번째 수준 카테고리에는 최대 […] 항목이 100개 또는 200개 정도 포함되어 있는지 확인하여 Google에 크롤링 및 색인 생성을 제공하는 측면에서 약간의 강제 기능을 가질 수 있도록 합니다 . 이를 바탕으로 조금 더 체계적으로 구축할 수 있습니다.

[...] 어느 정도까지는 Google이 모든 것을 크롤링하고 색인을 생성할 수 없다는 점을 인정합니다. […] 예를 들어 […] 개별 제품이 크롤링 및 색인화되지 않는다는 사실을 알고 있다면 최소한 해당 제품에 대한 카테고리 페이지가 크롤링 및 색인화되었는지 확인하십시오. 그렇게 하면 사람들은 여전히 ​​귀하의 웹사이트에서 해당 개별 제품에 대한 일부 콘텐츠를 찾을 수 있습니다 [...].

웹사이트를 직접 크롤링할 수 있는지 확인하여 귀하의 웹사이트와 같은 웹사이트를 크롤링하는 방법에 대한 직접적인 데이터를 조금 더 얻으십시오. 다양한 크롤링 도구가 있습니다. [...] 웹사이트를 직접 크롤링하면 이러한 URL 중 어느 것이 홈페이지에서 매우 멀리 링크되어 있고 이들 중 어느 것이 귀하의 홈페이지에 더 가깝게 링크되어 있는지 확인할 수 있습니다. 그리고 이를 기반으로 때때로 사이트의 구조를 약간 조정하여 홈 페이지와의 거리와 관련하여 상황이 합리적으로 가깝거나 합리적으로 안정적인지 확인할 수 있습니다.”