본문 바로가기
서치뉴스SearchNews
검색
← 목록으로

HTTP 응답 헤더에 내부 링크 그래프를 인코딩하여 65,000페이지를 99초에 크롤링한 실험

metehan.ai조회수 144일 전

핵심

저자는 자신의 웹사이트 65,000페이지를 HTML 파싱 없이 HTTP 응답 헤더만 읽어 99초 안에 크롤링했다. 내부 링크와 제목 계층 정보를 Base64url 인코딩된 JSON으로 헤더에 직접 담은 새로운 접근 방식의 실험이다.

문제 제기와 아이디어

SEO Week 2026에서 LLM 크롤러들이 렌더링된 DOM 처리에 어려움을 겪는다는 논의 중에 저자가 제기한 핵심 질문:

"웹사이트가 모든 크롤러, 스크래퍼, LLM에 완벽히 이해되도록 하기 위해 할 수 있는 가장 작고, 빠르고, 심플한 일은 무엇인가?"

기존의 Robots.txt, 사이트맵, llms.txt, Schema.org 같은 방법들은 모두 크롤러가 HTML을 다운로드하고 파싱해야 한다고 가정한다. 그 대신 저자가 시도한 것:

구현 방식

헤더 구조

Cloudflare Worker를 통해 모든 응답에 다음 헤더들 추가:

X-Internal-Links: [base64url-encoded JSON]
X-Internal-Links-Encoding: json+base64url
X-Internal-Links-Bytes: 1455
X-Internal-Links-Count: 31
X-Headings: [base64url-encoded JSON]
X-Headings-Encoding: json+base64url
X-Headings-Bytes: 534
X-Headings-Count: 8

디코딩하면:

왜 헤더인가?

성능 측정

Run 1: 콜드 캐시 (초기)

Run 2: 워밍 캐시 (Cache-Control 추가 후)

Run 3: 100URL 프로브 (캐시 제외, 양쪽 헤더 포함)

SEO 인사이트 (헤더 데이터만 사용)

크롤링 후 65,000개 JSON 페이로드 분석 결과:

이 수준의 구조적 문제는 Screaming Frog, Sitebulb, Ahrefs 같은 도구로는 "홈페이지 감사"만으로는 절대 잡지 못했을 것.

SEO/AEO/GEO에 미치는 영향

전통 SEO 활용

AEO/GEO (답변 엔진 최적화)

Perplexity, ChatGPT, Gemini 같은 AI 엔진들은 구조화된 정보를 선호:

X-Headings: (H1-H6 리스트)
X-Page-Topic: "ecommerce conversion benchmarks Bangladesh 2026"
X-Page-Entities: ["Bangladesh", "ecommerce", "conversion rate", "2026"]
X-Page-Summary: (base64url 280자 요약)

크롤러가 "페이지를 이해하기를 원한다"고 기도하는 대신, 이해를 그대로 건넨다.

기술적 SEO 운영

선행 기술과의 차이

RFC 8288 - Link HTTP 응답 헤더 (2017)

표준이지만 페이지 전체 내부 링크 그래프에 부적절한 형식 (rel당 하나씩). 신택스가 빠르게 팽창.

Cloudflare Agent Readiness 프레임워크 (Q1 2026)

공식적으로 Link 헤더를 세 가지 에이전트 발견성 표준 중 하나로 나열하지만, 표준 rel만 대상. 전체 링크 그래프 패턴은 없음.

llms.txt (Sept 2024, Jeremy Howard / Answer.AI)

사이트 설명 마크다운 파일. 의도는 유사하지만:

JSON-LD via Accept 콘텐츠 협상

별도 요청 필요, 클라이언트 옵트인 필요. 저자 방식: 무조건 모든 응답에 도착.

Open Graph / 구조화된 데이터를 헤더로 (제안 스레드들)

이론에 머무름. 저자의 각도: Google 파싱을 기대하지 않음. 자체 도구, SEO/AEO 파이프라인, 모니터링, 개발 팀, 앞서가는 에이전트를 위해 발행.

프로덕션 장애 사례

배포 1시간 전, X-Headings 헤더 추가 후:

curl https://data.stateglobe.com/
HTTP/2 500

원인: 홈페이지의 230개 링크 + 길은 제목 리스트가:

대부분의 서브페이지 (31개 링크, 540바이트)는 잘 작동. 허브 페이지(가장 중요한 페이지)가 깨짐.

방어적 헤더 예산 모듈 (해결책)

TypeScript 모듈 src/headers.ts 추가:

import { attachStructuralHeaders } from "./headers";
return attachStructuralHeaders(
  new Response(html, { status: 200 }),
  {
    url: req.url,
    links: getInternalLinks(page), // 크기 제한 적용
    headings: getHeadings(page),   // 크기 제한 적용
  }
  // 기본값: 헤더당 6KB, 합계 12KB
);

동작:

  1. 헤더별 상한 (기본 6KB): 각 리스트를 10% 단위로 축소하여 Base64url 인코딩 크기 맞춤
  2. 합계 하드 캡 (기본 12KB): 개별로는 맞지만 합계가 초과하면, 제목 리스트 먼저 자르고 필요시 링크 리스트도 자름
  3. 잘림 텔레메트리: X-Internal-Links-Truncated: 1 및 X-Internal-Links-Original: 230 추가로 모니터링 가능

스트레스 테스트: 5,000개 링크 + 5,000개 제목 → 11.4KB 출력, 안전하게 캡 내 (500 에러 없음).

배포 전 체크리스트

헤더 크기 제한은 실제

허브 페이지가 위험 구역

방어적으로 캡 적용

엣지에서 캐시

배포 후 캐시 퍼지

HEAD 요청은 피할 것

누락된 헤더는 "데이터 부재"로 처리

자신의 도메인으로만 범위

엔터프라이즈: 혼자 배포하지 말 것

구조, 3문장 요약

  1. 페이지당 작은 JSON 페이로드(링크/제목/주제) 생성 후 캐시
  2. 모든 응답에 Base64url 인코딩 헤더로 페이로드 첨부, 크기 캡 적용해 헤더 합계 원점 제한 내 유지
  3. 응답을 엣지에서 캐시하면 두 번째 크롤은 본질상 무료

머신러닝, 복잡한 인프라, 프로토콜 변경 없음. 단일 개발자가 오후 한 번에 배포 가능하고, 부주의하면 5분 안에 프로덕션 깨뜨릴 수 있는 수준.

더 큰 그림: 헤더를 발행 표면으로

전통적 사고 vs 새 관점

지난 30년: 모든 것을 본문(body)에 집어넣고 기계가 파싱하길 원함. 크롤러, 파서 강화. 매 요청마다 번역 비용 지불.

HTTP 응답의 실체:

헤더 ← 기계 읽기용, 빠름, 구조화, 거의 무료
본문 ← 인간 읽기용, 느림, 비구조화, 비쌈

변화의 신호

LLM과 답변 엔진이 웹의 주요 소비자가 되면서, 구조화된 의도를 발행하는 사이트를 보상. HTTP 헤더는 구조화된 의도를 발행하기 위한 가장 빠르고 싸고 보편적인 장소.

새 프로토콜, 표준, W3C 위원회 불필요. JSON을 헤더에 넣고 신중하게 배포하면 됨.

향후 방향

완성된 것

✅ 방어적 헤더 예산 라이브러리 (src/headers.ts)

탐색 중

현재 라이브 데모 (data.stateglobe.com)

주의: 안전한 실험을 위해 의도적으로 페이로드 자름. 200+ 링크 허브는 완전한 그래프 배송 시 청크 헤더 필요. 공개 데모는:

배포 전 읽기 자료

코드 저장소

리포트

마무리

이 실험은 크롤링 문제 해결로 시작했으나, SEO Week 2026에서 전체 SEO/AEO/GEO 스택을 보는 새로운 방식으로 발전했다:

HTTP 헤더는 가장 과소평가된 웹 발행 표면이며, 기계가 더 많이 읽을수록 더 중요해질 것.

결과:

자신의 사이트가 있고, 오후 한두 시간, 개발팀 협력이 가능하다면 시도해보자. 먼저 눈에 띄는 것은 변화의 작음. 두 번째는 사이트 이해 방식이 얼마나 바뀌는지.

——

감사의 말: iPullRank 팀과 Michael King에게 SEO Week 2026 개최로 이 아이디어가 탄생할 수 있는 공간을 제공해주셔서 감사합니다.