SEO 업무 시간 – 2021년 12월 24일

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

페이월 콘텐츠 및 클로킹

00:49 “페이월 콘텐츠가 있는 페이월 데이터와 관련하여. [...] 웹사이트가 있습니다. 우리는 많은 기사를 작성했으며 모든 것이 Google에서 액세스할 수 있습니다. 그리고 거기에 페이월을 추가하고 싶지만 [...]만 […] 사용자가 가지고 있는 구조화된 데이터 스니펫과 함께 페이월 콘텐츠를 Google에 표시합니다. 은폐로 간주됩니까?

그래서 구글봇인지 확인하고 […] 구조화된 데이터, 즉 페이월 데이터만 […] 표시합니다. 하지만 일반 사용자에게는 [...] 구조화된 데이터를 표시하지 않습니다. 괜찮나요?”

John은 이 솔루션의 문제를 보지 못했습니다. “괜찮습니다. 다른 것을 보여주고 있기 때문에 기술적으로 여전히 클로킹으로 간주 되지만 Google 정책에서는 허용됩니다. 사용자가 […] 페이월을 통과하면 […] Googlebot에 표시되는 콘텐츠를 볼 것이기 때문입니다.”

잠재적인 인덱싱 문제

03:38 “나는 고품질 콘텐츠를 게시하고 사이트맵을 제출하고 때때로 Google Search Console에서 색인 생성을 요청합니다. 하지만 새 콘텐츠를 인덱싱하는 데 여전히 문제가 있거나 [지연됨]으로 인덱싱됩니다. [...] Google의 버그입니까, 아니면 새로운 알고리즘 업데이트입니까?”

존은 “그런 점에서 우리 쪽에는 버그가 없습니다. [...] 우리는 모든 콘텐츠 를 색인화하지 않으며 일부 웹사이트에서는 많은 콘텐츠를 생성합니다. 모든 것을 색인화하지 않으면 […] 괜찮습니다. 하지만 모든 것을 색인화하기를 원할 수도 있고 항상 모든 작업을 수행할 수는 없습니다.

까다로운 부분 […]은 과거에 […] 많은 웹사이트가 기술적으로 그렇게 좋지 않았다는 것입니다. 어떤 콘텐츠가 인덱싱되지 않았는지 조금 더 명확해졌습니다. 요즘 웹 사이트는 기술적으로 정상이며 [...] 품질 표시줄이 약간 더 높은 [...]과 같습니다. 누구나 이론적으로 인덱싱될 수 있는 것을 게시할 수 있지만 […] 실제로 유용하고 사용자에게 관련성이 있는 올바른 것을 인덱싱해야 합니다. 그래서 우리는 때때로 어떤 것을 색인화하지 않은 채로 놔둬야 합니다.”

제품 리뷰 업데이트 – 영향을 받는 언어 및 국가

14:01 “상품평 업데이트 안내입니다. [...] 업데이트가 영어권 웹사이트에만 영향을 미치더라도 독일어 검색에서도 약간의 움직임이 보였습니다. 이 제품 리뷰 업데이트나 어떤 종류의 [...]에 의해 다른 언어의 웹사이트에도 영향을 미칠 수 있는지 궁금합니다.”

John이 말했듯이 " 내 가정은 이것이 전 세계적이고 모든 언어에 걸쳐 […] 그러나 일반적으로 엔지니어링 팀이 이에 대한 결정을 내리도록 하여 블로그 게시물에 적절하게 문서화할 수 있도록 합니다. 제품 리뷰 업데이트로 그런 일이 발생했는지 모르겠습니다. [...] 우리가 여러 언어로 할 수 있고 영어에만 얽매이지 않을 것 같습니다. 그리고 처음에 영어였더라도 전반적으로 관련이 있는 것처럼 느껴지며 시간이 지남에 따라 다른 언어로도 롤아웃할 수 있는 방법을 찾아야 합니다. 그래서 독일에서 변화를 목격한 것이 그다지 놀랍지 않습니다. […]”

Google 블로그 게시물이 영어 웹사이트에 영향을 미치는 업데이트만 언급한 것을 알게 된 John은 다음과 같이 자세히 설명했습니다.

“이러한 종류의 업데이트를 통해 우리는 하나의 언어 또는 하나의 위치에서 시작하여 조정해야 할 사항을 확인한 다음 거기에서 확장합니다. [...] 콘텐츠와 관련된 콘텐츠의 경우 일반적으로 다른 언어로 확장하는 데 시간이 조금 더 걸립니다 [...].”

영어권 국가의 페이지 현지화

