Vue.js와 SEO: 검색 엔진과 봇을 위한 반응형 웹사이트를 최적화하는 방법

반응형 JavaScript 프레임워크(예: React, Vue.js 및 Angular)는 최근 대세이며 유연성, 모듈성 및 자동화된 테스트의 용이성으로 인해 점점 더 많은 웹사이트와 애플리케이션에서 사용되고 있습니다.

이러한 프레임워크를 사용하면 웹사이트나 앱에서 이전에는 상상할 수 없었던 새로운 것을 달성할 수 있지만 SEO 측면에서 어떻게 수행됩니까? 이러한 프레임워크로 만든 페이지가 Google에서 색인을 생성합니까? 이러한 프레임워크를 사용하면 페이지 렌더링의 전부 또는 대부분이 JavaScript로 수행되기 때문에(봇이 다운로드하는 HTML은 대부분 비어 있음) 웹사이트를 검색 엔진 또는 일반적으로 봇에 의해 구문 분석됩니다.

이 기사에서는 Vue.js가 내가 가장 많이 사용한 프레임워크이고 주요 프로젝트에서 검색 엔진의 인덱싱 측면에서 직접적인 경험이 있기 때문에 주로 Vue.js에 대해 이야기하겠습니다. 내가 다룰 내용은 다른 프레임워크에도 유효합니다.

문제에 대한 몇 가지 배경

인덱싱 작동 방식

Google에서 웹사이트의 색인을 생성하려면 각 페이지 내의 링크를 따라가는 Googlebot(웹사이트를 방문하여 페이지 콘텐츠를 색인에 저장하는 자동 색인 생성 소프트웨어)에서 크롤링해야 합니다. 또한 Googlebot은 웹사이트에서 특수 Sitemap XML 파일을 찾아 공개 사이트에서 올바르게 연결되지 않았을 수 있는 페이지를 찾고 웹사이트의 페이지가 얼마나 자주 변경되고 언제 마지막으로 변경되었는지에 대한 추가 정보를 받습니다.

약간의 역사

몇 년 전까지(2009년 이전) Google은 JavaScript로 생성된 모든 콘텐츠를 제외하고 웹사이트의 HTML 콘텐츠를 색인화했습니다. 중요한 링크와 콘텐츠는 Google에서 색인을 생성하지 않기 때문에 JavaScript로 작성해서는 안 되며, Google에서 웹사이트 소유자가 시도한 것처럼 "가짜 콘텐츠"로 간주할 수 있으므로 웹사이트에 불이익을 줄 수 있다는 것이 SEO의 일반적인 지식이었습니다. 사용자에게 검색 엔진에 표시된 것과 다른 것을 보여주고 검색 엔진을 속이려고 합니다.

예를 들어, 많은 SEO 친화적 콘텐츠를 HTML에 넣고 JavaScript로 숨기는 것은 사기꾼들의 매우 일반적인 관행이었습니다. Google은 항상 이러한 관행에 대해 경고했습니다.

"일반 사용자가 볼 수 있는 것과 다른 Googlebot 콘텐츠를 제공하는 것은 클로킹으로 간주되며 웹마스터 가이드라인에 위배됩니다."

이에 대해 불이익을 받을 수 있습니다. 경우에 따라 서버 측의 다른 사용자 에이전트에 다른 콘텐츠를 제공하는 것에 대해 처벌을 받을 수 있지만 페이지가 로드된 후 JavaScript를 통해 콘텐츠를 전환하는 경우에도 처벌을 받을 수 있습니다. 이것은 Google이 오랫동안 JavaScript를 실행하는 웹사이트를 색인화해 왔다는 것을 보여줍니다. 적어도 웹사이트의 최종 HTML(JavaScript 실행 후)과 색인을 위해 구문 분석한 원시 HTML을 비교하기 위해서입니다. 그러나 Googlebot은 항상 JavaScript를 실행하지 않았으며 Google은 색인 생성 목적으로 JavaScript 생성 콘텐츠를 사용하지 않았습니다.

