Cloudflare가 ChatGPT의 새로운 페이지 발견을 돕는 방법: 크롤러가 내 사이트를 건너뛰지 않도록 수정할 5가지 사항

Cloudflare와 OpenAI의 검색 파일럿 결과 및 AI 검색 트렌드 분석

10월 15일, Cloudflare와 OpenAI는 지난 7월에 시작한 연구 파일럿의 초기 결과를 공유했습니다. Cloudflare가 자체 네트워크에서 신호(signals)를 OpenAI의 검색 크롤러로 전달했고, Cloudflare's write-up에 따르면 이 과정이 ChatGPT 검색을 위해 "수억 개의 새로운 웹 페이지"를 발견하고 색인화하는 데 도움을 주었습니다. 이 파일럿은 Cloudflare 네트워크의 약 1%만을 대상으로 했습니다.

같은 날, Google은 AI Mode 및 AI Overviews 변경 사항을 발표했습니다. 응답 상단에 더 많은 인라인 링크가 표시되며, 특정 작업 완료를 위해 "웹상의 공식적인 장소" 한두 곳을 보여주는 섹션 테스트가 진행되고 있습니다.

이 두 가지 정보를 종합해 볼 때 개발자들에게 전달되는 메시지는 매우 명확합니다. AI 검색은 페이지를 찾는 능력은 향상되고 있지만, 방문할 가치가 있는 페이지에 대해서는 점점 더 까다로워지고 있다는 것입니다. Cloudflare 게시물에서 흥미로운 부분은 헤드라인의 숫자가 아닙니다. 대부분이 우리가 직접 배포하는 버그들 때문에 크롤러가 시간을 낭비하게 만드는 요소들의 목록입니다.

이번 주말에 제가 제 사이트에서 확인해 볼 사항들과, 그중 대부분을 자동화할 수 있는 간단한 Node 스크립트를 소개합니다.

파일럿이 실제로 말하는 것 (그리고 그렇지 않은 것)

정확할 필요가 있습니다. "Cloudflare가 이제 귀하의 사이트를 ChatGPT에 공급한다"는 것이 사실은 아닙니다.

Cloudflare는 OpenAI 크롤러가 페이지를 찾는 데 도움이 되는 **신호(signals)**를 제공합니다. 이후 OpenAI가 해당 페이지들을 "독립적으로 평가하고 순위화"합니다.
해당 게시물에 따르면, 이 연구는 모델 훈련을 위해 페이지 콘텐츠를 공유하는 것이 아니라, 검색 및 발견을 위한 웹 메타데이터를 사용한다고 합니다.
"페이지에 대한 신호가 접근 권한을 부여하지 않습니다." 여전히 귀하의 robots.txt와 Cloudflare 설정이 접근을 결정합니다.
파일럿은 약 1% 규모의 코호트였습니다. 이에 참여할 수 있는 옵트인(opt-in) 설정은 없으며, 게시물에서도 이를 설명하고 있지 않습니다.

따라서 토글할 것은 없습니다. 통제할 수 있는 것은 크롤러가 나타났을 때 사이트가 깨끗한 신호를 보내는지 여부입니다.

1. 어떤 OpenAI 봇이 무엇을 하는지 파악하기

OpenAI는 세 가지 주요 에이전트(agents)를 문서화하고 있으며, 이들은 독립적입니다:

OAI-SearchBot: ChatGPT의 검색 기능에서 사이트를 노출합니다. 이를 차단하면 OpenAI에 따르면 해당 사이트는 여전히 탐색 링크(navigational link)로 나타날 수 있지만, ChatGPT 검색 답변에는 표시되지 않습니다.
GPTBot: OpenAI의 파운데이션 모델(foundation model) 훈련에 사용될 수 있는 콘텐츠를 크롤링합니다. 이를 차단하는 것이 훈련 제외(training opt-out)입니다.
ChatGPT-User: 사용자가 ChatGPT에 무언가를 요청할 때 페이지를 가져옵니다. OpenAI는 사람이 요청을 시작했기 때문에 robots.txt 규칙이 "적용되지 않을 수 있다"고 언급하며, 이는 검색에서 무엇이 나타날지 결정하는 데 사용되는 것이 아니라고 합니다.

많은 사이트가 2024년에 단일 규칙으로 "모든 AI"를 차단했고 다시는 확인하지 않았습니다. ChatGPT 검색에 나타나고 싶지만 훈련에서는 제외하고 싶다면, 분리는 다음과 같습니다:

User-agent: OAI-SearchBot
Allow: /
Disallow: /dashboard
...

OpenAI는 변경 사항이 검색에 반영되는 데 약 24시간이 걸릴 수 있다고 말합니다. Cloudflare를 사용한다면, AI Crawl Control (모든 플랜에서 이용 가능)을 통해 실제로 어떤 AI 크롤러가 사이트에 접근했는지, 그리고 그들이 robots.txt를 따르는지 확인할 수 있습니다. 이는 파일에 명시된 내용보다 더 정확한 진실의 원천입니다.

2. 누락된 페이지가 실제 404를 반환하도록 설정하기

이것은 Cloudflare 게시물에서 가장 직접적으로 언급하는 내용입니다. 그들은 "봇들이 존재하지 않는 파일을 반복적으로 요청한다", "일부 사이트는 거의 모든 주소를 홈페이지로 리디렉션(redirect)한다", 그리고 다른 주소들은 "동일한 콘텐츠의 사본으로 연결된다"는 것을 발견했습니다. 이러한 패턴을 인식하면 크롤링 요청 자체를 완전히 건너뛸 수 있게 됩니다.

사이트가 /anything-at-all에 200 상태 코드를 반환하고 홈페이지나 /로 302를 반환하는 경우, 모든 크롤러는 페이지가 존재하지 않다는 것을 파악하기 위해 가져와 비교해야 합니다. Google의 문서는 2xx 상태 코드로 제공되는 오류 페이지를 soft 404라고 부릅니다. 또한 Google은 4xx URL이 시간이 지남에 따라 인덱스에서 제외되며, "새로 발견된 404 페이지는 처리되지 않는다"고 언급합니다. 이는 쓰레기(junk) URL에 정확히 필요한 방식입니다.

일반적인 원인은 SPA (Single Page Application) 폴백 리라이트(fallback rewrite)인데, 이 경우 모든 경로가 200 상태 코드를 가진 index.html을 제공하기 때문입니다. Next.js App Router 프로젝트에서 동적 라우트에 대한 해결책은 데이터가 존재하지 않을 때 notFound()를 호출하는 것입니다. 이렇게 하면 404 상태 코드를 가진 not-found 페이지가 렌더링됩니다:

// app/blog/[slug]/page.tsx
import { notFound } from "next/navigation";
import { getPost } from "@/lib/posts";
...

페이지가 영구적으로 사라진 경우, 410도 괜찮습니다. Google은 429를 제외한 모든 4xx 코드를 동일하게 취급합니다.

3. URL 변형을 하나로 통합하세요

"동일한 콘텐츠의 복사본(Copies of the same content)"이라는 것은 일반적으로 같은 페이지가 여러 주소에 존재한다는 것을 의미합니다: http와 https, www와 베어 도메인, 트레일링 슬래시 유무, 추적 매개변수 포함 여부 등입니다. 하나의 버전을 선택하고 나머지 모든 것을 해당 버전으로 영구 리디렉션(301 또는 308)하세요. Google은 301을 강력한 신호로, 302를 약한 신호로 취급하므로, 영구적인 이동에 대한 임시 리디렉션은 조용한 실수입니다.

그런 다음 <link rel="canonical">, 사이트맵 URL, 내부 링크 모두가 이 동일한 버전을 사용하도록 하세요. Google의 사이트맵 문서는 절대 URL 형태로 오직 정규(canonical) URL만 나열할 것을 권장합니다.

4. 진실된 변경 신호를 보내세요

Cloudflare에 따르면 다음 단계에서는 "더 빠르고 더 신뢰할 수 있는 변경 신호"를 테스트할 것이라고 합니다. 그 이유는 "변경되지 않은 페이지를 반복적으로 다운로드하는 크롤러는 어떤 이점도 없이 부하만 추가하기 때문입니다." 이미 두 가지의 신호가 존재하며, 아마도 그 중 하나가 부분적으로 작동하고 있을 것입니다.

사이트 최적화 및 보안 점검 체크리스트

Sitemap의 lastmod 활용. 구글은 lastmod를 "일관되고 검증 가능할 때만" 사용한다고 밝히며, 이는 저작권 연도가 아닌 마지막 중요한 업데이트(콘텐츠, 구조화된 데이터 또는 링크)를 반영해야 한다고 설명합니다. 흔한 오류는 모든 URL에 빌드 시간을 찍는 생성기입니다. 시간이 지나면 크롤러들은 귀하의 lastmod가 아무 의미가 없다는 것을 학습하게 됩니다.

