SEO 업무 시간, 2022년 3월 11일

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

단일 페이지가 전체 도메인에 영향을 줄 수 있습니까?

6:50 " [...] 우리는 최근 지속적으로 상당한 트래픽과 참여를 유도하는 페이지를 사이트에 추가했습니다 [...]. 제 질문은 참여도와 트래픽이 매우 높은 단일 페이지가 도메인 전체에 영향을 미칠 수 있습니까? […] ”

John은 “ 나는 우리가 참여를 요인으로 사용하지 않을 것이라고 생각합니다. 그러나 일반적으로 웹 사이트 내의 페이지가 웹 사이트의 나머지 부분과 연결되어 있는 경우입니다. 그리고 웹사이트 전반에 걸친 내부 링크를 통해 일부 신호를 전달합니다. 따라서 페이지가 정말 좋은 페이지라는 것을 확인하고 검색에서 많이 표시하고 싶거나 다양한 외부 링크가 있을 수도 있습니다. 그러면 해당 페이지에 대한 추가 컨텍스트가 많이 제공됩니다. 그리고 우리는 그 중 일부를 웹사이트의 나머지 부분에 전달할 수 있습니다. 그래서 일반적으로 좋은 일입니다.

내가 주의해야 할 점은 그것이 당신이 관심을 갖고 있는 종류의 일에 대한 참여를 유도하는지 여부입니다. 그것은 내가 가끔 본 것입니다. 특정 검색어에 대해 페이지가 매우 잘 보일 수 있지만 검색어를 보면, 글쎄요, 나는 그것에 대해 순위를 매기고 싶지 않습니다. 내 주제는 다른 것입니다. 따라서 지표를 신중하게 살펴보기 위한 것일 수 있습니다.”

그런 다음 그 사람은 페이지의 한 섹션에서 낮은 핵심 성능 평가 점수가 나머지 도메인에 영향을 줄 수 있는지 물었습니다. 그녀가 언급한 메트릭 인 LCP(Large Contentful Paint) 및 CLS(Cumulative Layout Shift) 에 익숙하지 않다면 What Is Largest Contentful Paint 및 What Is Cumulative Layout Shift 에 대한 가이드를 읽는 것이 좋습니다 .

8:28 “[...] Core Web Vitals의 경우 제품 개선을 위해 높은 검색 페이지의 우선 순위를 지정합니다. […] LCP 또는 CLS가 불량한 페이지의 하위 집합(예: 사이트의 기본 또는 2차 또는 3차 검색 트래픽 유도 페이지가 아닌 사이트의 비디오 페이지만 사이트의 나머지 전체 핵심 핵심 성능에 영향을 미칠 수 있음) 점수? […] "

John은 “ 보통 문제가 되지 않을 것입니다. 그래서 두 가지 측면이 있다고 생각합니다. 한편으로 핵심 성능 보고서의 경우 Chrome 사용자 경험 보고서 기능 을 통해 수행되는 해당 페이지로의 트래픽 샘플을 살펴봅니다 . Chrome 측 어딘가에 문서화되어 있다고 생각합니다. 그러나 이는 본질적으로 귀하의 웹사이트로 유입되는 트래픽의 일부입니다. 즉, 대부분의 경우 우리가 가장 많이 보게 될 항목은 실제로 가장 많이 방문하는 페이지라는 것을 의미합니다. 따라서 아무도 보지 않는 임의의 페이지가 있고 페이지가 정말 느리다면 사이트가 아래로 드래그되지 않습니다 . 그리고 그 반대도 마찬가지입니다. 임의의 페이지가 정말 빠르면 사이트를 끌어올리지 않을 것입니다. 무작위 페이지가 많더라도 전반적으로 트래픽이 많지 않다면 우리는 그것에 대해 별로 신경 쓰지 않습니다. [...] 사람들이 보는 것은 좋은 사용자 경험을 제공해야 합니다. 따라서 대부분의 사람들이 사이트의 특정 부분을 보고 있다면 그 부분에 집중해야 합니다.

다른 하나는 페이지 경험 업데이트를 사용하면 웹 사이트에 대한 데이터의 양에 따라 다른 섹션으로 나눌 수 있다는 것입니다. 그리고 우리는 웹사이트에서 어떤 페이지가 본질적으로 유사한지를 이해함으로써 그렇게 하려고 노력합니다. 이는 템플릿 유형이나 이와 유사한 것일 수 있습니다. 즉, 전자 상거래 사이트의 경우 모든 제품 페이지가 정말 빠르며 제품 페이지를 볼 수 있는 충분한 데이터가 있다는 것을 알 수 있습니다. 개별적으로 페이지 그룹이 자체적으로 처리하도록 할 수 있습니다. 사이트 전체에 데이터가 충분하고 속도가 느린 다른 종류의 페이지가 있는 경우 이러한 종류의 페이지는 더 느립니다. 두 번째 부분입니다. 매우 느린 페이지 유형이 있고 해당 페이지가 이해할 수 있는 충분한 데이터가 있는 경우 웹사이트의 해당 부분만 이해하면 됩니다. Core Web Vitals 및 페이지 환경 업데이트의 영향을 받습니다. "

