서효다발견 실측

잘 만들었는데 아무도 모른다면,
대개 만든 쪽에 이유가 있습니다.

이 사이트를 하루 동안 실제로 재고 고친 기록입니다. 찾은 결함 중 절반은 사이트가 아니라 제 계측기에 있었습니다 — 숫자가 커 보이는 방향으로만 틀려 있었습니다. 남의 사례가 아니라 제 것이라, 수치는 전부 그날 잰 값입니다.

01 출발

AI 는 오는데 검색은 안 옵니다

서버 로그를 요청 단위로 세면 이렇게 나옵니다.

9,346Bytespider
5,340Amazonbot
5,107GPTBot
4,146ClaudeBot
1,628PerplexityBot
1,151Googlebot
489bingbot
204Yeti (네이버)

AI 크롤러는 대량으로 오고, 검색 크롤러는 그 20분의 1 수준입니다. 이 도메인은 그 시점에 Bing 색인에서 0건이었습니다. 많이 읽히는데 검색으로는 안 찾아지는 상태입니다 — 어느 쪽이 얼마나 중요한지는 제가 단정할 수 없고, 여기 적는 것은 그날 잰 두 숫자뿐입니다.

02 계기

그 표부터 두 배 부풀려져 있었습니다

처음 센 방식은 grep -o 였습니다. 요청이 아니라 이름이 나타난 횟수를 셉니다. GPTBot 의 UA 를 보면 이유가 보입니다.

Mozilla/5.0 … compatible; GPTBot/1.4; +https://openai.com/gptbot)

한 줄에 두 번 있으니 요청 5,107건이 10,210건으로 찍힙니다. 절대값보다 나쁜 것은 배수가 봇마다 다르다는 점입니다 — GPTBot·ClaudeBot 은 2.0배, bingbot 은 2.2배인데 Googlebot 과 Yeti 는 UA 에 이름이 한 번이라 1.0배입니다. AI 봇만 부풀고 검색 봇은 그대로라, 「AI 는 오는데 검색은 안 온다」는 격차 자체가 과장돼 있었습니다.

그리고 요청 기준 1위인 Bytespider 는 애초에 집계 목록에 없어서 한 번도 보이지 않았습니다. 세는 목록에 없으면 없는 것이 됩니다.

03 자기 발자국

내 확인 요청을 남의 관심으로 세고 있었습니다

경로별 요청 수를 뽑았더니 /llms.txt 가 610건이었습니다. 「AI 가 이 파일을 열심히 읽는다」로 읽힙니다. 요청자를 갈라보니:

542배포 뒤 내가 «올라갔나» 확인한 요청
6GPTBot

자기 발자국을 남의 관심으로 읽는 것 — 아무 일도 안 일어났는데 「잘 되고 있다」고 말하게 됩니다. 가장 나쁜 종류의 오측입니다.

고친 방식은 단순합니다. 우리 도구가 자기 이름을 대게 했습니다. hyoda-kr-verify-live, hyoda-kr-healthcheck 처럼 UA 에 도구 이름을 박으니, 로그에서 «누가 몇 번» 이 정확히 갈립니다. 가를 수 없는 것은 가를 수 없다고 적는 칸을 따로 뒀습니다 — 모르는 것을 발견 쪽에 넣지 않으려고.

04 표면

영문 페이지가 한글 메타데이터를 달고 있었습니다

「Seo Hyoda」로 찾는 사람을 위해 만든 영문 페이지인데, 머리에 붙은 것이 전부 한글이었습니다.

langko — 영문 페이지가 스스로를 한국어라고 선언
oglocale ko_KR — 공유 카드가 한국어로 표시
본문한글 329자 — 수치·출처·푸터가 그대로

「19년 9개월」·「8만 줄 → 2만 줄」·「위시켓 인증」이 영문 표 안에 있었습니다. 숫자가 있어도 값이 전달되지 않습니다 — 영어권 독자는 「8만」을 읽지 못합니다.

고치면서 배운 것: 검사를 세운 범위가 세 번 연속 좁았습니다. JSON-LD 만 봐서 og:locale 을 놓쳤고, 메타만 봐서 본문을 놓쳤고, HTML 만 봐서 기계용 텍스트 파일을 놓쳤습니다. 마지막이 제일 나쁩니다 — 그 파일이 바로 AI 가 읽으라고 만든 것이니까요.

05 자해

