봇도 빠른 페이지를 읽습니다: AI 크롤러 감사 후 우리가 우선순위를 재조정한 것들

지난 겨울, 한 클라이언트가 GPTBot이 자신들의 새로운 도움말 센터를 "볼" 수 있는지 물어보았기에 우리는 작은 감사를 실시했습니다. Search Console은 괜찮아 보였습니다. 홈페이지의 PageSpeed Insights도 괜찮아 보였습니다. 하지만 서버 로그(Server logs)는 다른 이야기를 하고 있었습니다. 롱테일 URL(long tail URLs)이 타임아웃되고 있었고, 카테고리 템플릿은 첫 번째 응답에서 JavaScript 셸(JavaScript shell)을 반환하고 있었으며, /robots.txt 규칙 중 하나는 마케팅 팀이 이미 AI Overviews를 위해 제안했던 경로를 차단하고 있었습니다.

이 목록 중 특이한 것은 없었습니다. 이는 모두가 북마크하는 세 개의 URL만 테스트하는 것을 멈추고, 봇이 실제로 무엇을 요청하는지 읽기 시작할 때 비로소 눈에 띄는 종류의 편차(drift)였습니다.

그 감사는 "ChatGPT를 위한 최적화"에 관한 그 어떤 슬라이드보다 우리의 모니터링 우선순위를 바꾸어 놓았습니다. 봇도 빠른 페이지를 읽습니다. 또한 느린 페이지는 포기하고, 비어 있는 HTML은 건너뛰며, robots.txt를 문자 그대로 준수합니다. 아래는 우리가 우선순위를 재조정한 것, 과장하기를 멈춘 것, 그리고 크롤링 가능성(crawlability)이 확보된 후 정기적인 PageSpeed 모니터링이 어디에 위치해야 하는지에 대한 내용입니다.

왜 서버 로그에서 GPTBot 및 기타 AI 크롤러 트래픽을 감사했는가

대규모 언어 모델(Large language models)과 AI 검색 제품은 파트너 인덱스(partner indexes)와 전용 크롤러를 통해 귀하의 콘텐츠에 도달합니다. OpenAI는 GPTBot을 공개하고 있으며, Google은 여전히 검색 및 관련 기능을 위해 Googlebot을 보냅니다. 다른 벤더들도 각자의 사용자 에이전트(user-agents)를 문서화합니다. 정확한 구성은 사이트와 산업에 따라 다릅니다.

우리는 Lighthouse 점수가 아닌 로그부터 시작했습니다:

2주 동안 알려진 AI 및 주요 검색 사용자 에이전트(user-agents)별로 요청을 필터링합니다.
가장 많이 요청된 경로와 첫 번째 바이트까지의 중간 시간(TTFB, median time to first byte)을 나열합니다.
200 이외의 응답, 5초 이상의 응답, 그리고 합리적인 크기 임계값 미만의 HTML 본문을 표시(flag)합니다.
해당 목록을 우리가 실제로 매주 모니터링하던 URL과 비교합니다.

그 중첩되는 부분은 부끄러울 정도로 적었습니다. 우리는 홈 페이지, 가격 페이지, 그리고 캠페인 랜딩 페이지 하나만을 모니터링하고 있었습니다. 하지만 봇들은 긴 형식의 가이드(long-form guides), 필터링된 카테고리 페이지, 그리고 몇 달 동안 PSI(PageSpeed Insights)에서 아무도 열어보지 않은 레거시 블로그 경로를 타격하고 있었습니다.

그 격차가 바로 감사(audit)의 핵심입니다. 우리의 사용 사례에서 AI 크롤러 성능(AI crawler performance)이란 "봇이 제시간에 완전한 응답을 가져올 수 있는가?"를 의미하며, "내일 Perplexity가 우리를 인용할 것인가?"를 의미하는 것이 아닙니다.

LLM 크롤러 크롤링 가능성(crawlability): 타임아웃, JavaScript 셸, 그리고 빈 HTML

크롤러는 렌더링 예산(rendering budgets)이 제한된 성급한 클라이언트처럼 행동합니다. 우리가 목격한 일반적인 실패 모드(failure modes)는 다음과 같습니다:

깊은 URL에서의 타임아웃(Timeouts on deep URLs): 인간은 내부 검색을 통해 도달하지만 봇은 직접 요청하는 페이지네이션(Pagination) 및 패싯형 카테고리 경로(faceted category routes). 캐시 키(cache keys)가 배가될 때 TTFB(Time to First Byte)가 급증했습니다.
클라이언트 렌더링 셸(Client-rendered shells): 로딩 스피너가 포함된 초기 HTML과 대규모 번들(bundle) 이후에 주입되는 본문 내용. 많은 크롤러는 해당 JavaScript를 실행하지 않고 셸(shell) 상태 그대로 저장합니다.
의도치 않은 차단(Accidental blocks): 스테이징(staging) 환경의 Disallow 설정이 운영 환경에 복사되었거나, 사이트맵(sitemap)에는 여전히 나열되어 있지만 경로는 차단된 경우.
소프트 404(Soft 404s): "상품을 이용할 수 없습니다"라는 문구와 함께 텍스트가 거의 없는 HTTP 200 응답. 맥락을 아는 인간에게는 괜찮지만, 구조를 파싱(parsing)하는 모든 것에는 무용지물입니다.

이것들은 우선적으로 크롤링 가능성(crawlability)의 문제입니다. 또한 이는 Core Web Vitals 작업에서도 나타납니다. 봇의 가져오기(fetch)에 실패하는 페이지는 느린 모바일 네트워크를 사용하는 실제 사용자에게도 (단지 더 긴 시간의 문제일 뿐) 실패할 가능성이 높습니다.

우리는 템플릿당 하나의 실험실 체크(lab check)를 추가했습니다: 단순한 HTTP 클라이언트로 URL을 가져오고, TTFB를 측정하며, Lighthouse 점수가 녹색(green)임을 신뢰하기 전에 첫 번째 HTML 청크(chunk)에 주요 콘텐츠가 나타나는지 확인하는 것입니다. 투박한 방식이지만, 우리가 해당 URL들에 대해 PSI를 전혀 실행하지 않았기 때문에 PSI만으로는 잡아내지 못했던 문제들을 포착할 수 있었습니다.

AI 크롤러 성능과 Core Web Vitals: 인용 순위가 아닌 가져오기 준비 상태

이 논의에서 Core Web Vitals는 여전히 중요하지만, 그 역할은 소셜 포스트에서 암시하는 것보다 더 좁습니다.

**LCP (Largest Contentful Paint)**는 fetch-only 크롤러가 텍스트와 헤딩(headings)을 캡처할 수 있을 만큼 메인 콘텐츠가 충분히 일찍 도착하는 것과 자주 상관관계가 있습니다.
**INP (Interaction to Next Paint)**는 단순 GET 요청에서는 부차적이지만, 메인 스레드(main thread)를 점유하는 페이지는 모든 사용자에게 지저분하고 느린 로딩을 유발하는 경향이 있습니다.
**CLS (Cumulative Layout Shift)**는 주로 인간의 오클릭(mis-taps)에 관한 것이지만, 안정적인 레이아웃은 DOM을 순서대로 탐색하는 파서(parsers)에게 여전히 도움이 됩니다.

우리는 고객들에게 LCP를 개선한다고 해서 LLM 인용률이 높아진다고 말하지 않습니다. Google의 AI Overviews documentation에는 페이지 속도가 인용 요소로 나열되어 있지 않습니다. 다만, 우리는 느리거나 깨진 fetch가 귀하의 콘텐츠가 풀(pool)에 진입할 기회 자체를 줄일 수 있다고 말합니다. Fetch readiness(가져오기 준비 상태)는 관련성(relevance), 권위(authority)

전체적인 기술적 기준점(robots 규칙, sitemaps, SSR vs 클라이언트 렌더링)에 대해서는 왜 AI 크롤러에게 빠르고 크롤링 가능한 페이지가 필요한가에 관한 Watcher 기사에서 더 자세히 다룹니다. 이 포스트는 우리가 로그를 분석한 후 진행한 모니터링의 변화에 관한 것입니다.

AI 크롤러를 위한 웹사이트 최적화: URL 리스트에서 변경한 사항

