JavaScript SEO: 서버 측 렌더링의 함정 피하기
게시 됨: 2019-11-06JavaScript SEO는 현재 SEO 업계에서 가장 뜨거운 주제 중 하나입니다. 현대 웹이 진화하고 점점 더 많은 웹사이트가 재실행되거나 JavaScript 기반 웹 애플리케이션(주로 React 또는 AngularJS를 기반으로 함)에 구축되기 때문입니다. 이를 통해 페이지의 색인을 생성하고 순위를 올바르게 지정할 수 있도록 Google이 JavaScript를 효과적으로 렌더링할 수 있는지 확인해야 하므로 SEO에 더 많은 복잡성이 추가됩니다. 이것은 서버 측 렌더링을 사용하여 달성할 수 있습니다. 그러나 이것은 위험하지 않습니다. 이 기사에서는 5가지 서버 측 렌더링 실수를 살펴보고 이를 방지할 수 있는 방법을 설명합니다.
웹 사이트의 기술 최적화에 대한 지원을 찾고 있다면 Digital Strategies Group 컨설턴트와 구속력이 없는 약속을 잡고 어디에서 도움을 받을 수 있는지 알아보십시오.
약속을 요청하세요!
서버 측 렌더링에는 어떤 종류가 있습니까?
서버에서 Google용 웹사이트를 사전 렌더링(서버 측 렌더링, SSR)하는 것은 JavaScript 웹사이트가 Googlbot 친화적인지 확인하는 한 가지 옵션입니다. 이러한 방식으로 웹사이트의 미리 렌더링된 HTML 버전을 Google에 전달할 수 있고 사용자는 아직 렌더링되지 않은 일반 브라우저 버전을 받을 수 있습니다.
그러나 서버 측 렌더링의 경우 Jan-Willem Bobbink의 몇 가지 유용한 추가 기능과 함께 Google에서 유용하게 제공한 다음 차트에서 볼 수 있듯이 다양한 렌더링 방법이 있습니다.
서버 측 렌더링을 설정하고 실행하는 세 가지 주요 방법이 있습니다.
1. 동적 HTML을 사용한 서버 측 렌더링
서버 측 렌더링은 요청 시 각 URL의 렌더링된 HTML 버전을 생성합니다.
2. 정적 HTML을 사용한 정적 렌더링
기본적으로 이것은 미리 렌더링된(정적) HTML 버전의 URL을 미리 만들어 캐시에 저장합니다.
3. 동적 HTML 및 JS/DOM을 사용한 (재)수화를 통한 서버 측 렌더링
서버는 이미 구조화된 DOM(Document Object Model) 마크업을 포함하는 URL 및 클라이언트(브라우저 등)의 정적 HTML 버전을 제공합니다. 클라이언트는 이것을 가져와 클라이언트 측 변경 사항에 반응할 수 있는 동적 DOM으로 변환하고 더 대화식으로 만듭니다.
Google은 모든 장단점과 함께 웹 렌더링에 대한 훌륭한 개요와 관심이 있는 경우 더 자세한 설명을 게시했습니다. 그러나 우선 JavaScript SEO 또는 서버 측 렌더링 주제에 대한 도움을 찾고 있다면 여기 Searchmetrics Digital Strategies Group에 문의하십시오.
연락해!
서버를 통해 JavaScript 웹사이트를 렌더링할 때의 함정
우리는 최근에 고객 중 한 명과 함께 몇 가지 SSR 문제를 발견했습니다. 그들은 Angular JS에서 웹사이트를 실행하고 Headless Chrome을 통해 Rendertron으로 렌더링합니다.
정적 SSR 렌더링 접근 방식을 사용합니다. 즉, 페이지를 렌더링하고 렌더링된 HTML을 서버에 미리 캐시합니다. 캐시된 HTML은 자동으로 대체되지 않지만 렌더링 논리를 기반으로 합니다. 다음은 이 웹사이트에서 작업하면서 발생한 5가지 문제입니다. 비슷한 문제가 있는 경우 대처 방법을 알 수 있도록 여기에서 공유하고 있습니다. 그러나 이것은 미완성/확장 가능한 목록으로 간주될 수 있습니다.
1. 아무것도 하지 않을 때
Google이 페이지를 렌더링하는 방식에 관심이 없고 주의를 기울이지 않을 때 Google이 페이지를 렌더링(실제로 보는) 방법을 보여드리겠습니다. 이것은 서버 측 렌더링 없이 JavaScript 프레임워크를 사용하는 단일 페이지 애플리케이션(SPA)에 구축된 웹사이트를 기반으로 합니다.
이것은 특히 유망해 보이지 않습니다. 그렇죠? 이것이 바로 SSR을 사용하는 것이 중요한 이유입니다. 그 이유는 다음과 같습니다.
2 . 쪽수 매기기
렌더링과 관련하여 페이지가 매겨진 페이지를 처리하는 방법은 무엇입니까? 글쎄, 특히 게시에서 페이지를 매긴 페이지는 Google이 크롤링하는 동안 (가장 최근) 기사를 Google에 제공하는 데 여전히 좋은 방법일 수 있습니다. 로그 파일을 보면 Google이 페이지 매김에 액세스하는 방법을 알 수 있으므로 미리 렌더링된 버전을 제공하는 것이 적절한 위치를 알 수 있습니다(스포일러: 렌더링된 버전과 함께 399개의 URL을 제공할 필요가 없습니다. )
클라이언트가 정적 SSR 접근 방식으로 렌더링할 때 첫 번째 페이지를 렌더링하고 페이지 1의 캐시된 버전을 10페이지까지 미러링했습니다. 11페이지부터 렌더링된 버전이 없습니다. 다음은 문제를 잘 보여주는 두 개의 스크린샷입니다. 1페이지와 정확히 동일한 내용이 2-10페이지에도 제공됩니다.
즉, 동일한 콘텐츠와 기사가 포함된 10개의 페이지를 Google에 제공합니다. 이상적으로는 Google이 올바르게 페이지가 매겨진 기사로 모든 페이지를 고유한 것으로 렌더링하기를 원합니다.
삼 . 새 기사/제품이 게시된 후 카테고리 페이지의 렌더링된 버전 갱신
저희 클라이언트는 게시자 캐러셀을 제외하고 AMP 캐러셀, Google 뉴스 상자 및 모바일 뉴스 상자와 같은 거의 모든 Google 뉴스 속성에서 순위를 상당히 높였습니다. 우리는 이것을 조사하기 시작했고 새로운 기사가 게시되었을 때 우리 클라이언트가 캐시된 버전을 업데이트하지 않은 것으로 나타났습니다. 우리는 그들이 일주일 후에 주요 카테고리의 캐시된 버전을 갱신했다는 것을 알게 되었습니다.
그리고 한 달 뒤에도 하위 카테고리에서.
이로 인해 사전 렌더링된 버전에 여전히 Brexit 주제에 대한 이전 기사가 있었지만 해당 주제에 대한 모든 새 기사가 게시되지는 않았습니다. 여기에서 우리는 이 문제로 인해 Google이 캐러셀을 채울 수 있는 새로운 기사가 충분하지 않아 실적에 큰 부정적인 영향을 미쳤다고 가정합니다. 우리는 여전히 변경 사항의 영향을 조사하고 있습니다.
4 . 렌더링으로 인해 콘텐츠가 중복되고 정규화가 잘못될 수 있습니다.
미리 렌더링된 버전의 URL을 제공하면 시스템 기반 문제가 발생할 수 있습니다. 우리 클라이언트가 렌더링 엔진에 의해 생성된 고유한 URL이 있는 미리 렌더링된 페이지를 제공함에 따라 이러한 URL에는 "p=1; render=1”이고 완전히 인덱싱 가능:
해당 URL에 대해 SSR 엔진이 설정한 새로운 표준도 있었습니다. 꽤 으스스하죠?
이상적으로는 Google 크롤링에서 이러한 매개변수를 제외하는 것이 좋습니다.
5 . 렌더링 시 페이지 제목 변경
또한 현재 페이지 제목이 JavaScript를 통해 렌더링되었음을 알았습니다. 이것은 JavaScript가 비활성화되었을 때 HTML 메타 제목이 항상 브랜드 이름을 표시함을 의미하는 방식으로 수행되었습니다. 그리고 사용자 에이전트가 Googlebot이 아닌 경우 HTML 페이지 제목만 렌더링합니다. 아래의 두 가지 예를 참조하십시오. 첫 번째는 JavaScript가 비활성화된 URL을 보여줍니다. 두 번째는 동일한 URL이지만 JavaScript가 활성화되어 있습니다.
메타데이터가 항상 올바르게 렌더링되도록 하려면 URL의 렌더링되지 않은(JavaScript) 버전에 메타데이터를 포함해야 합니다.
결론
서버 측 렌더링은 단일 페이지 응용 프로그램을 렌더링하기 위한 쿠키 커터 접근 방식으로 사용할 수 없습니다. 스냅샷만 제공하는 정적 접근 방식에는 특별한 주의가 필요합니다. 고객의 예에서 볼 수 있듯이 SSR 엔진이 항상 최신 버전의 URL을 제공하는지 확인해야 합니다. 그렇지 않으면 Google에서 가장 최근 기사를 보고 캡처하지 않으며 소중한 트래픽을 놓치고 있습니다.
HTML 기반 웹사이트에서 JavaScript 기반 프레임워크로 다시 시작하기 전에 서버 측 렌더링이 포함되어 있고 항상 동적으로 제공되는지 확인하십시오!
JavaScript 문제가 있거나 웹 사이트의 기술 최적화에 대한 지원을 찾고 있다면 Digital Strategies Group 컨설턴트와 구속력이 없는 약속을 잡고 어디에서 도움을 받을 수 있는지 알아보십시오.
약속을 요청하세요!