IndexNow

프로토콜이 동작하는 방식

움직이는 부품은 둘뿐입니다. 첫째는 키입니다. 무작위 문자열을 만들어 그 문자열을 그대로 파일 이름으로 삼은 일반 텍스트 파일을 사이트 루트에 두고 제공하면 됩니다. 이 파일은 설계상 공개되는 것입니다. 사이트 소유자만 만들 수 있는 URL에서 그것을 공개적으로 제공한다는 사실 자체가 소유권 증명의 전부이며, 그래서 IndexNow 키는 비밀이 아니고 코드와 함께 커밋해도 괜찮습니다. 둘째는 전송입니다. 호스트, 키, 키 파일 위치, 그리고 변경된 URL 목록을 담은 POST를 보냅니다.

동작은 의도적으로 단순합니다. IndexNow 문서는 POST 한 번에 10,000개 URL을 상한으로 두는데, 대부분의 사이트가 한 번에 필요로 하는 양을 넘습니다. 새 키로 보내는 첫 전송은 200이 아니라 HTTP 202가 돌아올 수 있습니다. 엔진이 무언가를 받아들이기 전에 키 파일을 가져와 확인하기 때문이며, 그 과정이 끝나면 성공한 전송은 200을 반환합니다. 거부는 거의 언제나 키 파일 때문입니다. 없거나, 이름이 바뀌었거나, 보낸 키와 다른 내용을 제공하는 경우입니다. 잘 되던 전송이 실패하기 시작하면 여기부터 확인하세요.

목록에 있는 엔진

IndexNow는 참여 엔드포인트를 공개하며, 이 글을 쓰는 시점 기준으로 Bing, Naver, Seznam.cz, Yandex, Yep입니다. 이해해 둘 만한 설계 요점은 전송이 한 번이면 된다는 것입니다. 참여 엔드포인트 중 아무 곳에나 보내면 나머지와 공유되므로 같은 묶음을 다섯 번 보내서 얻을 것은 없습니다. 여러 콘텐츠 플랫폼과 CDN도 IndexNow 지원을 내장하고 있어서, 아무도 결정한 적 없는데 이미 전송하고 있는 사이트도 있습니다.

• Google은 그 목록에 없습니다. IndexNow로 보내도 Google 검색에는 아무 효과가 없습니다. Google은 여전히 예전 방식으로, 즉 링크와 이미 Search Console에 등록한 사이트맵으로 페이지를 찾습니다. IndexNow를 Google에 빨리 올라가는 방법이라고 파는 설명은 다른 프로토콜 이야기를 하고 있는 것입니다.
• 대부분이 수고를 들이는 이유는 Bing입니다. 영어권에서는 참여 엔진 가운데 압도적으로 큰 쪽이라, 대부분의 사이트에서는 이 프로토콜에 반나절을 쓸 값어치가 있는지를 사실상 이 하나가 결정합니다.
• 지역 엔진은 구색이 아닙니다. 한국, 체코, 러시아가 실제 시장이라면 Naver, Seznam.cz, Yandex가 그곳의 자국 검색엔진이며, 이들이 포함되어 있다는 사실 자체가 이 프로토콜을 돌릴 진짜 이유가 됩니다.
• IndexNow 자신의 설명도 AI 답변에 기대고 있습니다. 문서는 이 프로토콜을 AI 기반 검색 결과에서 콘텐츠를 최신으로 유지하는 데 도움이 되는 것으로 설명합니다. 바탕이 되는 색인의 신선도는 거기서 읽어 가는 어떤 어시스턴트보다 상류에 있으므로, 이는 정직한 표현입니다.

200이 실제로 알려주는 것

전송이 접수되었다는 뜻입니다. 그게 전부입니다. IndexNow 문서는 이 점에서 보기 드물게 직설적입니다. URL을 보냈다고 색인된다는 보장은 없습니다. 크롤링할지 여부는 엔진이 자체 일정, 크롤링 할당량, 품질 검사에 비추어 계속 판단하기 때문입니다. 이 프로토콜은 페이지를 발견 대기열 앞쪽으로 옮길 뿐이고, 발견 이후의 모든 단계는 그대로입니다.

저희는 agentceres.com에서 IndexNow를 빌드마다가 아니라 일일 루틴의 한 단계로 실행합니다. 변경되지 않은 URL을 과도하게 재전송하지 말라고 프로토콜이 요청하기 때문입니다. 오늘 실행에서는 운영 중인 사이트맵을 읽어 한 번의 POST로 415개 URL을 보냈고 엔드포인트는 HTTP 200을 반환했습니다. 이 숫자가 저희가 받는 피드백의 전부입니다. 콜백도, URL별 상태도, 크롤러가 언제 실제로 왔는지 또는 오기는 했는지 알려주는 것도 없습니다. 확인은 Bing Webmaster Tools, 해당 엔진에 대해서는 Search Console, 아니면 자체 서버 로그에서 가져와야 합니다. 저희 전송 스크립트는 올려둔 키 파일이 없거나 그 내용이 스크립트의 키와 어긋나면 아예 실행을 거부합니다. 그 어긋남은 거부로 돌아오지만 겉보기에는 평범한 실패 요청과 같아서 그냥 지나치기 쉽기 때문입니다.

• 설정할 값어치가 있는 경우는 유기적 재크롤링을 기다리는 것이 실제 지연이 될 만큼 자주 페이지를 올리거나 바꾸는 때입니다. 문서 사이트, 프로그래매틱하게 만든 페이지 묶음, 재고가 바뀌는 커머스 카탈로그, 또는 삭제한 페이지가 색인에 남아 있으면 곤란한 경우입니다.
• 별로 도움이 안 되는 경우는 한 달에 몇 페이지만 올리고 내부 링크도 잘 되어 있는 때입니다. 이미 사이트를 넉넉히 감당하는 크롤링 예산에는 쓰는 것을 도울 필요가 없습니다.
• 크롤링할 이유를 대신하지는 결코 못합니다. 얄팍한 페이지를 더 빨리 알리면 더 빨리 보게 될 뿐입니다. 깔끔한 canonical 태그나 llms.txt 파일과 같은 종류의 지렛대로, 장애물을 치우는 배관이지 누군가 관심을 가질 이유는 아닙니다.