2026년의 SEO: 트래픽의 절반이 ChatGPT를 통해 유입될 때

2026년에 실제로 존재하는 발견 채널(discovery channels)에 맞춰 재구축된 소규모 SaaS의 공개 인터페이스에 대한 주말 작업 기록입니다. 저는 2018년 스타일(PageMeta + sitemap.xml + robots.txt)의 탄탄하지만 구식인 베이스라인에서 시작하여, 모든 공개 인터페이스에 JSON-LD를 적용하고, 동적 사이트맵(dynamic sitemap), AI 크롤러를 겨냥한 llms.txt, 게시 시 IndexNow 알림, 실제 사용자의 Web Vitals 텔레메트리(telemetry), 그리고 JavaScript 엔진이 없는 AI 봇들이 각 경로의 특정 메타데이터를 실제로 볼 수 있도록 경로별 HTML 캡처를 구현하며 마무리했습니다. 빌드 과정에 Puppeteer는 사용하지 않았습니다.

TL;DR

계층	이전	이후
페이지별 메타(title/desc/canonical/OG/Twitter)	52/139 페이지에 PageMeta 래퍼 적용	변경 없음; 패턴이 이미 올바르게 구성되어 있었음
...

2026년의 기본 질문은 "우리가 AI 답변에 포함되어야 할까?"가 아니라, "우리가 AI 답변에 '조금이라도' 포함되어 있는가?"입니다. 단 하루의 작업으로 5년 전에는 존재하지 않았던 발견 채널을 확보할 수 있습니다.

시작점

frontend/
├── public/
│   ├── robots.txt          # 14줄, 기본적으로 Allow + 비공개 인터페이스 Disallow
...

베이스라인이 나쁘지는 않았습니다. PageMeta는 이미 title, description, canonical, OG, Twitter Card를 생성하고 있었습니다. index.html은 소셜 프리뷰어(LinkedIn, WhatsApp, Slack)가 어떤 JS가 실행되기 전에도 유용한 미리보기를 받을 수 있도록 정적 기본값을 제공했습니다. 인증 흐름의 페이지들은 이미 noindex,nofollow를 로드하고 있었습니다.

하지만 다음과 같은 것들은 수행하지 못하고 있었습니다: 2019년 이후 크롤러들이 추가한 그 어떤 것도 말이죠.

1. schema.org 없음. hreflang 없음. llms.txt 없음. 동적 사이트맵 없음. 실제 사용자들이 실제로 무엇을 보는지에 대한 텔레메트리(telemetry) 전무. 유기적 트래픽(organic traffic)의 점점 더 큰 비중을 차지하고 있는 AI 크롤러를 위한 특별한 처리도 전혀 없었습니다.

1단계: PageMeta 래퍼(wrapper)에서의 schema.org JSON-LD + hreflang

가장 큰 승리는 병렬 인프라를 구축하는 대신 이미 존재하던 PageMeta 컴포넌트를 확장하는 데서 왔습니다. 세 가지 새로운 props를 추가했습니다:

