SEO 업무 시간, 2021년 11월 5일
게시 됨: 2021-11-102021년 11월 5일 John Mueller 와 함께한 Google SEO Office Hours 에서 가장 흥미로운 질문과 답변을 요약한 것입니다 .
스팸 백링크와 핵심 업데이트
00:47 “스위스에는 3개의 온라인 약국이 있습니다. [...] [그 중 하나]의 경우 스팸 백링크가 많이 있습니다. [...] 내가 이미 알고 있는 바에 따르면 일반적으로 Google은 이러한 유형의 백링크를 관리할 수 있지만 7월의 Google 핵심 업데이트 이후에는 특히 스팸성 백링크를 받은 [한] 상점에 대해 가시성이 크게 손상되었습니다. [...] 나는 그것에 대한 당신의 추천을 받고 싶습니다. 우리가 가진 기술적 문제를 해결하기 위해 무엇을 할 수 있습니까? 지금까지는 스팸 백링크 때문에 그런 일이 발생했다고 생각하지만 [확실하지 않습니다.]
John은 다음과 같이 말했습니다. “일반적으로 핵심 업데이트에서 변경 사항이 발견되면 일반적으로 사이트의 관련성이 전반적으로 무엇인지 파악하는 것과 관련이 있고 스팸 링크와 같은 것과는 관련이 적습니다. 그것은 내가 당신의 웹사이트로 이동하는 임의의 스팸 링크를 기반으로 하는 핵심 업데이트에서 어떤 반응도 기대하지 않는 것입니다.
또한 핵심 업데이트를 사용하면 전반적인 품질과 관련하여 시간이 지남에 따라 사이트를 개선하기 위해 점진적으로 변경할 수 있으며 이는 점진적으로 도움이 될 것이지만 핵심 업데이트로 정말 강력한 조정이었다면 기다려야 할 수도 있습니다. 이러한 변경 사항을 보려면 다음 핵심 업데이트까지. [...] 사이트의 관련성이 전반적으로 무엇인지 파악하려고 노력하는 것은 우리의 문제이며 이는 전체 사이트의 품질에 거의 의존하는 것입니다.
상당히 유사한 상점이 여러 개 있는 경우 까다롭다고 생각합니다. [...] 아마도 그 중 하나가 나쁘다는 것이 아니라 다른 하나는 정말 좋습니다. 그러나 여전히 사용자 연구를 사용하여 이 사이트가 특히 관련성이 있음을 분명히 하기 위해 […] 무엇을 할 수 있는지 알아낼 수 있는 것입니다. 제 생각에는 특히 약국과 같은 웹사이트와 관련하여 저희 알고리즘이 좀 더 중요해지도록 노력해야 하는 부분이라고 생각합니다. [...] 스토리와 재미있는 그림이 있는 임의의 웹사이트가 아니라 사람들의 건강과 관련이 있습니다."
John은 “특히 핵심 업데이트와 관련이 없는 404페이지 및 기술적인 문제와 관련하여. 핵심 업데이트는 사이트의 전반적인 품질과 관련성을 이해하는 데 중점을 두고 있으며 기술적인 문제보다는 스팸에 대한 것입니다."
자바스크립트 콘텐츠 인덱싱
05:11 “Core Web Vitals용 웹사이트 [...]에서 일하고 있습니다. 유튜브 영상을 맨 위에 올려놓는 기능이 있어서 LCP 요소가 되었습니다. 우리가 가진 것보다 일반 이미지처럼 무거웠습니다. 그래서 우리는 그것을 동적으로 주입하는 방법을 시도하고 있습니다. [… ] 폴드 콘텐츠 아래에 있지 않기 때문에 지연 로드하지 않지만 파사드를 사용하고 있으며 사용자가 재생 버튼을 클릭할 때 <iframe>이 동적으로 주입됩니다. 기사가 본질적으로 페이지의 비디오 콘텐츠와 함께 인덱싱되지 않는다는 것을 이제 깨달았습니다. 따라서 페이지를 검색하고 비디오 검색으로 이동하면 거기에 나타나지 않습니다. 페이지와 함께 해당 콘텐츠의 색인을 생성하는 가장 좋은 방법이 무엇인지 궁금합니다. [...] <noscript> 같은 것이나 구조화된 데이터가 갈 길입니까? 이에 대한 모범 사례가 있습니까?”
John: “당신이 거기에서 언급한 파사드를 설정하는 방식에 따라, 기본적으로 이미지나 <div>를 클릭한 다음 백그라운드에서 비디오를 로드하는 경우가 있을 수 있습니다. t 우리가 페이지를 볼 때 자동으로 비디오로 선택합니다. 나는 비디오 검색 팀으로부터 우리가 사람들에게 이런 문제를 야기하기 때문에 이것을 하지 말라고 하는 피드백을 받았습니다. 기본적으로 가장 좋은 접근 방식은 구조화된 데이터를 사용하여 아직 동영상이 있다는 것을 알 수 있도록 하는 것입니다. 추가할 수 있는 비디오 전용 구조화된 데이터가 있다고 생각합니다. 동영상 사이트맵은 이 페이지에서 관련 동영상이 있다는 점에서 본질적으로 매우 유사합니다. 그래서 두 가지 접근 방식이 있습니다.
시간이 지남에 따라 Youtube 삽입이 점점 더 빨라지고 이러한 트릭을 수행해야 하는 문제가 줄어들 것이라고 생각합니다. 그러나 현재로서는 여전히 의미가 있을 수 있으며 페이지의 핵심 웹 바이탈에 여전히 큰 영향을 미칠 수 있다고 생각합니다. 그런 면에서 보면 기가 막힙니다. 영상팀에서 직접 올려야 한다고 하고 다른팀에서는 빨리 하라고 하면 중간 지점을 찾기 어렵습니다. 하지만 적어도 비디오가 있다는 것을 인식할 수 있도록 하는 것이 정말 중요하다고 생각합니다.”
카테고리 페이지
13:35 “우리는 [...] 금속 프로파일을 판매하고 있으며 이러한 프로파일의 다양한 유형이 있습니다. 우리는 같은 변형이 있기 때문에 얇은 콘텐츠가 많이 있습니다. [...] 우리는 이 URL 내에 수천 개의 변형 [...]을 가지고 있으며 이를 처리하는 방법을 모르겠습니다. 그것들을 정규화해야 합니까? 그러나 다시, 우리는 [이 URL들]에 연결하고 있으므로 내 페이지 내부에 나쁜 인링크나 품질이 나쁜 링크를 만들고 싶지 않습니다. [이 URL]의 색인을 생성하지 않거나 로봇에서 [이]를 차단해야 합니까? [...] 우리는 이러한 변형 페이지에 사람들이 올 필요가 없습니다. 카테고리 페이지에서 좋은 품질을 만들고 싶을 뿐입니다.”
John은 다음과 같이 대답했습니다. "일반적으로 고유한 항목을 고유한 방법으로 찾을 수 있는 경우 고유한 URL이 있는지 확인하고 해당 항목이 표준인지 확인하는 것이 좋습니다. noindex에 의해 차단되지 않습니다. 그러나 이러한 개별 URL에 관심이 없거나 상위 수준 카테고리에 더 관심이 있는 경우 또는 본질적으로 콘텐츠를 찾는 가장 중요한 방법인 보다 광범위한 제품 또는 카테고리가 있는 경우 다음을 수행할 수 있습니다. 원하는 경우 해당 페이지에 다른 버전의 색인을 생성할 수 없습니다. 따라서 기본적으로 원하는 모든 작업을 수행하여 귀하가 관심을 갖고 있는 해당 메인 페이지에 모든 신호를 집중할 수 있습니다.
[...] 귀하가 언급한 것과 같은 산업 제품의 경우 치수와 변형이 매우 다양하므로 일반적인 레이아웃에 초점을 맞추고 이러한 다양한 옵션이 모두 기본적으로 주요 제품의 속성이라고 말하는 것이 합리적일 것입니다. 주요 제품에만 집중해야 합니다.”
John은 “Canonical을 설정할 때 염두에 두어야 할 점은 말씀해 주신 Canonical 페이지의 색인을 생성하려고 한다는 것입니다. 따라서 비표준 페이지에 고유한 것이 있다면 우리는 그것을 찾을 수 없을 것이므로 본질적으로 중요한 것은 무엇입니까? 표준 페이지에도 언급되어 있는지 확인하십시오.”
Google 디스커버에서의 순위
18:31 “디스커버에는 서로 다른 두 개의 검색 결과 페이지가 있습니다. 첫 번째 페이지가 있고 더 많은 결과를 클릭하면 두 번째 페이지가 나타납니다. 어떤 기사가 두 번째 페이지에 오도록 순위가 관련되어 있습니까? 아니면 업데이트되는 시간 문제입니까?”
존은 “ 순위의식이 있을 수 있지만 기존의 웹 랭킹과 같지는 않다고 생각한다. Discover는 너무 개인화되어 있으므로, '오, Discover 페이지를 열었고 5위이고 다음번에 4위가 될 수도 있습니다'라는 전통적인 개념을 갖는 것은 말이 되지 않습니다 그런. […]

