SEO 업무 시간 – 2021년 9월 17일

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

단어 제한

09:05 “[카테고리] 페이지에서 사용해야 하는 단어의 한계는 무엇입니까?”

John은 그러한 제한이 없다고 말하면서 "[...] 특히 카테고리 페이지의 경우 주제가 무엇인지 이해할 수 있도록 페이지에 약간의 정보가 있어야 합니다. 그러나 그것은 일반적으로 매우 적은 정보입니다. 그리고 많은 경우에 우리는 당신이 나열한 제품에서 우리가 이해할 수 있을 만큼 제품 이름이 명확하다는 것을 이해합니다. [… ] 그러나 때때로 제품 이름이 이해하기 조금 어려울 수 있습니다. 그런 다음 거기에 약간의 컨텍스트를 추가하는 것이 합리적일 수 있습니다. 그러나 일반적으로 한두 문장 정도의 추가 맥락이 있습니다.”

색인 범위 측정항목에 변경 사항 없음

10:57 “저는 몇 백만 페이지가 있는 큰 웹사이트에서 일하고 있습니다. 두 언어 간에 리디렉션을 수행했습니다. [… ] 마이그레이션이 잘 진행되고 있으며 트래픽이 두 번째 경로에서 이동하고 있습니다. 명확히 하자면 두 개의 하위 폴더 또는 동일한 도메인 내의 모든 항목 사이의 투영입니다. 여기서 제기하고 싶은 것은 리디렉션을 수행한 지 거의 3주가 지난 후에도 적용 범위 측정항목에 변화가 없다는 것입니다. [...] 유효한 페이지를 삭제하지 않고 리디렉션이나 이와 유사한 이유로 제외된 페이지가 증가하지 않습니다. 우리가 그것에 대해 걱정해야 합니까?”

“나는 그런 종류의 것들이 가시화되기 위한 고정된 타임라인이 있다고 생각하지 않습니다. [...] 우리는 웹사이트에서 다른 속도로 페이지를 크롤링합니다. 또한 일부 페이지는 매일 다시 크롤링하고 다른 페이지는 한 달에 한 번 또는 몇 달에 한 번 다시 크롤링합니다. 따라서 병합하려는 이러한 폴더의 콘텐츠가 거의 크롤링되지 않는 콘텐츠인 경우 해당 내용이 반영되는 데 오랜 시간이 걸립니다. 반면에 매우 활발하게 크롤링되는 콘텐츠인 경우 일반적으로 일주일 정도 이내에 변경 사항을 확인해야 합니다."

색인 범위 보고서의 업데이트

13:25 두 개의 하위 폴더를 병합할 때 "[...] 트래픽이 사이트의 한 부분에서 다른 부분으로 이동합니다. 모든 것이 잘 진행되고 있으며 로그 파일에서도 이를 확인할 수 있습니다. [...] 그러나 우리는 적용 범위 측정항목에서 이것을 볼 수 없습니다. 버그를 보고하거나 하루 종일 기다려야 하지 않을까 걱정이 됩니다.”

John은 "[...] Index Coverage 보고서는 일주일에 두 번 업데이트됩니다. [...] Search Console의 많은 보고서는 일주일에 한두 번이므로 지연될 수 있습니다. 그러나 트래픽이 올바른 페이지로 이동하는 것을 보고 있고 실적 보고서를 보고 그러한 종류의 변화를 보고 있다면 완벽하게 괜찮다고 생각합니다. 나는 당신이 이와 같은 것에 대한 인덱스 커버리지 보고서를 조심할 필요가 있다고 생각하지 않습니다. 이와 같이 페이지를 병합할 때 일반적으로 발생하는 일은 시스템이 먼저 이러한 페이지에 대한 새로운 표준을 찾아야 한다는 것을 파악해야 하기 때문입니다. 따라서 두 페이지를 가져와 하나로 접습니다. 그런 다음 이것이 페이지 집합임을 확인하고 표준을 선택해야 하며 이 프로세스에는 약간의 시간이 걸립니다. 그리고 그 내용이 보고에 반영되기까지 약간의 시간이 걸립니다. 반면에 클린 사이트 이전과 같은 작업을 수행하면 모든 것을 이전할 수 있습니다. 우리가 알아내야 하는 이 정규화 프로세스가 없습니다. 그래서 그곳에서 눈에 보이는 데 시간이 더 걸린다고 상상할 수 있었습니다.”

웹사이트의 품질 이해

