Gerry White와 함께 SEO용 로그 파일을 사용하는 5가지 방법

게시 됨: 2023-02-08



SEO를 개선하기 위해 로그 파일을 어떻게 활용하고 있습니까?

오늘 우리는 BBC, Just Eat, Rise at Seven을 포함한 브랜드와 대행사에서 일하는 SEO 업계에서 20년 이상의 경험을 가진 한 남자와 이야기할 것입니다. In Search SEO 팟캐스트 Gerry White에 오신 것을 환영합니다.

이 에피소드에서 Gerry는 다음을 포함하여 SEO에 로그 파일을 사용하는 5가지 방법을 공유합니다.
  • Google이 귀하의 사이트를 어떻게 보는지 확인
  • 매개변수
  • 크롤링 예산을 소비하는 하위 도메인이 있습니까?
  • 자바스크립트 및 CSS 파일
  • 응답 코드

Gerry: 이봐, 여기 와서 기뻐.

D: 당신이 있어 좋은. LinkedIn에서 Gerry White를 검색하여 Gerry를 찾을 수 있습니다. Gerry, 모든 SEO가 로그 파일을 사용해야 합니까?

G: 아니요, 로그 파일에 엄청난 양의 정보가 있다고 말할 때 논란의 여지가 있다는 것을 압니다. 그러나 솔직히 말해서 수익이 감소하는 경우가 많습니다. 그리고 종종 일반적으로 로그 파일로 이동하기 전에 많은 정보를 찾을 수 있습니다. 즉, Google Search Console 정보를 살펴보면 엄청난 양의 정보가 있습니다. 내가 로그 파일을 조사했을 때 처음으로 많은 다른 곳을 처음으로 소진했을 때입니다. 나는 항상 Screaming Frog 또는 가지고 있는 데스크톱 크롤러와 같은 것을 사용하여 사이트를 크롤링한 다음 로그 파일을 보기 전에 Google Search Console을 볼 것을 권장합니다.

내가 그렇게 말하는 이유와 로그 파일이 얼마나 유용한지에 대해 이야기할 때 거의 안티 로그 파일처럼 들리는 이유는 실제로 초기에 작업하기가 상당히 까다롭기 때문입니다. 그리고 그것들을 실제로 손에 쥐고 접근하기까지 약간의 기술, 지식 및 경험이 필요합니다. 그러나 오늘날의 한 가지 좋은 점은 이제 거의 그 어느 때보다 로그 파일에 더 많이 액세스할 수 있다는 사실입니다. 처음 시작했을 때는 Google Analytics나 오늘날과 같은 분석 소프트웨어가 없었습니다. 로그 파일 분석은 사람들이 웹 사이트를 방문한 방식을 살펴보는 방법이었습니다. 이제 우리는 InfoSec으로 무언가를 하지 않는 한 사람들이 웹사이트를 보는 방식에 대해 거의 로그 파일을 보지 않습니다. 또는 정말 이상하고 놀라운 것을 진단하기 위해 무언가를 하고 있습니다.

하지만 실제로는 훨씬 더 나은 분석 소프트웨어가 있는 경우가 많습니다. 사실 한 가지 이상한 점은 많은 웹사이트에서 얼마나 많은 사람들이 404 페이지로 이동하는지 추적할 수 없다는 사실입니다. 대부분의 경우 404 페이지에서 쿠키를 허용한다는 것을 클릭하지 않기 때문입니다. . 갑자기 로그 파일이 다시 돌아와 이와 같은 매우 이상한 질문에 답합니다.

그러나 오늘 로그 파일에 대해 이야기하는 주된 이유는 SEO 목적입니다. 예, 대형 사이트에 문제가 있거나 대형 전자 상거래 웹 사이트가 있는 경우, 패싯 탐색 기능이 있는 국제적인 다국어 대형 사이트가 있는 경우 로그 파일은 확실히 가져와야 하는 것입니다. 고려하고 가능한 한 빨리 라인을 살펴봐야 합니다.

D: 그래서 오늘 SEO가 로그 파일을 사용해야 하는 다섯 가지 방법을 공유하고 있습니다. 첫 번째부터 시작하여 Google이 귀하의 사이트를 어떻게 보는지 확인하십시오.



1. Google이 귀하의 사이트를 어떻게 보는지 확인



