IndexNow란? 빙·네이버까지 실시간으로 알리는 색인 요청

결론부터 말하면 이렇다. IndexNow는 새 글을 발행하거나 수정했을 때, 검색엔진이 알아서 다시 방문할 때까지 기다리지 않고 "지금 바뀌었다"고 직접 알리는 개방형 프로토콜이다. 한 번 알리면 빙(Bing)·네이버·얀덱스(Yandex) 등 참여 중인 검색엔진 전체에 자동으로 공유된다는 점이 핵심이다.

다만 여기서 바로 짚어야 할 오해가 하나 있다. 구글은 IndexNow 참여 목록에 없다. 그래서 "IndexNow를 쓰면 구글 색인도 빨라진다"는 식으로 소개된 글을 보면 절반만 맞는 설명이라고 봐야 한다.

이 글은 빙 웹마스터 도구 가이드에서 짧게 언급했던 IndexNow를 원리부터 실제 연동 방법까지 깊이 있게 정리한다. 워드프레스든 자체 도메인 홈페이지든, 발행 후 색인까지 걸리는 시간을 줄이고 싶은 운영자를 대상으로 한다.

특히 체감 효과가 큰 쪽은 발행 주기가 잦은 사이트다. 매일 여러 편을 발행하는 블로그, 재고와 가격이 수시로 바뀌는 쇼핑몰 상품 페이지, 속보성 뉴스 페이지라면 검색엔진이 정기 크롤링 순서를 기다리는 동안 이미 정보 가치가 떨어질 수 있다. 반대로 몇 달에 한 번 페이지 몇 개만 손보는 소개 사이트라면 IndexNow 없이도 큰 차이를 못 느낄 수 있다는 점도 미리 알아 두는 편이 좋다.

예를 들어 하루에도 여러 번 품절·재입고가 반복되는 쇼핑몰이라면, 상품 페이지 문구가 바뀔 때마다 IndexNow로 알려 두는 편이 검색 결과에 오래된 가격·재고 정보가 남는 상황을 줄이는 데 도움이 된다. 반대로 회사 소개, 오시는 길처럼 거의 바뀌지 않는 페이지까지 매번 제출할 필요는 없다.

이 글에서 먼저 챙겨 갈 핵심만 추리면 이렇다.

• IndexNow는 빙·네이버 서치어드바이저·얀덱스·세즈남(Seznam)·옙(Yep)·아마존봇 등이 참여하는 공동 프로토콜이다.
• 구글은 참여하지 않는다. 구글 색인은 여전히 사이트맵·서치 콘솔 URL 검사가 기본 경로다.
• 워드프레스는 랭크매스(Rank Math)의 인스턴트 인덱싱, 요스트(Yoast) SEO가 플러그인 안에서 바로 연동을 지원한다.
• 한 번 제출한 URL은 같은 값으로 5분 안에 다시 제출할 수 없다. 무작정 자주 보낸다고 유리해지지 않는다.
• IndexNow는 색인을 보장하는 도구가 아니라 크롤링 우선순위를 높이는 신호일 뿐이다.

IndexNow가 정확히 무엇인가?

한마디로, 검색엔진이 내 사이트를 다시 크롤링할 차례가 올 때까지 기다리지 않고, URL이 바뀌었다는 사실을 직접 통보하는 방식이다. 2021년 마이크로소프트와 얀덱스가 공동으로 발표했고, 지금은 indexnow.org에서 사양을 공개 관리하는 개방형 프로토콜이다.

기존 방식과 비교하면 차이가 뚜렷하다. 사이트맵(sitemap.xml)은 검색엔진이 "언젠가" 와서 읽어 가는 파일이다. 크롤링 주기는 사이트 규모와 신뢰도에 따라 다르고, 신생 사이트일수록 그 주기가 길어질 수 있다. 반면 IndexNow는 발행 즉시 능동적으로 알리는 방식이라, 이론상 확인까지 걸리는 시간을 크게 줄일 수 있다.

