Bing 웹마스터 도구와 IndexNow로 새 글 알리기

한 문장 답

Bing 웹마스터 도구는 Google Search Console에서 확인된 사이트와 사이트맵을 그대로 가져올 수 있고, IndexNow로 바뀐 URL을 한 번 보내면 Bing과 네이버를 포함한 참여 검색엔진에 공유됩니다. 다만 IndexNow 요청이 받아들여졌다는 응답은 “요청을 받았다”는 뜻일 뿐이고, 크롤링이나 색인을 약속하지는 않습니다. 이 글은 등록부터 키 파일, 전송 예제, 배포 파이프라인 연결, 그리고 결과를 확인하는 보고서까지 순서대로 다룹니다.

Bing을 따로 챙겨야 하는 이유

국내에서는 Google과 네이버만 관리해도 충분하다고 생각하기 쉽습니다. 그런데 Bing 검색 색인은 Bing 검색결과에만 쓰이지 않습니다. Bing 웹마스터 가이드라인은 Bing이 콘텐츠를 Bing 검색, Copilot, 그리고 grounding API 결과 전반에 보여 준다고 설명하고, 생성형 답변과 AI 경험에도 기본 SEO 원칙이 그대로 적용된다고 적어 두었습니다.

Microsoft Advertising 쪽 설명을 보면 Copilot의 웹 검색 기반 답변은 Bing 검색을 활용합니다. 여기서 한 걸음 더 나아가 “Copilot의 모든 답변이 Bing 색인에서 나온다”거나 “다른 AI 검색 서비스가 Bing에 크게 의존한다”고 말하는 글도 보이는데, 공개 자료로 확인되는 범위를 넘는 주장이라 이 가이드에서는 쓰지 않습니다. 확인된 사실만으로도 Bing의 검색과 AI 노출 영역을 함께 점검할 이유는 충분합니다.

Bing은 IndexNow를 두고 검색과 AI 경험 전반에서 정보를 최신 상태로 유지하는 데 도움이 된다고 설명합니다(Bing 웹마스터 블로그, AI Performance 소개). 새 글을 자주 올리거나 가격, 재고, 일정처럼 자주 바뀌는 정보를 다루는 사이트라면 특히 챙길 만합니다.

등록과 소유 확인

Search Console에서 가져오기

가장 빠른 방법은 이미 Google Search Console에 확인된 사이트를 가져오는 것입니다. Bing 웹마스터 블로그와 Bing 도움말에 따르면 가져오기 과정에서 고른 사이트는 자동으로 소유 확인이 되고, Search Console에 제출해 둔 사이트맵도 함께 넘어옵니다. 새로 파일을 올리거나 DNS를 건드릴 필요가 없어서 처음 시작할 때 부담이 가장 적습니다.

직접 확인하는 방법

Search Console을 쓰지 않거나 권한이 없다면 직접 확인합니다. Bing이 제공하는 방법은 다음과 같습니다.

방법	하는 일	잘 맞는 경우
XML 파일	BingSiteAuth.xml 파일을 사이트 루트에 올림	정적 파일 배포가 쉬운 사이트
meta 태그	콘솔에 표시된 <meta> 태그를 홈페이지 <head>에 넣음	CMS에서 head 편집이 가능한 경우
DNS 레코드	도메인 DNS에 지정된 레코드를 추가	하위 도메인을 한꺼번에 관리할 때
Domain Connect	지원하는 DNS 업체 계정으로 연결	DNS 업체가 Domain Connect를 지원할 때
GSC 가져오기	Search Console에서 확인된 사이트를 가져옴	이미 Search Console을 쓰는 경우

확인 파일이나 태그를 쓰는 경우에는 배포 과정에서 빠지지 않는지 점검하세요.

사이트맵 제출

