SEO 업무 시간, 2022년 5월 6일

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

웹 사이트에서 웹 구성 요소를 사용할 수 있습니까?

3:08 “SEO에 웹 컴포넌트를 사용하는 데 문제가 있습니까?”

John은 "[...] SEO에 관해서는 [...] 웹 구성 요소는 다양한 형태의 JavaScript를 사용하여 구현되며 Google 검색과 관련하여 거의 대부분의 JavaScript를 처리할 수 있습니다. 그리고 맹목적으로 모든 것이 지원될 것이라고 말하고 싶지만 이것을 테스트할 수 있고 이것을 테스트해야 합니다.

이를 테스트하는 가장 좋은 방법은 Search Console에 있습니다. URL 검사 도구 가 있습니다. 거기에 URL을 삽입하면 Google이 해당 페이지에 대해 렌더링할 HTML을 볼 수 있습니다. 우선 스크린샷에서 볼 수 있으며 렌더링된 HTML에서도 볼 수 있습니다. 그리고 Google이 웹 구성 요소에서 가져올 수 있는 항목을 다시 확인할 수 있습니다.

중요한 정보가 있다고 생각하면 모든 준비가 완료된 것입니다. 중요한 정보 중 일부가 누락되었다고 생각되면 드릴다운하여 무엇이 문제인지 알아낼 수 있습니까? 그리고 요즘 자바스크립트 웹사이트와 웹 검색에 대한 문서가 많기 때문에 다시 한 번 확인합니다. […]”

페이지의 여러 섹션에서 FAQ 스키마를 사용해도 되나요?

5:18 "FAQ 스키마를 사용하여 기존 FAQ 목록 형식이 아닌 블로그 게시물의 다른 섹션에 나타나는 질문과 답변을 표시해도 괜찮습니까?"

John은 다음과 같이 대답했습니다. “ 공식 문서 [...]를 다시 확인했는데 문제가 없는 것 같습니다.

일반적으로 FAQ 스니펫 및 구조화된 데이터와 관련하여 중요한 부분 은 콘텐츠가 페이지에 표시되어야 한다는 것입니다. 따라서 누군가가 해당 페이지를 방문할 때 질문과 답변이 모두 표시되어야 하며 페이지의 한 섹션에 숨겨져 있는 것이 아닙니다. 그러나 질문과 답변이 페이지에서 볼 수 있다면 페이지의 다른 위치에 있더라도 완벽합니다.

기억해야 할 또 다른 사항은 모든 구조화된 데이터와 마찬가지로 FAQ 스니펫이 검색 결과에 표시된다는 보장이 없다는 것입니다. 기본적으로 이러한 FAQ 스니펫을 표시할 수 있는 페이지를 만들지만 표시된다는 보장은 없습니다.

따라서 테스트 도구를 사용하여 모든 것이 제대로 구현되었는지 확인할 수 있습니다. 테스트 도구가 괜찮다고 한다면 아마도 올바른 길을 가고 있는 것입니다. 그러나 검색 결과에 표시되는 내용을 보기 위해 Google이 페이지를 해석하고 처리하는 방법을 계속 기다려야 할 것입니다.

구조화된 데이터의 경우 FAQ의 경우라고 생각합니다. 하지만 적어도 다른 유형의 경우 검색 콘솔에 특정 보고서가 있어서 발견된 구조화된 데이터와 에 표시된 구조화된 데이터에 대한 정보를 제공합니다. 대략적으로 측정할 수 있도록 검색 결과가 원하는 대로 작동하고 있습니까, 아니면 원하는 대로 작동하지 않습니까?

그리고 이와 같은 경우 웹사이트에서 테스트 페이지를 만들고 검색 결과에서 결과가 어떻게 나오는지 확인하고 원하는 작업인지 다시 한 번 확인한 다음 전체에 구현하는 것이 좋습니다. 웹사이트의 나머지 부분."

FAQ 스키마에 대한 추가 질문이 있는 경우 FAQ 리치 스니펫 (리치 결과라고도 함) 에 대해 자주 묻는 질문이 포함된 블로그 기사를 읽어보세요 .

콘텐츠를 표절하는 것이 가능합니까?

7:37 "Google은 게시자가 자신의 콘텐츠를 표절하는 것을 허용합니까?"