17:53 “다른 영어권 국가에 대해 동일한 페이지 집합을 현지화하는 다른 방법을 알고 있습니까? [...] 호주, 뉴질랜드 하위 도메인과 같이 .jo 최상위 도메인이 있는 여러 하위 도메인이 있으며 JSA 백엔드에서 국가를 설정하고 페이지 수준에서도 hreflang을 사용합니다. [...] 이러한 하위 도메인을 현지화하는 데 도움이 되는 다른 방법을 찾을 수 없었습니다. 좋은 방법이나 개선할 수 있는 방법이 있습니까?”

John이 이 주제에 대해 논의한 방법은 다음과 같습니다.

“주요 내용을 다뤘다고 생각합니다. 그것은 Search Console 및 hreflang 설정의 지역 타겟팅입니다.

지역 타겟팅 은 하위 디렉토리 또는 하위 도메인 수준에서 작동하며 모든 페이지가 거기에 있습니다.

Hreflang은 페이지 단위입니다. 한 국가에 대한 홈페이지가 있고 같은 국가에 대해 서로 다른 제품 페이지가 있는 경우 해당 페이지 각각을 hreflang과 교차 링크해야 합니다.

제가 항상 추천하려고 하는 또 다른 방법은 일종의 백업 계획을 세우는 것입니다. […] 사용자가 잘못된 버전의 사이트에 있다는 것을 인식할 때 표시할 수 있는 JavaScript 기반 배너와 같은 것입니다. 예를 들어 호주의 사용자가 영국의 페이지를 방문하는 경우 '이 페이지의 호주 버전이 있습니다. 바로 갈 수 있습니다.' 자바스크립트 기반 배너의 장점은 robots.txt로 차단할 수 있어 인덱싱 관점에서 볼 때 표시되지 않는다는 것입니다. 그리고 자동으로 리디렉션하지 않으면 […] [검색 엔진]이 두 버전을 독립적으로 처리할 수 있습니다.

이러한 페이지가 본질적으로 동일한 경우 이러한 페이지 중 하나를 표준 버전으로 취급할 수 있습니다. 예를 들어, 뉴질랜드와 호주에 대한 페이지가 있고 전체 내용이 동일하고 약간만 다른 것은 페이지의 통화뿐이며 […] 우리는 해당 페이지를 함께 접고 그 중 하나를 다음과 같이 선택합니다. 표준이며 이를 검색의 기초로 사용합니다.

hreflang이 있는 경우 해당 페이지에서도 여전히 hreflang을 사용하여 올바른 버전의 URL을 표시합니다. 그러나 인덱싱된 콘텐츠는 정식 버전에서 가져온 것이며 Search Console의 모든 보고는 정식 버전에 대한 것입니다. 그것은 때때로 약간 까다롭습니다. 특히 다른 국가에 대해 동일한 콘텐츠를 가진 더 큰 웹사이트가 있는 경우에 더욱 그렇습니다.”

페이지에 동적 콘텐츠 추가

25:0 “내 웹사이트에는 카테고리, 하위 카테고리, 제품, 전자상거래 […] 페이지와 같은 수백만 페이지가 있습니다. 우리는 동적 콘텐츠를 추가했습니다. 수백만 페이지가 […] […] 각 페이지에 별도의 콘텐츠나 고유한 콘텐츠를 […] 추가하기 어렵기 때문입니다. 카테고리 페이지, 하위 카테고리 페이지 및 제품 페이지에 […] 템플릿 기반 콘텐츠를 추가했습니다. [...] 웹사이트 성능에 좋을까, 아니면 각 페이지의 콘텐츠를 업데이트해야 할까요? […]”.

존은 이렇게 대답했습니다.

" 페이지에 관련 콘텐츠를 동적으로 추가하는 것은 […] 의미가 있을 수 있습니다 . […] [그것]은 본질적으로 […] 데이터베이스 조회를 수행하고 이를 기반으로 콘텐츠를 추가하기 때문입니다. [...] 설정 방법에 따라 다릅니다.

내가 피하고 싶은 주요 사항은 인위적으로 추가한 키워드에 대해 이 페이지의 순위가 더 높기를 바라는 목적으로 페이지에 인위적으로 콘텐츠를 추가하는 상황에 빠지는 것입니다. [...] 사용자가 거기에 가면 '이 페이지에 이러한 임의의 키워드가 있는 이유는 무엇입니까?' [...] 해당 핵심 키워드에 대해 실제로 적절하고 관련성 높은 콘텐츠가 있는지 확인하는 것이 [...]에 더 중점을 둡니다.”

