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

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

schema.org 유효성 검사기와 Google Search Console의 스키마 마크업 테스트

7:41 “John, 첫 번째 질문은 Google Search Console에서 필수 구조화된 데이터 요소에 오류 […]가 발생한다는 것입니다. 그러나 validator.schema.org 에서 동일한 것을 확인하면 경고나 오류가 표시되지 않습니다. 따라서 첫 번째 질문은 웹 페이지의 AMP 구현을 확인하기에 적합한 사이트입니까? […]"

John은 " 네, 그래서 이 테스트 도구는 약간 다른 목적을 위한 것입니다. 아마 그 차이를 느끼기 때문일 것입니다. schema.org의 테스트 도구는 schema.org의 요구 사항을 기반으로 전체와 마찬가지로 schema.org 마크업을 이해하는 데 더 가깝습니다. 그리고 Search Console의 테스트 도구는 순전히 구조화된 데이터에서 추출하여 검색 기능에 표시하는 데 사용할 수 있는 것에 중점을 둡니다. 그래서 그것은 그 이야기의 검색 부분에 정말로 초점을 맞추고 있습니다. 그리고 검색 내에서 schema.org 마크업의 일부만 사용합니다. 때로는 기본 schema.org 마크업이 요구하는 것보다 더 많은 특정 요소가 필요할 수 있는 약간 다른 요구 사항이 있습니다. 그리고 그것이 종종 당신이 그 차이를 보는 이유입니다. schema.org 유효성 검사기는 이론적 마크업을 위한 것이고 Google 유효성 검사기는 실제로 실제 Google 검색 측면을 위한 것입니다. "

9:20 “[…] 기본적으로 오류가 아닙니다. Search Console의 경고입니다. 그리고 Search Console에서 세부정보를 확인하면 제대로 하지 않고 있다고만 나옵니다. 그렇다면 [문제를 해결하는] 가능한 방법이 있습니까? 아니면 개발팀에서 해결해야 합니까?

존은 “네, 경고라면 신경 쓰지 않겠습니다. 그것은 기본적으로 당신이 다른 일을 할 수 있다고 말하는 것입니다. […]. 차이점이 정확히 무엇인지 알고 싶다면 내가 할 수 있는 것은 모든 구조화된 데이터와 모든 필수 및 권장 필드가 문서화된 검색용 developer.google.com의 문서를 다시 확인하는 것입니다. 그리고 아마도 권장 또는 선택 필드 중 하나가 이 경고를 트리거하는 것입니다."

페이지가 크롤링되지만 색인이 생성되지 않는 이유

14:11 " 특정 페이지가 여러 번 크롤링되었음에도 불구하고 [...] 색인이 생성되지 않는 가능한 이유는 무엇입니까? "

이에 존은 “ 그럴 수 있다. 일반적으로 우리가 무언가를 크롤링하기로 결정할 때 우리는 그것을 시작하고 색인을 생성하는 것을 매우 기쁘게 생각하기 때문에 그렇게 자주는 아닐 것이라고 생각합니다. 그러나 페이지를 크롤링하고 결국에는 실제로 색인을 생성할 필요가 없다고 결정하는 경우가 있습니다.

[...] 귀하의 경우에는 적용되지 않을 수 있는 몇 가지 일반적인 상황은 페이지에 오류 코드가 있는 경우입니다. 먼저 크롤링해야 오류 코드가 표시됩니다. 페이지에 noindex 가 있는 경우 먼저 크롤링한 다음 noindex를 확인해야 합니다. 페이지가 이미 본 다른 페이지의 완전한 복제본인 경우 크롤링하여 복제본을 확인하지만 기본 페이지에 다시 초점을 맞춥니다. 그래서 우리가 무언가를 크롤링하고 인덱싱하지 않는 일반적인 상황입니다. 그러나 우리가 무언가를 크롤링한 다음 인덱싱에 도달할 즈음에 우리는 오, 글쎄요, 실제로는 웹사이트에서 다른 것을 얻고자 하는 결정을 내릴 수도 있습니다. "

15:41 "[...] [이미 언급한 요소 외에] 어떤 다른 요소로 인해 Googlebot이 최종적으로 색인을 생성하고 싶지 않다고 결정할 수 있습니까?"

