SEO 업무 시간, 2022년 7월 1일

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

PageSpeed ​​Insights 또는 Google Search Console - 어느 것이 더 정확합니까?

0:44 “내 웹사이트에서 PageSpeed ​​Insights 점수를 확인하면 간단한 숫자가 표시됩니다. Search Console 및 핵심 성능 보고서에 표시되는 내용과 일치하지 않는 이유는 무엇인가요? 이 숫자 중 어느 것이 맞습니까?”

John에 따르면: “[...] 속도에 관해서는 정확한 숫자가 없습니다 . 웹사이트가 사용자를 위해 수행되는 방식을 이해하는 것과 관련하여. PageSpeed ​​Insights에서는 기본적으로 0에서 100까지의 단일 숫자를 표시한다고 생각합니다. 이는 사용자에게 다른 것이 조금 더 빠르거나 느리다고 가정하는 여러 가정을 기반으로 합니다. 그리고 이를 바탕으로 점수를 계산합니다.

Search Console에는 속도, 응답성, 상호작용성에 대한 세 가지 숫자를 기반으로 하는 핵심 성능 향상 정보 가 있습니다. 그리고 이 숫자는 물론 약간 다릅니다. 왜냐하면 그것은 하나의 숫자가 아니라 세 개의 숫자이기 때문입니다. 그러나 이 수치를 결정하는 방식에도 큰 차이가 있습니다. 즉, 소위 필드 데이터와 실험실 데이터 사이에는 차이가 있습니다.

필드 데이터는 사용자가 웹사이트를 방문할 때 본 것입니다. 그리고 이것이 우리가 Search Console에서 사용하는 것입니다. 그것이 우리가 검색에도 사용하는 것입니다. 실험실 데이터는 웹사이트에 대한 이론적인 관점인 반면, 당사 시스템은 일반 사용자가 아마도 이런 종류의 장치를 사용하고 이런 종류의 연결을 사용하고 있을 것이라고 생각하는 특정 가정을 가지고 있습니다. 그리고 이러한 가정을 기반으로 평균 사용자에게 해당 수치가 얼마인지 추정할 것입니다. 이러한 추정이 100% 정확하지 않을 것이라고 상상할 수 있습니다.

마찬가지로, 사용자가 본 데이터도 시간이 지남에 따라 변경될 것입니다. 일부 사용자는 매우 빠른 연결 또는 빠른 장치를 사용하고 웹사이트에서 또는 웹사이트를 방문할 때 모든 것이 빠르게 진행되지만 다른 사용자는 그렇지 않을 수 있습니다. 그것을 가지고. 그리고 그 때문에 이 변형은 항상 다른 숫자로 나타날 수 있습니다.

일반적으로 Search Console에서 볼 수 있는 필드 데이터를 사용하여 웹 사이트의 현재 상황을 이해한 다음 랩 데이터, 즉 실행할 수 있는 개별 테스트를 사용하는 것이 좋습니다. 웹사이트를 최적화하고 개선하기 위해 직접 자신에게. 그리고 웹사이트의 새 버전에서 얻은 실험실 데이터가 만족스러우면 시간이 지남에 따라 자동으로 발생하는 현장 데이터를 수집하고 사용자가 데이터가 더 빠르다는 것을 다시 확인하거나 더 반응이 좋습니다.

따라서 다시 말해서 이러한 측정항목에 대해 정확한 수치는 없습니다. [… ] 그러나 데이터를 수집하는 데에는 가정과 방법이 다르며 각각이 미묘하게 다릅니다.”

Googlebot이 JavaScript 기반 페이지의 색인을 생성하는 데 어려움을 겪는 이유는 무엇입니까?

4:19 “robots.txt나 사이트맵 파일 없이 Next.js를 사용하는 고객 페이지가 몇 개 있습니다. 이론적으로 Googlebot은 이러한 모든 페이지에 도달할 수 있지만 왜 홈페이지만 색인이 생성됩니까? Search Console에는 오류나 경고가 없습니다. Googlebot이 다른 페이지를 찾지 못하는 이유는 무엇입니까?”