내부 링크가 너무 많으면 웹사이트가 손상될 수 있습니까?

12:50 " 이전 근무 시간 에 같은 페이지에 너무 많은 내부 링크를 사용하면 가치가 희석될 수 있고 Google이 사이트 구조를 이해하지 못할 수도 있다고 말한 적이 있습니다. 따라서 수백만 페이지가 있는 전자 상거래 사이트의 페이지당 이상적인 내부 링크 수는 얼마라고 생각하십니까? "

이에 존은 “ 최적의 수치는 없다고 생각한다. 내가 조심해야 할 부분은 웹사이트를 크롤링할 때 여전히 구조가 있다는 것을 인식할 수 있다는 것입니다. 특히 전자 상거래 사이트에서 여전히 인식할 수 있습니다. 여기에 기본 홈 페이지가 있습니다. 여기에 최상위 범주, 두 번째 수준 범주가 있습니다. 개별 페이지의 컨텍스트가 어떤지 명확하도록 해당 구조를 여전히 인식할 수 있습니다. . [...] 모든 페이지가 다른 모든 페이지와 연결되어 있으면 구조를 인식하기가 더 어렵습니다. 웹사이트에 수백만 개의 페이지가 있다고 해서 모든 페이지에 수백만 개의 링크가 있는 것은 아닙니다. 그런 관점에서 저는 일반적으로 전자 상거래 사이트에서 이와 관련된 문제를 보지 않습니다. 왜냐하면 전자 상거래 CMS는 어쨌든 그런 방식으로 설정되는 경향이 있기 때문에 카테고리 수준이 다르기 때문입니다. 그런 다음 특정 시점에서 개별 제품 페이지로 이동합니다. "

소규모 웹사이트의 크롤링 문제 진단

25:47 " Search Console의 크롤링 통계 보고서를 살펴보고 Google이 웹사이트를 크롤링하는 데 기술적인 문제가 있는지 확인하려고 했습니다. Google이 무언가를 크롤링하는 데 어려움을 겪거나 Googlebot이 관련 없는 파일로 인해 주의를 산만하게 하는 경우 […] "

John은 질문을 하는 사람이 상대적으로 작은 웹사이트를 관리하고 있는지 확인한 다음 이렇게 대답했습니다. " 크롤링 통계 보고서는 크롤링이 통계 보고서는 실제로 웹사이트 크롤링에 대한 집계 보기를 보고 있습니다. 그리고 일반적으로, 저는 잘 모르겠습니다. 수십만 페이지가 있는 경우에 더 의미가 있습니다. 그러면 당신은 그것을 보고 말할 수 있습니다. 오, 음, 평균적으로 크롤링이 느립니다. 반면 웹사이트에 100페이지 정도가 있는 경우에는 기본적으로 크롤링 속도가 정말 느리더라도 100페이지는 여전히 얻을 수 있습니다. 하루, 최악의 경우 일주일에 한 번. 크롤링과 관련하여 기술적인 문제는 아닙니다.

본질적으로 웹 사이트가 실제로 색인을 생성해야 하는 독특하고 가치 있는 것을 제공한다는 것을 이해하는 것이 더 중요합니다. 따라서 크롤링 측면에 대한 문제가 줄어들고 인덱싱 측면에 대한 문제가 더 많습니다. 여기에서 예외는 웹사이트에 정말 큰 기술적인 문제가 있는 경우입니다. 하지만 이러한 URL을 개별적으로 확인하고 Google에서 해당 URL을 전혀 크롤링할 수 없음을 알 수 있기 때문에 바로 알 수 있습니다. 반환된 오류가 있거나 반환된 noindex [태그]가 있습니다. 그리고 그것은 매우 명백할 것입니다. 따라서 특히 소규모 웹사이트 의 경우 Google이 웹사이트의 가치를 이해하고 가능한 한 많은 색인을 생성하는 것이 합리적이라는 것을 인지하는 것이 중요하다고 가정합니다. 크롤링 측면이 제한 요소가 되지 않기 때문입니다. 실제로 크롤링을 시도해야 한다는 사실을 먼저 Google에 설득해야 합니다. "

