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

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

robots.txt 파일의 크기

00:45 "거대한 robots.txt로 인해 발생할 수 있는 부정적인 SEO 효과가 있습니까?"

John은 "직접적으로 부정적인 SEO 문제는 없습니다. 하지만 유지하기가 훨씬 더 어렵습니다. 그리고 문제를 일으키는 것을 실수로 푸시하기가 훨씬 쉬워집니다. 파일이 크다고 해서 문제가 되는 것은 아니지만 문제를 만들기가 더 쉬워집니다." […]

04:35 “[robots.txt 파일]을 근본적으로 줄이는 것 외에 [그것]을 구축하기 위한 지침이 있습니까?”

존: “아니요, 그것은 본질적으로 당신에게 달려 있습니다. 일부 사이트에는 대용량 파일이 있습니다. 일부 사이트에는 작은 파일이 있습니다. 그들은 모두 작동해야합니다. 우리는 우리가 사용하는 robots.txt 파서의 오픈 소스 코드를 가지고 있습니다. 따라서 개발자가 해당 파서를 실행하거나 테스트할 수 있도록 설정하도록 할 수도 있습니다. 그런 다음 해당 파서로 웹사이트의 URL을 확인하여 차단될 URL과 변경될 URL을 확인합니다. 그렇게 하면 라이브로 만들기 전에 테스트할 수 있습니다."

또한 SEO를 위한 Robots.txt에 대한 궁극적인 가이드 에서 robots.txt 파일에 대한 자세한 정보를 찾을 수 있습니다 .

제품 카테고리를 새 도메인으로 마이그레이션

08:56 “다중 공급업체라는 하나의 제품 범주를 새 도메인이나 하위 도메인으로 이동할 계획입니다. [...] 새 도메인의 순위를 매기는 방법은 무엇입니까? 현재 도메인은 Google 및 기타 검색 엔진에서 좋은 순위를 기록하고 있으며 우수한 유기적 검색 트래픽을 제공합니다. 새 도메인이 현재 수신 중인 트래픽 양을 수신하는 데 얼마나 시간이 걸리나요?”

John은 이렇게 대답 했습니다. “ 당신이 한 도메인에서 다른 도메인으로 이동하지 않는 것처럼 들리기 때문에 그 변경에 대해 정해진 시간이 없다고 생각합니다 . 한 인프라에서 다른 인프라로 이동하고 있습니다. 그리고 종종 이는 콘텐츠가 다를 것임을 의미합니다. 페이지 구조, 심지어 URL도 다를 수 있습니다. 그 모든 것이 바뀔 수 있습니다. 그리고 이 모든 것들이 처리되는 데 시간이 걸리는 요소입니다. 얼마나 걸릴지는 웹사이트에 따라 다릅니다. 그리고 당신이 그것에 대한 특정 일정을 가질 수 있다는 것이 아닙니다.

또한 염두에 두어야 할 다른 부분은 이러한 변경이 웹사이트에 전반적으로 긍정적이거나 부정적인 영향을 미칠 수 있다는 것입니다. 따라서 이러한 종류의 마이그레이션을 수행할 수 있으며 SEO도 작업하고 페이지의 상호 연결, URL 구조 및 페이지의 HTML 형식을 개선할 것입니다. 이 모든 것이 귀하의 웹사이트에 매우 긍정적인 영향을 미칠 수 있습니다.

그러나 동시에 이러한 것들을 주의하지 않고 갑자기 URL이 엉망이 되고 HTML이 검색 엔진에서 쉽게 이해되지 않는다면 부정적인 영향을 미칠 수 있습니다. 따라서 전자 상거래 상점을 한 플랫폼에서 다른 플랫폼으로 마이그레이션하는 경우 일정 시간이 지나면 다른 플랫폼에서도 동일할 것이라고 가정해서는 안 되는 부분입니다. 비슷하거나 훨씬 더 좋을 수 있지만 훨씬 더 나쁠 수도 있습니다. 따라서 이러한 모든 세부 사항을 주의 깊게 살펴보고 원하는 최종 구조가 무엇인지, 해당 마이그레이션에 포함하려는 SEO 요소가 무엇인지 생각해야 합니다.”

