2019년 1월 22일 – Google 도움말 행아웃 메모

이번 주 John은 NYC의 Big Apple에 있습니다. 왼쪽부터 Google Java Script 팀의 Martin Splitt, Chris Love, Lily Ray, Marie Haynes, Dave Minchala 및 Quason Carter가 IRL에 합류했습니다. 이번 주에는 Cloudfare, The QRG 및 New Page Speed ​​Tool에 대한 몇 가지 훌륭한 질문이 있었습니다. 동영상 링크와 전체 내용은 아래에서 확인하실 수 있습니다!

Cloudflare가 때때로 Googlebot을 차단합니까?

7:58

"예, 지금은 Cloudflare가 어떻게 설정되어 있는지 모르지만 과거에는 Googlebot을 위조하는 사람들을 차단하는 데 사용되었다는 것을 압니다. 따라서 귀하가 자신의 것을 사용하는 경우 Screaming Frog 또는 무언가-- 당신이 말했듯이, 저는 Googlebot 사용자 에이전트를 사용하고 있고, 그들은 이것이 합법적인 Googlebot이 아니라는 것을 알 수 있기 때문에 차단할 것입니다. 우리는 그것을 차단할 수 있습니다. 하지만 대부분은 그들이 가지고 있다고 생각합니다 정상적인 Googlebot을 인식하고 정상적으로 크롤링할 수 있도록 충분한 연습이 필요합니다."

요약: 때때로 테스트할 때 Cloudflare가 Googlebot을 차단하는 것처럼 보일 수 있습니다. 여기서 일어날 가능성이 있는 일은 Cloudflare가 Googlebot을 사칭하는 사람들을 차단하고 있다는 것입니다. 따라서 Screaming Frog와 같은 도구를 사용하고 Googlebot을 사용자 에이전트로 선택하면 Cloudflare를 사용하여 사이트를 크롤링하지 못할 수 있습니다 .

부자연스러운 링크가 여전히 알고리즘적으로 사이트에 피해를 줄 수 있습니까? 그렇다면 거부 도구를 사용할 수 있습니까?

14:01

"좋은 질문이라고 생각합니다. 그래서 제 관점에서 볼 때, 한편으로는 수동 조치가 있는 경우입니다. 그러나 또한 귀하가 많은 직접 조치를 보면 웹 스팸 팀이 지금 이것을 본다면 직접 조치를 취하겠다고 말할 것입니다. 시간이 지남에 따라 수행된 작업에 기반을 둔 것이 아니라-- 저도 잘 모르겠습니다-- 어디에서 분명히 몇 년 전에 수행되었으며 경계선이 아니었습니다. 웹 스팸 팀의 누군가가 이것을 팁으로 받으면 직접 조치를 취할 것이고 그것은 확실히 내가 그것을 정리하고 그것에 대해 거부하는 종류의 일이라고 생각합니다. 특정 타임라인 같은 게 있다고 말하기는 어렵지만 일반적으로 웹스팸 팀이 이것을보고 일이 진행되었다고 말하면 분명히 d 몇 년 전에 하나. 완전히 악의적 인 것은 아닙니다. 그러면 아마 이에 대해 직접 조치를 취하지 않을 것입니다. "

그리고 나는 당신이 아마도 이것에 대답할 수 없다고 가정합니다. 그러나 어떤 방법이 있습니까? 예를 들어 우리가 직접 조치를 취하지 않았거나 그들이 직접 조치를 취하지 않았다고 가정해 봅시다. 이러한 링크가 알고리즘에 해를 끼칠 수 있습니까? 일부 사이트에서 거부한 후 일부 개선 사항이 있는 것처럼 느끼기 때문입니다. 그래서 다시, 나는 그것이 항상-- 결코 흑백이 아니라는 것을 압니다.

확실히 그럴 수 있습니다. 그래서 그것은 우리가 알고리즘을 볼 때 그들이 볼 때, 오, 여기에는 정말 나쁜 링크가 많이 있다는 것을 알 수 있습니다. 그러면 아마도 웹사이트에 대한 일반적인 링크와 관련하여 좀 더 신중할 것입니다. 따라서 이를 정리하면 알고리즘이 이를 보고 이렇게 말합니다. 나쁘지 않아.

요약: SEO만을 위해 특별히 만들어진 링크가 있고 링크가 많으면 Google 알고리즘이 모든 링크를 불신하게 만들 수 있습니다. 이와 같은 경우에는 거부하는 것이 가장 좋습니다.

Google 알고리즘은 게시자의 EAT를 어떻게 측정합니까?

33:40

"모르겠습니다. 아마도 알고리즘적으로 파악하기 어려울 것 같습니다. 그리고 귀하가 수행해야 하는 기술적인 일이 있으면 알려 드리겠습니다. 따라서 저작권 마크업과 같은 것이 있으면 우리가 생각하기에 이와 같은 것에 유용할 것이라고 생각하는 어떤 지점에서, 우리는 그것을 분명히 거기에 가져올 것입니다. 하지만 많은 것들이 실제로 우리가 알아내려고 하는 일종의 부드러운 품질 요소이며, 당신이 하고 있거나 하지 않는 중입니다. 사용자가 이것을 어떻게 볼 수 있는지 알아내려는 것과 같습니다. 따라서 내가 지적할 수 있는 구체적인 것은 없습니다."

요약: Google이 검토하는 "소프트 품질 요소"가 많이 있습니다. 사용자의 관점에서 사물을 보십시오. 또한 저작권 마크업은 Google이 상황을 더 잘 이해하는 데 도움이 될 수 있습니다.

품질 평가자 가이드라인에 있는 내용이 있는 경우 Google이 이를 알고리즘에 반영하기를 원한다고 가정하는 것이 합리적입니까?

34:44

일반적으로 그것을 목표로 하는 것이 좋은 습관이라고 생각합니다. 저는 Google이 알고리즘 요소로 사용할 수 있는 것에 너무 많은 초점을 맞추려고 하는 것을 피하고 더 많이 살펴봅니다. 우리는 이것이 웹에 좋다고 생각합니다. 종류의 것들. 그래서 순위를 올리기 위해 좋은 웹사이트를 만드는 것이 아니라 검색에 표시될 때 사람들이 좋은 경험을 하기를 원하기 때문에 좋은 웹사이트를 만들고 있는 것입니다. 그리고 나서 그들은 내 웹사이트로 돌아올 것이고 아마도 무언가를 살 것입니다. 그래서 그것이 내가 볼 수 있는 방향입니다. 순위를 매기기 위해 이렇게 하는 것이 아니라 웹에서 건강하고 장기적인 관계를 유지하기 위해 이렇게 하는 것입니다.

요약: 사용자에게 가장 적합한 것이 무엇인지 생각하십시오. QRG에 있는 모든 내용이 현재 Google 알고리즘에 반영된 것은 아니지만, 이는 모두 품질을 전반적으로 개선하기 위한 훌륭한 단계입니다.

음성 검색 결과에서 사이트가 더 높게 표시되도록 하는 스키마가 있습니까?

36:10

모르겠어요. 나는 아무 것도 생각할 수 없습니다. 따라서 사용할 수 있는 말하기 가능한 마크업이 있습니다. 이는 아마도 페이지에서 의미가 있는 위치를 확인하기 위해 조사하는 것이 합리적일 것입니다. 아직 모든 위치에서 사용하지는 않을 것 같습니다.

요약: Speakable 마크업은 아직 모든 지리적 위치에서 사용되지 않습니다. 그러나 이것은 시작하기에 좋은 곳입니다.

추천 스니펫 획득에 대한 몇 가지 팁

38:03

