2019년 2월 8일 – Google 도움말 행아웃 메모

이번 주 John은 웹사이트의 신뢰성과 관련하여 우리의 열렬한 팬인 Quality Ratingrs Guide에 대한 훌륭한 통찰력을 얻었습니다. 다음은 SEO에 가장 도움이 된다고 생각되는 직접 뽑은 질문과 답변입니다. 전체 비디오 및 전사는 아래에 있습니다!

<p> 대신 h 태그가 사용될 때 Google은 페이지를 어떻게 해석합니까?

4:34

큰 문제가 없다고 생각합니다 모든 것이 중요하다고 말함으로써 당신은 우리에게 모두 같은 중요성을 말하고 있습니다. 따라서 모든 것이 중요하므로 특별히 중요한 것은 없습니다. 그래서 우리는 페이지 내의 컨텍스트를 이해하는 데 문제가 있습니다. 그래서 대부분 청소를 하게 됩니다. 우리는 일반 텍스트에서 어떤 부분이 정말 중요하고 어떤 부분이 어떤 종류인지 파악할 수 있으므로 이러한 페이지를 조금 더 잘 이해할 수 있습니다. 수정으로 인해 직접적인 순위 변경을 볼 수 있을지 모르겠지만 페이지의 실제 내용을 파악하기가 더 쉽습니다. 이것이 스팸이나 문제가 될 것이라고 생각하지 않습니다. 정말 중요하다고 말함으로써 우리에게 제공할 수 있는 만큼 많은 정보를 제공하지 않는 것입니다. 그리고 이것은 일종의 정상적인 콘텐츠입니다.

요약: 이것은 아마도 큰 문제가 아닐 것입니다. 그러나 John은 Google이 h 태그를 사용하여 페이지의 어떤 콘텐츠가 중요하고 페이지가 무엇에 관한 것인지 결정할 수 있음을 확인했습니다.

Google이 때때로 신디케이트된 콘텐츠의 표준을 존중하지 않는 이유는 무엇입니까?

8:56

나는 이것이 항상 까다로운 상황이라고 생각합니다. 어떤 페이지가 이러한 쿼리 중 일부와 가장 관련이 있는지 파악하고 사용자가 해당 페이지로 직접 연결되도록 하려고 하지만 이들이 완전히 별개의 웹 사이트이고 동일한 기사를 게시하는 경우에는 또한 웹 사이트의 나머지 부분에서 많은 종류의 추가 가치가 있으며 해당 특정 페이지에 대한 정보가 될 수 있으며 누군가가 해당 기사를 방문할 때 웹 사이트의 나머지 부분이 가져오는 일종의 추가 가치일 수 있습니다. 그렇지 않으면 그것도 매우 좋았기 때문에 웹사이트에서 다른 것들을 보십시오. 따라서 이는 항상 발생할 수 있는 일이며 콘텐츠를 신디케이션하는 경우 다른 웹사이트에 신디케이션한 콘텐츠가 항상 완전히 피할 수 있는 것은 아니지만 콘텐츠보다 순위가 높은 경우가 발생할 수 있다는 점을 고려해야 합니다. . 그래서 그것들은 당신이 거기에서 보아야 하는 일종의 절충점입니다. 제 생각에 표준은 이 두 페이지가 함께 속해 있음을 알려주는 좋은 방법이지만 표준이 다음과 같은 어떤 경우에도 실제로 정확하지 않은 경우이기도 합니다. 페이지 자체가 완전히 다를 수 있기 때문입니다. 이 두 페이지에서 동일한 텍스트 블록이 있을 수 있지만 해당 페이지 주변에 사용자 의견일 수 있는 완전히 다른 많은 다른 콘텐츠가 있을 수 있습니다. 웹사이트 자체. 따라서 다시 한 번 검토해야 하는 일종의 절충안입니다. 콘텐츠를 신디케이션하여 정보를 더 많은 청중에게 제공하는 것이 합리적이지만 다른 한편으로는 이러한 다른 웹사이트가 상위에 랭크될 수도 있다는 점을 고려해야 합니다. 특정 콘텐츠를 검색할 때 귀하의 웹사이트.

요약: 콘텐츠를 신디케이션하는 경우 Google은 귀하의 콘텐츠가 아닌 재게시 사이트의 콘텐츠에 대한 색인을 생성할 수 있습니다. 이러한 페이지 중 하나에 다른 콘텐츠(예: 댓글)가 많은 경우 Google은 표준을 준수하지 않을 수 있습니다.

Google은 구조화된 데이터 마크업을 항상 인식합니까?

26:58

따라서 구조화된 데이터 구성이 무엇을 의미하는지 모르겠지만 일반적으로 구조화된 데이터를 검색 결과에 리치 결과로 표시하는 것이 합리적일 때와 그렇지 않을 수 있다고 생각할 때를 파악하는 알고리즘이 있습니다. 이 웹사이트나 이 웹사이트에서 구조화된 데이터가 구현되는 방식에 대해 100% 확신하지 못한다고 느낄 때 또는 우리는 조금 더 신중해질 것입니다. 따라서 유효한 구조화된 데이터 마크업을 제공한다고 해서 검색 결과에 항상 정확하게 표시된다는 보장은 없습니다.

요약: 구조화된 데이터가 리치 결과를 생성하지 않는 경우(예: 검색 결과의 별표) 제대로 구현되지 않았을 수 있습니다. 그러나 Google의 알고리즘이 이를 표시하지 않기로 결정했기 때문일 수도 있습니다.

Google은 구조화된 데이터 마크업을 항상 인식합니까?

53:46

