새 글을 올리거나 고쳤을 때 검색엔진에 알리는 법 — 사이트맵 lastmod, IndexNow, 구글 서치 콘솔, 네이버 수집 요청

글을 올렸다고 검색엔진이 바로 아는 것은 아니다

홈페이지에 새 글을 올리거나 영업시간·가격을 고쳤을 때, 검색엔진은 그 사실을 저절로 바로 알지 못합니다. 검색로봇이 다음에 들를 때까지 기다리거나, 사이트 쪽에서 ‘이 주소가 새로 생겼다, 바뀌었다’고 알려야 합니다.

이것이 AI 답변과도 이어지는 이유는, 구글 AI 개요처럼 검색 색인에 들어 있는 문서에서 출처를 고르는 AI 답변이 있기 때문입니다. 구글은 AI 개요·AI 모드의 링크로 보이려면 “a page must be indexed and eligible to be shown in Google Search with a snippet”, 즉 페이지가 색인돼 있고 스니펫과 함께 검색에 나올 수 있어야 한다고 적었습니다. Copilot과 빙 색인의 관계, ChatGPT 검색이 외부 검색 제공자를 쓴다는 OpenAI의 설명과 그 한계는 한 페이지 한 주소 글에, 네이버 AI 브리핑이 무엇을 출처로 쓰는지 공개된 범위는 네이버 AI 브리핑 글에 정리했습니다. 그 글을 쓸 때(2026-10-14)까지 네이버가 운영자용으로 공개한 AI 브리핑 출처 선정 기준 문서는 찾지 못했지만, 웹 문서가 출처 후보가 되려면 먼저 네이버가 그 문서를 수집해야 한다고 보는 것이 자연스럽습니다(제 추론입니다).

그래서 이 글은 한 가지만 다룹니다. 글을 올린 뒤, 또는 고친 뒤 엔진마다 무엇을 하면 되는가. 걸리는 기간은 AI 상위노출은 얼마나 걸리나에, 날짜가 AI 답변에 주는 영향은 AI 답변 최신성에 따로 있으니 여기서는 되풀이하지 않습니다.

엔진마다 할 일 — 한 장으로

공통 규칙은 두 가지입니다. 사이트맵이 먼저이고, 내용이 바뀌지 않은 주소는 다시 보내지 않습니다. 아래는 이 표의 칸마다 근거가 된 문서입니다.

구글 — 사이트맵과 서치 콘솔 URL 검사

구글의 재크롤 요청 문서는 방법을 둘로 나눕니다. 주소 몇 개라면 URL 검사 도구, 주소가 많으면 사이트맵 제출입니다. 그리고 이렇게 덧붙였습니다.

“Keep in mind that there’s a quota for submitting individual URLs and requesting a recrawl multiple times for the same URL won’t get it crawled any faster.”

개별 URL 제출에는 할당량이 있고, 같은 주소를 여러 번 요청해도 더 빨리 크롤되지 않는다는 뜻입니다. 할당량이 몇 개인지는 문서에 숫자로 나와 있지 않습니다. URL 검사에서 색인을 요청하려면 서치 콘솔 속성의 소유자이거나 전체 권한 사용자여야 한다고도 적혀 있습니다. 같은 문서는 크롤에 “a few days to a few weeks”, 며칠에서 몇 주가 걸릴 수 있고, 요청해도 검색 결과에 바로 또는 아예 들어간다는 보장은 없다고 밝힙니다.

사이트맵은 서치 콘솔의 사이트맵 보고서에서 제출하거나, robots.txt에 Sitemap: 줄을 넣어 알릴 수 있습니다. 다만 구글 사이트맵 문서는 제출이 “merely a hint”, 단지 힌트일 뿐이라고 적었습니다.

구글이 IndexNow를 받는다고 볼 근거는 찾지 못했습니다. 구글의 재크롤 요청 문서에는 IndexNow가 나오지 않고, 2026-10-23에 연 IndexNow.org의 참여 검색엔진 목록(searchengines.json)에도 구글은 없었습니다. 구글에는 사이트맵과 서치 콘솔로 알립니다.

빙과 IndexNow — 한 번 보내면 참여 엔진이 나눠 받는다

IndexNow는 ‘이 주소가 추가·수정·삭제됐다’고 검색엔진에 직접 알리는 방식입니다. IndexNow 문서에는 참여 검색엔진이 받은 URL을 서로 공유한다는 약속이 적혀 있습니다.

“Search engines adopting the IndexNow protocol agree that submitted URLs will be automatically shared with all other participating search engines.”