Google이 페이지를 가치를 제공하는 것으로 보기 위해 각 페이지에 관련 콘텐츠를 작성해야 하는지 추가로 질문했을 때 John은 다음과 같이 말했습니다.

“페이지에 관련성이 있는 내용이어야 합니다. 그리고 그것이 카테고리 페이지라면, 거기에 나열한 제품은 매우 관련성이 있고 [...] 일반적으로 해당 카테고리에 대한 설명이 있습니다. [...] 이 모든 제품과 제품의 출처에 대해 맨 아래에 Wikipedia 기사를 작성해야 하는 것이 아니라 [...] 페이지와 관련된 약간의 정보가 중요합니다.”

JavaScript 파일 렌더링 및 인덱싱

28:28 “내 웹사이트 […] [사용] 클라이언트 측 렌더링으로 React, […] JavaScript와 브라우저를 끄면 내 페이지가 완전히 비어 있습니다. 그것이 낮은 순위 또는 웹 페이지의 성능 저하의 원인이 될 수 있습니까?”

John의 대답은 다음과 같습니다 . [...] 검색을 위해 렌더링을 수행하고 페이지에서 JavaScript를 처리합니다. 일반 브라우저에서 볼 수 있고 특별히 나쁜 작업을 수행하지 않는 경우 해당 페이지를 정상적으로 색인화할 수 있습니다. Search Console 의 Inspect URL 도구 를 사용하여 Googlebot이 페이지를 렌더링하려고 할 때 콘텐츠가 실제로 표시되는지 확인 하고 콘텐츠가 표시되면 모든 설정이 완료된 것입니다 ."

웹사이트 내 검색을 통해 생성된 인덱싱 URL

30:11 “우리는 이미 우리 웹사이트에 검색창을 추가했습니다 . 그래서 사용자가 우리 웹사이트에 와서 검색하면 모든 검색에 대해 고유한 URL이 생성됩니다. 이러한 URL은 색인을 생성할 수 있어야 합니까?

John이 말했듯이 “ 보통 그렇지 않습니다. […] 그 이유는 크게 두 가지입니다.

한편으로는 검색만 다른 백만 개의 URL이 더 있고 아무런 가치도 제공하지 않는 상황이 되기 쉽습니다. 우리는 그것을 무한 공간[…]이라고 부릅니다. 그것은 당신이 피하고 싶은 것입니다.

피하고 싶은 또 다른 것은 사람들이 검색 상자에서 스팸성 작업을 수행하고 이러한 항목을 색인화하려고 시도하는 것 입니다. 이는 전화번호 및 […] 비즈니스 유형을 검색하는 것과 같을 수 있습니다. 갑자기, 귀하의 웹사이트 검색 페이지는 그러한 종류의 비즈니스에 대한 순위를 매기고 전화번호를 표시합니다. 귀하가 해당 검색어와 일치하는 콘텐츠가 없더라도 [...] 검색 결과에 표시되도록 하기 위해 이 작업을 수행합니다. robots.txt를 사용하여 이러한 종류의 검색 페이지를 차단합니다. 그렇게 하면 콘텐츠에 대한 색인을 생성할 수 없다는 것을 확신할 수 있습니다.”

YMYL과 같은 SEO 사이트

31:55 "SEO 회사는 Your Money 또는 Your Life 웹사이트로 분류됩니까, 아니면 의료 및 재정 조언 웹사이트와만 관련이 있습니까?"

John에 따르면, “[...] SEO 웹사이트가 사람들의 삶에 그렇게 중요하다고 생각하지 않습니다. 분명히, 만약 당신이 SEO 회사에서 일한다면 당신은 그것에 묶여 있지만 웹사이트 자체가 당신의 돈이나 당신의 삶 유형 웹사이트라는 것은 아닙니다. [...] 무언가를 판매하는 모든 웹사이트가 이 범주에 속하는 것은 아닙니다.

여기서 제가 추천하고 싶은 것은 맹목적으로 '이 유형의 웹사이트가 이 특정 범주에 속하는가?'를 확인하려는 것보다 […] 이 범주가 어디에서 왔는지, 즉 품질 평가자 가이드라인을 읽고 조금 더 이해하는 것입니다. Google은 이러한 다양한 유형의 웹사이트를 이해하기 위해 무엇을 하려고 하는지입니다 . […] 그러면 실제로 일어나고 있는 일에 대한 배경 정보를 조금 더 얻을 수 있습니다. […]”

탐색경로 구조화된 데이터 구현