나는 그것이 항상 약간 까다롭다고 생각합니다. 거기에는 일반적으로 거기에 관련된 두 가지 측면이 있습니다. 하나는 특히 웹 사이트 이름이나 회사 이름이 일반 쿼리와 유사한 최신 웹 사이트에서 더 문제입니다. 예를 들어 웹사이트의 이름이 "피츠버그 최고의 변호사" 또는 이와 유사한 것입니다. 그런 다음 한편으로는 그것이 회사 이름일 수 있고 다른 한편으로 누군가 검색에 그것을 입력한다면 우리는 아마도 그들이 그 특정 회사를 찾는 것이 아니라 그 쿼리에 대한 정보를 찾고 있다고 가정할 것입니다 . 특히 우리가 가끔 보게 되는 새로운 회사의 경우 그렇습니다. 포럼이나 그곳의 사람들이 "나는 내 도메인 이름으로 순위를 매기는 것이 아니라 그들의 도메인 이름이 I don't know best VPN provider.com과 같은 것입니다. 글쎄요, 도메인 이름이지만 그렇지 않습니다."라고 말하는 것을 봅니다. 해당 쿼리에 대해 순위를 매길 것이라는 의미는 아닙니다. 그래서 그것은 이미 존재하는 조금 더 확고한 사이트에 관해서는 일반적으로 우리가 그 웹사이트를 더 이상 실제로 신뢰하지 않는다는 신호에 가깝습니다. 그래서 우리는 실제로 사람들이 이 회사를 검색하고 있다는 것을 인식할 수 있지만 회사 웹사이트 자체가 여기에서 가장 관련성이 높은 결과가 아닐 수도 있다고 생각합니다. 어쩌면 사용자보다 더 중요한 해당 회사에 대한 일종의 보조 정보가 있다고 느낄 수도 있습니다. 이러한 일이 발생할 수 있는 곳을 먼저 확인하십시오. 일반적으로 검색 결과의 처음 한두 페이지를 뒤섞는 것과 같은 문제입니다. 검색 결과의 처음 몇 페이지에 웹사이트가 표시되지 않는 결과를 초래하는 경우는 정말 드뭅니다. 나는 그것이 당신이 당신의 질문과 함께 거기에 강조한 것이 있다고 생각합니다. 그것이 내가 잘 생각하는 것입니다. 우리가 더 이상 이 웹사이트를 신뢰하지 않더라도 적어도 검색 결과 어딘가에 있어야 합니다. 왜냐하면 우리가 말할 수 있다면 누군가가 명시적으로 해당 웹사이트를 찾고 있다는 사실을 사용자가 전혀 표시하지 않는 것은 실례가 됩니다. 일반적인 쿼리의 경우와 같이 완벽한 결과가 아니라고 주장할 수 있지만 사용자가 실제로 해당 웹사이트를 찾고 있다고 말할 수 있다면 최소한 사용자에게 해당 웹사이트도 볼 수 있는 기회를 주어야 합니다. 그래서 제가 이것을 조금 더 잘 잡아야 하고 우리 알고리즘이 귀하의 웹사이트가 얼마나 신뢰할 수 있는지 제대로 이해하고 있는지 잘 모르겠습니다. 제가 웹사이트를 잘 몰라서 판단하기 어려운 부분이지만, 전혀 신뢰할 수 없다고 생각하더라도 첫 페이지의 검색 결과 어딘가에 표시해야 할 것 같습니다. 아직 하지 않았다면 살펴봐야 할 또 다른 사항은 우리가 가지고 있는 품질 평가자 지침을 살펴보는 것입니다. 거기에는 일종의 신뢰성에 대한 정보가 많이 있습니다. 그 중 일부는 약간의 가치가 있습니다. 그런 종류의 일대일을 가져와 순위 요소로 사용하는 것은 아니지만 특히 주제에 대해 이야기할 때 많은 아이디어가 있습니다. 일종의 법적 웹사이트나 의료 웹사이트인 경우 사용자에게 이 정보를 제공하는 이유를 사용자가 신뢰해야 하는 이유를 보여주는 것이 합리적입니다.

요약: 브랜드 이름과 URL에 키워드가 있는 새 브랜드가 있다고 해서 해당 키워드에 대해 자동으로 순위가 매겨져야 한다는 의미는 아닙니다. 그러나 Google 알고리즘이 사이트를 신뢰하지 않으면 순위가 좋지 않습니다. John은 더 많은 정보를 위해 품질 평가자의 지침을 알려줍니다. 참고 사항: 최근 알고리즘 업데이트가 신뢰와 어떻게 연결되어 있다고 생각하는지에 대한 좋은 정보도 있습니다.

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

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

전체 비디오 및 대본