John에 따르면 “[...] 자신의 콘텐츠를 재사용하는 것은 표절이 아닌 것 같습니다. […]

Google의 관점 에서 자신의 웹사이트에서 콘텐츠를 가져와서 페이지의 일부 요소를 변경하여 다시 게시하는 것은 본질적으로 귀하에게 달려 있습니다. 그리고 그것은 [...] 기존 기사를 복사하고 기사의 일부 단어를 변경하는 것만으로는 많은 가치를 제공하지 못하는 것입니다.

따라서 [...] 전략적 관점에서, 아마도 당신은 해당 주제에 대해 독특하고 설득력 있는 글을 작성하거나 이러한 다양한 변형을 다루는 하나의 기사를 작성하는 것이 더 적합할 것입니다. 하지만 [...] 정책적 관점에서 보면, 개별 기사를 가져와서 소수의 사본을 만드는 데 특별히 방해가 되는 것은 없다고 생각합니다. [...] 하지만 제 추천은 실제로 정말 좋은 기사를 더 적게 만드는 것입니다.

자신의 콘텐츠를 집중적으로 복사 하는 경우 나타날 수 있는 한 가지 극단적인 경우 는 결국 도어웨이 페이지를 만드는 것입니다. 그리고 그것은 본질적으로 하나의 콘텐츠를 취하고 그 안에 다른 단어로 많은 변형을 만드는 것입니다. 이는 웹마스터 가이드라인에 위배되는 것입니다 .

[...] 그리고 그것은 웹사이트를 위한 수많은 [...] 정크 페이지를 생성하는 곳입니다. 기본적으로 전체적으로 고유한 가치를 제공하지 않는 [...]입니다. 그리고 웹사이트의 콘텐츠를 그렇게 희석하는 대신 웹사이트 의 주요 콘텐츠를 훨씬 더 강력하게 만드는 데 집중하는 것이 좋습니다. […]”

JavaScript가 꺼진 상태에서 웹사이트가 사용자 친화적이지 않으면 어떻게 됩니까?

10:24 “자바스크립트가 꺼져 있으면 웹사이트가 사용자 친화적이지 않습니다. 대부분의 이미지가 로드되지 않습니다. 플라이아웃 메뉴를 열 수 없습니다. 그러나 모든 메뉴 링크의 Chrome 검사 기능은 소스 코드에 있습니다. JavaScript에 대한 의존도가 Googlebot에게 여전히 문제가 될까요?”

John: “내 관점에서 […] 나는 그것을 테스트할 것입니다. [...] 그리고 아마도 합리적인 방법으로 JavaScript를 사용하고 있고 페이지에서 JavaScript를 차단하기 위해 특별한 조치를 취하지 않는다면 아마도 제대로 작동할 것이라고 가정할 것입니다. 하지만 저를 그냥 믿는 것이 아니라 테스트 도구를 사용하여 사용해 보는 것이 훨씬 좋습니다. [...] 따라서 JavaScript 및 SEO에 대한 가이드를 다시 확인하고 원하는 방식으로 작동하는지 확인한 다음 웹사이트를 전반적으로 개선하기 위해 시도해 볼 수 있는지 생각합니다.

JavaScript와 관련하여 사용자 친화적이라고 언급하셨습니다. 따라서 Google의 관점에서 볼 때 Googlebot이 기술적인 관점에서 콘텐츠를 볼 수 있고 페이지의 링크를 기술적 관점. 기본적으로 사용자 친화성에는 관심이 없습니다 .

그러나 물론 사용자는 사용자 친화성을 중요하게 생각합니다. 사용자가 페이지에서 좋은 경험을 할 수 있도록 조금 더 노력하는 것이 합리적일 수 있습니다.

그리고 이것은 단순한 테스트 도구의 문제가 아니라 소규모 사용자 연구를 수행하거나 일부 사용자를 인터뷰하거나 최소한 웹사이트에서 설문조사를 수행하여 어디에서 수행하는지 이해해야 하는 경우 가 많습니다. 그들은 붙어? 그들은 어떤 문제에 직면해 있습니까? [...] 텍스트가 너무 작거나 버튼을 제대로 클릭할 수 없는 것일 수 있습니다. 이는 기술적인 문제와 일치하지 않지만 사용자 측의 문제일 수 있습니다.