동의어가 순위에 영향을 미치는 이유

39:34 "동의어에 작은 차이가 [...] 순위에 큰 차이를 만드는 이유는 무엇입니까?"

그 사람은 "비디오 편집" 및 "비디오 편집기"와 같은 동의어의 예를 제시했습니다.

John은 이렇게 대답했습니다 . 쿼리. 특히 동의어와 관련하여 우리는 어떤 것이 대부분 동의어라고 가정할 수 있지만 그것이 완전히 동의어라는 의미는 아닙니다. 그리고 특히 "비디오 편집" 대 "비디오 편집기"와 같은 것을 볼 때 사용자 측의 기대는 약간 다릅니다. 한편으로는 비디오를 편집하고 싶습니다. 반면에 비디오 편집기를 다운로드할 수도 있습니다. 그리고 매우 비슷해 보이지만 거기에서 사용자가 원하는 것은 약간 다릅니다. 그래서 제 관점에서는 그런 종류의 우리가 다른 순위를 보여줄 것이라는 것이 합리적입니다. 그리고 우리는 단어의 철자가 약간 다를 때도 마찬가지입니다. 예를 들어 영어 단어의 영국식 또는 미국식 버전이 있고 액센트가 있는 단어나 문자가 있고 액센트가 없는 경우 이러한 항목이 대부분 동일하다는 것을 이해하지만 또한 그것들이' 약간 다릅니다. 그리고 그런 점을 고려한 검색 결과를 보여주려고 합니다.”

페이지에서 여러 리치 결과 유형 결합

42:06 “ 우리 나라에서는 대부분의 레시피 웹사이트가 그다지 유용한 정보를 제공하지 않는 것을 보았고 더 유용한 정보를 제공하고 모든 레시피에 FAQ를 추가하는 지점으로 이동하여 이를 변경하려고 합니다. 이러한 FAQ를 추가하는 가장 좋은 방법은 무엇입니까? "

John은 “[...] 내 관점에서 그것은 전적으로 당신에게 달려 있습니다. 페이지와 잠재적으로 관련성이 높은 리치 결과 유형이 여러 개 있는 이와 같은 경우에 제가 주의해야 할 점은 이러한 유형 중 일부는 결합할 수 있고 일부는 실제로 결합할 수 없다는 것입니다. 잘. 조리법에 관해서는 언제 조합할 수 있는지, 아니면 본질적으로 둘 중 하나를 선택해야 하는지 구체적으로 모르겠습니다. 그리고 다른 레시피 웹사이트에 레시피 리치 스니펫과 하단에 FAQ 섹션이 없는 것을 알게 된다면 아마도 우리는 그것들을 결합할 수 없을 것입니다. 그런 다음 실제로 표시하고 싶은 리치 결과 유형의 유형을 선택하고 해당 유형에만 집중하는 것이 더 나을 것입니다. "

페이월이 클로킹 페널티를 유발하지 않도록 하는 방법

43:43 " Google은 구독 및 페이월 콘텐츠 가이드라인에서 페이월 콘텐츠를 색인에 공유하고 클로킹 패널티를 유발하지 않으려면 특정 스키마를 페이지에 추가해야 한다고 설명합니다. 그러나 이것을 구현한 후 리치 결과 테스트는 이를 식별하지 못하는 것 같고, 우리가 부주의하게 은폐 패널티를 위험에 빠뜨리는 것 아닙니까?”

John은 다음과 같이 말했습니다. "리치 결과 테스트가 이를 표시한다고 가정하지만, 대부분의 경우 리치 결과 테스트는 Google이 검색 결과에 리치 결과 유형으로 실제로 표시할 내용에 초점을 맞추기 때문에 실제로 확인하지 않았습니다. . 그리고 본질적으로 페이월 콘텐츠는 특정 리치 결과 유형으로 표시할 항목 중 하나가 아닐 수 있습니다. 그래서 우리가 그 테스트에서 그것을 보여주지 않을 가능성이 있습니다. 그렇게 하는 한 가지 간단한 방법은 매우 간단한 테스트 페이지를 만들고 해당 페이지를 개별적으로 테스트하는 것입니다. Google이 마크업이 있는 전체 콘텐츠를 실제로 보고 있는지 확인하기 위해 수행할 수 있는 다른 테스트는 페이지의 라이브 스케치를 수행하고 해당 페이지에 대해 생성된 HTML을 볼 수 있는 일반 URL 검사 테스트입니다. 페이지. 그리고 그것을 편집기로 복사하고 거기에 표시하려는 구조화된 데이터가 실제로 표시되는지 다시 한 번 확인할 수 있습니다. 그래서 그런 방향으로 가고 있습니다.”