요한복음 0:33의 참고 사항 - 질문으로 넘어가기 전에 한 가지만 간단히 이야기하고 싶었습니다. 보셨겠지만 검색 콘솔에 대한 블로그 게시물, 검색 콘솔에 적용될 변경 사항 중 일부입니다. 작년에 우리는 검색 콘솔에서 새로운 플랫폼으로 이동하기 시작했고 검색 콘솔 팀을 위해 이것은 그들이 꽤 오랜 시간 동안 작업해 왔던 것입니다. 늦어도 연말. 따라서 일부 변경 사항이 포함된 블로그 게시물의 목표는 가능한 한 빨리 모든 사용자에게 알리는 것입니다. 상황이 변경되거나 사라지면 귀하에게 영향을 줄 수 있다고 생각되는 상황이 가능한 한 빨리 알려드리고자 합니다. 내가 생각하는 변경은 특히 프로세스가 상당히 잘 작동하고 누군가가 도구를 변경하거나 도구에서 제공되는 데이터를 변경하는 경우 항상 약간의 좌절감을 주는 약간의 번거로움입니다. 따라서 이러한 변경 사항 중 일부는 피할 수 없습니다. 초기에 검색 콘솔을 시작했을 때 지금 알았더라면 지금 알고 있는 것이 우리가 발표한 정식 변경 사항과 비슷해야 한다고 생각합니다. 이번 주. 그래서 때때로 이것이 약간 실망스럽다는 것을 알고 있습니다. 그러나 우리는 우리가 앞으로 꽤 좋은 길이 있기를 바랍니다. 그리고 우리는 당신에게 정말로 일찍 알리고 당신이 일을 일찍 시도할 수 있도록 하여 상황이 변할 때 너무 놀라지 않도록 하고 싶습니다. 우리는 또한 정말 깔끔한 것들이 많이 준비되어 있으며, 새로운 플랫폼으로 이동하고 이전 기능 중 일부를 제거함으로써 팀은 실제로 앞으로 나아가고 새롭고 멋진 것들을 만드는 데 훨씬 더 많은 시간을 할애할 수 있습니다. 사라지거나 누락되었거나 새 도구에서 보고 싶은 특정 사항에 대해 강하게 느끼면 거기에서 할 수 있습니다. 검색 콘솔에서 피드백 기능을 사용하고 그냥 가지 말고 거기에서 내가 정말로 이것을 원하지만 이 새로운 기능을 사용하거나 이전 기능과 동일한 기능을 사용함으로써 달성하고자 하는 것과 같은 것에서 보고 싶은 것에 대한 정보를 알려주십시오. 새로운 정보에서 조금 더 많은 정보를 제공하면 우선 순위를 지정하는 방법을 파악하는 데 도움이 되기 때문에 조기에 생각했어야 하는 것을 놓쳤을 수 있습니다. 이 정보를 제공하거나 이전 도구에서 제공했던 작업을 수행하는 데 도움이 되는 더 나은 방법을 제공할 수 있습니까? 따라서 피드백 도구로 이동하여 정보를 보내주십시오. 다르게 보고 싶은 사항에 대한 피드백을 보내주십시오. 이 중 일부는 우리가 할 수 있습니다. 그 중 일부는 정말 필요하기 때문에 시간이 조금 더 걸릴 수 있습니다. 먼저 우리가 수년 동안 수집한 오래된 것들을 모두 정리하고 모든 것을 새 플랫폼으로 옮기는 것입니다. 그래서 그 중 일부에 대해서는 약간의 인내심을 좋아하지만 정말로 강하게 느끼는 것이 있으면 음성으로 알려주는 것도 괜찮습니다. 너무 부끄러워하지 마십시오.

질문 4:34 - 우리는 고객 사이트 중 하나를 찾았습니다. 그들이 웹사이트를 구축한 방식에는 단락 텍스트가 없고 모두 h1 h2 h3 h4 태그입니다. 따라서 이들은 P 태그 대신 표제 4 태그를 사용합니다. 웹사이트의 주요 콘텐츠는 웹사이트의 주요 콘텐츠에 제목 4 태그를 사용합니다. 이것이 순위에 부정적인 영향을 미칩니까?

답변 4:40 - 큰 문제가 없다고 생각합니다. 당신이 분명히 당신을 좋아한다는 것을 알게 되었기 때문에 정리하는 것이 합리적일 수 있지만 이것이 부정적인 영향이라고 말하는 것이 아니라 오히려 무엇을 의미합니까? 당신은 모든 것이 중요하다고 말함으로써 모든 것이 똑같이 중요하다고 말하고 있습니다. 따라서 모든 것이 중요하므로 특별히 중요한 것은 없습니다. 그래서 우리는 페이지 내의 컨텍스트를 이해하는 데 문제가 있습니다. 그래서 대부분 청소를 하게 됩니다. 우리는 일반 텍스트에서 어떤 부분이 정말 중요하고 어떤 부분이 어떤 종류인지 파악할 수 있으므로 이러한 페이지를 조금 더 잘 이해할 수 있습니다. 수정으로 인해 직접적인 순위 변경을 볼 수 있을지 모르겠지만 페이지의 실제 내용을 파악하기가 더 쉽습니다. 이것이 스팸이나 문제가 될 것이라고 생각하지 않습니다. 정말 중요하다고 말함으로써 우리에게 제공할 수 있는 만큼 많은 정보를 제공하지 않는 것입니다. 그리고 이것은 일종의 정상적인 콘텐츠입니다.

질문 7:03 - 검색 콘솔에 무작위로 깨진 링크가 계속 나타납니다. 링크를 리디렉션하거나 그대로 두려면 어떻게 해야 합니까?

답변 7:15 - 조언을 얻기 위해 포럼에 게시할 수 있는 임의의 깨진 링크가 무엇인지 모르지만 일반적으로 웹사이트를 가리키는 링크가 표시되지 않는 경우 전혀 작동하지 않으면 존재하지 않는 URL에 대해 404를 반환해도 됩니다. 이것이 404 상태 코드의 용도이며 우리 시스템이 잘 작동하는 것입니다. 따라서 존재하지 않는 URL이 있는 경우 404를 반환하면 완벽합니다. 반면에 다른 곳을 가리키는 웹사이트로 연결되는 링크가 있는 것을 보면 그 링크가 의미하는 바를 추측할 수 있으며 끝에 오타나 추가 점이 있을 수 있습니다. 그러면 의미가 있을 수 있습니다. 특히 사람들이 해당 링크를 통해 이동하는 것을 볼 때 리디렉션하는 것은 무언가 또는 누군가가 귀하의 웹사이트를 추천하려고 하지만 완벽하게 이해하지 못한 것처럼 보이기 때문입니다. 따라서 대신 올바른 페이지로 리디렉션하는 것이 합리적일 수 있습니다. 많은 사람들이 해당 URL로 이동하는 경우 해당 URL을 통한 트래픽을 조금 볼 수 있는 이 두 가지 상황 모두에서 사람들이 귀하의 페이지로 이동하기를 원하기 때문에 어떻게든 고무적이라고 생각합니다. 그러면 의미가 있을 수 있습니다. 이 링크가 의미하는 바가 무엇인지 확인하는 방법과 링크를 가리킬 수 있는 위치, 사람들을 리디렉션할 수 있는 위치를 파악하는 것입니다.

