[네이버 SEO 05] Yeti는 자바스크립트를 안 읽는다, SSR이 필수인 이유

네이버 크롤러의 이름은 Yeti다. 이 Yeti가 구글봇과 결정적으로 다른 점이 하나 있는데, 자바스크립트를 실행하지 않거나 매우 제한적으로만 실행한다는 것이다. 이 한 가지 차이가 사이트 구조 전체를 좌우한다. 이번 편은 Yeti의 특성과, 그래서 왜 서버 사이드 렌더링이 네이버에 필수인지를 다룬다.

구글 시리즈에서 빙도 자바스크립트에 약하다고 했는데, 네이버 Yeti는 그 성향이 더 뚜렷하다. 그래서 이건 네이버와 빙에 공통으로 걸리는 문제이고, 뒤에서 빙 편과도 이어진다.

1. Yeti라는 크롤러

Yeti는 네이버의 검색 로봇이다. 사용자 에이전트 문자열에 Yeti라는 이름이 들어 있고, 진짜 Yeti인지는 역방향 DNS 조회로 네이버 도메인에서 온 요청인지 확인할 수 있다. 이 진위 확인은 가짜 봇을 걸러내거나 방화벽 설정을 할 때 필요하다.

Yeti의 역할은 구글봇과 같다. 웹을 돌아다니며 페이지를 수집해 네이버 검색에 반영한다. 하지만 앞서 말했듯 네이버는 소극적으로 크롤하기 때문에, Yeti의 방문 빈도는 구글봇보다 낮은 편이다. 그래서 능동적으로 알려주는 수집 요청과 RSS가 중요한 것이다.

그리고 Yeti의 가장 중요한 특성이 바로 자바스크립트 처리 방식이다. 이게 사이트를 어떻게 지어야 하는지를 결정한다.

Yeti의 진위 확인이 실무적으로 중요한 이유가 있다. 가짜 봇이 Yeti인 척 사이트를 긁는 경우가 있어서, 로그만 보고 진짜 네이버 크롤러라고 믿으면 안 된다. 역방향 DNS로 네이버 도메인에서 온 요청인지 확인해야 진짜 Yeti다. 이건 방화벽에서 봇을 선별해 허용할 때도 필요한 절차다.

Yeti라는 이름이 네이버 검색 로봇을 부르는 정식 명칭이라는 걸 알아두면, 서버 로그를 볼 때 유용하다. 로그에서 Yeti의 방문 기록을 찾으면 네이버가 언제 내 사이트를 긁어갔는지 알 수 있다. 이 방문 빈도가 늘고 있는지를 보면 네이버 크롤이 활성화되고 있는지 가늠된다.

덧붙이면 Yeti 대응을 잘해두면 그 혜택이 빙까지 이어진다. 빙도 자바스크립트에 약해서, Yeti를 위해 갖춘 SSR이 빙 색인에도 그대로 도움이 된다. 즉 네이버를 위한 렌더링 정비가 빙까지 한 번에 챙기는 셈이다. 이게 뒤에서 네이버와 빙을 함께 다루는 또 하나의 이유다.

2. 자바스크립트를 실행하지 않는다

Yeti는 자바스크립트를 실행하지 않거나 매우 제한적으로만 처리한다. 즉 페이지를 받았을 때 그 안에 든 자바스크립트를 돌려 화면을 완성하는 과정을 구글봇만큼 하지 않는다. Yeti가 보는 건 서버가 처음 내려준 HTML 그 자체에 가깝다.

이게 왜 치명적이냐면, 요즘 많은 사이트가 클라이언트 렌더링 방식을 쓰기 때문이다. 서버는 텅 빈 껍데기 HTML을 내려주고, 자바스크립트가 브라우저에서 실행되며 본문을 채워 넣는 방식이다. 사람의 브라우저는 자바스크립트를 실행하니 내용이 보이지만, Yeti는 그걸 안 하니 텅 빈 껍데기만 보게 된다.

결과는 명확하다. 클라이언트 렌더링으로만 만든 사이트는 Yeti에게 내용이 없는 페이지로 보이고, 그래서 네이버 색인이 안 된다. 사람 눈엔 멀쩡한 글이 네이버에는 존재하지 않는 셈이다. 구글은 자바스크립트를 실행해줘서 넘어가도, 네이버에선 그대로 걸린다.

자바스크립트를 안 읽는다는 게 얼마나 치명적인지는, 클라이언트 렌더링 사이트의 소스를 직접 봐보면 실감한다. 브라우저에선 글이 가득한데, 페이지 소스를 열면 본문이 하나도 없고 빈 컨테이너와 스크립트만 있다. 그 빈 소스가 바로 Yeti가 보는 화면이다. 사람 눈과 봇 눈의 이 간극이 네이버 색인 실패의 핵심 원인이다.

3. 서버 사이드 렌더링이 답

해법은 서버 사이드 렌더링이다. 서버가 페이지를 내려줄 때부터 본문과 제목, 메타 정보가 HTML에 다 담겨 있게 만드는 것이다. 그러면 Yeti가 자바스크립트를 실행하지 않아도 처음 받은 HTML에서 내용을 온전히 읽는다.

이때 화면 인터랙션은 여전히 자바스크립트로 화려하게 만들어도 된다. 핵심은 봇과 첫 방문자를 위해 서버가 완성된 HTML을 함께 내려주는 것이다. 사람에겐 자바스크립트로 동적인 경험을 주되, 봇에겐 서버가 렌더한 정적 HTML을 주는 이중 구조다. 이러면 구글, 네이버, 빙을 다 만족시킨다.

