네이버 검색에 사이트가 잡히지 않을 때 확인해야 할 수집 조건을 순서대로 정리했습니다. robots.txt의 Yeti 허용, 소유확인, 사이트맵 선언, 봇 UA 응답까지 자동 점검하는 방법과 흔한 오탐을 다룹니다.
LumiBreeze
2026년 7월 25일
사이트를 만들고 몇 주가 지나도 네이버 검색에 잡히지 않으면 원인을 짐작하기 어렵습니다. 콘텐츠가 부족해서인지, 설정이 잘못돼서인지, 아니면 그냥 시간이 더 필요한 것인지 구분이 안 되기 때문입니다. 이럴 때는 추정하기 전에 기계적으로 확인 가능한 조건부터 배제하는 것이 효율적입니다.
네이버 검색 로봇의 이름은 Yeti입니다. 확인할 것은 두 가지입니다.
User-agent: *)에 대해 사이트 전체가 차단되어 있지 않은지여기서 흔한 오탐이 하나 있습니다. 자동 점검 스크립트를 만들 때 Disallow 줄이 있으면 차단으로 판정하도록 짜면, /admin/이나 /api/처럼 일부 경로만 막은 정상 설정까지 전체 차단으로 잘못 잡힙니다. 실제로 이 오탐 때문에 멀쩡한 도메인을 문제로 분류한 적이 있습니다. 판정은 반드시 루트 경로에 대한 전체 차단인지를 기준으로 해야 하고, 애매하면 파일을 직접 열어 확인하는 편이 빠릅니다.
네이버 서치어드바이저에 사이트를 등록하고 소유확인을 마쳐야 수집·색인 현황을 볼 수 있고, 사이트맵 제출과 수집 요청도 가능해집니다. 확인 방법은 페이지 HTML의 <head>에 소유확인 메타 태그가 살아 있는지 보는 것입니다.
주의할 점은 배포 과정에서 메타 태그가 사라지는 경우입니다. 템플릿을 개편하거나 빌더를 재실행하면서 헤드 영역이 통째로 교체되면 소유확인이 풀립니다. 배포 후 자동으로 확인하도록 점검에 포함해 두는 것이 좋습니다.
Sitemap: 줄로 사이트맵 주소가 선언되어 있는지마지막 항목이 특히 자주 빠집니다. 목록 페이지나 카테고리 페이지가 "얇은 콘텐츠"라는 이유로 사이트맵 생성 로직에서 의도적으로 제외되어 있었는데, 정작 그 페이지들이 검색 유입의 진입점이었던 사례를 실제로 확인한 적이 있습니다. 제외 규칙이 있다면 그 규칙이 지금도 타당한지 주기적으로 되돌아볼 필요가 있습니다.
브라우저로는 잘 열리는데 봇에게는 다르게 응답하는 경우가 있습니다.
확인 방법은 간단합니다. Yeti의 User-Agent 문자열로 요청을 보내 응답 코드와 본문 길이를 비교해 보면 됩니다. 브라우저 요청과 결과가 다르면 그 지점이 원인입니다.
여기까지 통과했다면 코드나 설정 측 문제는 대체로 배제된 것입니다. 남는 변수는 다음과 같습니다.
이 단계에서 할 수 있는 실질적인 조치는 색인 제출 프로토콜로 신규·수정 페이지를 알리고, 유입 경로가 될 외부 링크를 만들고, 기다리는 것입니다. 조급하게 구조를 계속 바꾸면 무엇이 효과가 있었는지 판단할 수 없게 되므로, 점검 항목을 고정해 두고 주기적으로 같은 방식으로 확인하는 편이 낫습니다.
본 글은 LumiBreeze가 발행하는 GEO/AEO 사례 연구·리서치 콘텐츠입니다. 인용된 사례는 일반적인 운영 데이터 기반으로 작성되었으며, 개별 의료기관·기업의 진료·서비스에 대한 보장이 아닙니다.