그래서 문서상으로는 빙에 보내든 네이버에 보내든 공용 엔드포인트(api.indexnow.org)에 보내든, 한 번 보내면 참여 엔진 모두에 공유됩니다. 공유된 URL을 실제로 크롤·색인할지는 각 엔진이 정합니다. 2026-10-23에 확인한 참여 목록은 Bing, Yandex, Seznam, Naver, Yep, Internet Archive, Amazonbot이었습니다.

쓰기 전에 필요한 것은 키 파일 하나입니다. 문서가 권하는 방법은 키 문자열을 담은 UTF-8 텍스트 파일(키.txt)을 사이트 루트에 올려 두는 것이고, 엔진은 그 파일을 열어 사이트 소유를 확인합니다. 한 번의 POST 요청에 최대 10,000개 URL을 담을 수 있다고 IndexNow 문서와 네이버 ‘페이지 갱신 요청하기’ 문서가 같이 적었습니다.

무엇을 보낼지는 빙 안내가 분명합니다. IndexNow를 쓰기 시작한 뒤 추가·수정·삭제된 URL만 보내고, 지난해 바뀐 URL까지 올릴 필요는 없다고 적었습니다. IndexNow FAQ는 더 직접적입니다. “Submit only when content has changed. Do not resubmit unchanged URLs.” — 내용이 바뀌었을 때만 보내고, 바뀌지 않은 URL은 다시 보내지 말라는 뜻입니다.

보낸 뒤 돌아오는 응답 코드는 IndexNow 문서의 표에 이렇게 정리돼 있습니다.

200이 색인을 뜻하지 않는다는 점, 빙 웹마스터 도구 URL 검사 상태를 읽는 법은 한 페이지 한 주소 글에 정리했습니다. 빙 안내 역시 “Using IndexNow does not guarantee that web pages will be crawled or indexed by search engines.”라고, IndexNow를 써도 크롤·색인이 보장되지 않는다고 적었습니다.

네이버 — IndexNow와 별개로 수집 요청이 있다

네이버 서치어드바이저는 IndexNow를 지원합니다. ‘IndexNow 소개’ 문서에는 새로 만들거나 업데이트·삭제된 페이지를 네이버 검색에 알릴 수 있고, “갱신된 페이지 정보가 다른 검색사들에게도 공유됩니다”라고 적혀 있습니다. 같은 문서는 “웹페이지의 색인을 보장하지는 않습니다”라는 문장도 함께 둡니다.

네이버 쪽에서 눈여겨볼 것은 IndexNow FAQ의 이 문답입니다.

“Q. IndexNow는 서치 어드바이저 내의 수집 요청이나 RSS, 사이트맵 제출을 대체하나요? 아니요, IndexNow는 새로운 정보가 있다는 것을 검색엔진에 빨리 알리고, 동시에 다른 검색엔진들에 널리 알리기에 좋습니다. 서치 어드바이저 웹마스터 도구의 수집 요청, RSS, 사이트맵 제출 중 적절하게 선택하여 사용하실 수 있습니다.”

IndexNow가 웹마스터 도구의 수집 요청·RSS·사이트맵 제출을 대신하지 않는다는 뜻입니다. 사이트맵과 RSS는 서치어드바이저 웹마스터 도구에서 제출합니다. 네이버는 제출된 RSS와 사이트맵을 “콘텐츠 피드”로 보고 주기적으로 다시 방문한다고 적었고, RSS는 본문을 담느라 많은 URL을 넣기 어려우니 되도록 사이트맵을 적극 쓰라고 권합니다.

웹 페이지 수집 요청에는 기대치를 낮추는 문장이 여럿 있습니다. ‘수집요청 및 검색제외’ 문서의 내용입니다.

• 요청한 URL도 우선순위에 따라 처리되므로 검색로봇이 실시간으로 방문하지 않고, “최소 1일에서 몇 주간의 시간이 소요될 수 있습니다.”
• 그러므로 “동일 URL에 대해서 매일 반복적으로 수집요청을 제출할 필요는 없습니다.”
• 수집 요청은 수집 대상 URL을 전달하는 “도우미의 역할만” 하고, 수집에 성공해도 검색 결과에 노출된다는 보장은 없습니다.
• 네이버는 “인위적인 수집요청 처리보다는 검색로봇의 자연스러운 수집을 권장합니다.”

그래서 저는 수집 요청을 모든 글에 쓰지 않고, 상담이나 예약으로 이어지는 중요한 페이지를 새로 만들었을 때 한 번 씁니다. 다른 사이트에서 IndexNow를 보낸 지 며칠이 지나도 검색에 나타나지 않던 새 페이지가, 운영자가 검색 콘솔에서 직접 수집을 요청하자 같은 날 오전 안에 페이지 제목 검색 1위로 잡힌 기록이 있습니다(기록). 그 기록에서는 색인 안 됨을 ‘전체 결과 수가 적다’가 아니라 ‘페이지 제목을 그대로 검색해도 0건’일 때로만 판정했습니다. 한 사이트·한 번의 관찰이고, 같은 결과를 약속하는 근거는 아닙니다.

