SEO 업무 시간, 2021년 11월 12일

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

Google Search Console의 NOINDEX 페이지

8:16 “ [일부 페이지]가 noindex로 잘못 설정되었습니다. 이것은 몇 달 전에 수정되었습니다. […] Search Console을 통해 색인 생성을 요청하고 사이트맵을 다시 제출하려고 했지만 여전히 이 페이지의 색인이 생성되지 않습니다. Googlebot이 인덱싱 요청을 수신하지 않거나 Search Console에 인덱싱 관련 알려진 문제가 있는 경우 원인이 무엇인지 알고 계신가요?”

John: “그와 관련하여 알려진 문제가 없다고 생각합니다. 하지만 때때로 우리는 색인 생성 요청 제출과 관련하여 약간 보수적입니다. [...] 한편으로, 페이지가 더 오랜 기간 동안 NOINDEX임을 확인하면 일반적으로 해당 페이지의 크롤링 속도가 느려집니다. [...] 또한 페이지의 색인을 생성할 수 있게 되면 크롤링을 다시 시작하므로 기본적으로 사용자가 수행해야 하는 푸시 유형 중 하나입니다.

또 다른 사실은 Search Console이 기본적으로 우리가 웹사이트에 대해 알고 있는 URL에 대해 보고하기 때문에 사진이 실제보다 더 나빠 보일 수 있다는 것입니다. 예를 들어, 실적 보고서에서 웹사이트의 해당 섹션 또는 해당 URL 패턴을 필터링하여 Search Console의 높은 NOINDEX 페이지가 실제로 중요하지 않았으며 해당 섹션의 중요한 페이지가 실제로 인덱싱되었습니다.”

John은 또한 "[...] 사이트맵은 기본적으로 좋은 시작이지만, 여러분이 할 수 있는 또 다른 일은 이러한 페이지가 웹사이트에 매우 중요하다는 것을 내부 링크를 통해 명확히 하여 우리가 조금 더 빠르게 크롤링할 수 있도록 하는 것입니다. 일시적인 내부 연결이 될 수 있습니다. 몇 주 동안 홈페이지에서 개별 제품으로 연결합니다. [...] 기본적으로 내부 연결이 크게 변경된 것을 발견하면 일반적으로 해당 페이지도 다시 확인합니다. 따라서 다시 인덱스에 반영하는 일시적인 접근 방식이 될 수 있습니다. 내부 링크를 사용하면 웹 전체에서 중요한 페이지가 아니라 웹사이트와 관련된 중요한 페이지입니다. 따라서 내부 링크를 크게 변경하면 색인이 거의 생성되지 않은 웹 사이트의 다른 부분이 어느 시점에서 중단될 수 있습니다. 그래서 임시 수준에서 이 작업을 수행하고 일반 속도로 다시 크롤링되도록 이를 시스템에 다시 푸시하고 모든 것이 다시 정상화되도록 내부 링크를 다시 변경합니다. .”

바닥글에 링크를 추가하는 것과 관련하여 John은 다음과 같이 덧붙였습니다. "그것도 효과가 있을 것이라고 생각합니다. 일반적으로 웹 사이트의 정말 중요한 페이지에서 찾을 수 있다면 더 좋습니다. 일반적으로 홈 페이지와 같은 […] 여기에서 이것이 귀하에게 중요하므로 해당 페이지를 다시 확인하겠습니다. "

표준 및 대체 태그

14:25 “저는 워드프레스 웹사이트를 사용하고 있고 두 개의 플러그인을 사용하고 있습니다. [그 중] 하나는 자동으로 모든 페이지에 rel=" canonical" 링크를 추가합니다. […] [다른 하나는 번역기 플러그인입니다] 모든 페이지에 rel="대체" 링크를 추가합니다. 다음과 같이 말하는 것이 논리적입니까? 해당 URL에 대해 정식이지만 대안이기도 합니까? 크롤러의 어딘가에서 충돌합니까?”

존은 “아니다. 이 두 플러그인이 무엇을 하는지 정확히 모릅니다. 전반적인 관점에서 rel=canonical이 있는 페이지가 있다면 기본적으로 표준적인 말을 하고 있는 것입니다. 언급된 링크는 내가 원하는 기본 URL입니다. 동일한 페이지라면 이 페이지가 인덱싱하려는 페이지라는 확인을 제공하기 때문에 완벽합니다.

