엔터프라이즈 기술 SEO - 1페이지 파워 웨비나

안녕하세요. Enterprise Technical SEO 에 대한 Page One Power의 패널 웨비나 요약에 오신 것을 환영합니다.

먼저, 시간과 통찰력을 우리와 청중과 공유해 주신 멋진 패널들에게 감사드립니다! 당사의 전문가 패널은 다음과 같은 기능을 제공했습니다.

• Distilled의 연구 개발 책임자인 Tom Anthony
• Catalyst의 전략 및 혁신 이사인 Paul Shapiro
• IBM의 SEO 전문가 Patrick Stox
• Page One Power의 R&D 이사인 Nicholas Chimonas.

이것은 엔터프라이즈 수준의 기술 SEO와 관련된 다양한 주제에 대한 흥미로운 토론과 대화가 있는 훌륭한 웨비나였습니다.

참고: 이 요약은 대화 내용을 그대로 옮겨 적는 것이 아니라 직접 번역한 것입니다. 정확한 대화를 듣는 데 관심이 있다면 전체에 포함된 비디오를 볼 수 있습니다.

개요

대화는 약 1시간 동안 진행되었으며 패널은 다양한 주제, 과제 및 솔루션을 다루었습니다.

토론을 보다 쉽게 ​​이해할 수 있도록 여기에서 모든 것을 분류했습니다. 각 해당 질문의 시작 부분에서 시작되는 포함된 비디오가 포함됩니다(노란색 하위 헤더로 표시됨).

또한 가독성을 높이기 위해 블록 텍스트를 통해 특히 흥미로운 인용문이나 아이디어를 가져왔습니다. 다시 말하지만, 이것은 직접적인 인용 이 아닙니다 .

녹화된 비디오 전체를 보고 싶다면 여기로:

전문가 패널이 다룬 질문은 다음과 같습니다.

1. 엔터프라이즈 사이트에는 수백만 페이지는 아니더라도 수천 페이지가 있습니다. 이 규모에서 기술 문제의 우선 순위를 지정하고 관리하는 방법은 무엇입니까?
2. 엔터프라이즈 클라이언트와 함께 작업하면 구현 주기가 느려집니다. 그에 따른 계획은 어떻게 되나요?
3. SEO는 종종 기업 구조에서 최소한의 인지도를 받습니다. 어떻게 예산을 확보하고, 가치를 업스트림에 판매하고, 우선순위를 확보할 수 있습니까?
4. 기술 SEO에는 다양한 부서 간의 협업이 필요합니다. 부서 간 협업을 어떻게 구축합니까?
5. 기술 SEO에서 가장 마음에 드는 점은 무엇입니까?
6. 매일 수많은 404를 발생시키는 대규모 재고 변경을 어떻게 처리합니까?
7. 페이지가 더 빨리 로드되도록 바닥글에 웹 사이트에 대한 큰 CSS 및 Javascript를 사용하는 것이 좋습니까?
8. 어떻게 변화의 결과를 정확하게 측정하고 그 결과를 클라이언트에게 보여줄 것인가?

이러한 질문은 토론의 시작점이 되어 대화를 통제하기보다는 안내하는 데 도움이 되었습니다.

대화가 스크립트로 작성되지 않았기 때문에 패널리스트는 개인적인 일화, 독특한 전략, 풍부한 실제 정보 및 조언을 포함할 수 있었습니다.

즐기시기 바랍니다!

질문 1: 엔터프라이즈 사이트에는 수백만 페이지는 아니더라도 수천 페이지가 있습니다. 이 규모에서 기술 문제의 우선 순위를 지정하고 관리하는 방법은 무엇입니까?

토론은 4:05에 시작됩니다.

니콜라스: 패트릭, 같이 가자.

영향에 따른 우선 순위 지정

패트릭: 알았어. 나는 당신이 상당한 영향을 미칠 곳을 치라고 말하고 싶습니다. 페이지별 규모에서 가장 중요한 페이지 중 하나가 아닌 한 큰 차이를 만들지 않을 것입니다. 그러나 때로는 작은 성공을 거두고 더 큰 프로젝트를 처리하는 데 필요한 신뢰를 구축하기 위해 페이지별로 작업을 수행해야 합니다.

우리의 경우 사례 연구를 구축하고 다른 사람들에게 영향을 줄 수 있도록 다양한 CMS 시스템과 다양한 사업부의 다양한 문제를 한 번에 하나씩 해결하는 것입니다. 그것이 우리가 그것에 대해 가는 방법입니다.