lastmod는 정직하게

사이트맵의 lastmod는 ‘이 페이지가 언제 바뀌었나’를 검색엔진에 알리는 칸입니다. 이 칸은 정확할 때만 쓸모가 있습니다.

• 구글: lastmod가 일관되고 검증 가능하게 정확할 때만 쓰고, 그 값은 페이지의 ‘의미 있는 마지막 수정’을 가리켜야 한다고 적었습니다. 본문·구조화 데이터·링크 변경은 대개 의미 있는 수정이고, 저작권 연도 변경은 아니라는 예도 들었습니다. <priority>와 <changefreq>는 무시한다고 밝힙니다.
• 빙: 2025년 7월 웹마스터 블로그에서 lastmod가 “remains a key signal”, 여전히 핵심 신호라고 하면서 이렇게 적었습니다.

“Avoid setting lastmod to the time your sitemap was generated unless the content on that URL was actually updated.”

사이트맵을 만든 시각을 lastmod로 넣지 말고, 그 URL의 내용이 실제로 바뀌었을 때만 날짜를 바꾸라는 뜻입니다. 같은 글은 changefreq와 priority도 빙이 무시한다고 밝혔습니다.

• 네이버: ‘RSS 및 사이트맵 제출’ 문서는 lastmod를 ‘페이지가 수정된 날짜’, 선택 항목으로 설명합니다. 네이버가 lastmod를 어떻게 쓰는지 더 자세한 설명은 찾지 못했습니다.

정리하면 규칙은 하나입니다. 내용이 바뀐 날만 날짜를 바꾸고, 날짜를 바꾼 주소만 알립니다. 배포할 때마다 사이트 전체의 lastmod를 빌드한 날로 채우는 설정은, 위 문서들에 비추어 보면 lastmod를 믿을 수 없는 값으로 만드는 쪽입니다(제 해석입니다).

이 규칙은 생각보다 자주 어긋납니다. 다른 사이트에서 새 페이지 17개가 lastmod 없이 사이트맵에 나가고 있던 것을 IndexNow를 보내기 전에 발견한 적이 있고(기록), 페이지에 새 섹션을 넣고도 lastmod를 예전 날짜로 둔 적도 있습니다(기록). 첫 번째는 날짜를 손으로 적지 않고 원고 레지스트리에서 사이트맵이 읽어 오는 구조로 바꿔 재발을 막았습니다. 두 번째는 본문과 사이트맵 날짜가 서로 다른 파일에 있어서 생긴 실수였고, 그 기록을 쓸 때까지 이런 어긋남을 자동으로 잡는 장치는 없었습니다.

이 사이트는 어떻게 보내나 (자체 기록)

이 사이트(hwano-ai.com)에서 하는 방식을 그대로 적습니다.

lastmod: 인사이트 글은 원고 머리에 적은 updated 날짜가 화면의 확인일, 구조화 데이터의 dateModified, 사이트맵 lastmod로 함께 나갑니다. 기록 글도 updated가 있으면 같은 값이 나가고, 없으면 정해 둔 기본 날짜를 씁니다. 고정 페이지는 내용이 마지막으로 바뀐 날을 사이트맵 설정에 페이지별로 적어 둡니다. 2026-10-19 점검 때 사이트맵에는 URL 152개가 있었고, 모두 정본 주소였으며, 모든 URL에 lastmod가 있었습니다.

IndexNow: npm run indexnow 명령이 scripts/indexnow.mjs를 실행합니다. 주소를 인자로 주면 그 주소만, 주지 않으면 빌드된 사이트맵(dist/sitemap-0.xml)의 주소 전체를 hwano-ai.com 주소만 걸러 하나의 POST 요청에 담아 공용 엔드포인트(api.indexnow.org)와 네이버 엔드포인트(searchadvisor.naver.com/indexnow) 두 곳에 보냅니다. 키 파일은 사이트 루트에 배포돼 있습니다. 전체 제출은 처음 등록할 때 한 번만 쓰고, 그 뒤로는 배포가 라이브에 반영된 것을 확인한 다음 내용이 실제로 바뀐 주소만 하나씩 넣어 보냅니다. CSS처럼 모양만 바뀐 배포에서는 lastmod도 올리지 않고 IndexNow도 보내지 않습니다.