G: 그래, Google은 제멋대로인 아이처럼 거의 예측할 수 없다. 이상하게도 우리는 사이트를 볼 수 있고 크롤링 도구를 사용하여 Google이 사이트를 어떻게 봐야 하는지 살펴볼 수 있지만 Google이 한 세트의 페이지에 집착하거나 어딘가 이상한 길을 따라. 또는 더 최근에 저는 Odor라는 슈퍼마켓에서 지난 1년 동안 함께 일했습니다. 우리가 발견한 것 중 하나는 Google 봇이 일종의 분석 구성을 살펴보고 여기에서 인공 링크를 생성한다는 것입니다. Google에서 깨진 링크를 찾습니다. 그리고 오랜 시간 동안 페이지에 전혀 없는 404 중 수십 개의 404를 찾는 이유를 알아내려고 노력했습니다. 하지만 분석 구성을 살펴보고 여기에서 링크를 생성하고 있는 것으로 나타났습니다. 그래서 우리는 그것이 얼마나 많은 영향을 미쳤는지 살펴보고 있습니다. 그리고 Google이 이러한 404를 모두 찾는다는 사실을 보면 큰 문제가 아닐 수 있습니다. 하지만 이제 우리는 404에 소요되는 시간이 얼마나 되는지 알고 싶습니다. 이 작은 문제 하나를 수정하면 나머지 사이트의 크롤링이 20-30% 증가한다는 의미입니까? 우리가 그것을 고친다면 어떤 기회가 있습니까? Google이 사이트를 그렇게 보는 이유와 실제로는 찾지 말아야 할 항목을 찾는 것이 전부입니다.



2. 매개변수



우리가 자주 보는 다른 것은 매개변수입니다. 아시는지 모르겠지만 SEO 담당자는 항상 페이지의 표준 버전에 연결합니다. 내 말은 때때로 어떤 종류의 내부 추적 또는 외부 추적이 있는 여러 버전의 페이지가 있다는 것입니다. 예를 들어 제품이 사이트의 여러 위치에 있을 수 있는 경우가 많습니다. 이에 대한 좋은 예는 Magento라는 사이트에서 작업한 것입니다. 그리고 모든 제품이 모든 단일 범주에 속하는 것 같았기 때문에 모든 제품에 약 20개의 버전이 있고 모든 제품을 크롤링할 수 있다는 사실을 알았을 때 정말 놀랐습니다. 그래서 거기에서 우리는 Google이 사이트를 크롤링하는 데 엄청난 시간을 소비하고 있음을 알았습니다. 그리고 흥미로운 점은 제품을 제거하면 Google에서 "아, 하지만 이 제품의 다른 버전이 19개 있습니다."라는 메시지가 표시되므로 제품을 사용한 경우 실제 페이지가 거의 사라지는 데 시간이 걸립니다. Google의 작동 방식 때문에 404 또는 그와 비슷한 것입니다. Google은 이 페이지가 이 페이지의 표준 버전임을 확인합니다. 그러나 표준 버전을 제거하면 다른 버전을 사용하기 시작합니다. 그리고 이것이 종류입니다. 로그 파일이 우리에게 제공하는 정보 우리가 Google이 있는 방식으로 사이트를 볼 수 있는 능력.

또한 상태 코드와 같은 것을 볼 수 있습니다. 이것의 좋은 예는 내가 수정되지 않았다는 상태 코드가 있다는 것입니다. 그리고 지금 내 삶을 위해 그것이 무엇인지 생각할 수 없습니다. 이 팟캐스트 전에 이것을 기록했어야 했습니다. 하지만 기본적으로 "수정되지 않았습니다"는 웹사이트의 크롤링 속도를 크게 향상시킵니다. 이것이 Google이 존중하는 것임을 알았을 때 제가 할 수 있는 것은 모든 이미지, 모든 제품에 대한 것이었습니다. , 정기적으로 수정되지 않는 이러한 모든 부분을 수정하지 않음을 사용하여 Google의 크롤링 속도를 개선하고 효율성을 개선하며 서버의 부하를 줄일 수 있다면 그런 다음 Google이 모든 다양한 제품을 찾는 방식을 크게 개선합니다.