질문 8:56 - 파트너 사이트에서 신디케이트된 콘텐츠의 순위를 높이는 요인은 무엇입니까? 이것은 Canonical이 내 쪽의 원래 콘텐츠로 설정되어 있고 몇 달 동안 거기에 있었음에도 불구하고입니다. 그것은 사이트 또는 틈새 또는 권위의 문제입니다. 거기서 무엇을 할 수 있습니까?

답변 9:19 - 저는 이것이 항상 까다로운 상황이라고 생각합니다. 어떤 페이지가 이러한 쿼리 중 일부와 가장 관련이 있는지 파악하고 사용자에게 직접 해당 페이지를 가리키도록 노력하지만 이들이 완전히 별도의 웹 사이트이고 단지 게시하는 경우 같은 기사는 웹사이트의 나머지 부분에서 많은 종류의 추가 가치가 있으며 이는 해당 특정 페이지에 대한 정보일 수 있습니다. 누군가가 해당 기사를 방문할 때 웹사이트의 나머지 부분이 가져오는 일종의 추가 가치일 수 있습니다. 어쩌면 그들은 웹사이트에서 다른 것을 보고 다른 것을 볼 수도 있습니다. 그렇지 않으면 그것도 매우 좋았기 때문입니다. 따라서 이는 항상 발생할 수 있는 일이며 콘텐츠를 신디케이션하는 경우 다른 웹사이트에 신디케이션한 콘텐츠가 항상 완전히 피할 수 있는 것은 아니지만 콘텐츠보다 순위가 높은 경우가 발생할 수 있다는 점을 고려해야 합니다. . 그래서 그것들은 당신이 거기에서 보아야 하는 일종의 절충점입니다. 제 생각에 표준은 이 두 페이지가 함께 속해 있음을 알려주는 좋은 방법이지만 표준이 다음과 같은 어떤 경우에도 실제로 정확하지 않은 경우이기도 합니다. 페이지 자체가 완전히 다를 수 있기 때문입니다. 이 두 페이지에서 동일한 텍스트 블록이 있을 수 있지만 해당 페이지 주변에 사용자 의견일 수 있는 완전히 다른 많은 다른 콘텐츠가 있을 수 있습니다. 웹사이트 자체. 따라서 다시 한 번 검토해야 하는 일종의 절충안입니다. 콘텐츠를 신디케이션하여 정보를 더 많은 청중에게 제공하는 것이 합리적이지만 다른 한편으로는 이러한 다른 웹사이트가 상위에 랭크될 수도 있다는 점을 고려해야 합니다. 특정 콘텐츠를 검색할 때 귀하의 웹사이트.

질문 11:24 - Google은 이러한 URL에 대해 만료된 제품 페이지를 소프트 404로 보고하고 원하는 제품을 사용할 수 없다는 메시지와 함께 관련 대체 제품으로 리디렉션합니다. 리디렉션으로 인해 소프트 404 또는 리디렉션 페이지의 콘텐츠가 발생합니까?

답변 11:47- 여기에서 일어나고 있는 일은 우리 알고리즘이 이 페이지를 보고 있고 이 페이지에 이 제품을 더 이상 사용할 수 없다는 배너가 있는 것을 보고 있으며 이것이 다음 페이지에 적용된다고 가정하는 것입니다. 사용자가 종료되었습니다. 그래서 때때로 그곳에서 피할 수 없는 경우가 있습니다. 실제로 한 제품을 다른 제품으로 교체하는 경우 리디렉션하는 것이 합리적일 수 있습니다.

질문 12:32 - Google이 Hreflang 태그를 인식하는 데 얼마나 걸립니까? Google이 먼저 스위스에서 색인을 생성하고 독일 TLD에 따라 웹사이트의 CH 버전을 표시할 수 있습니까?

답변 13:02 - 따라서 우리는 실제로 스위스에서 콘텐츠를 먼저 색인화하지 않습니다. 크롤러와 시스템은 스위스보다는 미국에 더 있습니다. 따라서 다른 콘텐츠보다 스위스 콘텐츠를 우선시할 것이라고 생각하지 않지만 일반적으로 hrefLang 링크에서 발생하는 일은 일종의 다단계 프로세스입니다. 먼저 페이지의 서로 다른 버전을 크롤링하고 색인을 생성해야 합니다. 그런 다음 hreflang 마크업 내에서 지정한 것과 동일한 URL로 색인을 생성해야 하며 페이지의 다른 버전 간에 해당 hreflang 마크업을 따라갈 수 있어야 하며 그렇게 하려면 해당 확인도 다시 받아야 합니다. . 따라서 이는 일반적인 크롤링 및 인덱싱보다 시간이 조금 더 오래 걸리는 작업이므로 모두 이 hreflang 페이지 집합의 일부로 간주되는 서로 다른 페이지 간의 네트워크를 이해해야 합니다. 그래서 그것은 우리가 hreflang 버전 간의 링크를 이해할 수 있도록 개별 페이지를 크롤링하고 색인을 생성하는 것보다 2~3배 더 오래 걸리는 것이 정상일 수 있습니다. 다시 말하지만 유럽의 다른 나라들보다 스위스를 선호하는 것은 일종의 이기적인 관점에서 개인적으로 나에게 좋을 것이라고 생각하지만 일반적으로 글로벌 지역에서는 의미가 없습니다. 우리는 모든 웹사이트를 동일하게 취급하려고 노력합니다. 따라서 웹사이트에 CH 버전이 있다고 해서 자동으로 독일어 버전보다 높은 순위가 되는 것은 아닙니다. 따라서 hreflang의 다른 점은 대부분 순위를 변경하지 않고 URL만 교체한다는 것입니다.

