robots.txt 하나 고치다가, AI 크롤러한테만 문 열어둔 걸 발견했습니다
안녕하세요. 비개발자로 AI 자동화를 하고 있는 벨라입니다.
이번 과제(robots.txt·sitemap.xml 등록 / 리치 스니펫 / EEAT / llms.txt)를
제가 운영하는 사이트 3개에 하루 동안 실제로 적용해 봤습니다.
결과부터 말씀드리면, 등록보다 "확인"에서 배운 게 훨씬 많았습니다.
설정을 넣는 건 30분이면 끝나는데, 그게 진짜 작동하는지 보는 데서 사고가 3개 나왔거든요.
그중 하나는 저희가 AEO 하겠다고 넣은 설정이
정작 AI 크롤러한테만 구멍을 내고 있었던 겁니다.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. 대상 사이트 3개
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- kndli.com : 메인 사이트 (한국어/영어/간체/번체 4개 언어, 219페이지)
- nest.kndli.com : 운영 기록 아카이브 (아티클 214건)
- 워드프레스 블로그 : 새로 만든 채널
같은 과제를 세 곳에 적용하니 차이가 선명하게 보였습니다.
"이미 있는 곳", "아예 없는 곳", "플랫폼이 대신 해주는 곳"이 하나씩이었거든요.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
2. [과제] robots.txt · sitemap.xml 등록
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
■ 사고 1. 아카이브 사이트에 sitemap이 아예 없었습니다
아티클 214건을 쌓아둔 사이트인데 sitemap.xml도 robots.txt도 404였습니다.
메타태그, canonical, hreflang은 다 잘 돼 있었는데 그 둘만 없었어요.
검색엔진이 찾아올 통로 자체가 없던 겁니다.
글은 2년치 쌓였는데 아무도 못 들어오는 상태였습니다.
Next.js라 sitemap.ts / robots.ts 파일을 만들어 자동 생성되게 했고,
빌드하니 228개 URL(고정 페이지 14 + 아티클 214)이 나왔습니다.
여기서 하나 챙긴 게 있는데, lastModified(수정일)를 전부 "오늘"로 넣지 않았습니다.
아티클마다 실제 발행일을 넣었어요.
전 페이지를 같은 날짜로 채우면 "가짜 신선도"가 되는데,
그건 검색엔진 입장에서 신뢰를 깎는 신호입니다.
■ 사고 2. AI 크롤러한테만 차단이 풀려 있었습니다 ← 이게 제일 놀랐습니다
메인 사이트 robots.txt는 이렇게 돼 있었습니다.
User-agent: *
Allow: /
Disallow: /ds/ ← 디자인 조각 파일, 색인되면 안 되는 것
User-agent: GPTBot
Allow: /
User-agent: ClaudeBot
Allow: /
... (AI 크롤러 15종을 하나씩)
AI 답변에 노출되고 싶어서 AI 크롤러를 일부러 하나하나 허용해 둔 겁니다.
좋은 의도였죠.
그런데 robots.txt 사양 문서에 이런 문장이 있습니다.
"특정 크롤러에 하나의 그룹만 유효합니다. 다른 그룹은 무시됩니다."
즉 GPTBot은 자기 그룹(Allow: / 만 있는)만 보고,
위에 있는 * 그룹의 Disallow는 아예 안 봅니다.
실제로 파서로 돌려봤더니 이렇게 나왔습니다.
Googlebot /ds/ → 차단 (의도대로)
GPTBot /ds/ → 허용 ← 구멍
ClaudeBot /ds/ → 허용 ← 구멍
PerplexityBot /ds/ → 허용 ← 구멍
Google-Extended /ds/ → 허용 ← 구멍
Yeti(네이버) /ds/ → 허용 ← 구멍
구글한테는 막아둔 파일을 ChatGPT·Claude·Perplexity·네이버한테는 열어두고 있었습니다.
AEO 하려고 넣은 설정이 정확히 AEO 쪽에 구멍을 냈습니다.
고치는 법은 간단했습니다. User-agent 줄을 연달아 써서 한 그룹으로 묶는 겁니다.
User-agent: GPTBot
User-agent: ClaudeBot
User-agent: PerplexityBot
... (15종)
Allow: /
Disallow: /ds/ ← 이제 다 같이 적용됨
문서에 이렇게 적혀 있더라고요.
"여러 크롤러의 규칙을 하나의 그룹으로 통합하면
그룹의 모든 규칙이 나열된 모든 사용자 에이전트에 적용됩니다."
■ 여기서 제가 한 번 틀렸습니다 (이게 더 중요한 교훈일지도)
수리하고 파이썬 기본 robots 파서로 검증했는데,
수리 전이랑 후가 똑같이 나왔습니다. 심지어 Googlebot도 "허용"이라고요.
"어? 원래 문제가 없었나?" 하고 넘어갈 뻔했습니다.
원인은 그 파서가 구글 규칙을 구현하지 않아서였습니다.
구글은 "경로 길이가 긴 규칙이 이긴다"인데,
그 파서는 그걸 안 해서 Allow: / 가 전부 이겨버린 거죠.
구글 규칙을 따르는 파서로 바꾸니 그제서야 진짜 그림이 나왔습니다.
도구가 "문제 없음"이라고 말할 때, 도구 자체를 의심해야 하는 순간이 있습니다.
이게 오늘 제일 크게 배운 겁니다.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
3. [과제] 리치 스니펫 (구조화된 데이터)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
구글이 지원하는 구조화 데이터 유형이 25종이더라고요.
기사, 탐색경로, 캐러셀, 과정, 이벤트, 채용정보, 레시피, 영화, 상품, Q&A, 리뷰...
처음엔 "다 넣으면 좋은 거 아닌가" 했는데, 문서를 읽고 생각이 바뀌었습니다.
"정보가 정확하더라도 사용자에게 표 시되지 않는 정보에 관한
구조화된 데이터를 추가하지 마세요."
화면에 없는 걸 마크업하면 가이드라인 위반입니다.
그래서 25종을 하나씩 "우리 화면에 이게 실제로 있나?"로 판정했습니다.
결과:
- 이미 쓰는 것 5종 (기사 / 탐색경로 / 캐러셀 / 조직 / FAQ)
- 넣을 수 있는데 안 한 것 5종 (상품 / 과정 / 이벤트 / 동영상 / 이미지)
- 조건이 안 되는 것 2종 (소프트웨어앱 / 리뷰)
- 우리와 무관 13종 (레시피 / 영화 / 채용정보 / 숙박 등)
여기서 재밌는 걸 하나 발견했는데,
뉴스레터 웹판에 FAQ가 화면에는 분명히 있는데 마크업만 빠져 있었습니다.
"화면에 없는 걸 마크업하면 안 된다"의 정반대 상황이라, 이건 그냥 채우면 되는 점수였어요.
그리고 "소프트웨어앱"은 포기했습니다.
필수 속성에 평점이나 리뷰가 들어가는데,
자기 사이트에서 자기가 관리하는 후기로는 별표가 안 나온다고 문서에 적혀 있더라고요.
없는 평점을 지어낼 순 없으니 안 하는 게 맞습니다.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
4. [과제] EEAT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
E-E-A-T를 네 개 다 채워야 하는 줄 알았는데, 문서에 이렇게 적혀 있었습니다.
"E-E-A-T라는 덕목 중에서도 가장 중요한 것은 신뢰성입니다.
나머지 덕목들은 신뢰성에 기여하지만
콘텐츠에서 이 모든 덕목을 갖추고 있어야 할 필요는 없습니다."
신뢰성 하나에 집중하면 된다는 뜻이었습니다.
저희한테 신뢰성은 결국 세 가지더라고요.
출처를 밝히는 것, 실제로 잰 수치를 쓰는 것, 그리고 실패를 안 지우는 것.
그래서 이 글에도 제가 파서 때문에 틀렸던 얘기를 그대로 남겼습니다.
성공만 적힌 글보다 이런 게 더 믿을 만하다고 생각해서요.
관련해서 이 문장도 인상적이었습니다.
"AI 생성 등의 자동화를 사용하여 검색 순위를 조작하는 것을 주목적으로
콘텐츠를 생성하는 행동은 스팸 정책 위반입니다."
기준이 "AI를 썼느냐"가 아니라 "주목적이 순위 조작이냐"입니다.
AI로 쓰는 게 문제가 아니라, 사람한테 쓸모없는 걸 양산하는 게 문제인 거죠.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
5. [과제] llms.txt ← 여기서 제일 크게 뒤집혔습니다
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
llms.txt를 넣으면 AI가 우리 사이트를 더 잘 이해한다고 알고 있었고,
저희도 이미 llms.txt와 llms-full.txt를 만들어 두고 있었습니다.
그런데 구글 공식 문서를 읽다가 이런 취지의 내용을 봤습니다.
구글 검색은 llms.txt를 사용하지 않는다.
그리고 이 문장도요.
"AI 개요 또는 AI 모드에 표시되기 위한 추가적인 요구사항은 없으며,
다른 특별한 최적화가 필요하지도 않습니다."
"AI 개요 또는 AI 모드에서 참조 링크로 표시되려면
페이지의 색인이 생성되어 있고 검색 기술 요구사항을 충족하여
스니펫과 함께 Google 검색에 표시될 수 있어야 합니다."
정리하면 이렇습니다.
구글 AI 답변에 나오는 조건은 딱 두 개입니다. 색인될 것, 스니펫으로 보일 수 있을 것.
그 외에 따로 할 건 없다는 겁니다.
llms.txt는 지웠냐고요? 안 지웠습니 다.
다른 AI 시스템은 참고할 수도 있으니까요.
다만 "구글 노출을 위해 llms.txt를 넣었다"는 말은 이제 안 합니다. 근거가 없으니까요.
이번 과제에서 제일 값진 게 이거였습니다.
"해야 할 것"보다 "안 해도 되는 것"을 알게 된 것.
하루 동안 확인한 "안 해도 되는 일"이 꽤 됩니다.
- 크롤링 예산 최적화 → 1만 페이지 미만 사이트는 볼 필요 없다고 문서에 명시
- 추천 스니펫 확보 → 마크업으로 지정 자체가 불가능
- 사이트링크 → 자동 생성이라 지정 불가
- crawl-delay → 구글은 처리하지 않음
- 자체 후기 별표 → 자기가 관리하는 리뷰는 별표 안 나옴
이거 다 하려고 했으면 며칠 날렸을 겁니다.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
6. 등록하고 나서 본 진짜 데이터
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
설정을 다 넣고 Search Console에 sitemap을 제출했습니다.
아카이브 사이트 : 228개 발견 (성공)
워드프레스 : 7개 + 뉴스 사이트맵 1개 (성공)
그리고 색인 보고서를 열었더니 404가 10건 잡혀 있었습니다.
자체 점검 도구로는 절대 못 잡는 항목이었어요.
저희 도구는 sitemap에 있는 219개만 검사하는데,
이 10개는 sitemap에 없는 옛날 주소였거든요. 구글만 알고 있던 겁니다.
원인을 나눠 보니:
- 2건은 예전에 일부러 없앤 페이지 → 404가 정답, 그대로 둠
- 7건은 앱이 호출하는 /api/ 주소 → 페이지가 아니라 API, robots.txt로 차단
여기서도 하나 배웠는데, 404가 나쁜 게 아니었습니다.
문서에 "4xx 상태 코드는 크롤링 예산을 낭비하지 않는다"고 적혀 있더라고요.
없는 페이지에 404를 주는 건 정상 동작입니다.
그리고 /api/ 차단을 넣을 때, 아까 배운 걸 바로 써먹었습니다.
* 그룹에만 넣으면 AI 크롤러들은 계속 두드릴 테니, AI 크롤러 그룹에도 같이 넣었습니다.
아침에 그 함정을 안 봤으면 또 반쪽만 고쳤을 겁니다.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
7. 빙(Bing)도 등록했습니다 — ChatGPT 때문에
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
빙을 왜 하냐면, ChatGPT의 웹 검색이 빙 인덱스를 쓰기 때문입니다.
구글 SEO와는 별개의 축이에요.
빙 웹마스터 도구에 좋은 기능이 있었습니다.
"Google Search Console에서 가져오기"입니다.
인증 파일도 메타태그도 필요 없이,
구글 계정 연결 한 번으로 사이트 3개 + 사이트맵 4개가 통째로 넘어왔습니다.
"Google Search Console 계정에서 3개의 사이트를 가져왔습니다"
구글을 먼저 해두면 빙이 공짜로 따라오는 구조라,
순서를 이렇게 잡는 걸 추천드립니다.
추가로 IndexNow도 붙였습니다.
검색엔진이 찾아올 때까지 기다리지 않고 "여기 바뀌었다"고 먼저 알리는 방식인데,
219개 URL을 한 번에 밀어넣었고 HTTP 200이 떨어졌습니다.
빙과 네이버가 참여사입니다. (구글은 참여 안 하니 구글은 sitemap으로)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
8. 네이버 블로그는 안 됐습니다 (알아두시면 좋을 것)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
네이버 블로그도 등록하려다가 두 가지를 확인했습니다.
첫째, Search Console 등록 이 구조적으로 불가능합니다.
소유권 확인을 하려면 <head>에 메타태그를 넣거나 루트에 파일을 올려야 하는데
네이버 블로그는 둘 다 못 합니다.
둘째, 이게 더 중요한데 blog.naver.com/robots.txt에 이런 주석이 있습니다.
# AI 학습 및 검색증강생성(RAG) 목적의 봇 접근을 엄격히 금지함
그리고 GPTBot, ClaudeBot, PerplexityBot, Google-Extended가 전부 Disallow입니다.
즉 네이버 블로그에 쓴 글은 ChatGPT나 Claude가 인용할 수 없습니다.
Googlebot은 허용이라 일반 검색에는 나오지만, AI 답변에는 못 들어갑니다.
그래서 채널 역할을 이렇게 나눴습니다.
네이버 블로그 → 네이버 검색 유입용 (AI 인용은 포기)
워드프레스·자체 사이트 → 구글 + AI 인용용
그리고 순서를 지키기로 했습니다.
자체 사이트에 먼저 발행하고, 네이버에는 요약 + 원문 링크를 올리는 식으로요.
구글 문서에 "원본 콘텐츠 시스템은 인용한 콘텐츠보다 원본을 위에 표시한다"고 돼 있어서,
반대로 하면 우리가 베낀 쪽으로 보일 수 있거든요.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
9. 정리하면
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
하루 해보고 남은 건 이 세 가지입니다.
1) 설정을 넣는 것보다 "진짜 그렇게 작동하는지" 확인하는 게 훨씬 어렵고 중요합니다.
저는 검증 도구가 잘못돼서 한 번 속았습니다.
2) 통설로 아는 것과 공식 문서에 적힌 것이 다를 수 있습니다.
llms.txt가 그랬고, 크롤링 예산이 그랬고, 추천 스니펫이 그랬습니다.
"해야 할 것" 목록보다 "안 해도 되는 것" 목록이 시간을 더 아껴줬습니다.
3) 등록은 색인을 보장하지 않습니다.
문서에도 "요구사항을 준수하더라도 크롤링·색인·게재를 보장하지 않는다"고 적혀 있고,
"크롤링은 며칠에서 몇 주까지 걸릴 수 있다"고 합니다.
그래서 오늘 제출해 두는 게 중요합니다. 시계가 그때부터 도니까요.
아직 못 한 것도 많습니다.
이미지 사이트맵, 동영상 구조화 데이터, 상품 마크업, 그리고 정보성 페이지 늘리기까지요.
2주쯤 뒤에 Search Console 실적을 보고 뭐가 실제로 달라졌는지 다시 정리해 보겠습니다.
비개발자도 충분히 할 수 있는 작업들이었고,
어려운 건 기술이 아니라 "내가 넣은 게 진짜 작동하나"를 확인하는 습관이었습니다.
읽어주셔서 감사합니다.
1. 새로 만든 robots.txt — AI 크롤러 14종을 한 그룹으로 묶은 모습
이름과 전화번호 목록이 적힌 흰색 페이지
2. 자동 생성된 sitemap.xml — 아티클 214건 포함 228 URL
항목 목록을 보여주는 웹페이지 스크린샷
3. Search Console 색인 보고서 — 404 10건이 잡힌 화면
한국어로 된 Google Analytics 대시보드 스크린샷
4. Search Console sitemap 제출 성공 — 228개 발견
한국어가 포함된 Google 검색 페이지의 스크린샷
5. 빙 웹마스터 "Google Search Console에서 가져오기" 화면
한국어 텍스트가 포함된 웹페이지의 스크린샷
6. 가져오기 성공 — 3개 사이트가 한 번에 등록된 결과
7. 빙 대시보드 — 3사이트 등록 완료, IndexNow 메뉴 확인
한국사이트 스크린샷