11:45 "해당 인프라를 새로운 영역으로 이전할 때 어떤 부정적인 측면에 직면하게 될까요?"

John에 따르면 "[...] 일반적으로 모든 것이 잘 정렬된 상황에서 발생하는 상황은 시간이 지남에 따라 새로운 웹사이트에 대해 알게 될 때부터 모든 것을 바꿀 때까지 약간의 변동을 볼 수 있습니다. 그리고 그것은 검색에서 가시성이 다소 떨어질 것이라고 가정하는 것입니다. 그러나 거기에서 수행하는 모든 변경 사항에 따라 다르며 훨씬 더 오래 걸릴 수 있습니다. 또한 최종 결과가 이전보다 훨씬 더 나 빠지거나 훨씬 더 나은 결과가 나올 수도 있습니다.”

앱 리디렉션

20:38 “ 앱과 같은 사이트 페이지 도구에서 사용자를 리디렉션할 때의 위험이 무엇인지 아십니까? SEO 관점에서 트래픽에 부정적인 영향을 미칩니까? […] 우리 앱은 [모바일 버전보다] 전환율이 더 높기 때문에 일부 사용자가 일부 제품 페이지나 카테고리 페이지를 방문할 때 [...] 앱이나 앱 스토어로 리디렉션할 수 있다고 생각합니다. 더 높은 전환율에 기여할 수 있을까요?”

John의 대답은 다음과 같습니다. “전반적으로 그렇게 할 수 있다고 생각합니다. 내가 일반적으로 여기서 주의할 점은 사용자가 원할 경우 앱으로 이동할 수 있는 방식으로 수행한다는 것입니다. 현재로서는 앱과 웹페이지 간의 연결에 대해 자세히 알지 못하지만 사용자가 앱을 설치한 것으로 인식할 수 있는 스마트 배너를 만드는 방법이 있다고 생각합니다. , 거기에서 앱 경험으로 이동하는 것은 매우 쉽습니다. 하지만 안드로이드와 아이폰에 대한 구체적인 내용은 모릅니다. […]

일반적으로 검색의 관점에서 개별 모바일 페이지, 데스크톱 페이지 또는 거기에서 사용할 수 있는 모든 항목을 색인화할 수 있다면 완벽합니다. 그리고 귀하의 페이지에 있는 사람들이 결국 앱으로 이동하는 경우에도 저희 관점에서는 완벽하게 괜찮습니다."

22:57 “당신은 사이트 페이지의 상단 배너에 대해 이야기하고 있습니다. 아마도 우리가 [강제로] 리디렉션하면 SEO나 사이트에 좋지 않을까요?”

존은 “아마 괜찮을 것 같다. 내 머리 속에는 두 가지가 있는데, 그것은 조심해야 할 것입니다.

Googlebot은 Android 사용자 에이전트도 사용하므로 앱을 설치하지 않으므로 Googlebot을 앱 스토어나 앱으로 리디렉션하지 않도록 해야 합니다. 한 가지입니다. 다른 하나는 특히 핵심 성능 향상 관련 메트릭과 관련이 있습니다. 항상 앱을 통해 직접 모바일 사용자를 리디렉션하는 경우 핵심 성능 평가에 대한 데이터가 많지 않습니다. 사이트에 따라 […] 또한 염두에 두어야 할 사항입니다. 하지만 […] 사용자를 앱으로 리디렉션하는 경우 SEO 관점에서 부정적인 것은 없다고 생각합니다. 사용성 관점에서 보면 선택 사항으로 만드는 것이 훨씬 좋습니다. 그러나 궁극적으로 그것은 당신과 당신의 사용자 사이에 있습니다.”