Google이 사물을 보는 방식, 우리가 원하고 서버 관리자가 원하고 모두가 원하는 방식은 서버가 가능한 한 빠르고 효율적이어야 한다는 것입니다. 다시 로그 파일 측면으로 돌아가서 오늘날 우리는 수년 동안 로그 파일을 전혀 효과적으로 사용할 수 없었습니다. CDN을 사용하면 페이지가 방문되는 여러 위치가 있는 경우가 종종 있습니다. 그리고 CDN에는 종종 로그 파일 자체가 없었습니다. 따라서 우리는 이 모든 다른 장소를 살펴보고 이 서버에 얼마나 많은 부하가 있는지, 해당 서버에 얼마나 많은 부하가 있는지 확인할 것입니다. 그리고 우리는 모든 것을 하나로 통합하려고 시도하고 로그 파일은 다른 형식이 됩니다. 이제 CDN을 사용하면 실제로 CDN의 효율성을 이해할 수 있습니다. PageSpeed와 같은 기능은 로그 파일을 사용하면 예를 들어 이미지의 정규화를 통해 이미지가 여러 페이지에 걸쳐 사용된다는 사실을 이해할 수 있다는 사실로 인해 엄청난 영향을 받고 개선됩니다. URL이 일관되면 CDN이 작동하고 Google이 더 잘 크롤링합니다. 예, 로그 파일이 PageSpeed를 개선하고 사용자와 검색 엔진을 훨씬 더 효율적으로 캐싱하고 서비스하는 데 도움이 되는 다양한 방법이 있습니다.

D: 공유하려고 했던 다섯 가지 사항을 검토하고 있습니다. 그리고 이미 공유한 다른 요소가 있습니다. 당신은 내가 한 가지만 질문할 수 있는 사람을 생각나게 하고 그들은 더 이상 질문하지 않고 15분짜리 팟캐스트 에피소드를 제공합니다. 당신보다 훨씬 더 그렇게 할 수 있는 사람이 한 명 있습니다. 그리고 그것은 아마도 Duane Forrester일 것입니다. Duane과 나는 그가 그에게 한 가지 질문만 하고 내가 자리를 비우고 나머지 에피소드에 대한 내용을 공유하도록 남겨둔 것에 대해 농담을 했습니다. 그러나 당신은 매개변수에 대해 조금 이야기했습니다. 크롤링 예산을 소비하는 하위 도메인이 있어서는 안 되지만 발견하는 3번 항목을 건드렸는지 모르겠습니다.



3. 크롤링 예산을 소비하는 하위 도메인이 있습니까?



G: 이것은 사실 Just Eat으로 거슬러 올라갑니다. 어느 시점에서 우리는 웹사이트가 여러 개의 서로 다른 하위 도메인에 복제되어 있고 이들 모두가 크롤링 가능하다는 사실을 발견했습니다. 흥미롭게도 Citrix와 같은 도구에 따르면 이들은 가시성이 없었습니다. 그리고 그들이 하지 않은 이유는 그것이 모두 정형화되었기 때문입니다. 따라서 이러한 중복 항목이 외부에 있지만 Google이 이러한 하위 도메인을 크롤링하는 데 예산의 60~70% 미만을 지출하고 있음을 알게 되었습니다. 그리고 CDN 및 기타 기술로 인해 동일한 방식으로 캐시되지 않았기 때문에 실제로 많은 서버 부하가 발생했습니다. 그래서 그것은 우리에게 매력적인 것이었습니다. 왜냐하면 우리는 이것을 바로 미래에 언젠가 고쳐야 할 문제로 그냥 무시하고 있었기 때문입니다. 문제에 대해 알고 있었기 때문입니다. 우리는 일종의 문제가 있다는 것을 알고 있었고 그것에 대해 이야기했습니다. 하지만 로그 파일을 보기 전까지 우선 순위를 낮췄습니다.

우리는 Google이 여기에서 많은 에너지, 시간 및 리소스를 사용하고 있음을 확인했습니다. 얼마나 많은 서버 부하가 발생합니까? 얼마나 영향이 있었나요? 그리고 서버가 다른 소스를 해석할 수 없는 방식 때문에 서버 부하가 어느 정도인지 이해할 수 없었습니다. 그래서 우리가 로그 파일을 얻었을 때 웹 사이트의 신뢰성을 상당히 향상시킬 수 있다는 것이 흥미로웠습니다. 그래서 우리는 하위 도메인에 대해 알고 있었고 로그 파일을 조사하기 전까지는 문제가 얼마나 되는지 알지 못했습니다. 그리고 갑자기 이 문제를 최대한 빨리 해결해야 한다는 것을 알게 되었습니다. 그것은 우리가 그것을 고칠 방법을 알고 있는 것 중 하나였습니다. 그것은 단지 우선순위였습니다. 대기열 맨 아래에 있었고 2 위로 올라갔습니다.



