며칠 전 이런 글을 썼습니다. AI가 귀사를 추천하지 않는 이유는 세 가지 층위에 있을 수 있습니다. AI가 귀사를 모르거나, 검색하지 못하거나, 검색했지만 선택하지 않은 것입니다.
오늘은 두 번째 층위의 구체적인 확인 방법을, 그중에서도 유일하게 확실한 증거를 확보할 수 있는 층위를 다룹니다. 서버 로그에서 AI 크롤러가 실제로 방문했는지 확인하는 것입니다.
이 작업의 가치는 이렇습니다. ‘AI가 우리를 어떻게 보는가’에 관한 앞선 모든 판단은 간접적인 추측일 뿐이고, 서버 로그만이 직접적인 증거입니다. 누가 왔는지, 몇 번 왔는지, 어떤 페이지를 수집했는지, 자체적으로 차단한 것은 없는지가 모두 기록으로 남아 있습니다.
저희는 어제 이 방법으로 자사 사이트를 점검해 두 가지 문제를 발견했습니다. 그중 하나는 모든 검색엔진과 AI 크롤러에 영향을 주는 설정 오류였고, 이미 상당 기간 아무도 모르게 존재하고 있었습니다. 아래에서 확인 방법과 이 두 가지 함정을 함께 설명하겠습니다.
1단계: 각 크롤러의 수집량 집계
운영 담당자나 웹사이트 제작사에 웹사이트 접속 로그(보통 서버에 있으며 파일명이 웹사이트 도메인.log 형태)를 요청한 다음, 크롤러 식별자별로 건수를 집계하면 됩니다.
자주 보이는 크롤러 식별자:
- 검색엔진:
Baiduspider(바이두),Googlebot,bingbot,Sogou(서우거우),YisouSpider(선마),360Spider - AI / 대규모 언어모델 관련:
Bytespider(바이트댄스 계열),GPTBot및OAI-SearchBot(OpenAI),ClaudeBot,PetalBot(화웨이)
두 가지를 중점적으로 보십시오. 어느 것이 완전히 0인지, 그리고 각 크롤러 간의 수량 격차입니다. 특정 크롤러가 장기간 0이라면, 그 플랫폼은 귀사를 전혀 수집하지 않고 있다는 뜻입니다. 그렇다면 그 플랫폼에서는 어떤 콘텐츠 최적화를 해도 헛수고입니다.
헷갈리기 쉬운 부분을 짚어드립니다: 집계 전에 먼저 로그의 시간 범위를 확인하십시오. 저희도 처음에 특정 크롤러가 수십 건뿐인 것을 보고 수집량이 매우 낮다고 판단했지만, 나중에 그 로그가 겨우 세 시간 분량이라는 것을 알게 되었습니다. 환산하면 실제로는 하루 수백 회로 완전히 정상이었습니다. 절대 수치로 결론을 내리기 전에 먼저 시간으로 나누십시오.
2단계: 크롤러가 받은 상태 코드 확인
이 단계는 ‘자체적으로 차단한 것이 있는지’를 확인하는 작업입니다. 각 크롤러의 요청을 상태 코드별로 그룹화하십시오:
| 상태 코드 | 의미 | 주의 필요 여부 |
|---|---|---|
| 200 / 304 | 정상적으로 수집됨 | 정상이며 대부분을 차지해야 함 |
| 301 / 302 | 리다이렉트 | 소량은 정상, 대량 발생 시 링크 구조에 문제가 있는지 확인 필요 |
| 404 | 페이지 없음 | 소량은 정상, 대량이면 잘못된 주소로 귀사를 찾고 있다는 뜻 |
| 403 / 444 / 429 | 거부됨, 속도 제한 | 경고: 크롤러를 차단한 상태이므로 즉시 보안 규칙 확인 |
| 5xx | 서버 오류 | 크롤러가 방문한 시점에 사이트가 정상이 아니었으므로 평가에 영향 |
귀사가 많은 기업처럼 방화벽, CDN 또는 보안 플러그인을 설치했다면 이 단계는 반드시 확인해야 합니다. 이런 보호 기능은 접속 빈도가 높은 크롤러를 스캐너로 오인하기 쉽기 때문입니다. 저희도 검색엔진 크롤러를 차단할 뻔했는데, 차단 규칙을 적용하기 전에 ‘탐지만 하고 차단하지 않는’ 방식으로 한 차례 운영해 본 덕분에 발견할 수 있었습니다.
3단계: ‘수집해야 할 페이지’를 수집하고 있는지 확인
이 단계는 가장 자주 건너뛰지만 매우 유용합니다. 특정 크롤러가 수집한 주소를 나열해 어디에 집중하는지 살펴보십시오.
저희 사이트를 점검했을 때 발견한 것은, 특정 AI 크롤러가 주로 이미지, 오래된 글, 주변부 페이지를 수집했고, 최근에 집중적으로 최적화한 ‘회사 소개’ 페이지는 한 번도 건드리지 않았다는 점입니다.
이것은 한 가지를 의미합니다. 크롤러가 들어올 수 있다는 것과 귀사가 보여주고 싶은 것을 보았다는 것은 다릅니다. 중요한 페이지를 최적화한 직후인데 크롤러가 그 페이지를 수집한 적이 없다면, 그 최적화는 아직 AI 쪽에서 반영되지 않은 것입니다. 사이트맵과 능동적 제출을 통해 유도해야 합니다.
저희가 발견한 첫 번째 함정: robots 파일의 사이트맵이 전부 깨져 있었습니다
앞 단계에서 이어서 ‘왜 핵심 페이지가 수집되지 않았는가’를 추적하다 robots.txt를 확인했습니다. 이 파일은 모든 크롤러가 사이트에 들어와 가장 먼저 읽는 파일로, 사이트맵이 어디에 있는지 알려줍니다.
그런데 그 안에 나열된 사이트맵 주소 6개가 모두 무효였습니다. 각각 리다이렉트되었고, 리다이렉트 후 반환된 것은 웹사이트 첫 페이지의 HTML이었으며 사이트맵이 아니었습니다.
더 심각한 것은 실제로 유효한 사이트맵은 아예 기재되지 않았다는 점입니다.
이것은 곧 방문하는 모든 크롤러, 즉 검색엔진과 AI의 크롤러가 robots 파일을 읽고 6개의 무효 주소만 받은 뒤 아무것도 얻지 못한다는 뜻입니다. 크롤러는 스스로 링크를 따라 층층이 페이지를 찾아야 하므로 효율이 크게 떨어지고, 신규 콘텐츠나 내부 링크가 없는 페이지를 놓치기 쉽습니다.
이 문제는 이미 상당 기간 존재했습니다. 경고도 없었고, 사이트 접속도 완전히 정상이었고, 관리자 화면도 모두 정상이었습니다. 직접 확인해야만 발견할 수 있습니다.
자가 점검 방법은 매우 간단하며 1분이면 됩니다: 브라우저에서 귀사 도메인/robots.txt를 열고, 그 안의 각 Sitemap: 뒤 주소를 하나씩 열어보십시오. 올바른 결과는 XML 코드가 표시되는 것입니다. 웹페이지가 열린다면 그 항목은 잘못된 것입니다.
두 번째 함정: 크롤러가 오래전에 사라진 주소로 귀사를 찾고 있습니다
또한 특정 검색엔진 크롤러가 다량의 404를 발생시키는 것을 발견했고, 그 주소들을 분류해 보니 규칙성이 보였습니다. 그것들은 현재 사이트에 전혀 속하지 않는 주소 구조(옛날 형식의 카테고리 및 상품 페이지)였습니다.
이런 경우 보통 몇 가지 원인이 있습니다. 사이트가 예전에 개편되었거나 프로그램을 교체한 경우, 도메인을 이전에 다른 사람이 사용한 경우, 또는 어딘가에 옛 주소로 향하는 링크가 남아 있는 경우입니다.
영향: 크롤러의 일일 수집 할당량은 한정되어 있습니다. 존재하지 않는 주소에 할당량을 써버리면 실제 콘텐츠에 돌아갈 몫이 줄어듭니다. 대처 방법: 양이 많다면 웹마스터 플랫폼에 죽은 링크를 제출하거나, 이런 주소를 규범에 맞게 처리해 계속 헛돌지 않도록 하세요.
마지막 단계: 크롤러를 직접 “초대”하고, 그냥 기다리지 마세요
점검 후 특정 AI나 검색엔진의 수집량이 낮다는 것을 발견했다면, 위의 문제들을 수정하는 것 외에도 직접 제출할 수 있습니다.
- 주요 검색엔진은 모두 웹마스터 플랫폼을 제공하며, 사이트맵 제출, 새 링크 푸시, 수집 빈도와 색인량 확인이 가능합니다.
- AI 노출을 노린다면 대규모 언어모델 기업 자체의 검색 플랫폼을 빠뜨리지 마세요. 많은 AI 어시스턴트는 인터넷에 연결될 때 자사 체계의 검색 기능을 사용합니다. 그 체계에서 제출하고 수집되는 것이 다른 곳에서 애쓰는 것보다 훨씬 직접적입니다.
- 이런 플랫폼은 대부분 QR코드 로그인을 지원하며, 사이트 인증은 보통 파일 하나를 올리거나 코드 한 줄을 추가하는 방식이므로 기술 담당자에게 한 번만 협조를 요청하면 이후 오래 사용할 수 있습니다.
순서상 권장 사항: 먼저 robots와 사이트맵을 올바르게 수정한 후 제출하세요. 그렇지 않으면 크롤러를 초대해도 그 “목록”을 여전히 받지 못합니다.
10분 자가 점검 체크리스트
| 무엇을 점검 | 어떻게 점검 | 정상 상태 |
|---|---|---|
| 사이트맵이 올바르게 등록되었는지 | 도메인/robots.txt를 열고 Sitemap 주소를 하나씩 클릭 |
열면 XML 코드가 나오며, 웹페이지가 아님 |
| 어떤 크롤러가 방문했는지 | 운영 담당자에게 크롤러 식별자별로 로그 건수를 집계하도록 요청 | 주요 검색엔진과 AI 크롤러 모두 기록이 있어야 하며, 장기간 0인 항목이 있어서는 안 됨 |
| 자체적으로 차단되고 있는지 | 크롤러별로 상태 코드 집계 | 주로 200이며, 403/429가 나타나면 즉시 보호 규칙 확인 |
| 핵심 페이지를 수집하고 있는지 | 특정 크롤러가 수집한 주소를 나열 | 회사 소개, 주요 서비스 등 핵심 페이지가 포함되어야 함 |
| 404가 많은지 | 크롤러 요청 중 404의 비율과 주소 패턴을 집계 | 비율이 낮아야 함; 규칙성을 띤 대량의 404는 처리 필요 |
자주 묻는 질문 몇 가지
Q: 서버 권한이 없는데 어떻게 점검하나요?
A: 웹사이트 제작사나 운영 담당자에게 최근 접속 로그를 요청하면 됩니다. 아주 일반적인 요청입니다. 상대방이 제공할 수 없다면, 차선책으로 각 웹마스터 플랫폼의 수집 통계로도 대략적인 상황을 볼 수 있습니다. 다만 로그만큼 완전하지는 않습니다.
Q: 크롤러가 많이 수집하는 게 좋은 일인가요? 사이트가 느려지지 않나요?
A: 정상 범위 내라면 좋은 일이며, 활발하게 수집하고 있다는 뜻입니다. 실제로 부담이 된다면 올바른 방법은 방화벽으로 차단하는 것이 아니라 웹마스터 플랫폼에서 수집 빈도를 조정하는 것입니다. 차단하면 수집을 스스로 끊는 셈입니다.
Q: robots 파일의 주소가 잘못되었는데 직접 수정할 수 있나요?
A: 웹사이트 루트 디렉터리에 있는 텍스트 파일일 뿐이므로 기술 담당자에게 수정을 요청하면 됩니다. 몇 분이면 끝나는 일입니다. 수정 후에는 다시 열어 한 번 확인하는 것을 잊지 마세요. 많은 문제가 “수정했지만 검증하지 않아서” 발생합니다.
Q: 얼마나 자주 점검해야 하나요?
A: 월 1회를 권장하며, 그 외에 테마/플러그인을 교체하거나, 서버를 이전하거나, 보호 규칙을 변경한 후에는 반드시 점검해야 합니다. 이러한 작업은 모르는 사이에 크롤러의 접근 결과를 바꾸기 가장 쉽습니다.
AI와 검색엔진의 크롤러가 정말로 당신의 웹사이트를 정상적으로 수집하고 있는지 알고 싶으신가요?
Siwenlide는 베이징 및 인근 지역 중소기업을 위해 공식 웹사이트와 SEO/GEO 콘텐츠 고객 유치 운영을 제공합니다. 서버 로그에서 각 크롤러의 수집량, 상태 코드, 수집 경로를 확인하고, robots, 사이트맵, 보호 기능의 잘못된 차단처럼 “알림은 없지만 계속 새고 있는” 문제를 해결한 뒤, 각 웹마스터 플랫폼에서 제출과 모니터링을 진행하고 매월 대조 보고서를 제공합니다. 본문에 나온 이 두 가지 함정은 바로 이 프로세스에 따라 저희 사이트에서 직접 점검해 찾아낸 것입니다. siwenlide.com을 방문하거나(또는 저희 회사 소개를 먼저 확인하거나) 400-686-2011로 전화해 이야기해 보세요.