그런 다음 웹 사이트에서 동적 콘텐츠를 제공하기 위해 AJAX 사용이 증가함에 따라 Google은 사용자가 AJAX 기반 웹 사이트를 인덱싱하는 데 도움이 되는 "AJAX 크롤링 체계"를 제안했습니다. 그것은 매우 복잡했습니다. 기본적으로 웹 사이트에서 AJAX 콘텐츠가 포함된 페이지 렌더링을 생성해야 했습니다. Google에서 요청하면 서버는 HTML 페이지에 포함된 JavaScript에 의해 동적으로 생성되었을 모든(또는 대부분) 콘텐츠가 포함된 페이지 버전을 제공합니다(콘텐츠의 HTML 스냅샷 으로 미리 렌더링됨). 서버 측 솔루션이 클라이언트 측에서 생성해야 하는 콘텐츠를 전달하도록 하는 이 프로세스는(다른 모든 목적을 위해) Google에서 색인된 JavaScript에 크게 의존하는 사이트를 갖고자 하는 사람들이 많은 과정을 거쳐야 함을 의미했습니다. 기술적인 번거로움.

예를 들어 AJAX에서 읽은 콘텐츠가 외부 웹 서비스에서 온 경우 동일한 웹 서비스 호출을 서버 측에서 복제하고 서버 측에서 클라이언트 측에서 생성했을 것과 동일한 HTML을 생성해야 했습니다. JavaScript — 또는 최소한 매우 유사한 것. 이것은 Node.js가 출현하기 전에 두 가지 다른 프로그래밍 언어(프론트엔드용 JavaScript와 PHP, Java, Python, Ruby 등)에서 동일한 렌더링 논리를 적어도 부분적으로 복제해야 했기 때문에 매우 복잡했습니다. 백엔드. 이것을 " 서버 측 렌더링 "이라고 하며 유지 관리 지옥으로 이어질 수 있습니다. 프론트엔드에서 콘텐츠를 렌더링하는 방법에 중요한 변경을 가한 경우 백엔드에서 해당 변경 사항을 복제해야 했습니다.

논리 중복을 피하기 위한 유일한 대안은 JavaScript를 실행하는 브라우저로 자체 사이트를 구문 분석하고 최종 결과를 서버에 저장하고 이를 Googlebot에 제공하는 것입니다. 이것은 현재 " 사전 렌더링 "이라고 불리는 것과 유사합니다.

Google(AJAX 크롤링 체계 사용)은 또한 이 경우 Googlebot과 사용자에게 서로 다른 콘텐츠를 제공하고 있기 때문에 불이익을 피할 수 있다고 보장했습니다. 그러나 2015년부터 Google은 웹사이트 관리자에게 다음과 같이 알리는 공식 블로그 게시물을 통해 이러한 관행을 더 이상 사용하지 않습니다.

"오늘날 Googlebot이 JavaScript 또는 CSS 파일을 크롤링하는 것을 차단하지 않는 한 일반적으로 최신 브라우저처럼 웹페이지를 렌더링하고 이해할 수 있습니다."

이것이 우리에게 말해주는 것은 Googlebot이 웹 페이지를 인덱싱할 때 갑자기 JavaScript를 실행할 수 있는 능력을 획득했다는 것이 아닙니다. 왜냐하면 그것이 아주 오랫동안(적어도 가짜 콘텐츠와 사기를 확인하기 위해) 그렇게 해왔다는 것을 알고 있기 때문입니다. 대신 JavaScript 실행 결과가 SERP에서 인덱싱되고 사용된다고 말했습니다.

이것은 우리가 더 이상 서버 측 렌더링 HTML을 Google에 제공하는 것에 대해 걱정할 필요가 없다는 것을 의미하는 것 같습니다. 그러나 JavaScript 프레임워크에 사용할 수 있는 서버 측 렌더링 및 사전 렌더링을 위한 모든 종류의 도구가 있지만 그렇지 않은 것 같습니다. 또한 큰 프로젝트에서 SEO 대행사를 다룰 때 사전 렌더링은 필수로 간주되는 것 같습니다. 어떻게 왔어요?

Google은 실제로 프론트엔드 프레임워크로 생성된 페이지를 어떻게 색인화합니까?

실험