[...] 이러한 기능을 개선하고 사용자를 더 행복하게 만들 수 있다면 사용자는 계속 머물다가 다시 돌아올 것이며 더 많은 사람들이 귀하의 웹사이트를 방문하도록 초대할 것입니다.”

블로그에서 JavaScript SEO에 대한 자세한 내용을 보려면 여기 를 클릭 하십시오.

인덱싱 문제는 사용되는 웹사이트 기술 유형에 따라 달라지나요?

13:08 “ 정적 페이지는 HTML로, 블로그는 워드프레스로 만들었습니다. 우리 블로그 게시물의 대부분은 Google에서 색인 생성 문제를 겪고 있습니다. 이 문제를 해결하려면 어떻게 해야 합니까?”

John: “우선, 이것이 서로 다른 플랫폼이라는 것을 아는 것이 중요합니다. 그리고 본질적 으로 이러한 모든 플랫폼을 사용하여 HTML 페이지를 만들고 있습니다. 그리고 이러한 HTML 페이지를 생성하는 웹사이트의 배경 또는 백엔드 측면은 Googlebot이 보지 않는 것입니다. 또는 적어도 Googlebot이 평가하려고 하지 않는 것입니다.

따라서 페이지가 HTML로 작성되고 편집기로 작성되고 서버에 로드되고 그렇게 작동하면 HTML 페이지임을 알 수 있습니다. WordPress 또는 사용 중인 다른 플랫폼의 데이터베이스를 기반으로 서버에서 즉석에서 생성된 다음 HTML 페이지를 생성하는 경우 최종 HTML 페이지를 보고 기본적으로 해당 페이지로 작업합니다.

따라서 크롤링, 색인 생성 또는 순위 지정과 같은 문제와 관련하여 웹사이트 전반에 걸쳐 문제가 발생하고 Googlebot이 콘텐츠를 볼 수 있는 기술적인 요소를 제외할 수 있는 경우 일반적으로 남은 것은 물건의 품질 측면.

이는 이러한 페이지를 만드는 데 사용하는 인프라에 의존하지 않고 웹 사이트에서 제공하는 콘텐츠 와 웹 사이트에서 제공하는 전반적인 경험에 관한 것입니다. 따라서 예를 들어 블로그 게시물이 Google에서 선택되지 않거나 Google에서 순위가 ​​좋지 않고 정적 HTML 페이지가 Google에서 제대로 작동 하는 것을 보고 있다면 정적 HTML 페이지가 아니기 때문입니다. 그들이 Google에서 잘하고 있다는 것이 아니라 Google이 다른 사용자에게 추천해야 할 좋은 콘텐츠라고 생각하기 때문입니다.

그리고 그 수준에서 내가 살펴보고 인프라에 집중하지 않고 제공하는 실제 콘텐츠에 집중할 것입니다.

콘텐츠와 관련하여 페이지의 주요 부분과 같은 것은 텍스트만이 아닙니다. 그것은 작동하는 전체 웹사이트 주변의 모든 것과 같습니다. 그래서 저는 한 발 물러서서 더 큰 그림을 보려고 노력할 것입니다. 그리고 품질 문제가 있을 수 있는 부분이나 개선할 수 있는 부분을 더 큰 그림의 관점에서 볼 수 없다면 사용자 연구를 수행하는 것이 좋습니다.

이를 위해 웹사이트와 직접 관련이 없는 소수의 사람들을 초대하여 웹사이트에서 몇 가지 작업을 수행하도록 할 수 있습니다. 그런 다음 이 웹사이트에 문제가 있다고 생각하는 부분이나 이 웹사이트를 신뢰할 수 있는지 또는 웹사이트 품질을 이해하는 것과 관련된 기타 질문에 대해 어려운 질문을 하십시오. 그리고 영감을 얻기 위해 사용할 수 있는 일부 블로그 게시물에 이러한 질문이 많이 있습니다 . [...] 그들의 답변을 마음에 새기고 웹사이트를 전반적으로 개선할 수 있는 방법에 대해 생각해 보십시오.”

Google이 표준 태그를 준수하지 않는 이유는 무엇입니까?