Nicholas: 사이트의 더 작은 하위 섹션으로 귀하의 사례를 입증하면 더 쉽게 동의 를 얻을 수 있다고 생각하십니까? 그렇다면 개발 팀이 더 큰 규모로 그렇게 하도록 설득할 수 있는 화력이 있습니까?

패트릭: 네, 물론입니다.

니콜라스: 폴에 대해 어떻게 생각하세요? 또한 이에 대한 답변을 원하시면 청중으로부터 질문을 받을 수 있습니다. 질문은 "엔터프라이즈 클라이언트의 크롤링 예산을 어떻게 최적화합니까?"입니다.

Paul: 먼저 주요 질문을 다루겠습니다.

변경 사항의 영향을 평가할 수 있는지 여부가 정말 중요하다고 생각합니다.

비용과 소요 비용을 알고 나면 우선 순위를 지정하는 것이 더 쉬워집니다.

즉, 모델을 구축하고, 영향을 예측하고, 변경 사항을 구현하기 위한 비용(인력, 리소스, 기술 등)을 계산하고 그에 따라 우선 순위를 지정할 수 있어야 합니다. 비용과 비용이 무엇인지 알게 되면 우선 순위를 정하는 것이 더 쉬워집니다.

크롤링 예산

크롤링 예산 질문과 관련하여 내가 Search Engine Land에 대해 작성한 기사에서 PageRank 알고리즘을 사용하고 웹사이트 전체에서 내부적으로 계산하고 이를 사용하여 크롤링 예산에 영향을 미치는 방법을 설명하는 기사를 확인할 수 있습니다.

니콜라스: 물론이죠. 이는 아키텍처의 이러한 변경이 예상한 변경을 만들 것이라고 생각하는 이유에 대한 일부 데이터를 얻으려고 시도하면서 정말 자주 무시되는 접근 방식입니다.

톰, 이에 대해 어떻게 생각하세요?

ROI를 기술 SEO에 연결

Tom: 먼저 Patrick과 Paul의 의견에 동의합니다. 그들이 건드린 것들의 상관 관계는 어떤 수정 사항이 가장 높은 ROI를 가질 것인지 이해하려고 노력하는 것입니다.

기업 사이트의 어떤 영역이 실제로 작업할 수 있는지 식별하고 작업을 얼마나 빨리 구현할 수 있는지 이해해야 합니다.

따라서 필요한 노력이 무엇인지에 대한 가설이 필요할 뿐만 아니라 결과와 수명에 대해서도 이야기해야 합니다. 나쁜 경우의 예는 개발자가 도달하는 데 너무 오래 걸리고 결과가 나올 때쯤에는 더 이상 가치가 없는 것입니다.

기업 사이트의 어떤 영역이 실제로 작업할 수 있는지 식별하고 작업을 얼마나 빨리 구현할 수 있는지 이해해야 합니다.

Distilled ODN의 관점에서 볼 때 흥미로운 점 중 하나는 영향에 대한 더 나은 가설이 있다는 것입니다.

일반적으로 기업 사이트에는 일정 수준의 우선 순위가 필요한 기술적 SEO 변경에 대한 긴 백로그가 있습니다. 따라서 특정 변경 사항의 영향을 더 잘 가정할 수 있도록 테스트에 ODN을 사용하도록 권장하고 있습니다. 기업 사이트에서 기술적 SEO 변경의 ROI를 예측하는 것은 놀라울 정도로 어렵지만 ODN을 사용하면 다양한 것을 테스트할 수 있습니다.

Nicholas: 이 수준(기업)에서 특히 그렇습니다. 간단한 변경이 예상보다 더 큰 영향을 미칠 수 있습니다. 그리고 저는 더 큰 사이트에서 작업할 때 온페이지 SEO가 훨씬 더 중요하다고 생각합니다.

톰: 물론이죠. Mike King은 Moz의 기술 SEO에 대한 훌륭한 게시물을 가지고 있습니다.

Nicholas: 예, Mike의 게시물은 많은 SEO 도구가 게임의 이면에 있다는 점을 매우 잘 보여줍니다. 따라서 도구에만 의존하고 수동으로 확인하지 않으면 중요한 문제를 놓칠 수 있습니다. 흥미로운 글이니 한번 보시길 추천합니다.