그러나 특집 스니펫, 특히, 제 생각에 우리는 그것에 특정한 마크업 유형이 없다고 생각합니다. 따라서 페이지에 명확한 종류의 구조가 있으면 많은 도움이 됩니다. 페이지의 표와 같은 것을 인식할 수 있다면 훨씬 쉽게 꺼낼 수 있습니다. 반면에 멋진 HTML과 CSS를 사용하여 테이블처럼 보이도록 만들지만 실제로 테이블이 아닌 경우 꺼내기가 훨씬 더 어렵습니다.

요약: 추천 스니펫을 획득하기 위해 추가할 수 있는 마크업이 없습니다. 그러나 h 태그와 일반 HTML 테이블을 잘 사용하면 정말 도움이 될 수 있습니다.

모든 페이지에 위치 스키마를 추가해야 합니까?

50:47

답변 51:42 - 내가 아는 한, 그것은 단지 홈페이지일 뿐입니다. 모르겠어요. 아시는 분 계신가요?

Liz 51:4 7의 답변 - 일반적으로 조직 및 기업이 포함된 한 페이지여야 합니다. 일반적으로 권장하는 사항입니다.

MARTIN SPLITT 52:00 - 어느 쪽이든 상관없을 것 같습니다. 어떤 페이지든 중요하지 않습니다. 마치 당신이 가지고 있는 모든 페이지에 그것을 넣지 않는 것이 더 중요한 부분인 것 같습니다. 내 생각에 그것은-- 만약 당신이 뉴스 사이트라면 그것을 연락처 페이지나 정보 페이지 등에 넣는 것이 합리적일 것입니다. 반면에 상점이나 레스토랑 웹사이트에서는 홈페이지에 올려도 괜찮습니다.

JOHN 52:20 - 또한 이 경우 홈 페이지나 연락처 페이지와 같은 곳에서 찾을 수 있어야 하기 때문에 우리에게는 그다지 중요하지 않다고 생각합니다. 그러나 우리가 그것을 다른 곳에 가지고 있다면 그것은 우리를 위해 아무것도 바꾸지 않습니다. 따라서 비교하지 말아야 할 가장 중요한 점은 사람들이 웹사이트의 모든 페이지에 대해 별점과 검색 결과를 얻으려는 희망으로 웹사이트의 모든 페이지에 회사 리뷰와 같은 글을 올리는 것을 가끔 볼 수 있는 리뷰 마크업입니다. 그리고 그것은 우리에게 좋지 않을 것입니다. 하지만 연락처 정보가 표시되어 있다면 그건... 문제가 없다고 생각합니다.

요약: 별로 중요하지 않습니다. 연락처 페이지에 있어야 하며 아마도 귀하의 정보 페이지 및 홈 페이지에 있어야 합니다. 사이트 전체에 위치 스키마를 갖는 것은 문제가 되지 않지만 필요하지 않을 수도 있습니다.

Lighthouse를 기반으로 하는 새로운 PageSpeed ​​Insights 도구가 웹사이트 점수를 매길 때 훨씬 더 가혹한 이유는 무엇입니까?

53:05

Marie Haynes: 제 질문은 아니지만 상황을 설명하자면 페이지 속도에 대한 새로운 Lighthouse 데이터는 Page Speed ​​Insights 이전보다 훨씬 더 가혹합니다. 따라서 Page Speed ​​Insights에서 80점과 같은 점수를 받은 항목은 Lighthouse에서 빨간색 29점일 수 있습니다. 좋은 질문입니다. 모바일에서는 매우 느린 사이트가 강등될 수 있다는 것을 알고 있기 때문입니다. 그래서 만약 당신이 Lighthouse 테스트에서 적자라면, 강등을 유발할 수 있기 때문에 우리가 정말로 개선해야 한다고 말하는 것이 좋은 것입니까? 아니면 컷오프가 있습니까?

답변 54:07 - 그래서 우리는 외부 도구와 소셜에 사용하는 모든 것에 대한 일대일 매핑이 없습니다. 네, 그건 정말 말하기 어렵습니다. 하지만 검색에서는 Lighthouse 테스트와 유사한 실험실 테스트 데이터와 Chrome UX 보고서 데이터를 혼합하여 사용하려고 합니다. 우리가 측정하고 있는 것은 웹사이트의 사용자들이 보게 될 것입니다.

MARTIN SPLITT 55:37 - 예를 들어 Lighthouse가 특히 중간 수준의 3G 연결을 측정한다는 사실을 확인하는 것도 중요합니다. 따라서 기본적으로 최근 Apple McIntosh 또는 사무실에서 유선 연결 또는 Wi-Fi 연결과 같은 정말 좋은 최신 고속 Windows 컴퓨터를 사용하는 경우 물론 로드 시간이 2초이지만 야생에서 휴대전화를 가지고 있는 실제 사용자는 아마 그것을 보지 못할 것입니다. 따라서 웹사이트를 더 빠르게 만드는 것이 결코 나쁠 것이 없는 것과 같은 이러한 경우 중 하나입니다. 도구가 노출하는 것....물론 수정하는 것이 중요합니다. 왜냐하면 사용자가 웹사이트에서 영원히 기다리지 않기 때문입니다. 당신을 다치게 할거야. 그것은 사용자에게 피해를 줄 것입니다. 검색에 피해를 줄 뿐입니다. 하지만 저는 돈을 내지 않습니다. 도구만 보면 됩니다. 도구가 당신이 잘하고 있다고 말한다면 그것에 대해 너무 걱정할 필요가 없습니다. 도구가 당신에게 당신이 정말 좋지 않다고 말한다면, 나는 그것이 말하는 이유를 알아내는 데 시간을 할애했다고 생각합니다. 오히려 사이트를 더 빠르게 만드는 방법을 살펴봐야 합니다.

모바일 성능은 사용자는 물론 다른 모든 요소에 있어 매우 중요한 요소입니다. 따라서 귀하의 웹 사이트가 실제 조건에서 잘 작동하는지 확인하고 싶습니다. 어쩌면 싼 전화를 사서 때때로 웹사이트를 사용해 볼 수도 있습니다. 그리고 만약 내가 하고 싶은 일이고, 함께 일하고 있던 개발 팀과 함께 Google에 합류하기 전에 하던 일입니다. 이 전화에서 이 웹사이트를 사용하시겠습니까? 마치, 오, 이것은 끔찍했습니다. 나는, 음, 그래, 그래서 아마도 우리가 그것에 대해 뭔가를 해야 할 것 같다.

JOHN - Chrome에서 설정하고 다른 연결 속도를 시도할 수 있습니다. 모바일 에뮬레이터. 나는 그것이 정말 좋은 점이라고 생각합니다. 또한 사용자 기반을 살펴보는 것과 같습니다. 사람들이 귀하의 웹사이트를 고급형 iPhone으로만 사용하고 있다는 사실을 알게 된다면 분석 데이터를 살펴보십시오. 그러면 사람들이 무작위로 연결된 시골 지역에서 귀하의 사이트에 연결하는 것보다 문제가 덜할 수 있습니다. 느리고 저사양 기기를 가지고 있다면 그 이상일 것입니다.

요약: Lighthouse는 3G 연결 속도를 측정하므로 대부분의 사이트는 대부분의 세션에서 여기에 표시된 것보다 훨씬 더 빠르게 작동합니다. 참고: 이 행아웃이 끝난 후 Martin은 잠재적인 순위 강등과 관련하여 가장 중요한 "콘텐츠가 포함된 첫 번째 페인트"라고 말했습니다.

이런 내용이 마음에 든다면 제 뉴스레터도 마음에 드실 겁니다!

저희 팀과 저는 매주 최신 Google 알고리즘 업데이트, 뉴스 및 SEO 팁을 보고합니다.

비디오 및 전체 대본

질문 1:32 - SEO가 비즈니스에 더 정확하고 더 자신 있게 보고하는 데 사용할 수 있는 방식으로 테스트에 대한 더 많은 지침이나 관점이 있는지 궁금합니다. 우리는 이것을 시도했고 그 영향을 미쳤습니다. 그리고 Google에서 권장하는 방식과 같은 확실한 방식으로 작업을 수행했습니다.