Google에서 페이지의 유사성을 평가할 수 있습니까?

26:28 "Google은 페이지의 유사성을 어떻게 측정합니까?"

John은 “우리는 그렇지 않다고 생각합니다. 귀하의 관점에서 이러한 URL 중 어느 것이 동등한지 이해하기 위해 hreflang을 사용한다고 생각합니다. 그리고 우리는 그것들을 교환할 것입니다. […]

표준 URL이 무엇인지 이해하기 위해 rel=”canonical”과 같은 항목에 대해서만 그렇게 할 것입니다. 그러나 hreflang 의 경우 이 특정 콘텐츠가 다른 국가 또는 다른 언어와 동일하다는 것을 이해하는 것은 불가능하다고 생각합니다. 항상 가능한 많은 지역적 차이가 있습니다.”

스팸 백링크 확인

27:22 “우리는 큰 전자상거래 사이트이며 수백만 개의 백링크가 있습니다. 매달 또는 몇 달에 걸쳐 일부 스팸 백링크를 확인하는 표준 절차가 있습니다. Google Disavow 목록의 상한선은 2MB에 불과합니다. 우리 파일이 한도를 초과했는지 궁금합니다. 그런 다음 스팸 백링크를 처리하는 방법입니다. [...] 현재 우리가 발견한 대부분의 스팸 링크는 우리 사이트를 대상으로 하여 검색 페이지로 연결되는데, 이는 제게 매우 이상합니다.”

John은 "보통 한편으로는 같은 사이트에서 여러 항목을 저장 하고 모든 링크를 정리하는 데 너무 집중하지 않는 도메인 지시문을 가능한 한 많이 사용하는 것이 좋습니다. 그것은 항상 불가능하기 때문입니다. 나는 링크에 거부를 사용하는 데 집중할 것입니다. 여기서 링크를 보면 웹사이트 팀의 누군가가 이것을 보면 귀하가 구매했거나 여기에서 어떤 교환이 일어나고 있다고 100% 확신할 것이라고 생각합니다. 그러나 웹사이트가 받는 이러한 모든 종류의 임의 링크의 경우, 스팸성 페이지나 복사 페이지 또는 임의의 포럼 게시물에서도 이러한 것들은 거부 파일에 넣을 필요가 없습니다. […]

귀하의 상황이 이러한 경우인지는 모르겠지만 이전에 [이 링크]가 전화번호나 URL과 같은 항목을 포함하는 특정 검색어가 있는 검색결과 페이지를 대상으로 하는 것을 보았습니다. 번호가 검색 결과에 나타납니다. 그리고 검색 결과 페이지 또는 더 긴 쿼리가 포함된 검색 결과 페이지의 색인을 생성하지 않으면 자동으로 색인이 생성되지 않습니다.”

트래픽 감소와 AMP 페이지 제거

30:43 "AMP를 제거하면 트래픽이 감소해야 하나요?"

John: “전통적인 HTML 페이지와 AMP 페이지가 있고 이 페이지를 연결하는 설정이라고 가정합니다. 이렇게 AMP 페이지를 제거하면 세 가지가 합쳐지는 것 같아요.

한편, AMP 전용 페이지로 제한되는 일부 검색 기능이 있습니다. [… ] 다시 확인해야 하겠지만 현재로서는 AMP 페이지에서만 사용할 수 있는 검색 기능이 없는 것 같습니다. 따라서 그 관점에서 보면 아무것도 잃지 않을 것입니다.

다른 하나는 AMP 페이지가 매우 빠른 경향이 있거나 매우 빠른 AMP 페이지를 만드는 것이 더 쉽다는 것입니다. 그리고 우리는 순위 요소로 속도와 페이지 경험을 사용하기 때문에 AMP에 매우 빠른 페이지가 많고 AMP가 아닌 느린 페이지로 전환하면 거기에서 효과를 볼 수 있습니다. 물론 AMP가 아닌 매우 빠른 페이지도 만들 수 있습니다. AMP에 국한되지 않습니다. 그래서 Speed와 관련된 사항이 어떻게 적용되는지 확인하기 위해 다시 한 번 확인합니다.