rel="alternate"는 기본적으로 이 페이지의 대체 버전도 있음을 의미합니다. 따라서 다른 언어의 경우 예를 들어 영어로 된 한 페이지, 프랑스어로 된 한 페이지가 있는 경우 두 언어 버전 간에 rel="대체" 링크가 있습니다. 그리고 해당 링크가 있는 페이지가 대체 페이지라는 것이 아니라 두 가지 다른 버전인 것 같습니다. 그 중 하나는 영어로, 하나는 프랑스어로 되어 있습니다. 둘 다 표준이 될 수 있으므로 일반적으로 해당 조합을 사용하는 것이 좋습니다.

약간 주의 해야 할 부분 은 표준이 여러 언어에 걸쳐서는 ​​안 된다는 것입니다. 따라서 프랑스어 페이지에서는 기본적으로 다른 페이지이기 때문에 영어 버전으로 정식 설정되어 있으면 안 됩니다. 그러나 프랑스어 페이지는 표준이 될 수 있고 영어 페이지는 표준이 될 수 있으며 둘 사이에 대체 링크가 있으며 이는 본질적으로 좋은 세트입니다."

정규화 또는 noindex 태그

16:49 “우리는 콘텐츠가 얇거나 중복된 다양한 제품이 있는 전자 상거래 상점이 있는 웹사이트를 보유하고 있습니다. 색인을 생성하고 싶은 모든 URL의 목록을 만들었는데 […] 색인을 생성하고 싶지 않습니다. [...] 정규화 또는 NOINDEX 중 어느 것이 더 나은지 잘 모르겠습니다.”

John은 다른 페이지에 대해 "noindex 또는 rel=" canonical을 사용해야 하는지에 대한 일반적인 질문은 아마도 절대적인 답변이 없을 수 있는 문제라고 생각합니다. […] 당신이 그것을 위해 고군분투하는 경우, 당신은 같은 사람이 유일한 사람이 아닙니다 오, 어느 것을 사용해야합니까? 이는 또한 일반적으로 이 두 가지 옵션이 모두 괜찮을 수 있음을 의미합니다. 그래서 보통, 내가 거기에서 볼 것인 것은 당신이 정말로 선호하는 것이 무엇인지입니다. 강력한 선호도가 이 콘텐츠가 검색에 전혀 표시되는 것을 정말로 원하지 않는다면 noindex를 사용할 것입니다. 기본 설정이 더 많다면 모든 것이 한 페이지에 결합되기를 정말로 원합니다. [...], 그러면 rel=” canonical”을 사용하겠습니다. 궁극적으로 효과는 보고 있는 페이지가 검색에 표시되지 않을 가능성이 있다는 점에서 유사하지만 noindex를 사용하면 확실히 표시되지 않고 rel=" canonical"을 사용하면 표시되지 않을 가능성이 더 큽니다. "

존은 “ 둘 다 할 수도 있다. 예를 들어 외부 링크가 이 페이지를 가리키고 있는 경우 두 링크를 모두 거기에 두는 것이 우리가 잘 파악하는 데 도움이 됩니다. 이 페이지의 색인을 생성하는 것을 원하지 않지만 다른 링크도 지정했기 때문에 우리가 할 수 있는 신호 중 일부는 그냥 앞으로.”

모바일 우선 인덱싱 및 크롤링

28:26 “[...] 그에 따라 [모바일 우선 인덱싱을 위해] 사이트를 최적화합니다. 구성과 관련하여 Google은 두 가지 방법을 권장합니다. 첫 번째는 반응형 웹 디자인이고 두 번째는 동적 서빙입니다. 첫 번째 방법은 기술 환경을 통해 달성하기가 약간 어렵기 때문에 두 번째 방법을 사용합니다. 그러나 오늘날에도 여전히 모바일 도메인으로 매일 20만 건 이상의 크롤링이 발생하고 있습니다. 이렇게 보는게 정상인가요? [...] 우리는 m-dot 도메인을 가지고 있었고 메인 도메인으로 리디렉션했습니다.”

