분류 javascript

초보자를 위한 JavaScript SEO 모범 사례 가이드

컨텐츠 정보

  • 조회 293 (작성일 )

본문

웹 사이트가 클라이언트 측에서 렌더링 된 자바 스크립트에 크게 의존하는 경우 검색 엔진이 이를 효율적으로 크롤링하고 색인을 생성하는 데 어려움을 겪고 있습니다. 대부분의 경우 이는 사이트 순위가 좋지 않음을 의미합니다.


Google이 JavaScript 사이트를 처리하는 방법과 JavaScript 사이트가 다른 사이트와 마찬가지로 성능을 발휘하도록 적용 할 수 있는 모범 사례에 대해 알아보십시오.


JavaScript SEO 란 무엇입니까? 


자바 스크립트 SEO는 자바 스크립트 기반 웹 사이트가 검색 엔진에서 잘 작동하도록 하기 위해 필요한 모든 것을 포함합니다. 기술 SEO 내의 전문화라고 생각하십시오.


왜 중요함? 


개발자는 JavaScript가 훌륭하다고 말하고 AngularJS, Vue, Backbone 또는 React에 대해 열광합니다. 사람들이 좋아하는 대화 형 웹 페이지를 만들 수 있기 때문에 JavaScript를 좋아합니다.


SEO는 자바 스크립트가 SEO 성능에 종종 끔찍하다는 것을 알려줄 것이며, 사이트가 클라이언트 측에 의존하기 시작한 후 급격히 감소하는 유기적 트래픽을 보여주는 차트를 빠르게 끌어 올리면서 자바 스크립트가 그들에게 직업 보안이라는 말까지 할 것입니다. 표현.


둘 다 맞습니다.


동시에 개발자와 SEO가 생산적으로 협력하면 훌륭한 결과를 얻을 수 있습니다. 방문자와 검색 엔진 모두에게 최상의 경험을 제공하는 데 집중할 때 JavaScript 기반 웹 사이트도 검색에서 매우 잘 수행 될 수 있습니다.


자바 스크립트 기반 웹 사이트가 검색에서 잘 작동하려면 검색 엔진이 페이지의 내용과 초기 HTML 응답에서 크롤링 및 색인 생성 가이드 라인이 무엇인지 완전히 이해할 수 있어야 합니다.


그러나 JavaScript는 무엇입니까? 


물어봐 주셔서 감사합니다! JavaScript는 브라우저 내에서 로컬로 실행되는 웹용 프로그래밍 언어입니다. 웹 페이지에 활기를 불어 넣는 데 사용됩니다. 예를 들어 알림을 전달하고, 웹 사이트를 맞춤 설정하고, 콘텐츠 업데이트를 자동으로 가져 오거나, 페이지 하단에 거의 도달 할 때 새 콘텐츠를 로드하는 데 사용됩니다.


가장 많이 방문한 웹 사이트는 JavaScript에 크게 의존하여 작동합니다!


Twitter, Facebook, Instagram, YouTube, Netflix 등 모두 JavaScript를 사용합니다.


또한 귀하의 사이트에서 자바 스크립트를 사용하지 않을 가능성이 거의 없습니다. 어디에나 있고 사라지지 않습니다. JavaScript 채택은 더 이상 증가 할 것입니다.


2019 년 설문 조사에서 67.8 %의 개발자가 자바 스크립트를 사용하고 있다고 답했습니다. GitHub는 그 인기를 확인하고 몇 년 동안 계속해서 가장 인기 있는 프로그래밍 언어임을 보여줍니다.


JavaScript는 SEO 성능에 어떤 영향을 줍니까? 


JavaScript에 크게 의존하는 웹 페이지는 느리게 인덱싱 됩니다. 그 이유를 설명하기 전에 먼저 HTTP 요청이 작동하는 방식과 JavaScript가 웹 페이지에 미치는 영향에 대해 알아봐야 합니다.


HTTP 요청 작동 방식 