그리고 세 번째는 […] AMP 페이지의 순위가 더 높다는 가정입니다. 그리고 그것은 사실이 아닙니다. AMP는 순위 요소가 아닙니다. 따라서 AMP 페이지가 있거나 AMP 페이지가 없다고 해서 순위가 ​​변경되어서는 안 됩니다. […]

일반 페이지가 빠르고 동등하며 해당 일반 페이지에 필요한 모든 구조화된 데이터가 있는지 확인할 수 있다면 AMP를 끌 수 있습니다. 그리고 그것은 본질적으로 매우 유사할 것입니다. 아마도 일부 AMP 페이지가 여전히 AMP 캐시에 있고 버블링되는 데 시간이 걸리는 과도기적 현상을 보게 될 것입니다. 그러나 일반적으로 이러한 기능을 끌 수 있습니다. AMP 페이지 끄기에 대한 도움말 센터 문서가 있으므로 그것도 다시 확인하겠습니다."

지식 패널

35:17 “최근 몇 달 동안 Google이 특정 이름 검색에 대해 모바일에서 매우 일관되게 지식 패널을 조사한 것을 확인했습니다. 동일한 검색어에 대해 데스크톱에서는 전혀 검색하지 않았습니다. [...] 이 상황에서 지식 패널이 모바일 사용자에게는 적합하지만 데스크톱 사용자에게는 적합하지 않은 것으로 간주되는 이유를 이해할 수 있습니까? 그리고 Google이 지식 패널을 표시할지 여부를 결정할 때 Wikipedia가 중요한 요소입니까?”

John은 “지식 패널과 관련하여 모바일과 데스크톱에서 다르게 수행되는 특정 작업을 알지 못합니다. 그러나 우리가 사용할 수 있는 부동산의 기기 유형에 따라 일부 기능을 켜고 일부 기능을 꺼서 원하는 것을 표시할 수 있도록 하는 것은 다양한 검색 기능에서 매우 일반적 입니다. 사용 중인 쿼리를 기반으로 사용자에게 유용합니다. 그런 점에서 데스크탑과 모바일에서 서로 다른 지식 패널이 표시되더라도 놀라지 않을 것입니다. 그러나 나는 또한 우리가 말할 특정한 요소가 있다고 생각하지 않습니다. 이것이 당신이 이 시간에 이 지식 패널을 보고 있는 이유이며 다른 시간이 아닌 이유입니다.

때때로 이러한 종류의 쿼리와 관련하여 이 변경 사항이 있는 곳에서 지식 패널을 표시할지 여부의 경계에 있을 수 있습니다. 그런 다음 장치 유형이 이를 뒤집고 결국 예 또는 아니오와 같이 될 수 있습니다. 그러나 그것은 이것을 표시하거나 표시하지 않는 것과 관련된 한 가지 특정 요소가 있다고 생각하지 않는 것입니다. 우리는 지식 패널에 대해 다양한 소스를 사용합니다. 그리고 그 중 일부는 지식 패널에서 직접 볼 수 있습니다. 그래서 그것은 당신이 조금 따라갈 수 있는 한 가지입니다.

이와 관련하여 제가 드리고 싶은 또 다른 팁은 지식 패널과 Google에서 항목을 선택할 때 항목이 표시되는 방식을 조사하는 데 많은 시간을 할애한 Google 외부의 사람들이 있다는 것입니다. [...] Jason Barnard는 내가 아는 사람 중 이 작업을 잘 수행하는 사람 중 한 명입니다. 그는 지식 패널에 대해 항상 Twitter에 게시하고 있습니다. 그리고 아마도 그것은 당신이 그곳에서 볼 수 있는 것에 대한 몇 가지 아이디어를 제공할 수도 있습니다.”

