네이버 서치어드바이저 소유권 인증으로 크롤링 관리 기능 개방
목차
네이버 서치어드바이저 인증 메타태그를 index.html에 박아 넣은 날.
왜 네이버 site verification인가
구글 Search Console 인증이야 이미 익숙한 루틴이지만, 네이버 서치어드바이저는 생각보다 놓치기 쉬운 구석이다. 특히 서비스 초기에 SEO 작업을 빠르게 치고 나갈 때, 크롤러 등록보다 "일단 만들고 보자"가 우선이 되다 보니 검색 엔진 소유권 인증은 뒤로 밀리기 십상이다.
daily-bible.hedvion.com 서비스도 비슷한 흐름이었다. 서비스 자체의 기능 완성도를 먼저 챙기고, 어느 정도 궤도에 오른 시점에 SEO 기반 작업을 한 번에 정리하는 타이밍을 잡은 것. 네이버 서치어드바이저 인증은 그 첫 번째 체크포인트였다.
작업 내용
변경 파일은 app/web/index.html 딱 하나. stat도 크지 않다. 코드 자체는 단순하다.
<head>
<!-- 기존 메타태그들 -->
<meta name="naver-site-verification" content="[발급된 인증코드]" />
</head>
이 메타태그 한 줄이 전부인데, 이게 의미하는 바는 꽤 크다. 네이버 서치어드바이저가 해당 도메인을 크롤링할 때 이 태그를 읽어서 "이 사이트의 소유자가 직접 등록 요청을 한 서비스다"를 확인한다. 인증 전까지는 색인 요청, 크롤링 주기 설정, 검색 노출 통계 확인 같은 기능이 전혀 열리지 않는다.
| 항목 | 인증 전 | 인증 후 |
|---|---|---|
| 사이트맵 제출 | 불가 | 가능 |
| 크롤링 요청 | 불가 | 가능 |
| 검색 노출 통계 | 열람 불가 | 대시보드 확인 가능 |
| 수집 오류 리포트 | 확인 불가 | 확인 가능 |
이런 작업에서 팀 리딩 관점으로 챙겨야 할 것들
단순 메타태그 하나라서 PR 리뷰 피드백도 짧고, 배포 리스크도 거의 없다. 그런데 이런 "작아 보이는 SEO 기반 작업"이 쌓이는 타이밍과 우선순위를 어떻게 잡느냐가 서비스 성숙도를 가른다고 생각한다.
- 서비스 론칭 직후에 바로 인증까지 묶어서 체크리스트화하는 게 이상적
- 그런데 현실에선 기능 개발 sprint와 SEO/마케팅 기반 작업이 겹치면 후자가 밀림
- 이런 류의 작업은 "backlog에 카드는 있는데 아무도 안 가져가는" 상태로 방치되기 쉬움
- 팀장 포지션에서는 이걸 누군가 자연스럽게 픽업할 수 있게 작업 단위를 잘게 쪼개두는 게 중요
실제로 이 커밋도 크게 어렵지 않은 작업이라 주니어 멤버한테 던져줄 수 있는 종류다. 서치어드바이저 콘솔에서 인증코드 발급하는 법, index.html의 <head> 안에 메타태그 위치 잡는 컨벤션, 배포 후 인증 확인까지 — 이 흐름을 한 번 직접 해보면 SEO 파이프라인 전체를 이해하는 좋은 입문 경험이 된다.
인증 방식 선택 기준
네이버 서치어드바이저가 제공하는 인증 방식은 두 가지다.
1. HTML 메타태그 삽입 방식
→ <head> 안에 <meta name="naver-site-verification" content="..." /> 추가
2. HTML 파일 업로드 방식
→ 발급받은 .html 파일을 루트 경로에 업로드
SPA(Single Page Application) 구조에서는 파일 업로드 방식이 라우팅 처리 때문에 꼬이는 경우가 간혹 있어서, 메타태그 방식이 더 안전하다. index.html 하나만 수정하면 되니까 변경 범위도 명확하고 롤백도 간단하다. 이번에 메타태그 방식을 선택한 것도 같은 맥락.
구글 Search Console 인증도 동일한 패턴으로 처리되어 있으니, 새로운 서브도메인이 생길 때마다 이 검색 엔진 인증 체크가 배포 체크리스트에 들어가 있으면 나중에 뒤늦게 챙기는 낭비를 줄일 수 있다. 다음엔 그 체크리스트 자동화까지 연결해볼 만하다.
끝.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.