2019년 3월 5일 – Google 도움말 행아웃 메모

이 웹마스터 도움말 행아웃에서 John Mueller의 집에 합류합니다. Page Speed, hreflang 및 Backlinks에 대한 몇 가지 중요한 질문이 있었습니다. 비디오와 전체 필사본은 여름 이후에 찾을 수 있습니다. 이것이 마음에 들면 주간 뉴스레터에 가입하는 것을 고려하십시오! 우리는 쉽게 소화할 수 있는 금주의 최고의 SEO 기사를 요약합니다.

태그 관리자를 통해 json - ld를 사용할 때의 문제를 설명할 수 있습니까 ?

11:18

그래서 제 생각에 우리가 이야기한 내용은 꽤 여러 번 그리고 이러한 행아웃의 무리이며 Barry를 비롯한 다양한 사람들이 이에 대해 작성한 새 블로그 게시물도 있다고 생각합니다. 그러나 본질적으로 태그 관리자에서 콘텐츠를 가져올 수 있다는 것은 태그 관리자에서 JavaScript 프로세스 스크립트 파일을 렌더링하고 거기에 쓰기를 출력하고 인덱싱 측면을 포함할 수 있어야 한다는 것을 의미합니다. 그래서 그것은 우리 시스템에서 항상 많은 작업을 필요로 하는 일이며 모든 페이지에 대해 항상 하는 것은 아닙니다. 특히 페이지가 동일하지 않을 경우 시스템이 이를 정당화하기가 다소 어렵습니다. 이 JavaScript도 모두 처리해야 합니다. 그리고 그 위에 태그 관리자 및 출력을 처리하지 않는 많은 테스트 도구가 있으므로 도구에서 이 마크업이 제대로 작동하는지 확인하기가 정말 어렵습니다. 검색에서 처리되는 데 시간이 더 오래 걸리고 약간 불안정할 수 있으며 주어진 시간에 색인이 생성되는 항목을 정확히 알지 못할 수 있습니다. 이것이 내가 내 관점에서 볼 때 태그 관리자를 다른 용도로 사용하는 것이 괜찮은 이유입니다. 검색을 위한 구조화된 데이터에 대한 JsonLD에도 이것을 사용하는 것이 좋지만 검색에서 특히 구조화된 데이터에 대한 훌륭한 접근 방식이 아니라는 점을 염두에 두는 것이 좋습니다. 웹 페이지에서 직접 구조 데이터를 제공하는 훨씬 더 간단한 방법으로 유지 관리가 더 쉬워지고 모든 테스트를 위해 추적이 더 쉬워집니다. 그래서 그것이 내가 권장하는 것입니다. 여기에서 태그 관리자를 사용할 수 없다는 말은 아닙니다. 확실히 사용할 수 있으며 우리는 그것을 선택하여 사용하기 위해 최선을 다할 것입니다. 그러나 그것은 그렇지 않습니다. 실제로 페이지에서 직접 구조 데이터를 제공할 때 동일한 수준의 속도와 유연성, 보안.

요약: Google 태그 관리자를 통해 JSON-LD 및 기타 구조화된 데이터를 사용할 수 있지만 최선의 방법은 아닙니다. Google이 태그 관리자에서 콘텐츠 양식을 가져오려면 JavaScript를 렌더링해야 합니다. 태그 관리자에서 스크립트를 처리하고 쓰기를 출력한 다음 색인을 생성합니다. Google에서 더 쉽게 구조화된 데이터를 페이지에 직접 제공하는 간단한 방법이 있습니다.

Google은 검색에 표시할 URL을 어떻게 선택합니까?

15:20

따라서 이러한 종류의 질문은 Google이 검색에 표시할 URL을 선택하는 방법에 대한 일반적인 질문으로 이동합니다. 한편으로는 이 경우 이미지 1의 방문 페이지에 rel canonical이 전체 ​​페이지 보기로 설정된 것과 같은 측면이 있습니다. 이 페이지가 동일하지 않음을 의미합니다. 그래서 우리가 그 표준을 선택하고 사용하는 것은 일종의 히트 또는 미스입니다. 그것이 염두에 두어야 할 한 가지 측면이라고 생각합니다. 명심해야 할 또 다른 사항은 이러한 페이지가 동등하게 보일 수 있다는 것을 이해하더라도 이 페이지 중 실제 표준 페이지를 결정하기 위해 여러 요소를 사용하는 것은 우리의 문제라는 것입니다. 그래서 그것을 위해 우리는 rel canonical을 사용하고, 무언가가 있으면 리디렉션을 사용합니다. 우리는 사이트맵, hreflang 링크와 같은 것을 사용하는 내부 외부 링크를 사용합니다. 이 모든 것은 이러한 URL 중 우리가 표시해야 하는 URL과 귀하가 지정한 표준 URL이 나머지 내에서 절대 사용하지 않는 URL인지 이해하는 데 도움이 되었습니다. 웹사이트의 링크를 표준으로 만든 것은 실수로 웹마스터가 실제로 그런 의미로 만들지 않았으며 아마도 다른 URL을 표준으로 선택해야 할 가능성이 있습니다. 그래서 제 생각에는 여기에서 일어날 일은 rel canonical을 무시하거나 그것들이 동일하지 않기 때문에 무시하거나 다른 기존 페이지 중 하나를 선택하는 것입니다. 웹 사이트. 따라서 이 특정 설정이 귀하의 경우에 그렇게 유용할 것이라고 생각하지 않습니다.

요약: Google은 URL을 이해하기 위해 rel canonical, 리디렉션, 내부 링크, 사이트맵, hreflang 을 사용하여 Google이 표시해야 하는 URL을 이해합니다. 그러나 지정된 표준 URL이 사이트의 나머지 부분에서 사용되지 않는 URL인 경우 Google은 표준 URL을 무시하고 내부적으로 많이 연결된 다른 페이지를 선택할 수 있습니다.

일반 편집기 사용자 대신 블로그 게시물에 작성자를 포함하는 것이 좋은 생각입니까?

17:38

