SEO 업무 시간 – 2021년 10월 8일

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

인덱싱된 페이지 수와 사이트 권한

03:52 “그래서 당신은 과거에 여러 번 큰 사이트 […]가 더 작은 페이지 집합에 초점을 맞추는 […] 내가 지금 작업하고 있는 사이트에는 트래픽이 전혀 발생하지 않는 오래된 페이지가 […] 있으므로 제거하는 것이 좋습니다. 그러나 Google 개발팀이 Google이 귀하의 사이트에 대해 색인을 생성한 페이지가 많을수록 사이트에 더 높은 권한을 부여하고 페이지를 제거하는 데 주저한다는 인상을 받고 있다는 질문이 있습니다. 그것에 대해 좀 밝혀 주시겠습니까?”

John이 말했듯이 “인덱싱된 페이지가 더 많다고 해서 귀하의 웹사이트가 더 나은 것은 아닙니다. [...] 때로는 많은 페이지를 인덱싱하는 것이 합리적입니다. 때때로, 그것들은 그런 식으로 인덱싱되는 일종의 유용한 페이지입니다. 그러나 인덱싱된 페이지 수와 관련하여 품질의 표시가 아닙니다. 그리고 특히 […] 1,000, 2,000, 5,000 페이지에 대해 이야기하는 경우 일반적으로 우리 시스템에서는 매우 적은 수입니다. 5,000페이지가 1,000페이지보다 낫다고 말하는 것이 아닙니다. 우리에게 그것은 작은 웹사이트와 같으며 우리가 거기에서 끌어낼 수 있는 일을 합니다. 물론 작은 웹사이트는 상대적입니다. 관련 없는 웹사이트라고 말하는 것과는 다릅니다. 작을 수 있지만 여전히 매우 유용할 수 있습니다[...]”.

웹사이트의 주요 목적 평가

10:03 “지난번에 우리는 웹사이트의 몇 가지 문제에 대해 이야기했습니다. […] – 그것은 정보와 거래가 있는 전자 상거래 웹사이트입니다. [...] 귀하의 조언은 이 콘텐츠를 트랜잭션 지향 페이지와 정보 지향 페이지로 조금 분리하는 것이었습니다. 그래서 이것에 대해 또 다른 질문이 있습니다. 예를 들어 전자 상거래 웹사이트가 있고 방대한 블로그나 잡지 또는 이와 유사한 정보 자료가 많이 있지만 오래된 섹션이 있다고 가정해 보겠습니다. 다른 한편으로는 이러한 모든 제품 페이지와 카테고리 등이 있습니다. 따라서 순수한 정보 자료가 포함된 이 거대한 블록은 전체 웹사이트에 정보 제공 또는 특성을 부여하여 Google에서 "오, 이것이 […] 사람들이 물건을 사는 것보다 정보를 얻을 수 있는 곳인지, 아니면 이 평가는 페이지 단위로 수행됩니까?”

John은 다음과 같이 말했습니다: “[...] 내 이해는 이것이 페이지 수준에 가깝다는 것입니다. [...] 많은 웹 사이트에는 다양한 종류의 콘텐츠가 혼합되어 있습니다. 그런 다음 이러한 페이지 중 검색자의 의도와 일치하는 페이지를 파악하고 해당 페이지의 순위를 적절하게 지정하려고 합니다. […]

뉴스 웹사이트에서 자주 볼 수 있습니다. [...] 최근 이벤트가 있지만 발생한 이전 이벤트에 대한 섹션도 있습니다. [...] 다른 큰 이벤트의 경우 격리된 아카이브 섹션이 있습니다. 그리고 그것들은 매우 다른 의도입니다. 당신이 정말로 지금 일어나고 있는 무언가를 원하거나 정보 연구, 상록 유형의 콘텐츠를 원하는 경우입니다.

[...] 우리는 페이지 단위로 그것을 보아야 하고 , 여기에 약간의 연구 콘텐츠가 있기 때문에 이것이 연구 웹사이트라고 말하지 않아야 합니다.”

링크 리디렉션