감사(audit) 전에는 우리의 기본 모니터링 패키지가 SEO 보고서를 반영했습니다: 홈 페이지, 주요 랜딩 페이지, 그리고 아마도 /blog 정도였습니다. 감사 이후에는 봇이 실제로 행동하는 방식에 따라 URL을 그룹화했습니다:

그룹	추가된 항목	이유
롱폼 콘텐츠 (Long-form content)	주요 도움말 문서, 비교 페이지, 용어 사전 항목	로그상에서 높은 봇 가져오기(fetch) 볼륨
...

또한 그룹별로 **모니터링 빈도(monitoring frequency)**를 나누었습니다. 홈 페이지는 매일, 롱테일 콘텐츠(long-tail content)는 주 2회, 검색이나 필터에 영향을 주는 배포(deploy)가 있을 때마다 패싯 경로(faceted routes)를 모니터링합니다. 이는 더 많은 실행을 의미하지만, 세 개의 녹색 점수(green scores)로 만들어진 분기별

감사(audit) 이후, 우리는 일회성 점검(ad-hoc checks)을 위해 PSI를 유지하고, 포트폴리오 기준점(baselines)은 저장된 이력과 예산 알림(budget alerts)이 포함된 정기 실행(scheduled runs)으로 이동했습니다. 이는 우리가 PageSpeed Insights vs automated monitoring에서 대행사들을 위해 문서화한 것과 동일한 구분 방식입니다. 즉, 단일 의사결정을 위해서는 수동(manual) 방식을, 회귀(regressions)가 달력 알림을 기다려서는 안 되는 상황에서는 자동화(automation) 방식을 사용하는 것입니다.

특히 AI 크롤링 가능성(crawlability)을 위해, LCP 및 INP 외에 두 가지 임계값(thresholds)을 추가했습니다:

봇 비중이 높은 URL에서의 TTFB (마케팅 페이지보다 엄격한 내부 대역).
클라이언트 사이드 렌더링(client-side rendering)을 사용하는 것으로 알려진 템플릿에 대한 간단한 "첫 번째 응답 내 콘텐츠 존재 여부" 확인.

두 임계값 모두 당신이 인용될 것임을 증명하지는 않습니다. 다만, 두 방식 모두 홈페이지에 대한 월간 PSI 점검보다 "봇이 유용한 정보를 전혀 얻지 못한 상황"을 더 일찍 포착해 냅니다.

온보딩(onboarding)에 추가된 AI 검색 기술적 SEO 점검 항목

AI 검색을 위한 기술적 SEO(Technical SEO)는 여전히 전통적인 크롤링 위생(crawl hygiene)과 겹치는 부분이 많습니다. 우리는 새로운 사이트들이 '홈페이지만 관리하는 습관'을 물려받지 않도록 명시적인 온보딩 단계를 추가했습니다:

robots.txt 검토: GPTBot 및 Googlebot 규칙이 경영진이 공개적이라고 생각하는 내용과 일치하는지 확인합니다. 의도적으로 차단하되, 실수로 차단하지 마십시오.
사이트맵(Sitemap) 교차 확인: 사이트맵의 모든 URL이 200 상태 코드를 반환하며 허용되지 않은(disallowed) 경로가 아닌지 확인합니다. 오래된 경로를 제거하십시오. 봇은 사이트맵을 따라 막다른 길로 들어갑니다.
렌더링 전략(Render strategy) 기록: 어떤 템플릿이 첫 번째 응답에서 의미 있는 HTML을 제공하는지, 반대로 어떤 템플릿이 클라이언트 번들(client bundles)에 의존하는지 문서화합니다. 위 첫 번째 그룹에 속하는 트래픽이 높은 템플릿에 대한 수정을 우선시하십시오.
선택 사항인 llms.txt: 일부 팀은 시스템이 선호하는 문서로 향할 수 있도록 llms.txt를 게시합니다. 대부분의 아키텍처에서 이는 선택 사항입니다. Lighthouse의 에이전틱 브라우징(Agentic Browsing) 카테고리에는 이를 게시할 경우 발견 가능성(discoverability) 확인이 포함됩니다 (위에 링크된 점수 산정 관련 게시물 참조).