특히 기사를 처음 쓴 사람이 누구인지 알고 작성자 랜딩 페이지처럼 취급할 수 있다면 좋은 움직임이라고 생각합니다. 순수한 사용자의 관점에서도 누군가가 귀하의 웹사이트를 방문했을 때 갑자기 이 기사가 편집자가 아닌 Barry가 작성했으며 해당 작성자에 대한 방문 페이지가 있는 경우 해당 작성자에 대한 방문 페이지가 있는 경우 해당 기사가 사용자가 선택하거나 작성자의 랜딩 페이지로 이동하여 이 작성자가 실제로 이 분야의 전문가이고 몇 년 동안 그곳에서 활동한 것을 볼 수 있는 사용자입니다. 일반적이며 Google 순위와 관련하여 직접적인 영향이 있는지 여부를 말하기는 어렵습니다. 그러나 최소한 간접적인 효과는 사용자가 귀하의 콘텐츠를 추천하는 것처럼 신뢰할 수 있다는 것입니다.

요약: 네! 저자 랜딩 페이지를 갖는 것은 저자의 EAT를 보여주는 방법입니다. 또한 일반적인 "편집자" 또는 "관리자"가 있는 것과는 대조적으로 일반적으로 사용자 경험을 개선합니다.

UI가 다른 언어로 번역될 수 있지만 사용자 생성 콘텐츠와 같은 추가 콘텐츠가 다른 언어로 유지되는 경우 권장 사항은 무엇입니까?

21:48

따라서 이것은 특히 사용자 생성 콘텐츠에서 꽤 자주 발생하는 일입니다. 따라서 포럼이나 블로그 또는 무언가가 있고 사람들이 한 언어로 댓글을 달고 있지만 UI가 다른 언어로 변경될 수 있도록 설정한 경우입니다. 그런 다음 UI가 프랑스어나 독일어로 되어 있을 수 있지만 예를 들어 모든 사람이 스페인어로 댓글을 달고 있기 때문에 콘텐츠가 여전히 스페인어로 되어 있을 수 있는 상황이 빠르게 발생합니다. 이는 본질적으로 여러 가지 방법으로 처리할 수 있는 것입니다. 따라서 내 표준 버전은 스페인어 버전이고 모든 것이 스페인어 버전과 같으며, 이는 한 가지 옵션입니다. 해당 버전 간에 hreflang 주석을 사용하여 이것이 내 콘텐츠의 가장 프랑스어 버전이라고 말할 수 있습니다. 주요 콘텐츠는 프랑스어로 되어 있지 않지만 UI는 프랑스어로 되어 있으므로 페이지를 이동하는 사용자가 일종의 탐색을 할 수 있습니다. 내 웹사이트는 당신이 할 수 있는 일입니다. 그리고 본질적으로 그것들은 당신이 선호하는 것이 무엇인지에 대해 조금 더 알려주기 위해 당신이 거기에서 제공할 수 있는 다양한 변형입니다. 실용적인 관점에서 볼 때 검색에 표시되는 방식과 관련하여 궁극적으로 귀하에게 달려 있습니다. 따라서 프랑스 사용자가 사이트에 와서 스페인어로 된 콘텐츠와 프랑스어로 된 UI가 있는 페이지를 방문하는 것이 유용하다고 생각되면 반드시 해당 버전 간에 hreflang 주석을 사용하십시오. UI가 프랑스어로 되어 있어도 주요 콘텐츠가 스페인어인 경우 프랑스 사용자가 사이트 탐색에 전혀 문제가 없다고 생각한다면 스페인어 UI가 색인화된 스페인어 버전을 유지하는 것이 합리적일 수 있습니다. 따라서 이것은 궁극적으로 당신에게 달려 있습니다. 둘 다 완벽한 솔루션이 아니라고 생각합니다. 때로는 콘텐츠가 얼마나 균일한지 인덱싱하려는 언어 버전과 사용자가 검색 결과에서 볼 것으로 기대하는 버전을 얼마나 명확하게 이해하는지에 따라 약간 다릅니다. 따라서 예를 들어 매우 국제적인 포럼이고 사람들이 모든 종류의 다른 언어로 게시물을 게시하는 경우 이 UI 버전만 인덱싱하려는 것처럼 말하는 것이 까다로울 수 있습니다. 모든 UI 버전을 인덱싱하는 것이 합리적일 수 있습니다. 물론 모든 UI 버전을 인덱싱하는 것의 단점은 사이트에 갑자기 존재하는 URL의 수가 증가한다는 것입니다. 즉, 우리는 훨씬 더 많이 크롤링해야 하며 크롤링해야 하는 대규모 사용자 생성 콘텐츠 사이트인 경우 한 손으로 모든 사용자 생성 콘텐츠를 크롤링한 다음 각각에 대해 그 배수를 모두 크롤링해야 합니다. 언어 버전이 유용한지 모르겠습니다. 웹사이트에 대한 크롤링이 너무 많아 검색 결과에 최신 콘텐츠가 빠르게 표시되지 않을 수 있습니다. 그것은 거기에 무게를 달아야 할 다른 것입니다. 몇 천 개의 기사에 대해 이야기하고 있다면 그것은 문제가 되지 않을 수 있습니다.

요약: 하나의 언어 버전을 표준 버전으로 선택하거나 해당 언어 버전 사이에 hreflang 주석을 추가할 수 있습니다.

내 사이트로 연결되는 다수의 임의 URL을 거부해야 합니까?

27:58

아니요, 그것은 본질적으로 올바른 행동이며 특히 그것이 정말로 걱정되는 경우입니다. 그래서 대부분의 웹사이트에서 우리가 그냥 무시하기 때문에 엉뚱하고 이상한 것과 같은 것들을 거부하는 것은 이치에 맞지 않는다고 생각합니다. 따라서 특히 링크와 관련하여, 당신이 그것을 볼 때 당신이 잘 말한다면 이것은 우리가 이 링크를 구매하는 것으로 볼 수 있습니다. 이것을 수동으로 보면 그들은 이것이 우리가 어리석은 일을 하고 있다고 가정할 것입니다. 그것이 아마도 그들을 거부하거나 제거하는 것이 올바른 이동이 될 것이라고 말할 수 있는 종류의 것입니다. 거기에 수백만 개의 다른 링크가 있는 것처럼 보입니다. 누군가 도구를 실행하고 이 포럼에 수많은 링크를 떨어뜨렸는데, 이는 우리 알고리즘이 이미 파악한 것입니다. 그래서 그것은 내가 걱정할 일이 아닙니다.

