사이트를 완전히 AI 에이전트가 읽을 수 있게 만들었습니다. 실제 수치는 이렇습니다.
지난 몇 달 동안 built2winweb.com을 1인 개발자가 만들 수 있는 최대한 “에이전트가 읽을 수 있는” 사이트로 바꿨습니다. MCP 서버, A2A 에이전트 카드, NLWeb /ask 엔드포인트, ACP, UCP, agents.txt, llms.txt, RSL 라이선스, 모든 페이지의 Markdown 콘텐츠 협상, 그리고 CDN에 연결한 IndexNow까지. 그런 다음 자리에 앉아 실제로 측정했습니다. 이것은 솔직한 버전입니다 — 작동하지 않은 부분, 제 의도와 반대로 움직이던 두 가지 Cloudflare 기본값, 그리고 모든 프로토콜 배관을 합친 것보다 중요했던 숫자까지 포함해서요.
숫자로 보기
- 209,600 — IndexNow로 보낸 URL
- 1,319 — Bing이 실제로 색인한 페이지
- 28,685 — 사이트맵의 URL
- 16 — 참조 도메인 — 진짜 한계
실제로 만든 것
전체 목록은 agent-ready 페이지에 정리해 두었지만 요약하면: 도구 7개를 제공하는 /mcp의 MCP 서버, SEP-2127 서버 카드, AP2 머천트 확장이 포함된 A2A 에이전트 카드, ACP 디스크립터, UCP 커머스 프로필, 경로별 에이전트 권한, 사이트 전체에 BM25를 실행해 Schema.org 타입 응답을 돌려주는 /ask 엔드포인트, llms.txt와 llms-full.txt, AGENTS.md, Markdown 사이트맵, 그리고 robots.txt에서 참조되며 검색 색인·RAG·모델 학습을 명시적으로 허용하는 RSL 1.0 라이선스입니다.
모두 실제로 동작하고, 공개되어 있으며, API 키가 필요 없습니다. 프레임워크는 쓰지 않았습니다 — 공유 호스팅 위의 손으로 쓴 PHP입니다. 보고 싶다면 그냥 호출해 보세요.
결과: 숫자
여기서는 성공 사례보다 솔직함이 더 쓸모 있습니다. 약 3개월 동안:
- IndexNow에 209,600개 URL 제출
- Bing 색인 1,319페이지
- 사이트맵 28,685개 URL
- Bing 검색에서 노출 111회, 클릭 0회
- 참조 도메인 16개
Seznam도 다른 각도에서 같은 이야기를 합니다. 3,390개 URL 발견, 크롤러 DB에 86개 보관, 19개 색인. 발견한 것의 0.6%입니다.
정리하면: 페이지당 평균 일곱 번쯤 검색엔진에 알렸고, 사이트의 약 4.5%가 색인됐습니다. 통지는 애초에 병목이 아니었습니다.
Cloudflare Crawler Hints가 18시간마다 4,900개 URL을 보내고 있었다
Bing Webmaster Tools를 열어보지 않았다면 절대 못 찾았을 부분입니다. 209,600건의 IndexNow 제출은 전부, 켜 놓고 잊어버린 Cloudflare Crawler Hints에서 나온 것이었습니다. 28,685개 URL 사이트에서 18시간마다 4,900개 URL을 밀어내고 있었죠 — 일부러 noindex로 표시한 페이지와, 404를 반환하는 .well-known 검증 파일까지 포함해서요.
Bing은 알고 있었습니다. 대시보드 최상단 권장사항에는 이렇게 적혀 있었습니다: “서버 부하 증가와 색인 지연을 방지하려면 IndexNow 배치 모드를 피하세요.” 스위치 하나를 끄지 않은 탓에 유용한 프로토콜을 자초한 문제로 바꿔 놓은 셈입니다. IndexNow는 변경된 콘텐츠를 위한 것입니다. 사이트 전체를 반복해서 쏘는 것은 키가 후순위로 밀리는 전형적인 방법입니다.
내 CDN이 내 robots.txt와 정반대를 말하고 있었다
두 번째 놀라움은 더 나빴습니다. 제가 하려던 일과 정면으로 충돌했으니까요. 제 robots.txt는 약 200줄에 걸쳐 AI 크롤러 — GPTBot, ClaudeBot, PerplexityBot, CCBot 등 — 를 명시적으로 환영하고 Content-Signal: search=yes, ai-input=yes, ai-train=yes를 선언합니다.
그런데 그 위에, Cloudflare가 정반대를 말하는 관리 블록을 삽입하고 있었습니다:
# BEGIN Cloudflare Managed content
User-agent: ClaudeBot
Disallow: /
User-agent: GPTBot
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: Google-Extended
Disallow: /
# END Cloudflare Managed Content제가 yes라고 쓴 자리에 ai-train=no도 선언되어 있었습니다. RFC 9309에서는 중복된 user-agent 그룹이 병합되고 동점일 때 Allow: /가 이기므로, 예의 바른 크롤러는 아마 계속 가져갔을 겁니다. 그러나 저는 쓴 적도 없는 지시문을 무효화하기 위해 동점 규칙에 기대고 있었던 셈입니다. 디스크의 원본이 아니라 실제로 서빙되는 robots.txt를 확인하세요. CDN이 편집하고 있을 수 있습니다.
발견과 인용은 서로 다른 문제다
원하지 않았지만 데이터가 강요하는 결론입니다. 제가 구현한 모든 프로토콜은 발견을 해결합니다 — 기계가 존재하는 것을 찾고 해석하도록 돕는 일이죠. 어느 것도 권위는 해결하지 못합니다 — 누군가가 인용할 이유를 만드는 일 말입니다.
참조 도메인이 16개인 상태에서 Bing은 제 사이트 대부분을 색인하지 않기로 결정했고, 아무리 알려도 그 결정은 바뀌지 않습니다. Bing은 두 번째 권장사항에서 직접 말했습니다: “귀하의 사이트는 고품질 도메인의 인바운드 링크가 충분하지 않습니다.” 검색엔진 두 곳, 크롤 오류 0, 가이드라인 위반 0, 그런데도 거의 색인되지 않았습니다. 이건 기술적 실패가 아니라, 그 콘텐츠를 저장할 가치가 있는지에 대한 판단입니다.
이 작업을 SEO 수단으로 고려하고 있다면, 하지 마세요. 그런 게 아닙니다.
그 아래 숨어 있던 버그
감사를 하다가 어떤 프로토콜 세부사항보다 부끄럽고 파장이 큰 문제를 발견했습니다. 제 글 URL 13개가 엉뚱한 글을 보여주고 있었습니다.
리라이트 규칙이 여러 슬러그를 위치 기반 앵커 — blog-card-1, blog-card-3 — 로 연결해 두었는데, 이는 특정 글이 아니라 블로그 목록의 “자리”를 가리키는 것이었습니다. 목록 순서를 바꾸자 슬러그가 조용히 내용과 분리됐습니다. Shopify 이전에 관한 URL이 크리티컬 CSS 글을 보여주고 있었고, 그중 하나는 사이트맵에도 들어 있었습니다.
반면 설명적으로 이름 붙인 앵커는 전부 여전히 정확했습니다. 하나도 어긋나지 않았죠. 교훈은 시시하지만 보편적입니다: 사물은 위치가 아니라 정체로 이름 짓는다. 그리고 제목이 약속한 것을 지키지 않는 페이지로 가득한 색인은 클릭률 0%를 아주 잘 설명합니다.
제가 권하는 순서
사이트를 에이전트가 읽을 수 있게 만들고 싶다면, 실제로 중요한 순서는 이렇습니다:
- 먼저 고장 난 것을 고치세요. 잘못 연결된 라우트, 도시 슬러그의 아포스트로피로 생긴 오래된 404 2,020건, 페이지를 흰 바탕에 흰 글씨로 렌더링하던 CSS 규칙을 찾았습니다. 빠진 매니페스트보다 이쪽이 훨씬 비쌉니다.
llms.txt와/ask형태의 엔드포인트를 공개하세요. 저렴하고 실제로 유용하며, 어시스턴트가 추측 대신 출처 있는 답을 얻게 해줍니다.- CDN이 당신 이름으로 무엇을 하는지 확인하세요. 제 가장 큰 문제 두 가지는 제가 고른 적 없는 기본값이었습니다.
- 그다음에 링크를 얻으세요. 느린 단계이고, 나머지 전부를 결정하는 단계입니다.
그래서 할 만했나?
네 — 다만 처음 시작한 이유 때문은 아닙니다. 얻은 것은 트래픽이 아니라 정확성입니다. 맞춤 사이트 비용을 묻는 질문에 어시스턴트가 마케팅 문구를 바꿔 말하는 대신 출처가 붙은 타입화된 답을 가져올 수 있게 됐습니다. 제 오리진에서는 아무것도 생성하지 않으므로 가격에 대한 환각도 없습니다. 그 자체로 가치가 있고, 앞으로 사람들이 무언가를 찾는 방식에 대한 합리적인 베팅이기도 합니다.
하지만 지름길은 아닙니다. 인용할 가치가 있다는 사실을 대신해 줄 매니페스트는 없습니다. 그래프가 우상향하는 버전을 파는 것보다, 이렇게 분명히 말하는 편이 낫다고 생각합니다.
이런 방식의 사이트를 원한다면
저는 제가 만드는 모든 사이트를 PHP로 직접 씁니다 — WordPress도, 페이지 빌더도, 월 사용료도 없습니다. 위의 에이전트 인터페이스도 같은 종류의 작업입니다. 사람도 기계도 읽을 수 있는 빠른 사이트를 원한다면 무료 견적을 요청하고 필요한 것을 알려주세요.
함께 읽기
자주 묻는 질문
MCP, A2A, llms.txt를 추가해서 검색 순위가 올랐나요?
아니요. 3개월 동안 28,685개 URL 중 1,319페이지가 색인됐지만 Bing에서 노출 111회, 클릭 0회였습니다. 이 프로토콜들이 해결하는 것은 발견 — 기계가 콘텐츠를 찾고 해석하도록 돕는 일입니다. 권위는 만들어 주지 않으며, 검색엔진이 색인할지 말지를 결정하는 것은 권위 쪽입니다.
Cloudflare Crawler Hints란 무엇이고 꺼야 하나요?
변경된 URL을 대신 IndexNow에 자동 제출하는 기능입니다. 제 사이트에서는 209,600개 URL, 18시간마다 약 4,900개를 보냈고 noindex 페이지와 404까지 포함됐습니다. Bing은 이를 과도하다고 표시했습니다. 사이트가 크거나 템플릿으로 생성된다면, 켜 둔 채로 두기 전에 실제로 무엇을 보내는지 확인하세요.
CDN이 왜 내 robots.txt를 바꾸나요?
Cloudflare는 AI 크롤러를 차단하는 관리 블록을 삽입할 수 있고, 그것이 당신의 규칙보다 위에 나타납니다. 제 경우 파일에서는 명시적으로 환영하던 GPTBot, ClaudeBot, CCBot, Google-Extended를 차단하고 있었고, ai-train=yes에 맞서 ai-train=no를 선언하고 있었습니다. 항상 디스크의 원본이 아니라 실제 URL에서 서빙되는 파일을 읽으세요.
IndexNow는 설정할 가치가 있나요?
실제로 변경된 콘텐츠라면 그렇습니다. 키 파일 하나와 POST 요청 하나면 되고 Bing, Yandex, Naver, Seznam이 사용합니다. Google은 사용하지 않습니다. 다만 변경되지 않은 사이트를 대량으로 재제출하지 마세요. 그것이 키를 후순위로 밀리게 하는 행동입니다.
작은 사이트는 무엇부터 해야 하나요?
고장 난 것을 고치고, llms.txt와 질문에 답하는 엔드포인트를 공개하고, CDN의 기본 동작을 점검한 뒤, 남은 노력은 전부 링크를 얻는 데 쓰세요. 기술 작업은 주말이면 끝납니다. 링크는 몇 년이 걸립니다.
기계가 정말로 읽을 수 있는 사이트를 원하시나요?
구조화 데이터, 스키마, 에이전트 엔드포인트를 기본 탑재한 빠른 PHP 사이트를 직접 손으로 만듭니다. 일회성 비용, 구독 없음, 코드는 당신 것입니다.
무료 견적 받기