4. JavaScript 및 CSS 파일



D: 정규화에 대해 언급하셨지만 특히 JavaScript 및 CSS 파일이 문제가 될 수 있다고 말씀하셨습니다. 왜 그런 겁니까?

G: 우리가 자주 하는 일 중 하나는 CSS 파일에 매개변수를 추가하여 캐시를 깨는 것입니다. 우리가 이렇게 하는 이유는 CDN 또는 이와 유사한 것을 사용하는 경우 발생하는 일입니다. CSS를 업데이트할 때마다 새 페이지 등을 생성하게 되면 문제는 캐시된 CSS 파일이 있다는 것입니다. 새 페이지에서 사용할 수 없습니다. 그리고 이러한 다양한 JavaScript 및 CSS 파일 모두에서 캐시 시간이 깁니다. 따라서 페이지 내에서 JavaScript 또는 CSS를 업데이트해야 하는 항목을 추가하자마자 페이지 내에서 매개 변수를 약간 변경하기만 하면 됩니다. 거기에서 우리는 서로 다른 모든 서버가 앞으로 동일한 매개 변수 버전을 사용하고 있는지 확인해야 했습니다. 여러 다른 팀, 여러 웹사이트, 전체를 구동하는 더 나은 JavaScript를 사용하는 경우 항상 올바른 버전인지 확인했습니다. 그리고 로그 파일은 API 키 또는 이와 유사한 것을 업데이트해야 할 수 있기 때문에 서로 다른 모든 페이지가 지속적으로 올바른 JavaScript 버전에 도달하는지 확인하는 한 가지 방법이었습니다. 우리가해야 할 일이 너무 많았습니다. 그리고 이것은 개발자에게 엄청난 작업이었습니다.

우리가 로그 파일에서 보고 있던 것 중 하나는 이전 것이 맞았는지, 어디에서 맞았는지, 그리고 우리가 그것을 고칠 수 있었는지였습니다. 또한 JavaScript 파일에 대한 경로를 작성할 수 있는 다양한 방법이 있음을 발견했습니다. 예를 들어, 다른 호스트 이름을 사용한 하위 도메인에 있었습니다. 흥미롭게도 여러 다른 웹 사이트에서 작업하는 경우 실제로 동일한 서버에 액세스하는 다른 URL이나 다른 도메인 이름이 있는 경우가 종종 있습니다. 그리고 종종 CDN을 사용하거나 하위 디렉토리를 사용하는 경우 때때로 매우 일관성이 없을 수 있습니다. 그리고 사용자의 관점에서 볼 때 여정 내에서 동일한 JavaScript 파일을 6~7가지 다른 방식으로 실행한다면 6~7가지 다른 방식으로 파일을 로드하게 됩니다. 별거 아닌 것 같지만 누적하면 여정에 몇 메가바이트가 추가됩니다. 물론 전체 경험이 느려지고 서버 효율성이 떨어집니다. 그리고 훨씬 더 많은 것이 있습니다. 따라서 올바른 버전의 JavaScript, CSS 및 기타 비트와 조각이 항상 히트되고 있는지 확인하십시오. 또한 JavaScript가 매개변수 등으로 숨겨질 이유가 없는지 확인하십시오. 스파이더 트랩을 생성할 수 있는 방법에는 여러 가지가 있습니다. 여기에는 JavaScript 파일이 포함됩니다. 예를 들어 무언가 태그가 지정되고 JavaScript에 대한 올바른 절대 참조를 사용하지 않을 수 있습니다. 따라서 다른 시간과 다른 디렉토리에 있습니다. 자바스크립트가 여러 페이지에서 조금씩 다르게 로드되는 것을 발견할 수 있는 다양한 방법이 있다는 것은 놀라운 일입니다. 네, 아주 간단한 것입니다. 그러나 분석에 있어서는 놀라울 정도로 비용이 많이 듭니다.



5. 응답 코드



D: 또한 응답 코드가 원하는 방식으로 전달되는지 확인합니다. 예를 들어 TOS를 통해 Google에서 표시되어야 하거나 표시되어서는 안 되는 TOS가 표시되거나 표시되지 않는 경우가 있습니다. 그렇다면 왜 그런 일이 일어날까요?