요약: Google은 무시할 링크를 잘 파악합니다. 하지만 거절할 때는 미안하기보다는 안심하는 것이 좋습니다.

페이지 속도는 Google에 얼마나 중요합니까?

42:30

현재 정책은 무엇입니까? 그래서 속도는 우리에게 상당히 중요하고 사용자에게 큰 영향을 미치므로 개인적으로 매우 심각하게 생각하는 부분이며 속도에 대한 좋은 부분은 꽤 객관적인 측정을 제공하는 다양한 도구가 있다는 것입니다. 실제로 작업할 수 있습니다. 우리 중 많은 사람들이나 SEO와 같은 다른 문제와 관련하여, 나는 그 속도와 같은 콘텐츠의 품질이 상당히 측정 가능하고 작업할 수 있는 어떤 것인지 모르겠습니다. 웹사이트 내에서 사용자 행동의 직접적인 영향으로 사용되는 것입니다. 따라서 Google의 관점에서 보면 속도가 중요하다고 말하는 것이 아니라 순위 추적기이지만 사용자가 웹사이트를 방문하고 웹사이트가 해당 사용자를 로드하는 데 갑자기 몇 초 더 오래 걸릴 때 직접 볼 수 있는 것입니다. 웹사이트에서 매우 다르게 반응할 것이며 웹사이트에서 고객을 정의하더라도 고객으로 전환하는 데 더 많은 어려움을 겪을 것입니다.

요약: Google에서는 속도가 매우 중요합니다. 쉽게 추적하고 쉽게 실행할 수 있는 하나의 메트릭입니다. 사이트의 성능과 페이지 속도를 높이는 데 도움이 되는 작업에 대한 훌륭한 통찰력을 제공하는 훌륭한 도구가 있습니다.

Google Ads 비용을 지불하면 순위가 더 좋아질까요, 나빠질까요?

47:24

그래서 우리는 때때로 이 질문을 받습니다. 여기에서 질문은 '내 순위가 영향을 받을까요? 하지만 더 좋거나 최악의 부분은 Google Ads를 사용하면 순위가 더 좋아지지 않을 것이라는 일부 사람들의 말을 듣는 것입니다. 어떤 사람들은 더 많은 광고를 구매하기를 원하기 때문에 Google 광고를 사용하면 순위가 낮아질 것이라고 말하지만 둘 다 사실이 아닙니다. 따라서 Google 검색결과는 Google Ads 사용 여부에 따라 완전히 독립적이며 웹사이트에서 사용하는 기술과는 완전히 별개입니다. 따라서 분석이나 다른 추적 도구와 같은 것을 사용하는 경우 전적으로 귀하에게 달려 있습니다. Adsense 또는 이러한 다른 광고 네트워크로 수익을 창출하는 경우 전적으로 귀하에게 달려 있습니다. 따라서 웹사이트 내에서 Google 제품을 사용하는지 여부에 관계없이 웹사이트에 다른 Google 서비스를 사용하는 것은 전적으로 귀하에게 달려 있습니다. 그것은 우리가 이러한 서비스 종류를 독자적으로 유지하는 것을 선호하는 것입니다. Google 서비스가 좋지 않은 특별한 이유 중 하나라고 한다면 저는 그것을 사용하고 싶지 않고 다른 것을 사용해도 무방합니다. 우리는 웹사이트에 집중하는 것과 사용자에게 옳다고 생각하는 것을 하는 것과 이 특정 제품을 사용해야 하는 것 사이에서 고민하는 그런 상자에 당신을 가두고 싶지 않습니다. 그래서 우리는 이것들을 함께 묶지 않고 명시적으로 하며 이러한 것들이 잘 작동하는지 확인하기 위해 열심히 일합니다.

요약: Google Ads는 자연 순위에 영향을 미치지 않습니다.

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

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

전체 비디오 및 대본

질문 1:14 - 2주 전 우리 웹사이트는 밤새 Google 트래픽의 94%를 잃었습니다. 지난 20년 동안 일관된 검색 트래픽과 큰 변화가 없었기 때문에 Cloudfare와 같은 CDN을 통해 IPS 또는 SSL을 공유하는 기술적인 요소가 알고리즘적으로 트래픽을 크게 떨어뜨릴 수 있다고 가정합니다. 우리는 더 깊이 파고 들어 동일한 IP에서 매우 위험한 콘텐츠로 보이는 일부 사이트를 발견했습니다. 우리는 테마를 변경할 수 있고 전용 인증서를 가질 수 있지만 트래픽이 계속 줄어들 것입니다. 여기서 무슨 일이 일어날 수 있습니까?

답변 2:01 - 그러나 일반적으로 다른 사이트가 동일한 IP 주소에서 호스팅된다고 해서 일반적으로 우려할 이유는 아닙니다. 따라서 특히 더 큰 호스팅 업체에서 IP 주소를 공유하는 것은 CDN에서 매우 일반적입니다. 공유 IP 주소는 매우 일반적입니다. 그리고 많은 CDN이 다른 국가에 엔드포인트를 갖고 있고 해당 엔드포인트를 그곳에서 활성화된 다른 웹사이트와 공유하기 때문에 변화하는 것입니다. 따라서 본질적으로 사용자와 독일은 예를 들어 미국의 사용자와 다른 IP 주소를 볼 수 있지만 일반적으로 이것은 IP 주소를 공유하는 매우 일반적인 관행이며 문제가 되지 않을 것입니다. 초기에 이것은 날짜와 호스트를 인식하는 데 때때로 매우 유용했습니다. 고정 주소가 있는 하나의 IP 주소와 9000개의 사이트가 있고 모두 스팸이고 동일한 호스트에 다른 두 개의 웹사이트가 있는 경우 이 두 사이트가 실제로 완전히 통합되었는지 확인하기 어려울 수 있습니다. 이 9,000개의 다른 사이트와 비교하여 별도의 사이트입니다. 알고리즘에 있어서는 일종의 까다로운 상황입니다. 그러나 이와 같은 대부분의 경우 우리는 모든 종류의 다른 사이트가 혼합되어 있는 것을 볼 수 있으므로 다른 국가의 다른 언어로 된 다른 사이트는 대상 사용자가 다릅니다. 일부 스팸 사이트 일부 스팸 사이트는 동일한 IP 주소에 있으며 이 모든 것이 완벽합니다. . 그래서 우리가 이렇게 말할 이유가 되지는 않을 것입니다. 이 IP 주소에 스팸 사이트가 하나 있기 때문에 문제가 될 수 있습니다. 그래서 나는 이 웹사이트에서 무슨 일이 일어났는지 구체적으로 알지 못합니다. 나는 일반적으로 우리 웹사이트의 한 측면이 귀하에게 좋은 것과 같다고 말하는 경향이 있기 전에 수년 동안 검색에서 좋은 성과를 거두고 있다는 점을 조사했습니다. 하지만 항상 그렇게 유지해야 하는 것은 아닙니다.