URL로 이동하면 브라우저가 서버에서 URL의 콘텐츠를 요청합니다. 요청이 성공하면 서버는 해당 URL에 대한 HTML 문서로 응답합니다. 이 HTML 문서에는 이미지, CSS 및 JavaScript (있는 경우)와 같은 외부 파일에 대한 참조와 함께 텍스트가 포함되어 있습니다. 그렇다면 브라우저는 이러한 파일에 대한 별도의 추가 요청도 생성합니다.


JavaScript 실행이 시작됩니다. 


다음 단계는 브라우저가 DOM을 구성하고 웹 페이지 렌더링을 시작하는 것입니다. 이 프로세스의 일부는 DOM을 수정하는 JavaScript 코드를 실행하는 것입니다. 이는 작은 수정 (예 : 지원 채팅로드) 또는 큰 수정 (예 : 페이지의 모든 콘텐츠로드) 일 수 있습니다.


페이지가 브라우저에 나타나고 상호 작용할 수 있습니다. 그러나 DOM을 많이 수정하는 JavaScript 렌더링은 페이지가 방문자와 상호 작용하는 데 걸리는 시간을 몇 초 더 늘릴 수 있습니다.


이러한 수정 사항을 DOM 클라이언트 측 렌더링 (줄여서 'CSR')이라고 합니다. 이 경우 클라이언트 측에서 수행되는 자바 스크립트 렌더링 (이 경우에는 브라우저)입니다. JavaScript 렌더링은 가져와야 하는 많은 콘텐츠, 만들어야 하는 많은 추가 요청, 비효율적 인 코드 등 다양한 이유로 느려질 수 있습니다.


예를 들어, 많은 WordPress 테마는 JavaScript 라이브러리를 많이 로드 하기 때문에 (종종 필요하지 않은) JavaScript로 끔찍하게 부풀어 있습니다. Google의 Lighthouse는 대체 자바 스크립트 라이브러리를 제안하기 까지 합니다.


DOM이란 무엇입니까? 


위에서 우리는“DOM”을 언급했습니다. DOM은 웹 페이지의 객체 지향 표현이며 JavaScript와 같은 프로그래밍 언어를 사용하여 수정할 수 있습니다.


DOM tree explained 


DOM은 Document Object Model을 나타냅니다.


문서 : 웹 페이지입니다.

개체 : 웹 페이지의 모든 요소 (예 : <head> </ head>, <body> </ body>, <title> </ title>, <h1> </ h1> 및 <p> </ p>) .

모델 : 문서 내의 계층 구조를 설명합니다 (예 : <title> </ title>은 <head> </ head>로 이동).


이것이 제시하는 문제 


브라우저가 웹 페이지를 완전히 렌더링 하는 데 몇 초가 걸리고 페이지 소스에 본문 내용이 많지 않은 경우 검색 엔진은 이 페이지가 무엇인지 어떻게 파악할까요?


브라우저가 방금 한 것과 비슷하게 페이지를 렌더링 해야 하지만 화면에 표시 할 필요가 없습니다. 검색 엔진은 소위 "헤드리스 브라우저"를 사용합니다.


HTML을 다운로드하는 것과 비교할 때 JavaScript 렌더링은 리소스를 많이 사용합니다 (100 배 더 비쌉니다). 그렇기 때문에 검색 엔진은 방문하는 모든 페이지를 렌더링 하지 않습니다.


2016 년 7 월에 Google은 130 조 개가 넘는 문서를 발견했다고 밝혔으며 그 이후로 문서의 양이 엄청나게 증가했다고 말하는 것이 안전합니다.


Google은 이러한 모든 페이지를 렌더링 할 수 있는 능력이 없습니다. 이러한 페이지를 모두 크롤링 할 수 있는 능력도 없기 때문에 모든 웹 사이트에 크롤링 예산이 할당되어 있습니다.


웹 사이트에는 할당 된 렌더링 예산도 있습니다. 이를 통해 Google은 렌더링 작업의 우선 순위를 지정할 수 있습니다. 즉, 방문자가 더 자주 검색 할 것으로 예상되는 페이지를 렌더링 하는 데 더 많은 시간을 할애 할 수 있습니다.