존은 “직접적으로는 모른다. 전반적인 웹사이트 품질 이 확실히 중요한 역할을 한다고 생각 하지만 일반적으로 웹사이트 품질에 대해 확신이 없으면 처음부터 페이지를 크롤링하지 않을 것입니다. 그래서 좀 난감한 상황인 것 같아요. 그리고 Search Console을 보면 거의 모든 사이트에 대해 검색되었지만 인덱싱되지 않았 으며 크롤링되었지만 인덱싱되지 않은 그룹이 있다고 생각합니다. 제 생각에는 모든 사이트에서 흔히 볼 수 있는 일입니다.”

질문을 하는 사람은 페이지 품질과 기술적인 문제 외에 조사해야 할 다른 것이 있는지 알고 싶어했습니다. John은 한 페이지에 너무 집중하지 말라고 권고했습니다. “특정 페이지에 너무 집중하지 않는 것도 중요 하다고 생각합니다 . 따라서 기술적인 관점에서 모든 것이 정상이라고 확신하는 경우 특정 페이지의 품질이 문제라고 가정하지 않고 웹사이트 또는 전체 웹사이트 자체. 인덱싱되지 않은 개별 페이지뿐만 아니라 해당 페이지 주변의 더 큰 그림이 무엇인지를 개선하기 위해 무엇을 할 수 있는지 알아보려고 노력하는 곳 입니다. "

전자 상거래 사이트에서 제품 목록을 제거하면 불이익을 받을 수 있습니까?

21:48 " 그래서 우리는 전자 상거래 웹사이트를 운영하고 있으며 이제 카테고리 페이지를 대대적으로 업데이트하려는 단계에 있습니다. [...] 하나의 초안에서 제품 목록을 없애고 싶습니다. 따라서 찾고 있는 제품을 필터링할 수 있는 패싯 검색이 있는 제품 목록이 있습니다. [...] 카테고리 페이지의 전체 제품 목록을 제거하면 먼저 다른 모든 경쟁자가 이러한 종류의 제품 목록을 가지고 있기 때문에 순위에 불이익이 있습니까? 그리고 두 번째로, 이것은 사용자가 모든 제품에 대한 일종의 개요를 갖고 [...] 원하는 제품을 검색할 수 있게 해주는 필터를 기대하는 전자 상거래 페이지에 대해 확립된 요소라고 생각합니다. "

John은 이렇게 대답 했습니다. 나는 우리가 깨끗한 링크를 가지고 있는 모든 개별 제품을 여전히 찾을 수 있도록 당신이 조심하고 싶어하는 다른 것들이 있다고 생각합니다. 그러나 이 카테고리 페이지를 다시 디자인하고 정보 페이지처럼 보이게 하는 것이라면 문제가 없을 것입니다. 또한 검색에서 이러한 종류의 카테고리 페이지에 대해 특별한 작업을 수행하지 않는다고 생각합니다. 따라서 이러한 관점에서 보면 기본적으로 디자인을 변경하는 것뿐입니다.  

상품 페이지라면 완전히 바뀌었을 거라고 생각합니다. 상품 페이지 를 인식해서 가격이 어디인지, 재고가 어디 있는지 , 그런 것들이 어디 있는지 파악하려고 하기 때문입니다. 그리고 완전히 다르게 보이게 했다면 […], 우리가 제품 페이지를 선택하는 방법과 제품 검색 결과에 표시할 수 있는지 여부에 영향을 줄 수 있다고 상상할 수 있습니다. 하지만 카테고리 페이지는 제가 아는 한 특별한 조치를 취하지 않습니다. 따라서 기본적으로 제품을 숨기고 제품에 대한 링크를 찾을 수 있도록 [...] 그렇게 할 수 있습니다. 그러나 더 많은 정보를 제공하여 더 유용하게 만들고 싶다면 좋은 생각이라고 생각합니다.”

질문 말미에 John 은 사용자의 관점에서 변경 사항 을 확인하는 것이 중요하다고 덧붙였습니다 . 나는 그것을 다시 확인할 것입니다. 따라서 SEO 측면에서는 완벽하게 괜찮다고 생각하지만 사용자 측면에서는 아마도 먼저 테스트하고 싶은 것입니다.”

내부 연결 구조의 중요성

25:18 " 이동 경로 설정을 위한 구조화된 데이터가 있는 경우 SEO에 내부 링크가 여전히 중요합니까?"