질문 15:12 - 최근에 내 사이트의 도메인을 이 도메인에서 다른 도메인으로 변경했습니다. 301 리디렉션이 있습니다. 주소 변경이 시작되었는데 여전히 이전 URL이 표시되고 3주가 지났는데 정상인가요? 마이그레이션이 발생한 후 일주일 동안 301이 활성화되지 않는 문제가 있었지만 지금은 활성화되어 있습니다. 일부 쿼리의 경우 이전 사이트와 새 사이트가 모두 검색 결과에 표시됩니다. 여기서 달리 무엇을 할 수 있습니까?

답변 15:46 - 따라서 301 리디렉션은 실제로 주의해야 하는 것입니다. 301 리디렉션이 페이지 단위로 이루어지는 것이 중요합니다. 따라서 모든 이전 페이지는 새 웹사이트의 동일한 페이지로 리디렉션됩니다. 사이트 이동에 대한 도움말 센터의 정보에 모든 내용이 포함되어 있으므로 다시 확인하고 URL별로 단계별 및 URL을 통해 실제로 작동해야 하는 방식으로 작동하는지 확인합니다. . 명심해야 할 또 다른 사항은 URL을 개별적으로 크롤링하고 색인을 생성한다는 것입니다. 따라서 우리는 전체 웹사이트를 한 번에 크롤링한 다음 전환하지 않고 단계별로 수행하며 이러한 페이지 중 일부는 몇 시간 내에 크롤링되고 색인이 생성되며 일부는 다시 크롤링하는 데 훨씬 더 오래 걸립니다. 크롤링하고 다시 인덱싱하는 데 몇 개월이 걸릴 수 있습니다. 그래서 이것은 우리가 이 모든 페이지에 대한 리디렉션을 크롤링하고 색인을 생성하고 처리할 기회가 없었기 때문에 이전 웹사이트에서만 볼 수 있었던 일부가 여전히 있는 곳에서도 역할을 할 수 있는 것입니다. 그리고 우리가 이미 새 제품에서 본 것들도 있습니다. 특히 3-4주의 기간을 보고 있는 경우 이것이 정상적인 역할을 할 수 있으며 마지막으로 여기에 약간의 역할도 하는 것은 SEO와 웹마스터가 매우 혼란스러워하는 것입니다. 누군가가 명시적으로 이전 URL을 찾는 경우 해당 리디렉션을 처리한 후에도 이전 URL을 표시합니다. 그래서 우리 시스템이 여기에서 도움을 주려고 하는 것이 약간 혼란스럽습니다. 우리는 이 이전 URL이 존재한다는 것을 잘 알고 있고 여기에 새 콘텐츠가 있지만 그것이 당신이 찾고 있는 것일 수 있기 때문에 그것을 보여줄 것입니다. 따라서 예를 들어 사이트 이동을 수행한 후에도 이전 URL에 대한 사이트 쿼리를 수행하는 경우 해당 URL에 대한 리디렉션을 이미 처리했음에도 불구하고 사이트 쿼리와 함께 이전 웹사이트의 일부 URL을 계속 표시할 수 있습니다. . 따라서 예를 들어 사이트 이름을 변경하면 사이트 쿼리 내에서 거기에 언급된 새 사이트 이름과 함께 이전 URL을 볼 수 있으며 의도한 대로 작동하는 Google의 관점에서 도움을 드리고자 합니다. URL을 찾는 일반 사용자입니다. 방금 사이트 이동을 수행한 웹마스터에게는 약간 혼란스러운 일입니다. 그래서 그것이 우리가 변경할 것인지는 모르겠지만 일반적으로 그런 종류의 의미가 있다고 생각합니다.

질문 21:46 - Google 검색 봇은 웹사이트 개인화를 어떻게 봅니까? 웹 사이트에서 단일 회사라도 산업 위치를 기반으로 개인화할 수 있는 새로운 제품 레이어가 있으므로 콘텐츠를 실제로 조정할 수 있습니다.

답변 22:12 - 우리는 이것을 마지막으로 본 것 같지만 여기서 중요한 부분은 Googlebot이 주로 미국에서 크롤링한다는 것입니다. 따라서 다른 국가에 다른 콘텐츠를 제공하는 경우 Googlebot은 콘텐츠의 미국 버전만 볼 수 있습니다. 다른 위치에 대해 다른 버전의 콘텐츠를 인덱싱할 수 없습니다. 따라서 색인을 생성하려는 항목이 있는 경우 웹사이트의 일반적인 부분에 있는지 확인하여 Googlebot이 해당 항목을 선택할 수 있도록 하십시오. 페이지 전체에 일종의 추가 정보를 추가하기 위해 개인화를 사용할 수 있지만 인덱싱하려는 항목은 개인화와 연결되지 않은 페이지 부분에 있어야 합니다.

질문 22:59 - web.div의 매우 낮은 성능 비율이 웹사이트의 Google 순위에 얼마나 영향을 미치는지 궁금합니다.