이로 인해 신뢰성이 높은 JavaScript 웹 페이지의 색인이 "일반"HTML 페이지보다 훨씬 느리게 생성됩니다. 웹 페이지의 색인이 생성되지 않으면 순위가 매겨지지 않으며 자연 트래픽도 발생하지 않습니다.


Google은 JavaScript 사이트를 어떻게 처리합니까? 


Google's crawling, indexing, rendering and ranking pipeline 



위의 그림은 크롤링에서 순위 지정에 이르는 Google의 프로세스를 개념적으로 설명합니다. 매우 단순화되었습니다. 실제로 수천 개의 하위 프로세스가 관련됩니다.


프로세스의 모든 단계를 설명합니다.


  1. 크롤링 대기열 : 크롤링해야 하는 모든 URL을 추적하며 지속적으로 업데이트 됩니다.
  2. 크롤러 : 크롤러 ( 'Googlebot')가 크롤링 대기열에서 URL을 수신하면 HTML을 요청합니다.
  3. 처리 : HTML이 분석되고 a) 발견 된 URL은 크롤링을 위해 크롤링 대기열로 전달됩니다. b) 색인 생성의 필요성이 평가됩니다. 예를 들어 HTML에 메타 로봇 ​​noindex가 포함 된 경우 색인이 생성되지 않고 렌더링 되지 않습니다. HTML에서 새로운 내용과 변경된 내용도 확인합니다. 콘텐츠가 변경되지 않은 경우 색인이 업데이트 되지 않습니다. c) 렌더링의 필요성은 페이지의 자바 스크립트 의존도를 기반으로 평가됩니다. 렌더링해야 하는 URL이 렌더링 대기열에 추가됩니다. Google은 렌더링이 진행되는 동안 이미 초기 HTML 응답을 사용할 수 있습니다. d) URL이 정규화 됩니다 (이는 정규 링크 요소를 넘어선다는 점에 유의하십시오. 예를 들어 XML 사이트 맵 및 내부 링크와 같은 다른 정규화 신호도 고려됩니다).
  4. 렌더링 대기열 : 렌더링해야 하는 모든 URL을 추적하며 크롤링 대기열과 유사하며 지속적으로 업데이트 됩니다.
  5. 렌더러 : 렌더러 (웹 렌더링 서비스 또는 줄여서 "WRS")가 URL을 수신하면 URL을 렌더링하고 처리를 위해 렌더링 된 HTML을 다시 보냅니다. 3a, 3b 및 3d 단계가 반복되지만 이제 렌더링 된 HTML을 사용합니다.
  6. 색인 : 콘텐츠를 분석하여 관련성, 구조화 된 데이터 및 링크를 결정하고 PageRank 및 레이아웃을 (재) 계산합니다.
  7. 순위 : 순위 알고리즘은 색인에서 정보를 가져와 Google 사용자에게 가장 관련성이 높은 결과를 제공합니다.


따라서 Google이 자바 스크립트에 의존하는 웹 페이지를 이해하려면 직접 할 수 있는 대신 전체 렌더링 단계를 거쳐야 합니다.


  1. 크롤링해야 하는 URL을 크롤링 대기열로 전달하고
  2. 색인화해야 하는 정보를 색인 단계로 전달합니다. 이로 인해 전체 크롤링 및 인덱싱 프로세스가 매우 비효율적이고 느려집니다.


Google이 이중 패스를 수행하고 모든 페이지를 렌더링해야 하는 50,000 페이지의 사이트가 있다고 상상해보십시오. 이는 크게 떨어지지 않으며 SEO 성능에 부정적인 영향을 미칩니다. 콘텐츠가 유기적 트래픽을 유도하고 ROI를 제공하는 데 시간이 오래 걸립니다.


계속 읽으면 이 문제를 해결하는 방법을 배우게 됩니다.


프로 팁 


크롤링 예산을 유지하기 위해 CSS 및 자바 스크립트 파일을 차단하지 마세요. 이렇게 하면 검색 엔진이 페이지를 렌더링 하지 못해 검색 엔진이 페이지를 제대로 이해하지 못하고 SEO 성능이 저하 될 수 있습니다. 