이에 존은 “어느 정도 기어가는 것은 정상이다. 리디렉션된 후에도 시스템이 도메인 크롤링을 완전히 중지하는 데 시간이 매우 오래 걸리므로 문제로 보지 않습니다. 우리 시스템은 때때로 이와 같은 일에 대해 매우 긴 메모리를 가지고 있습니다. 사이트를 한 도메인에서 다른 도메인으로 이동하거나 하위 도메인으로 이러한 모바일 변경을 수행하는 경우 크롤링이 완전히 중지되는 데 몇 년이 걸리는 경우가 있습니다."

웹 기술 대 순위

36:00 “ 일반 HTML, CSS, JS 및 다른 하나인 PWA로 만든 웹사이트의 순위에 관계나 영향이 있습니까? [...] 우리의 주요 경쟁자 중 하나가 최근에 그것을 채택했고 우리는 그들의 SERP 순위가 크게 상승한 것을 발견했습니다.”

John은 "이것은 본질적으로 웹사이트를 만드는 다른 방법이며 다양한 프레임워크와 형식으로 웹사이트를 만들 수 있습니다. 대부분의 경우 이것을 일반 HTML 페이지로 봅니다. 따라서 JavaScript 기반 웹 사이트인 경우 렌더링한 다음 일반 HTML 페이지처럼 처리합니다. HTML이 이미 시작 부분에 있다면 그렇게 할 수 있습니다. 그 뒤에는 다양한 프레임워크와 CMS가 있습니다. 일반적으로 우리는 기본적으로 이를 무시하고 여기에 HTML 페이지가 있으며 처리할 수 있다고 말합니다.

따라서 경쟁업체 중 하나가 한 프레임워크에서 다른 프레임워크로 이동하고 검색이 개선되었다는 사실만으로도 내 관점에서 프레임워크 변경은 그에 대한 책임이 없을 것입니다. 하지만 그보다는 프레임워크 변경과 함께 새로운 웹사이트가 생겼을 수도 있습니다. 새로운 웹사이트는 내부 링크가 다르고 내부 콘텐츠가 다르거나 훨씬 빠르거나 훨씬 느리거나 사용자가 정말 좋아하거나 웹사이트 출시와 함께 마케팅 캠페인을 수행했을 수 있습니다. 이 모든 것이 거기에서 작동하며, 사용 중인 프레임워크에 국한되지 않는 모든 것입니다.”

Google PageSpeed ​​Insights 대 Lighthouse

37:39 “Google PageSpeed ​​Insights의 실험실 데이터 결과가 내 Chrome 브라우저의 Lighthouse 결과와 동일합니까? 그들은 같은 공식을 사용합니까?”

John은 “100%는 모르지만 완전히 다르게 수행됩니다. [...] 기본적으로 에뮬레이트된 장치가 있는 데이터 센터에서 실행되는 PageSpeed ​​Insights를 사용하는 경우 일반 컴퓨터처럼 작동하려고 하고 약간 느리게 만드는 제한이 있습니다. [...] Lighthouse에서는 기본적으로 인터넷에 연결된 컴퓨터에서 실행됩니다. Chrome 내의 Lighthouse에는 컴퓨터가 비교할 수 있는지 확인하기 위해 수행할 수 있는 것보다 약간 느리게 보이도록 적용하는 몇 가지 제한 사항이 있다고 생각 합니다.

그러나 본질적으로 이들은 완전히 다른 환경에서 실행되기 때문에 종종 다른 숫자를 볼 수 있습니다. [...] 온라인에서 실행되는 다른 속도 도구로 테스트하면 [또한] 다른 숫자가 표시될 수 있습니다. 또한 Search Console에서 볼 수 있는 검색 순위에 사용하는 데이터인 필드 데이터도 사용자가 평균적으로 다른 종류의 기기나 다른 종류의 인터넷 연결을 가지고 있다는 이유로 완전히 다른 수치가 될 수도 있습니다. 따라서 공식이 같더라도 이러한 시스템을 둘러싼 전체 환경은 매우 다릅니다.”

구글 디스커버