39:56 “구조화된 탐색경로 데이터의 경우 방문자가 페이지에서 보게 되는 탐색경로와 정확히 동일해야 합니까? 구조화된 데이터는 완전한 이동 경로 경로인 반면 페이지에는 압축된 버전의 이동 경로가 표시되는 경우가 있습니다. 둘 다 허용 가능한 옵션입니까?”

John이 말했듯이 "[...] 구조화된 데이터가 페이지에 표시되는지 여부를 인식하려고 합니다. 그리고 그것이 [...]가 아니라면, 우리는 “이것을 검색 결과에 표시하는 것이 여전히 의미가 있습니까? "

페이지에 이동 경로의 더 짧은 버전을 표시하는 것과 같은 작업을 수행하고 있는데 일치시킬 수 없는 경우 이동 경로 마크업을 실제로 선택하여 사용하면 약간의 성공을 거둘 수 있습니다.

개별 빵 부스러기 또는 […] 이동 경로 목록의 개별 항목을 선택하고 전체가 아니라 일부만 표시하는 경우 해당 항목만 선택할 수 있습니다. 이동 경로 일치 항목이 많이 […] 있기 때문에 나머지는 선택해야 할 수도 있습니다.

다른 종류의 구조화된 데이터와 유사한 페이지에 표시하지 않는 경우 보유하고 있는 전체 탐색경로 마크업을 선택하여 사용할 수 있다는 보장은 없습니다 .

내 생각에 주요 예외는 [...] FAQ 마크업으로, 질문과 답변이 있습니다. 여기서 [...] 중요한 부분은 질문이 실제로 표시되고 답변이 축소된 섹션과 같을 수 있다는 것입니다. 페이지이지만 […] 최소한 볼 수 있어야 합니다.”

웹사이트의 일부 페이지만 번역

44:00 “영어로 된 색인 페이지가 300개 미만인 사이트를 운영합니다. 이 페이지의 약 절반을 스페인어로 번역하려고 합니다. 이 페이지는 /ES와 같은 동일한 도메인의 하위 디렉토리에 배치되고 영어 콘텐츠의 대체 언어 버전으로 태그가 지정됩니다. 페이지 콘텐츠의 일부만 번역해도 될까요? 아니면 영어 웹사이트를 정확히 반영하고 다른 위치에서 순위를 매길 수 있는 가장 좋은 기회가 되도록 모든 것을 번역해야 합니까?”

John은 다음과 같이 말했습니다: “ 웹사이트의 일부 페이지를 번역하는 것만으로도 충분합니다. 우리는 페이지의 언어를 개별적으로 봅니다. 스페인어 페이지가 있는 경우 누군가 스페인어로 검색할 때 해당 스페인어 페이지만 봅니다. '여기에는 스페인어 페이지보다 영어 페이지가 훨씬 더 많습니다. 따라서 스페인어 사이트는 덜 중요합니다.' [...] 이것은 스페인어 페이지이며 스페인어로 순위가 매겨질 수 있습니다. [… ] 사용자의 경우 때때로 가능한 한 많은 콘텐츠를 번역하는 것이 합리적입니다. 그러나 일반적으로 이것은 시간이 지남에 따라 점진적으로 개선되는 것입니다. 여기서 일부 페이지로 시작하여 잘 현지화하고 더 많은 페이지를 추가합니다 [...].

hreflang 주석도 페이지별로 제공됩니다. 영어와 스페인어로 된 페이지가 있고 이를 링크하면 완벽합니다. 일부 페이지가 스페인어로만 되어 있다면 괜찮습니다. hreflang은 필요하지 않습니다. 일부 페이지는 영어로만 되어 있어도 괜찮습니다. 그런 면에서 합리적인 출발이라고 생각합니다.”

크롤링 예산 및 자동 생성된 URL

46:12 “내가 말하는 웹사이트는 워드프레스 웹사이트입니다. 여러 개의 원치 않는 URL을 자동으로 생성합니다. [...] 크롤러가 이러한 URL을 찾는 것을 중지할 수 있는 방법이 있습니까? 나는 그것을 'NOINDEX'할 수 있다는 것을 알고 있으며 그것들은 모두 인덱싱된 URL이 아닙니다. 하지만 검색 콘솔의 제외된 부분 아래에서 볼 수 있습니다. [...] 그것은 뉴스 웹사이트이고 수천 개의 URL을 가지고 있습니다. [...] 크롤링 예산에 영향을 미치나요?”

John은 웹사이트의 크기에 대해 물었고 URL이 5,000~10,000개 사이라고 들었습니다.