질문 2: 엔터프라이즈 클라이언트와 함께 작업하면 구현 주기가 느려집니다. 그에 따른 계획은 어떻게 되나요?

이 질문에 대한 토론은 12:50에 시작됩니다.

Nicholas: Patrick, 이 문제에 대해 다시 이야기해 보겠습니다.

패트릭: 하, 재미있는 질문이군요! 때때로 여러분은 기다리고 있습니다. 제가 기다리고 있는 많은 변화가 올해나 어떤 경우에는 내년에도 일어날 것으로 예상하지 않습니다. 하지만 항상 다른 할 일이 많이 있습니다.

하지만 항상 그런 것은 아닙니다. 경영진의 동의와 팀의 동의가 있는 경우 상황이 매우 빠르게 진행될 수 있습니다. 항상 느린 것은 아닙니다.

Nicholas: 네, 저는 동전의 양면을 모두 경험했습니다. 나는 당신이 절대적으로 옳다고 생각합니다. 그리고 그것은 당신이 그것을 밀어붙이고 더 빨리 일어나게 할 수 있는 (조직의 어떤 수준에서) 동의를 얻었는지에 달려 있습니다.

그리고 다른 한편으로, 일이 느리게 진행되고 구현되지 않는 곳에서는 아직 자신을 증명함으로써 신뢰를 얻거나 동의를 얻지 못했기 때문입니다. 권장 사항의 중요성을 입증한 후에는 구현 주기가 더 빨라지는 경우가 많습니다.

폴, 이에 대해 어떻게 생각하십니까?

직접 변경 구현

Paul: 구현 시간에 대해 아무 것도 할 수 없는 경우가 많으며 프로세스가 느려질 것입니다. 당신이 할 수 있는 일은 가능한 한 스스로 구현하는 것입니다. 직접 변경할 수 있는 기회가 있다면 프로세스 속도를 높이는 데 도움이 될 것입니다. 스스로 구현할 수 있는 작은 일이라도 프로세스 속도를 높일 수 있습니다.

강력한 기술 팀이 있는 경우 최종 변경 사항이 크지 않을 수 있음을 인정하고 가능한 한 도움을 제공함으로써 개발자 및 엔지니어와 신뢰를 구축할 수 있습니다. 수행 중인 작업을 아는 것만으로도 작업을 더 빨리 완료할 수 있습니다.

또한 이러한 변경 사항의 가치를 명확하게 전달하고 적절한 사람들과 이야기해야 합니다. 강력한 기술 팀이 있는 경우 최종 변경 사항이 크지 않을 수 있음을 인정하고 가능한 한 도움을 제공함으로써 개발자 및 엔지니어와 신뢰를 구축할 수 있습니다. 수행 중인 작업을 아는 것만으로도 작업을 더 빨리 완료할 수 있습니다.

Nicholas: 기꺼이 고삐를 잡고 개발자를 지원하고 대역폭에 공감하는 것이 도움이 됩니다. 자신을 사용할 수 있게 하면 액세스 권한을 얻을 수 있으며, 종종 스스로 변경할 수 있는 액세스 권한을 얻는 것이 백로그에 넣어 맨 위로 올라가는 것보다 더 쉽다는 것은 절대적으로 사실입니다.

Tom, 여기에 무게를 실을 수 있습니까?

개발 팀과의 관계 구축

Tom: 나는 다른 사람들이 개발자들과 친해지고 그들을 당신 편으로 만드는 것에 대해 말한 것과 절대적으로 일치합니다.

참석하는 것만으로도 받은 편지함에 얼굴 없는 이메일이 들어오는 것보다 더 많은 일을 할 수 있다는 것을 알게 될 것입니다.

에이전시 관점에서 볼 때 고객이 있는 경우 사무실에서 일해야 합니다. 사무실에 도착하면 역학을 볼 수 있고 작업을 완료하기 위해 누구와 이야기해야 하는지 이해할 수 있습니다. 개발 팀의 관점에서 회의에 참석할 수 있는지 확인하십시오.

참석하는 것만으로도 받은 편지함에 얼굴 없는 이메일이 들어오는 것보다 더 많은 일을 할 수 있다는 것을 알게 될 것입니다. 우리는 컨설턴트들이 회의에 참석하도록 했고, 이전에는 시들해졌던 SEO 티켓이 갑자기 거품을 일으키기 시작했습니다. 컨설턴트는 아무 말도 할 필요가 없었습니다. 이 티켓의 결과에 투자한 실제 사람이기 때문에 티켓이 맨 위로 떠올랐습니다.