답변 3:20 - 그래서 제 관점에서, 저는 품질 유형 변화의 종류에서 보다 기술적인 유형의 것들을 분리하려고 노력합니다. 따라서 정말 명확한 기술적인 것은 무엇이든 작동 여부를 테스트할 수 있습니다. 작동하거나 작동하지 않는 것은 문제가 아닙니다. 그러나 이러한 많은 기술적인 사항, 특히 렌더링을 볼 때 또는 Google이 실제로 이 콘텐츠의 색인을 생성할 수 있는지 볼 때 그렇습니다. 작동하거나 작동하지 않는 것. 까다로워지는 부분은 관련된 모든 것입니다. 인덱싱되지만 순위에는 어떻게 표시되나요? 그리고 많은 경우 실제로 그것을 테스트할 절대적인 방법은 없다고 생각합니다. 테스트 사이트를 만드는 것과 같이 격리된 상황에서 테스트하고 권장 사항이 무엇이든 설정하면 테스트 사이트가 일반 웹 사이트와 동일한 방식으로 수행될 것이라고 실제로 가정할 수 없기 때문입니다. 테스트 사이트라면 여기 저기에 너무 많은 시간을 할애하는 것이 말이 안 된다고 생각하기 때문에 전체 렌더링을 하지 않을 수도 있습니다. 예를 들어 아무도 보지 않기 때문입니다. 검색 결과에 표시되지 않습니다. 왜 그 뒤에 그렇게 많은 리소스를 넣어야 합니까? 반면에 일반 웹사이트에서 그렇게 하면 매우 다르게 작동합니다. 그래서 무엇을 해야 하고 무엇을 하지 말아야 하는지에 대한 명확한 지침이 없습니다. 해당 웹사이트가 표시되는 일반적인 추세, 해당 쿼리에 대해 보고 있는 순위의 변화, 그리고 모범 사례를 적용하려고 하는 것과 더 비슷합니다.

질문 5:21 - 그래서 아마도 만약-- 구체적인 예를 당신이 그것을 사용하여-- 아마도 그것이 도움이 될 것입니다. 그래서 제목 태그 테스트와 같은 것이 맞습니까? 만약 당신이 그렇게 한다면, 우리는 무엇을 찾아야 할까요? 아니면 풀기 위해 살펴볼 것이 있습니까? 이것은 우리의 테스트 때문입니까 아니면 서버, 알고리즘, 경쟁 역학에 대한 변경 사항 때문입니까? [웃음] 우리가 그 외부성을 보기 위해 다른 일을 한다고 가정합니다.

답변 5:56 - Google이 실제로 제공하는 제목 태그를 순위 지정을 위해 사용하는 것과 같은 상호 작용이 있다는 점에서 제목 태그 변경은 실제로 상당히 복잡하다고 생각합니다. 다른 한편으로는 검색 결과에 표시하기 위한 것입니다. 데스크톱 및 모바일과 마찬가지로 공간이 다르기 때문에 제목 태그가 약간 다를 수 있습니다. 사용자는 이에 대해 다양한 방식으로 응답할 수 있습니다. 따라서 같은 방식으로 순위를 매길 수 있지만 사용자는 '오, 이것은 훌륭한 페이지'라고 생각할 수 있습니다. 더 높게 표시하거나 검색 결과에서 멋진 페이지처럼 보이기 때문에 클릭하겠습니다. 그러면 더 많은 트래픽이 발생합니다. 그러나 실제로 순위는 동일합니다. 그래서 좋은 일 같습니까? 아마, 나는 추측한다. 순위만 보면 아무 것도 변경되지 않고 트래픽이 더 많아진 것처럼 보입니다.

그러나 그것은 거기에 흐름의 종류의 많은 다른 측면이 있는 곳입니다. 그래서 제 생각에는 SEO로서 한편으로는 무슨 일이 일어났는지에 대한 기술적 이해를 갖는 동시에 사용자가 변화에 어떻게 반응하는지에 대한 더 많은 마케팅 및 품질 이해를 갖는 것이 유용하다고 생각합니다. 사용자에게 영향을 줄 수 있는 장기적인 변경 사항이 있는 경우 사람들이 관련 항목을 검색하는 상황에서 당사 사이트가 가장 관련성 높은 사이트로 표시되도록 하려면 어떻게 해야 합니다. 그리고 테스트하기 정말 어려운 부분이라고 생각합니다. 예를 들어, 수년 간의 연습이 있었던 전통적인 마케팅에서도 테스트하기가 정말 어렵습니다. 예를 들어 이것이 실제로 큰 영향을 미치는지 여부와 같은 것입니다. 그것은 그들이 더 큰 그림을 보거나 사용자 연구를 하는 것으로 끝나는 것입니다. 이는 SEO로서도 할 수 있습니다. 죄송합니다. [웃음]

질문 7:58 - 더 직접적인 질문이 있습니다. 그래서 우리 사이트 중 많은 곳이 Cloudflare를 활용하고 있으며 Googlebot을 직접 차단하는 것으로 나타났습니다. 맞죠? 그러나 순위, 가시성 등에 큰 영향을 미치지 않았습니다. 그래서 어떻게 다른 봇을 사용하여 Googlebot 외부의 색인을 직접 크롤링하는지, 그리고 CDN이 봇을 차단하는 데 방해가 될 때 이에 대해 어떻게 생각해야 하는지 알아내려고 하는 것입니다.

답변 8:33 - 예, 현재 Cloudflare가 어떻게 설정되어 있는지 모르지만 과거에는 Googlebot을 속이는 사람들을 차단하는 데 사용되었던 것으로 압니다. 그래서 만약 당신이 Screaming Frog나 다른 것을 사용한다면, 저는 Googlebot 사용자 에이전트를 사용하고 있다고 말하면 그들은 이것을 차단할 것입니다. 예를 들어 이것이 합법적이지 않다고 말할 수 있기 때문입니다. 구글봇. 우리는 그것을 차단할 수 있습니다. 그러나 대부분의 경우 일반 Googlebot을 인식하고 정상적으로 크롤링할 수 있는 충분한 연습이 있다고 생각합니다.

질문 9:02 - 네, 재미있었습니다. 다른 에이전시의 동료들에게 연락을 취했고, 자신의 사이트에서도 비슷한 상황을 복제하고 있었기 때문입니다. 예를 들어 Cloudflare 내에 지원 티켓이 있었는데 Googlebot이나 Googlebot 스마트폰에서 직접 렌더링하려고 했을 때도 차단되고 있었습니다.

답변 9:21 - 네, 그렇습니다. 해결 방법이 없습니다. 예를 들어, 웹사이트가 우리를 차단하면 우리는 꼼짝 못하게 됩니다. 그러나 일반적으로 Cloudflare와 같은 서비스가 기본적으로 우리를 차단한다면 많은 웹사이트에 영향을 미칠 것입니다. 그리고 우리는 그것을 알아차렸을 것입니다. 우리는 아마도 그런 문제에 대해 Cloudflare에 연락할 것입니다. 서비스 계층이 다를 수 있습니다. 따라서 하위 계층에 있으면 무료 서비스와 같지만 트래픽 양에 제한이 있습니다. 그들에게 그런 것이 있는지 모르겠습니다. 그것은 내가 무료 기본 호스팅을 설정한 경우 때때로 트래픽 상한선이 있고 물건을 차단하는 다른 호스팅 업체에서 본 것입니다.