13:21 “사람들이 […] 페이지의 하위 범주에 연결하는 것을 보고 있습니다. 그리고 문제는 […] 우리의 콘텐츠가 왔다가 사라진다는 것입니다. 즉, 때로는 일부 범주에 더 많은 콘텐츠가 표시된다는 의미입니다. 간혹 내용이 삭제되는 경우가 있습니다. 따라서 하위 범주가 생성될 수도 있고 사라질 수도 있습니다. 그리고 우리는 더 이상 존재하지 않는 하위 카테고리에 연결되기 때문에 백링크에서 많은 추천을 보고 있습니다. 제 질문은 다음과 같습니다. 이 링크를 상위 카테고리로 리디렉션 [...]해도 됩니까? 그리고 그렇게 하면 어떻게 합니까? 예를 들어 302로? 임시 리디렉션과 마찬가지로 미래에 이 하위 범주에 콘텐츠가 다시 채워질 수 있기 때문에 [...] 영구적인 리디렉션이 아닙니다.”

John은 다음과 같이 대답했습니다. “따라서 상위 수준으로 리디렉션하는 더 큰 규모로 이러한 일이 발생하는 것을 본다면 아마도 이를 소프트 404로 볼 수 있을 것입니다. […] 그리고 404 코드 대신 리디렉션하고 있을 수 있습니다. 사용자에게는 더 좋지만 우리는 그것을 404로 봅니다. [...] 사용자 관점에서 리디렉션하는 것이 합리적이라면 그냥 사용하겠습니다.

[...] 301 또는 302와 관련하여 나는 그것이 중요하지 않다고 생각합니다. 왜냐하면 이것을 소프트 404로 보거나 정규화 질문으로 볼 것이기 때문입니다. 소프트 404라면 코드는 중요하지 않습니다. 정규화 질문인 경우 검색 결과에 표시되는 URL이 결정됩니다. 그리고 일반적으로 더 높은 수준의 신호는 어쨌든 더 강한 신호를 가지며 우리는 더 높은 수준의 신호에 집중할 것입니다. 따라서 301인지 302인지는 중요하지 않습니다.

[...] 소프트 404로 표시되면 [...] 여기에 아무 것도 없기 때문에 해당 특정 URL의 크롤링 속도가 느려집니다 [...]. 리디렉션 [...]으로 표시되는 경우 기본 URL에 초점을 맞추기 때문에 이를 매일 크롤링할 필요가 없습니다. 따라서 두 경우 모두 실제로 이것이 다시 새로운 것일 수 있다는 새로운 신호를 얻을 때까지 해당 URL의 크롤링 속도를 늦출 것이라고 생각합니다. [...] 내부 링크나 사이트맵 파일 [...]과 같습니다. 그리고 그것은 우리가 다시 기어야 한다는 더 강한 신호가 될 것입니다. 하지만 크롤링 속도가 느려지는 것은 이 모든 경우에 비슷할 것이라고 생각합니다.

[...] 사이트 맵을 [업데이트]하는 것만으로는 충분하지 않다고 생각합니다. 내부 연결도 명확하게 하도록 하겠다 ”고 말했다.

핵심 업데이트에서 복구

18:34 “그래서 약 1년 전에 트래픽이 상당히 감소했습니다. 감사 후 […] 모든 신호는 사이트 품질 문제가 있는 사이트를 가리켰습니다. 우리는 올해 2월까지 이러한 문제를 해결할 수 있었습니다. 그리고 6월 핵심 업데이트까지 약간의 증가를 보았습니다. 하지만 약 1년 전 감소했던 수준은 아직 아니다. 그래서 제 질문은 사이트 품질 문제입니다. 이 경우 복구를 기대할 수 있습니까, 아니면 식별된 모든 문제를 해결했다고 생각하는 경우 더 많은 복구를 기대할 수 있습니까? [...]”

John은 다음과 같이 말했습니다: “[...] 우리가 그것을 당신이 뭔가를 고쳐야 하는 상황으로 생각하는 것은 그리 많지 않습니다. 그러나 오히려 […] 웹사이트의 관련성을 개선하기 위해 노력한다면 […] 더 나은 웹사이트를 갖게 됩니다. 따라서 [...] 이전 상태로 다시 변경하지 않습니다. [...] 이전과 같지 않거나 비교할 수 없으므로 이전 상태로 변경될 것으로 예상하는 것은 다소 까다롭습니다 [...].