그런 다음 개발자를 돕기 위해 무엇을 할 수 있는지 알아보세요. 종종 특정 이유로 인해 어려움을 겪는 티켓이 있지만 항상 다시 연락을 받지는 않습니다. 하지만 실제로 가서 이야기를 해보면 그들이 왜 힘들어하는지 알 수 있고 도움을 줄 수 있습니다. 이것은 당신이 그들과 이야기하고 그들의 도전을 인정해 준 것에 감사할 것이기 때문에 당신이 그들에게 신뢰를 줄 것입니다.

크롤링 예산(계속)

로그 분석은 생각보다 훨씬 쉽게 접근할 수 있으며 이를 사용하여 실행 가능한 많은 데이터를 수집할 수 있습니다. 길가에 쓰러진 것 같지만 통나무는 금광입니다.

크롤링 예산 항목으로 돌아가서 엔터프라이즈 규모의 로그 분석은 크롤링 예산에 매우 유용합니다. 로그 분석은 생각보다 훨씬 쉽게 접근할 수 있으며 이를 사용하여 실행 가능한 많은 데이터를 수집할 수 있습니다. 길가에 쓰러진 것 같지만 통나무는 금광입니다.

Nicholas: Screaming Frog Log Analyzer와 같은 도구를 사용하면 그 어느 때보다 쉬워졌습니다. 이전에 한 번도 해본 적이 없다면 배울 수 있는 것에 놀랄 것이기 때문에 한 번 해보는 것이 좋습니다.

Tom: 종종 엔터프라이즈 규모에서 가장 어려운 부분은 누군가에게 로그에 대한 액세스 권한을 부여하도록 설득하는 것입니다. 그러나 다시 적절한 팀에 자신을 포함시키는 것이 도움이 될 것입니다.

ODN을 사용하여 구현 주기 우회

니콜라스: 그리고 한 가지 더. Distilled의 ODN을 사용하면 구현 주기를 우회하고 변경 작업을 직접 수행할 수 있습니다. ODN은 CDN처럼 작동하며 기존 시스템이 있는 모든 것을 우회할 수 있습니다.

Tom: 예, CDN과 유사하게 배포되며 사용자의 관점에서 볼 때 CDN이 존재하지 않는 것으로 보입니다. 그리고 다른 모든 것 위에 놓이는 거의 새로운 CMS처럼 작동합니다.

이것에 대해 매우 흥미로운 점은 개발 팀이 통제력 상실을 느낄 것이기 때문에 많은 반발이 있을 것으로 예상된다는 것입니다. 그러나 놀라운 것은 많은 개발 팀이 이전 플랫폼에 대해 좌절감을 느끼기 때문에 이러한 변경을 환영했다는 것입니다. 그래서 우리(SEO)는 티켓이 완료되지 않은 것에 대해 좌절했고 그들(개발자)은 완료하지 못한 것에 대해 좌절했습니다. ODN은 SEO가 개발 팀을 돕고 웹사이트를 가능한 한 성공적으로 만드는 공통 목표를 달성할 수 있는 플랫폼을 만듭니다.

Nicholas: 맞아요. 모든 면에서 승리입니다.

참고: Nicholas는 질문 3이 이미 다루어졌기 때문에 질문 3과 4를 결합했으며 질문 4와 잘 연결되었습니다. 두 질문에 대한 답변은 아래와 같습니다.

질문 3: SEO는 종종 기업 구조에서 최소한의 인지도를 받습니다. 어떻게 예산을 확보하고, 가치를 업스트림에 판매하고, 우선순위를 확보할 수 있습니까?

질문 4: 기술 SEO에는 다양한 부서 간의 협업이 필요합니다. 부서 간 협업을 어떻게 구축합니까?

이 질문에 대한 토론은 23:30부터 시작됩니다.

니콜라스: 패트릭과 함께 시작합시다. 이것은 IBM의 맥락에서 특히 흥미로운 질문이라고 생각합니다.

엔터프라이즈 수준의 교육 및 협업

Patrick: 알겠습니다. 한 질문에 두 가지 질문이 있습니다. 기업 구조에서 인지도에 관해서는 이미 테스트, 사례 연구, ROI 예측 등에 대해 이야기했습니다. 하지만 여기서 놓치고 있는 가장 큰 부분은 다양한 직원과 팀을 교육하는 것입니다.