이를 감안할 때 John은 " 크롤링 예산에 대해 걱정하지 않을 것입니다. [...] 많은 페이지를 보통 며칠 안에 상당히 빠르게 크롤링할 수 있습니다. 다른 하나는 [...] 'noindex' 가 페이지의 메타 태그라는 것입니다. 메타 태그를 보려면 페이지를 크롤링해야 합니다. 즉, 'NOINDEX' 페이지를 확인하는 것을 피할 수 없습니다. [...] 페이지에 'NOINDEX'가 있는 경우 일반적으로 시간이 지남에 따라 해당 페이지를 덜 자주 크롤링합니다. 우리는 때때로 다시 확인하지만 그렇지 않으면 색인이 생성되는 일반 페이지만큼 많이 확인하지 않습니다. 다른 접근 방식은 robots.txt를 사용하는 것입니다. robots.txt 파일을 사용하면 해당 페이지의 크롤링을 완전히 차단할 수 있습니다. 단점은 때때로 URL 자체가 페이지의 콘텐츠가 아니라 검색 결과에서 인덱싱될 수 있다는 점입니다 […].”

John은 또한 다음과 같은 예를 들었습니다.

"[...] 축구 뉴스 웹사이트가 있고 차단된 기사와 크롤링이 허용된 기사가 있는 경우 누군가 축구 뉴스를 검색하면 페이지의 색인 생성 가능한 버전을 찾을 수 있습니다. robots.txt에 의해 차단된 다른 페이지가 있다는 것은 중요하지 않습니다. 그러나 누군가가 차단된 페이지에 대해 명시적으로 사이트 쿼리를 수행하면 검색 […]에서 해당 URL을 볼 수 있습니다. 귀하와 같은 상황에서는 [...] 크롤링 예산에 대해 걱정하지 않을 것입니다.”

John은 또한 다음과 같이 덧붙였습니다. “ 실용적인 관점에서 'noindex'와 robots.txt는 둘 다 일종의 동등물이 될 것입니다. [...] 이 콘텐츠는 검색 결과에 나타나지 않을 수 있으며 'NOINDEX'가 있는 경우 여전히 크롤링해야 하지만 숫자가 너무 작아서 중요하지 않습니다. robots.txt […]에 의해 차단된 경우 URL로 색인을 생성할 수 있습니다.”

선호하는 방법과 관련하여 John은 다음과 같이 말했습니다. […] WordPress가 있고 게시물에 '이 페이지의 NOINDEX'라는 확인란만 있으면 가장 쉬운 방법일 것입니다.

매개변수가 있는 URL 크롤링

54:25 “로그 파일에서 볼 수 있고 IEP를 통한 Googlebot이라는 것도 증명하고 있습니다. 유기 봇에서 UTM 매개변수 URL, Google 디스플레이 및 범용 앱 캠페인으로의 많은 크롤링이 있습니다. [...] 우리는 어디에서나 해당 URL로 연결되는 링크를 볼 수 없습니다. [...] 이런 일이 어디서, 왜 일어나는지 알고 있습니까?”

John은 "Googlebot을 사용하여 광고 캠페인 [...]에 나열한 페이지도 크롤링하는 한 곳은 제품 검색입니다. 제품 검색 피드 또는 판매자 센터 피드 [...]가 설정되어 있는 경우 Googlebot이 해당 페이지를 크롤링하여 판매자 센터에서 해당 페이지를 선택할 수 있는지 확인합니다. 거기에 태그가 지정된 URL이 있는 경우 […] 태그가 지정된 URL을 유지하고 다시 처리합니다.

또한 다른 사람들이 이런 종류의 제품을 제출할 수 있을 수도 있습니다. […] 제출하는 사람이 반드시 귀하가 아닐 수도 있지만 귀하를 대신하여 일하거나 그렇게 할 수 있는 권한이 있는 사람일 수도 있습니다.

어딘가에서 이러한 페이지에 대한 링크를 찾으면 크롤링을 시도합니다. 웹사이트 내에서 내부 링크에 태그를 지정한 경우에도 이를 선택하여 크롤링하려고 합니다. 이 매개변수가 있는 추적 URL이 어딘가에 설정되어 있고 JavaScript를 처리할 때 해당 추적 URL에 대한 링크인 것처럼 보이는 JavaScript에 설정한 항목이 있는 경우에도 처리할 수 있습니다. [...] 개별 사례가 아니라 [...] 많은 수의 이러한 URL처럼 들리며, 이는 판매자 센터 측면과 매우 흡사합니다.”