John은 "[...] Next.js는 JavaScript 프레임워크입니다. 즉, 전체 페이지가 JavaScript로 생성됩니다. 그러나 Google이 모든 항목을 색인화하지 않는 이유와 같은 이러한 모든 질문에 대한 일반적인 답변이기도 합니다. 먼저 Googlebot이 웹사이트 전체의 모든 항목을 색인화하지 않을 것이라는 점을 먼저 말하는 것이 중요합니다. Google이 모든 것을 완전히 색인화하는 것은 사소하지 않은 크기의 웹사이트에서 발생하지 않는다고 생각합니다. 실용적인 관점에서 전체 웹에서 모든 것을 인덱싱하는 것은 불가능합니다. 모든 것이 이상적인 상황이라는 가정이 색인화됩니다. ‒ 나는 그것을 제쳐두고 Googlebot이 중요한 페이지에 집중하기를 원한다고 말할 것입니다.

그러나 제 생각에 그 사람이 Twitter에서 저에게 연락하여 자신의 웹사이트에 대한 추가 정보를 주었을 때 조금 더 명확해진 다른 것은 웹 사이트가 다른 페이지에 대한 링크를 생성하는 방식이었다는 것입니다. Google이 선택할 수 없는 방식으로. 따라서 특히 JavaScript를 사용하면 HTML 페이지의 모든 요소를 ​​가져와 누군가가 이를 클릭하면 이 JavaScript를 실행할 수 있습니다. 예를 들어 JavaScript의 일부는 다른 페이지로 이동할 수 있습니다. 그리고 Googlebot은 모든 요소를 ​​클릭하여 무슨 일이 일어나는지 확인하지 않고 웹사이트의 개별 페이지에 연결하는 전통적이고 일반적인 방법인 일반 HTML 링크를 찾습니다.

그리고 이 프레임워크에서는 이러한 일반 HTML 링크를 생성하지 않았습니다. 따라서 크롤링할 내용과 볼 페이지가 더 많다는 사실을 인식할 수 없었습니다. 그리고 이것은 JavaScript 사이트를 구현하는 방식으로 수정할 수 있는 것입니다. JavaScript 및 SEO에 관한 Search Developer Documentation 사이트, 특히 링크 주제에 대한 정보가 많이 있습니다. 링크를 만드는 창의적인 방법이 많이 있으며 Googlebot이 작동하려면 해당 HTML 링크를 찾아야 합니다. […]”

그리고 Google 공식 문서를 제외하고 블로그에서 JavaScript SEO에 대한 Ultimate Guide를 확인하십시오. "

HTTP 페이지에 대한 링크가 웹사이트의 SEO에 영향을 줍니까?

7:35 “내 페이지가 외부의 안전하지 않은 웹사이트에 연결되면 내 SEO 점수에 부정적인 영향을 줍니까? 따라서 HTTPS가 아닌 HTTP에서.”

John은 “우선 SEO 점수에 대한 개념이 없으므로 SEO 점수에 대해 걱정할 필요가 없습니다.

그러나 이와 관계없이 질문은 다음과 같다는 것을 이해합니다. HTTPS 페이지 대신 HTTP 페이지에 연결하는 것이 좋지 않습니까? 그리고 우리의 관점에서는 완벽하게 괜찮습니다. 이러한 페이지가 HTTP에 있는 경우 해당 페이지에 연결할 수 있습니다. 그것이 사용자가 찾을 것으로 기대하는 것입니다. 그런 사이트에 연결하는 데는 아무런 문제가 없습니다. 웹 사이트가 오래되었거나 딱딱하고 HTTPS에서만큼 멋지지 않기 때문에 HTTP 페이지에 대한 링크를 피하는 데에는 단점이 없습니다. 나는 그것에 대해 걱정하지 않을 것입니다.”

거부 파일을 삭제해야 합니까?

10:16 “지난 15년 동안 나는 총 11,000개가 넘는 링크를 거부했습니다. [...] 내가 거부한 링크는 해킹된 사이트나 말도 안되는 자동 생성 콘텐츠에서 온 것일 수 있습니다. Google은 이제 이러한 유형의 해킹 또는 스팸 링크를 알고리즘에 포함하지 않는 더 나은 도구가 있다고 주장하므로 거부 파일을 삭제해야 합니까? 그냥 삭제하면 위험하거나 단점이 있습니까?”

John은 "[...] Google이 전체 정보를 알려주지 않는 것 같아서 링크를 거부하는 것은 항상 까다로운 주제 중 하나입니다.