프론트엔드 프레임워크로 만든 웹사이트에서 Google이 실제로 색인을 생성하는 내용을 확인하기 위해 약간의 실험을 했습니다. 모든 사용 사례를 다루지는 않지만 적어도 Google의 행동에 대해 더 많이 알아낼 수 있는 수단입니다. Vue.js로 작은 웹사이트를 구축했고 텍스트의 다른 부분을 다르게 렌더링했습니다.

웹사이트의 내용은 Infinite Jest Wiki에 있는 David Foster Wallace의 Infinite Jest 책 설명에서 가져왔습니다( 감사합니다! ). 전체 책에 대한 몇 가지 소개 텍스트와 개별 전기가 있는 등장인물의 목록이 있습니다.

• Vue.js 기본 컨테이너 외부에 있는 정적 HTML의 일부 텍스트.
• 일부 텍스트는 애플리케이션 코드에 이미 있는 변수에 포함되어 있기 때문에 Vue.js에 의해 즉시 렌더링 data .
• # 일부 텍스트는 data 개체에서 Vue.js에 의해 렌더링되지만 300ms의 지연이 있습니다.
• 캐릭터 바이오스는 샌드박스를 사용하여 의도적으로 구축한 휴식 API 세트에서 가져옵니다. Google이 웹사이트의 코드를 실행하고 페이지의 현재 상태에 대한 스냅샷을 찍기 위해 일정 시간 후에 중지할 것이라고 가정했기 때문에 각 웹 서비스가 증분 지연으로 응답하도록 설정했습니다. 첫 번째는 0ms, 두 번째는 300ms, 세 번째는 600ms 등으로 최대 2700ms입니다.

각 캐릭터 약력은 단축되고 Vue.js를 통해서만 사용할 수 있는 하위 페이지에 대한 링크를 포함합니다(URL은 기록 API를 사용하여 Vue.js에서 생성됨). 페이지를 직접 방문하면 서버에서 응답이 없음), 해당 항목도 인덱싱되었는지 확인합니다. 나는 이것이 서버 측을 렌더링하는 적절한 링크가 아니기 때문에 색인이 생성되지 않을 것이라고 가정했으며 Google이 사용자를 해당 링크로 직접 안내할 수 있는 방법이 없습니다. 그러나 나는 단지 확인하고 싶었다.

이 작은 테스트 사이트를 내 Github 페이지에 게시하고 인덱싱을 요청했습니다. 살펴보세요.

결과

실험 결과(홈페이지 관련)는 다음과 같다.

• 이미 정적 HTML 콘텐츠에 있는 콘텐츠는 Google에서 색인을 생성합니다(이는 다소 분명합니다).
• Vue에서 실시간으로 생성된 콘텐츠는 항상 Google에서 색인을 생성합니다.
• Vue에 의해 생성되었지만 300ms 후에 렌더링된 콘텐츠도 인덱싱됩니다.
• 웹 서비스에서 가져온 콘텐츠는 약간의 지연과 함께 인덱싱 될 수 있지만 항상 그런 것은 아닙니다. 다른 순간에 페이지의 Google 색인 생성을 확인했으며 마지막으로(몇 초 후) 삽입된 콘텐츠가 색인이 생성되는 경우도 있고 그렇지 않은 경우도 있습니다. 매우 빠르게 렌더링되는 콘텐츠는 외부 웹 서비스에 대한 비동기 호출에서 비롯된 경우에도 대부분의 경우 인덱싱됩니다. 이는 내부 알고리즘에 따라 달라지는 각 페이지 및 사이트에 대한 렌더링 예산 을 갖는 Google에 따라 달라지며 사이트 순위 및 Googlebot의 렌더링 대기열의 현재 상태에 따라 크게 달라질 수 있습니다. 따라서 색인을 생성하기 위해 외부 웹 서비스에서 오는 콘텐츠에 의존할 수 없습니다.
• 하위 페이지(직접 링크로 액세스할 수 없기 때문에)는 예상대로 인덱싱되지 않습니다.

이 실험은 우리에게 무엇을 말해주는가? 기본적으로 Google은 외부 웹 서비스에서 가져온 경우에도 동적으로 생성된 콘텐츠의 색인을 생성하지만 "너무 늦게 도착하는" 경우 콘텐츠의 색인이 생성된다는 보장은 없습니다. 나는 이 실험 외에 다른 실제 프로덕션 웹사이트에서도 비슷한 경험을 했습니다.

