엔터프라이즈 SEO: '모범 사례'가 적합하지 않은 이유와 대신 수행할 작업

게시 됨: 2023-07-03

많은 SEO 전문가는 SEO 노력에서 "모범 사례"에 의존합니다.

그러나 사이트 속도를 위해 JavaScript 기반 기업 웹사이트를 최적화할 때는 "모범 사례" 이상이 필요합니다.

표준 솔루션이 엔터프라이즈 사이트에 항상 적용되지 않는 이유와 대신 할 수 있는 일이 있습니다.

사이트 속도 개선: 서버 측 렌더링으로 마이그레이션하는 것이 항상 정답은 아닙니다.

CEO(또는 고위 경영진)에게 가서 "웹 사이트를 서버측 렌더링(SSR)으로 변경해야 합니다."라고 조언한다고 상상해 보십시오.

그들은 "왜?"라고 묻습니다. 그들에게 줄 수 있는 유일한 대답은 "사이트 속도를 개선하는 것이 가장 좋은 방법이기 때문입니다."입니다. 당신은 문자 그대로 방에서 비웃을 것입니다.

SSR 마이그레이션과 관련된 비즈니스 영향 및 비용은 많은 노력과 낮은 영향을 받을 가치가 없습니다.

엔터프라이즈 웹 사이트가 처음부터 서버 측 렌더링을 위해 구축되었거나 이미 웹 사이트 마이그레이션을 진행 중인 경우가 아니면 SSR로 마이그레이션할 이유가 거의 없습니다.

이에 따른 소프트 및 하드 비용에 대해 생각해 보십시오.

  • 모든 시스템과 API를 검토하여 호환성을 확인합니다. 아마도 모두 문서화되지는 않았을 것입니다(수천은 아니더라도 수백).
  • 전체 웹 사이트에 대한 리팩터링, QA 및 검토 접근성에 수천 시간이 소요됩니다.
  • 새로운 프레임워크에 대한 기존 직원 교육(조직 전체에서 수백 명은 아니더라도 수십 명).
  • 새 프레임워크에 대한 사양이 없거나 사양에 부합하지 않는 개발자와 엔지니어를 고용하거나 해고합니다.
  • 서버 수수료에 더 많은 돈이 소비됩니다.

이러한 시간 소모적이고 자원 집약적인 프로세스를 견디는 대신 기업 웹 사이트의 속도를 개선할 수 있는 보다 성공적인 다른 방법이 있습니다.

이전 엔터프라이즈 역할에서 저는 선임 시스템 엔지니어 중 한 명과 재미로 바로 이 시나리오에 대해 이야기했습니다.

우리는 회사가 1년 반, 헌신적인 애자일 팀(보통 약 70명), 최소 200만 달러(AUD)가 소요될 것으로 예상했습니다. 그리고 그것은 아마도 보수적인 추정치였을 것입니다.

그래서 우리는 대신에 진전을 이루기 위해 무엇을 해야 합니까?

다른 팀에 대해 알아보고 도와주세요.

기업 수준에서 SEO는 카멜레온이 되어야 합니다. 다른 팀에 의존하여 우선순위를 정하고 작업을 완료해야 하기 때문입니다.

웹 사이트를 실시간으로 변경할 수 있는 왕국의 열쇠가 없는 데는 그만한 이유가 있습니다. 따라서 SEO는 단순한 SEO가 아닙니다.

SEO는 "이렇게 하면 사이트 속도가 향상되고/접근성 요구 사항을 충족하는 데 도움이 됩니다."입니다. 검색엔진 최적화는 모든 것입니다 그러나 SEO.

Tom Critchlow는 자신의 SEO MBA 과정과 내 팟캐스트인 Engage: On Enterprise SEO에서 이렇게 말했습니다.

엔터프라이즈 SEO로서의 삶을 정말 잘 요약합니다.

다른 사람들이 하는 일을 듣고 주의를 기울이는 데 많은 시간을 할애한 다음 그들이 하는 일이 웹사이트의 유기적 가시성을 어떻게 향상시켰는지 보여줘야 합니다.

옹호자를 만들면 이 사람들은 자신이 하고 있는 일과 웹 사이트에서 변경된 사항에 대한 꾸준한 보고서를 가지고 계속해서 돌아올 것입니다. 그것은 전투의 절반입니다.

후반부에는 개발자, 디자이너 및 분석가와 협력하여 작업을 완료합니다. 이것은 일반적으로 사람들이 자신의 생각, 감정 및 목표를 가진 사람이라는 것을 깨달을 때 훨씬 더 원활합니다.