MARTIN SPLITT: 순위 등의 통계에서 즉시 확인하지 못할 수도 있습니다. 왜냐하면 기본적으로 우리가 당신의 콘텐츠를 가지고 있고 기본적으로 웹사이트는 그렇지 않기 때문입니다. 차단된 대상에 따라 이 경우에는 내가 그것을 보지 못했기 때문입니다. 그리고 저는 Cloudflare 뒤에서 몇 개의 웹사이트를 운영하고 있으며 아무런 문제가 없었습니다. 그러나 다시 말하지만, 나는 무료 요금제를 사용하고 있기 때문에 거대한 웹사이트를 가지거나 엄청난 양의 트래픽을 좋아하지 않습니다. 그건-- 하지만 우리 쪽에서 오류가 발생하지 않는다면 그것은-- 우리가 마지막으로 본 내용을 유지하고 있기 때문일 수 있습니다. 그리고 그것은 좋은 평가를 받고 있습니다. 괜찮습니다.

답변 12:09 - 예, 귀하와 같은 경우에는 크롤링 속도가 느려질 것이라고 생각합니다. 그리고 더 많이 가져올 수 있는 콘텐츠를 인덱스에 유지하려고 노력하고 조금 더 오래 다시 크롤링할 것입니다. 그러나 이는 웹사이트에서 변경 사항을 적용하는 경우 해당 사항을 적용하는 데 시간이 더 오래 걸린다는 의미이기도 합니다. 잘 모르겠습니다. AMP를 다시 크롤링해야 하거나 전체 사이트에 이런저런 것을 추가하면 이 모든 것이 훨씬 더 오래 걸릴 것입니다. 따라서 일반 Googlebot으로 크롤링할 수 없다는 사실을 정기적으로 확인하는 경우 이를 확인할 수 있도록 호스트와 함께 조치를 취합니다.

질문 14:01 - 좋습니다. 그래서 거부 도구에 대해 질문이 있습니다. 그래서 우리는 우리가 링크 감사를 하기를 원하는 사람들을 항상 얻습니다. 그리고 펭귄 4.0 이후부터 2016년 9월까지 Gary Illyes가 말했고 당신도 말했듯이 Google은 부자연스러운 링크를 무시하는 데 꽤 능숙합니다. 그래서 당시 제 생각은 부자연스러운 링크에 대한 수동 조치가 없는 한 Google이 이미 무시하고 있는 링크를 무시하도록 Google에 요청하기 위해 거부 도구를 사용할 필요가 없다는 것이었습니다. 그래서 우리는 링크를 구축하고, 부자연스러운 링크를 조작하려고 하는 사이트에 대해서만 이 기능을 권장했습니다. 하지만 웹마스터들 사이에 너무 많은 혼란이 있다고 생각합니다. 왜냐하면 저는 사람들이 항상 감사에 막대한 비용을 청구하는 것을 보았기 때문입니다. 그래서 우리가 조금 더 명확하게 할 수 있다면 좋겠습니다. 예를 들어 몇 년 전에 SEO 회사를 고용한 비즈니스 소유자가 있고 해당 SEO 회사가 링크 및, 알다시피, 초스팸이 아니라 중간 품질이었습니다. 제 말의 의미를 알고 있다면 Google이 해당 링크를 무시하고 있다고 확신할 수 있습니까? 아니면 우리가 들어가서 거부해야 합니까?

답변 15:22 - 좋은 질문이었다고 생각합니다. 그래서 내 관점에서 내가 거기에서 볼 것은 한편으로는 수동 조치가 있는 경우입니다. 그러나 또한 직접 조치를 많이 보고자 하는 경우 웹 스팸 팀이 지금 이것을 본다면 직접 조치를 취하겠다고 말할 것입니다. 수동 조치는 시간 문제이며 수행된 작업을 기반으로 하는 것과는 다릅니다. 잘 모르겠습니다. 몇 년 동안 명확하게 수행된 경우 전에, 그리고 그것은 일종의 경계선이 아니었습니다. 하지만 웹 스팸 팀에서 누군가가 이것을 팁으로 받으면 수동 조치를 취할 것이고 그것은 확실히 정리하고 할 것입니다. 그것에 대한 거부처럼. 네, 구체적인 일정이 있는지 말씀드리기 어려운 것 같아요. 그러나 일반적으로 웹스팸 팀이 이를 보고 "일이 진행되었습니다. 이것은 분명히 몇 년 전에 이루어졌습니다. 완전히 악의적 인 것은 아닙니다. 그러면 아마 이에 대해 직접 조치를 취하지 않을 것입니다.

질문 16:43 - 그리고 아마 답을 못 하실 거라고 생각합니다. 하지만 그런 방법이 있나요? 예를 들어 우리가 직접 조치를 취하지 않았거나 그들이 직접 조치를 취하지 않았다고 가정해 보겠습니다. 이러한 링크가 알고리즘에 해를 끼칠 수 있습니까? 일부 사이트에서 거부한 후 일부 개선 사항이 있는 것처럼 느끼기 때문입니다. 그래서 다시, 나는 그것이 항상-- 결코 흑백이 아니라는 것을 압니다.

답변 17:03 - 확실히 그럴 수 있습니다. 그래서 그것은 우리가 알고리즘을 볼 때 그들이 볼 때, 오, 여기에는 정말 나쁜 링크가 많이 있다는 것을 알 수 있습니다. 그러면 아마도 웹사이트에 대한 일반적인 링크와 관련하여 좀 더 신중할 것입니다. 따라서 이를 정리하면 알고리즘이 이를 보고 이렇게 말합니다. 나쁘지 않아.

질문 17:24 - 수동 조치를 방지하기 위해 기본적으로 거부하는 것이 여전히 좋습니다. 맞습니까?

답변 17:29 - 웹 스팸 팀이 현재 상황에 따라 수동 조치를 취할 것이 정말 분명한 경우라면 저는 그것을 거부할 것입니다.

질문 17:37 - Google과 같이 생각하는 것이 좋습니다. Google 스팸 팀의 누군가가 이것을 본다면 어떻게 하시겠습니까?

답변 17:47 - 예.

질문 17:48 - 하지만 문제는 대부분의 사람들이 모른다는 것입니다. 제 말은, 평균적인 비즈니스 소유자는 웹 스팸 팀이 어떤 링크를 만들지 모릅니다. 즉, 지침이 있지만 매우-- 알다시피, 그것들을 해석하기는 어렵습니다. 그래서 제 생각에는... 제 말은, 제 말은 몇 가지 우려 사항이 있지만 제 주된 관심사는 사람들이 링크 감사에 많은 돈을 지출하고 있다는 것입니다. 반면에 링크 감사를 수행하지 않고 혜택을 받을 수 있는 일부 사이트에 대해 거부할 수 있습니다. 그래서 저는 당신이 말한 것이 우리가--알다시피, 좋은 일을 하는 데 많은 도움이 되었으면 합니다.

답변 18:22 - 네, 제 생각에 대부분의 사이트에는 과거에 좋지 않은 조언을 따랐던 것과 같은 일반적인 상황이 혼합되어 있다고 생각합니다. 그러면 그들은 정말로 그렇게 할 필요가 없습니다. 이것이 이 모든 것의 일종의 목표이며 이것이 거부 도구가 Search Console의 주요 기능과 같지 않은 이유입니다. 당신은 그것을 명시적으로 찾고 있습니다. 대부분의 사이트에서 링크에 그다지 집중할 필요가 없기 때문에 이는 모두 의도적으로 수행된 것입니다. 하지만 거부 도구에 대해 제가 좋아하는 것은 이것이 걱정된다면 여전히 거기에 가서 이렇게 말할 수 있다는 점입니다. 전에, 그리고 나는 그것에 대해 정말로 걱정하고 있습니다. 그런 다음 내 관점에서 그들을 부인하는 것은 문제가 되지 않습니다. 나는 나가서 그 모든 것을 구체적으로 검색하지 않을 것입니다. 하지만 당신이 그것에 대해 알고 있고 그것에 대해 정말로 걱정한다면, 당신은 그것을 돌볼 수 있습니다.