가져오기 과정에서 사이트맵이 넘어오지 않았다면 콘솔에서 직접 추가합니다. 2025년 6월 블로그 글에서 Bing은 사이트맵을 적어도 24시간에 한 번 처리한다고 밝혔습니다. 사이트맵 형식 자체는 sitemap.xml 만들기와 제출하기에 정리해 두었습니다.

IndexNow는 어떻게 동작하나

IndexNow는 사이트가 “이 URL이 추가되거나 바뀌었거나 삭제됐다”고 검색엔진에 직접 알리는 공개 프로토콜입니다. 크롤러가 알아서 찾아올 때까지 기다리는 대신, 사이트 쪽에서 먼저 신호를 보내는 방식입니다. 규칙은 IndexNow 문서에 정리돼 있습니다.

핵심은 세 가지입니다.

1. 사이트 소유자는 키를 하나 만듭니다. 길이는 8자에서 128자이고, 영문 대소문자, 숫자, 하이픈만 씁니다.
2. 그 키를 내용으로 하는 UTF-8 텍스트 파일 {key}.txt를 호스트 루트에 올립니다. 다른 위치에 두려면 요청에 keyLocation을 적는데, 이 경우 그 파일이 있는 경로 아래 URL만 제출할 수 있습니다.
3. 바뀐 URL을 참여 엔드포인트 한 곳에 보냅니다. 한 URL은 GET으로, 여러 URL은 POST JSON으로 한 번에 최대 10,000개까지 보냅니다.

유효한 요청은 참여 검색엔진들 사이에 공유됩니다. 그래서 Bing에 보냈다고 네이버에 또 보낼 필요는 없습니다. 공유는 비동기로 이뤄질 수 있으니 엔진마다 반영 시점이 다를 수 있다는 점은 감안해야 합니다.

참여 검색엔진

IndexNow 문서에 공개된 참여 엔드포인트는 Bing, 네이버, Seznam.cz, Yandex, Yep이며, FAQ에는 Amazon 엔드포인트도 적혀 있습니다. 이 공개 목록에 Google은 없습니다. Google 쪽 갱신 안내는 아래에서 따로 다룹니다.

네이버의 IndexNow

네이버는 2023년 7월 25일부터 IndexNow를 지원합니다(네이버 서치어드바이저 공지). 엔드포인트는 https://searchadvisor.naver.com/indexnow입니다.

네이버 IndexNow FAQ는 몇 가지를 분명히 해 둡니다. 200 응답은 요청을 받았다는 뜻이고 “문서들의 색인을 보장하지는 않습니다”. 전체 제출량에 정해진 상한은 없지만 짧은 시간에 몰아서 보내는 요청은 제한될 수 있습니다. 한 번에 수만 건을 쏟아붓기보다 바뀐 URL만 그때그때 보내는 편이 맞습니다. 서치어드바이저 등록과 수집 요청은 네이버 서치어드바이저 가이드에서 이어서 볼 수 있습니다.

키 파일 만들고 URL 보내기

1. 키 만들기와 파일 올리기

키는 허용된 문자와 길이 조건에 맞춰 만듭니다. 터미널에서 32자리 16진수 키를 만드는 예입니다.

openssl rand -hex 16
# 예: 3f9c2a7e5b1d4c8fa06e92b7d1c3e4f5

정적 사이트라면 빌드 결과물 루트(public/ 같은 폴더)에 파일을 둡니다.

public/3f9c2a7e5b1d4c8fa06e92b7d1c3e4f5.txt

파일 내용은 키 문자열 한 줄뿐입니다. 배포 후 https://example.com/3f9c2a7e5b1d4c8fa06e92b7d1c3e4f5.txt를 브라우저로 열어 키가 그대로 보이는지 확인합니다. 리디렉션이 걸리거나 HTML 오류 페이지가 나오면 검증이 실패합니다.

2. POST JSON으로 보내기

여러 URL을 한 번에 보낼 때는 POST를 씁니다.