그들의 삶을 더 쉽게 만들도록 돕고 싶어하는 호기심 많은 사람이 되는 것은 몇 주에 한 번씩 그들의 삶에 들어와 타협 없이 요구하는 도자기 가게에서 황소와 일하는 것보다 훨씬 더 매력적입니다.

개발자 및 생산자와 협력

요즘 많은 기업에서 사이트 속도는 전환율을 돕거나 방해하는 알려진 요소입니다.

사내의 많은 개발 팀은 아마 사이트 속도를 KPI로 삼을 것입니다. 그것을 활용하십시오.

당신은 둘 다 같은 것을 추구하고 있으며 당신의 개발자는 당신보다 코드베이스를 더 잘 알 것입니다. 그리고 잘하면 둘 다 보너스와 함께 나올 수 있습니다.

개발자가 도움을 줄 수 있는 몇 가지 일반적인 사이트 속도 기회는 다음과 같습니다.

코드의 크기/무게

팀에 기술 부채 스프린트 또는 할당이 있는 경우 일반적으로 이 작업을 수행하는 시기를 유지하면 리팩토링의 영향을 이해하는 데 도움이 될 수 있습니다.

그것을 그들에게 다시 반영하고 그들의 노력을 인정하십시오.

이미지 로딩 및 누적 레이아웃 이동(CLS)

CLS는 대규모 엔터프라이즈 JS 기반 웹 사이트의 인지된 로드 시간에서 큰 요인이 될 수 있습니다. 이것이 구현되는 방식에 따라 자리 표시자 JS 라이브러리를 사용하여 이미지 위치를 효과적으로 "유지"하면 이미지가 로드될 때 페이지를 이동하지 않음으로써 페이지의 인식되는 로드 시간을 줄일 수 있습니다.

리디렉션 관리

우리의 리디렉션 관리가 엄청나게 조각났기 때문에 이것은 내가 근거를 만들 수 있는 것이 아니었습니다.

그러나 시스템이 좀 더 중앙 집중화된 경우 리디렉션 관리, 홉 제거, 규칙을 정규식으로 통합하고 해당 기술 부채를 개선하면 상당한 도움이 될 수 있습니다.

일부 서버 배포에서는 페이지를 로드하기 전에 각 리디렉션 규칙을 읽어야 하며 이로 인해 초기 로드 시간에 상당한 시간(밀리초 이상)이 추가될 수 있습니다.

<a href> 대신 <버튼>

이것은 좀 더 미묘하지만 JS 개발자가 기본적으로 ahref 링크를 버튼으로 포함하는 것을 종종 발견했습니다.

이것은 일반적으로 시간이 부족하고 작업 중인 프레임워크의 기본 기본값이기 때문입니다.

새 페이지 템플릿을 QA할 때 <a href>로 업데이트되도록 종종 플래그를 지정했습니다.


검색 마케터가 의존하는 일일 뉴스레터를 받으세요.

처리 중…기다려 주십시오.

용어를 참조하십시오.


디자이너와 함께 일하기

기업 웹 사이트에서 가장 큰 사이트 속도 기회 중 하나는 이미지 크기와 무게입니다.

내부 표준은 특히 팀이 민첩하고 다소 분산된 경우 시간이 지남에 따라 잘못 번역되거나 손실될 수 있습니다.

엔터프라이즈 측에서 시작했을 때 일부 주력 제품의 제품 페이지에서 10MB 이미지를 본 기억이 납니다. 그것은 내 마음을 날려 버렸다.

웹에서 이미지가 10MB일 필요는 없습니다. 마침표.

그래서 디자이너들과 섬세한 대화를 나누었고 약 8개월 동안 이미지 크기를 줄이기 위해 함께 작업했습니다.

100KB는 내가 기꺼이 죽을 수 있는 언덕이 아니었기 때문에 디자이너에게 제목 배너 또는 프레임에 대해 100KB를 말하고 그들이 300KB로 가져왔다면 여전히 개선된 것입니다.

엔터프라이즈 SEO는 종종 점진적인 승리에 관한 것입니다.

분석가와 협력

분석가는 웹사이트의 태깅 시스템과 모든 타사 태그를 관리할 것이기 때문에 대화에 참여합니다.

이 특정 태그가 중요한지 또는 대안이 있는지에 대해 태그 소유자와 대화를 나누는 진입점입니다.

제3자 스크립트는 웹사이트에 막대한 부풀림을 유발할 수 있기 때문입니다.