17:12 “5 페이지에 표준 URL을 설정했지만 Google에서는 세 번째 페이지에도 표준 URL을 표시하고 있습니다. 표준을 설정한 URL만 표시되지 않는 이유는 무엇입니까?”

John은 "[...] 바꾸어 말하면 웹사이트의 5페이지에서 rel="canonical"을 설정한 것처럼 들립니다. 웹사이트에 rel="canonical"을 설정하지 않은 다른 페이지가 있습니다. 그리고 Google은 본질적으로 다양한 방식으로 색인이 생성된 이 모든 페이지를 보여주고 있습니다.

염두에 두어야 할 사항은 rel="canonical"이 중복 페이지 집합 내에서 이와 같이 색인을 생성하려는 페이지를 지정하는 방법이라는 것입니다 . 또는 본질적으로 사용하려는 주소입니다. 따라서 특히 파일 이름이 대문자인 페이지와 파일 이름이 소문자인 페이지가 각각 있는 경우 경우에 따라 서버에 동일한 내용이 표시될 수 있습니다. 기술적으로 서로 다른 주소입니다. [...] 그러나 실용적인 관점에서 서버는 동일한 것을 보여주고 있습니다.

그리고 구글은 그것을 볼 때 같은 내용을 가진 두 개의 주소를 인덱싱하는 것은 가치가 없다고 말합니다. 대신 이러한 주소 중 하나를 선택하여 해당 콘텐츠의 색인을 생성하는 데 사용할 것입니다. 그리고 rel="canonical"을 사용하면 Google에 신호를 보내고 Google에 이 콘텐츠를 색인화할 때 소문자 버전의 주소를 사용하라고 말합니다. 대문자 버전을 보셨을 수도 있지만 소문자 버전을 사용했으면 합니다. 그리고 이것이 본질적으로 rel="canonical"이 하는 일입니다.

귀하가 거기에서 지정한 버전을 사용한다는 보장은 없지만 우리를 위한 신호입니다. 다른 모든 항목이 동일한지 파악하는 데 도움이 됩니다. 이 주소를 정말 선호하므로 해당 주소를 사용하려고 합니다. […]

그리고 귀하의 웹사이트에 동일한 콘텐츠의 복사본이 여러 개 있다는 것을 인지했을 때 작동합니다. 그리고 다른 모든 것에 대해서는 우리가 할 수 있는 한 최선을 다해 색인을 생성하려고 노력할 것입니다. 이는 또한 rel="canonical"이 있는 페이지의 경우 때때로 귀하가 제공하는 조언을 따를 것임을 의미합니다. 때때로 우리 시스템은 "당신이 잘못 알고 있는 것 같습니다."라고 말할 수 있습니다. 다른 주소를 표준 주소로 사용해야 합니다. 그런 일이 일어날 수 있습니다. 순위가 다르게 지정되거나 검색에서 더 나빠질 것이라는 의미는 아닙니다. 단지, Google 시스템이 다른 시스템을 선택하고 있을 뿐입니다.

웹사이트의 다른 페이지에는 rel=”canonical”이 전혀 설정되어 있지 않을 수 있습니다. 그리고 그들을 위해 우리는 스스로 하나를 선택하려고 노력할 것입니다. 그것도 완벽하게 괜찮습니다. 그리고 이 모든 경우에 순위는 괜찮을 것입니다. 인덱싱이 잘 됩니다. 검색 결과에 표시되는 주소가 다를 뿐입니다.

따라서 일부 페이지에는 표준 세트가 있지만 다른 페이지에는 없는 경우에도 해당 페이지를 색인화 하고 검색에 표시할 때 해당 페이지에 사용할 올바른 주소를 찾습니다. 따라서 다른 주소가 표시될 수 있는 이 모호한 가능성을 제어하려고 하기 때문에 페이지에 rel="canonical"을 사용하는 것이 좋습니다. 그러나 rel="canonical"이 반드시 있어야 하는 것은 아닙니다.

스팸성 백링크를 제거하는 방법은 무엇입니까?