모범 사례 


페이지를 렌더링해야 하는 검색 엔진 방지 


초기 HTML 응답을 기반으로 검색 엔진은 페이지의 내용과 크롤링 및 색인 생성 지침이 무엇인지 완전히 이해할 수 있어야 합니다. 그렇지 않다면 페이지 순위를 경쟁적으로 올리는 데 어려움을 겪을 것입니다.


초기 HTML 응답에 필수 콘텐츠 포함 


페이지가 검색 엔진에 의해 렌더링 되는 것을 막을 수 없다면 최소한 HTML의 <head> 섹션에 들어가는 제목 및 메타 요소와 같은 필수 콘텐츠와 중요한 본문 콘텐츠가로드되었는지 확인하세요. JavaScript를 통해.


초기 HTML 응답에 포함되어야 합니다. 이를 통해 Google은 페이지에 대한 좋은 첫인상을 얻을 수 있습니다.


탭 콘텐츠 


이는 탭 콘텐츠에도 적용됩니다. 예를 들어 제품 세부 정보 페이지에서 탭 뒤에 숨겨진 콘텐츠가 초기 HTML 응답에 포함되어 있고 가져 오기 위해 자바 스크립트 코드를 실행할 필요가 없는지 확인합니다.


모든 페이지에는 고유 한 URL이 있어야 합니다. 


사이트의 모든 페이지에는 고유 한 URL이 있어야 합니다. 그렇지 않으면 Google은 귀하의 사이트를 탐색하고 귀하의 페이지가 순위를 매기는 데 필요한 것을 파악하는 데 정말 어려움을 겪을 것입니다.


URL에서 조각을 사용하여 새 페이지를 로드 하지 마세요. Google은 대부분 이를 무시합니다. 방문자가 https : //example.com#about-us에서 "회사 소개"페이지를 확인하는 것은 좋지만 검색 엔진은 종종 해당 부분을 무시하므로 해당 URL에 대해 알지 못합니다.


초기 HTML 응답에 탐색 요소 포함 


모든 탐색 요소는 HTML 응답에 있어야 합니다. 기본 내비게이션을 포함하는 것은 쉬운 일이 아니지만 중요한 문맥 링크가 포함 된 사이드 바와 바닥 글을 잊지 마세요.


특히 전자 상거래에서는 페이지 매김이 중요합니다. 무한 스크롤링은 멋진 사용자 경험을 제공하지만 페이지와 상호 작용하지 않기 때문에 검색 엔진에는 적합하지 않습니다. 따라서 추가 콘텐츠를 로드하는 데 필요한 이벤트를 트리거 할 수 없습니다.


다음은 Google에서 탐색 링크를 찾기 위해 페이지를 렌더링해야 하므로 피해야 할 사항의 예입니다.


<a onclick="goto('https://example.com/schoes/')"> 


대신 다음을 수행하십시오.


<a href="https://example.com/shoes/"> 


명확하고 모호하지 않은 인덱싱 신호 보내기 


Google은 사이트 소유자에게 명확하고 모호하지 않은 크롤링 및 색인 생성 신호를 보낼 것을 촉구합니다. 여기에서는 몇 가지 지침을 살펴보고 JavaScript SEO를 처리 할 때 명확하게 의사 소통하는 것이 그 어느 때보 다 중요한 이유를 설명합니다.


메타 로봇 ​​지침 


JavaScript를 사용하여 메타 로봇 ​​지시문을 덮어 쓰면 문제가 발생합니다. 그 이유는 다음과 같습니다.


색인으로 덮어 쓴 초기 HTML 응답에 <meta name = "robots"content = "noindex, follow"/>가 포함 된 경우 JavaScript를 사용하여 값을 따르십시오. 그러면 Google에서 이에 대해 알 수 없습니다. NOINDEX를 보고 귀중한 렌더링 리소스를 사용하지 않기로 결정했기 때문입니다.


또한 NOINDEX가 색인으로 변경된 사실을 발견하더라도 Google은 일반적으로 가장 제한적인 지침 인이 경우 NOINDEX를 준수합니다.