페이지의 특정 섹션에 있는 링크가 Google에 더 중요합니까?

45:11 “ [...] 사이트의 특정 섹션에 있는 링크가 다르게 표시됩니까? 예를 들어 페이지가 머리글 또는 바닥글 내에 연결되어 사이트의 모든 페이지에 포함된 경우 Google은 해당 링크를 페이지 본문 내의 링크와 다르게 표시합니까? "

John은 " 우리는 거기에서 실제로 구별하지 않습니다. 따라서 [페이지]가 페이지 바닥글에 연결되어 있고 전체 웹사이트에서 연결되어 있다면, 우리의 관점에서 보면 전체 웹사이트에서 해당 링크를 갖게 됩니다. 바닥글에 있는 링크의 가중치가 적거나 유용하지 않거나 무시하거나 이와 유사한 경우가 아닙니다. 따라서 이러한 관점에서 링크의 경우 본질적으로 페이지의 링크로 간주됩니다.

페이지의 주요 콘텐츠가 무엇인지 이해하려고 한다는 점에서 텍스트의 경우 약간 다릅니다. 그리고 웹사이트의 다른 콘텐츠와 비교하여 순위를 매길 때 페이지의 주요 콘텐츠 섹션에 중점을 두려고 노력할 것입니다. 그러나 우리의 관점에서 링크는 사이트 구조를 더 잘 이해하는 데 도움이 됩니다. 그리고 그것들이 머리글이든 바닥글이든, 사이드바에 있든, 메인 콘텐츠에 있든 그것은 우리에게 실제로 아무 것도 변경되지 않습니다. "

모바일 우선 인덱싱이 순위를 높이는 데 도움이 됩니까?

46:33 “ 모바일 퍼스트 인덱싱이 검색 순위에 도움이 되나요? 우리 웹사이트는 여전히 Googlebot 데스크톱에 의해 크롤링되고 있습니다. 그리고 모바일 우선으로 전환하지 않는 이유를 알 수 없습니다. 우리는 Google 문서와 문제 해결을 살펴보았지만 아무 것도 튀어나오지 않았습니다. 프로그레시브 웹 앱 및 오프라인 지원으로 전환하는 것이 도움이 될까요 ? "

이에 존은 “ 그래서 우선 모바일 퍼스트 인덱싱은 순위에 영향을 주지 않는다. 따라서 모바일 우선 인덱싱으로의 이동을 강제할 필요는 없습니다. 그것은 순전히 우리가 웹사이트에서 사용할 콘텐츠를 인덱싱하고 선택하는 문제입니다. 그래서 그런 관점에서 나는 이것에 대해 걱정하지 않을 것입니다. 귀하의 웹사이트가 모바일에서 제대로 작동한다면 어느 시점에서 전환될 것입니다. 아직 전환하지 않은 사이트가 남아 있다고 생각합니다. 그러나 대부분의 경우 대부분의 사이트를 전환했습니다. 그리고 남은 것들은 계속해서 다시 확인합니다. 그들이 준비되고 우리가 그들이 준비되었다고 생각되면 우리는 그것들을 바꿀 것입니다.

그러나 모바일 버전이 데스크톱 버전과 크게 다르지 않는 한 순위 변경을 확인할 수 있는 경우는 아닙니다. 그리고 그것이 우리가 모바일 우선 인덱싱으로 전환하지 않는 이유이기도 합니다. 모바일 버전이 크게 다르고 사이트에 대해 모바일 우선 인덱싱을 사용한 경우 기본적으로 모바일 버전을 기반으로 콘텐츠를 인덱싱합니다. 데스크톱 버전에 더 많은 콘텐츠가 있는 경우 무시합니다. 그런 관점에서 나는 이것을 강요하지 않을 것입니다. 프로그레시브 웹 앱으로 이동하는 것은 여러분이 할 수 있는 일이지만 모바일 우선 인덱싱이 웹사이트에서 어떻게 보이는지에 영향을 줄 것이라고는 생각하지 않습니다. 그리고 일반적으로 Progressive Web Apps의 경우 JavaScript 프레임워크 웹사이트입니다. JavaScript는 일반적으로 잘 렌더링하고 처리할 수 있지만 항상 순수한 정적만큼 쉬운 것은 아니기 때문에 Google에서 실제로 콘텐츠를 볼 수 있는지 확인해야 한다는 점에서 그와 함께 제공되는 다른 모든 문제가 발생합니다. HTML 페이지. "