"SEO는 끝났다"는 말이 유행처럼 번지고 있습니다. 그러나 검색 엔진이든 생성형 답변 엔진이든, 크롤링과 색인이라는 뿌리 단계는 생략할 수 없습니다. robots.txt와 sitemap.xml은 그 뿌리 단계의 인터페이스입니다.

---

왜 여전히 중요한가

1. 모든 AI 엔진은 크롤러를 통해 웹에 접근한다

OpenAI(GPTBot), Anthropic(ClaudeBot), Perplexity(PerplexityBot), Google(Google-Extended) — 주요 AI 엔진은 모두 독립된 크롤러를 운용합니다. 이들은 페이지를 방문하기 전에 반드시 robots.txt를 조회하고, 허용된 경로만 수집합니다.

robots.txt를 방치하면, AI에게 인용받길 바라면서 문을 잠가두는 것과 같습니다.

열려야 할 콘텐츠는 열고, 개인화·결제·관리자 경로는 확실히 닫는 크롤러 위생 관리가 필요합니다.

2. 크롤 예산은 유한하다 — sitemap이 우선순위를 결정한다

규모 있는 금융사 사이트는 수만 개의 URL을 보유합니다. 크롤러가 모든 URL을 방문하지는 않습니다. sitemap.xml은 "이 URL들부터 보라"는 우선순위 신호이자, 변경 빈도와 최종 수정 시점을 전달하는 채널입니다.

3. 구조화 데이터의 발견성은 크롤 접근에서 시작된다

Schema.org JSON-LD가 아무리 정교하게 마크업돼 있어도, 크롤러가 그 페이지에 도달하지 못하면 의미가 없습니다. 내부 링크 아키텍처가 완벽하지 않은 현실에서, sitemap은 깊은 페이지의 발견성을 보장하는 유일한 안전망입니다.

---

robots.txt — 2026년 체크리스트

권장 최소 구성

# AI + 검색 공통
User-agent: *
Allow: /
Disallow: /account/
Disallow: /admin/
Disallow: /api/
Disallow: /*?preview=

# AI 엔진 명시적 허용
User-agent: GPTBot
Allow: /
Disallow: /account/

User-agent: ClaudeBot
Allow: /
Disallow: /account/

User-agent: PerplexityBot
Allow: /

# sitemap 위치 명시
Sitemap: https://www.example.com/sitemap.xml

자주 발생하는 실수 4가지

  • `Disallow: /` 잔류 — 스테이징 설정이 운영 배포에 그대로 올라가는 사고. CI 파이프라인에 robots.txt 검사 단계를 추가해야 합니다.

  • AI 엔진별 블록 부재 — User-agent: * 규칙만 있으면 AI 크롤러가 의도치 않게 과도하게 막히거나 열립니다. 엔진별 명시가 필요합니다.

  • `Sitemap:` 디렉티브 누락 — robots.txt가 sitemap의 입구 역할을 해야 크롤러가 가장 빠르게 발견합니다.

  • 개인화 경로 누락 — /mypage, /order, /checkout 등이 크롤링되면 빈 페이지·리다이렉트가 반복 수집되어 크롤 신호가 오염됩니다.

---

sitemap.xml — 여전히 필수인 이유

기본 구조

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://www.example.com/</loc>
    <lastmod>2026-04-22</lastmod>
    <changefreq>weekly</changefreq>
    <priority>1.0</priority>
  </url>
  <url>
    <loc>https://www.example.com/insights/xxx</loc>
    <lastmod>2026-04-18</lastmod>
    <changefreq>monthly</changefreq>
    <priority>0.7</priority>
  </url>
</urlset>

금융사가 놓치기 쉬운 4가지

  • 동적 페이지 누락 — 상품 상세, 공시, 투자 용어집처럼 DB에서 생성되는 페이지는 빌드 타임 또는 런타임에 sitemap을 자동 생성해야 합니다. 수작업 유지보수는 반드시 실패합니다.

  • `lastmod` 허위 갱신 — 변경되지 않은 페이지까지 매일 lastmod를 업데이트하면 신호가 무의미해집니다. 실제 콘텐츠 변경 시점만 반영해야 크롤 예산이 필요한 곳에 집중됩니다.

  • 50,000 URL / 50MB 한도 초과 — 단일 sitemap 파일의 상한선입니다. 초과 시 sitemap index 파일로 분리해야 합니다.

  • non-canonical URL 포함 — ?utm=, ?ref= 등 파라미터 URL이 sitemap에 포함되면 중복 색인을 유발합니다. canonical URL만 포함하는 것이 원칙입니다.

---

SEO와 GEO는 층이 다른 레이어다

| 레이어 | 구성 요소 | 역할 | |---|---|---| | 크롤러 접근 | robots.txt · sitemap.xml | 누가, 어디까지 들어오는가 | | 구조 | HTML 시맨틱 · 접근성 | 페이지가 무엇인가 | | 의미 | Schema.org · llms.txt · 본문 품질 | 무엇을 주장하는가 | | 성과 | 인용 가능성 · 권위 · 인용 모니터링 | 얼마나 쓰이는가 |

GEO(Generative Engine Optimization)는 의미·성과 레이어를 공략합니다. 그러나 크롤러 접근 레이어가 흔들리면, 위 레이어의 최적화는 전부 무너집니다.

NCG가 고객 사이트 진단 시 가장 먼저 점검하는 것도 robots.txt와 sitemap.xml입니다. 기초 위에서만 GEO가 작동합니다.

---

당장 해야 할 3가지

  1. https://[내 사이트]/robots.txt를 열어 현 상태를 캡처하세요. 의도한 설정과 실제 파일이 일치하는지 확인합니다.

  2. sitemap.xml을 Google Search Console·Bing Webmaster에 재제출하세요. 마지막 제출이 6개월 이상 지났다면 최우선 과제입니다.

  3. 동적 페이지 자동 생성 로직을 현행화하고, `lastmod`가 실제 변경을 반영하도록 코드를 검토하세요.

기초를 다시 본다고 해서 구식이 되는 것이 아닙니다. AI 엔진이 급증한 지금, robots.txt와 sitemap.xml의 전략적 가치는 오히려 커졌습니다.