그러나 우리의 관점에서 […] 우리는 이러한 링크를 고려하지 않기 위해 열심히 노력합니다. 링크 거부 도구가 틈새 도구라는 것을 알고 SEO도 알고 있지만 웹사이트를 운영하는 일반 사람은 이에 대해 전혀 모르기 때문에 그렇게 합니다. 그리고 당신이 언급한 모든 링크는 모든 웹사이트가 수년에 걸쳐 얻게 되는 일종의 링크입니다. 그리고 우리 시스템은 이것이 당신이 우리 알고리즘을 게임하기 위해 하려는 일이 아니라는 것을 이해합니다.

따라서 이러한 관점에서 이러한 링크와 관련하여 해결해야 하는 직접 조치와 관련하여 아무 것도 없다고 확신하는 경우 거부 파일을 삭제 하고 […] 모든 것을 제쳐두고 있습니다. 내가 개인적으로 할 한 가지는 삭제한 내용을 기록할 수 있도록 다운로드하여 복사본을 만드는 것입니다. 그러나 그렇지 않고 이것이 인터넷의 평범하고 딱딱한 것들이라고 확신한다면 삭제하고 계속 진행하겠습니다. 웹사이트에 관해서는 웹사이트에서 발생하는 이러한 무작위적인 일을 부정하는 것보다 훨씬 더 많은 시간을 웹사이트에 할애해야 합니다.”

robots.txt 또는 robots 메타 태그로 크롤링을 차단하는 것이 더 낫습니까?

14:19 “ robots.txt 로 차단하는 것과 페이지에서 robots 메타 태그를 사용하는 것 중 어느 것이 더 낫습니까? 크롤링을 방지하는 가장 좋은 방법은 무엇입니까?”

John: “[...] 최근에 이에 대한 팟캐스트 에피소드 도 진행했습니다. 그래서 나는 그것을 확인할 것입니다. […]

실제로 여기에서 미묘한 차이가 있습니다. SEO에 있고 검색 엔진으로 작업한 적이 있다면 이미 이해하고 있을 것입니다. 그러나 이 지역을 처음 접하는 사람들에게는 이 모든 줄이 정확히 어디에 있는지 명확하지 않을 때가 있습니다.

질문에서 처음 언급한 robots.txt를 사용하면 크롤링을 차단할 수 있습니다. 따라서 Googlebot이 페이지를 보는 것조차 방지할 수 있습니다. 그리고 로봇 메타 태그를 사용하면 Googlebot이 페이지를 보고 로봇 메타 태그를 발견하면 색인 생성 차단과 같은 작업을 수행할 수 있습니다. 실제로 이 두 가지 결과 모두 페이지가 검색 결과에 나타나지 않지만 미묘하게 다릅니다.

따라서 크롤링할 수 없다면 무엇을 놓치고 있는지 알 수 없습니다. 그리고 사실 이 페이지에 대한 많은 참조가 있다고 말할 수도 있습니다. 어쩌면 그것은 무언가에 유용합니다. 우리는 모른다. 그런 다음 해당 URL은 우리가 볼 수 없기 때문에 콘텐츠 없이 검색 결과에 나타날 수 있습니다. 반면 로봇 메타 태그를 사용하면 페이지를 볼 수 있으면 메타 태그를 보고 거기에 noindex가 있는지 확인할 수 있습니다. 그런 다음 해당 페이지의 색인 생성을 중지하고 검색 결과에서 완전히 삭제합니다.

따라서 크롤링을 차단하려는 경우 확실히 robots.txt가 올바른 방법입니다. 페이지를 검색 결과에 표시하지 않으려면 구현하기 쉬운 쪽을 선택하겠습니다. 일부 사이트에서는 이 페이지가 검색에서 발견되는 것을 원하지 않는다는 확인란을 설정한 다음 noindex 메타 태그를 추가하는 것이 더 쉽습니다. 다른 경우에는 robots.txt 파일을 편집하는 것이 더 쉬울 수 있습니다. [그것은] 당신이 거기에 무엇을 가지고 있는지에 달려 있습니다.”

여러 사이트맵 파일에 동일한 URL을 배치할 수 있습니까?

16:40 " XML 사이트맵에 속성이 다른 중복 URL이 있으면 부정적인 영향이 있습니까? 예를 들어 hreflang 주석이 있는 한 사이트맵의 URL과 해당 주석이 없는 다른 사이트맵의 동일한 URL입니다."