나쁜 예는 글을 발행해 놓고 사이트맵이 알아서 반영되기만을 기다리는 경우다. 신생 사이트라면 며칠에서 몇 주까지 걸릴 수 있다. 좋은 예는 발행 버튼을 누르는 순간 IndexNow로 참여 검색엔진 전체에 동시에 알리고, 그 뒤 결과를 서치 콘솔·서치어드바이저에서 확인하는 경우다.

IndexNow는 새로운 크롤링 기술이 아니다. 기존 크롤링 순서에 "여기부터 먼저 봐 주세요"라는 알림을 끼워 넣는 것에 가깝다.

등장 배경도 함께 알아 두면 이해가 쉽다. 마이크로소프트와 얀덱스가 2021년 10월 공동으로 발표했고, 사양(스펙) 자체는 특정 회사가 독점하지 않도록 오픈소스로 공개해 관리한다. 이후 다른 검색엔진들이 순차적으로 이 사양에 맞춰 자체 엔드포인트를 열고 참여 목록에 이름을 올리는 방식으로 생태계가 넓어졌다. 즉 IndexNow는 한 회사의 제품이 아니라, 여러 검색엔진이 같은 규칙을 함께 쓰기로 합의한 업계 표준에 가깝다.

IndexNow는 실제로 어떻게 동작하나?

핵심 절차는 키 파일을 도메인에 올려 소유권을 증명한 뒤, URL 목록을 API로 전송하는 두 단계다. 구조 자체는 복잡하지 않다.

먼저 8자에서 128자 사이의 영문·숫자·하이픈으로 된 키를 하나 만든다. 이 키를 파일명으로 하는 텍스트 파일(예: abc123def.txt)을 도메인 루트에 올려 두면, 검색엔진이 이 파일을 확인해 "이 사람이 진짜 이 도메인의 소유자"라고 검증한다.

키 파일이 준비되면 아래 두 방식 중 하나로 URL을 제출한다.

방식	형태	용도
단건 제출(GET)	https://<검색엔진>/indexnow?url=[URL]&key=[키]	글 한 편만 빠르게 알릴 때
배치 제출(POST)	JSON으로 host·key·urlList 전송	한 번에 여러 URL을 묶어 보낼 때

배치 제출에 들어가는 값은 네 가지다. host(도메인), key(발급한 키), keyLocation(키 파일을 루트가 아닌 다른 경로에 뒀을 때만 필요), urlList(제출할 URL 배열, 한 번에 최대 1만 개)다.

여기서 가장 중요한 특징이 나온다. 한 검색엔진에만 제출해도 참여 중인 다른 검색엔진에 자동으로 공유된다. 즉 빙에만 보내도 네이버·얀덱스 쪽에도 같은 URL 정보가 전달되는 구조다. 이 덕분에 검색엔진마다 따로 API를 연동할 필요가 없다.

다만 제약도 있다. 같은 URL을 5분 이내에 다시 제출할 수 없고, URL에 콜론(:)·슬래시(/)·앰퍼샌드(&) 같은 특수문자가 있으면 RFC-3986 규격에 맞게 인코딩해야 한다. 나쁜 예는 인코딩 없이 한글 URL을 그대로 붙여 넣어 요청이 거부되는 경우다. 좋은 예는 플러그인이나 스크립트가 자동으로 인코딩을 처리하도록 맡기고, 사람은 발행 버튼만 누르는 경우다.

배치 제출용 JSON은 실제로 아래와 같은 형태다. 개발자가 직접 연동하거나, 플러그인이 내부적으로 어떤 값을 보내는지 확인하고 싶을 때 참고하면 된다.

{
  "host": "iruweb.com",
  "key": "abc123def456",
  "keyLocation": "https://iruweb.com/abc123def456.txt",
  "urlList": [
    "https://iruweb.com/blog/indexnow-protocol-guide-2026",
    "https://iruweb.com/blog/bing-webmaster-tools-copilot-chatgpt-guide-2026"
  ]
}

이 구조가 신뢰를 확보하는 방식도 간단하다. 키 파일이 실제로 그 도메인 루트에 올라가 있다는 사실 자체가 소유권 증명이 된다. 다른 사람이 남의 도메인 이름으로 URL을 제출해도, 그 도메인에 맞는 키 파일이 없으면 검증에서 걸러진다. 별도의 계정 가입이나 인증서 발급 절차 없이도 이 정도 신뢰 모델로 충분히 동작하도록 설계됐다.