ETag / Last-Modified와 304. 크롤러가 If-None-Match 또는 If-Modified-Since를 보내고 페이지에 변경 사항이 없을 경우, 304 Not Modified는 양측 모두에게 전체 다운로드를 절약해 줍니다. 구글 문서는 304가 파이프라인에 콘텐츠가 지난번과 동일함을 알려준다고 설명합니다. 많은 프레임워크 및 CDN 설정은 이러한 헤더를 제거하거나 항상 200을 반환하므로, 가정하기보다는 테스트할 가치가 있습니다.

5. 손상된 페이지 찾기

제가 예상하지 못했던 부분: Cloudflare와 OpenAI는 잠재적으로 유해한 페이지를 개별적으로 플래그 지정하는 신호를 테스트하고 있습니다. 그들의 예시는 "기존에 합법적인 사이트에 공격자가 심은 가짜 로그인 양식"입니다. 단지 해당 페이지만 플래그 지정함으로써, "사이트 소유자에게 불이익을 주지 않으면서" 사람들을 안전하게 지킬 수 있습니다.

이는 좋은 소식이지만, 여전히 먼저 해당 페이지를 찾는 것이 좋습니다. 제가 확인할 몇 가지 사항:

귀하가 생성하지 않은 페이지, 특히 업로드 폴더나 오래된 CMS 경로 아래에 있는 경우.
action이 소유하지 않은 도메인으로 POST하는 양식.
더 이상 사용하지 않는 서비스로 여전히 연결된 오래된 서브도메인 (쉬운 장악 대상).
페이지의 양식이 제출할 수 있는 위치를 제한하는 form-action 규칙을 가진 Content-Security-Policy와 같은 누락된 보안 헤더.

1~4번 점검을 위한 5분 스크립트

이 Node 스크립트(Node 18+, 의존성 없음)는 OAI-SearchBot 및 GPTBot에 대한 robots.txt 규칙, 임의 URL이 실제 404를 반환하는지 여부, 호스트 변형이 영구적으로 리디렉션되는지 여부, 사이트맵에 믿을 만한 lastmod 값이 있는지 여부, 그리고 페이지가 조건부 요청에 대해 304로 응답하는지를 확인합니다.

// crawl-check.mjs: node crawl-check.mjs https://example.com으로 실행
// Node 18 이상 필요 (내장 fetch 사용). 의존성 없음.
const origin = new URL(process.argv[2] ?? "https://example.com").origin;
...

node crawl-check.mjs https://your-site.com으로 실행해 보세요. 이 스크립트는 리디렉션을 고의로 따르지 않기 때문에, 크롤러가 첫 번째 단계에서 무엇을 보는지 정확히 알 수 있습니다. sitemap이 인덱스라면, 자식 sitemap 중 하나를 지정하여 검사하는 것도 좋습니다.

제가 잘 관리되는 몇몇 사이트에 이 스크립트를 실행해 봤는데, 심지어 그들조차 경고가 한두 개 있었습니다 (보통 유효성 검사기 누락 또는 조건부 요청에 대한 리디렉션). 이건 정상입니다. 목표는 어떤 것이 의도적인 문제인지를 아는 것입니다.

제가 가장 먼저 할 일

시간이 1시간밖에 없다면:

OAI-SearchBot과 GPTBot의 정책을 각각 결정하고, robots.txt에 작성하세요.
사이트에 가짜 URL을 입력해 보고 404를 반환하는지 확인하세요.
302로 되어 있지만 301이어야 하는 것을 수정하세요.
build 시간을 lastmod에 찍는 것을 중단하세요.

이것들은 새로운 SEO 조언이 아닙니다. 이번 주에 바뀐 것은 가장 큰 AI 검색 시스템 두 곳이 공개적으로, 이러한 정확한 패턴들이 무엇을 발견하게 하고 사이트가 얼마나 많은 크롤링을 유치하는지를 결정한다고 말했다는 것입니다.

만약 스크립트를 작성하지 않고도 목록을 받고 싶다면, 제가 Siteory를 만들었습니다. 이 도구는 웹사이트의 SEO, AI 검색 준비 상태 및 보안에 대한 무료 감사를 실행하고, 우선순위가 지정된 개발자용 수정 사항을 제공합니다. 어느 쪽이든, 가짜 URL 테스트는 10초밖에 걸리지 않습니다. 저는 거기서부터 시작할 것입니다.