따라서 사이트가 과거에 잘 하고 있었고 검색이 잘 되었다고 해서 한편으로는 계속해서 검색을 잘 할 것이라는 의미는 아닙니다. 예 사용자 기대치는 다른 한편으로는 Google의 알고리즘이 변경됩니다. 따라서 이러한 것들은 항상 변할 수 있고 상황이 때때로 크게 변하는 일이 발생할 수 있습니다. 우리의 목표는 이 특정 웹사이트가 나쁜 알고리즘이라고 말하는 것이 아니라 사용자 기대에 부응하지 못했거나 우리는 더 이상 사용자가 기대하는 것과 일치하지 않는 방식으로 일을 하고 있으므로 사용자와 관련성이 있는 결과를 검색 결과에 다시 가져오도록 알고리즘을 변경합니다. 따라서 웹 사이트 유형에 따라 항상 사용할 수 있는 것입니다.

질문 5:49 - 꽤 오래 전에 기본적으로 콘텐츠를 훔친 다음 저작권을 위반하지 않도록 수정한 다음 우리보다 순위가 높은 사이트에 대해 우리보다 순위가 높은 것으로 나타났습니다. 우리는 뒤돌아볼 때 패턴을 발견하고 일부 조사를 통해 사이트를 재설계하고, 품질을 개선하고, 순위를 개선한 다음 이를 복사하고 다음 달 또는 두 달에 걸쳐 순위를 매기기 시작할 것이라는 조사를 했습니다. 우리와 그것은 음 우리에게 알고리즘이 혼란스러운 것처럼 보이고 우리 대신 콘텐츠 작성자가 된 것에 대한 크레딧을 사이트에 부여하고 결과적으로 순위에서 우리를 억제합니다.

답변 6:37 - 잘 모르겠습니다. 정확히 무슨 일이 일어나고 있는지 보려면 사이트를 살펴봐야 합니다. 우리 알고리즘이 항상 해당 검색어에 대해 귀하의 사이트보다 해당 사이트를 선택하는 것처럼 알고리즘적 관점에서 말하기가 까다롭습니다. 그러나 내가 일반적으로 목표로 하는 것은 이러한 사이트가 귀하의 콘텐츠를 복사하는 경우 근본에서 문제를 해결하여 콘텐츠를 복사하지 않도록 권장하는 방법을 찾는 것입니다. 따라서 DMCA 불만 사항과 같은 항목을 살펴보십시오. 귀하의 경우와 관련이 있는지 여부는 알 수 없지만 검색 시 이러한 버전의 콘텐츠는 해당 쿼리에 대한 순위를 매겨야 합니다.

질문 11:18 - 태그 관리자를 통해 json-ld를 사용하는 문제를 설명할 수 있습니까? 태그 관리자는 검색 콘솔 및 아마도 분석을 확인하는 데 사용되므로 충분히 안정적입니다.

답변 11:33 - 그래서 우리가 이야기한 내용은 이 행아웃에 대해 여러 번 언급했으며 Barry를 비롯한 다양한 사람들이 이에 대해 작성한 새 블로그 게시물도 있다고 생각합니다. 그러나 본질적으로 태그 관리자에서 콘텐츠를 가져올 수 있다는 것은 태그 관리자에서 JavaScript 프로세스 스크립트 파일을 렌더링하고 거기에 쓰기를 출력하고 인덱싱 측면을 포함할 수 있어야 한다는 것을 의미합니다. 그래서 그것은 우리 시스템에서 항상 많은 작업을 필요로 하는 일이며 모든 페이지에 대해 항상 하는 것은 아닙니다. 특히 페이지가 동일하지 않을 경우 시스템이 이를 정당화하기가 다소 어렵습니다. 이 JavaScript도 모두 처리해야 합니다. 그리고 그 위에 태그 관리자 및 출력을 처리하지 않는 많은 테스트 도구가 있으므로 도구에서 이 마크업이 제대로 작동하는지 확인하기가 정말 어렵습니다. 검색에서 처리되는 데 시간이 더 오래 걸리고 약간 불안정할 수 있으며 주어진 시간에 색인이 생성되는 항목을 정확히 알지 못할 수 있습니다. 이것이 내가 내 관점에서 볼 때 다른 용도로 태그 관리자를 사용하는 것이 좋은 이유입니다. 검색을 위한 구조화된 데이터에 대한 JsonLD에도 이를 위해 사용하는 것이 좋지만 검색에서 특히 구조화된 데이터에 대한 훌륭한 접근 방식이 아니라는 점을 염두에 두는 것이 좋습니다. 웹 페이지에서 직접 구조 데이터를 제공하는 훨씬 더 간단한 방법으로 유지 관리가 더 쉬워지고 모든 테스트를 위해 추적이 더 쉬워집니다. 그래서 그것이 내가 권장하는 것입니다. 여기에서 태그 관리자를 사용할 수 없다는 말은 아닙니다. 확실히 사용할 수 있으며 우리는 그것을 선택하여 사용하기 위해 최선을 다할 것입니다. 그러나 그렇지 않습니다. 실제로 페이지에서 직접 구조 데이터를 제공하는 것과 같은 수준의 속도와 유연성, 보안.