15:22 “내 질문은 […] 특히 Google이 이를 호출하고 이해하려고 할 때 새 페이지가 있는 알고리즘 […]에 관한 것입니다. 그런 다음 해당 페이지를 사이트의 이전 레거시 페이지와 비교하여 "좋아, 이 페이지는 훌륭하지만 훨씬 오래된 페이지는 실제로는 쓰레기"라고 말합니다. 그러면 최신 페이지와 카테고리 페이지의 품질에 영향을 미칩니다. 알고리즘이 웹사이트의 품질을 실제로 이해하기 위해 […]하는 일입니까?”

John은 "[...] 우리가 웹사이트의 품질을 전반적으로 이해하려고 할 때 많은 시간이 걸리는 프로세스일 뿐입니다. 그리고 꽤 긴 리드 타임이 있습니다 . 따라서 이미 10,000페이지가 있는 웹 사이트에 5개의 페이지를 추가하면 먼저 대부분의 사이트에 초점을 맞춘 다음 시간이 지남에 따라 새 콘텐츠로 어떻게 해결되는지 보게 될 것입니다. 거기도.”

링크 에퀴티 전달

17:06 “백링크를 얻는다면 [Google]은 그것이 좋은 품질의 백링크라고 가정하고 맹목적으로 링크 에퀴티를 사이트에 전달하지 않을 것입니다. 그렇다면 Google은 이러한 백링크를 크롤링할 때 추천 트래픽을 보고 알고리즘에 반영합니까? 또는 해당 정보가 표시되지 않으면 해당 링크를 클릭할 가능성이 높은지 평가하려고 합니까? 따라서 해당 링크를 클릭하는 경향이 높으면 링크 자산을 통과하게 될까요? 없다면 […] 말 그대로 블로그와 링크를 지금 만들 수 있습니다. 이 경우 Google은 실제로 트래픽이 없다고 말합니다. 여기에서 실제로 많은 일이 진행되고 있지 않은데 왜 링크 에퀴티의 형태를 전달해야 합니까? [...] 그런 종류의 링크 자산이 사이트에 전달되는지 여부에 영향을 줍니까?”

“나는 그렇게 생각하지 않는다. 우리는 링크의 가치를 평가할 때 링크를 통한 트래픽과 같은 것을 사용하지 않습니다. 내가 아는 한, 우리는 누군가가 링크를 클릭할 확률과 같은 가치를 어떻게 평가해야 하는지도 고려하지 않습니다. 때때로 링크는 본질적으로 참조일 뿐이고 사람들이 페이지의 모든 링크를 클릭할 것으로 기대하는 것은 아니기 때문 입니다 . 그러나 누군가가 귀하의 사이트를 참조하여 이렇게 말하는 경우 여기 이 전문가가 그렇게 하라고 했기 때문에 제가 이 일을 하는 것입니다. 그러면 사람들은 링크를 클릭하지 않고 항상 […] 귀하의 사이트를 보고 거기에 쓰여진 내용을 확인합니다. 그러나 그들은 그것을 거의 참조로 볼 것입니다. […] 더 많은 정보를 알고 싶다면 그곳으로 갈 수 있습니다. 하지만 그럴 필요는 없습니다. 그리고 그런 관점에서 링크의 가치를 평가할 때 그것을 고려하지 않을 것이라고 생각합니다.”

도메인 사이트 마이그레이션

20:53 “ 한 도메인에서 새 도메인으로 사이트 도메인을 마이그레이션하고 모든 마이그레이션 요구 사항과 권장 사항을 따랐습니다. 리디렉션, 표준 태그를 업데이트하고 사전에 개발 환경에서 테스트했습니다. Google Search Console에서 새 속성을 추가하고 새 도메인을 확인했습니다. 주소 변경을 수행할 때 홈페이지에서 301 리디렉션이 있고 이전 도메인을 가져올 수 없다는 유효성 검사 실패 오류가 발생합니다. 주소 변경 도구에 대한 유효성 검사를 어떻게 통과합니까?”

“우선 명심해야 할 가장 중요한 점은 주소 변경 도구는 마이그레이션과 관련하여 사용하는 하나의 추가 신호일 뿐입니다. 그것은 요구 사항이 아닙니다. 따라서 어떤 이유로든 주소 변경 도구가 웹사이트에서 작동하도록 할 수 없는 경우 리디렉션이 제대로 설정되어 있으면 이 모든 것이 설정되어야 합니다. 꼭 해야 하는 것은 아닙니다. 나는 대부분의 사이트 […]가 실제로 이 도구를 사용하지 않는다고 상상합니다. Search Console에 대해 알고 이러한 종류의 멋진 것들을 모두 알고 있는 사람들이 사용하고 있을지도 모릅니다. 실패할 수 있는 이유와 관련하여 사이트 이름이나 테스트 중인 URL을 알지 못하면 말하기가 정말 어렵습니다.