curl -i -X POST "https://api.indexnow.org/indexnow" \
  -H "Content-Type: application/json; charset=utf-8" \
  -d '{
    "host": "example.com",
    "key": "3f9c2a7e5b1d4c8fa06e92b7d1c3e4f5",
    "keyLocation": "https://example.com/3f9c2a7e5b1d4c8fa06e92b7d1c3e4f5.txt",
    "urlList": [
      "https://example.com/guides/bing-webmaster-indexnow",
      "https://example.com/guides/sitemap"
    ]
  }'

URL 하나만 알릴 때는 GET으로도 충분합니다.

curl -i "https://www.bing.com/indexnow?url=https://example.com/guides/sitemap&key=3f9c2a7e5b1d4c8fa06e92b7d1c3e4f5"

urlList의 URL은 모두 host와 같은 호스트여야 합니다. 다른 도메인이 섞이면 요청 전체가 거절될 수 있습니다.

3. 응답 코드 읽기

코드	의미	할 일
200	요청을 정상적으로 받음	그대로 둠. 색인 여부는 보고서에서 확인
202	요청은 받았고 키 검증이 아직 진행 중	키 파일이 열리는지 확인하고 기다림
400	형식이 잘못된 요청	JSON 구조와 필드 이름 점검
403	키가 유효하지 않음	키 파일 위치, 내용, 리디렉션 여부 점검
422	URL이 호스트와 맞지 않거나 키와 맞지 않음	host, keyLocation, URL 목록 대조
429	요청이 너무 많음	전송 간격을 늘리고 바뀐 URL만 보냄

200과 202 모두 “받았다”는 신호입니다. 색인이 됐다는 뜻으로 읽으면 안 됩니다.

배포 파이프라인에 넣는 법

사람이 매번 손으로 curl을 치는 방식은 금방 잊히기 마련입니다. 배포가 끝난 직후, 이번 배포에서 바뀐 URL만 골라 보내도록 스크립트에 넣어 두는 편이 낫습니다. 애드브랜치처럼 정적 빌드 후 배포하는 사이트라면 다음 흐름이면 충분합니다.

1. 빌드 전에 직전 배포의 사이트맵을 내려받아 둡니다.
2. 새로 빌드한 사이트맵과 비교해 새 URL과 <lastmod>가 바뀐 URL을 뽑습니다.
3. 배포가 성공한 뒤에만 그 목록을 IndexNow로 보냅니다.
4. 응답 코드를 로그에 남기고, 403이나 422가 나오면 배포 알림에 경고를 띄웁니다.

Node로 3번과 4번을 구현한 짧은 예입니다.

// scripts/indexnow.mjs
const KEY = process.env.INDEXNOW_KEY;
const HOST = "example.com";

export async function submitChanged(urls) {
  if (urls.length === 0) return;
  const res = await fetch("https://api.indexnow.org/indexnow", {
    method: "POST",
    headers: { "Content-Type": "application/json; charset=utf-8" },
    body: JSON.stringify({
      host: HOST,
      key: KEY,
      keyLocation: `https://${HOST}/${KEY}.txt`,
      urlList: urls.slice(0, 10000),
    }),
  });
  console.log(`IndexNow ${res.status} (${urls.length} URLs)`);
  if (res.status >= 400) throw new Error(`IndexNow failed: ${res.status}`);
}

몇 가지 요령이 있습니다. 미리보기나 스테이징 배포에서는 보내지 않도록 환경 변수로 막습니다. 바뀌지 않은 URL을 매번 통째로 보내는 것은 피하고, 추가·변경·삭제된 URL만 전송 목록에 넣습니다. 키는 공개 파일과 짝을 이뤄야 하므로 저장소 설정과 배포 환경 변수에서 같은 값을 쓰는지 확인합니다.

Google은 목록에 없다: 사이트맵 lastmod가 기본

IndexNow 참여 목록에 Google은 없습니다. Google에 바뀐 페이지를 알리는 기본 수단은 여전히 사이트맵입니다. Google 사이트맵 안내에 따르면 Google은 <lastmod>가 일관되고 검증 가능할 만큼 정확할 때 그 값을 사용하며, priority와 changefreq는 쓰지 않습니다. 날짜 형식은 W3C Datetime입니다.