팀에 크레딧을 주는 것은 큰 도움이 됩니다. 팀이 훌륭한 일을 해냈다면 그에 대한 공로를 인정하십시오. 그들이 많은 노력을 기울이고 당신이 제안한 개선 사항을 만들었다면 그것은 당신과 함께 그들의 승리입니다.

믿거나 말거나 하지만 엔터프라이즈 SEO에서는 사이트 크기당 훨씬 적은 수의 SEO로 작업하므로 교육이 필수적입니다. 그리고 훈련의 좋은 점은 훈련을 받는 사람, 즉 전도자가 될 사람을 찾는 데 도움이 된다는 것입니다.

팀에 크레딧을 주는 것은 큰 도움이 됩니다. 팀이 훌륭한 일을 해냈다면 그에 대한 공로를 인정하십시오. 그들이 많은 노력을 기울이고 당신이 제안한 개선 사항을 만들었다면 그것은 당신과 함께 그들의 승리입니다.

영향을 미칠 것이라고 생각되는 것이 있으면 포기하지 마십시오. 귀를 기울일 사람을 찾고 백로그에서 죽어가고 있지 않은지 확인하는 방법을 찾아야 합니다.

협업에 관해서는 팀과 반복적으로 작업하면 관계를 구축하는 데 도움이 됩니다. 때때로 팀이 예산을 확보하거나 자체 예산에서 비용을 지불하여 프로젝트를 수행하는 데 필요한 리소스를 얻을 수 있도록 도울 수 있습니다.

프로젝트를 포기하지 마십시오

Patrick: 저는 계속해서 백로그, 백로그, 백로그를 듣습니다. 꽤 자주 발생합니다. 내부 또는 기관, 그것은 중요하지 않습니다 그냥 계속 밀어. 영향을 미칠 것이라고 생각되는 것이 있으면 포기하지 마십시오. 귀를 기울일 사람을 찾고 백로그에서 죽어가고 있지 않은지 확인하는 방법을 찾아야 합니다.

Nicholas: 네, 그럴 때면 정말 짜증이 납니다. 그러나 나는 내가 계속 추진한다면 내가 그것을 할 수 있다는 것을 자주 발견했습니다. 포기하지 않는 것이 정말 중요합니다.

Patrick: Tom은 앞서 에이전시 직원이 들어오는 것에 대해 좋은 지적을 했습니다. 사람들이 들어오면 일반적으로 적합한 사람을 만나고 귀를 기울이게 됩니다. 사내처럼 누군가에게 같은 말을 5번 해도 결과가 안 나올 수 있는데, 소속사 사람이 들어와서 갑자기 똑같은 말을 하면 더 수긍이 가더라고요.

니콜라스: 네 , 정말 그렇습니다. 나는 조직 내 사람들이 "고마워요. 저도 같은 말을 했지만, 우리는 외부에서 다시 와서 그것을 말해줄 누군가가 필요했습니다"라고 말하게 한 적이 있습니다.

Patrick에 대한 답변에 감사드립니다. 귀하의 투명성에 감사드립니다. 그리고 Paul, 이 질문들에 대한 당신의 생각을 들어봅시다.

언어 말하기

Paul: 우선 저는 Tom이 앞서 언급한 고객과의 대면 관계를 구축할 기회를 잡는 것에 대한 팁을 좋아합니다.

당신이 할 수 있는 다른 일의 관점에서, 당신이 누구와 이야기하고 있는지 알고 그들의 언어로 말하는 것은 정말 도움이 됩니다. 예를 들어, 마케팅 팀과 이야기하고 있다면 달러와 센트, 그리고 그것이 그들의 업무에 어떤 영향을 미칠지에 대해 이야기하고 싶을 것입니다.

Nicholas: 확실히, 그것은 클라이언트 사무실에 갈 때 정말 좋은 팁입니다. Tom, 우리에게 어떤 다른 훌륭한 팁이 있습니까?

기술 SEO 보고

Tom: 질문 3과 관련하여 아직 언급하지 않은 한 가지는 보고 방법입니다. SEO는 SEO의 근거와 결과를 뒤섞는 큰 보고서를 작성하는 경향이 있습니다. 더 나은 보고를 위한 한 가지 팁은 잠재 고객을 숨기지 않는 것입니다. 이메일 제목은 최상위 부가가치가 되어야 합니다. 그러나 또한 그들에게 방대한 Word 문서를 제공하지 마십시오.