내가 본 한 가지는 웹 사이트의 www 버전과 www가 아닌 ​​버전이 있고 이를 통해 단계별로 리디렉션하는 경우입니다. 예를 들어 www가 없는 버전으로 리디렉션한 다음 새 도메인으로 리디렉션합니다. 그런 다음 기본 버전이 아닌 사이트 버전에서 주소 변경을 제출하면 문제가 발생할 수 있습니다. 따라서 주소 변경 도구와 관련하여 현재 색인이 생성되었거나 색인이 생성된 버전을 제출하고 있거나 Search Console에서 대체 버전을 제출하고 있는지 다시 확인하는 것이 좋습니다."

여러 스키마 유형 추가

23:36 “한 페이지에 여러 스키마 유형을 추가할 수 있습니까? 그렇다면 FAQ 스키마와 레시피 스키마를 한 페이지에 결합하는 가장 좋은 방법은 무엇입니까?”

" 페이지에 구조화된 데이터를 원하는 만큼 넣을 수 있습니다. 그러나 대부분의 경우 검색 결과에 표시되는 리치 결과와 관련하여 한 가지 유형의 구조화된 데이터 또는 한 가지 리치 결과 유형만 선택하고 이에 집중하는 경향이 있습니다. 따라서 페이지에 여러 유형의 구조화된 데이터가 있는 경우 이러한 유형 중 하나만 선택하여 표시할 가능성이 매우 높습니다. 따라서 검색 결과에 특정 유형이 표시되기를 원하고 검색 결과를 볼 때 결합된 용도가 없다는 것을 알게 되면 단순히 결합하는 것이 아니라 원하는 유형에 초점을 맞추려고 합니다. 다른 것들과 함께. 따라서 이상적으로는 정말로 원하는 것을 선택하고 그것에 집중하십시오.”

404와 크롤링 가능성 및 인덱싱 가능성

24:39 " GSC 크롤링 통계 보고서는 우리 사이트의 일부가 아닌 404페이지의 꾸준한 증가를 보여주고 있습니다(이는 사이트맵에 존재하지 않으며 내부 검색에 의해 생성되지도 않음). URL에 추가되는 Google 검색으로 보이며 Google에서 크롤링을 시도하고 있습니다. 크롤링 응답 분석에서 이러한 404는 크롤링 응답의 40% 이상을 차지합니다. 이것이 크롤링 가능성과 인덱싱 가능성에 부정적인 영향을 미치지 않도록 하려면 어떻게 해야 합니까?”