질문 19:27 - 고객 웹사이트 중 하나에 대해 질문이 있습니다. 그래서 그들은 클럽을 운영하고 있습니다. 그들은 뉴사우스웨일즈의 3개 도시에 클럽을 가지고 있습니다. 그리고 각 클럽에는 웹사이트에 하위 도메인이 있습니다. 이제 웹사이트에 페이지를 추가할 때 각 하위 도메인에 대한 페이지를 만듭니다. 그래서 최근에 그들은 클럽 활동에 관한 페이지를 추가했으며 이 페이지를 모든 하위 도메인에 추가했습니다. 따라서 페이지 제목이 다른 것을 제외하고 모든 하위 도메인이 동일한 내용을 갖는다는 것을 의미합니다. 시드니의 경우 --에 추가할 때 제목 태그에 위치 이름을 추가하기 때문입니다. Newcastle용으로 추가할 때 제목 태그에 Newcastle을 추가하지만 페이지의 나머지 내용은 동일합니다. 그럼 50개의 하위 도메인이 있고 50개의 페이지를 생성했는데 제목만 제외하고 동일한 내용이 있다고 해서 문제가 될까요?

답변 20:36 - 좀 비효율적인 것 같군요. 그래서 제 말은, 당신은 이미 그것을 거론하고 있고, 이것은 다르게 할 수 있는 것처럼 보입니다. 콘텐츠가 모두 동일한 50개의 하위 도메인이 있고 제목 태그만 변경하는 경우 실제로 유용한 콘텐츠를 많이 제공하지 못할 수 있습니다. 그래서 제가 말하고 싶은 상황은 더 많은 하위 도메인으로 내용을 희석하는 것보다 모든 것을 결합하고 정말 강력한 페이지를 만드는 것이 더 합리적입니다.

질문 21:44 - 한 페이지를 만든 다음 다른 위치 페이지에 대한 표준 URL을 사용하는 것은 어떻습니까? 나는 그들의 활동에 대해 이야기할 한 페이지를 만들고 싶습니다. 링크를 다른 위치 페이지에 대한 표준 URL로 사용하겠습니다.

답변 22:10 - 위치-- 예. 나는 그것이 의미가있을 수 있다고 생각합니다. 그러면 당신이 물건을 다시 결합하기 때문입니다. 그런 다음 여러 종류의 희석된 페이지가 아닌 하나의 강력한 페이지를 만들고 있습니다.

질문 22:20 - 누군가가 웹사이트를 방문하고 위치를 선택하면 어떻게 됩니까? 그들은 자동으로 그 사람을 특정 위치에 대해 표시한 하위 도메인으로 리디렉션합니다. 그래서 그들이 해당 하위 도메인에 페이지가 필요한 이유입니다. 그렇기 때문에 한 페이지를 유지하고 표준 URL을 추가하면 현재로서는 이것이 유일한 옵션이라고 생각합니다.

답변 23:08 - 좋습니다. 하지만 기술적인 이유로 사이트에 별도의 페이지가 있어야 하고 표준을 입력한다면 좋은 접근 방식이라고 생각합니다.

질문 23:21 - 서로 다른 위치에 여러 프랜차이즈가 있고 각 프랜차이즈에 대해 본질적으로 동일한 콘텐츠를 가지고 있는 비즈니스가 다른 도시나 타운십 또는 기타 다른 곳에 있고 귀하의 관점을 다시 한 페이지로?

답변 23:34 - 특정 위치에서 그런 종류의 비즈니스를 찾는 사람들과 해당 비즈니스에 대한 정보 페이지의 균형을 직접 조정하기 때문에 항상 약간 까다롭다고 생각합니다. 그래서 그것은 때때로 비즈니스를 위해 그것을 분리하는 것이 합리적입니다. 때로는 중앙 위치에 일종의 일반 정보가 있고 주소, 영업 시간 등에 더 중점을 둔 위치 방문 페이지를 갖는 것이 합리적입니다.

질문 24:12 - 예, 저는-- 당신이 만들고 있는 표준 요점과 관련하여 관련 질문이 있습니다. 이것은 나와 내 팀이 수년 동안 가지고 있던 질문입니다. 그리고 우리는 여전히 그 해결책을 정확히 알지 못합니다. 따라서 많은 제품과 카테고리가 있는 대규모 전자 상거래 사이트를 처리하는 경우. 다양한 필터와 패싯, 그리고 페이지 콘텐츠를 약간 변경하지만 자체 URL을 갖는 것을 정당화하기에 충분하지 않은 속성이 있는 카테고리 페이지에 있다고 가정해 보겠습니다. 그러나 특정 필터가 있는 경우에는 사이트 URL이 있는 것이 정당화될 수 있습니다. 그렇다면 그 상황에서 크롤링을 처리하는 방법은 무엇입니까? 표준 태그가 작동합니까? 인덱싱된 페이지를 하나만 만드는 것이 포괄적인 솔루션입니까? 아니면 특정 패싯과 필터를 인덱싱하지 않거나 로봇을 사용하거나 대규모 전자 상거래 사이트에서 이를 어떻게 제어해야 하는지 알 수 있습니다.

답변 24:57 - 까다롭습니다. 현재로서는 이에 대한 명확한 지침이 없다고 생각합니다. 그래서 그것은 모든 다른 종류의 방법이 의미가 있을 수 있는 것입니다. 일반적으로 URL을 찾을 수 있기 때문에 robots.txt를 사용하지 않으려고 합니다. 우리는 거기에 무엇이 있는지 모릅니다. 따라서 서버에 너무 많은 부하를 일으키는 문제가 실제로 발생하지 않는 한 인덱스 없음, rel canonical 사용과 같은 것을 사용하려고 합니다. robots.txt를 사용하는 것보다 인덱스를 크롤링해야 하는 항목을 좀 더 명확하게 하기 위해 일종의 깔때기 항목에 대한 내부 링크와 함께 rel no-follow를 사용할 수도 있습니다. 그러나 언제 색인 수준 페이지로 결합할지, 색인 생성을 차단할지, 언제 하나의 표준 URL처럼 부드럽게 안내할지에 대한 결정은 때때로 정말 까다롭습니다.

질문 25:53 - 페이지 내용이 너무 다른 경우 표준이 무시되는 경우가 있기 때문입니다.

답변 25:57 - 맞습니다. 내용이 다르다면 우리는 이것이 다른 페이지라고 말할 수 있습니다. 우리는 표준을 사용해서는 안됩니다. 당신이 말할 수 있는 반면, 글쎄요, 이것은 정말로 제가 색인을 생성하고 싶지 않은 것입니다. 인덱스가 없는 것이 표준보다 더 합리적일 수 있습니다. 둘 다 결합할 수도 있습니다. 우리는 그것들을 결합하는 것을 권장하지 않습니다. 음, 무슨 뜻인가요? 이것이 동일하지만 하나는 인덱싱 가능하고 다른 하나는 인덱싱할 수 없다고 말하면 동일하지 않습니다. 그러나 나는 올해 동안 거기에서 작동할 수 있는 것에 대한 명확한 지침이 있을 것이라고 상상하는 것입니다. 그러나 특히 매우 큰 전자 상거래 사이트의 경우 크롤링 측면이 상당히 어려울 수 있습니다.

질문 26:46 - 최근에 몇 명의 고객과 함께 알아보려고 했던 시나리오가 있습니다. 우리는 페이지가 한동안 업데이트되지 않았고 콘텐츠가 오래되고 구식이며 일반적으로 여전히 HTTP를 사용하고 거의 버려진 것처럼 보이는 사이트를 본질적으로 정크할 수 없는 이유를 알아 내려고 노력하고 있습니다. 그래서 나는 그것에 대해 몇 가지 이론을 가지고 있습니다. 그것의 일부는 아마도 그것이 너무 오랫동안 지수에 포함되어 있어 여러분 모두가 그들과 함께 구축된 신뢰 요인을 가지고 있다는 것입니다. 그리고 그것들을 풀어내는 것은 다소 어렵습니다. That's part of my theory on that. So I'm just trying to figure out what's going on because I know HTTPS is a factor. I don't know how much of a factor it can be, but I also think the age might be part of the problem of trying to provide that newer, fresher content that-- in most cases, what we have done over last year is a lot more thorough than what was written, say 10, 12 years ago. So we're trying to figure out why is it taking so long to essentially move ahead of those pages in a lot of cases.

