정규식을 사용하여 Google Search Console API를 최대한 활용하는 방법

Google Search Console은 Google에서 직접 실제 사용자의 귀중한 검색 데이터를 제공하는 놀라운 도구입니다. 차트와 표는 다루기 쉽지만 대부분의 데이터는 UI에서 액세스할 수 없습니다.

이 숨겨진 데이터에 접근하는 유일한 방법은 API를 사용하고 방법을 알고 있는 경우 사용할 수 있는 모든 귀중한 검색 데이터를 추출하는 것입니다. 이것은 정규 표현식으로 가능합니다.

SMX Advanced에서 연설한 PayPal 회사 Honey의 제품 성장 부사장인 Eric Wu에 따르면 정규 표현식을 사용하여 Google Search Console API를 최대화하는 방법은 다음과 같습니다.

GSC로 SEO 문제 진단하기

성장이 정체되거나 감소하거나 핵심 업데이트가 떨어지는 웹 사이트에서 작업하고 계십니까?

대부분의 SEO 전문가는 이러한 문제를 진단하기 위해 Google Search Console(GSC)을 사용합니다.

(또는 리소스가 허용하는 경우 Ryte와 같은 유료 도구를 사용하거나 자체 플랫폼을 구축할 수도 있습니다.)

다행히 SEO 커뮤니티에는 다음을 포함하여 GSC 분석에 유용한 Looker Studio 대시보드(이전의 Google Data Studio)가 부족하지 않습니다.

• Aleyda Solis의 무료 대시보드는 GSC 데이터를 사용하여 Google 핵심 업데이트에서 최근 몇 일간 잠재적인 순위 변경 사항을 쉽게 식별합니다.
• 이제 Discover 및 Google 뉴스 트래픽 데이터를 가져오는 Google의 검색 트래픽 모니터링 대시보드.
• Hannah Butler의 Search Console Explorer Studio. (그리고 GSC 데이터를 직접 조작하고 빠른 통찰력을 얻으려면 Butler의 Search Console Explorer Sheet를 사용할 수 있습니다.)

대시보드를 통해 SEO는 GSC를 사용하고 필요한 데이터에 도달하기 위해 여러 번 클릭하는 것과는 반대로 다양한 추세의 개요를 볼 수 있습니다.

그러나 기업 사이트를 분석하는 경우 몇 가지 장애물에 부딪힐 수 있습니다.

• Looker Studio와 Google Sheets는 특히 대규모 사이트를 다룰 때 느리게 로드됩니다.
• GSC의 인터페이스에는 1,000행 내보내기 제한이 있습니다.
• GSC는 큰 샘플링 문제가 있습니다. Similar.ai에 따르면 엔터프라이즈 SEO 팀은 GSC 키워드의 90%를 놓치고 있습니다. 그리고 데이터를 추출하는 방법을 안다면 실제로 14배의 키워드를 얻을 수 있습니다.

GSC의 샘플링 문제 극복

Explorer for Search는 GSC 분석에 사용할 수 있는 또 다른 도구입니다. Two Octobers의 Noah Learner와 팀은 GSC의 API를 사용하여 데이터 파이프라인으로 구축한 다음 BigQuery로 데이터를 출력하고(기본적으로 Google 스프레드시트를 우회하고 CSV 파일 다운로드) 데이터 스튜디오로 정보를 시각화합니다.

이를 통해 거의 모든 데이터에 액세스하고 있다는 확신을 가질 수 있습니다.

GSC의 샘플링 문제, 특히 다양한 범주가 있는 대규모 전자 상거래 사이트의 경우 여전히 주의 사항이 있습니다. GSC는 해당 디렉토리에서 들어오는 모든 데이터를 반드시 표시하지는 않습니다.

GSC API에서 최대한의 데이터를 얻기 위해 다양한 테스트를 수행한 후 Similar.ai 팀은 GSC 샘플링 간격을 좁힐 방법을 발견했습니다.

그들은 GSC 대시보드 내에서 다른 프로필로 더 많은 하위 디렉토리를 추가함으로써 Google이 더 낮은 수준에서 더 많은 정보를 제공하므로 더 많은 데이터를 추출할 수 있다는 것을 발견했습니다.