G: 다시 말하지만 우리는 항상 같은 브라우저, 같은 기술, 같은 경험 등 모든 것을 사용하여 웹 페이지를 방문합니다. 나는 모두가 Screaming Frog 감사를 하기 때문에 내가 평소에 사용하는 도구가 아닌 다른 도구를 사용하려고 노력하므로 모든 종류의 조각과 조각을 사용하려고 합니다. 하지만 우리는 항상 우리가 일종의 컴퓨터인 척합니다. 따라서 우리는 결코 Googlebot인 척하지 않으며 우리 모두가 서로 다른 존재인 척하지 않습니다. 따라서 Google 봇이 다른 IP 주소에서 특정 파일에 액세스하는 방식을 보면… CloudFlare와 같은 많은 기술에서 Googlebot인 척하고 Screaming Frog를 사용하여 파일에 액세스하려고 하면 Googlebot이 아니라 당신이 바로 이것입니다. 따라서 Googlebot을 대하는 방식과 다르게 대합니다. 그리고 종종 서버는 모든 비트와 조각을 수행하기 위해 물건을 미리 렌더링하도록 구성됩니다. 그리고 모든 사람이 해당 지점에서 서버로부터 올바른 응답 코드를 받도록 하는 것입니다.

매우 간단해 보이지만 국제적으로 규모를 확장할 때... 지리적 리디렉션이 있을 때 누군가가 지리적 리디렉션을 입력했기 때문에 사용자나 검색 엔진이 특정 페이지에 액세스할 수 없는 경우 스페인의 웹사이트에서 이 하위 디렉토리를 로드하십시오... 따라서 루트 버전이나 대체 버전을 볼 수 없습니다. 그렇기 때문에 올바른 응답 코드와 같은 것이 절대적으로 중요합니다. 그리고 얼마나 자주 이러한 일을 겪고 모든 것이 올바르게 설정되었다고 가정하는지 놀랍습니다. 몇 번이고 우리는 그것이 어떻게 설정되어야 하는지 알고 있기 때문입니다. 우리는 이것을 누군가에게 주고, 누군가는 그것을 해석하고, 다른 사람은 그것을 구현하고, 다른 누군가는 그것을 겪습니다. 그런 다음 다른 누군가가 CDN의 버튼을 클릭합니다. "아, 이 특정 장소에서 누군가를 지리적으로 찾을 수 있습니다." 어떤 한 사람이 뭔가 잘못을 저질렀다는 사실이 그다지 중요하지 않아서 그것을 효과적으로 약간 깨뜨린 사슬 아래에 무언가가 있다는 것입니다.





파레토 피클 - 낮게 매달린 과일



D: 파레토 피클로 마무리합시다. 파레토는 20%의 노력으로 80%의 결과를 얻을 수 있다고 말합니다. 적당한 수준의 노력으로 놀라운 결과를 제공하는 추천할만한 SEO 활동은 무엇입니까?

G: 현재 제가 가장 좋아하는 것은 매우 기본적인 Google Data Studio 대시보드가 ​​있어서 손쉬운 열매라고 부르는 것을 살펴볼 수 있다는 것입니다. 이제 모두가 유행어 빙고를 싫어합니다. 그러나 이것은 내가 순위가 매겨지지 않은 것을 보는 나의 일입니다. 특정 페이지, 조리법, 제품 등에 대해 순위가 매겨진 모든 키워드를 살펴봅니다. 좋은 예는 현재 수십 개의 제품에 대해 작업하고 있으며 높은 노출수를 얻은 모든 페이지를 살펴보지만 위치 6에 있을 수 있으며 위치 3까지 작업할 수 있습니다. 열에 아홉은 제목 태그와 내부 링크가 개선되었는지 확인하는 것만으로도 가능합니다. 검색량이 많은 키워드 중 클릭률을 높이기 위해 조금 더 올릴 수 있는 키워드를 찾는 매우 간단한 작업입니다.

D: 나는 당신의 호스트였습니다, David Bain. LinkedIn에서 Gerry White를 검색하여 Gerry를 찾을 수 있습니다. Gerry, In Search SEO 팟캐스트에 참여해 주셔서 감사합니다.

G: 반가워요. 시간 내 주셔서 감사합니다.

D: 그리고 들어주셔서 감사합니다. 이전 에피소드를 모두 확인하고 Rank Ranger 플랫폼의 무료 평가판에 가입하세요.