이 단계들은 아무도 열어보지 않는 PDF가 아니라 프로젝트 위키(wiki)에 기록되어 있습니다. 도움말 문서의 TTFB(Time to First Byte)에 대한 모니터링 알람이 발생하면, 엔지니어는 해당 URL이 봇이 접근 가능해야 하는 것인지 아니면 의도적으로 제한된 것인지를 즉시 확인할 수 있습니다.

감사(Audit) 이후 우리가 더 이상 사용하지 않는 말들

다음 세 가지 문구는 고객 상담 시 더 이상 사용하지 않기로 했습니다.

"Core Web Vitals를 개선하면 ChatGPT가 당신을 인용할 것입니다." (과도한 주장; 데이터 가져오기(fetch)와 순위 및 인용을 혼동함.)
"홈페이지 점수가 90점 이상이므로 우리는 AI에 최적화되어 있습니다." (잘못된 URL 샘플; 잘못된 지표 해석.)
"안전을 위해 모든 AI 봇을 차단하세요." (라이선스 문제로 인해 때로는 유효할 수 있으나, 성능 전략은 아니며, 당신이 원할 수도 있는 검색 풀(retrieval pools)에서 스스로를 제외시키는 행위임.)

법률 및 SEO 검토를 통과하여 대체된 문구들은 다음과 같습니다.

"우리는 공개 콘텐츠를 가져올 수 있게 유지하며, 첫 응답 속도를 빠르게 하고, robots.txt 및 사이트맵(sitemaps)에 일관되게 등록합니다."
"우리는 홈페이지뿐만 아니라 봇이 실제로 요청하는 URL들을 모니터링합니다."
"인용 및 답변 품질은 콘텐츠와 권위(authority)의 문제이며, 우리는 성능 모니터링과 크롤링 체크를 통해 액세스 계층(access layer)을 관리합니다."

더 차분한 언어를 사용하게 되었습니다. 이를 통해 유사한 점수를 가졌음에도 경쟁사가 여전히 인용되는 상황이 발생하더라도, 실망하는 이해관계자(stakeholders)를 줄일 수 있었습니다.

다음 단계: 한 사이트에 대해 일주일간의 AI 크롤러 로그 감사 실행하기

지난 분기에 AI 검색 관련 이슈가 발생했던 사이트를 하나 선정하세요. 7일 동안 다음 과정을 수행합니다.

서버 로그(또는 CDN 로그)를 내보내고 GPTBot, Googlebot 및 호스트가 문서화한 기타 에이전트(agents)로 필터링합니다.
가장 많이 호출된 경로 10개와 해당 경로들의 TTFB 중앙값(median)을 나열합니다.
해당 목록을 현재 모니터링 일정에 포함된 URL들과 비교합니다.
이번 달에 확인하지 않은 트래픽이 높은 경로에 대해 PSI(PageSpeed Insights) 또는 예약된 테스트를 실행합니다.
TTFB가 가장 나쁜 URL을 간단한 HTTP 클라이언트로 호출하여 첫 번째 HTML 청크(chunk)에 실제 콘텐츠가 있는지 검사합니다.

만약 두 목록이 겹치지 않는다면, 새로운 스키마 마크업(schema markup)을 적용하기 전에 모니터링 항목을 업데이트하십시오. 봇은 빠른 페이지를 읽습니다. 또한, 당신이 전혀 테스트하지 않는 페이지는 건너뜁니다.

크롤링 규칙 (crawl rules), 사이트맵 (sitemaps), 그리고 CWV (Core Web Vitals) 대 인용 (citation)에 대한 솔직한 견해에 대해서는 Why AI crawlers need fast, crawlable pages를 읽어보십시오. 포트폴리오 전반에 걸쳐 수동 PSI (PageSpeed Insights) 측정이 더 이상 확장성을 갖지 못할 때는 PageSpeed Insights vs automated monitoring을 함께 참고하십시오.

접근성 (Access)이 우선입니다. 표현력 (Representation)은 그다음입니다. 모니터링은 모든 이가 표현력에 집중하는 동안, 접근성이 무너지지 않도록 유지하는 방법입니다.