하지만 반대로 <meta name = "robots"content = "index, follow"/>를 사용하고 JavaScript를 사용하여 해당 색인을 noindex로 변경하면 어떻게 될까요?


이 경우 Google은 초기 HTML 응답에 따라 허용되기 때문에 페이지 색인 만 생성 할 가능성이 높습니다. 그러나 페이지가 렌더링 된 후에야 Google은 NOINDEX에 대해 알아 내고 색인에서 페이지를 제거합니다. (짧은) 기간 동안 색인 생성을 원하지 않는 페이지는 실제로 색인이 생성되고 순위가 매겨졌습니다.


표준 링크 


표준 링크를 덮어 쓰면 똑같이 혼란이 생깁니다.


2018 년 5 월 John Mueller는“우리는 (현재) 처음에 가져온 렌더링 되지 않은 버전에서만 rel = canonical을 처리합니다.”라고 말했습니다. 그리고 Martin Splitt은 2020 년 11 월에 이 "정의되지 않은 동작"이 Google 측에서 추측으로 이어진다 고 말했습니다. 이는 실제로 피해야 할 일입니다. 


자바 스크립트를 통해 표준 링크를 삽입하면 Google이 페이지를 크롤링 하고 렌더링 한 후에 만 ​​표준 링크에 대해 알아내는 상황이 발생합니다. 표준 링크가 초기 HTML 응답에 포함되지 않고 자바 스크립트를 통해 삽입 되었기 때문에 Google이 고유 한 URL이 있는 방대한 양의 맞춤 페이지를 크롤링하기 시작하는 경우를 보았습니다. 이는 크롤링 예산 낭비이므로 피해야 합니다.


rel=”nofollow” link attribute value 


JavaScript를 사용하여 링크에 rel = "nofollow"속성 값을 추가하는 경우에도 마찬가지입니다. Google의 크롤러는 이러한 링크를 추출하여 크롤링 대기열에 추가합니다. Google이 페이지를 렌더링 할 수있는 것보다 빨리 크롤링 되어 rel = "nofollow"가 발견되었습니다. 다시 말하지만 이것은 크롤링 예산 낭비이며 혼란으로 이어질 뿐입니다.


반대로 rel = "nofollow"링크 속성 값이 존재하고 자바 스크립트를 사용하여 제거하는 것은 Google이 가장 제한적인 지침을 따르기 때문에 메타 로봇 ​​지침과 유사하게 작동하지 않습니다.


기타 지침 


초기 HTML 응답에 다음과 같은 다른 지시문도 포함하는 것을 잊지 마십시오.



검색 엔진이 JavaScript 파일에 액세스하도록 허용 



검색 엔진이 robots.txt 파일을 통해 자바 스크립트 파일에 액세스하는 것을 실수로 막지 않도록 하여 검색 엔진이 페이지를 올바르게 렌더링하고 이해할 수 없게 하세요.


렌더링 차단 JavaScript 제거 


렌더링 차단 JavaScript는 웹 페이지의 렌더링 속도를 늦추는 JavaScript 코드입니다. 이것은 사용자 경험의 관점에서 나쁘지만 Google이 웹 페이지를 렌더링 하는 데 최대한 빠르고 고통스럽지 않게 만들고자 하는 SEO 관점에서도 좋지 않습니다. 결국 웹 페이지를 이미 렌더링 해야 할만큼 나쁘다.


추가 네트워크 요청을 피하려면 인라인 JavaScript를 사용하십시오. 또한 다음 섹션에 설명 된 대로 지연로드를 적용합니다.


코드 분할 및 지연로드 활용 


이 상황을 상상해보십시오. 귀하의 홈페이지는 JavaScript에 크게 의존하고 있으며 다른 모든 페이지는 JavaScript를 제한적으로 사용합니다. 그러면 사이트의 페이지가 요청 될 때 모든 '홈페이지 전용'자바 스크립트 파일을 로드하는 것은 매우 비효율적입니다.