따라서 사이트에서 250개 이상의 광고 스크립트에 대해 대화를 나누는 동안 모든 스크립트가 필요한 경우 다음과 같은 단기적인 절충안을 찾을 수 있습니다.

  • 적극적으로 히트맵이 지정되거나 추적되는 페이지에서만 HotJar, Fullstory 또는 다른 사용자 경험 모니터링 스크립트를 실행합니다.
  • 중복에 대한 구현을 감사합니다(상상하는 것보다 더 많이 발생합니다).
  • 페이지가 로드될 때가 아니라 클릭 시 실행할 수 있는 챗봇 또는 고객 서비스 태그를 확인합니다.

QA 팀과 협력

이 파트너십은 당신에게 비밀 무기가 될 수 있습니다. 일반적으로 SEO뿐만 아니라 JavaScript SEO에도 다음과 같은 이진 예/아니요 요구 사항 또는 모범 사례가 많이 있습니다.

  • 메타 데이터는 페이지 소스와 클라이언트 측 렌더링 페이지 간에 동일해야 합니다.
  • Canonical은 클라이언트 측 렌더링 페이지에 있어야 합니다.
  • 링크는 <버튼>이 아닌 <a href=””> 형식이어야 합니다.
  • 글꼴 미리 로드
  • 대규모 리소스에 사전 연결

QA 팀과 함께 좋은 책을 읽고 그들과 협력(교육 포함)하여 일반적인 일상적인 QA 프로세스의 일부로 포함하십시오. 당신은 어디에서나 눈을 뜨고 잠재적으로 대규모 마이크로 지지자 네트워크를 갖게 될 것입니다.

웹 사이트의 SEO를 전반적으로 개선하기 위해 협력할 수 있는 다른 팀이 많이 있지만, 구현의 보다 기술적인 측면에서 가장 많이 협력하게 될 팀은 이들 팀일 것입니다.

함께 일하는 다른 팀 옹호

사람들이 사람이라는 것을 기억할 때 사람들과 함께 일하는 방식에 대해 이전에 내가 말한 것을 기억하십니까? 당신은 그것을 행동으로 옮기고 싶습니다.

엔터프라이즈 수준에서 이를 수행하는 두 가지 강력한 방법이 있습니다.

시간 존중

"서버측 렌더링으로 마이그레이션해야 한다"와 같은 큰 아이디어가 있다고 가정해 보겠습니다.

이 경우 PO에 가서 "이 모든 것을 할 수 있습니까?"라고 말하는 대신 그들과 협력하여 "쉬운" 버킷에 속하는 것으로 검증된 개념 증명을 만들고 그 영향을 추적합니다. .

작동하지 않는다면 이 대규모 프로젝트를 완료하기 위해 기본적으로 20개의 스프린트를 낭비하지 않은 것입니다.

작동하는 경우 재무 팀에 가져갈 비즈니스 사례가 있어 나머지 프로젝트에 자금을 지원하고 우선 순위를 지정하여 전체 웹 사이트에 적용하고 헌신적인 부족을 확보하여 완료하는 데 2백만 달러와 1년 반이 소요됩니다. .

그들의 노력을 증폭

SEO가 잘 못하는 것으로 악명이 높은 것은 성공을 전달하고 공유하는 것입니다.

"내가 한 이 멋진 일을 봐"라고 말하는 대신 "이봐 내가 밀접하게 일한 이 다른 팀이 한 이 놀라운 일을 보세요. 사이트 경험이 크게 향상되었습니다.”

SEO인 당신은 더 이상 관심의 대상이 아닙니다. 실제 작업을 한 팀은.

협업, 옹호 및 점진적인 승리

이 기사에서 JavaScript의 뉘앙스와 사이트 속도에 대해 실제로 너무 많이 말하지 않았다는 것을 알 수 있습니다.

엔터프라이즈 회사에서는 문제와 해결책의 형태를 가지고 갈 수 있는 정말 똑똑한 사람들과 함께 일할 가능성이 높기 때문입니다.

SEO 간행물의 기사보다 더 나은 결과를 얻을 수 있도록 도와줄 수 있습니다.

기업 수준에서 작업을 수행하는 것은 "무엇"이 아니라 "방법"에 관한 것입니다.

따라서 이 가이드라인을 사용하여 JavaScript 기반 웹 사이트의 사이트 속도를 개선하기 위한 "방법"을 파악하고 "무엇"이 훨씬 원활하게 이루어질 것인지 확인하십시오.


이 기사에 표현된 의견은 게스트 작성자의 의견이며 반드시 검색 엔진 랜드가 아닙니다. 교직원 저자는 여기에 나열됩니다.