[...] 핵심 업데이트를 통해 우리는 개별 문제에만 초점을 맞추지 않고 웹사이트 전체의 관련성에 중점을 둡니다 . 여기에는 유용성, 페이지의 광고 등이 포함될 수 있지만 본질적으로 웹사이트 전체입니다. 그리고 일반적으로 이는 콘텐츠의 초점, 콘텐츠를 제시하는 방식, 콘텐츠 이면에 있는 내용, 출처가 무엇인지 […] Google이 귀하의 웹사이트를 훨씬 더 나은 웹사이트로 보기를 정말로 원한다면 콘텐츠 측면에서도 작업해야 할 것입니다 .

[...] 사용자가 내 웹사이트를 방문할 때 혼동을 일으킬 수 있는 저품질 콘텐츠가 있는 위치를 생각해 보십시오. 그리고 그 혼란이 UX 변경과 함께 기술적인 문제로 해결할 수 있는 것입니까? 아니면 실제로 우리가 제시하는 콘텐츠의 일부를 변경해야 합니까?”

게스트 게시물의 링크

28:24 “[…] […] [웹사이트에] 게스트 게시물이 있고 Google에서 유료인지 여부를 모르는 경우 Google은 이 링크를 가져갈지 아니면 이 링크를 태워야 하는지 어떻게 결정할까요? 우리가 모든 각도에서 안전하기 위한 답은 무엇입니까?”

John에 따르면, “[...] 링크 및 게스트 게시물에 대한 지침은 팔로우 금지 . [...] 나는 당신이 인지도를 높이고, 당신이 하고 있는 일에 대해 이야기하고, 사용자가 당신의 페이지. 그러나 본질적으로 이것은 귀하의 비즈니스를 위한 광고입니다. 그런 관점에서 보면, 나는 그들을 팔로우하지 않도록 할 것입니다.”

순위 요소로서의 제품 가격

32:25 “정확히 동일한 제품을 판매하는 두 개의 경쟁 전자 상거래 사이트가 있는 경우 – 한 웹사이트는 제품을 $500에 제공하고 다른 웹사이트는 $100에 제공하며 모든 SEO 신호는 동일합니다. 똑같은 제품이라도 가격차이가 나기 때문에 더 저렴한 웹사이트가 순위를 매길 확률이 더 높을까요?”

John은 다음과 같이 말했습니다. 페이지에서 가격을 인식하고 이를 순위 요소로 사용하려는 경우는 아닙니다. 따라서 우리가 더 저렴한 것을 선택하고 더 높은 순위를 매길 것이라고 […]

그러나 이러한 제품 중 상당수가 일종의 제품 검색 결과로 표시되기도 합니다. 이는 귀하가 피드를 제출하거나 이러한 페이지에서 제품 정보를 인식하기 때문일 수 있습니다. 그리고 상품검색 결과는 어떻게 주문하는지 모르겠네요. 그들은 가격이나 가용성과 같은 것을 고려할 수 있습니다 [...].

따라서 웹 검색의 관점에서 우리는 가격을 고려하지 않습니다. 상품검색의 관점에서는 가능합니다 . 그리고 까다로운 부분은 SEO이기 때문에 검색의 이러한 다양한 측면이 종종 하나의 검색 결과 페이지에 결합되어 일반적인 웹 결과를 볼 수 있고 측면에 일부 제품 결과가 표시될 수도 있습니다. 당신은 그 혼합을 볼 수 있습니다 [...]”.

사이트맵 간 URL 이동

34:04 “200개의 사이트맵 파일이 있고 URL의 20~30%가 매주 한 파일에서 다른 파일로 이동한다면 얼마나 나쁠 수 있습니까? 아니면 영원히 같은 파일에 URL을 엄격하게 보관해야 합니까?”

“[…] 일반적으로 동일한 사이트맵 파일에 동일한 URL을 유지하는 것이 좋습니다 . 그 주된 이유는 사이트맵 파일을 다른 속도로 처리하기 때문입니다. 따라서 한 사이트맵 파일에서 다른 URL로 하나의 URL을 이동하는 경우 여러 사이트맵 파일의 동일한 URL이 시스템에 있을 수 있습니다. 예를 들어 다른 변경 날짜와 같이 이 하나의 URL에 대해 다른 정보가 있는 경우 실제로 사용할 속성을 알 수 없습니다.