발견을 늘리려다 「없음」을 색인 후보로 만들었습니다

없는 주소에 기본 404(162바이트) 대신 안내 페이지를 주도록 서버를 고쳤습니다. 그런데 그 문서를 직접 열면 200 이었습니다.

/404.html → 200 · 16,108B

「그 주소에는 아무것도 없습니다」라고 적힌 페이지가 정상 페이지로 색인될 수 있는 상태였습니다. 지시자 하나(internal)를 빠뜨린 결과입니다.

검사가 없어서 못 잡은 게 아니라 404 를 아예 안 보고 있었습니다. 지금은 «없는 주소가 404 인가» 와 «404 문서가 직접 열리지 않는가» 를 따로 봅니다. 둘은 다른 질문입니다.

06 배관

내 것들이 서로를 안 가리키고 있었습니다

제3자가 걸어주는 링크는 통제할 수 없습니다. 그런데 내가 가진 자산끼리 걸어주는 링크는 통제할 수 있는데 비어 있었습니다.

소유 자산 8곳 중 허브를 가리키는 것 1곳
10곳 중 5곳 · 그중 한 사이트는 54페이지 전부

도메인 단위로만 세다가 놓친 것이 있었습니다. 어떤 사이트는 「0곳」으로 세어졌는데, 실제로는 글 30편이 이미 저자 링크로 가리키고 있었습니다 — 홈페이지만 봤기 때문입니다. 페이지 단위로 세니 54개 중 31개였고, 비어 있던 것은 홈을 포함한 나머지 23개였습니다.

도메인 단위 집계는 큰 사이트의 절반쯤 맞은 상태를 0 이나 1 로 뭉갭니다. 두 층위를 다 봐야 어디가 비었는지 보입니다.

07 남은 것

통보는 색인이 아닙니다

IndexNow 로 14개 주소를 알렸고 응답을 받았습니다. 2분 뒤 bingbot 이 소유 확인용 키 파일을 가져갔습니다.

그리고 21초 뒤에 실제로 페이지를 가져갔습니다 — 이 기록들 중 3편입니다. 통보 → 소유 확인 → 수집까지는 일어납니다. 그다음이 색인인지는 아직 모릅니다 — 가져간 것과 실린 것은 다릅니다.

그래서 「보냈다」로 끝내지 않고 보낸 시점의 기준선을 같이 적어뒀습니다 — 며칠 뒤 무엇과 비교할지 지금 정해두지 않으면, 그때 가서 「좋아진 것 같다」로 끝납니다.

제3자 인바운드 링크는 여전히 0건입니다. 그건 만드는 쪽에서 해결되지 않습니다 — 위의 여섯 가지는 내 쪽에서 막고 있던 것이었고, 그것부터 치우는 것이 순서였습니다.

08 요지

고친 것보다 잘못 잰 것이 많았습니다

하루치 기록에서 반복해 나온 것은 결함 자체가 아니라 계측이 스스로를 속이는 방식이었습니다. 요청 대신 출현을 세고, 내 확인 요청을 관심으로 세고, 「검사를 세웠다」를 「그 자리를 다 봤다」로 읽었습니다. 셋 다 숫자가 커 보이는 방향으로만 틀렸습니다.

같은 자리에서 막혀 계시다면 순서는 이렇습니다 — 먼저 무엇을 세고 있는지 확인하고, 그다음 자기 발자국을 걷어내고, 그다음에야 늘릴 방법을 봅니다. 순서를 바꾸면 늘어난 것처럼 보이는 숫자만 남습니다.

이 문제 한 장으로 /lp/discovery 수치와 출처 /proof
사람이 읽는 것지금방법증거할 수 있는 것과 없는 것
깊이 보는 것숙박 운영을 시스템으로기록이 남는 곳발견되지 않는 이유띄우는 데서 막히는 자리지식이 흩어지는 자리없어도 돌아가게 만드는 자리AI가 실제 일에 붙는 자리기대던 것이 사라졌을 때
이런 게 막혀 있다면했던 걸 또 하고 있습니다제가 없으면 안 돌아갑니다다 만들었는데 띄우지를 못합니다잘 만들었는데 아무도 모릅니다AI를 배웠는데 정작 일에는 안 씁니다
다른 언어Seo Hyoda
AI·검색이 읽는 곳기계가 읽는 것

이 지도는 실제로 배포된 페이지에서 생성됩니다. 손으로 든 목록이 아닙니다.