질문 14:00 - 클라이언트가 301 대신 302를 사용하여 이동하여 HTTPS 마이그레이션을 수행했는데 301로 변경해야 합니까? Google이 이것이 영구적인 리디렉션임을 이해하는 데 얼마나 걸립니까?

답변 14:14 - 그래서 아마 많은 사람들이 사이트 이동에 잘못된 리디렉션 태그를 사용한다는 사실을 알게 될 것이며 이를 올바르게 파악하기 위해 계속 노력하고 있습니다. 무슨 일이 일어나고 있는지 확인하는 빠른 방법은 검색 콘솔에서 항목이 제대로 인덱싱되고 있는지 확인하는 것입니다. 따라서 새 도메인이 잘 작동한다면 이미 문제가 없는 것입니다. 즉, 웹 사이트에서 이와 같은 문제나 수정하기 쉽고 큰 영향을 미칠 수 있는 다른 기술 문제를 발견했다면 계속해서 수정하겠습니다. 특히 잘못된 리디렉션 유형은 대부분의 웹 사이트에서 htaccess 파일의 한 줄 변경과 같습니다. 그래서 정말 쉽게 고칠 수 있는 부분입니다. 따라서 검색 엔진이 잘못된 방식으로 해석하는 것에 대해 걱정할 필요가 없습니다.

질문 15:20 - 이미지 갤러리에는 /gallery/image1 또는 /image2 또는 /image 3과 같은 이미지에 대한 고유 URL이 있으며 갤러리 /view all을 추가하고 이를 표준 URL로 사용하고 싶지만 이 링크가 없습니다. 사이트 어디에서나 그렇게 할 수 있습니까? 보기가 모두 독자에게 보여야 합니까?

답변 15:46 - Google이 검색에 표시할 URL을 선택하는 방법에 대한 일반적인 질문으로 이동합니다. 한편으로는 이 경우 이미지 1의 방문 페이지와 같은 측면이 있습니다. 모든 페이지 보기는 이러한 페이지가 동일하지 않음을 의미합니다. 그래서 우리가 그 표준을 선택하고 사용하는 것은 일종의 히트 또는 미스입니다. 그것이 염두에 두어야 할 한 가지 측면이라고 생각합니다. 명심해야 할 또 다른 사항은 이러한 페이지가 동등하게 보일 수 있다는 것을 이해하더라도 이 페이지 중 실제 표준 페이지를 결정하기 위해 여러 요소를 사용하는 것은 우리의 문제라는 것입니다. 그래서 우리는 rel canonical을 사용합니다. 우리는 무언가가 있으면 리디렉션을 사용합니다. 우리는 사이트맵, hreflang 링크와 같은 것을 사용하는 내부 외부 링크를 사용합니다. 이 모든 것은 이러한 URL 중 우리가 표시해야 하는 URL과 귀하가 지정한 표준 URL이 나머지 내에서 절대 사용하지 않는 URL인지 이해하는 데 도움이 되었습니다. 웹사이트의 링크를 표준으로 만든 것은 실수로 웹마스터가 실제로 그런 의미로 만들지 않았으며 아마도 다른 URL을 표준으로 선택해야 할 가능성이 있습니다. 그래서 제 생각에는 여기에서 일어날 일은 rel canonical을 무시하거나 그것들이 동일하지 않기 때문에 무시하거나 다른 기존 페이지 중 하나를 선택하는 것입니다. 웹 사이트. 따라서 이 특정 설정이 귀하의 경우에 그렇게 유용할 것이라고 생각하지 않습니다.

질문 17:38 - 다른 언어와 국가에 제공하고 싶은 콘텐츠가 많지만 주요 콘텐츠가 아닌 인터페이스만 번역한 사이트에 대한 추천은 무엇입니까?

답변 17:55 - 이것은 특히 사용자 제작 콘텐츠에서 꽤 자주 발생하는 일입니다. 따라서 포럼이나 블로그 또는 무언가가 있고 사람들이 한 언어로 댓글을 달고 있지만 UI가 다른 언어로 변경될 수 있도록 설정한 경우입니다. 그런 다음 UI가 프랑스어나 독일어로 되어 있을 수 있지만 예를 들어 모든 사람이 스페인어로 댓글을 달고 있기 때문에 콘텐츠가 여전히 스페인어로 되어 있을 수 있는 상황이 빠르게 발생합니다. 이는 본질적으로 여러 가지 방법으로 처리할 수 있는 것입니다. 따라서 내 표준 버전은 스페인어 버전이고 모든 것이 스페인어 버전과 같으며, 이는 한 가지 옵션입니다. 해당 버전 간에 hreflang 주석을 사용하여 이것이 내 콘텐츠의 가장 프랑스어 버전이라고 말할 수 있습니다. 주요 콘텐츠는 프랑스어로 되어 있지 않지만 UI는 프랑스어로 되어 있으므로 페이지를 이동하는 사용자가 일종의 탐색을 할 수 있습니다. 내 웹사이트는 당신이 할 수 있는 일입니다. 그리고 본질적으로 그것들은 당신이 선호하는 것이 무엇인지에 대해 조금 더 알려주기 위해 당신이 거기에서 제공할 수 있는 다양한 변형입니다. 실용적인 관점에서 볼 때 검색에 표시되는 방식과 관련하여 궁극적으로 귀하에게 달려 있습니다. 따라서 프랑스 사용자가 사이트에 와서 스페인어로 된 콘텐츠와 프랑스어로 된 UI가 있는 페이지를 방문하는 것이 유용하다고 생각되면 반드시 해당 버전 간에 hreflang 주석을 사용하십시오. UI가 프랑스어로 되어 있어도 주요 콘텐츠가 스페인어인 경우 프랑스 사용자가 사이트 탐색에 전혀 문제가 없다고 생각한다면 스페인어 UI가 색인화된 스페인어 버전을 유지하는 것이 합리적일 수 있습니다. 따라서 이것은 궁극적으로 당신에게 달려 있습니다. 둘 다 완벽한 솔루션이 아니라고 생각합니다. 때로는 콘텐츠가 얼마나 균일한지 인덱싱하려는 언어 버전과 사용자가 검색 결과에서 볼 것으로 기대하는 버전을 얼마나 명확하게 이해하는지에 따라 약간 다릅니다. 따라서 예를 들어 매우 국제적인 포럼이고 사람들이 모든 종류의 다른 언어로 게시물을 게시하는 경우 이 UI 버전만 인덱싱하려는 것처럼 말하는 것이 까다로울 수 있습니다. 모든 UI 버전을 인덱싱하는 것이 합리적일 수 있습니다. 물론 모든 UI 버전을 인덱싱하는 것의 단점은 사이트에 갑자기 존재하는 URL의 수가 증가한다는 것입니다. 즉, 우리는 훨씬 더 많이 크롤링해야 하며 크롤링해야 하는 대규모 사용자 생성 콘텐츠 사이트인 경우 한 손으로 모든 사용자 생성 콘텐츠를 크롤링한 다음 각각에 대해 그 배수를 모두 크롤링해야 합니다. 언어 버전이 유용한지 모르겠습니다. 웹사이트에 대한 크롤링이 너무 많아 검색 결과에 최신 콘텐츠가 빠르게 표시되지 않을 수 있습니다. 그것은 거기에 무게를 달아야 할 다른 것입니다. 몇 천 개의 기사에 대해 이야기하고 있다면 그것은 문제가 되지 않을 수 있습니다.