답변 23:06 - 잘 모르겠습니다. 따라서 web.dev는 등대에 있는 다양한 테스트를 모아서 그에 대한 점수를 제공하고 이러한 점수를 개선하는 과정을 안내하는 정말 멋진 도구입니다. 따라서 속도에 관해서는 시도할 수 있는 것과 시간이 지남에 따라 웹사이트의 진행 상황을 추적하고 도구에 있는 다양한 콘텐츠를 살펴봐야 합니다. 그래서 그것은 일반적으로 거쳐야 하고 일종의 작업을 수행하는 것이 좋은 습관이라고 생각하지만 이는 따라야 하는 좋은 방법이기도 하지만 자동으로 더 높은 순위를 차지한다는 의미는 아닙니다. 마찬가지로 여기에서 점수가 낮다고 해서 웹사이트가 모범 사례를 따르지 않기 때문에 순위가 끔찍하다는 의미는 아닙니다. 따라서 웹 사이트가 너무 나빠서 제대로 색인을 생성할 수 없는 경우 URL에 액세스할 수 없거나 URL에 액세스할 수 없는 등대에서 SEO 점수가 정말 낮은 경우와 같은 경우가 있습니다. 이 페이지에는 URL이 없으며 JavaScript를 처리할 수 없는 JavaScript 셸일 뿐입니다. 내가 귀하의 SEO에 심각한 영향을 미칠 수 있지만 다른 한편으로 귀하의 사이트가 약간 느리거나 완벽하게 최적화되지 않은 문제라면 귀하의 웹사이트에 상당한 영향을 미칠지 모르겠습니다. 그래서 여기에서 제가 추천하는 방법은 web.dev와 같은 도구에서 제공되는 조언을 살펴보고 구현할 수 있는 것에 대해 생각하는 것입니다. 궁극적으로 사용자를 위해 일을 개선하는 일을 하는 경우 웹사이트의 나머지 부분에도 일종의 장기적인 낙수 효과가 있기 때문에 사용자를 위해 여기에서 요청하는 것입니다.

질문 26:58 - Google은 구조화된 데이터 조직의 정보를 표시할지 여부를 결정할 수 있습니다.

답변 27:05 - 구조화된 데이터 구성이 무엇을 의미하는지 모르겠지만 일반적으로 구조화된 데이터를 검색 결과에 리치 결과로 표시하는 것이 타당한 때와 말이 안 되거나 이 웹사이트나 이 웹사이트에서 구조화된 데이터가 구현되는 방식에 대해 100% 확신이 서지 않고 조금 더 신중해질 것입니다. 따라서 유효한 구조화된 데이터 마크업을 제공한다고 해서 검색 결과에 항상 정확하게 표시된다는 보장은 없습니다.

질문 28:31 - 웹사이트 구조 및 다국어 다중 지역 구성에 관한 질문입니다. 도메인을 폴더별로 분할하여 검색 콘솔에서 서비스를 분리할 때 URL 매개변수 구성에 대해 걱정해야 합니다.

답변 28:52 - 그래서 저는 한편으로는 이러한 종류의 문제를 조사하는 것이 좋다고 생각합니다. 다른 한편으로는 하위 디렉토리별로 웹사이트에 대해 다른 구성을 가질까봐 걱정스럽습니다. 웹사이트 전반에 걸쳐 일반적으로 URL 구성 매개변수로 정리하는 작업을 수행하지 않는 것과 같습니다. 그래서 그것은 여기에있는 것입니다. 여기 웹 사이트를 구체적으로 알지 못하므로 정말 말하기 어렵지만 다른 것을 의미하거나 무시할 수 있거나 무시해서는 안되는 매개 변수가 다른 것처럼 들립니다. 웹사이트 내의 개별 하위 디렉토리. 한편으로는 그것이 가능해야 하지만 다른 한편으로는 개별 URL 매개변수를 완전히 무시할 수 있는 상황과 이와 똑같은 매개변수가 콘텐츠에 중요한 다른 경우에 처리할 수 있어야 합니다. 알고리즘이 혼란스러워서 말할 수 있는 것과 같이 항상 이러한 매개변수를 유지해야 하거나 이러한 매개변수를 유지할 필요가 없습니다. 그런 다음 갑자기 콘텐츠의 일부가 누락되거나 콘텐츠의 일부가 여러 번 인덱싱됩니다. 따라서 URL 매개변수 도구를 사용하면 이와 같은 경우에 확실히 도움이 되지만 일반적으로 이러한 URL 매개변수를 정리하고 웹사이트 URL에 대해 일관된 구조를 갖는 방법을 찾는 것이 더 합리적일 것 같습니다. 알고리즘은 추측할 필요가 없고 알고리즘은 알아낼 필요가 없습니다. 오, 이 특정 경로에서 이 매개변수는 중요하고 이러한 다른 경로에서는 무시할 수 있습니다. 웹 사이트의 크롤링 및 인덱싱에 너무 많은 복잡성을 추가할 때마다 상황이 잘못될 수 있는 상황에 직면하게 됩니다. 따라서 더 쉽게 유지할 수 있을수록 더 깨끗하게 유지할 수 있습니다. 더 간단하고 URL 구조 내에서 유지할 수 있으므로 항상 두 번 생각할 필요 없이 해당 사이트를 크롤링하고 색인을 생성할 수 있습니다. URL 구성 도구가 없는 다른 검색 엔진이 있습니다. 그들이 그것을 볼 수 없도록 우리가 가지고 있는 데이터는 당신이 다른 검색 엔진에 문제를 일으키거나 아마도 당신의 콘텐츠가 소셜 미디어에서 공유되는 방식에 역할을 할 수도 있습니다. 그래서 이 모든 것들이 여기에서 작용합니다. 여기에서 나의 일반적인 권장 사항은 이러한 모든 하위 디렉토리에 대한 URL 매개변수 처리 도구를 미세 조정하는 데 너무 많은 시간을 소비하지 말고 오히려 그 시간을 들여서 URL로 갖고 싶은 것에 대해 생각하는 데 투자하는 것입니다. 장기적으로 구조를 파악하고 더 깨끗한 URL 구조에 도달하는 데 필요한 단계에 대해 생각합니다.

질문 32:17 - 표준으로 선택되지 않은 중복 제출 URL로 색인이 되는 콘텐츠와 관련하여 게시한 문제에 대한 통찰력을 얻고 싶습니다.