참고로 검색엔진별 제출 엔드포인트는 아래와 같이 나뉜다. 하나에만 보내도 자동으로 전체에 전파되지만, 특정 검색엔진의 반응만 별도로 확인하고 싶을 때는 해당 엔드포인트로 직접 보내는 것도 방법이다.

검색엔진	엔드포인트	비고
공용(전체 전파)	api.indexnow.org	어디로 보내도 결과는 동일하게 전파됨
빙	www.bing.com	챗GPT 검색·코파일럿도 함께 영향받음
네이버	searchadvisor.naver.com	서치어드바이저 등록이 먼저 필요
얀덱스	yandex.com	원년 공동 개발사
세즈남	search.seznam.cz	체코 시장 대상
옙	indexnow.yep.com	아레프스(Ahrefs) 자체 검색엔진

실무에서는 대부분 공용 엔드포인트나 워드프레스 플러그인이 기본으로 지정해 둔 엔드포인트 하나에만 제출하면 충분하다. 여러 엔드포인트에 중복으로 나눠 보낼 필요는 없다.

어떤 검색엔진이 IndexNow를 지원하나?

2026년 기준 참여 목록은 빙, 네이버(서치어드바이저), 얀덱스, 세즈남닷씨제트(Seznam.cz), 옙(Yep), 아마존봇(Amazonbot)이다. 검색엔진마다 성격이 조금씩 달라, 하나씩 짚어 보면 이해가 쉽다.

• 빙(Bing): 마이크로소프트가 얀덱스와 함께 IndexNow를 처음 발표한 당사자이자, 국내에서도 챗GPT 검색·코파일럿의 색인 기반이 되는 검색엔진이다.
• 네이버: 서치어드바이저에 등록된 자체 도메인 사이트를 대상으로 IndexNow를 지원한다. 국내 사이트 입장에서는 사실상 가장 체감 효과가 큰 참여 검색엔진이다.
• 얀덱스(Yandex): 러시아 최대 검색엔진으로, IndexNow를 빙과 공동 개발한 원년 참여사다.
• 세즈남(Seznam.cz): 체코의 대표 검색엔진으로, 유럽 지역 시장을 노리는 사이트라면 참고할 만하다.
• 옙(Yep): SEO 툴 기업 아레프스(Ahrefs)가 2021년 자체적으로 만든 검색엔진이다. 광고 수익의 상당 부분을 콘텐츠 제작자와 나누는 구조로 알려져 있으며, IndexNow 참여로 자사 크롤러의 색인 속도를 높이는 데 활용한다.
• 아마존봇(Amazonbot): 아마존의 크롤러로, 알렉사 같은 음성 비서 학습과 검색 품질 향상에 쓰인다.

국내 운영자 입장에서 실질적으로 챙길 대상은 빙과 네이버 둘이고, 나머지는 해외 진출 사이트가 아니라면 우선순위가 낮다.

이 목록에 구글은 없다. 구글이 빠진 이유는 명확한 정책 발표라기보다, 애초에 이 공동 프로토콜에 합류한 적이 없다는 사실 자체다. 나쁜 예는 IndexNow만 세팅해 두고 구글 색인까지 자동으로 빨라졌으리라 안심하는 경우다. 좋은 예는 IndexNow로 빙·네이버를 챙기는 동시에, 구글은 구글 서치 콘솔의 사이트맵 제출과 URL 검사를 별도로 병행하는 경우다. 사이트맵 자체를 아직 만들지 않았다면 사이트맵(sitemap.xml) 만드는 법부터 확인하는 편이 순서상 맞다.

구글에는 비슷한 게 없나? 색인 API와의 차이

구글도 색인 API(Indexing API)라는 이름의 비슷한 기능을 제공하긴 하지만, 대상이 극히 제한적이라 IndexNow와 같은 선상에서 비교하기 어렵다.