Answer 27:46 - So HTTPS is a ranking factor for us. But it's really kind of a soft ranking factor. It's really a small thing.

Question 27:55 - One of the things I've noticed about when I encounter sites that are still using HTTP is they haven't really-- they haven't been updated, in general, in two or three years, usually. So to me, it's kind of like they've almost been abandoned. To me I'm looking at it as a signal of freshness and stuff like that.

Answer 28:10 - Yeah, I mean, freshness is always an interesting one, because it's something that we don't always use. Because sometimes it makes sense to show people content that has been established. If they're looking at kind of long-term research, then like some of this stuff just hasn't changed for 10, 20 years.

Question 28:30 - I'll give you a pragmatic examples since I'm a web developer. I see pages that were written, say in 2006 or 2007. They haven't actually been changed, but the web standards, web specifications, or just the general way of handling those things has evolved. But that page is still written as if it's 2006. And yet I've got something that's fresher, you know, that's more in depth and things like that, and I'm like at number 11. They're sitting at number four, for example, like, why are they still up there, you know?

Answer 28:59 - Yeah. It's hard to say without looking at the specific cases. But it can really be the case that sometimes we just have content that looks to us like it remains to be relevant. And sometimes this content is relevant for a longer time. I think it's tricky when things have actually moved on, and these pages just have built up so much kind of trust, and links, and all of the kind of other signals over the years, where like, well, it seems like a good reference page. But we don't realize that, actually, other pages have kind of moved on and become kind of more relevant. So I think long-term, we would probably pick that up. But it might take a while.

I don't know if we call it trust or anything crazy like that. It's more-- it feels more like we just have so many signals associated with these pages, and it's not that-- like, if they were to change, they would disappear from rankings. It's more, well, they've been around. They're not doing things clearly wrong or for as long time, and people are maybe still referring to them, still linking to them. Maybe they're kind of misled in kind of linking to them because they don't realize that, actually, the web has moved on. Or maybe, I don't know, a new PHP version came out, and the old content isn't as relevant anymore. But everyone is still linking to, I don't know, version 3 or whatever.

Question 30:42 - But I've also seen that kind of in the health and fitness space as well, you know, like workout types were more popular 10 years ago, but the particular, you know, approach to it isn't necessarily as popular now or been kind of proven to not necessarily be as good. You know, it's just some other general observations I've made too.

Answer 31:06 - Yeah, I think it's always tricky because we do try to find a balance between kind of showing evergreen content that's been around and kind of being seeing more as reference content and kind of the fresher content and especially when we can tell that people are looking for the fresher content. But we'll try to shift that as well. So it's not something that would always be the same.

Question 32:20 - "We have a large e-commerce site that's not in the mobile-first index yet. We know we serve different HTML for the same URL, depending on the user agent. Could this harm us?

Answer 32:38 - So you don't have a ranking bonus for being in the mobile-first index. So it's not that you need to be in there. But it's more a matter of when we can tell that a site is ready for the mobile-first index, then we'll try to shift it over. And at the moment, it's not at the stage where we'd say, we're like flagging sites with problems and telling them to fix things. But more where we're just trying to get up to the current status and say, OK, we've moved all of the sites over that we think are ready for mobile-first indexing. And kind of as a next step, we'll trying to figure out the problems that people are still having and let them know about these issues so that they can resolve them for mobile-first indexing. So it's not that there is any kind of mobile-first indexing bonus that's out there. It's more that we're, step by step, trying to figure out what the actual good criteria should be.

Question 33:40 - Given that the search quality guidelines are an indication of where Google wants its algorithm to go, how does the current algorithm handle measuring the expertise and credibility of publishers?

Answer 33:59 - I don't know. I think that's probably hard to kind of figure out algorithmically. And if there were any kind of technical things that you should do, then we would let you know. So if there are things like authorship markup that we had at some points that we think would be useful for something like this, we would definitely bring that out there. But a lot of things are really more kind of soft quality factors that we try to figure out, and it's not something technical that you're either doing or not doing. It's more, like, trying to figure it out how a user might look at this. So not anything specific that I could point at.

Question 34:44 - Is that reasonable to assume that if something is in the Quality Raters' Guidelines that Google-- I mean, that's what Ben Gomes said, right? That's where the Google wants the algorithm to go. So I mean, we may be guilty putting too much emphasis on the Quality Raters' Guidelines, but it's all good stuff in there, right? So is it reasonable to make that assumption? Like, if it's in there, we should aim for that sort of standard of quality?

Answer 35:09 - I think, in general, it's probably good practice to aim for that. I avoid trying to focus too much on what Google might use as an algorithmic factor and look at it more as-- we think this is good for the web, and, therefore, we will try to kind of go in that direction and do these kind of things. So not so much it's like I'm making a good website just so that I can rank better, but I'm making a good website because when I do show up in search, I want people to have a good experience. And then they'll come back to my website, and maybe they'll buy something. So that's kind of the direction I would see that, not as, like, do this in order to rank, but do this in order to kind of have a healthy, long-term relationship on the web.

Question 36:10 - Is there a particular type of schema that is more likely to obtain featured snippets of voice search results?

Answer 36:18 - I don't know. I can't think of anything offhand. So there is the speakable markup that you can use, which is probably reasonable to-- kind of look into to see where it could make sense on a page. I don't think we'll use that in all locations yet.

Question 36:41 - Is that the goal to us it in more locations?

Answer 36:47 - I believe-- I guess. I mean, it's always a bit tricky because, sometimes, we try them out in one location, and we try to refine it over time. And usually, that means we roll it out in the US, and where we can kind of process the feedback fairly quickly, we can look to see how it works, how sites start implementing it or not. And based on that, we can refine things and say, OK, we're doing this in other countries, and other languages, and taking it from there. But it's not always the case that that happens. Sometimes it happens that we keep it in the US for a couple of years, and then we just said, oh, actually, this didn't pan out the way that we wanted it. So we'll try something new, or we'll give it up. Yeah. But a lot of the structured data types, we do try to roll out in other countries, other languages. I imagine the speakable markup is tricky with regards to the language. So that's something more where we'd say, well, Google Assistant isn't available in these languages. So, like, why do we care what markup is actually used there.

I don't know how many places this system is available yet. Maybe that's everywhere now. But featured snippets, in particular, I don't think we have any type of markup that's specific to that. So that's something where if you have clear kind of structure on the page, that helps us a lot. If we can recognize like tables on a page, then we can pull that out a lot easier. Whereas if you use fancy HTML and CSS to make it look like a table, but it's not actually a table, then that's a lot harder for us to pull out.

Question 38:37 - John, do internal links help with featured snippets if you have an anchor? Sorry, not an internal, like, an anchor like-- do you think that that would help?

Answer 38:48 - I don't know. I do know we sometimes show those anchor links in search as a sub site link-type thing. But I don't know if that would work for featured snippets.

Question 39:04 - Does cross domain site map submissions still work when 301 redirecting to an external sitemap file URL?

Answer 39:16 - Hopefully.

Question 39:17 - What about using meta-refresh? This was something that was recommended by a video hosting company. People said, we'll host the site map on our site, but, you know, the XML file will metarefresh over to our site where all the links are located.

Answer 39:33 - I don't think that would work. So sitemap files are XML files, and we process those kind of directly.