고객이 연례 보고서나 웹사이트에서 어떤 언어를 사용하는지 살펴보고 해당 언어를 슬라이드 데크에 반영해야 합니다. 그렇게 하면 당신이 말하는 모든 것이 그들 자신의 언어로 그들에게 다시 연결됩니다.

보고서를 주요 상위 수준 요약을 제공하는 슬라이드 데크로 생성하여 정보에 대한 접근성과 공유 가능성을 높일 수 있습니다. 큰 텍스트 보고서는 경영진이 읽을 수 없지만 스캔 가능한 슬라이드 데크를 제공하면 비즈니스 내부의 더 많은 사람들이 비즈니스를 위해 수행하는 작업에 노출될 것입니다.

또 다른 정말 중요한 요점은 바울이 말한 것입니다. 바로 그들의 언어를 사용하는 것입니다. 고객이 연례 보고서나 웹사이트에서 어떤 언어를 사용하는지 살펴보고 해당 언어를 슬라이드 데크에 반영해야 합니다. 그렇게 하면 당신이 말하는 모든 것이 그들 자신의 언어로 그들에게 다시 연결됩니다. 그리고 그것을 수익에 연결하십시오. 그것이 경영진이 중요하게 생각하는 것이기 때문입니다.

공통 목표/목표 강조

보다 전술적인 접근은 각 부서의 목표가 무엇인지 알아내는 것입니다. 목표를 이해하면 변경 사항이 목표 달성에 어떻게 도움이 되는지 설명할 수 있습니다.

Nicholas: 네, 당신이 함께 일하고 있는 부서의 목표를 이해하고 당신의 보고를 거기에 직접 연결하는 것은 정말 좋은 포인트입니다.

패트릭: 좋은 지적입니다. 부서마다 목표가 다르며 이러한 다양한 부서에서 귀하의 권장 사항이 개인 목표를 달성하는 데 어떻게 도움이 되는지 보여주는 성과 기록표를 만들 수 있습니다.

니콜라스: 맞아. 그리고 이는 구현 주기를 통과할 동기를 제공할 수 있습니다.

Paul: Moz 블로그에 Rob Ousbey가 작성한 훌륭한 게시물이 있습니다. 이 문제를 다루고 있다면 읽어보길 권합니다.

Nicholas: David Sottimano가 주니어 SEO 체크리스트를 제공한 게시물도 확인할 가치가 있습니다.

다양한 보고서 작성

Nicholas: Tom이 언급한 또 다른 흥미로운 점은 보고의 삼각형입니다. 내 생각에는 스프레드시트와 데이터 요약, 핵심이 아닌 요약을 원하는 경영진을 위한 슬라이드 쇼, 그리고 그런 다음 모든 것을 심층적으로 설명하는 긴 서면 보고서.

보고를 할 때 일반적으로 세 가지 모두를 수행합니까, 아니면 함께 작업하는 사람에 따라 보고서를 조정합니까?

Tom: 우리가 자주 하는 일은 텍스트가 많은 보고서를 표로 변환하는 것입니다. 따라서 한 문장으로 권장 사항을 표시한 다음 열에 기술적인 근거, 수행해야 할 작업 및 영향을 줄 수 있습니다. 이것은 다른 팀이 다른 열에 관심을 가질 수 있고 관련 없는 정보를 쉽게 건너뛸 수 있기 때문에 잘 작동합니다.

여러 팀에서 액세스할 수 있는 방식으로 하나의 보고서를 작성할 수 있다면 여러 개의 다른 보고서를 작성할 필요가 없습니다.

Nicholas: 네, 저는 그것이 사실이라는 것을 확실히 알았습니다.

Tom: 따라서 여러 팀에서 액세스할 수 있는 방식으로 하나의 보고서를 작성할 수 있다면 여러 개의 다른 보고서를 작성할 필요가 없습니다.

Nicholas: 맞아요. 완전히 이해가 됩니다. 그 정보를 그래프와 그림이 있는 슬라이드 쇼에 넣는 것은 항상 가치가 있을 거라고 생각하지만, 바쁘기 때문에 가능하면 그렇게 하는 것을 피하고 싶습니다.

질문 5: 기술적 SEO에 대해 가장 좋아하는 것은 무엇입니까?

