블로그 배포 스크립트에 IndexNow 색인 알림 자동화

블로그 배포 스크립트에 IndexNow ping 단계를 끼워 넣었다.

작업 자체는 publish.sh 한 파일 수정이지만, 이게 왜 필요했고 어떤 흐름으로 처리됐는지 짚어두려고 기록으로 남긴다.

배경 — 배포하면 끝이라는 착각

콘텐츠를 발행해도 검색 엔진이 크롤링해 가기 전까지는 사실상 없는 글이나 마찬가지다. 특히 빠른 색인이 중요한 상황에서 크롤러가 알아서 주기적으로 방문해주길 기다리는 건 비효율적이다.

IndexNow는 이 문제를 꽤 깔끔하게 해결해준다. URL 하나가 바뀌었다는 사실을 검색 엔진에 직접 "지금 봐라"고 알려주는 프로토콜이다. Bing, Yandex 등 IndexNow를 지원하는 엔진들은 이 ping을 받으면 대기 큐 없이 우선 크롤링을 시도한다.

서버 쪽 설정은 5/22에 이미 끝났고, 이번 작업은 그 서버 작업과 배포 스크립트를 연결하는 마지막 조각이었다.

작업 내용 — publish.sh에 단계 추가

publish.sh는 이미 여러 스텝이 순서대로 묶여 있는 배포 파이프라인이다. 대략 이런 구조 위에 ping 단계를 끝에 붙인 형태다.

# 기존 흐름 (단순화)
build_site
rsync_to_server
invalidate_cache

# 추가된 단계
ping_indexnow

ping 자체는 간단하다. 배포가 완료된 URL을 IndexNow 엔드포인트로 HTTP 요청 한 방 쏘는 것. 하지만 이게 publish.sh 안에 있어야 하는 이유는 명확하다 — 배포와 알림이 항상 같이 움직여야 하기 때문이다.

별도 스크립트로 빼거나 수동으로 돌리면 결국 까먹는다. 특히 배포 직후 다른 일로 넘어가면 ping을 빠뜨린 채 그냥 지나가게 된다. 배포 파이프라인 안에 묶어두는 게 제일 안전하다.

결국 세 번째를 선택한 건 "자동화는 흐름에 붙여야 효과가 있다"는 단순한 원칙 때문이다.

서버 작업과의 연결

5/22 서버 작업이 먼저였다는 점이 중요하다. IndexNow는 ping을 받기 전에 서버에 인증 키 파일이 올라가 있어야 한다. 검색 엔진이 /.well-known/ 경로나 루트에 있는 키 파일로 소유권을 확인하는 구조라서, 서버 준비 없이 ping만 날리면 아무 효과도 없다.

이번처럼 서버 준비 → 스크립트 반영 순서로 나눠서 진행한 건 맞는 방향이다. 반대로 가면 ping이 날아가도 검색 엔진이 소유권 검증에서 실패하고 조용히 무시한다.

회고

publish.sh 한 파일 수정이지만 배포 이후 색인 속도에 직접 영향을 주는 변경이다. 그리고 이런 종류의 작업 — "배포 후 해야 하는 것을 배포 과정에 포함시키는" — 은 쌓일수록 스크립트 한 번 실행으로 모든 게 끝나는 구조가 된다.

서버 작업과 스크립트 작업을 나눠서 커밋한 것도 나름 의도된 분리다. 인프라 변경과 배포 로직 변경은 롤백 범위가 다르기 때문에 한 커밋에 묶으면 나중에 골치 아파진다.

다음 배포 때 ping이 정상적으로 나가는 걸 확인하면 이 작업은 완전히 마무리된다.

🛒 이 글과 어울리는 추천 상품

• 기계식키보드 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.