질문 21:25 - 블로그 게시물이 일반 편집자 사용자가 작성한 것으로 처음 표시되었을 때부터 전자 상거래 웹사이트와 함께 블로그를 운영하고 있습니다. 품질 가이드라인과 EAT를 보면 편집자를 포스트 작성자의 실명으로 교체하고 싶습니다. 이런 종류의 작업은 긍정적입니까 아니면 스팸을 볼 수 있습니까?

답변 21:48 - 특히 누가 기사를 처음 작성했는지 알고 작성자 랜딩 페이지처럼 취급할 수 있다면 좋은 조치라고 생각합니다. 저는 그것이 좋은 조치라고 생각합니다. 순수한 사용자의 관점에서도 누군가가 귀하의 웹사이트를 방문했을 때 갑자기 이 기사가 편집자가 아닌 Barry가 작성했으며 해당 작성자에 대한 방문 페이지가 있는 경우 해당 작성자에 대한 방문 페이지가 있는 경우 해당 기사가 사용자가 선택하거나 작성자의 랜딩 페이지로 이동하여 이 작성자가 실제로 이 분야의 전문가이고 몇 년 동안 그곳에서 활동한 것을 볼 수 있는 사용자입니다. 일반적이며 Google 순위와 관련하여 직접적인 영향이 있는지 여부를 말하기는 어렵습니다. 그러나 최소한 간접적인 효과는 사용자가 귀하의 콘텐츠를 추천하는 것처럼 신뢰할 수 있다는 것입니다.

질문 22:58 - 데스크톱 및 amp 버전의 스키마 마크업, 데스크톱 버전이 마이크로데이터를 사용하여 구현되지만 amp 버전이 json-ld를 사용하는 경우 괜찮습니까?

답변 23:09 - 물론 완벽합니다. 거기에서 사용되는 형식이나 형식과 관련하여 염두에 두어야 할 유일한 문제는 내가 아는 한 어떤 종류의 구조화된 데이터는 json-ld에서만 사용할 수 있다는 것입니다. 따라서 사용 중인 구조화된 데이터 유형을 다시 확인해야 하지만 동일한 데스크톱 모바일 내에서도 한 가지 유형의 구조 데이터를 사용하는 사이트 버전과 다른 유형을 사용하는 다른 버전이 있는 경우가 있습니다. 예를 들어 블로그가 있고 웹사이트와 전자상거래 사이트에 제품 디렉토리가 있고 전자상거래 사이트에 json-ld를 사용하는 리뷰가 있고 블로그에서 마이크로 데이터를 사용하는 기사 마크업, 그것이 올바른 방법인지는 모르겠지만 완벽하게 괜찮을 것입니다.

질문 24:19 - 숨겨진 콘텐츠 display:none과 관련하여 Google 지원은 정상이며 흰색 배경의 흰색 글꼴 또는 글꼴 크기 0은 지침에 위배된다고 언급했지만 display:none은 어떻습니까?

답변 24:32 - 숨겨진 콘텐츠는 일반적으로 우리가 높이 평가하는 것이 아닙니다. 특히 페이지 자체에는 실제로 표시되지 않는 키워드를 Google 색인에 푸시하려고 시도하는 사이트로 나타납니다. 그래서 정말 피하고 싶은 것입니다. 반응형 디자인에 대해 언급하셨고 나머지 질문에 대해서는 그것이 여기에서 작용하는 한 가지 측면이라고 생각합니다. 따라서 반응형 디자인을 사용하여 이 콘텐츠를 모바일 사용자나 데스크톱 사용자가 볼 수 있도록 하는 경우 문제가 없습니다. 그러나 이 콘텐츠가 흰색 배경의 0 또는 흰색 글꼴 또는 검은색 배경의 검은색 글꼴과 같이 본질적으로 항상 보이지 않는다면 우리 시스템이 감지하여 잘 말할 수 있는 그런 종류의 것입니다. 아마도 여기에 있는 이 텍스트는 관련성이 없을 것입니다. 그렇지 않으면 실용적인 관점에서 이와 같은 것에 대해 직접 조치를 취하지 못할 것입니다. 그러나 이것을 알아내려고 하는 것 외에는 검색과 관련하여 해당 콘텐츠를 평가절하하려고 할 것입니다. 스니펫에 표시될 가능성이 줄어들기 때문에 해당 페이지에서 실제로 중요한 것으로 취급될 가능성이 줄어듭니다.

질문 25:55 - 링크 수동 조치 후 재검토 요청이 수락되었지만 트래픽에서 잠재적 순위를 회복하지 못한 경우 Google은 도메인을 얼마 동안 처리합니까?