구글 공식 문서는 이 API를 채용 공고(JobPosting) 구조화 데이터가 포함된 페이지, 또는 VideoObject 구조화 데이터가 포함된 실시간 방송(BroadcastEvent) 페이지에만 쓸 수 있다고 명시한다. 일반 블로그 글이나 상품 페이지에는 공식적으로 허용되지 않는다. 기본 할당량도 하루 200건(작업 등록·삭제 요청 합산)으로, 이보다 많은 페이지를 처리하려면 별도 승인을 받아야 한다.

항목	IndexNow	구글 색인 API
참여 검색엔진	빙·네이버·얀덱스 등 다수	구글 단독
대상 페이지	제한 없음	채용 공고·실시간 방송 페이지 한정(공식 정책)
기본 할당량	배치당 최대 1만 개 URL	하루 200건(프로젝트당)
일반 블로그·상품 페이지 사용	가능	공식적으로 허용되지 않음

나쁜 예는 일반 블로그에 구글 색인 API를 무리하게 연동해 정책 범위를 벗어난 방식으로 쓰는 경우다. 계정 상태에 불이익이 갈 수 있다. 좋은 예는 채용 정보 페이지가 실제로 있는 사이트에서만 색인 API를 쓰고, 일반 콘텐츠는 사이트맵과 서치 콘솔 URL 검사로 관리하는 경우다.

IndexNow는 "검색엔진 전체에 통하는 만능 알림"이 아니다. 구글 몫은 여전히 구글의 방식으로, 그것도 대부분은 사이트맵과 서치 콘솔로 따로 챙겨야 한다.

워드프레스에서 IndexNow, 어떻게 설정하나?

플러그인을 쓰면 코드 한 줄 없이 몇 분 안에 끝난다. 대표적으로 두 플러그인이 자체 기능으로 IndexNow를 지원한다.

랭크매스(Rank Math)는 인스턴트 인덱싱(Instant Indexing)이라는 이름의 모듈로 IndexNow를 지원한다. 빙 웹마스터 팀과 공식적으로 협업해 만들어진 기능으로, 설정에서 모듈을 켜고 API 키를 생성해 붙여 넣으면 글을 발행·수정할 때마다 자동으로 제출된다.

요스트(Yoast) SEO도 2022년 6월 업데이트부터 IndexNow 연동을 기본 기능에 포함시켰다. 별도 유료 확장 없이 설정 화면에서 켜기만 하면 동작한다.

절차를 순서대로 정리하면 다음과 같다.

1. 랭크매스 또는 요스트 SEO 플러그인을 설치·활성화한다.
2. 설정 메뉴에서 IndexNow(또는 인스턴트 인덱싱) 항목을 찾아 켠다.
3. 플러그인이 키를 자동 생성하고 키 파일도 자동으로 루트에 올려 준다.
4. 이후 글을 발행·수정할 때마다 별도 조작 없이 자동으로 제출된다.

나쁜 예는 플러그인 없이 직접 API를 호출하는 코드를 매번 손으로 짜 넣으려는 경우다. 유지보수 부담만 커진다. 좋은 예는 이미 쓰고 있는 SEO 플러그인의 기본 기능부터 확인하고, 없을 때만 별도 플러그인을 추가로 검토하는 경우다.

플러그인을 쓰고 싶지 않거나, 이미 커스텀으로 발행 시스템을 구축해 둔 경우라면 발행 훅(hook)에 API 호출 코드 한 줄을 추가하는 방식도 가능하다. 예를 들어 글이 발행될 때 실행되는 함수 안에 IndexNow API로 POST 요청을 보내는 코드를 넣어 두면, 플러그인 없이도 동일한 효과를 낼 수 있다. 다만 이 방식은 개발 리소스가 필요하므로, 대부분의 워드프레스 운영자에게는 기존 SEO 플러그인의 내장 기능을 쓰는 편이 훨씬 간단하다.

카페24·아임웹 같은 자체 제작 홈페이지는 어떻게 하나?

빌더형 홈페이지는 플랫폼 차원의 IndexNow 자동 연동이 폭넓게 확인되지는 않는다. 워드프레스처럼 플러그인 생태계가 열려 있는 구조가 아니라서, 직접 키 파일을 루트에 올릴 수 있는지부터 플랫폼별로 확인이 필요하다.