따라서 이러한 관점에서 항상 동일한 사이트맵 파일에 파일이 있으면 오, 이 URL에 대한 정보가 여기에 있고 거기에만 있기 때문에 해당 정보를 신뢰할 수 있다고 말하는 것이 훨씬 쉽습니다. 그래서 저는 이러한 URL이 무작위로 섞이는 것을 피하려고 […] 그러나 동시에 일반적으로 사이트맵 파일 처리가 중단되지는 않습니다. 그리고 그것은 확실히 귀하의 웹사이트에 순위 영향을 미치지 않을 것입니다. 따라서 우리 사이트맵 시스템에는 웹사이트의 품질에 매핑되는 것이 없습니다 .

다지역 콘텐츠

38:13 “저는 뉴스 카테고리에서 일합니다. 우리 팀은 국제적 입지를 확장하기 위해 노력하고 있으며 다중 지역 하위 디렉토리를 설정하는 작업을 완료했습니다. 대부분의 경우 여러 지역 에디션의 페이지는 동일하게 보입니다. 정치나 라이프스타일과 같은 홈페이지 및 섹션 페이지는 지역 고유의 몇 가지 부분을 제외하고 유사한 콘텐츠를 갖습니다.

기사가 까다롭습니다. 관련 링크가 있는 모듈 외부의 다중 지역 하위 디렉토리에서 구분할 수 있는 부분이 많지 않기 때문에 중복 콘텐츠 문제가 걱정됩니다. Google은 뉴스 공간의 중복 콘텐츠를 어떻게 처리합니까? [...] 내용은 동일하게 유지되지만 템플릿의 요소는 다릅니다. 모든 다중 지역 웹사이트에서 표준이 하나만 있어야 합니까?”

John의 응답은 다음과 같습니다. “[...] 이것은 같은 국가 내에서 다른 지역으로 들리며 동일한 언어 내용입니다. [...] 국가가 다른 경우 지역 타겟팅 측면이 있으며 이는 언어가 다른 경우 역할을 합니다. 예를 들어 유럽에서 일하고 독일, 프랑스, ​​이탈리아 등을 다루고 있다면 언어도 다릅니다.

[...] 그러나 동일한 국가 내에서 동일한 언어 콘텐츠에 대해 이야기하는 경우 [...] 이러한 모든 기술 연결에 대해 걱정할 필요가 없기 때문에 조금 더 쉽습니다. 그러나 다른 한편으로는 중복 콘텐츠 문제가 훨씬 더 눈에 띕니다. 콘텐츠 복제와 관련하여 이와 같은 사이트의 까다로운 측면은 결국 결국 자신과 경쟁하게 된다는 것입니다. 5개 또는 6개의 다른 지역 웹사이트에 게시하는 뉴스 기사가 하나 있는 경우 이 모든 지역 웹사이트는 정확히 같은 기사에 대한 순위를 매기려고 합니다. 그리고 그 결과 해당 기사의 순위가 좋지 않을 수 있습니다.

따라서 이러한 개별 기사에 대한 표준 URL을 찾는 것이 좋습니다. 그러면 '글쎄요, 제 5개 지역 웹사이트에 이 기사가 하나 있습니다. 검색'. 그리고 나서 우리는 우리의 모든 에너지와 모든 신호를 선호하는 버전에 집중할 수 있고 그 버전을 조금 더 잘 순위를 매길 수 있습니다. 항상 같은 버전일 필요는 없습니다. 따라서 한 지역에 있는 하나의 뉴스 기사가 정규화된 경우일 수 있습니다. 다른 뉴스 기사는 다른 지역에 대해 더 정규화된 것입니다. 표준으로 선택하는 지역을 선택하는 방법은 전적으로 귀하에게 달려 있습니다. [...] 일반적으로 가장 관련성이 높은 위치를 파악하고 표준 버전으로 선택합니다. 개별 기사 자체에 대한 것입니다.