답변 26:08 - 수동 조치가 해결되면 해당 사이트가 직접 조치 없이 검색에서 거의 직접적으로 표시될 경우 두 가지 측면이 있다고 생각합니다. 따라서 여기에 한 가지 예외가 있습니다. 순수한 스팸 이유로 사이트가 제거되면 기본적으로 색인에서 완전히 제거됩니다. 따라서 단순히 다시 켜고 다시 표시할 수 있는 것이 아니라 실제로 다시 크롤링하고 해당 사이트를 처리해야 하는 경우도 있지만 다른 모든 직접 조치의 경우 해당 직접 조치가 해결되면 이전 상태로 돌아왔습니다. Google이 원한을 품고 여기에 직접 조치가 있었다고 말하는 것이 아닙니다. 그래서 정말 해결되었으니 각별한 주의가 필요합니다. 물론 링크와 관련하여 귀하의 사이트가 부자연스러운 링크로 인해 검색 결과에서 인위적으로 순위가 매겨진 경우 수동 조치를 취하고 이러한 부자연스러운 링크를 제거하여 수정하면 당연히 귀하의 사이트는 그 부자연스러운 연결은 이제 사라졌습니다. 따라서 이와 같은 문제를 해결한 후 가시성 변화를 보는 것이 완전히 정상적인 경우입니다. 마찬가지로 웹사이트의 다른 요소로 인해 사이트가 부자연스럽게 표시되고 다른 요소를 제거하여 이를 해결하는 경우 사이트는 분명히 자연스럽게 다시 보이게 되지만 제거한 것들로 인해 부자연스럽게 보이지는 않으니 염두에 두셔야 합니다.

Question 27:59 - In looking at some of our backlink profile we had found, I don't even know how our links ended up on these pages, like on pages that have just like 7,000 links and things like that. We disavowed them when we found them. Is there anything we need to be concerned about other than doing that with when we find stuff like that?

Answer 28:20 - No that's that's essentially the right move to do and especially if it's something that you're really worried about. So I think for most websites it doesn't make sense to go out there and disavow things that are just like iffy and weird because for the most part we just ignore those. So in particular with regards to links, if it's something that when you look at it you say well this could be seen as these links be being bought by us, like naturally placed there by us, if someone from the website team were to take a look at this manually and they would assume that, this is us doing something stupid, that's the kind of thing where I'd say probably disavowing them or getting them removed would be the right move there but otherwise if it's just an iffy link and it looks like it's something like there are millions of other links on there someone ran a tool and dropped tons of links into this forum then that's something our algorithms have figured out already. So that's not something I wouldn't worry about.

Question 30:06 - What do you suggest to tackle a low traffic, low quality pages on a site? There lots of suggestions regarding content pruning what recommendations do you have regarding that?

Answer 30:20 - So I think first off the assumption that a page that has low traffic is also low quality is something that I would question and sometimes pages just have low traffic because a lot of people search for them but they're still a really good truck pages. So II would question kind of the assumption that you can just go into analytics and sort of your pages by a number of page views and delete all of the lowest pages there because I don't think that necessarily picks up like that these pages are really low quality or not. So that's kind of a first assumption there, if you know your website then obviously you can combine different metrics to try to figure out where the low quality pages are but I would still recommend making sure that these are really low quality pages before you take any kind of harsh action on those pages. And then as a next step if you do know that these are low quality pages when whenever I talk to our engineers from the quality team they tell us not to tell web masters to just go off and delete those pages but instead to going to improve them. So if you know that they're low quality pages that probably means you know what is missing and that probably means you know there are ways to kind of make these higher quality pages. So that's kind of the direction I would take there and not just delete things that are low quality but figure out a way to make them more high quality instead. So that could be by combining pages maybe it's something where you see this one-page, its kind of thin but it matches this your page and you have otherwise on your website maybe combining them makes sense. So 301 redirecting them to kind of one shared URL instead that might be an option. Rewriting them to be higher quality is obviously a good idea obviously takes work so it's not this one simple magic trick to make number one. Then finally if it's really something that you can't resolve at all or that is such a big mass of pages that are low quality that you can't really fix then maybe deleting them is it right. So those are kind of the different variations there that are available but again I would strongly question the the assumption that low traffic equals low quality. So if you're looking even looking at a larger site don't just assume that because something has low traffic is sign that it's not important for your website or for the rest of the web.

Answered Cont' 34:03 - Yeah so I think one way you could look at this is to say given this state of content that you have what would be your preferred new website look like? So kind of saying like assuming I had all of this content and I had to create a new website out of it what would it look like and then to try to find a way to migrate your existing content into this new structure that you have in mind and like I said it could improve include combining pages, combining maybe tens of different pages together into one stronger page, it could be deleting pages where you say, well these don't make any sense for my website anymore maybe it was something that users cared about a couple years ago but now, I don't know, nobody is playing ingress anymore so all of those ingress pages on my website I have to make a hard decision and delete them. I can see the shocked faces everywhere in here now. But these kind of things happen over time and it makes sense to clean things up over time and sometimes it means deleting, sometimes that means combining, sometimes that just means rewriting and cleaning up. So it's it's hard to have one one answer that works for every side in every situation.

Question 36:36 - How to fix the crawl frequency of low priority pages within a website? Will Google crawl more of such pages because the quantity of these pages is more compared to the important pages?

Answer 36:49 - So I think this was your question as well in general you don't need things the the crawl rate of pages unless these are pages that are being changed more frequently than the crawl rate. So if you have an article that you wrote and it's being crawled once every three months and you're never changing this article that's that's perfectly fine we don't need to crawl it more often. There is no ranking bonus for being crawled more often. So crawling from our site is more of a technical thing where we say, this page has changed we should find a way to pick up this change as quickly as possible. It's not that we would say well the stage has been crawled twice in the last week therefore we will rank it higher those are completely separate parts of our algorithms.

Question 37:48 - I was checking the log files and 90% of our crawl budget is going to those specific URLs only and only 10% is crawling my product pages. So I was wondering I could make them crawl less frequently for those specific sections and maybe Google can start crawling or kind of giving more importance to my other sections of a set?

Answer 38:18 - Okay so you actually want to do the opposite which is I think a good move too. To have those pages crawled less frequently. So from from our point of view there's really no way to do that. So it's something that you would need to almost attack from the other way around to say, that I think these are other pages that are important on my website and therefore I'll link them prominently within my website. I'll make sure that all of my other pages refer to those pages, that they're specifying the sitemap file with the last modification page that we can confirm. So all of those signals to help us understand we need to be able to crawl these pages more frequently because there are changes on these pages. On the other hand if there are no changes on these pages we don't really to recall them for more free company so that's kind of be the other aspect there. If these are pages that are important for you but they are not changing frequently then there's no need to artificially force them to be crawled more often.