루트 경로에 파일 업로드 기능을 제공하지 않는 빌더라면, 현실적인 대안은 두 가지다. 하나는 빙 웹마스터 도구의 URL 제출 기능을 이용하는 방법이다. 빙 자체가 IndexNow 참여 검색엔진이므로, 웹마스터 도구 화면에서 URL을 수동으로 제출해도 사실상 비슷한 효과를 볼 수 있다. 절차는 빙 웹마스터 도구 완벽 가이드에 정리해 두었다.

다른 하나는 사이트맵 갱신 주기를 짧게 유지하고, 콘텐츠 발행 뒤 서치 콘솔·서치어드바이저에서 수동으로 재검토를 요청하는 기존 방식을 그대로 유지하는 것이다. 자동화 도구가 없다고 해서 색인 자체가 안 되는 것은 아니며, 다만 확인까지 걸리는 시간이 조금 더 걸릴 수 있다는 차이일 뿐이다.

개발 인력이 있는 조직이라면 세 번째 방법도 있다. 빌더가 루트 파일 업로드를 막아 두더라도, 서브도메인이나 별도 경로에 키 파일을 올릴 수 있는 경우가 있다. 이때는 keyLocation 파라미터로 실제 파일 위치를 지정해 검증을 통과시키고, 발행 시스템과 연동된 별도 스크립트나 서버리스 함수로 API를 직접 호출하는 방식을 구성할 수 있다. 다만 이 방법은 빌더마다 파일 업로드 정책이 달라 사전에 반드시 확인이 필요하다.

나쁜 예는 빌더 플랫폼이 IndexNow를 지원하지 않는다는 이유로 색인 관리 자체를 포기하는 경우다. 좋은 예는 자동화가 안 되는 만큼 사이트맵 최종 수정일 관리와 서치 콘솔 URL 검사를 더 꼼꼼히 챙기는 경우다.

네이버 서치어드바이저 등록과 IndexNow는 뭐가 다른가?

서치어드바이저 등록은 "네이버가 이 사이트를 알게 하는 절차"이고, IndexNow는 그 위에서 "지금 바뀐 페이지를 즉시 알리는 절차"다. 둘은 순서가 다른 별개의 단계이지 서로 대체하는 관계가 아니다.

자체 도메인 홈페이지가 네이버 검색에 노출되려면 먼저 네이버 서치어드바이저에 사이트를 등록하고 소유권을 확인해야 한다. 이 등록 자체가 없으면 IndexNow로 아무리 URL을 보내도 네이버가 애초에 이 사이트를 인지하지 못한 상태라 효과를 기대하기 어렵다. IndexNow는 이미 등록된 사이트를 대상으로, 새 글이 나올 때마다 확인 순서를 앞당기는 역할을 한다.

여기서 반드시 구분해야 할 사실이 하나 있다. 네이버 블로그(blog.naver.com)는 네이버가 자동으로 수집·색인하므로 서치어드바이저 등록이나 IndexNow 연동이 필요 없다. 이 절차는 워드프레스·카페24·아임웹처럼 자체 도메인으로 운영하는 "네이버 외부 사이트"에만 해당한다.

나쁜 예는 네이버 블로그 운영자가 서치어드바이저 등록 방법을 찾아 헤매는 경우다. 애초에 필요 없는 절차다. 좋은 예는 자체 도메인 홈페이지 운영자가 서치어드바이저 등록부터 마친 뒤, 그 위에 IndexNow로 발행 속도를 더하는 경우다.

실무에서 순서를 헷갈리는 경우가 의외로 많다. 서치어드바이저에 사이트를 등록하지 않은 상태에서 워드프레스 플러그인의 IndexNow 기능만 켜 두고 "네이버에 왜 안 뜨지"라고 묻는 문의가 대표적이다. 소유권 확인 절차 자체가 없으면 네이버가 이 도메인을 애초에 신뢰할 근거가 없다는 뜻이므로, 반드시 서치어드바이저 등록과 소유권 확인을 먼저 마친 다음 IndexNow 연동을 켜는 순서를 지켜야 한다.

IndexNow를 쓰면 정말 색인이 빨라지나?

빨라질 수는 있지만, 보장되지는 않는다. IndexNow는 크롤링 우선순위를 높이는 신호일 뿐, 색인 여부를 결정하는 요인은 여전히 콘텐츠 품질과 사이트 신뢰도다.