카테고리, 섹션, 홈 페이지의 경우 콘텐츠가 더 독특하고 개별 지역에 더 구체적인 것이 될 것 같습니다. 그리고 그 때문에 인덱스 수준을 별도로 유지하려고 합니다. 따라서 5개의 서로 다른 지역 웹사이트, 홈 페이지, 카테고리 섹션이 있는 경우 모두 개별적으로 색인이 생성됩니다. 그리고 뉴스 기사 자체는 이러한 다른 지역 중 하나로 매핑됩니다. 그래서 우리가 거기에서 권장하는 접근 방식입니다 [...].

그리고 이 접근 방식은 […] 다른 도메인 이름에서도 작동합니다. 따라서 개별 지역에 대해 다른 도메인이 있지만 모두 동일한 뉴스 그룹의 일부인 경우에도 다른 버전 간에 이 표준 이동을 수행할 수 있습니다. 하위 디렉토리가 있는 동일한 도메인 내에서 수행하는 경우에도 괜찮습니다."

사이트 이동 시 리디렉션

44:34 “모든 URL을 새로운 URL 세트로 리디렉션해야 할 때 취해야 할 가장 좋은 조치는 무엇입니까? 페이지 수가 100만 개가 넘는데 샌드박스 효과를 최소화하고 싶으신가요? 샌드박스 효과가 있다면 얼마나 오래 지속될 수 있습니까? 절대 회복할 수 없는 순위를 잃게 될까요? 일대일 리디렉션을 계획하고 일괄 리디렉션을 요청했지만 그럴 가능성이 없으므로 페이지, 이미지, URL 등이 동시에 뒤집혀야 합니다."

John은 다음과 같이 말했습니다. “나에게 이것은 전통적인 사이트 이동 상황처럼 들립니다. 한 도메인에서 다른 도메인으로 이동하고 이전 사이트의 모든 URL을 새 사이트로 리디렉션하며 […] 사이트 이동과 관련하여 우리 측에서 샌드박스 효과로 정의된 것은 없습니다 . 따라서 사이트를 이동해야 하는 경우 사이트를 이동하고 모든 페이지를 리디렉션합니다. 가장 쉬운 방법은 모든 페이지를 한 번에 리디렉션하는 것입니다. 우리 시스템은 또한 그것을 인식하기 위해 약간 조정됩니다. 따라서 웹사이트에서 모든 페이지를 다른 웹사이트로 리디렉션하기 시작 하면 해당 사이트 이동을 최대한 빨리 처리할 수 있도록 조금 더 빠르게 재처리하려고 합니다. 그리고 우리가 "오, 그들은 사이트 이동을 하고 있으므로 속도를 늦출 것입니다[...]"라고 말할 경우가 아닙니다."

API 및 크롤링 예산

46:13 “데이터를 얻기 위해 클라이언트 측에서 API에 연결하는 웹사이트가 있습니다. 해당 URL이 크롤링 예산에 포함됩니까? 해당 URL을 허용하지 않으면 [...] 문제가 발생합니까?”

"[...] 이러한 API가 페이지가 렌더링될 때 포함된다면 예, 크롤링에 포함될 것이며 기본적으로 페이지를 렌더링하기 위해 해당 URL을 크롤링해야 하기 때문에 크롤링 예산에 포함됩니다. 크롤링되지 않거나 렌더링 중에 사용되지 않으려면 robots.txt로 차단할 수 있습니다. 당신이 그것을 선호한다면 전적으로 당신에게 달려 있습니다. 특히 유지 관리에 비용이 많이 들거나 많은 리소스를 사용하는 API가 있는 경우 때때로 그것이 의미가 있습니다.

까다로운 부분은 API 엔드포인트의 크롤링을 허용하지 않으면 인덱싱을 위해 API 반환에 대한 데이터를 사용할 수 없다는 것입니다. 따라서 페이지 콘텐츠가 순수하게 API에서 제공되고 API 크롤링을 허용하지 않는 경우 해당 연락처가 없습니다. [...] API가 페이지에 있는 지도나 [...] 페이지에 있는 숫자 테이블의 그래픽을 그리는 것과 같이 페이지를 보완하는 작업을 수행하는 경우 [...] 해당 콘텐츠가 인덱싱에 포함되지 않습니다. 다른 점은 때때로 API가 차단되었을 때 페이지가 어떻게 작동하는지가 중요하지 않다는 것입니다. 특히 자바스크립트를 사용하는데 robots.txt 때문에 API 호출이 차단된다면 어떻게든 그 예외를 처리해야 한다. 그리고 페이지에 JavaScript를 포함하는 방법, API로 수행하는 작업에 따라 여전히 작동하는지 확인해야 합니다. 따라서 해당 API 호출이 작동하지 않고 페이지의 나머지 렌더링이 완전히 중단되면 렌더링할 항목이 남아 있지 않기 때문에 색인을 많이 생성할 수 없습니다.