개인화 된 순위 측면에도 들어가는 것들이 많이 있습니다. 지역 타겟팅의 다양한 측면과 웹 페이지의 다양한 형식, 더 많은 비디오 또는 더 적은 비디오, 더 많은 이미지 - 더 적은 이미지가 있다고 생각합니다. 하지만 솔직히 [이것이] 구체적으로 무엇인지 모르겠습니다.”
존은 또한 구글의 권고사항 을 따를 것을 권고 하며 “특히 이런 행동을 하지 말라고 하는 측면을 조심하라. 나는 또한 Twitter에서 외부를 둘러볼 것입니다. Discover에 거의 전문화된 소수의 사람들이 있습니다. [… ] 그런 것들을 확인하고 싶지만 우리의 관점에서 볼 때 개인화 된 피드이기 때문에 거기에서 순위를 향상시키기 위해 노력할 수는 없습니다. 사람들이 찾는 키워드가 아닙니다. 그래서 우리가 흥미롭게 생각할 수 있는 몇 가지 자료가 있습니다.”
301 리디렉션
22:23 “영구 리디렉션에 301을 사용하여 PageRank를 가능한 가장 빠르고 빠르게 전달해야 한다는 것을 알고 있습니다. 그러나 우리 개발 팀은 301이 브라우저에 영원히 저장되기 때문에 구현하는 것을 좋아하지 않습니다. 그들은 잘못 구성된 리디렉션의 경우 사람들이 잘못된 301 리디렉션을 잃지 않을 수 있다고 말합니다. Google은 일부 브라우저와 마찬가지로 301 리디렉션을 저장합니까?”
John에 따르면 "전체 크롤링 및 인덱싱 시스템은 모든 네트워크 측면이 서로 다른 것에 최적화되어 있다는 점에서 브라우저와 본질적으로 다릅니다. 브라우저에서는 사물을 캐시하고 더 오래 캐시하는 것이 훨씬 더 합리적입니다. 그러나 본질적으로 크롤링 및 인덱싱 측면에서 […] 우리의 관점에서 크롤링 및 인덱싱 을 브라우저와 동일하게 취급하지 않습니다. 페이지를 브라우저처럼 렌더링한다는 점에서 약간 이상하지만 콘텐츠를 시스템으로 가져오는 전체 프로세스는 매우 다릅니다. 페이지를 렌더링하거나 페이지가 렌더링되는 것을 볼 때 가끔 이것을 볼 수 있습니다. 브라우저에 있을 수 있는 잠시 동안 캐시할 수 있었기 때문에 정말 오래된 JavaScript 파일을 사용합니다. 그러나 본질적으로 다릅니다.”
캐시 제어 헤더
23:59 " Google은 "Cache-Control: no-cache", "Cache-Control: max-age=[time]" 또는 "Expires: [date]" 헤더가 있는 301 리디렉션을 수락하여 두 세계의 최고?"
John은 “네, 아주 좋습니다. 301 리디렉션인 경우 301 리디렉션으로 처리합니다. 그 위에 추가하는 캐시 헤더의 종류는 중요하지 않습니다. 따라서 이러한 관점에서 이것이 귀하의 개발 팀과 귀하 자신을 위해 잘 작동하는 솔루션이라면 그 이유는 무엇입니까? [...] 다른 것은 302 리디렉션이 개발자 팀에 더 잘 작동하는 경우 옵션이 될 수도 있다는 것입니다. 302 리디렉션은 일반 리디렉션과 동일하게 작동하기 때문에 잘못된 것으로 생각되는 SEO 사이에서 평판이 좋지 않습니다. 그들이 그런 어떤 PageRank도 전달하지 않는다는 것이 아닙니다. 장기적으로 302개의 리디렉션이 있는 경우 어쨌든 301개의 리디렉션과 동일하게 취급합니다. 따라서 301 리디렉션이 어떻게 작동하는지 알 수 없다면 302 리디렉션도 옵션이 될 수 있습니다.”
품질 향상 인식
31:25 “페이지 경험 업데이트를 통해 Google에서 페이지 품질을 개선하는 것이 중요하다면 Google에서 이러한 개선 사항을 인식하는 데 왜 그렇게 오랜 시간이 걸리나요? SEO가 몇 달 동안 검색 순위와 트래픽을 희생해야 하는 경우 웹 경험을 개선하기 위해 실질적인 차이를 만들기 위해 노력하는 것은 직관적이지 않은 것 같습니다.”
John에 따르면, “[...] 웹사이트를 더 크게 변경하면 때때로 변동이 발생하지만 웹사이트를 개선했기 때문에 변동이 있다고 말할 수 있는 부분은 아닙니다. 웹 사이트에서 정말 큰 변화를 일으킬 때 우리는 웹 사이트를 다시 이해해야 합니다. 그러나 내 관점에서 보면 설정 방법에 따라 웹사이트에서 수행할 수 있는 많은 재구성 [...] – 검색 및 웹사이트 전체가 사라지지 않도록 하세요."
NOINDEX 페이지 대 사이트 크롤링 가능성
32:48 "품질로 인해 여러 페이지의 색인이 생성되지 않으면 전체 사이트 크롤링 가능성에 영향을 줍니까?"
존: “아니. 페이지의 색인을 생성하지 않도록 선택하더라도 웹사이트의 나머지 부분을 크롤링하는 방법에는 영향을 미치지 않습니다. 물론 여기서 한 가지 예외는 noindex에서 해당 페이지를 먼저 크롤링해야 한다는 점입니다. 따라서 생성 중인 페이지가 수백만 페이지이고 그 중 90%가 색인이 없는 페이지가 있고 색인을 생성할 수 있는 페이지가 100개 있다고 가정해 보겠습니다. 우리는 그 100페이지를 발견하기 위해 전체 웹사이트를 크롤링해야 하며, 분명히 수백만 페이지를 크롤링하는 데 수렁에 빠질 것입니다. 그러나 색인 생성 가능 페이지와 색인 불가능 페이지의 비율이 보통이라면 [...] ‒ 크롤링 가능성과 관련하여 전혀 문제를 일으키지 않는 것으로 보입니다. 그리고 이것은 Google이 말하는 품질상의 이유 때문에 […] 아닙니다. 색인 페이지가 좋지 않습니다. 순전히 기술적인 문제입니다. 백만 개의 URL을 크롤링해야 하는 경우 백만 개의 URL을 크롤링하여 거기에 무엇이 있는지 확인해야 합니다. 그것은 우리가 말할 수 있는 것이 아닙니다. 음, 일부 noindex 페이지가 있기 때문에 50,000개만 크롤링할 것입니다. 본질적으로 그것은 단지 숫자의 문제입니다.”
302 리디렉션
34:22 “임시(302) 리디렉션이 링크 자산을 통과하지 못한다고 들었습니다. 그것에 대한 우리의 이해가 정확합니까? 일반적으로 302를 사용하면 심각한 SEO 문제가 발생한다는 말을 들었습니다. 따라서 302를 어떻게든 피해야 하는지 아니면 사용해야 하는 특정 상황이 있는지 궁금합니다.”
존은 “대답은 아니오이다. 302 리디렉션으로 인한 부정적인 SEO 효과는 없습니다. 302 리디렉션을 수행할 때 PageRank를 잃는 전체적인 느낌은 거짓이라고 생각합니다. 이따금 나옵니다. 이것이 나오는 주된 이유는 302 리디렉션이 정의에 따라 다르기 때문이라고 생각합니다. [...] 301 리디렉션을 사용하여 주소를 변경하고 Google 시스템이 대상 페이지를 선택하기를 원합니다. 302 리디렉션을 사용하면 일시적으로 다른 위치에 있지만 Google 시스템이 원래 URL을 유지하기를 원한다고 말합니다. 따라서 순전히 개별 URL의 순위를 추적하는 경우 301은 대상 페이지의 색인을 생성하고 순위 및 302 리디렉션은 원래 페이지 색인과 순위를 유지합니다. 그러나 PageRank 또는 할당된 신호의 손실은 없습니다. [...] 때로는 302 리디렉션이 올바른 일입니다. 때로는 301 리디렉션이 올바른 일입니다. 일시적인 움직임이 아닐 수도 있다고 생각하는 더 오랜 기간 동안 302 리디렉션을 발견하면 301 리디렉션으로도 취급합니다. 그러나 301 리디렉션과 302 리디렉션을 사용하면 숨겨진 SEO 이점이 없습니다. 그것들은 단지 다른 것들일 뿐입니다.”
사용자에게 더 적은 콘텐츠 표시
46:54 “[한 가지] 클라이언트에 문제가 있습니다. [...] robots.txt에 의해 차단된 많은 URL에는 noindex에 설정된 HTTP 헤더도 있습니다. 그래서 URL의 색인을 제거할 수 있도록 robots.txt를 열도록 설정했습니다. 그러나 클라이언트는 서버가 모든 요청보다 먼저 실행되지 않고 실패할 것을 두려워합니다. 그래서 저는 사용자 에이전트를 봇으로 본다면 빈 HTML 본문이나 다른 페이지를 제공할 수 있다고 말했습니다. HTTP 헤더가 noindex로 설정되어 있으면 클로킹으로 인해 불이익을 받을 위험이 있나요?”
John은 이렇게 대답 했습니다. 특히 검색 엔진을 사용자에게 표시하는 것보다 적게 표시하는 경우 클로킹과 관련하여 문제가 되지 않습니다. 우리에게 더 문제가 되는 클로킹 부분은 우리에게 정말 크고 흥미로운 페이지를 보여주고 사용자가 거기에 도착했을 때 정말 작거나 약간 다른 것을 보게 되는 것입니다. 그러나 본질적으로 빈 페이지를 보여주면서 "여기에 이 페이지의 색인을 생성하지 말아야 할 것이 없습니다. 그리고 색인에서 삭제하면 사용자가 다른 것을 보더라도 상관하지 않습니다."라고 말합니다. 따라서 우리의 관점 에서 피하고 싶은 것은 사용자에게 찾을 수 없는 것을 약속하는 것입니다. 따라서 색인에서 페이지를 삭제하면 더 이상 해당 페이지가 없기 때문에 해당 페이지를 추천할 수 없습니다. [...] 우리가 사람들에게 특정 쿼리에 대한 페이지를 추천하고 그들이 거기에 가는데 그 콘텐츠를 찾을 수 없다면 그들은 좌절하고 우리가 잘못했다고 생각합니다. 그것이 바로 우리의 클로킹 문제가 있는 곳입니다. 에서 오는. 하지만 적게 보여주는 것은 완벽합니다.”