빙 웹마스터 도구 안내에 따르면 IndexNow로 알린 URL은 사이트맵만 제출했을 때보다 확인까지 걸리는 시간이 짧아지는 경향이 있다고 설명한다. 다만 이는 "크롤링을 더 빨리 시도한다"는 의미이지, "무조건 색인된다"는 뜻은 아니다. 품질이 낮거나 중복된 페이지라면 빠르게 방문은 해도 색인은 거절될 수 있다.

IndexNow는 줄을 서는 순서를 앞당겨 줄 뿐, 심사 결과 자체를 바꾸지는 않는다.

나쁜 예는 IndexNow만 세팅하면 콘텐츠 품질과 무관하게 색인이 보장된다고 오해하는 경우다. 좋은 예는 IndexNow로 확인 속도를 앞당기되, 실제 색인 여부는 서치 콘솔·서치어드바이저에서 별도로 확인하는 습관을 유지하는 경우다. 색인의 기본 원리가 궁금하다면 구글 색인이란? 내 페이지가 검색에 뜨는 원리를 함께 참고하면 이해가 쉽다.

자주 하는 실수는 무엇인가?

가장 흔한 실수 네 가지는 키 파일 위치 오류, 과도한 재제출, 저품질 URL 대량 제출, 호스트 값 불일치다. 대부분 기술 지식이 부족해서라기보다, 설정 화면을 꼼꼼히 확인하지 않고 넘어가서 생기는 문제다.

키 파일 위치 오류부터 보면, 키 파일을 서브디렉터리에 올려 두고 keyLocation 파라미터 없이 제출하는 경우가 많다. 이렇게 하면 검증에 실패한다. 나쁜 예는 /blog/abc123.txt에 올려 두고 루트 파일인 것처럼 제출하는 경우다. 좋은 예는 키 파일을 도메인 루트(/abc123.txt)에 두거나, 부득이하게 다른 경로에 뒀다면 keyLocation 값을 정확히 함께 보내는 경우다.

과도한 재제출도 흔한 실수다. 문서에는 같은 URL을 5분 안에 다시 제출하지 말라는 안내가 있는데, 자동화 스크립트를 잘못 짜면 사소한 수정마다 반복 제출이 발생할 수 있다. 나쁜 예는 캐시 갱신 같은 사소한 변경에도 매번 전체 URL 목록을 다시 제출하는 경우다. 좋은 예는 실제 콘텐츠가 바뀐 URL만 골라 제출 대상에 넣는 경우다.

저품질 URL 대량 제출은 신뢰도 측면에서 가장 조심해야 할 실수다. 태그 페이지, 검색 결과 페이지처럼 색인 가치가 낮은 URL을 습관적으로 대량 제출하면, 검색엔진 입장에서 이 사이트의 제출 신호를 신뢰하기 어려워질 수 있다. 나쁜 예는 사이트의 모든 URL을 자동으로 긁어 통째로 제출하는 경우다. 좋은 예는 실제로 사람이 읽을 가치가 있는 본문 페이지 위주로 제출 대상을 정리하는 경우다.

호스트(host) 값 불일치도 자주 놓치는 부분이다. www.iruweb.com으로 키 파일을 올려놓고 iruweb.com(www 없이) 주소로 URL을 제출하면, 도메인 표기가 다르다는 이유로 검증에 실패할 수 있다. 나쁜 예는 사이트 주소 표기를 신경 쓰지 않고 뒤섞어 쓰는 경우다. 좋은 예는 사이트가 실제로 쓰는 정규 도메인 형태(www 포함 여부)를 확인하고, 키 파일 위치와 제출하는 URL의 도메인 표기를 정확히 맞추는 경우다.

IndexNow 효과, 어떻게 확인하나?

제출 자체가 성공했는지와 실제로 색인이 됐는지는 서로 다른 질문이다. 두 가지를 각각 다른 도구로 확인해야 정확하다.