47:09 “우리 웹사이트에서 Google Discover에 큰 문제가 있음을 발견했습니다. 이틀 만에 트래픽이 70% 감소했습니다. [...] 그래서 우리가 뭔가를 잘못했는지 궁금하십니까? [...] 너무 과감한 추첨이기 때문에 정확히 무슨 일이 일어 났는지 명확히 할 수 있습니까? [...] 기술적 오류일 수 있습니까?”

John은 "귀하의 웹사이트와 관련하여 구체적으로 알지 못하지만 많은 사람들로부터 Discover 트래픽이 켜져 있거나 꺼져 있다는 보고를 받았습니다. 우리 알고리즘이 현재 Discover에서 이 웹사이트의 많은 콘텐츠를 표시하지 않을 예정입니다. 그러면 기본적으로 모든 트래픽이 사라집니다. 다른 방식으로, Discover에서 귀하의 웹사이트에서 무언가를 표시하면 갑자기 트래픽이 다시 급증하는 것과 같습니다.

기술적인 문제인 경우 웹 검색에서도 이를 볼 수 있으며 크롤링 문제가 표시되는 것을 볼 수 있습니다. Discover에서 정확히 어떤 일이 일어나는지에 대한 완전한 통찰력은 없지만 일반적으로 사람들이 이야기하는 것을 보는 문제는 웹 사이트의 품질이 좋지 않은 품질 문제입니다. Discover에 대한 개별 정책. 특히 Discover의 경우 웹 검색 과 약간 다른 정책과 성인 콘텐츠, 클릭 유도 콘텐츠와 관련하여 약간 다른 권장 사항이 있다고 생각합니다. [...] 이것이 모두 Discover에 대한 도움말 센터 페이지에 언급된 것입니다. 나는 많은 웹사이트가 이 모든 것을 약간 혼합하고 있다고 상상하고 때때로 우리 알고리즘이 너무 많은 것을 찾는 것 같다고 생각합니다. 그런 다음 그들은 "오, 우리는 지금 이 웹사이트를 조심해야 합니다."라고 말합니다. 따라서 귀하의 웹사이트를 알지 못하거나 Discover가 그곳에서 정확히 무엇을 수집하는지에 대한 세부사항을 알지 못한다면 그것이 제가 그곳으로 향할 방향입니다. […]

우리의 관점에서 디스커버는 사람들에게 정보의 흐름을 보여주려고 하는 곳이며, 그 때문에 실제로 성과를 내기 위해 정확히 무엇을 제공해야 하는지에 대한 자세한 정보가 많지 않은 경향이 있습니다. 그래서 때때로 다른 사람들이 알아낸 것을 살펴보는 것이 합리적입니다.”

응답 시간

50:41 "새로운 뉴스 미디어 사이트의 적절한 응답 시간은?"

John에 따르면 " 응답 시간은 서버 크롤링에 걸리는 시간을 파악하는 데 중요한 역할을 합니다. 일반적으로 실제적인 관점에서 응답 시간은 크롤링에 필요한 병렬 연결 수를 제한하거나 제한합니다. 따라서 웹 사이트에서 1,000개의 URL을 크롤링하려는 경우 하루 동안 해당 URL을 퍼뜨리는 응답 시간이 상당히 길어질 수 있습니다. 반면에 웹 사이트에서 백만 개의 URL을 크롤링하고 응답 시간이 긴 경우 서버에 대한 병렬 연결이 많이 발생하게 됩니다. 서버에 문제를 일으키고 싶지 않다는 점에서 한계가 있다고 생각합니다. 그래서 응답 시간이 크롤링 속도와 직접 연결됩니다.

뉴스 웹사이트의 경우 뉴스인지 아닌지의 문제가 아니라 하루에 크롤링해야 하는 URL의 수입니다. 그것이 내가 그곳에서 바라보는 각도입니다. 뉴스 웹사이트에서 우리는 하루에 10,000페이지를 크롤링할 수 있으며 이러한 기사가 모두 중요한 뉴스 기사입니다. 아카이브를 항상 새로 고쳐야 하기 때문에 하루에 수백만 개의 기사를 크롤링해야 할 수도 있습니다. […] 그러면 응답 시간, 크롤링 속도가 확실히 다르게 보입니다."