경쟁력 있는 SEO

자, 콘텐츠의 색인 이 생성되지만 이 실험이 알려주지 않는 것은 콘텐츠의 순위가 경쟁적으로 될까요? Google은 동적으로 생성된 웹사이트보다 정적 콘텐츠가 포함된 웹사이트를 선호합니까? 이것은 대답하기 쉬운 질문이 아닙니다.

내 경험에 비추어 볼 때 동적으로 생성된 콘텐츠가 SERPS의 최상위 순위에 포함될 수 있음을 알 수 있습니다. 저는 주요 자동차 회사의 새 모델을 위한 웹사이트에서 일했으며, 새로운 3단계 도메인으로 새 웹사이트를 시작했습니다. 사이트는 <title> 태그와 meta 설명 외에 정적 HTML의 콘텐츠가 거의 없는 Vue.js로 완전히 생성되었습니다.

사이트는 게시 후 처음 며칠 동안 사소한 검색에 대한 순위를 매기기 시작했으며 SERP의 텍스트 스니펫은 동적 콘텐츠에서 직접 나온 단어를 보고했습니다.

3개월 만에 해당 자동차 모델과 관련된 대부분의 검색에서 1위를 차지했습니다. 이는 자동차 제조업체의 공식 도메인에서 호스팅되기 때문에 비교적 쉬웠고 도메인은 평판 좋은 웹사이트에서 많이 연결되어 있었습니다.

하지만 프로젝트를 맡은 SEO 업체의 강력한 반대에 부딪혀야 했다는 점을 감안하면 여전히 괄목할 만한 결과였다고 생각합니다.

촉박한 기한과 프로젝트에 주어진 시간 부족으로 인해 사전 렌더링 없이 사이트를 게시할 예정이었습니다.

애니메이션 텍스트

Google에서 색인을 생성하지 않는 것은 애니메이션이 많은 텍스트입니다. 내가 일하는 회사 중 하나인 Rabbit Hole Consulting의 사이트에는 사용자가 스크롤하는 동안 수행되는 많은 텍스트 애니메이션이 포함되어 있으며 텍스트를 여러 태그에 걸쳐 여러 청크로 분할해야 합니다.

웹사이트 홈 페이지의 주요 텍스트는 SEO에 최적화되어 있지 않기 때문에 검색 엔진 인덱싱을 위한 것이 아닙니다. 그들은 기술 언어로 만들어지지 않았으며 키워드를 사용하지 않습니다. 회사 에 대한 개념적 여정에서 사용자를 동반하기 위한 것일 뿐입니다. 사용자가 홈 페이지의 다양한 섹션에 들어갈 때 텍스트가 동적으로 삽입됩니다.

웹사이트의 이러한 섹션에 있는 텍스트는 Google에서 색인을 생성하지 않습니다. Google이 SERP에서 의미 있는 것을 표시하도록 하기 위해 문의 양식 아래 바닥글에 일부 정적 텍스트를 추가했으며 이 콘텐츠는 SERP에서 페이지 콘텐츠의 일부로 표시됩니다.

바닥글의 텍스트는 페이지 하단으로 스크롤하고 "질문" 버튼 을 클릭하여 문의 양식을 열지 않는 한 사용자에게 즉시 표시되지 않더라도 색인이 생성되고 SERP에 표시됩니다. 이것은 사용자에게 즉시 표시되지 않더라도 콘텐츠가 주문형으로 렌더링되거나 오랜 지연 후에 렌더링되는 것과는 달리 HTML로 곧 렌더링되는 한 콘텐츠가 인덱싱된다는 제 의견을 확인시켜줍니다.

사전 렌더링은 어떻습니까?

그렇다면 사전 렌더링에 대한 모든 소란이 왜 서버 측에서 또는 프로젝트 컴파일 시간에 수행됩니까? 정말 필요한가요? Nuxt와 같은 일부 프레임워크를 사용하면 훨씬 쉽게 수행할 수 있지만 여전히 피크닉이 아니므로 설정 여부를 선택하는 것은 쉽지 않습니다.