FAQ 목록에 포함할 질문 수

40:41 “내 웹페이지에 15~20개의 FAQ가 있습니다. FAQ 스키마에 모든 질문을 포함해야 합니까, 아니면 중요하다고 생각하는 질문만 포함해야 합니까?"

John에 따르면, “구조화된 데이터의 경우 페이지에 구조화된 데이터가 표시되기를 원하지만 표시되는 모든 콘텐츠가 구조화된 데이터로 마크업되어야 하는 것은 아닙니다. 페이지에 구조화된 데이터를 제공하려는 개별 콘텐츠가 있는 경우 계속 진행하십시오. 페이지의 모든 콘텐츠에 대해 그렇게 할 필요는 없습니다. 따라서 20개의 FAQ가 있고 그 중 5개를 표시하면 전적으로 귀하에게 달려 있습니다. 원하는 경우 data-nosnippet을 사용하여 이러한 다른 항목 중 일부가 스니펫에 나타나지 않도록 완전히 차단할 수도 있습니다."

인덱스 커버리지 문제

52:00 “[문제] 중 하나는 크롤링 - 현재 인덱싱되지 않고 [후자]는 발견됨 - 현재 인덱싱되지 않습니다. 그리고 두 경우 모두 페이지가 인덱싱되지 않습니다. [...] Google이 전체 콘텐츠의 색인을 생성하지 않는다는 것을 알고 있습니다. [...] 내 특정 웹사이트의 일부 검색어에 대해 이미 순위가 매겨진 홈 페이지에서 링크하거나 페이지에서 링크하는 것과 같이 이러한 페이지를 최소한 [색인화]하려면 어떻게 해야 합니까? [...] 더 많은 백링크를 가져올 수 있습니까?”

존은 “그런 것들이 다 도움이 되는 것 같다. 올바른 방향으로 가고 있는 것 같으며 무엇을 기대해야 하는지 조금은 알 수 있습니다.

우리의 관점에서 볼 때 모든 웹사이트의 콘텐츠를 색인화하지 않는 경우 이며 이는 우리 측에서 예상한 것입니다. 따라서 콘텐츠의 많은 부분이 이미 인덱싱되고 있는 경우 올바른 접근 방식에 있다고 생각합니다. 하지만 모든 것이 완벽하다는 것은 아닙니다. 웹사이트의 전반적인 품질이 정말 좋은지 확인하는 내부 연결과 같은 작업은 많은 도움이 됩니다.

때로는 웹사이트를 전체적으로 살펴보고 두 번째 파일에 500페이지를 제출했다고 말하는 것이 합리적일 수도 있습니다. 그리고 그 중 200개가 인덱싱되고 있습니다. 인덱싱되지 않는 300페이지의 가치는 무엇입니까? 웹사이트에 500개의 임의 페이지가 있는 상태에서 내가 할 수 있는 일이 있습니까? 더 적은 수의 페이지에 가치를 집중시키기 위해 웹사이트에서 정말 좋은 페이지를 300개로 줄이는 것이 아닐까요? 최소한 그 적은 수의 페이지가 인덱싱됨에 따라 해당 페이지의 많은 가치를 다시 얻을 수 있습니다. 이는 다른 키워드에 대해 순위를 매기거나 우선 순위를 지정하는 방법으로 가장 관심 있는 사용자를 위해 작동할 수 있습니다. Google에 할 일을 모두 넘기기 전에

그래서 그것이 내 접근 방식이 될 것입니다. 한편으로 는 내부 연결 및 전반적인 웹 사이트 품질과 함께 모든 것이 적절하게 정렬되어 있는지 확인합니다. 반면에 많은 페이지의 색인이 생성되지 않고 있는 경우 우선 순위를 지정해야 하는 페이지를 Google에 명확하게 알리는 방법을 찾고 있습니다 . 귀하의 사이트에 중요하지 않거나 중요하지 않습니다."