이에 존은 “네, 물론입니다. 내부 연결이 SEO에 매우 중요한 부분 입니다. Google을 안내하고 방문자를 중요하다고 생각하는 페이지로 안내하는 것이 웹사이트에서 할 수 있는 가장 큰 일 중 하나라고 생각합니다. 그리고 당신이 중요하다고 생각하는 것은 전적으로 당신에게 달려 있습니다. 가장 많은 돈을 버는 곳에서 일을 중요하게 하거나 가장 강력한 경쟁자이거나 가장 약한 경쟁자인 곳에서 일을 중요하게 만들 수 있습니다. 내부 연결을 사용하면 사이트의 해당 방향과 해당 부분에 집중할 수 있습니다. 그리고 그것은 구조화된 데이터로 대체할 수 있는 것이 아닙니다.

따라서 페이지 어딘가에 구조화된 데이터가 있다고 해서 일반 내부 링크를 대체하는 것으로 볼 수 없습니다. 구조화된 데이터에서 URL도 제공하더라도 페이지에서 일반 내부 링크를 사용하는 것과 같은 방식으로 해당 URL을 사용하지 않습니다. 따라서 hreflang 주석이 국가 버전 간의 링크를 대체하거나 이동 경로 주석이 웹사이트의 다른 수준 간의 링크를 대체하는 것은 아닙니다. 웹사이트의 다른 부분 사이에 정상적인 HTML 링크가 있어야 합니다. 그리고 이상적으로는 기본적인 링크 집합만 있는 것이 아니라 전략적으로 바라보고 가장 중요하게 생각하는 것이 무엇인지 생각해야 하며 내부 연결을 통해 이를 어떻게 강조할 수 있을까요? "

제품 목록 페이지의 여러 제품 스키마

29:50 “ 제품 목록 페이지의 경우 제품 목록 페이지에 여러 제품 스키마를 구현할 수 있습니까? "

John은 다음과 같이 말했습니다. “ 정책적 관점에서 보면 최소한 구조화된 데이터 관련 정책을 마지막으로 확인했을 때는 그렇게 해서는 안 된다고 생각합니다. 구조화된 제품 데이터의 경우 기본 데이터에 적용하기를 원하기 때문 페이지의 요소입니다. 그리고 한 페이지에 여러 제품이 있는 경우 그 중 하나가 페이지의 기본 요소가 아닙니다. 따라서 이러한 관점에서 카테고리 페이지 [...]에서 여러 제품 구조화된 데이터 요소를 사용해서는 안 됩니다. "

혼합 언어 페이지를 만들면 순위가 떨어질 수 있습니까?

30:30 " 혼합 언어가 사용된 페이지에 대한 모범 사례가 있습니까? 예를 들어, 일본에 있는 우리 국제학교는 일본인 및 외국인 가족을 대상으로 하지만 대부분의 정보는 영어로 홈페이지에 보관합니다. 일본어 페이지에서도 지원을 추가합니다. [… ] 실생활에서 우리의 의사 소통은 혼합 언어이기 때문에 홈페이지에 반영되는 것이 더 자연스럽게 느껴졌습니다. 페이지가 의도적으로 혼합된 언어인 경우 검색 시 처벌을 받나요?”

이에 존은 “꼭 그런 경우에 한 페이지가 처벌받는다는 말은 하지 않는다. 그러나 우리는 페이지의 기본 언어가 무엇인지 이해하려고 노력하고 있으며, 이는 우리가 이 페이지를 표시할 수 있는 쿼리의 종류를 이해하는 데 도움이 됩니다. 그래서 제 생각에는 이런 경우에는 좀 까다롭습니다.

한 페이지에 여러 언어가 있는 경우에도 이해할 수 있습니다. 누군가가 영어로 검색하는 경우 이 페이지가 그들에게 보여줄 올바른 페이지라는 사실을 훨씬 더 쉽게 알 수 있습니다. 그래서 저는 홈 페이지 같은 것을 상상할 수 있었습니다. 아마도 그 믹스나 약간의 믹스를 갖는 것이 합리적일 것입니다. 하나의 홈페이지가 기본 영어인 경우 일본어로 된 일부 요소를 포함할 수 있습니다. 기본적으로 일본어이고 일부 요소는 영어로 된 다른 버전이 있으면 괜찮습니다. 그러나 이것은 대부분이 영어 페이지라는 것을 진정으로 이해하는 데 도움이 됩니다. 그리고 누군가 일본에 있는 특정 종류의 국제 학교를 영어로 검색하는 경우, 우리가 귀하의 요구에 적합하고 귀하가 제공한 쿼리와 일치하는 영어 콘텐츠가 여기 있다고 말하는 것이 합리적입니다. 따라서 이러한 관점에서 페이지가 처벌을 받는다고 말할 수는 없지만 시스템에서 해당 페이지의 순위를 올바르게 지정하는 방법을 파악하는 것이 훨씬 더 어렵습니다.