John은 “[...] 우리의 관점에서 이것은 완벽하게 괜찮습니다. [...] 이것은 때때로 발생합니다. 어떤 사람들은 사이트맵 파일에 hreflang 주석을 따로 따로 두고 모든 것에 대한 일반 사이트맵 파일도 가지고 있습니다. 그리고 겹치는 부분이 있습니다.

우리의 관점에서 이러한 사이트맵 파일을 가능한 한 처리하고 해당 정보를 모두 고려합니다. 여러 사이트맵 파일에 동일한 URL을 사용하는 데에는 단점이 없습니다.  

내가 주의할 유일한 것은 이 사이트맵 파일에 충돌하는 정보가 없다는 것입니다. 예를 들어 hreflang 주석이 있는 경우 이 페이지는 독일용이고 다른 사이트맵 파일에서는 실제로 이 페이지가 프랑스용이고 […] 시스템은 아마도 여기에서 무슨 일이 일어나고 있을까요? 우리는 이러한 주석 조합으로 무엇을 해야 할지 모릅니다. 그런 다음 우리가 하나 또는 다른 것을 선택하는 일이 발생할 수 있습니다.

마찬가지로, 이 페이지가 20년 전에 마지막으로 변경되었다고 하면 […], 다른 사이트맵 파일에서는 5분 전이라고 합니다. 그러면 우리 시스템이 이를 보고 당신 중 한 명이 틀렸다고 말할 수 있습니다. 우리는 어느 쪽인지 모릅니다. 아마도 우리는 둘 중 하나를 따를 것입니다. 어쩌면 우리는 마지막 수정 날짜를 완전히 무시할 것입니다. 그래서 주의해야 할 점입니다.

그러나 그렇지 않고 여러 사이트맵 파일이 언급되고 정보가 일관되거나 함께 작동하는 경우 하나는 마지막 수정 날짜를 갖고 다른 하나에는 hreflang 주석이 있을 수 있으므로 완벽합니다."

포함된 비디오 페이지가 인덱싱되지 않도록 하는 방법은 무엇입니까?

19:00 “저는 비디오 재생 플랫폼을 담당하고 있으며 우리의 임베드는 때때로 개별적으로 인덱싱됩니다. 어떻게 막을 수 있습니까?”

John은 다음과 같이 대답했습니다. “[...] 웹사이트를 보았는데, 이것은 비디오 플레이어가 내장된 단순화된 HTML 페이지를 포함하는 iframe입니다.

기술적인 관점에서 페이지에 iframe 콘텐츠가 있으면 두 개의 HTML 페이지가 표시됩니다. 그리고 우리 시스템은 두 HTML 페이지가 별도의 HTML 페이지이기 때문에 두 HTML 페이지를 모두 색인화했을 수 있습니다. 하나는 일반적으로 다른 하나에 포함되지만 이론적으로 자체적으로 설 수도 있습니다.

그리고 그것을 방지할 수 있는 한 가지 방법이 있습니다. 이는 할 수 있는 로봇 메타 태그와의 상당히 새로운 조합입니다. 이는 indexifembedded robots 메타 태그 와 noindex robots 메타 태그 를 사용하는 것 입니다.

그리고 포함된 버전에서는 비디오가 직접 포함된 HTML 파일에 noindex와 indexifembedded robots 메타 태그의 조합을 추가합니다. 즉, 해당 페이지를 개별적으로 찾으면 noindex [태그]가 있음을 알 수 있습니다. 우리는 이것을 인덱싱할 필요가 없습니다.

그러나 indexifembedded를 사용하면 […] 일반 웹사이트에 비디오가 포함된 이 페이지를 찾으면 해당 비디오 콘텐츠를 색인화할 수 있습니다. 즉, 개별 HTML 페이지는 색인화되지 않습니다. 그러나 비디오 정보가 포함된 임베드가 있는 HTML 페이지는 정상적으로 인덱싱됩니다. 그것이 내가 거기에서 사용할 설정입니다. 그리고 이것은 상당히 새로운 로봇 메타 태그이므로 모든 사람이 필요로 하는 것은 아닙니다. iframe 콘텐츠 또는 포함된 콘텐츠의 이러한 조합은 드물기 때문입니다. 그러나 일부 사이트의 경우 그렇게 하는 것이 합리적입니다.”