답변 33:04 - 일반적으로 여기에서 일어나는 일은 우리 알고리즘이 이 페이지가 동등하고 함께 접을 수 있다고 믿는 이유가 무엇이든 간에 이 페이지 중 하나에서 표준을 선택하면 다음과 같이 보입니다. 브라우저에서 수동으로 페이지를 보는 것과 같이 실제로는 상당히 다른 페이지이므로 함께 접는 것은 의미가 없으므로 이 자산에서 표준을 선택하는 것도 의미가 없습니다. 과거에 이와 같은 결과를 초래한 것 중 하나는 콘텐츠를 제대로 렌더링할 수 없는 경우입니다. 실제로 콘텐츠에 제대로 액세스할 수 없을 때 기본적으로 빈 페이지가 보일 때 "오, 이것은 우리가 본 다른 빈 페이지와 동일하며 아마도 함께 접을 수 있습니다."라고 말합니다. 따라서 Google에서는 이러한 페이지가 동등하다고 생각하는 방향으로 이동하여 실제 콘텐츠가 없는 것처럼 모바일 친화적 테스트에서 가능할 수 있다고 생각합니다. Googlebot 사고에 전면 광고를 표시하고 있는데 해당 전면 광고만 색인을 생성하고 있는 것일 수 있습니다. 여기서 어떻게 될까요? 아직 여기에서 자세히 살펴볼 기회가 없었기 때문에 이와 같은 일이 귀하 측에서 일어나고 있을 수도 있고 저희 측에서 이상한 일이 일어나고 있을 수 있으며 우리는 그것을 고칠 필요가 있지만 친절합니다. 이런 경우에 내가 취할 방향.

질문 34:41 - 내 웹사이트에서 고객을 좀 더 잘 탐색하고 싶습니다. 이것이 Google을 혼동하지 않도록 하고 싶습니다. 내 URL 구조를 도메인, 카테고리, 제품 경로로 설정하고 싶습니다. 또는 다르게 설정하려면 어떻게 해야 하며, 어떤 URL 구조를 선택해야 하나요?

답변 35:13 - 우리의 관점에서 모든 URL 구조를 사용할 수 있습니다. 따라서 완벽하게 괜찮은 일종의 경로 하위 도메인 하위 디렉토리 구조를 사용하는 경우 무한 공간에 빠지지 않는 것이 중요합니다. So if you use URL rewriting on your server that it's not the case that you can just add like the last item in your URL and just continue adding that multiple times and just it always shows the same content but it should be a clean URL structure where we can crawl from one URL to the other without getting lost in infinite spaces along the way. You can use your URL parameters if you want but if you do decide to use your URL parameters like I mentioned in one of the previous questions try to keep it within a reasonable bound. So that we don't again run off into infinite spaces where lots of URLs lead to the same content but whether or not you put the product first or the category first or you use an ID for the category or write out the category as text that's totally up to you. That doesn't have to be a line between your ecommerce site on your blog that can be completely different on both of these. So I think it's good to look at this but on the other hand I lose too much sleep over this and rather define the URL structure that works for you in the long run in particular one that you don't think you need to change in the future. So try not to get too narrow down and pick something that works for you, works for your website.

Question 37:43 - We're developing an application for angular Universal with some sections we want to change the appearance of the URLs in the browser but keep it the same on the server side. So for the server it would be luxury goods leather bags but the user would see just leather bags. Is there any problem with this in angular Universal using dynamic rendering?

Answer 38:08- So just from from a practical point of view Googlebot doesn't care what you do on the server you can track that however you want on your server. The important part for us is that we have separate URLs for separate pages that we have links that Googlebot can click on that are in kind of a elements with an href pointing to a URL that we can follow and that we can access these URLs without any history is with them. So if we take one URL from your website we can copy and paste it into an incognito browser and it should be able to load that content and if it loads that content if you have proper links between those pages then from our point of view how you handle that on your server is totally up to you. Using angular Universal with dynamic rendering or if you have something of your own that you set up that's all totally up to you that's not something that we would care about. It's not something we would even see because we see the HTML that you serve us and the URLs that you serve us.

Question 39:18 - My website fetches individual web pages which are not interlinked through an API but no links are displayed through clicks. It has a search box where every individual page shows search results is Google is successfully crawling all links as valid via sitemap does Google see this is a valid practice because links and millions will harm rankings or increase ranking.

Question 39:48 - So there are lots of aspects in this question where I say this sounds kind of iffy there is some things that sound kind of ok. So if Google is already indexing these pages then something is working out right. In general I I'd be careful to avoid setting up a situation where normal website navigation doesn't work. So we should be able to crawl from one URL to any other URL on your website just by following the links on the page. If that's not possible then we lose a lot of context. So if we're only seeing these URLs through your sitemap file then we don't really know how these URLs are related to each other and it makes it really hard for us to be able to understand how relevant is this piece of content in the context of your website, in the context of the whole web. So that's that's one thing to kind of watch out for and the other thing to watch out for. The other thing too watch out for I think is if you're talking about millions of pages that you're generating through an API with a search box and just so many of those via sitemap files. I may be kind of cautious there with regards to the quality of the content that you're providing there. So in particular if you have like product feeds if you're using RSS feeds to generate these pages, if you're doing anything to automatically pull content from other websites or from other sources and just kind of republishing that on your site then that's something where I could imagine our quality algorithms maybe not being so happy with that. Similarly if this is all really completely republished from other web sites I could imagine the web spam team taking a look at that as well and saying well why should we even index any of this content because we already have all of the content indexed from from the original sources. Like what is the value that your website is providing that the rest of the web is not providing. So that's one thing to kind of watch out for. I don't want to kind of suggest that your website is spammy I haven't seen your website but it is something that we do see a lot and it's something where as a developer you go, oh I have all of these sources and I can create code therefore I can combine all of these sources and create HTML pages and now have a really large website without doing a lot of work, and that's really tempting and lots of people do that, lots of people also buy frameworks that do this for you but it doesn't mean that you're creating a good website. It doesn't mean that you're creating something that Google will look at and say oh this is just what we've been waiting for we will index it and ranked it number one for all of these queries. So it might mean that it looks like very little work in the beginning because you could just combine all of these things but in the end you spend all this time working on your website when actually you're not providing anything of value then you end up starting over again and trying to create something new again. So it looks tempting to save a lot of work in the beginning but in the long run you basically lose that time. So it might make more sense to figure out how can you provide significant value of your own on your website in a way that isn't available from other sites.