여기에서 생각할 수 있는 것 중 하나는 Search Console에서 웹사이트 또는 홈페이지로 이동하는 검색어를 확인하는 것입니다. 그리고 Google이 언어를 제대로 이해하지 못한 경우 영향을 받을 수 있는 검색어에 대해 생각해 보세요. 그리고 대부분의 사람들이 귀하의 이름이나 학교 브랜드를 검색하는 경우 기본적으로 전혀 영향을 받지 않을 수도 있습니다. 반면에 대부분의 사람들이 귀하의 홈페이지에 있는 내용과 거의 일치하는 문장과 같은 보다 광범위한 검색어, 보다 일반적인 검색어를 검색하는 경우 검색 결과에 귀하가 표시되기가 조금 더 어려울 것이라고 상상할 수 있습니다. , 귀하의 홈페이지가 실제로 해당 검색어의 언어로 되어 있는지 확실하지 않기 때문에 […]

당신이 할 수 있는 한 가지는 […] 당신의 홈 페이지를 일종의 이중 언어 버전으로 만드는 것입니다 [… 이것은 여전히 ​​순수한 영어 또는 대부분의 영어 페이지를 찾은 다음 거기에서 웹 사이트의 나머지 부분으로 전환할 수 있습니다 [...].

모바일 버전과 데스크톱 버전의 콘텐츠 차이

34:20 " 모바일 버전과 데스크톱 버전의 콘텐츠 차이가 있다면 구글이 웹사이트를 처벌하고 웹사이트 순위에 영향을 미친다는 뜻인가요, 아니면 단순히 구글봇이 모바일 버전에서 찾을 수 있다는 의미인가요 ? 순위를 매길 수 없습니까? "

John은 " 그래서 대부분의 인덱싱을 모바일 우선 인덱싱으로 전환 했습니다. 즉, 그런 경우에는 웹사이트의 모바일 버전만 볼 것입니다. 따라서 기본적으로 웹 사이트의 데스크톱 버전에 약간 다른 것이 있는 경우 대부분의 경우 검색에 해당 항목을 사용하지 않습니다. 차이 때문에 웹사이트를 벌하는 것이 아니라, 웹사이트의 한 버전만 보고 다른 버전에 무엇이 있는지조차 알지 못하는 것과 같습니다. .  

그리고 여전히 데스크톱 인덱싱 상태에 있는 소수의 사이트의 경우에는 다른 방식으로 적용됩니다. 물론, 데스크탑 버전에는 없는 모바일 버전에 […] 무언가가 있고 데스크탑 크롤러에 의해 색인이 생성된다면 우리는 그것을 실제로 보지 못할 것입니다. 때때로 대체 버전을 크롤링하지만 더 많은 정보를 얻기 위해 크롤링하는 것이 아니라 데스크톱 URL과 모바일 URL 간에 연결이 있는지 확인하기 위한 것입니다. "

클라우드에서 사이트맵을 호스팅할 수 있습니까?

46:20 “ 수백만 개의 URL이 있는 정말 거대한 페이지가 있고 […] 사이트맵 이 현재 리노베이션 중입니다. 그리고 우리 IT 팀은 우리 클라우드 서비스에 새로운 사이트맵 파일을 저장하는 것을 고려하고 있습니다. 이는 example.com/sitemaps에서 cloud.com/sitemaps로 이동한다는 의미입니다. 그리고 우리는 사이트맵을 클라우드에 저장하는 것이 문제인지 궁금합니다. 그리고 그것이 문제가 되지 않는다면 이 example.com/sitemap의 이전 URL에 대한 영구 리디렉션 도 생성 해야 합니까? 아니면 이동을 어떻게 계획해야 합니까? "

John은 “ 사이트맵 파일을 다른 곳에 호스팅하는 것은 확실히 가능합니다. 두 가지 방법이 있습니다. 하나는 Search Console에서 두 도메인을 모두 확인한 경우 작동합니다. 다른 방법은 robots.txt 파일과 함께 제출하는 경우입니다. 여기서 'sitemap:'을 지정한 다음 사이트맵의 URL을 지정합니다. 다른 도메인으로 이동할 수도 있습니다. [...] 나는 또한 깨끗하기 위해 이전 사이트맵 파일을 새 위치로 리디렉션하지만 아마도 이전 사이트맵 URL을 삭제하고 새 URL을 제대로 제출했는지 확인하더라도 제대로 작동할 것입니다.  

조금 까다로울 수 있는 것은 Search Console이 UI에 직접 표시하는 방법을 모른다는 것입니다 . 특히 사이트맵 파일이 다른 위치에 있는 경우 Search Console이 인덱싱 보고서에 사이트맵 정보를 표시하는 경우, 예를 들어. 그러나 그것은 보고 문제입니다. 그것은 사이트맵 파일의 기능에 의존하는 것이 아닙니다. Search Console이 제대로 표시하지 않는 것뿐입니다. 그리고 다시, 아마도 그럴 것입니다. 100% 확신할 수 없습니다. "

도메인 기록이 웹사이트에 영향을 줄 수 있습니까?

49:40 “[…] 그래서 [ 이전 SEO 근무 시간 동안 ] 우리는 에스코트 서비스 제공자로서의 이력이 있는 도메인에 대한 질문을 제기했습니다. […] 해당 웹사이트의 첫 번째 스냅샷이 1997년에 있기 때문에 도메인은 오랜 역사를 가지고 있습니다. […] 우리는 작년 6월에 웹사이트를 다시 시작했습니다. […] 그리고 우리가 겪고 있는 주요 문제는 […] 여전히 [성인 콘텐츠로] 플래그가 지정된다는 것입니다. 또한 현재 인덱싱되지 않은 크롤링 문제[...]가 있습니다. 그리고 도메인 기록이 실제로 색인 생성 문제에 영향을 미칠 수 있는지 이해하려고 노력하고 있습니다. [...] 우리는 우리가 게시하는 콘텐츠의 품질이 우수하다고 믿습니다. 내부적으로 연결되어 있으며 양질의 사이트를 구축하기 위해 노력하고 있습니다. 현재 우리가 어려움을 겪고 있는 부분은 페이지 성능이므로 이를 최적화하기 위해 현재 진행 중입니다. 그러나 우리는 prerender.io 를 사용 하므로 Google에 표시되는 것은 이미 사전 렌더링된 버전입니다. 따라서 Lighthouse 점수에 관해서는 모든 것이 좋습니다. [...] 색인이 생성되지 않는 이유를 이해하기 위해 무엇을 개선하거나 찾을 수 있습니까? URL도 공유하게 되어 기쁩니다. "

존은 나중에 URL을 살펴보자고 제안한 후 " 일반적으로 웹 사이트에 성인용 콘텐츠가 이전에 있었다면 인덱싱 측면은 관련이 없었을 것입니다.

이전에 거기에 있던 콘텐츠가 매우 스팸성인 경우 색인 생성 측면이 영향을 받을 수 있습니다. 인덱싱의 관점에서 볼 때 이 새 웹사이트가 실제로 스팸이 아니라는 사실을 파악하는 데 시간이 걸릴 수 있습니다.

하지만 이전에 성인용 콘텐츠가 있었다면 세이프서치 필터가 이를 인식하는 속도가 약간 느릴 수 있다고 상상할 수 있습니다. 나는 우리가 그것을 더 빠르게 만들기 위해 몇 가지 조치를 취했다는 것을 알고 있습니다. […

세이프서치 쪽은 사이트 쿼리를 하고 세이프서치를 켜고 끄면 확인할 수 있는 부분입니다. SafeSearch에서 어떤 일이 일어나고 있는지 확인할 수 있어야 합니다. 그러나 인덱싱과 관련해서는 그렇지 않습니다. 하지만 나중에 이것을 볼 수 있고, 내가 당신에게 알려줄 수 있는 아주 명백한 것이 있는지 볼 수 있습니다. "