그러나 API 호출이 중단되고 페이지의 나머지 부분을 계속 색인화할 수 있다면 완벽할 수 있습니다. [...] 다른 사람을 위해 API를 실행하는 것이 더 까다롭다고 생각합니다. 크롤링을 허용하지 않으면 다른 사람의 웹사이트가 귀하의 API에 의존할 수 있는 2차 효과가 발생할 수 있기 때문입니다. API가 하는 일에 따라 갑자기 웹 사이트에 색인 생성 가능한 콘텐츠가 없습니다. 그리고 그들은 갑자기 당신이 거기에 허용하지 않음을 추가했다는 것을 알지 못하기 때문에 눈치채지 못할 수도 있습니다. 그리고 그것은 일종의 간접적인 효과를 일으킬 수 있습니다[…].”

자바스크립트와 구글 캐시

49:36 “그래서 같은 도메인에서 시작된 두 페이지가 있습니다. URL은 약간 다르며 동일한 디렉토리 구조의 일부입니다. 그리고 […] 그것들은 NextJS에 의해 생성됩니다. 따라서 NextJS는 서버 측 렌더링된 반응 프레임워크입니다. 그리고 색인이 생성되고 있지만 Google 캐시에 한 페이지가 있고 두 번째 페이지는 Google 캐시에 없습니다. 그리고 페이지를 생성하는 방법에 관계없이 동일한 패턴을 봅니다[...]. 내 페이지의 대부분은 Google 캐시에 있지만 현재 이러한 모든 페이지를 생성하는 Java 기반 기술 스택에서 Google NextJS로 이동하고 있기 때문에 걱정이 됩니다. [...] 디버깅할 때 이것이 우리가 사용하고 있던 이전 Java 스택에도 문제가 있음을 발견했습니다.

그래서 질문은 두 부분입니다. 기본적으로 왜 이런 행동을 합니까? 두 번째는 이 행동이 내 순위에 영향을 미칩니까? Google 캐시에 없는 검색 결과에 해당 페이지가 표시됩니다."

John은 다음과 같이 대답했습니다. “[...] 캐시 페이지는 우리가 인덱싱하는 페이지와 완전히 분리되어 있습니다. 따라서 캐시 페이지가 있든 없든 순위는 전혀 중요하지 않고 인덱싱에는 전혀 중요하지 않습니다 . 때때로 캐시 페이지가 없는 기술적인 이유가 있습니다. 때로는 개별 URL에 대한 캐시 페이지가 없습니다. 다른 하나는 페이지가 JavaScript 프레임워크를 사용하는 경우 캐시 페이지가 Google 도메인에서 호스팅되기 때문에 JavaScript가 캐시 페이지에서 실행되는지 여부가 까다롭습니다. 가지고 있는 JavaScript의 종류, JavaScript 파일을 가져오는 위치에 따라 Google 도메인에서 JavaScript를 실행할 수 없는 경우가 있습니다.

[...] 캐시 페이지가 렌더링된 페이지가 아닙니다. 본질적으로 우리가 요청한 HTML 파일과 그 사본입니다. HTML 파일에 무언가가 표시되면 괜찮습니다. JavaScript를 사용하고 JavaScript가 캐시 페이지이기 때문에 실행되지 않는 경우에도 마찬가지입니다. 캐시 페이지에서 볼 수 없습니다. 따라서 캐시 페이지가 표시되지 않아도 걱정할 필요가 없습니다. 그것은 어떤 문제의 징후가 아닙니다. 그리고 종종 [...] 캐시 페이지가 있는지 여부를 제어할 수 없습니다. 그냥 무시하겠습니다."

https://www.youtube.com/watch?v=Vd0rEQrwHDc