Question 40:11 - Can you tell if with redirection only link penalty passes or link penalty and content penalties both pass for example at website with pure spam manual action is redirected to another site so technically the URLs will be a soft 404, will it affect the redirected website?

Question 40:37 - So I'm not quite sure with which part of this question you're you're kind of focusing on. On the one hand if a random spammy website redirects to your website that's usually something we can recognize and just ignore. On the other hand if yours is that spammy website and you're redirecting to another website to try to escape that penalty then probably we will be able to follow that site migration and apply that manual action or algorithmic action to the new website as well. So my recommendation there would be instead of trying to get away by doing fancy redirects or other types of site moves. I would recommend just cleaning up the issues so that you don't have to worry about those anymore. So if there are link actions with regards to that website then clean up those those links so that you're in a clean state again. The reconsideration process is great for that because someone from the web spam team will take a manual look at your website and they'll say, this looks good this is fine like. You did good work and clean things up it's clear that you understand what you should be doing now so we can remove them. So I think that's really useful to have there from a practical point of view. So that would be kind of my recommendation if you're the website that has this problem. On the other hand if like I mentioned some random website redirects to your website and that's usually something that we can recognize, this is not a normal site move this is just the read website redirecting to you to another website and we can get that.

Question 42:30 - John two quick general questions one related to site load speed, we've read and heard various things including recently people saying that like every microsecond counts and things like that, what is the current policy I know in the past you said as long as it's not ridiculously long to load you're fine?

Answer 42:53 - What is the current policy? So speed is something that does matter quite a bit to us and it has a big effect on users so that's something that I would personally take quite seriously and I think the the nice part about speed is there various tools that gives you pretty objective measures there that you can actually work on. With regards to a lot of us or other issues around SEO like, I don't know the quality of their content things like that speed is something that that is quite measurable and something that you can kind of work on, and it should also be something we're used a direct effect from your users behavior within your website. So it's not just something that from from Google's point of view like we say speed is important it is rank tracker but it's something that you will see directly when users come to your website and your website is suddenly taking a couple seconds longer to load those users will react quite differently on your website and you'll have more trouble converting them into customers however you define customers on your website.

Question 44:08 - From the standpoint of like if it's 1.1 seconds versus 1.2 second that kind of thing would would you say that that's very important to try to really optimize those?

Answer 44:21 - I think the tricky part with speed is there's so many different measures in the meantime that it's hard for me to say like, load time is the only thing you should be thinking about, but there ways to to kind of determine how quickly the page is is generally accessible. How quickly they the content is visible on the page, even kind of ignoring the aspect that maybe the rest of the page below the fold is still rendering and still takes a bit of time to actually be ready, maybe the part that users care about is actually visible fairly quickly. So from from that point of view usually small differences are less of a thing but kind of like I mentioned speed is something where you can use these different tools who could come up with a different metrics and you can focus on those metrics and try to improve those and you can measure that yourself and you can kind of work on that without having to go through various Google tools and waiting for things to update in the index in these tools.

Question 45:47 - Can I use Google official videos in my blog or can I only link to them for example Matt Cutts videos about SEO. I will use Adsense on the blog when I have enough adsense my blog will be complete in 6 months.

Answer 46:03 - I don't think there are any restrictions with regards to embedding videos for a channel but if there were no restrictions then I think the embed option YouTube wouldn't be available there. So if the embed option is there then then go for it. I think in in general I'd be cautious about using just a video as the primary piece of content on a web page and you should really work to kind of use the video in a way that supports your primary content but not that it replaces your primary. So for example I wouldn't take any of these videos and just put them on a blog post and add a title to them and expect them to show up highly in search. But if you have specific content around that video if you have a transcription of that many don't you have some comments to that transcription to the content that are shown in the video or you're using that video as kind of a point of reference with regards to your content and I think that's a perfectly fine approach. But just purely using a video on a page is something that atleast in a web search point view makes it really hard for us to determine what is actually useful on this page and why should we show it in the search results.

Question 47:27 - If I pay for Google Ads will my ranking be better or worse?

답변 47:34 - 그래서 우리는 가끔 이 질문을 받습니다. 여기서 질문은 내 순위에 영향을 미칠까요? 하지만 더 좋거나 가장 나쁜 부분은 일부 사람들이 말하는 것을 듣게 되는 것입니다. Google Ads를 사용하면 더 좋습니다. 일부 사람들은 Google 광고를 사용하면 더 많은 광고를 구매하기를 원하지만 둘 다 사실이 아니기 때문에 Google 광고를 사용하면 순위가 낮아질 것이라고 말합니다. 따라서 Google 검색결과는 Google Ads 사용 여부에 따라 완전히 독립적이며 웹사이트에서 사용하는 기술과는 완전히 별개입니다. 따라서 분석이나 다른 추적 도구와 같은 것을 사용하는 경우 전적으로 귀하에게 달려 있습니다. Adsense 또는 이러한 다른 광고 네트워크로 수익을 창출하는 경우 전적으로 귀하에게 달려 있습니다. 따라서 웹사이트 내에서 Google 제품을 사용하는지 여부에 관계없이 웹사이트에 다른 Google 서비스를 사용하는 것은 전적으로 귀하에게 달려 있습니다. 그것은 우리가 이러한 서비스 종류를 독자적으로 유지하는 것을 선호하는 것입니다. Google 서비스가 좋지 않은 특별한 이유 중 하나라고 한다면 저는 그것을 사용하고 싶지 않고 다른 것을 사용해도 무방합니다. 우리는 당신이 웹사이트에 집중하는 것과 사용자에게 옳다고 생각하는 것을 하는 것과 이 특정 제품을 사용해야 하는 것 사이에 갇힌 것과 같은 상자에 당신을 집어넣고 싶지 않습니다. 그래서 우리는 이것들을 함께 묶지 않고 명시적으로 하며 이러한 것들이 잘 작동하는지 확인하기 위해 열심히 일합니다.