20:56 " 악의적인 도메인에 백링크로 계속 배치되는 수천 개의 스팸 링크가 있는 경우 어떻게 해야 합니까? 스팸성 키워드가 포함되어 있으며 도메인에서 404가 발생합니다. 우리는 이러한 스팸 링크와 2021년 스팸 업데이트 이후에 받은 패널티 사이에 강한 상관 관계가 있음을 확인했습니다. 우리는 모든 스팸 링크를 거부하고 스팸 링크의 소스로 나열된 도메인을 보고했습니다. 우리가 무엇을 더 할 수 있습니까?”

John은 다음과 같이 대답했습니다. “[...] 이 특별한 경우에 언급해야 할 중요한 두 가지가 있습니다. 한편으로 이러한 링크가 404를 반환하는 웹사이트의 페이지를 가리키고 있어 본질적으로 존재하지 않는 페이지로 연결되는 경우 연결할 항목 이 없기 때문에 해당 링크를 고려하지 않습니다. 와 함께 귀하의 웹사이트에. 기본적으로 사람들은 누락된 위치에 연결하고 있습니다. 그런 다음 이 링크로 무엇을 할 수 있습니까? 아무것도 연결할 수 없으므로 많은 항목이 이미 삭제된 것처럼 [...] 삭제합니다.

두 번째 부분은 스팸성 백링크를 거부했다고 언급했습니다. 그리고 특히 이것이 소수의 도메인과 같다고 언급하면 ​​백링크 거부 도구의 도메인 항목으로 그렇게 할 수 있습니다. 그리고 그것은 본질적으로 그것들을 우리 시스템에서도 빼냅니다. 따라서 Search Console에 계속 나열되며 여전히 검색 콘솔에서 찾을 수 있으며 이에 대해 약간 혼란스러울 수 있습니다. 그러나 본질적으로 그들은 전혀 영향을 미치지 않습니다. 그들이 거부되는 경우 우리는 시스템에 이러한 사항을 긍정적으로든 부정적으로든 고려하지 말라고 말합니다. 따라서 실용적인 관점에서 404 측면과 거부 측면 모두에서 해당 링크는 귀하의 웹사이트에 부정적인 영향을 미치지 않을 것입니다.

검색에서 웹사이트와 관련하여 중요한 변경 사항이 있는 경우 해당 링크에 초점을 맞추지 않고 더 자세히 살펴보겠습니다. 그리고 그것은 당신이 거기에서 제공하는 가치가 무엇인지 조금 더 잘 이해하기 위해 당신의 웹사이트 내에서 할 수 있습니다. 사용자에게 제공하는 놀라운 가치와 관련하여 다른 모든 웹사이트보다 우위에 있기 위해 무엇을 할 수 있습니까? 검색 엔진에 가능한 한 명확하게 하려면 어떻게 해야 합니까? [...] 당신은 그들이 오고 있는 전체 도메인을 거부하고 다음으로 넘어갈 수 있습니다. 거기에서 해야 할 일은 전혀 없습니다. 특히 404페이지에 이미 링크되어 있는 경우 이미 무시됩니다.”

앱 인덱싱 없이 앱을 어떻게 인덱싱합니까?

26:51 " [...] 앱 인덱싱이 더 이상 작동하지 않는 경우 Google에서 앱 순위를 지정하는 방법은 무엇입니까?"

John은 "[...] 모든 앱과 관련하여 할 수 있는 한 가지, [...] 홈 페이지를 만들 수 있습니다. 그리고 그것은 다른 것과 마찬가지로 검색에 표시될 수 있는 것입니다. 그리고 많은 스마트폰 앱의 경우 Play Store 또는 App Store에도 페이지가 있습니다. [...] 그러나 일반적으로 검색에도 나타날 수 있는 일반 웹페이지인 방문 페이지와 같습니다. 사람들 이 앱 주변에서 검색할 때 이러한 항목이 검색에 나타날 수 있습니다.

[...] 그리고 특히 웹사이트의 경우 웹사이트의 SEO와 관련하여 우리가 이야기하는 모든 작업을 수행할 수 있습니다. 따라서 앱 인덱싱이 더 이상 10년 전과 같지 않다고 말하지는 않겠습니다. [...] 그러나 오히려 검색에 표시될 수 있는 다양한 방법이 있습니다. 이 특정 측면에만 의존할 필요는 없습니다.”