그래서 IndexNow를 붙였다고 사이트맵 관리를 느슨하게 하면 안 됩니다. 실제로 내용이 바뀐 날짜만 <lastmod>에 반영하고, 빌드할 때마다 모든 URL의 날짜를 오늘로 덮어쓰는 설정은 끄는 것이 좋습니다. 그런 값은 정확하지 않기 때문에 신호로 쓰이지 않을 수 있습니다.

반영 속도에 대한 기대치도 맞춰 둡니다. Google의 SEO 기본 가이드는 어떤 변화는 몇 시간 만에, 어떤 변화는 몇 달이 걸려 반영된다고 설명하고, 재크롤링 요청 안내는 크롤링에 며칠에서 몇 주가 걸릴 수 있다고 말합니다.

검사기에서 확인하는 항목

애드브랜치 SEO·GEO 검사기는 이 부분을 두 규칙으로 봅니다.

• sitemap-discovery: robots.txt 선언 등을 통해 사이트맵 파일을 찾고 읽을 수 있는지 확인합니다.
• sitemap-lastmod: 사이트맵에서 검사한 URL의 <lastmod>를 봅니다. 사이트맵을 읽지 못했으면 확인 불가, 사이트맵 인덱스이거나 URL이 목록에 없으면 해당 없음으로 처리합니다. <lastmod>가 없거나, W3C Datetime 형식이 아니거나, 미래 날짜면 경고이고 그 밖에는 통과입니다.

IndexNow 전송 여부 자체는 바깥에서 확인할 방법이 없어 검사 항목에 넣지 않았습니다. 규칙 전체는 검사 규칙과 검사 방법에서 볼 수 있습니다.

AI Performance 보고서로 결과 보기

2026년 2월 Bing 웹마스터 도구에 AI Performance 보고서가 공개 미리보기로 추가됐습니다(Bing 웹마스터 블로그). 이 보고서는 사이트 콘텐츠가 Microsoft Copilot, Bing의 AI 요약, 파트너 연동 서비스에서 어떻게 나타나는지 보여 줍니다.

운영 순서는 단순합니다. IndexNow와 사이트맵으로 바뀐 페이지를 알리고, 일반 검색 성과 보고서와 AI Performance 보고서에서 그 페이지가 어떻게 잡히는지 봅니다. 한 번 보고 끝내기보다 월 단위로 같은 페이지 묶음을 비교해야 변화가 보입니다. Google 쪽 지표와 함께 보는 방법은 SEO·GEO 성과 측정에 정리했습니다.

자주 묻는 질문

IndexNow를 쓰면 Bing과 네이버에 바로 색인되나요?

아닙니다. 200이나 202 응답은 요청을 받았다는 뜻입니다. 크롤링 여부와 시점, 색인 여부는 각 검색엔진이 따로 판단합니다. 네이버도 FAQ에서 색인을 보장하지 않는다고 밝히고 있습니다.

Bing과 네이버에 각각 보내야 하나요?

한 곳에 보내면 됩니다. 유효한 IndexNow 요청은 참여 검색엔진 사이에 공유됩니다. 다만 공유가 비동기로 이뤄질 수 있어 엔진마다 반영 시점은 다를 수 있습니다.

Google에도 IndexNow가 통하나요?

공개된 참여 목록에 Google은 없습니다. Google에는 정확한 <lastmod>가 들어간 사이트맵과 Search Console 제출을 기본으로 쓰고, IndexNow는 Bing과 네이버 같은 참여 엔진을 위한 보조 수단으로 생각하는 편이 맞습니다.

관련 가이드

• sitemap.xml 만들기와 제출하기
• 네이버 서치어드바이저 가이드
• SEO·GEO 성과 측정
• robots.txt 작성법