2026-10-19에 보낸 결과입니다.

홈 주소의 422는 원인을 확인하지 못했습니다. 문서에 적힌 뜻만 옮깁니다. IndexNow 문서의 표는 422를 “In case of URLs which don’t belong to the host or the key is not matching the schema in the protocol”, 보낸 URL이 호스트에 속하지 않거나 키가 프로토콜 형식과 맞지 않을 때라고 적었고, 네이버 문서는 “URL이 key 정보와 일치하지 않습니다”라고 적었습니다. IndexNow FAQ는 흔한 원인으로 도메인 불일치, 키 파일 누락이나 접근 불가, 의미 있는 변경 없이 같은 URL을 반복 제출하는 경우를 꼽습니다. 홈 주소에 대한 api.indexnow.org 응답은 기록에 없습니다. 같은 키·같은 호스트로 보낸 다른 두 주소는 네이버에서도 200을 받았으니 키 파일 자체의 문제는 아닐 것으로 보지만(제 추론입니다), 위 원인 가운데 무엇인지는 이 기록만으로 가릴 수 없습니다.

올린 뒤·고친 뒤 체크리스트

새 페이지를 올렸을 때

• 배포가 끝나 실제 주소에서 200으로 열리는지 확인했다
• 그 주소가 정본 주소(https, www 여부, 끝 슬래시까지)이고 사이트맵에 들어 있다
• 사이트맵 lastmod가 올린 날이다 — 비어 있지 않다
• 메뉴나 관련 글에서 새 페이지로 가는 내부 링크가 있다
• 구글: 서치 콘솔 URL 검사에서 색인을 한 번 요청했다
• 빙·네이버: IndexNow로 그 주소 하나를 보내고 응답 코드를 적어 두었다
• 네이버: 중요한 페이지라면 서치어드바이저에서 웹 페이지 수집을 한 번 요청했다

기존 페이지를 고쳤을 때

• 고친 것이 본문·가격·시간·구조화 데이터·링크처럼 내용에 해당한다(모양만 바뀌었다면 아래는 하지 않는다)
• 그 페이지의 lastmod를 고친 날로 바꿨다 — 다른 페이지 날짜는 건드리지 않았다
• IndexNow로 바뀐 주소만 보냈다
• 같은 주소를 같은 날 여러 번, 또는 매일 반복해 요청하지 않았다

며칠 뒤 확인

• 구글은 URL 검사, 빙은 웹마스터 도구 URL 검사, 네이버는 페이지 제목 검색과 site: 검색으로 들어갔는지 본다
• 200이 아닌 응답이 있었다면 위 표의 뜻을 보고 키 파일 위치와 보낸 주소의 호스트부터 확인한다

아무것도 보장하지 않는다

이 글의 모든 작업은 검색엔진에 ‘여기를 봐 달라’고 알리는 일입니다. 실제로 크롤할지, 색인에 넣을지, AI 답변의 출처로 쓸지는 각 엔진이 정합니다. 구글은 크롤 요청이 검색 결과 포함을 보장하지 않는다고, 빙은 IndexNow가 크롤·색인을 보장하지 않는다고, 네이버는 수집에 성공해도 노출을 보장하지 않는다고 각각 문서에 적었습니다. 색인된 뒤에도 AI 답변에 인용되는 것은 또 다른 단계입니다.

아직 모르는 것도 적어 둡니다.

• 2026-10-19에 200을 받은 두 주소가 언제 크롤·색인됐는지는 이 글을 쓰는 시점에 따로 확인하지 않았습니다. 200은 접수만 뜻합니다.
• 홈 주소의 422 원인은 확인 전입니다. 확인되면 이 글에 날짜와 함께 덧붙입니다.
• 한 사이트의 운영 방식과 기록입니다. 다른 사이트에서 같은 응답이나 같은 속도를 기대할 근거는 아닙니다.

새 페이지가 크롤·색인을 거쳐 답변에 쓰이기까지의 단계와 기간은 AI 상위노출은 얼마나 걸리나에, 진단부터 재측정까지의 순서는 진행 방식에 있습니다.

이 글을 쓴 사람

이 글은 AI 상위노출(AI 검색 노출) 작업을 하는 유환호가 썼습니다. 이 주제로 일을 하고 있으므로 이해관계가 있습니다. 응답 코드 표는 이 사이트(hwano-ai.com)에서 날짜를 적어 직접 받은 값이고, 인용한 구글·빙·IndexNow·네이버 서치어드바이저 문서는 2026-10-23에 원문을 열어 문장을 대조했습니다. 문서 내용이 바뀌거나 422의 원인이 확인되면 이 글에 날짜와 함께 고칩니다.