그 위에 코드 분할을 적용하여 필요한 JavaScript를 즉시 로드하고 나머지는 지연로드 하십시오. 이렇게 하면 페이지가 빠르게 로드되고 상호 작용할 수 있습니다.


로딩 속성으로 이미지 지연 로딩 구현 


지연로드 이미지는 페이지로드 속도를 향상 시킬 수 있는 좋은 방법이지만 Google이 어떤 이미지가 포함되어 있는지 파악하기 위해 페이지를 완전히 렌더링 하지 않아도 됩니다.


loading 속성이 도입됨에 따라 더 이상 자바 스크립트를 통해 지연로드를 구현할 필요가 없습니다. Chromium 기반 브라우저 (Chrome, Edge 및 Opera)와 Firefox는 로딩 속성에 대한 기본 지원을 제공합니다.


loading 속성 예를 통해 포함 된 이미지는 아래를 참조하세요.


<img src="/images/cat.png" loading="lazy" alt="Black cat" width="250" height="250"> 


loading 속성을 통해 이미지를 포함하면 두 가지 장점을 모두 얻을 수 있습니다.


  • 검색 엔진은 HTML에서 이미지 URL을 직접 추출 할 수 있습니다 (렌더링 할 필요 없음).
  • 방문자의 브라우저는 이미지를 지연로드하는 것을 알고 있습니다.


JavaScript 캐싱을 활용하고 콘텐츠 해시를 사용합니다. 



웹 사이트의 사용자 경험에 영향을 주지 않기 위해 Google은 자바 스크립트를 적극적으로 캐시합니다. 자바 스크립트 코드가 너무 자주 변경되지 않는 경우 좋습니다.하지만 변경되면 어떻게 될까요? 그런 다음 Google에서 최신 버전을 신속하게 가져올 수 있어야 합니다.


다음과 같은 파일 이름을 포함하여 JavaScript 파일 이름에 콘텐츠 해시를 추가합니다.


  • main.2a846fa617c3361f.js
  • example.117e1c5c1e1838c3.js
  • runtime.9bdf68f2f1992a3d.js


JavaScript 코드가 변경되면 해시가 업데이트되고 Google은 요청이 필요하다는 것을 알고 있습니다.


모든 사람이 최신 iPhone을 가지고 있고 빠른 인터넷에 액세스 할 수 있다고 가정하지 마십시오. 


모든 사람이 최신 iPhone을 가지고 돌아 다니며 4G 및 강력한 WiFi 신호에 액세스 할 수 있다고 가정하는 실수를 하지 마십시오. 대부분의 사용자는 그렇지 않으므로 서로 다른 구형 기기와 느린 연결에서 사이트의 성능을 테스트해야 합니다. 실험실 데이터에만 의존하지 마십시오. 대신 필드 데이터에 의존하십시오.


렌더링 옵션 


이제 JavaScript 코드를 실행하기 위해 전적으로 클라이언트 (브라우저 또는 크롤러)에 의존하는 클라이언트 측 렌더링이 전체 크롤링, 색인 생성 및 순위 지정 프로세스에 부정적인 영향을 미친다는 것이 분명합니다.


그러나 이전 섹션에서 방금 다룬 JavaScript SEO 모범 사례 외에도 JavaScript가 SEO 성능을 저하 시키는 것을 방지하기 위해 취할 수 있는 추가 단계가 있습니다.


많은 렌더링 옵션 (예 : 사전 렌더링)이 있지만 모든 옵션을 다루는 것은 이 기사의 범위를 벗어납니다. 따라서 검색 엔진 (및 사용자)에게 더 나은 경험을 제공하는 데 도움이 되는 가장 일반적인 렌더링 옵션을 다룰 것입니다.


  • Server-side rendering
  • Dynamic rendering


Server-side rendering 


서버 측 렌더링은 웹 페이지를 클라이언트에 의존하여 렌더링 하는 대신 클라이언트 (브라우저 또는 크롤러)로 보내기 전에 서버에서 웹 페이지를 렌더링하는 프로세스입니다.