“우선, 우리는 URL을 구성하지 않으므로 Google 검색을 수행한 다음 귀하의 웹사이트에 URL을 구성하는 것이 아닙니다. 나는 이것이 우리가 웹에서 찾은 무작위 링크라고 생각합니다. [...] 그래서 그것은 항상 일어나는 일입니다. 이러한 링크를 찾은 다음 크롤링합니다. 404를 반환한 다음 무시하기 시작합니다. 따라서 실제로 이것은 당신이 돌봐야 할 일이 아닙니다. [...] 일반적으로 이러한 종류의 링크에서 발생하는 일은 웹사이트에 대해 크롤링해야 하는 URL과 크롤링해야 하는 빈도를 파악하는 것입니다. 그리고 우리가 절대적으로 해야 할 일, 추가로 할 수 있는 일을 파악한 후 고려합니다. 그리고 그 추가 버킷에는 등급이 매겨진 URL 세트와도 같으며, 기본적으로 예를 들어 스크레이퍼 사이트에서 [… 따라서 이러한 임의의 링크에서 가져온 사이트의 많은 URL을 크롤링하고 있는 경우 기본적으로 중요하다고 생각되는 항목에 대한 크롤링이 이미 완료되었다고 가정할 수 있습니다. 사이트가 중요합니다. 서버에 시간과 용량이 있을 뿐이며 다른 작업도 시도할 것입니다. 따라서 이러한 관점에서 이러한 404가 웹사이트 크롤링에 문제를 일으키는 것은 아닙니다. 우리가 귀하의 웹사이트에 충분한 용량을 보유하고 있다는 신호에 가깝습니다. 웹사이트 내에서 실제로 링크한 것보다 더 많은 콘텐츠가 있는 경우 해당 콘텐츠도 크롤링하고 색인을 생성할 것입니다. 따라서 본질적으로 이는 거의 좋은 징조이며 robots.txt로 이를 차단할 필요가 없습니다. 억제해야 할 대상이 아닙니다 [...]”

다른 국가의 트래픽 차단

27:34 “ 프랑스에서만 운영되는 서비스 웹사이트가 있습니다. 그리고 대역폭이 매우 나쁜 다른 국가에서 많은 트래픽이 유입되어 CWV 점수가 낮아집니다. [...] 우리는 프랑스 밖에서 사업을 하고 있지 않기 때문에 프랑스 밖에서의 트래픽에는 아무 소용이 없습니다. 다른 나라에서 오는 트래픽을 차단하는 것이 좋습니까?”

John이 말한 내용은 다음과 같습니다. “다른 국가에서 오는 트래픽을 차단하지 않으려고 합니다. 나는 그것이 궁극적으로 당신에게 달려있는 일이라고 생각합니다. 귀하의 웹사이트입니다. 당신은 당신이하고 싶은 것을 선택할 수 있습니다. [...] 이 경우 염두에 두어야 할 사항 중 하나는 미국에서 거의 모든 웹사이트를 크롤링한다는 것입니다. 따라서 프랑스에 있고 다른 모든 국가를 차단하면 Googlebot 크롤링도 차단됩니다 . 그러면 본질적으로 귀하의 콘텐츠에 대한 색인을 생성할 수 없습니다. 이러한 관점에서 다른 국가를 차단하려면 최소한 Googlebot이 크롤링하는 국가를 차단하고 있지 않은지 확인하세요. 적어도 검색에 관심이 있다면.”

페이지 재그룹화

35:38 " Google은 최근 CWV 점수에 대해 눈에 띄게 다른 페이지인 30,000개 이상의 페이지를 우리 사이트에서 다시 그룹화했습니다. [...] 제품 페이지가 다시 그룹화되기 전에 평균 2.5초였음에도 불구하고 이로 인해 이 페이지의 평균 LCP가 최대 3.4초가 되었습니다. 우리는 페이지를 임계값보다 2.5초 아래로 낮추기 위해 노력했지만 이제 우리의 전술은 우리가 달성해야 하는 점수에 도달하기에는 너무 미미해 보입니다. 그룹화 집합을 선택한 다음 점수 평균을 취합니까 아니면 점수를 취한 다음 그룹화 집합을 취합니까? – (이는 해당 제품 페이지를 2.5초 미만으로 가져오는 것이 문제를 해결하는 데 도움이 되는지 여부를 확인하는 데 도움이 됩니다.)”

“[...] 그룹화 방법에 대한 명확하거나 정확한 정의가 없습니다. 웹 사이트에 대해 보유한 데이터의 양에 따라 시간이 지남에 따라 조금씩 발전해야 하기 때문입니다. 따라서 웹 사이트에 있는 다양한 종류의 페이지에 대한 많은 데이터가 있는 경우 시스템에서 그룹화를 이전보다 약간 더 세분화하여 수행할 것이라고 말하는 것이 훨씬 쉽습니다. 반면에 데이터가 많지 않으면 전체 웹사이트를 하나의 그룹으로 간주하는 상황까지 가게 됩니다. 그게 한 가지입니다. 다른 하나는 우리가 수집하는 데이터가 현장 데이터를 기반으로 한다는 것입니다. Search Console에서도 볼 수 있습니다. 즉, 개별 페이지의 평균을 취하여 페이지 수로 평균을 내는 것이 그다지 중요하지 않습니다. 그러나 실제로는 일부 페이지에 훨씬 더 많은 트래픽이 있고 거기에 더 많은 데이터가 있다는 점에서 트래픽 가중 평균에 가깝습니다. 그리고 다른 페이지는 트래픽이 적고 거기에는 데이터가 많지 않습니다. 그래서 그것은 여러분이 이러한 종류의 차이점을 보고 있는 것일 수 있습니다. 많은 사람들이 귀하의 홈페이지를 방문하고 개별 제품을 방문하는 사람은 많지 않다면 데이터가 더 많기 때문에 홈페이지에 가중치가 조금 더 높을 수 있습니다. 이것이 제가 갈 방향입니다. 실제로는 개별 페이지에 너무 집중하는 대신 Google Analytics 또는 기타 분석과 같은 것을 살펴보고 어떤 페이지나 페이지 유형을 파악해야 하는지를 의미합니다. 많은 트래픽을 얻고 있습니다. 그런 다음 해당 페이지를 최적화함으로써 본질적으로 사용자 경험을 개선하려고 하는 것입니다 [… 따라서 본질적으로 페이지 수에 대한 평균은 줄이고 사람들이 웹사이트를 방문했을 때 실제로 보게 되는 트래픽에 대한 평균은 더 높아집니다."

MUM 알고리즘

42:44 “ MUM 알고리즘 의 출현으로 검색 결과가 여러 소스에 대한 응답이 될까요? 즉, 사용자가 주제를 검색할 때 여러 소스에서 답변을 선택하여 패키지로 제공한다는 것입니다. 우리는 미래의 경쟁이 일종의 경쟁자 간의 상호 작용이 될 것이라고 생각합니다. 그들은 함께 검색자의 요구를 충족시킬 수 있습니다. 사이트는 더 잘 제공할 수 있는 서비스에 중점을 둡니다. 여러 경쟁자가 검색자의 요구를 충족할 수 있습니다. 사용자 요구 포트폴리오는 더 잘 알려진 최고의 서비스를 위해 경쟁하는 여러 사이트에서 완성됩니다."

존은 “모르겠습니다. 아마도 그것은 어느 시점에 일어날 것입니다. 특정 주제에 대해 매우 강력하거나 다른 의견이 있을 수 있는 경우 검색 결과에 다양한 옵션을 제공하려는 개념이 있습니다 . 그리고 거기에 어떤 의견이 있는지에 대한 질문입니다. 그런 다음 해당 주제에 대해 다양한 각도를 다루는 다양한 결과 집합과 같은 것을 제공하는 것이 합리적일 수 있습니다. 나는 그것이 대부분의 쿼리에 적용된다고 생각하지 않지만 때로는 우리가 고려하려고 노력하는 것입니다.”

사이트 마이그레이션

47:11 " 사이트 마이그레이션을 수행할 때 트리거를 해제하는 날 robots.txt가 두 도메인을 모두 차단하고 [...] 302개의 임시 리디렉션을 수행하면(개발자가 아무것도 확신하지 못한 후 며칠 또는 몇 주 내에 301로 전환) break), Devs가 고장난 것을 확인하는 동안 하루 또는 몇 시간 동안 사이트 전체에 503 HTTP 상태를 제공합니까?"

John에 따르면, “[...] 이것들은 모두 별개의 상황입니다. 그리고 이것은 우리가 말하는 경우가 아닙니다. 음, 이것은 이 변형이 있는 사이트 이동입니다. 그러나 오히려 당신이 물건을 막고 있다면, 물건이 고장났다면, 우리는 무엇보다도 그것을 고장난 물건으로 볼 것입니다. 그리고 나중 단계에서 실제로 리디렉션되는 것을 확인하면 이제 사이트가 리디렉션되고 있다고 말할 수 있습니다. 그리고 우리는 그것들을 별도의 상태로 취급할 것입니다. 따라서 사이트를 이동하려는 날에 서버에서 무언가가 중단되고 모든 것이 중단된 경우 서버에서 모든 것이 중단된 것을 잘 볼 수 있습니다. 우리는 모든 것이 망가진 것을 볼 것이기 때문에 당신의 의도가 사이트 이동을 하려는 것인지 몰랐을 것입니다. 그런 관점에서 나는 이들을 별개의 상태로 취급할 것입니다. 물론 손상된 상태를 가능한 한 빨리 수정하고 기본적으로 그 이후에는 가능한 한 빨리 마이그레이션으로 이동하십시오."

뉴스 사이트에서 오래된 콘텐츠 제거

49:42 “뉴스 웹사이트에서 오래된 뉴스를 제거/인덱싱하지 않음/허용하지 않는 것을 살펴볼 가치가 있습니까? 10세 이상 뉴스? 일반적으로 웹사이트 품질에 영향을 미치며 크롤링 예산을 최적화합니까? 3백만 페이지가 넘는 페이지가 있는 사이트입니다. 그게 뭔가 하는 건가요?”

“오래된 뉴스를 제거하는 것만으로는 많은 가치를 얻을 수 없다고 생각합니다. 때로는 모든 정보가 여전히 유용하기 때문에 뉴스 웹사이트에 추천하지도 않습니다. 그 관점에서, 나는 SEO 이유로 이것을 하지 않을 것입니다. 사용성 또는 유지 관리를 위해 콘텐츠를 제거하거나 웹사이트의 아카이브 섹션에 넣는 이유[...]라면, 확실히 할 수 있는 일입니다. 하지만 오래된 콘텐츠라고 맹목적으로 제거하지는 않을 것”이라고 말했다.