빙 웹마스터 도구에는 URL 제출 이력을 보여 주는 화면이 있어, 어떤 URL을 언제 제출했고 크롤러가 언제 방문했는지 시간순으로 확인할 수 있다. 네이버는 서치어드바이저의 요청 수집 메뉴와 사이트 현황에서 제출·수집 상태를 볼 수 있다.

여기서 흔히 하는 실수 하나를 짚어야 한다. 구글에서 site:도메인 검색으로 나오는 결과 개수를 색인 여부의 절대 기준으로 삼는 경우가 많은데, 이 방식은 정확한 색인 현황을 보여 주지 않는다는 점이 여러 차례 지적된 바 있다. 정확한 색인 여부를 확인하려면 서치 콘솔의 URL 검사 도구처럼 검색엔진이 공식 제공하는 도구를 쓰는 편이 안전하다.

나쁜 예는 IndexNow로 제출한 직후 site: 검색 결과 개수만 보고 효과가 없다고 성급하게 판단하는 경우다. 좋은 예는 빙 웹마스터 도구·서치어드바이저의 공식 이력 화면과 서치 콘솔 URL 검사 결과를 함께 놓고, 며칠 간격을 두고 다시 확인하는 경우다.

IndexNow 적용 체크리스트

아래 순서를 그대로 따라가면 설정을 놓치지 않는다. 워드프레스라면 1번부터 3번까지는 플러그인이 자동으로 처리해 주므로, 사람이 직접 신경 써야 할 부분은 5번과 6번, 즉 네이버·구글 각각의 등록 절차와 이후 결과 확인이다.

1. 키 발급: 워드프레스라면 랭크매스나 요스트 SEO에서 자동 생성, 직접 붙이는 경우라면 8자에서 128자 사이 영문·숫자 키를 만든다.
2. 키 파일 위치 확인: 도메인 루트에 올렸는지, 아니라면 keyLocation을 함께 보내는지 확인한다.
3. 제출 대상 URL 정리: 태그·검색 결과 같은 저품질 URL은 제외하고 본문 페이지 위주로 정리한다.
4. 자동화 여부 결정: 플러그인이 있다면 자동 제출에 맡기고, 없다면 발행 시 수동 제출 루틴을 만든다.
5. 네이버 서치어드바이저 선등록: 자체 도메인이라면 IndexNow보다 먼저 서치어드바이저 등록을 마쳤는지 확인한다.
6. 구글 경로 별도 관리: 사이트맵 최종 수정일 갱신과 서치 콘솔 URL 검사를 병행한다.
7. 결과 확인: 빙 웹마스터 도구·네이버 서치어드바이저에서 실제로 확인 시점이 앞당겨졌는지 점검한다.

자주 묻는 질문

IndexNow를 쓰면 구글 색인도 빨라지나요?

아니다. 구글은 IndexNow 참여 검색엔진 목록에 없다. 구글 몫은 사이트맵 제출과 서치 콘솔 URL 검사로 별도로 챙겨야 한다.

IndexNow는 무료인가요?

그렇다. 키 발급과 URL 제출 모두 비용이 들지 않는다. 워드프레스 플러그인의 IndexNow 기능도 대부분 무료 범위에서 제공된다.

워드프레스가 아니어도 쓸 수 있나요?

가능하다. 키 파일을 도메인 루트에 직접 올릴 수 있는 환경이라면 플랫폼과 무관하게 API를 호출할 수 있다. 다만 루트 파일 업로드 자체가 막혀 있는 일부 빌더형 홈페이지라면 빙 웹마스터 도구의 URL 제출 같은 대안을 쓰는 편이 현실적이다.

네이버 블로그도 IndexNow 연동이 필요한가요?

필요 없다. 네이버 블로그는 네이버가 자동으로 수집·색인하는 플랫폼이라, 서치어드바이저 등록도 IndexNow 연동도 대상이 아니다. 이 절차는 자체 도메인으로 운영하는 사이트에만 해당한다.

한 번에 몇 개 URL까지 제출할 수 있나요?

배치 제출 기준 한 번에 최대 1만 개까지 가능하다. 다만 같은 URL을 5분 이내에 다시 제출할 수는 없으므로, 실제 변경이 있는 URL만 골라 보내는 편이 효율적이다.

키 파일을 잃어버리거나 삭제하면 어떻게 되나요?