Question 43:34 - We're facing an issue where lots of resources couldn't load through the to the same page not getting rendered in the snapshot for Googlebot while debugging these issues we couldn't find a solution and Google is marking them as other error. What could that be?

Answer 43:51 - So this is also a fairly common question what is essentially happening here is we're making a trade-off between a testing tool and the actual indexing and within the testing tool we try to get information as quickly as possible directly from your server but at the same time we also want to give you an answer fairly reasonably quickly so that you can see what is happening. What what tends to happen here is if you have a lot of resources on your pages that need to be loaded in order for your page to load then it could happen that our systems essentially timeout and we try to fetch all of these embedded resources but we don't have enough time because we want to provide an answer to you as quickly as possible. So you end up seeing these embedded resources not being pulled and you see an error in the live rendering of the page like that. When it comes to indexing our systems are quite a bit more complex though we cache a lot of these resources. So if we try to index an HTML page we'll know all of these CSS files we've seen before we can just pull them out of our cache we don't have to fetch them again we can render those pages normally and that just works. One thing you can do or maybe they're two you can do to to kind of help improve that for the testing tool and for users in general. On the one hand you can reduce the number of embedded resources that are required on your pages. So instead of having a hundred CSS files you've you kind of throw them into the tool you create one CSS file out of that that's one thing that you can do that makes sense for both users and for search engines. You can do that for JavaScript as well you can minify the JavaScript you can combine things and kind of make packages rather than individual files I think that's a good approach. The other thing is if you're seeing this happening for your pages and you don't have a lot of embedded content then that's kind of a hint that your server is a bit slow and that we can't kind of fetch enough content from your server to actually make this work. So that might be a chance to look at your server your network connectivity and to think about what you can do to make that a little bit faster so that these tools don't time out so that it's also faster for users as well. So in both of these cases the net effect is that users will mostly be seeing the speed improvement but the side effect will also be that you'll be able to use these tools a little bit better because they tend not to time out as much.

So what what I would do there is try to use some other tools to figure out is this really a problem on your side somehow that things are a little bit slow or is this something just on Google side that we we tend not to have as much time to fetch all of these individual resources so what you could do is use the the chrome developer tools what is it the network tab that you have there and to figure out like how many of these resources are being loaded how long does it take you can use webpagetest.org it also creates a kind of a waterfall diagram for your content also listing the the time that it takes for those test URLs and the size of the resources that were to return and by using those two you can kind of figure out is is it the case that it just takes 20 seconds to load my page with all of the embedded content with all of the high resolution images or is it the case that these testing tools say my page loads in 3 or 4 seconds with all of the embedded content therefore it's probably more an issue on Google side I don't have to worry about it.

Question 53:46 - I've noticed as a result of the last several updates that have been coined the the medic update. I've seen some websites that no longer show on the first page of search results for their own company, for their own brand, and I was wondering why in general what would that be?

Answer 54:35 - I think that's that's always a bit tricky there usually are two aspects that are involved there. One is more an issue especially with newer websites where the website name or the company name is more like a generic query. So if for example the the website's name is “ Best Lawyers in Pittsburgh” or something like that. Then on the one hand that might be the company name, on the other hand if someone were to type that into search, we would probably assume that they're not looking for that specific company but rather they're looking for information for that query. So that's especially with newer companies that's something that we see every now and then. We see that the forums or people there saying, oh I'm not ranking for my domain name, and then their domain name is something like I don't know best VPN providers.com it's like well, it's a domain name but it doesn't mean that you will rank for for that query. So that's one thing when it comes to sites that are a little bit more established that are out there already usually it's more a sign that we just don't really trust that website as much anymore. So that's something where we might recognize that actually people are searching for this company but we feel maybe the company website itself is not the most relevant result here, maybe we feel that there is kind of auxiliary information about that company which is more important that users see first where which could result in something like this happening. Usually that that's more a matter of things kind of shuffling around on the first one or two pages in the search results. It would be really rare that that's something like that would result in a website not showing up at all the first couple pages of the search results. I think that's that's kind of what you highlighted there with your question and that's something where I think well, even if we didn't trust this website as much anymore then we should at least have it somewhere in the search results because if we can tell that someone is explicitly looking for that website it would be a disservice for the user to not show it at all. Like for maybe for generic queries one could argue maybe it's not the perfect result but if we can tell that they're really looking for that website at least we should give the user a chance to see that website as well. So that's kind of why I took that and said well maybe we should be catching this a little bit better and II don't know if our algorithms are correctly kind of understanding how trustworthy your website there would be. I don't know the website so that's really hard for me to judge but even if we think that it wasn't trustworthy at all maybe we should still show it somewhere in the search results on the first page. The other thing to maybe look at if you haven't done so already is look at look at the quality rater guidelines that we have and there's a lot of information about kind of trustworthiness in there. Some of that is worth taking with a grain of salt it's not that we take that kind of one-to-one and use that as a ranking factor but there there are a lot of ideas in there especially when you're talking about a topic that's a kind of legal website or medical website then it does make sense to show users like why are you providing this information why should they trust you.