대화는 38:42에 시작됩니다.

니콜라스: 패트릭, 당신이 우리를 데려가도록 합시다.

기술 SEO: 새로운 도전, 창의성 및 측정 가능한 결과

패트릭: 이 질문이 좋아요! 저에게는 항상 새로운 문제와 전에 본 적이 없는 것들이 있다는 것을 좋아합니다. 다른 곳에서는 볼 수 없는 것 같은 느낌이 드는 것이 항상 있습니다. 항상 새로운 것이 있습니다.

Nicholas: 그게 기술 SEO의 가장 좋은 점 중 하나라는 데 동의합니다. 답답한 순간이 거의 없고 항상 해결해야 할 새로운 퍼즐이 있습니다.

폴 당신은 어때요, 당신이 가장 사랑하는 것은 무엇입니까?

Paul: 아시다시피, 기술 SEO는 매우 건조하다는 평판을 얻습니다. 하지만 저는 그것이 SEO의 가장 창의적인 영역 중 하나라고 생각합니다. 왜냐하면 당신은 제약의 형태를 다루고 있고 독특한 솔루션을 제시하고 흥미로운 방식으로 문제를 해결해야 하기 때문입니다. 그래서 저에게 있어 기술 SEO와 관련된 창의성이 저를 위해 일합니다.

니콜라스: 물론이죠. 기술적 문제에 접근하고 이해하기 위해서는 창의적이고 틀을 벗어난 사고 방식이 필요합니다.

Tom, 기술 SEO에서 가장 좋아하는 것은 무엇입니까?

Tom: 제가 생각하는 것과 같은 대답을 되풀이할 것입니다. 바로 이 퍼즐 풀기 부분입니다. 종종 하나의 정답이 없거나 있을 때 실제로 그 솔루션을 수행할 수 없으므로 차선책을 찾아야 합니다. 다양한 솔루션을 찾는 창의적인 생각입니다.

기술 SEO에서는 실제로 달성한 것을 볼 수 있습니다.

또 다른 이유는 마케팅의 다른 영역에서는 수행하기 어려운 영향을 실제로 측정할 수 있는 마케팅 영역 중 하나이기 때문입니다. 기술 SEO에서는 실제로 달성한 것을 볼 수 있습니다.

Nicholas: 물론입니다. 그리고 기술적 SEO의 가장 중요한 부분 중 하나는 테스트와 실험입니다. 검색 엔진과 기계 학습 알고리즘을 가지고 노는 것과 가장 잘 작동하는 것이 무엇인지 알아내려고 노력하는 것은 나에게 매력적입니다.

톰: 네. 그리고 끊임없이 변화하는 Google의 알고리즘에 맞게 최적화하면 몇 달 전에 효과가 있었던 것이 더 이상 사실이 아닐 수 있으므로 계속 배워야 합니다.

니콜라스: 물론입니다. 이것이 왜 기술적 SEO가 놀라운지에 대한 좋은 이유입니다. 감사합니다.

질문 6: 매일 수많은 404가 발생하는 대규모 재고 변경을 어떻게 처리합니까?

토론은 43:40 지점에서 시작됩니다.

Patrick: 전자상거래라고 가정하겠습니다. 나는 제품이 돌아오는 것으로 시작할 것 같아요? 재고가 없어서 그냥 404ing하는 경우 다음 주에 재고가 있게 되며 이는 제품이 방금 소진된 경우와 다릅니다.

전자의 경우에는 해당 페이지 404를 허용하지 않고 재고가 없음을 표시합니다. 후자의 경우 많은 경우 리디렉션을 확장하거나 들어오는 링크(내부 및 외부 모두)를 기반으로 우선 순위를 지정하여 404를 얻지 않도록 해야 할 수 있습니다.

데이터 확인

Nicholas: 이 질문이 웹마스터 도구가 소프트 404이기 때문에 많은 오류가 발생하는 사람에게서 온 것인지 궁금합니다. 따라서 이것들이 404가 되는 것은 괜찮을 수 있지만 소프트 404가 되어서는 안 되며 서버가 적절한 응답을 보내고 있는지 확인해야 합니다.