새 키를 발급해 다시 올리면 된다. 기존 키가 사라져도 새 키 파일을 도메인 루트에 올리고 이후 제출부터 새 키를 쓰면 문제없이 이어서 사용할 수 있다.

서브도메인이 여러 개면 키도 따로 만들어야 하나요?

서브도메인마다 별도 관리가 안전하다. host 값은 도메인 단위로 검증되므로, blog.iruweb.com과 shop.iruweb.com을 함께 운영한다면 각 서브도메인 루트에 맞는 키 파일을 따로 준비하는 편이 오류 없이 동작한다.

RSS 핑(ping)이나 웹훅과 뭐가 다른가요?

목적은 비슷하지만 받는 대상이 다르다. RSS 핑은 피드리더나 특정 서비스에 새 글을 알리는 방식이고, IndexNow는 검색엔진에 URL 변경을 알리는 전용 규격이다. 검색 노출이 목적이라면 RSS 핑만으로는 부족하고 IndexNow가 더 직접적인 경로다.

페이지를 삭제했을 때도 IndexNow를 쓸 수 있나요?

쓸 수 있다. 삭제되거나 더 이상 존재하지 않는 URL도 같은 방식으로 제출하면, 검색엔진이 더 빨리 방문해 삭제 사실을 확인하고 검색 결과에서 내리는 데 도움이 된다.

HTTPS가 아닌 사이트에서도 쓸 수 있나요?

기술적으로는 가능하지만 권장하지 않는다. 프로토콜 자체가 HTTPS를 강제하지는 않지만, 대부분의 검색엔진이 보안 연결이 안 된 사이트의 신뢰도를 낮게 평가하는 추세다. IndexNow를 도입하는 시점에 HTTPS 적용 여부도 함께 점검하는 편이 안전하다.

정리하면 IndexNow, 지금 세팅해야 할까?

지금까지 짚은 내용을 한 줄씩 다시 정리하면 이렇다.

• 역할: 발행·수정 즉시 검색엔진에 알려 확인 시점을 앞당기는 신호이지, 색인을 보장하는 도구는 아니다.
• 지원 범위: 빙·네이버·얀덱스·세즈남·옙·아마존봇은 지원하지만 구글은 지원하지 않는다.
• 구글 대안: 구글 색인 API는 채용 공고·실시간 방송 페이지에만 공식 허용되므로, 일반 콘텐츠는 사이트맵·서치 콘솔로 관리해야 한다.
• 워드프레스: 랭크매스·요스트 SEO 플러그인으로 몇 분 안에 설정이 끝난다.
• 빌더형 홈페이지: 자동 연동이 폭넓게 확인되지는 않으므로 빙 웹마스터 도구 수동 제출을 대안으로 쓸 수 있다.
• 네이버: 서치어드바이저 등록이 먼저이고, IndexNow는 그다음 단계다.
• 효과 확인: site: 검색 결과 개수가 아니라 빙 웹마스터 도구·서치어드바이저·서치 콘솔의 공식 이력 화면으로 확인한다.

결국 IndexNow는 콘텐츠 발행 루틴에 한 단계를 더하는 도구이지, 색인 문제를 통째로 해결해 주는 만능 열쇠는 아니다. 사이트맵·서치 콘솔·서치어드바이저라는 기본기가 먼저 갖춰져 있어야 IndexNow의 효과도 온전히 나타난다. 발행 빈도가 잦은 사이트일수록 도입 효과가 크므로, 지금 운영 중인 사이트의 발행 주기부터 다시 한번 점검해 보는 편이 좋다.

---

새 글을 발행할 때마다 빙과 네이버에 즉시 알리고, 구글 몫은 사이트맵과 서치 콘솔로 따로 챙기는 이 루틴이 번거롭게 느껴지실 수 있습니다. 이루웹은 워드프레스·자체 도메인 홈페이지 제작부터 색인 관리까지 함께 세팅해 드리고 있으니, 홈페이지 제작 서비스를 살펴보시거나 서비스 전체 안내를 확인해 보시기 바랍니다. 구체적인 상담이 필요하시다면 편하게 문의 남겨 주시기 바랍니다.