잘 만들었는데 아무도 모른다면,
대개 만든 쪽에 이유가 있습니다.
이 사이트를 하루 동안 실제로 재고 고친 기록입니다. 찾은 결함 중 절반은 사이트가 아니라 제 계측기에 있었습니다 — 숫자가 커 보이는 방향으로만 틀려 있었습니다. 남의 사례가 아니라 제 것이라, 수치는 전부 그날 잰 값입니다.
AI 는 오는데 검색은 안 옵니다
서버 로그를 요청 단위로 세면 이렇게 나옵니다.
AI 크롤러는 대량으로 오고, 검색 크롤러는 그 20분의 1 수준입니다. 이 도메인은 그 시점에 Bing 색인에서 0건이었습니다. 많이 읽히는데 검색으로는 안 찾아지는 상태입니다 — 어느 쪽이 얼마나 중요한지는 제가 단정할 수 없고, 여기 적는 것은 그날 잰 두 숫자뿐입니다.
그 표부터 두 배 부풀려져 있었습니다
처음 센 방식은 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 는 애초에 집계 목록에 없어서 한 번도 보이지 않았습니다. 세는 목록에 없으면 없는 것이 됩니다.
내 확인 요청을 남의 관심으로 세고 있었습니다
경로별 요청 수를 뽑았더니 /llms.txt 가 610건이었습니다.
「AI 가 이 파일을 열심히 읽는다」로 읽힙니다. 요청자를 갈라보니:
자기 발자국을 남의 관심으로 읽는 것 — 아무 일도 안 일어났는데 「잘 되고 있다」고 말하게 됩니다. 가장 나쁜 종류의 오측입니다.
고친 방식은 단순합니다. 우리 도구가 자기 이름을 대게 했습니다.
hyoda-kr-verify-live, hyoda-kr-healthcheck 처럼
UA 에 도구 이름을 박으니, 로그에서 «누가 몇 번» 이 정확히 갈립니다.
가를 수 없는 것은 가를 수 없다고 적는 칸을 따로 뒀습니다 —
모르는 것을 발견 쪽에 넣지 않으려고.
영문 페이지가 한글 메타데이터를 달고 있었습니다
「Seo Hyoda」로 찾는 사람을 위해 만든 영문 페이지인데, 머리에 붙은 것이 전부 한글이었습니다.
「19년 9개월」·「8만 줄 → 2만 줄」·「위시켓 인증」이 영문 표 안에 있었습니다. 숫자가 있어도 값이 전달되지 않습니다 — 영어권 독자는 「8만」을 읽지 못합니다.
고치면서 배운 것: 검사를 세운 범위가 세 번 연속 좁았습니다.
JSON-LD 만 봐서 og:locale 을 놓쳤고, 메타만 봐서 본문을 놓쳤고,
HTML 만 봐서 기계용 텍스트 파일을 놓쳤습니다.
마지막이 제일 나쁩니다 — 그 파일이 바로 AI 가 읽으라고 만든 것이니까요.
발견을 늘리려다 「없음」을 색인 후보로 만들었습니다
없는 주소에 기본 404(162바이트) 대신 안내 페이지를 주도록 서버를 고쳤습니다. 그런데 그 문서를 직접 열면 200 이었습니다.
/404.html → 200 · 16,108B
「그 주소에는 아무것도 없습니다」라고 적힌 페이지가
정상 페이지로 색인될 수 있는 상태였습니다.
지시자 하나(internal)를 빠뜨린 결과입니다.
검사가 없어서 못 잡은 게 아니라 404 를 아예 안 보고 있었습니다. 지금은 «없는 주소가 404 인가» 와 «404 문서가 직접 열리지 않는가» 를 따로 봅니다. 둘은 다른 질문입니다.
내 것들이 서로를 안 가리키고 있었습니다
제3자가 걸어주는 링크는 통제할 수 없습니다. 그런데 내가 가진 자산끼리 걸어주는 링크는 통제할 수 있는데 비어 있었습니다.
도메인 단위로만 세다가 놓친 것이 있었습니다. 어떤 사이트는 「0곳」으로 세어졌는데, 실제로는 글 30편이 이미 저자 링크로 가리키고 있었습니다 — 홈페이지만 봤기 때문입니다. 페이지 단위로 세니 54개 중 31개였고, 비어 있던 것은 홈을 포함한 나머지 23개였습니다.
도메인 단위 집계는 큰 사이트의 절반쯤 맞은 상태를 0 이나 1 로 뭉갭니다. 두 층위를 다 봐야 어디가 비었는지 보입니다.
통보는 색인이 아닙니다
IndexNow 로 14개 주소를 알렸고 응답을 받았습니다. 2분 뒤 bingbot 이 소유 확인용 키 파일을 가져갔습니다.
그리고 21초 뒤에 실제로 페이지를 가져갔습니다 — 이 기록들 중 3편입니다. 통보 → 소유 확인 → 수집까지는 일어납니다. 그다음이 색인인지는 아직 모릅니다 — 가져간 것과 실린 것은 다릅니다.
그래서 「보냈다」로 끝내지 않고 보낸 시점의 기준선을 같이 적어뒀습니다 — 며칠 뒤 무엇과 비교할지 지금 정해두지 않으면, 그때 가서 「좋아진 것 같다」로 끝납니다.
제3자 인바운드 링크는 여전히 0건입니다. 그건 만드는 쪽에서 해결되지 않습니다 — 위의 여섯 가지는 내 쪽에서 막고 있던 것이었고, 그것부터 치우는 것이 순서였습니다.
고친 것보다 잘못 잰 것이 많았습니다
하루치 기록에서 반복해 나온 것은 결함 자체가 아니라 계측이 스스로를 속이는 방식이었습니다. 요청 대신 출현을 세고, 내 확인 요청을 관심으로 세고, 「검사를 세웠다」를 「그 자리를 다 봤다」로 읽었습니다. 셋 다 숫자가 커 보이는 방향으로만 틀렸습니다.
같은 자리에서 막혀 계시다면 순서는 이렇습니다 — 먼저 무엇을 세고 있는지 확인하고, 그다음 자기 발자국을 걷어내고, 그다음에야 늘릴 방법을 봅니다. 순서를 바꾸면 늘어난 것처럼 보이는 숫자만 남습니다.