의무 사항은 아니라고 생각합니다. Google에서 색인을 생성하려는 많은 콘텐츠가 외부 웹 서비스에서 제공되고 렌더링 시 즉시 사용할 수 없고 일부 불행한 경우에는 다음과 같은 이유로 인해 전혀 사용할 수 없는 경우 확실히 요구 사항입니다. , 웹 서비스 다운타임. Googlebot이 방문하는 동안 일부 콘텐츠가 너무 느리게 도착하면 색인이 생성되지 않을 수 있습니다 . 웹 서비스에서 유지 관리를 수행하는 순간에 Googlebot이 페이지의 색인을 생성하는 경우 동적 콘텐츠의 색인을 생성하지 않을 수 있습니다.

또한 정적 콘텐츠와 동적으로 생성된 콘텐츠 간의 순위 차이에 대한 증거가 없습니다. 다른 실험이 필요할 수 있습니다. 콘텐츠가 외부 웹 서비스에서 제공되고 즉시 로드되지 않으면 순위에 매우 중요한 요소인 사이트 성능에 대한 Google의 인식에 영향을 미칠 가능성이 매우 높다고 생각합니다.

추천 자료 : 모바일 웹 디자인이 지역 검색에 미치는 영향(및 이에 대해 해야 할 일)

기타 고려 사항

호환성

최근까지 Googlebot은 상당히 오래된 버전의 Chromium(Google Chrome의 기반이 되는 오픈 소스 프로젝트), 즉 버전 41을 사용했습니다. 이는 일부 최근 JavaScript 또는 CSS 기능을 Google에서 올바르게 렌더링할 수 없음을 의미합니다(예: IntersectionObserver, ES6 구문 등).

Google은 최근 Googlebot에서 최신 버전의 Chromium(74, 작성 당시)을 실행 중이며 버전이 정기적으로 업데이트될 것이라고 발표했습니다. Google이 Chromium 41을 실행하고 있다는 사실은 IE11 및 기타 이전 브라우저와의 호환성을 무시하기로 결정한 사이트에 큰 영향을 미쳤을 수 있습니다.

여기에서 Chromium 41과 Chromium 74의 기능 지원 비교를 볼 수 있습니다. 그러나 사이트에서 누락된 기능을 이미 폴리필링하여 이전 브라우저와 호환되도록 했다면 문제가 없었을 것입니다.

일반적으로 생각하는 기능에 대한 지원을 놓치는 브라우저를 알 수 없으므로 항상 폴리필을 사용하십시오 . 예를 들어 Safari는 2019년 3월에 나온 버전 12.1까지 IntersectionObserver와 같은 중요하고 매우 유용한 새 기능을 지원하지 않았습니다.

자바스크립트 오류

중요한 콘텐츠를 렌더링하기 위해 자바스크립트를 실행하는 Googlebot에 의존하는 경우 콘텐츠 렌더링을 방해할 수 있는 주요 자바스크립트 오류는 어떤 대가를 치르더라도 피해야 합니다. 봇이 완벽하게 유효하지 않은 HTML을 구문 분석하고 색인을 생성할 수 있지만(모든 사이트에 유효한 HTML이 있는 것이 항상 바람직합니다!), 일부 콘텐츠의 로드를 방해 하는 JavaScript 오류가 있는 경우 Google에서 색인을 생성할 방법이 없습니다. 그 내용.

어쨌든 JavaScript를 사용하여 최종 사용자에게 중요한 콘텐츠를 렌더링하는 경우 모든 종류의 차단 오류를 확인하기 위한 광범위한 단위 테스트가 이미 있을 수 있습니다. 그러나 Javascript 오류는 예를 들어 API 응답에서 오류를 부적절하게 처리하는 경우와 같이 예측할 수 없는 시나리오에서 발생할 수 있습니다.

단위 또는 수동 테스트 중에 선택하지 않을 수 있는 엣지 케이스 오류에 대해 경고하는 실시간 오류 검사 소프트웨어(예: Sentry 또는 LogRocket)를 설치하는 것이 좋습니다. 이는 SEO 콘텐츠에 JavaScript에 의존하는 복잡성을 가중시킵니다.