예를 들어 example.com/televisions를 보고 GSC 프로필의 하위 디렉토리로 "televisions"를 추가하면 Google은 해당 하위 디렉토리에 대한 키워드와 클릭 정보만 제공합니다.

그리고 이러한 다양한 하위 디렉토리를 많이 추가하여 더 많은 정보를 추출할 수 있습니다.

그러면 샘플링 문제가 해결되지만 정규식을 사용하면 더 많은 데이터를 얻을 수 있습니다.

정규 표현식으로 더 많은 GSC 데이터 얻기

정규식 또는 정규식은 데이터를 이해하는 강력한 도구입니다.

2021년 4월 Google은 GSC에 정규식 지원을 추가하여 SEO가 유기적 검색 데이터를 분할하고 분할할 수 있는 더 많은 방법을 제공합니다.

많은 경우 데이터는 이해할 수 없으면 유용하지 않습니다. 그리고 정규식은 GSC의 풍부한 데이터에서 실행 가능한 통찰력을 추출하는 데 도움이 됩니다.

그러나 정규식은 아무리 강력하더라도 배우기 어려울 수 있습니다.

정규 표현식을 이해하고 자세히 알아볼 수 있는 가장 좋은 곳은 GitHub의 Google 공식 문서입니다. (Google은 자사 제품에 RE2를 사용하는데, 이는 정규 표현식의 특징입니다.)

regex는 모든 종류의 다양한 프로그래밍 언어에서 사용할 수 있지만 .htaccess 파일을 수정하는 사람들에게도 거의 모든 곳에서 찾을 수 있습니다.

다음 몇 섹션에서는 GSC에 정규식을 활용하기 위한 사용 사례를 설명합니다.

정규식 정보 쿼리

GSC에서 실제 정보 검색 쿼리를 볼 때 일반적으로 다음을 이해하려고 합니다.

• 사람들이 실제로 어떻게 귀하의 사이트를 방문합니까?
• 그들은 어떤 질문을 추출하고 있습니까?

일회성 관점에서 보면 GSC 내에서 어려울 수 있습니다.

당신은 항상 "무엇을", "어떻게", "왜", 그리고 "언제"라는 단어를 검색합니다.

정규식을 사용하여 정보 쿼리를 덜 지루하게 추출하는 몇 가지 방법이 있습니다.

Daniel K. Cheung은 클릭 또는 노출이 발생한 "무엇", "어떻게", "왜" 및 "언제"가 포함된 모든 쿼리를 표시하는 정규식 문자열을 공유했습니다.

• "what|how|why|when"

그리고 Steve Toth가 공유한 이 정규식 문자열은 이전 예제를 한 단계 업그레이드했습니다.

• ^(who|what|where|when|why|how)[" "]

"누가", "무엇을", "어디서", "언제", "왜" 및 "어떻게"로 시작 하고 그 뒤에 공백이 오는 질문 기반 쿼리를 캡처하려는 경우 이 문자열을 사용할 수 있습니다.

이것은 질문을 시작하는 모든 유형의 단어를 찾을 때 사용할 수 있는 훌륭한 목록입니다.

• 이다, 할 수 있다, 할 수 없다, 할 수 있다, 할 수 없다, 했다, 하지 않았다, 하다, 하다, 하지 않는다, 어떻게 무엇을, 언제, 어디서, 누구, 누구, 누구, 왜, 하지, 하지, 하지, 하지 않을

이 모든 것을 정규식 형식으로 바꾸면 다음과 같이 보일 것입니다.

• ^(are|can|can't|could|couldn't|did|didn't|do|does|doesn't|how|if|is|isn't|should|shouldn't|was|wasn't|were|weren't|what|when|where|who|whom|whose|why|will|won't|would|wouldn't)\s

이 178자 문자열에서:

• 쿼리가 다음 단어로 시작해야 한다고 알려주는 캐럿( ^ )이 있습니다.
• 단어는 쉼표 대신 파이프( | )로 구분됩니다.
• 모든 단어는 괄호로 묶입니다.
• 백슬래시와 단어 뒤에 공백을 나타내는 "s"( \s )가 있습니다.

이것은 좋은 일이지만 하기가 지루할 수도 있습니다.

아래에서 Wu는 이전 단어 목록을 보다 정규식에 친숙하고 더 짧게 단순화하여 복사 및 붙여넣기에 이상적입니다. 이런 식으로 유지하는 것도 효율성에 도움이 됩니다.