So if you do something that's more like a JavaScript redirect or that uses JavaScript to get us the sitemap content, then that would work. It would really need to be a server-side redirect. What you can also do is use the robots.txt file to specify a sitemap file on a different host. That also confirms to us that actually you told us specifically to use a sitemap file from there. So I probably use something like that more than any kind of a redirect. I imagine the 301 server-side redirect would work. But, no, I don't know, you should be able to see some of that in Search Console too, like, if we're picking the sitemap up in the index composition tool, you can pick the sitemap file, then that's a pretty clear sign that we can process that.

질문 42:29 - 여행을 위한 여행사 웹사이트에 관한 것이었습니다. 검색 도시에서 가장 저렴한 상위 10개 호텔과 같은 동적 콘텐츠를 표시하기 위해 내부 검색을 선택합니다. 알겠습니다. 따라서 페이지 프레임이 즉시 로드됩니다. 그러나 웹사이트가 뒤에서 이 검색을 수행한 다음 검색자에게 가장 저렴한 상위 10개 목록을 나열하기 위해 결과를 비교하고 구체화해야 하기 때문에 검색이 수행된 후 상위 10개의 가장 저렴한 호텔 결과는 약 30초 만에 동적으로 로드됩니다. 호텔. 그래서 그것들을 나열하는 데 약간의 시간이 걸립니다. 따라서 현재 Googlebot은 페이지의 배경만 봅니다. 그런 다음 10개의 빈 자리 표시자는 내부 검색이 수행된 후 결과가 조금 나중에 로드되는 위치였습니다. 그래서 이것이 여행 웹사이트가 가능한 한 신선하고 정확한 정보를 제공하는 추세이기 때문에 Google이 이에 대해 무엇을 하고 있는지 생각하고 있습니다. 물론, 다른 모든 웹사이트가 오늘날 Google을 위해 하는 것처럼 이러한 페이지에 일부 정적 콘텐츠를 나열할 수 있습니다. 그러나 그런 종류는 대부분의 사용자가 지금 신선하고 저렴하게 보고 싶어하는 목적을 무너뜨립니다.

답변 44:00 - 거기에 로드되지 않으면 색인을 생성할 수 없습니다. 그러나 일반적으로 JavaScript를 처리할 수 없거나 실제로 콘텐츠에 액세스하지 못하도록 차단되는 것이 더 문제입니다. 그래서 그것은 당신이 효과가 있는 방식으로 할 수 있는 일입니다. 절대로 작동하지 않도록 설계된 것이 아닙니다. 따라서 모바일 친화적 테스트와 같은 것을 사용하여 세부 사항을 파고들어 관련된 JavaScript 오류가 있는지 확인하고 문제가 차단되었는지 확인하고 거기에서 일종의 수정을 할 수 있습니다. 따라서 불가능한 것은 아니지만 약간의 작업이 필요합니다.

질문 44:42 - John, Google에서 차단된 항목이 없는지 확인합니다. Google이 하기를 바라는 유일한 것은 동적 콘텐츠가 페이지에 로드될 때까지 조금 기다리는 것입니다. 이것은 다음 단계입니다. 왜냐하면 이 페이지는 끝없는 스크롤과 같은 것이 아니라 Facebook이라고 합시다. 제한된 10개의 결과 페이지이기 때문입니다. 그래서 유한합니다. 제한적입니다. 문제는 Google이 동적 콘텐츠를 조금 기다려야 한다는 것입니다. 나는 단지 당신에게 예를 줄 뿐입니다. 그러나 나는 세상에 다른 많은 예가 있다고 확신합니다. 그리고 이것이 사람들이 어떻게든 정렬하고 보내는 시간이 점점 줄어들기 때문에 동적 콘텐츠를 보는 추세이기 때문에 사람들은 웹사이트에서 보내는 시간이 점점 줄어들고 가능한 한 빨리 찾고 싶어합니다. 내가 그렇게 말할 수 있다면 완벽한 결과. 여러분이 이 개선 사항을 찾고 있는지 궁금합니다.

답변 45:55 - 그래서 우리는 렌더링을 위해 조금 기다립니다. 그러나 사람들이 참을성이 없다면 그것은 어쨌든 더 빨라야 한다는 신호입니다. 그래서 어쨌든 그것에 대해 조사 할 것입니다. 하지만 스크린샷을 보면 회색 상자 안에 있는 모든 항목이 차단된 것 같습니다. 그래서 그것은 단지 시간 초과라기보다는 기술적인 문제에 더 가깝다고 느껴집니다.

마틴 스플릿 : 네. JavaScript와 같은 것을 사용하더라도 문제 없이 인덱싱되는 동적 콘텐츠가 많이 보입니다. 따라서 시간이 초과되면 검색에 걸리는 시간과 관련하여 문제가 있을 수 있으며 이는 실제로 다른 곳에서도 반영될 수 있습니다. 콘텐츠가 완성될 때까지 꽤 오랜 시간을 기다립니다.

질문 46:48 - 시간을 줄 수 있습니까? 얼마나 기다리세요?

MARTIN SPLITT : 정말, 정말 까다롭습니다 왜냐하면 기본적으로- 그래서 문제는, 우리가 당신에게 시간 프레임을 줄 수 없는 이유는 시간 때문입니다- 그리고 이것은 정말 이상하게 들릴 것이고 잠시만 참아주세요 . Googlebots 렌더링의 시간은 특별하며 반드시 아인슈타인의 원칙을 따르는 것은 아닙니다. [웃음] 그래서 정말 많은 말을 할 수 없습니다. 내가 말할 수 있는 것은 네트워크가 사용 중이고 네트워크에 병목 현상이 있는 경우 우리는 아마 기다리고 있을 것입니다. 그러나 우리는 너무 오래 기다리기만 합니다. 따라서 1분 또는 30초 정도 시간이 걸리면 그 사이에 시간이 초과될 수 있습니다. 하지만 어려운 것은 없습니다. 10초라고 말하면 효과가 있을 수도 있고 아닐 수도 있습니다. 30초라고 말하면 효과가 있을 수도 있고 아닐 수도 있습니다. 그래서 나는 숫자를 말하지 않는 것이 좋습니다. 내가 말하고 싶은 것은 가능한 한 빨리 그것을 얻으려고 노력하십시오. 그리고 빨리 얻을 수 없다면 검색 결과를 캐싱하는 것과 같이 검색이 어느 정도 가능하도록 하거나 페이지에 결과를 생성하는 것이 점점 더 즉각적으로 이루어지도록 하십시오. 또는 이에 대한 해결 방법이 될 수 있는 동적 렌더링을 시도하십시오. 또한 시도할 수 있는 것은 서버 측에 배치하고 기본적으로 첫 번째 단계에서 가능한 한 많은 콘텐츠를 생성하려고 시도할 수 있다는 것입니다. 이는 특히 사용자가 느린 네트워크에 있는 경우 사용자에게 이익이 되는 것입니다. 그래. 죄송합니다. 간단한 답변이 없지만 Googlebot의 시간은 펑키합니다.

답변 49:29 - 아마도 웹사이트가 실제로 하는 일에 달려 있다고 생각합니다. 렌더링 속도에서 까다로운 점 중 하나는 서버에서 보낸 많은 항목을 브라우저에서보다 더 많이 캐시할 수 있다는 것입니다. 왜냐하면 이러한 많은 작업에 인덱스를 사용할 수 있기 때문입니다. 따라서 때때로 JavaScript가 우리 측에서 캐시되면 가져올 필요가 없습니다. 그런 다음 시간을 다시 비교하면 사용자가 보는 것과 일치하지 않습니다. webtest.org에서 보는 것과 일치하지 않습니다. 그래서 정말 까다롭습니다. 시간이 더 오래 걸린다는 것을 알고 있는 부분에 대해서는 좀 더 참을성 있게 여길 것입니다. 하지만 테스트하기가 까다롭습니다. 그렇기 때문에 가능한 한 많은 오류를 표시하는 이러한 모든 테스트 도구가 있어 예를 들어 전혀 작동하지 않는지 파악할 수 있습니다. 때때로 작동하며 문제가 발생하는 위치는 어디입니까?