기타 검색 엔진

다른 검색 엔진은 동적 콘텐츠가 있는 Google만큼 잘 작동하지 않습니다 . Bing은 동적 콘텐츠를 전혀 색인화하지 않는 것 같으며 DuckDuckGo 또는 Baidu도 마찬가지입니다. 아마도 이러한 검색 엔진에는 Google이 가진 리소스와 컴퓨팅 성능이 부족할 것입니다.

헤드리스 브라우저로 페이지를 구문 분석하고 렌더링된 콘텐츠를 구문 분석하기 위해 몇 초 동안 JavaScript를 실행하는 것은 일반 HTML을 읽는 것보다 확실히 리소스를 더 많이 사용합니다. 또는 이러한 검색 엔진이 다른 이유로 동적 콘텐츠를 검색하지 않도록 선택했을 수도 있습니다. 원인이 무엇이든 프로젝트에서 이러한 검색 엔진을 지원해야 하는 경우 사전 렌더링을 설정해야 합니다.

참고 : 다른 검색 엔진의 렌더링 기능에 대한 자세한 정보는 Bartosz Goralewicz의 이 기사를 참조하십시오. 조금 오래되었지만 내 경험에 따르면 여전히 유효합니다.

기타 봇

귀하의 사이트는 다른 봇도 방문한다는 것을 기억하십시오. 가장 중요한 예로는 Twitter, Facebook 및 기타 소셜 미디어 봇이 있습니다. 이 봇은 사용자가 연결할 때 페이지 미리보기를 표시하기 위해 페이지에 대한 메타 정보를 가져와야 합니다. 이러한 봇은 동적 콘텐츠를 색인화하지 않고 정적 HTML에서 찾은 메타 정보만 표시합니다. 이것은 우리를 다음 고려 사항으로 이끕니다.

하위 페이지

귀하의 사이트가 소위 "원페이지 웹사이트"이고 모든 관련 콘텐츠가 하나의 기본 HTML에 있는 경우 Google에서 해당 콘텐츠의 색인을 생성하는 데 문제가 없습니다. 그러나 Google에서 웹사이트의 보조 페이지를 색인 생성하고 표시해야 하는 경우 JavaScript 프레임워크에 의존하여 현재 URL을 확인하고 추가할 관련 콘텐츠를 제공하더라도 각각에 대해 정적 HTML을 생성 해야 합니다. 그 페이지에서. 이 경우 최소한 올바른 title 태그와 메타 설명/정보를 제공하는 서버 측(또는 정적) 페이지를 만드는 것이 좋습니다.

결론

이 기사를 조사하면서 얻은 결론은 다음과 같습니다.

1. Google만 대상 으로 하는 경우 사전 렌더링을 사용하여 사이트의 전체 색인을 생성할 필요는 없습니다 .
2. 특히 빠르게 응답하지 않는 경우 인덱싱해야 하는 콘텐츠에 대해 타사 웹 서비스 에 의존해서는 안 됩니다.
3. Vue.js 렌더링을 통해 HTML에 즉시 삽입 하는 콘텐츠는 인덱싱되지만 스크롤 등과 같은 사용자 작업 후에 DOM에 삽입되는 애니메이션 텍스트나 텍스트를 사용해서는 안 됩니다.
4. 전체 페이지/섹션이 인덱싱되지 않거나 사이트가 전혀 인덱싱되지 않을 수 있으므로 JavaScript 오류를 테스트 해야 합니다.
5. 사이트에 여러 페이지 가 있는 경우에도 홈페이지와 동일한 프런트 엔드 렌더링 시스템에 의존하면서 Google에서 개별 URL로 색인을 생성할 수 있는 페이지를 생성하기 위한 몇 가지 로직이 필요합니다.
6. 다른 페이지 간에 소셜 미디어에 대해 다른 설명 과 미리보기 이미지 가 필요한 경우 서버 측에서 또는 각 URL에 대해 정적 페이지를 컴파일하여 이 문제도 해결해야 합니다.
7. Google 이외의 검색 엔진 에서 사이트를 수행해야 하는 경우 일종의 사전 렌더링이 반드시 필요합니다.