// myapp/src/components/seo/PageMeta.tsx (발췌)
export interface PageMetaProps {
  title: string;
...

• jsonLd: schema.org 딕셔너리 또는 리스트를 허용하며, 각각 application/ld+json 타입의 <script> 태그를 생성합니다. 페이지는 선언적(declarative) 상태를 유지하며, 무거운 작업은 빌더 라이브러리에서 처리됩니다.
• ogType: 기존에 하드코딩되어 있던 website 대신, 블로그 포스트는 og:type=article로, 프로필은 og:type=profile로 설정할 수 있게 합니다. 이는 LinkedIn/Discord/Slack에서의 리치 카드(rich card) 미리보기를 관리합니다.
• hreflang="es-mx" + x-default: 매 렌더링 시 적용됩니다. 이것이 없으면 Google이 가끔 다른 언어의 검색 결과에 스페인어 페이지를 제공하여 사용자들이 이탈(bounce)하게 만들었는데, 이는 5-10%의 조용한 인덱싱 손실을 초래했습니다.

여섯 개의 빌더를 포함한 작은 schema.ts 라이브러리:

// myapp/src/components/seo/schema.ts (발췌)
export function articleSchema(args: {
  url: string;
...

그 후 각 페이지에서 한 줄의 코드:

// myapp/src/pages/BlogPostPage.tsx (발췌)
<PageMeta
  title={post.title}
...

해당하는 페이지에 게시된 6가지 스키마(schema):

페이지	스키마	해제되는 기능
홈(Home)	Organization + WebSite (SearchAction)	Google 지식 패널 + 사이트링크 검색창
...

배포 전 Google의 리치 결과 테스트(https://search.google.com/test/rich-results)를 통해 검증을 마쳤습니다.

2단계: llms.txt + 명시적인 AI 크롤러 정책

robots.txt는 기본적으로 User-agent: *를 통해 모든 것을 허용했습니다. 허점은 다음과 같습니다: 일부 AI 크롤러(crawler)는 자신의 User-agent에만 규칙을 한정하고 *를 무시한다는 점입니다. 또한 robots.txt는 '의도(intention)'를 전달하지 못합니다. 그저 "크롤링할 수 있습니까?"라고 물을 뿐, "이 사이트는 무엇이며, 누구를 위한 것이고, 어떻게 인용해야 합니까?"라고 묻지는 않습니다.

두 부분으로 구성된 해결책:

1. 루트 디렉토리의 llms.txt (2026년의 표준 — 사양은 https://llmstxt.org에서 확인 가능). Anthropic, OpenAI, Perplexity, 그리고 Google의 AI 크롤러들이 이를 읽습니다. 이는 AI를 위한 친화적인 README처럼 보입니다:

# 내 사이트

> LATAM 기술 전문가 커뮤니티. ...
...

2. 자신의 User-agent에만 집중하는 봇들을 위한 robots.txt 내 명시적 허용 블록: GPTBot, ClaudeBot, anthropic-ai, PerplexityBot, Google-Extended (Googlebot과는 별개인 Google AI Overviews의 크롤러), CCBot 등이 대상입니다. 각 봇은 프라이빗 영역의 Disallow 정책을 반복하여 명시합니다.

이 결정을 내린 이유: AI 답변에서의 가시성(visibility)은 이미 주요한 발견 채널(discovery channel)이 되었습니다. 여기서 빠지기로 선택하는 것은 스크래핑(scraping)에 대한 우려를 줄여 얻는 이득보다, 도달 범위(reach) 상실로 인한 손실이 더 큽니다. 어떠한 독점적 콘텐츠도 공개된 영역에 존재하지 않기 때문입니다. 가역적(Reversible)입니다: 영향을 받는 User-agent 블록에서 Allow: /를 Disallow: /로 변경하기만 하면 됩니다.

3단계: 동적 사이트맵 (Dynamic sitemap)

정적 sitemap.xml은 13개의 랜딩 URL만을 포함하고 있었습니다. 블로그 포스트, 공개 프로필, 급여 보고서 등은 Google 인덱스에 절대 나타나지 않았습니다.

아키텍처: 정적 sitemap.xml을 정적 랜딩 페이지 목록과 백엔드에서 제공되는 3개의 동적 사이트맵을 참조하는 **사이트맵 인덱스 (sitemap index)**로 전환합니다.

<!-- frontend/public/sitemap.xml — 기존에는 urlset이었으나, 이제는 sitemapindex입니다 -->
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap><loc>https://misitio.io/sitemap-landing.xml</loc></sitemap>
...

백엔드는 크롤러(Crawler)가 자연스러운 URL로 인식할 수 있도록 동적 콘텐츠를 루트(Root)에서 서빙합니다 ( /api/v1 아래가 아님).

# myapp/api/sitemap.py
@router.get("/sitemap-blog.xml", include_in_schema=False)
async def sitemap_blog(db: AsyncSession = Depends(get_db)) -> Response:
...

테스트를 까다롭게 만드는 세 가지 함정:

# myapp/tests/test_sitemap.py
async def test_sitemap_blog_skips_published_with_null_published_at(...):
    # 발행 중인 행 (is_published=True 이지만 published_at 이 NULL인 경우)
...

호스트 간 교차(Cross-host) 주의사항: 루트 도메인이 misitio.io인 상태에서 api.misitio.io로부터 서빙하는 경우, 두 호스트 모두 Google Search Console 및 Bing Webmaster Tools에서 동일한 속성(Property)으로 인증되어야 합니다. 콘솔에서 약 5분 정도 소요되는 작업이며, 운영 매뉴얼에 문서화되어 있습니다.

4단계: 게시 시 IndexNow 적용

Google은 2023년에 /ping?sitemap=... 엔드포인트를 중단했습니다. Google의 전략은 "동적 사이트맵에 URL을 포함하고 Search Console의 발견(Discovery) 기능을 신뢰하라"는 것이며, 이것이 이전 단계였습니다.

그 외 모든 서비스(Bing, Yandex, Naver, Seznam, Cloudflare)를 위해서는 IndexNow를 사용합니다. 새로운 URL을 https://api.indexnow.org/IndexNow로 POST 요청하면 몇 분 내에 인덱스(Index)에 반영됩니다.

# myapp/services/indexnow.py
async def ping(urls: Sequence[str], *, host: str = "myapp.example") -> bool:
    key = settings.INDEXNOW_KEY
...

소유권 확인은 사이트 루트에 {INDEXNOW_KEY}.txt 파일을 배치하여 작동합니다 (우리는 이를 frontend/public/ 아래에 게시합니다). 키는 단순한 32자 16진수 문자열이며, 파일에는 동일한 문자열이 포함됩니다. IndexNow는 요청을 수락하기 전 이 파일을 한 번 확인합니다.

게시 흐름(Publishing flow)에 연결하기:

# myapp/services/blog_service.py (발췌)
async def publish_post(db, slug, user) -> BlogPost:
    # ... 보상, 알림, 감사 로그(Audit log) ...
...

try: ... except: pass는 의도된 것입니다. IndexNow가 다운되어 있더라도 게시물은 반드시 정상적으로 발행되어야 합니다. 관찰 가능성(Observability)은 게시 경로가 아니라 헬퍼(Helper)의 구조화된 로그(Structured logs)에 존재하기 때문입니다. 테스트는 각각의 조용한 건너뛰기(Silent skip) 분기를 묶어줍니다:

# myapp/tests/test_indexnow.py
async def test_ping_noop_when_indexnow_key_unset(...): ...
async def test_ping_noop_on_empty_url_list(...): ...
...

여기서 발생하는 버그는 "새 게시물이 일주일 동안 Bing에 나타나지 않음"과 같은 조용한 버그가 됩니다. 따라서 각 분기에서의 명시적인 단언(Asserts)이 중요합니다.

5단계: Web Vitals를 통한 실제 사용자 모니터링

개발자의 노트북에서 측정된 Lighthouse 점수는 허구입니다. 올바른 질문은 "Querétaro의 불안정한 LTE 연결 환경에서 대시보드를 열 때 관리자가 실제로 무엇을 보는가?"여야 합니다.

Web Vitals가 그 해답을 제공합니다: CLS, INP, LCP, FCP, TTFB를 각 페이지 뷰에서 샘플링하고, 트리거하는 탐색(Navigation) 과정 중에도 로드가 유지될 수 있도록 navigator.sendBeacon을 통해 전송합니다.

프론트엔드 (web-vitals 패키지 위에 구현된 약 1KB의 코드):

// myapp/src/lib/vitals.ts
import { onCLS, onFCP, onINP, onLCP, onTTFB } from "web-vitals";

...

백엔드 (단일 엔드포인트, 데이터베이스 쓰기 없음 — Vitals는 샘플링된 휘발성 데이터이며, "하루 수천 건"의 데이터를 저장하기에는 CloudWatch가 적절한 저장소입니다):

# myapp/api/v1/rum.py
class VitalsPayload(BaseModel):
    v: int = Field(ge=1, le=1)
...

페이지별 LCP의 p75를 구하기 위한 CloudWatch Logs Insights 쿼리:

fields @timestamp, name, value, url
| filter name = "LCP"
| stats pct(value, 75) as p75 by url
...

p75(LCP) > 3000ms에 대한 미래의 알람은 배포 후 몇 시간 내에 회귀(Regression)를 포착할 수 있습니다. 이는 그 어떤 월간 Lighthouse 감사보다 빠릅니다.

6단계: Puppeteer 없이 경로별 HTML 캡처

현대의 Googlebot은 JavaScript를 실행합니다. Bingbot은 2019년부터 그렇게 해왔습니다. 하지만 대부분의 AI 크롤러 (Anthropic, OpenAI, Perplexity)와 제가 테스트한 모든 소셜 프리뷰어 (LinkedIn, WhatsApp, Slack, Discord)는 어떠한 JS가 실행되기 전에 원시 HTML (raw HTML)을 다운로드하고 메타 태그 (meta tags)를 읽습니다.

런타임 시의 PageMeta (react-helmet-async)는 브라우저와 JS를 이해하는 크롤러에게는 정확하지만, SPA가 제공하는 첫 번째 바이트의 HTML은 요청된 경로를 가져오지 않은 상태의 홈 페이지 기본값입니다. /nosotros를 콜드 스타트(cold visit)로 방문하면 메타 태그는 '우리(Nosotros)' 페이지가 아닌 홈 페이지를 설명하게 됩니다.

처음에는 @prerenderer/rollup-plugin + Puppeteer 조합을 시도했습니다. 작동은 했지만, Chromium 다운로드 용량이 약 300MB에 달하며, 셀프 호스팅 중인 CI 러너는 2GB ARM 인스턴스입니다. pytest의 4개 샤드(shards)가 병렬로 실행될 때 테스트 작업이 메모리 부족을 겪는 것과 마찬가지로, 매 빌드마다 메모리 부족 현상이 발생할 것이 분명했습니다. 그럴 가치가 없었습니다.

대신 100줄 정도의 포스트 컴파일 (post-compilation) 스크립트를 작성했습니다. 각 정적 랜딩 경로에 대해 dist/index.html을 복사한 뒤, 해당 경로에 특화된 <title>, <meta name="description">, <link rel="canonical">, 그리고 OG, Twitter, hreflang 태그들을 패치(patch)합니다.

// myapp/frontend/scripts/build-seo-snapshots.mjs (발췌)
const ROUTES = [
  { path: "/nosotros", title: "Nosotros", description: "..." },
...

빌드 프로세스에 연결:

{
  "scripts": {
    "build": "vite build --mode production && node scripts/build-seo-snapshots.mjs"
...

출력:

[build-seo-snapshots] wrote 8 per-route HTML snapshots

CloudFront는 /nosotros 요청에 대해 SPA의 폴백(fallback)이 아닌 dist/nosotros/index.html을 서빙합니다 (S3는 일치하는 경로의 index를 자동으로 서빙합니다). 이제 경로를 콜드 스타트로 요청하면 첫 번째 바이트에서 해당 경로의 특정 메타 데이터를 반환합니다.

Puppeteer를 이용한 SSR과의 트레이드오프 (trade-off):

	정적 캡처 (이 방식)	Puppeteer를 이용한 SSR
메타 태그 (Meta tags)	경로별, 첫 번째 바이트	경로별, 첫 번째 바이트
...

AI 우선 (AI-first) 2026년 전략을 위해서는, 정적 캡처 (static captures) 방식이 단 1%의 복잡성으로 대부분의 가치를 포착합니다.

결과