질문 50:29 - 매우 큰 웹사이트의 경우 XML 사이트맵의 URL 순서가 중요합니까?

답변 50:34 - 아니요. 우리는 상관하지 않습니다. XML 파일입니다. 우리는 모든 데이터를 가져옵니다. 한번에 처리해 드립니다.

질문 50:44 - 그러면 사이트맵의 우선순위 매개변수는 어떻습니까?

답변 50:47 - 우리는 그것을 전혀 사용하지 않습니다. 그래서 처음에는 페이지를 크롤링해야 하는 빈도를 파악하는 데 유용할 수 있다고 생각했습니다. 그러나 웹마스터에게 물어보면 모든 것이 우선 순위인 것처럼 보입니다. 가장 중요합니다. 그리고 사이트맵의 변경 빈도와 유사합니다. 사람들이 항상 상황이 바뀌는 것처럼 말하지만 작년에 마지막으로 업데이트되었음을 ​​알 수 있었습니다. 따라서 변경 빈도와 날짜가 있는 경우 어쨌든 날짜에서 해당 정보를 얻습니다. 따라서 변경 빈도를 무시합니다.
질문 51:35 - 회사 스키마를 홈페이지, 연락처 페이지 또는 모든 페이지에 추가해야 합니까?

답변 51:42 - 내가 아는 한, 그것은 단지 홈페이지일 뿐입니다. 모르겠어요. 아시는 분 계신가요?

Liz 51:4 7의 답변 - 일반적으로 조직 및 기업이 포함된 한 페이지여야 합니다. 일반적으로 권장하는 사항입니다.

MARTIN SPLITT 52:00 - 어느 쪽이든 상관없을 것 같습니다. 어떤 페이지든 중요하지 않습니다. 마치 당신이 가지고 있는 모든 페이지에 그것을 넣지 않는 것이 더 중요한 부분인 것 같습니다. 내 생각에 그것은-- 만약 당신이 뉴스 사이트라면 그것을 연락처 페이지나 정보 페이지 등에 넣는 것이 합리적일 것입니다. 반면에 상점이나 레스토랑 웹사이트에서는 홈페이지에 올려도 괜찮습니다.

JOHN 52:20 - 또한 이 경우 홈 페이지나 연락처 페이지와 같은 곳에서 찾을 수 있어야 하기 때문에 우리에게는 그다지 중요하지 않다고 생각합니다. 그러나 우리가 그것을 다른 곳에 가지고 있다면 그것은 우리를 위해 아무것도 바꾸지 않습니다. 따라서 비교하지 말아야 할 가장 중요한 점은 사람들이 웹사이트의 모든 페이지에 대해 별점과 검색 결과를 얻으려는 희망으로 웹사이트의 모든 페이지에 회사 리뷰와 같은 글을 올리는 것을 가끔 볼 수 있는 리뷰 마크업입니다. 그리고 그것은 우리에게 좋지 않을 것입니다. 하지만 연락처 정보가 표시되어 있다면 그건... 문제가 없다고 생각합니다.
질문 53:05 - 우리가 사용하고 있는 Google 웹사이트 속도 테스트는 매우 느린 페이지 로드 시간을 기록했지만 해외 동료와 함께 수행한 독립적인 테스트에서는 페이지 로드 시간이 매우 빠른 것으로 나타났습니다. Google이 측정한 이 잘못된 기록이 Google 알고리즘에서 사이트 순위가 매겨지는 방식에 영향을 줍니까?

Marie Haynes: 제 질문은 아니지만 상황을 설명하자면 페이지 속도에 대한 새로운 Lighthouse 데이터는 Page Speed ​​Insights 이전보다 훨씬 더 가혹합니다. 따라서 Page Speed ​​Insights에서 80점과 같은 점수를 받은 항목은 Lighthouse에서 빨간색 29점일 수 있습니다. 좋은 질문입니다. 모바일에서는 매우 느린 사이트가 강등될 수 있다는 것을 알고 있기 때문입니다. 그래서 만약 당신이 Lighthouse 테스트에서 적자라면, 강등을 유발할 수 있기 때문에 우리가 정말로 개선해야 한다고 말하는 것이 좋은 것입니까? 아니면 컷오프가 있습니까?

답변 54:07 - 그래서 우리는 외부 도구와 소셜에 사용하는 모든 것에 대한 일대일 매핑이 없습니다. 네, 그건 정말 말하기 어렵습니다. 하지만 검색에서는 Lighthouse 테스트와 유사한 실험실 테스트 데이터와 Chrome UX 보고서 데이터를 혼합하여 사용하려고 합니다. 우리가 측정하고 있는 것은 웹사이트의 사용자들이 보게 될 것입니다.

MARTIN SPLITT 55:37 - 예를 들어 Lighthouse가 특히 중간 수준의 3G 연결을 측정한다는 사실을 확인하는 것도 중요합니다. 따라서 기본적으로 최근 Apple McIntosh 또는 사무실에서 유선 연결 또는 Wi-Fi 연결과 같은 정말 좋은 최신 고속 Windows 컴퓨터를 사용하는 경우 물론 로드 시간이 2초이지만 야생에서 휴대전화를 가지고 있는 실제 사용자는 아마 그것을 보지 못할 것입니다. 따라서 웹사이트를 더 빠르게 만드는 것이 결코 나쁠 것이 없는 것과 같은 이러한 경우 중 하나입니다. 도구가 노출하는 것....물론 수정하는 것이 중요합니다. 왜냐하면 사용자가 웹사이트에서 영원히 기다리지 않기 때문입니다. 당신을 다치게 할거야. 그것은 사용자에게 피해를 줄 것입니다. 검색에 피해를 줄 뿐입니다. 하지만 저는 돈을 내지 않습니다. 도구만 보면 됩니다. 도구가 당신이 잘하고 있다고 말한다면 그것에 대해 너무 걱정할 필요가 없습니다. 도구가 당신에게 당신이 정말 좋지 않다고 말한다면, 나는 그것이 말하는 이유를 알아내는 데 시간을 할애했다고 생각합니다. 오히려 사이트를 더 빠르게 만드는 방법을 살펴봐야 합니다.

모바일 성능은 사용자는 물론 다른 모든 요소에 있어 매우 중요한 요소입니다. 따라서 귀하의 웹 사이트가 실제 조건에서 잘 작동하는지 확인하고 싶습니다. 어쩌면 싼 전화를 사서 때때로 웹사이트를 사용해 볼 수도 있습니다. 그리고 만약 내가 하고 싶은 일이고, 함께 일하고 있던 개발 팀과 함께 Google에 합류하기 전에 하던 일입니다. 이 전화에서 이 웹사이트를 사용하시겠습니까? 마치, 오, 이것은 끔찍했습니다. 나는, 음, 그래, 그래서 아마도 우리가 그것에 대해 뭔가를 해야 할 것 같다.

JOHN - Chrome에서 설정하고 다른 연결 속도를 시도할 수 있습니다. 모바일 에뮬레이터. 나는 그것이 정말 좋은 점이라고 생각합니다. 또한 사용자 기반을 살펴보는 것과 같습니다. 사람들이 귀하의 웹사이트를 고급형 iPhone으로만 사용하고 있다는 사실을 알게 된다면 분석 데이터를 살펴보십시오. 그러면 사람들이 무작위로 연결된 시골 지역에서 귀하의 사이트에 연결하는 것보다 문제가 덜할 수 있습니다. 느리고 저사양 기기를 가지고 있다면 그 이상일 것입니다.