첫 번째 열에는 일반 단어가 있고 두 번째 열에는 압축된 정규식이 있습니다.

예를 들어 "can"이라는 단어는 압축된 버전 can('t)? .

물음표가 나타내는 것은 괄호 안의 모든 것이 선택 사항이라는 것입니다. 압축된 구문을 사용하면 "can"과 "can't"라는 단어를 모두 포함할 수 있습니다.

더 흥미롭게도 단어의 -ould 부분이 (c|sh|w)ould(n't)? . 이 짧은 문자열은 이러한 6가지 경우를 모두 포함합니다.

긴 단어 목록을 단순화하면 문자열이 가독성이 떨어지긴 하지만 정규식 필드에 더 잘 맞고 복사하여 붙여넣기가 더 쉬워진다는 점이 좋습니다.

• ^(are|can('t)?|(c|sh|w)ould(n't)?|did(n't)?|do(es)?(n't)?|how|if|is(n't)?|was(n't)?|were(n't)?|wh(at|en|ere|y)who(m|se)?|will|won't)\s

한 단계 더 나아가면 더 압축할 수 있습니다. 이 경우 Wu는 문자 수를 135자에서 113자로 줄였습니다.

• ^(are|can('t)?|how|if|wh(at|en|ere|y)|who(m|se)?|will|won't|((c|sh|w)ould|did(n't)?|do(es)?|was|is|were)(n't)?)\s

정규식은 정말 복잡해질 수 있습니다. 다른 사람으로부터 정규식 문자열을 받고 수행 중인 작업을 명확하게 하려는 경우 Regexper를 사용하여 시각화할 수 있습니다.

아래에서 다양한 정규식 문자열 버전의 비교를 볼 수 있습니다. 첫 번째 것을 유지하는 것이 더 쉽고 마지막을 유지하고 읽는 것이 분명히 더 어렵습니다.

그러나 더 긴 정규 표현식이 있는 경우 문자 수가 특히 중요할 때가 있습니다.

Google Search Advocate Daniel Waisberg에 따르면 GSC의 정규식 필터 제한은 4,096자입니다.

꽤 그럴 것 같습니다. 그러나 전자 상거래 사이트가 있고 도메인 이름, 하위 도메인 또는 더 긴 디렉토리를 추가해야 하는 경우 해당 제한에 도달할 가능성이 큽니다.

정규식 브랜드 쿼리

GSC에서 정규식 문자 제한에 도달하기 시작할 수 있는 또 다른 경우는 브랜드 쿼리에 사용할 때입니다.

한 사람이 입력할 수 있는 브랜드 이름의 모든 다른 유형의 철자 오류에 대해 생각해 보면 4,096자라는 숫자에 빠르게 부딪힐 것입니다. 예를 들어:

• aamaung, damsung, mamsang, sam sung, samaung, samdung, samesung, sameung, samsung, samgung, samsang, samsaung, samsgu, samshgg, samshng, samsing, samsnug, samssum, samsnug, samssum, samsam , samsung g, samsunb, samsund, samsund, samsunh, samsunt…

여기에서 정규식을 이해하는 것이 도움이 됩니다. 이 문자열을 사용하면 맞춤법 오류와 함께 브랜드 이름 "samsung"을 캡처할 수 있습니다.

• (s+|a|d|z)[az\s]{1,4}m?[az\s]{1,6}(m|u|n|g|t|h|b|v)

많은 경우 사람들은 단어의 중간 부분의 철자를 틀리게 만들 것입니다. 그러나 일반적으로 형식과 길이가 적절하며 이러한 방식으로 구문에 접근할 수 있습니다.

브랜드 쿼리 철자가 잘못된 경우 다음을 고려하세요.

• 브랜드 쿼리를 구성하는 주요 문자 .
• 자음 .
• 단단한 자음을 둘러싼 글자 .

빨간색은 사람들이 브랜드 이름을 입력할 때 일반적으로 놓치지 않는 단단한 자음입니다. 이들은 특정 브랜드를 구성하는 주요 문자입니다. "samsung"의 경우 시작 부분에 "s", 중간에 "m", 끝 부분에 "n" 및 "g"가 있습니다.

키보드의 주요 자음을 둘러싼 파란색 문자는 사람들이 일반적으로 잘못 입력하는 문자입니다. 예에서 "s" 주위에 "a", "d" 및 "z"가 표시됩니다. (다국어 키보드의 레이아웃은 다르지만 개념은 여전히 ​​​​동일합니다.)

위의 정규식 문자열은 "samsung"의 가능한 모든 변형을 캡처합니다.

다른 주요 트릭은 [az\s]{1,4} 에 있습니다.

정규식 형식에서 이것은 기본적으로 "나는 모든 문자 "a"를 "z" 또는 공백과 1~4번 일치시키고 싶습니다.

이것은 잠재적으로 동일한 키를 여러 번 누르거나 실수로 스페이스바를 누를 수 있는 브랜드 쿼리 중간에 발생할 수 있는 모든 이상한 맞춤법 오류를 캡처합니다.

또한 브랜드 이름은 일정 길이("samsung"은 7자)입니다. 사람들은 아마도 20-50자를 입력하지 않을 것입니다.

따라서 이 정규식에서 "samsung"의 "s"와 "m" 사이에 누군가가 1-4자를 잘못 입력할 것이라고 추측하고 있습니다. 그런 다음 끝에 "m"에서 "g"까지 공백을 포함하여 1-6자를 잘못 입력합니다.

이 모든 것을 추가하면 브랜드 쿼리의 다양한 변형을 포괄적으로 캡처할 수 있습니다.

주목해야 할 또 다른 사항은 브랜드 이름이 쿼리의 다른 부분에 나타날 수 있다는 것입니다.

따라서 브랜드 이름 자체가 캡처되었는지 확인해야 합니다. 다음 중 하나여야 합니다.

• 쿼리 시작 시.
• 쿼리 중간(따라서 공백으로 둘러싸여 있음).
• 또는 쿼리의 끝에서.

이에 대한 정규식은 다음과 같습니다.

• (^|\s)(s+|a|d|z)[az\s]{1,4}m?[az\s]{1,6}(m|u|n|g|t|h|b|v)(\s|$)

이것은 브랜드 이름 "samsung"이 시작, 중간 또는 끝에 있는 모든 쿼리를 캡처합니다.

• 문자열의 시작 = ^
• 공백으로 둘러싸인 = \s
• 문자열 끝 = $

JC Chouinard의 게시물인 Google Search Console의 정규식(RegEx)에서는 정규식 예제에 대해 더 자세히 다룹니다.

Regex 및 GSC API 작동

정규식은 Wu와 그의 팀이 핵심 업데이트 이후 트래픽 감소가 발생한 클라이언트와 작업할 때 유용했습니다.

전자 상거래 사이트의 다양한 문제를 살펴본 후 일부 제품 세부 정보 페이지에 문제가 있음을 발견했습니다.

그들은 GSC에서 분석을 위해 페이지 유형을 분류해야 했습니다. 그러나 이것은 미국 및 국제 제품의 URL 구조가 다르기 때문에 복잡한 작업이었습니다.

사이트의 국제 제품 URL에는 언어 및 국가 코드가 포함되어 있지만 미국 제품 URL에는 포함되어 있지 않습니다.

제품 슬러그, 범주 및 하위 범주에 문자와 대시가 있기 때문에 정규식 구문을 사용하는 것조차 까다로웠습니다. 또한 미국 페이지만 캡처하기 위해 해외 제품 URL을 필터링해야 했습니다.

모든 미국 제품 방문 + 세부 정보 페이지(i18n 페이지 아님 )를 얻으려면 다음 정규식 문자열을 사용했습니다.

포함: /([^/]+/){1,2}p?

제외: /[a-zA-Z]{2}|[a-zA-Z]{2}-[a-zA-Z]{2}/

분석 결과는 다음과 같습니다.

팀은 범주, 하위 범주 및 모든 제품을 일치시키고자 하여 다음을 포함했습니다.

• 슬래시가 아닌 모든 문자 = [^/]+
• 디렉토리 1개 또는 2개 = /){1,2}
• 때때로 제품 슬러그 = p?

캐럿( ^ )은 일반적으로 문자열의 시작을 의미합니다. 그러나 대괄호 안에 있으면( [^/] 에서와 같이) 부정을 나타냅니다(즉, "이 상자 안에 아무 것도 없음").

그래서 이 문자열은 /([^/]+/){1,2}p? "나는 슬래시가 아닌 임의의 수의 문자를 원하고, 슬래시(디렉토리를 나타냄)로 시작하고 때로는 문자 'p'(제품 슬러그의 접두사)가 오기도 합니다."

동시에 팀은 문자와 대시도 포함된 국가 및 언어 조합을 일치시키고 싶지 않았기 때문에 다음을 제외했습니다.

• 임의의 2글자 디렉토리 = [a-zA-Z]{2}
• 2글자 + 2글자 lang-country 콤보 = [a-zA-Z]{2}-[a-zA-Z]{2}

모든 언어 및 국가 코드와 일치하는 정규식을 자체적으로 만드는 것은 가능한 모든 조합으로 인해 지루할 것이므로 정보 쿼리(모든 단일 유형의 조합이 제외된 경우)에서와 같이 접근할 수 없었습니다.

그러나 이러한 정규식 문자열을 만든 후에도 문제가 발생했습니다.

Google Search Console에는 정규식 문자열을 붙여넣는 필드가 하나만 있습니다. 정규식과 일치 또는 정규식 과 일치하지 않음 을 선택해야 합니다. 두 가지를 동시에 사용할 수는 없습니다.

여기서 GSC API는 정규식 문자열을 결합할 수 있으므로 유용합니다.

Google Search Console API 문서 에는 지금 사용해 보기 링크가 있습니다.  

클릭하면 사이트를 선택하고 웹 보기를 통해 API를 요청할 수 있는 콘솔이 열립니다.

그러나 API 쿼리를 더 잘 관리하기 위해 Wu는 데스크톱에서 Postman을 사용하거나 Mac에 기본 제공되는 Paw를 사용할 것을 권장합니다.

Postman을 사용하면 쿼리를 만들고 나중에 사용할 수 있도록 저장할 수 있습니다. 다른 사이트에 액세스할 수 있는 경우 매번 새 쿼리를 만들 필요가 없습니다. 변수로 사이트 이름을 변경한 다음 여러 요청을 하기만 하면 됩니다.

반면에 Paw는 살펴보고 활용하기가 훨씬 쉽습니다.

API에 액세스하려면 API 키를 가져와야 합니다. (Chouinard의 유용한 튜토리얼이 있습니다.)

이 정보를 얻으면 Postman 또는 Paw 내에서 OAuth 2.0 인증에 추가할 클라이언트 ID와 클라이언트 비밀을 갖게 됩니다.

거기에서 일반 계정으로 로그인할 수 있습니다.

Wu는 주로 Paw의 정규식 문자열을 사용하여 GSC API 요청을 했습니다. 쿼리는 인터페이스 중간에 입력됩니다.

Google의 응답은 GSC API 웹 보기의 응답과 유사합니다. 그런 다음 처리를 위해 데이터를 내보낼 수 있습니다.

데이터가 JSON이기 때문에 정보가 지저분하고 읽기 어려울 수 있습니다.

이를 위해 JQ라는 무료 오픈 소스 명령줄 JSON 프로세서를 사용하여 정보를 예쁘게 인쇄할 수 있습니다.

데이터는 스프레드시트로 가져올 때까지 그다지 유용하지 않습니다. Paw에서 JQ로 내보낸 파일을 파이프합니다. 그것을 연 다음 각 행을 반복합니다. CSV로 출력할 수 있도록 각 요소를 저장합니다.

여기에서 부동 소수점(소수점이 있는 숫자)인 클릭과 노출을 변환해야 합니다. 둘 다 CSV와 호환되는 문자열로 변환해야 합니다.

그러면 JQ는 다음과 같은 훨씬 더 간단한 형식을 출력합니다.

다음으로 Dasel을 사용하여 이 형식을 취한 다음 CSV로 만듭니다.

그리고 여기 최종 결과가 있습니다.

Wu 팀의 놀라운 점은 Google Search Console API와 정규 표현식을 사용하여 다음을 수행할 수 있다는 것입니다.

• 모든 국제 쿼리를 걸러내고 주요 문제가 발생한 미국만 살펴봅니다.
• 사이트에 문제가 발생한 날짜를 식별합니다.

보기: Google Search Console API 최대한 활용하기

아래는 Wu의 SMX Advanced 프레젠테이션의 전체 비디오입니다.