이 렌더링 프로세스는 실시간으로 발생하며 방문자 및 예를 들어 Googlebot은 동일하게 취급됩니다. JavaScript 코드는 여전히 활용할 수 있으며 초기 로드 후에 실행됩니다.


장점 


  • 검색 엔진에 중요한 모든 요소는 초기 HTML 응답에서 쉽게 사용할 수 있습니다.
  • 빠른 First Contentful Paint ( "FCP")를 제공합니다.


단점 


  • 서버가 웹 페이지를 즉시 렌더링해야 하기 때문에 첫 번째 바이트로 가는 시간 ( "TTFB")이 느립니다.

Dynamic Rendering 


동적 렌더링은 요청한 사람에 따라 서버가 다르게 응답 함을 의미합니다. 크롤러인 경우 서버는 HTML을 렌더링하고 이를 다시 클라이언트로 보내지 만 방문자는 클라이언트 측 렌더링에 의존해야 합니다.


이 렌더링 옵션은 해결 방법이며 일시적으로 만 사용해야 합니다. 클로킹처럼 들리지만 Google은 동적 렌더링이 두 요청 유형에 대해 동일한 콘텐츠를 생성하는 한 동적 렌더링 클로킹을 고려하지 않습니다.


Dynamic rendering explained 


장점 


  • 검색 엔진에 중요한 모든 요소는 검색 엔진에 전송 된 초기 HTML 응답에서 쉽게 사용할 수 있습니다.
  • 구현하는 것이 더 쉽고 빠릅니다.


단점 


  • 디버깅 문제를 더 복잡하게 만듭니다.

렌더링 된 페이지가 어떻게 보이는지 확인하려면 어떻게 합니까? 


Google의 모바일 친 화성 테스트를 사용하여 페이지를 가져오고 테스트하여 SCREENSHOT 탭에서 렌더링 된 페이지가 어떻게 보이는지 확인할 수 있습니다.


Screenshot of rendered page from Google's Mobile Friendly test tool 



스크린 샷에서 페이지가 잘리는 것에 대해 걱정하지 마십시오. 괜찮습니다. Google Search Console의 URL 검사 도구를 사용하여 렌더링 된 페이지가 어떻게 보이는지 확인할 수도 있습니다.


렌더링 된 HTML을 표시하는 HTML 탭에 액세스 할 수도 있습니다. 이것은 디버깅에 도움이 될 수 있습니다.


예산 렌더링 


Google I / O ‘18에서 Google의 Tom Greenaway는 다음과 같이 설명했습니다.


"Google 검색에서 JavaScript 파워 웹 사이트의 렌더링은 Googlebot이 해당 콘텐츠를 처리 할 수 있는 리소스를 확보 할 때까지 연기됩니다." 


그리고 상상할 수 있듯이 모든 웹 사이트가 동일하지는 않기 때문에 Google은 렌더링의 우선 순위를 설정해야 합니다. 따라서 웹 사이트에는 할당 된 렌더링 예산이 있습니다. 이를 통해 Google은 방문자가 더 자주 검색 할 것으로 예상되는 페이지를 렌더링 하는 데 더 많은 시간을 할애 할 수 있습니다.


이로 인해 JavaScript에 크게 의존하는 웹 페이지가 "일반"HTML 페이지보다 훨씬 느리게 색인화 됩니다. 특히 이러한 웹 사이트가 마지막 렌더링 괄호에 속하는 경우 더욱 그렇습니다.


소셜 미디어 크롤러는 어떻습니까? 


Facebook, Twitter, LinkedIn 및 Slack과 같은 소셜 미디어 크롤러는 의미 있는 스니펫을 생성 할 수 있도록 HTML에도 쉽게 액세스 할 수 있어야 합니다.


페이지의 OpenGraph, Twitter 카드 마크 업을 찾을 수 없거나 사용할 수 없는 경우 제목 및 메타 설명을 찾을 수 없는 경우 스니펫을 생성 할 수 없습니다. 즉, 스니펫이 나빠 보일 것이며 이러한 소셜 미디어 플랫폼에서 많은 트래픽을 얻지 못할 가능성이 높습니다.



SEO