확인 방법은 간단하다. 자바스크립트를 끈 브라우저나 명령줄 도구로 페이지를 받아봐서 본문이 그 안에 있는지 보면 된다. 자바스크립트를 꺼도 글이 보이면 Yeti도 볼 수 있고, 껐더니 빈 화면이면 Yeti는 그 글을 못 읽는다. 구글 빙 편에서 쓴 것과 똑같은 테스트다.

서버 사이드 렌더링이 부담스럽게 느껴질 수 있지만, 요즘은 이를 지원하는 프레임워크와 도구가 많아 진입 장벽이 낮아졌다. 그리고 한 번 갖춰두면 구글, 네이버, 빙을 다 만족시키고 첫 화면 로딩 속도까지 좋아진다. 즉 SSR은 네이버만을 위한 게 아니라 사이트 전체의 기초 체력을 올리는 투자다.

SSR과 클라이언트 렌더링을 흑백으로 나눌 필요는 없다. 중요한 콘텐츠, 즉 봇이 읽어야 할 본문과 메타는 서버가 렌더하고, 부가적인 인터랙션은 클라이언트가 담당하는 혼합 방식이 현실적이다. 핵심은 색인시킬 내용이 초기 HTML에 있느냐다. 그것만 지키면 나머지는 자유롭게 구성해도 된다.

4. 초기 HTML에 담겨야 할 것

Yeti를 위해 초기 HTML에 반드시 담겨야 할 것들이 있다. 페이지의 제목 태그, 메타 설명문, 오픈그래프 정보, 그리고 무엇보다 본문 텍스트다. 이것들이 서버 응답 HTML에 처음부터 들어 있어야 한다. 자바스크립트로 나중에 채워 넣는 방식은 Yeti에게 통하지 않는다.

특히 오픈그래프 정보가 중요하다. 제목, 설명, 대표 이미지, 정규 주소를 오픈그래프로 정확히 주면, 네이버가 페이지를 이해하고 공유 시 카드를 만드는 데 쓴다. 이 정보들이 페이지의 실제 내용과 일치해야 신뢰를 얻는다.

정규 주소를 뜻하는 canonical도 모든 크롤러에게 동일한 정식 주소를 가리켜야 한다. 사람에게 보여주는 주소와 봇에게 알려주는 정규 주소가 어긋나면 혼란이 생긴다. 구글 시리즈에서 다룬 canonical 원칙이 네이버에도 그대로 적용된다.

초기 HTML에 담을 것들을 점검할 때는 봇의 관점에서 확인하는 게 중요하다. 사람이 보는 화면이 아니라 서버가 처음 내려주는 소스를 기준으로, 제목과 설명문, 본문이 다 있는지 봐야 한다. 이 확인을 자바스크립트 끈 상태에서 하는 습관을 들이면, 렌더링 문제를 배포 전에 잡을 수 있다.

5. Cloudflare 같은 방화벽 주의

마지막으로 실전 함정 하나. Yeti가 SSR도 잘 돼 있는데 색인이 안 된다면, 방화벽이 Yeti를 차단하고 있을 수 있다. 특히 봇을 자동으로 막는 보안 기능이 켜져 있으면, 정상 크롤러인 Yeti까지 걸러버리는 경우가 있다.

그래서 봇 차단 기능을 쓴다면 검증된 봇 목록에서 Yeti가 허용돼 있는지 확인해야 한다. 실제로 Yeti의 사용자 에이전트로 내 사이트에 요청을 보내봐서 정상 응답이 오는지 테스트하면 확실하다. 정상 크롤러를 실수로 막고 있으면 아무리 SSR을 잘해도 소용이 없다.

정리하면 Yeti는 자바스크립트를 안 읽으니 서버 사이드 렌더링이 필수이고, 초기 HTML에 본문과 메타가 다 담겨야 하며, 방화벽이 Yeti를 막지 않는지 확인해야 한다. 이건 빙에도 통하는 공통 처방이다. 다음 편에서는 네이버가 소극적으로 크롤하는 문제를 능동적으로 뚫는 법, RSS와 수집 요청을 다룬다.

방화벽이 Yeti를 막는 문제는 의외로 흔한 함정이다. SSR도 완벽하고 사이트맵도 냈는데 네이버 색인만 안 된다면, 십중팔구 봇 차단 설정을 의심해봐야 한다. 정상 크롤러를 실수로 막고 있으면 다른 모든 작업이 물거품이 된다. 그래서 봇 차단 기능을 쓴다면 Yeti가 허용 목록에 있는지 반드시 확인해야 한다.

방화벽 함정을 점검하는 습관을 들이면 좋다. 새 사이트를 네이버에 등록하고 며칠이 지나도 수집이 안 되면, SSR과 사이트맵을 의심하기 전에 봇 차단부터 확인하는 것이다. Yeti 사용자 에이전트로 직접 요청을 보내 정상 응답이 오는지 보면 몇 분 만에 확인된다. 이 간단한 점검이 헛수고를 막는다.

다음 편에서는 이 SSR 위에서 네이버가 소극적으로 크롤하는 문제를 뚫는 법을 다룬다. Yeti가 자주 오지 않으니, 가만히 기다리는 대신 RSS와 수집 요청으로 여기 새 글 있다고 능동적으로 알려야 한다. SSR로 읽을 수 있게 만들고, 능동 발견으로 오게 만드는 두 단계가 네이버 색인의 뼈대다.