Tom: 이것이 로그 파일 분석에 대한 또 다른 이유입니다. 왜냐하면 그것은 당신이 정말로 신뢰할 수 있는 데이터이기 때문입니다. 때때로 웹마스터 도구를 사용하면 데이터가 신뢰할 수 있는지 확인하기가 정말 어렵습니다. 그리고 반동적인 접근을 하고 그에 따른 조치를 취하는 것은 위험할 수 있으므로 실제로 일어나는 일을 먼저 확인하고 싶습니다.

Paul: 왜 404ing인지 물어볼 수도 있습니다. 고의인지 아닌지? 재고가 없을 때 404ing이 되지 않도록 재구성하고 싶을 것입니다. 이는 사용 중인 CMS에 따라 다릅니다.

Nicholas: 상황에 따라 다르고 완전히 사라진 제품인지 아니면 다시 돌아올 것인지에 따라 다릅니다. 그것이 정말로 결정적인 요소입니다.

질문 7: 페이지가 더 빨리 로드되도록 바닥글에 웹 사이트에 대한 큰 CSS와 JavaScript를 사용하는 것이 좋습니까?

토론은 46:20부터 시작됩니다.

Tom: 그래서 거기에는 정말로 두 가지 질문이 있습니다. JavaScript는 확실히 바닥글에 있어야 합니다. 이는 페이지 속도에 대한 표준 모범 사례입니다. SEO에 영향을 미치는 좋은 사례(JavaScript)를 들어본 적이 없습니다.

항상 Search Console 내부에서 일어나는 일을 확인해야 합니다.

최근 JavaScript 파일의 더 큰 문제는 사람들이 때때로 느리고 종종 robots.txt에 의해 차단되는 타사 JavaScript 파일을 사용하고 있다는 것입니다. 따라서 Search Console 내에서 Google로 렌더링을 수행하면 실제로 차단되고 있음을 알 수 있습니다. 따라서 항상 Search Console 내부에서 일어나는 일을 확인해야 합니다.

니콜라스: 맞아. 헤드에 JavaScript를 사용하는 것과 관련된 흥미로운 문제 중 하나는 Search Console이 그 아래에 있는 hreflang 코드를 감지하는 것이었습니다. 그래서 Search Console은 마크업이 있는 페이지가 0개이고 헤드의 hreflang 위에 JavaScript가 있기 때문이라고 말했습니다.

그래서 우리는 JavaScript를 바닥글로 옮겼고, hreflang을 감지하고 가져오기 및 렌더링도 제대로 작동하게 했습니다.

질문 8: 변경 결과를 어떻게 정확하게 측정하고 그 결과를 고객에게 표시합니까?

토론은 48:51에 시작됩니다.

Tom: 이를 수행하는 다양한 방법이 있습니다. 한 가지 흥미로운 방법은 Google의 CausalImpact 라이브러리를 사용하여 변경 사항의 영향을 테스트하는 데 도움이 되는 것입니다. Tom은 Mark Edmondson의 이 게시물을 참조했습니다.

그 외에도 점점 더 많은 사람들이 A/B 방법론을 사용하기 시작했습니다. Tom은 Etsy의 이 게시물을 참조했습니다.

Nicholas: 이에 대해 Patrick이나 Paul의 이야기를 들어보겠습니다.

Patrick: 규모에 따라 다르겠지만 중요한 것을 추적하기만 하면 됩니다. 수행하려는 작업을 추적하는 데 필요한 데이터가 있는지 확인하십시오.

니콜라스: 물론이죠. 당신이 스스로 길의 끝까지 내려와 데이터를 갖고 있지 않은지 모르겠지만, 그곳은 재미있는 곳이 아닙니다.

자, Paul의 마지막 생각으로 이 글을 마무리하겠습니다.

폴: 물론이죠. 우선 A/B 테스팅 방법론은 SEO 환경에서 매우 저평가되어 있다고 생각하며, 조직 내에서 이를 수행할 수 있는 좋은 프로세스를 찾을 수 있다면 적극 권장합니다.

그것이 가능하지 않다면 어떤 변경 사항이 있었는지, 언제 변경되었는지, 검색 엔진은 언제 이러한 변경 사항을 적용했는지, 어떤 영향을 미쳤는지(트래픽 증가, 전환 개선 등) 확인해야 합니다.

그런 다음 가능한 한 많은 관련 없는 요소를 제거하고 변경한 내용과 분리합니다. 항상 쉽지는 않지만 적어도 이것이 주어진 변경의 영향이라고 방향적으로 말하는 적절한 작업을 수행할 수 있습니다.

그리고 그것은 랩입니다!