AI 검색 시대에도 테크니컬 SEO가 먼저인 이유는?
AI 검색에서 노출되려면 새로운 비법보다 AI 크롤러가 내 페이지를 읽고 색인할 수 있게 만드는 테크니컬 SEO가 먼저입니다. 구글 AI 개요와 ChatGPT 검색은 모두 웹에서 접근할 수 있는 페이지를 근거로 답을 만들어요. 봇 접근 설정이나 렌더링, 색인 신호가 막혀 있으면 콘텐츠가 아무리 좋아도 인용 후보에 오르지 못합니다.
“이제 AI 검색에 대응해야 한다”는 말은 여기저기서 들립니다. 그런데 막상 개발자나 제작사에 무엇을 요청해야 할지 막막하다는 분들이 많더라고요. 그래서 이번 글에서는 접근 제어, 렌더링, 색인 신호, 속도, 구조화 데이터, 측정까지 여섯 가지 영역을 점검 순서대로 정리했습니다.
AI 답변은 크롤링·색인된 페이지 위에서 만들어진다
구글의 AI 개요(AI Overviews)와 AI 모드는 별도의 수집 시스템을 쓰지 않습니다. Googlebot이 크롤링해서 구글 검색에 색인한 페이지 중에서 답의 근거를 고르는 구조예요. 구글 Search Central의 “AI features and your website” 문서에도 AI 기능에 노출되기 위한 추가 요건은 없다고 나와 있습니다. 일반 검색에 노출되는 기술 요건을 갖추면 된다는 뜻이에요.
ChatGPT 검색과 Perplexity는 사정이 조금 다릅니다. OpenAI는 OAI-SearchBot, Perplexity는 PerplexityBot이라는 자체 검색 봇으로 페이지를 모읍니다. 이 봇들이 내 사이트에 들어오지 못하면 해당 서비스에서는 인용될 기회가 아예 없어요.
AI 검색은 ‘새로운 검색’이라기보다 ‘내 페이지를 읽는 주체가 늘어난 검색’에 가깝습니다. 읽히지 않은 페이지는 인용될 수 없습니다.
기존 SEO와 달라지는 것, 그대로인 것은?
기본기는 그대로입니다. 다만 점검해야 할 범위가 넓어졌어요. 아래 표에 차이를 정리했습니다.
| 항목 | 그대로인 것 | 달라지는 것 |
|---|---|---|
| 크롤링 접근 | robots.txt와 서버 응답으로 검색 봇의 접근을 보장해야 함 | 확인해야 할 AI 봇의 종류가 늘어남 |
| 렌더링 | Googlebot은 자바스크립트를 렌더링함(지연 가능) | 자바스크립트를 실행하지 않는 것으로 보고된 AI 크롤러가 있음 |
| 색인 | 색인돼야 노출됨. AI 개요도 구글 색인을 씀 | 서비스마다 따로 색인 체계를 가짐 |
| 페이지 품질 | 유용하고 신뢰할 수 있는 콘텐츠가 기준 | 변화 없음 |
| 노출 형태 | 검색 결과에서 클릭을 받아 유입 | 클릭 없이 답변 속 인용으로만 노출되는 경우가 생김 |
“SEO는 끝났다”는 말이 자주 들리지만, 제가 보기엔 게임이 바뀌었다기보다 점검할 범위가 넓어진 쪽에 가깝습니다. AEO의 개념과 전략은 AEO 답변 엔진 최적화 7가지 전략에서 다뤘어요. 문단 구조나 직답형 작성 같은 콘텐츠 쪽은 AI 검색에 인용되는 콘텐츠 작성법을 참고하세요. 이 글은 기술 영역에만 집중합니다.
AI 크롤러 접근 설정: robots.txt와 방화벽 점검
AI 크롤러는 학습용·검색용·사용자 요청용으로 나뉘며, 검색 노출에는 검색용 봇 허용이 핵심입니다. 이 구분을 모른 채 “AI 봇은 다 막자” 또는 “다 열자”로 정하면 원치 않는 결과가 생기기 쉬워요.
학습용 봇과 검색용 봇은 다르게 다뤄야 한다
주요 AI 회사들은 용도별로 봇을 나눠 운영합니다. 아래 표는 2026년 10월 기준으로 각 사 공식 문서에 공개된 이름을 정리한 것입니다. 봇 이름과 동작은 자주 바뀌니, 설정하기 전에 공식 문서를 한 번 더 확인하세요.
| 회사 | 학습용 | 검색 색인용 | 사용자 요청용 |
|---|---|---|---|
| OpenAI | GPTBot | OAI-SearchBot | ChatGPT-User |
| Anthropic | ClaudeBot | Claude-SearchBot | Claude-User |
| Perplexity | 별도 공개 없음 | PerplexityBot | Perplexity-User |
| Google-Extended(제어용 토큰) | Googlebot(검색·AI 개요 공용) | 해당 없음 |
여기서 많이 헷갈리는 게 Google-Extended입니다. 이건 별도 크롤러가 아니라 Gemini 모델 학습 등에 콘텐츠를 쓸지 정하는 제어용 토큰이에요. 구글 공식 문서 기준으로, Google-Extended를 막아도 구글 검색 순위나 AI 개요 노출에는 영향이 없습니다. AI 개요에 내 콘텐츠가 쓰이는 걸 제한하고 싶다면 nosnippet 같은 스니펫 제어를 써야 해요.
사용자 요청용 봇은 사용자가 대화 중에 특정 링크를 열어 달라고 할 때 접근합니다. 각 사는 이런 요청에 robots.txt 규칙이 그대로 적용되지 않을 수 있다고 안내하고 있어요. 아래는 “학습은 거부하되 검색 노출은 허용”하는 robots.txt 예시입니다.
# 학습용 봇 차단
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /
# AI 검색용 봇 허용
User-agent: OAI-SearchBot
Allow: /
User-agent: Claude-SearchBot
Allow: /
User-agent: PerplexityBot
Allow: /
# 그 외 모든 봇
User-agent: *
Disallow: /admin/
Sitemap: https://www.example.com/sitemap.xmlChatGPT 검색에 노출되려면 GPTBot보다 OAI-SearchBot 허용 여부가 더 중요합니다. 실전 전략은 챗GPT 검색 노출, 지금 해야 할 3가지 실전 전략에 따로 정리해 두었어요.
학습용 봇까지 열지는 정답이 없는 선택입니다. 유료 콘텐츠나 독자적인 자료를 보호하는 게 중요하다면 막는 편이 맞아요. 반대로 브랜드가 AI 답변에 더 자주 언급되는 게 목표라면 여는 쪽을 고려할 수 있습니다. 봇 방문이 몰려 서버 부하가 커지는 것도 함께 따져봐야 해요.
CDN·방화벽이 AI 봇을 몰래 막고 있지는 않을까?
robots.txt에서 허용해 놓아도 CDN이나 방화벽(WAF)이 막고 있으면 소용이 없습니다. 실제로 Cloudflare는 2025년 7월, 새로 연결하는 도메인에서 AI 크롤러를 기본으로 차단하는 방향으로 정책을 바꾼다고 발표했어요. 사이트 운영자가 직접 설정을 바꾼 적이 없는데도 AI 봇이 막혀 있을 수 있다는 얘기입니다.
- CDN 대시보드의 보안·봇 관리 메뉴에서 AI 봇 차단 옵션이 켜져 있는지 확인합니다. 메뉴 이름은 업데이트에 따라 바뀔 수 있어요.
- CDN이 robots.txt를 대신 관리해 주는 기능을 쓰고 있는지 봅니다. 브라우저에서 내 도메인/robots.txt를 직접 열어 실제로 적용된 규칙을 확인하세요.
- WAF 사용자 규칙, 국가 차단, 요청 빈도 제한이 해외 봇 트래픽을 막고 있지 않은지 점검합니다.
- 아래 명령어로 봇 이름을 흉내 낸 요청을 보내 응답 코드를 확인합니다. 403이나 챌린지 페이지가 돌아오면 차단된 상태예요.
- 서버 접근 로그나 CDN 분석 화면에서 봇 이름으로 검색해 실제 방문 기록이 있는지 확인합니다.
# 봇 이름으로 접근했을 때 응답 코드 확인
curl -I -A "OAI-SearchBot" https://www.example.com/
# 서버 로그에서 AI 봇 방문 기록 찾기
grep -iE "OAI-SearchBot|GPTBot|ClaudeBot|Claude-SearchBot|PerplexityBot" access.log참고로 봇 이름(User-Agent)은 누구나 흉내 낼 수 있습니다. 로그에 찍힌 방문이 진짜 봇인지 확인하려면 각 사가 공개한 IP 대역과 대조해야 해요. 이 작업은 개발자나 호스팅 담당자에게 맡기는 게 좋습니다.
자바스크립트로 만든 사이트, AI에게도 보일까?
Googlebot은 자바스크립트를 렌더링하지만, 상당수 AI 크롤러는 실행하지 않는 것으로 보고됐습니다. Googlebot도 렌더링 대기열을 거치기 때문에 반영이 늦어질 수 있어요. 2024년 Vercel과 MERJ의 분석에서는 GPTBot, ClaudeBot 같은 주요 AI 크롤러가 자바스크립트 파일을 내려받기는 해도 실행하지는 않는다고 보고됐습니다.
크롤러는 계속 업데이트되니 영구적인 사실로 보기는 어렵지만, 지금 대비해 둘 이유로는 충분합니다.
렌더링 방식별 노출 차이(SSR·SSG·CSR)
핵심은 “서버가 처음 보내는 HTML에 본문이 들어 있는가”입니다. 렌더링 방식별로 비교하면 이렇습니다.
| 방식 | 초기 HTML의 본문 | Googlebot | JS를 실행하지 않는 크롤러 |
|---|---|---|---|
| SSR(서버 사이드 렌더링) | 포함 | 읽음 | 읽음 |
| SSG(정적 생성) | 포함 | 읽음 | 읽음 |
| CSR(클라이언트 렌더링) | 비어 있을 수 있음 | 렌더링 후 읽음(지연 가능) | 놓칠 위험이 큼 |
React나 Vue로 만든 SPA가 대표적인 CSR 사이트예요. 이런 사이트는 서비스 설명, 가격, FAQ가 페이지가 열린 뒤 API를 호출해서 그려지는 경우가 많습니다. 그러면 초기 HTML에는 <div id="root"></div> 같은 빈 틀만 남아요. 사람 눈에는 멀쩡해 보여도, 자바스크립트를 실행하지 않는 크롤러 입장에서는 내용이 없는 페이지입니다.
원본 HTML에 핵심 내용이 있는지 확인하는 법
개발 지식이 없어도 아래 세 가지 방법으로 확인할 수 있습니다.
- 페이지 소스 보기: 페이지에서 마우스 오른쪽 버튼을 누르고 ‘페이지 소스 보기’를 선택하세요(Ctrl+U). 그다음 Ctrl+F로 본문의 핵심 문장이나 가격을 검색합니다. 개발자 도구의 Elements 탭은 렌더링이 끝난 화면이라 이 확인에는 맞지 않아요.
- curl로 받아 보기: 터미널에서
curl -s https://www.example.com/page | grep "핵심 문장"을 실행합니다. 아무것도 나오지 않으면 초기 HTML에 그 내용이 없는 거예요. - Search Console URL 검사: URL을 입력하고 ‘실제 URL 테스트’를 누른 뒤 ‘테스트한 페이지 보기’에서 HTML을 확인합니다. 이건 Googlebot이 렌더링한 결과라서, 1번의 원본 소스와 비교하면 차이가 보입니다.
소스에는 없는데 URL 검사 결과에만 있다면 구글은 읽지만 일부 AI 크롤러는 못 읽는 상태입니다. 그럴 땐 개발자에게 이렇게 요청하면 돼요.
“서비스 소개·상품 상세·FAQ 페이지의 본문, 가격, FAQ 텍스트가 자바스크립트 실행 전 초기 HTML에 포함되도록 SSR이나 SSG로 바꿔 주세요. 전체 전환이 어렵다면 이 경로만이라도 사전 렌더링(프리렌더링)을 적용해 주세요.”
색인 신호 정리: 캐노니컬·사이트맵·IndexNow
색인 신호는 캐노니컬·리디렉션·사이트맵이 모두 같은 대표 URL 하나를 가리키도록 맞추는 것이 핵심입니다. 신호가 서로 엇갈리면 검색엔진이 대표 URL을 스스로 고르는데, 그 선택이 운영자의 의도와 다를 수 있어요.
중복 URL과 캐노니컬 충돌 정리
중복 URL은 생각보다 흔하게 생깁니다. utm 같은 추적 파라미터나 정렬 파라미터, http와 https 혼재, www 유무, 끝 슬래시 차이, 페이지네이션이 대표적인 원인이에요. 아래는 실무에서 자주 보이는 신호 충돌 예시입니다.
| 신호 | 충돌 상태 | 정리 후 |
|---|---|---|
| 캐노니컬 태그 | http://example.com/service | https://www.example.com/service |
| 리디렉션 | https://www.example.com/service/ (슬래시 붙음) | https://www.example.com/service 로 301 |
| 사이트맵 | https://example.com/service (www 없음) | https://www.example.com/service |
| 내부 링크 | 세 가지 형태가 섞여 있음 | 대표 URL로 통일 |
정리 원칙은 간단합니다. 대표 URL을 하나 정하고, 캐노니컬·리디렉션·사이트맵·내부 링크를 모두 그 URL에 맞추세요. 파라미터가 붙은 URL은 캐노니컬로 원본을 가리키게 합니다. 페이지네이션은 2페이지, 3페이지가 각자 자기 자신을 캐노니컬로 지정하는 게 기본이에요. 모든 페이지를 1페이지로 몰아 버리면 뒤쪽 페이지의 콘텐츠가 색인에서 빠질 수 있습니다.
색인이 안 되는 원인 전체를 진단하고 싶다면 내 홈페이지가 검색에 안 뜨는 이유와 진단법을, 색인 이후 순위가 정해지는 구조는 구글 상위 로직 해부를 참고하세요.
사이트맵 lastmod와 IndexNow, 언제 써야 할까?
사이트맵의 lastmod는 실제로 내용을 수정했을 때만 바꿔야 합니다. 구글은 lastmod 값이 꾸준히 정확한 사이트에서만 이 값을 참고한다고 밝혔어요. 사이트맵을 만들 때마다 모든 페이지에 오늘 날짜를 찍는 설정이라면 이 신호가 무시될 수 있습니다.
IndexNow는 페이지가 바뀌었을 때 검색엔진에 바로 알리는 프로토콜이에요. Bing, Yandex, 네이버 등이 지원하지만 구글은 지원하지 않습니다. ChatGPT 검색이 Bing 색인과 관련이 있다는 업계 관측이 있어서 간접적인 도움을 기대하는 의견도 있습니다. 다만 OpenAI가 공식 확인한 내용은 아니므로 “IndexNow를 쓰면 ChatGPT 노출이 늘어난다”고 보기는 어려워요.
워드프레스라면 플러그인으로 쉽게 켤 수 있으니, Bing과 네이버 색인 속도를 높이는 용도로 보면 적당합니다.
Core Web Vitals, 어디까지 신경 써야 할까?
Core Web Vitals는 LCP·INP·CLS 세 지표로 구성되며, 2024년 3월부터 FID 대신 INP를 씁니다. 지금도 FID를 기준으로 설명하는 글이 남아 있으니, 참고 자료를 볼 때 이 부분부터 확인해 보세요.
FID가 아니라 INP: 2024년에 바뀐 지표
구글은 2024년 3월 12일부터 INP(Interaction to Next Paint)를 Core Web Vitals에 넣고 FID를 뺐습니다. FID는 사용자의 첫 번째 입력에 대한 지연만 쟀어요. INP는 페이지에 머무는 동안 일어난 클릭, 탭, 키 입력 전체의 응답성을 봅니다. 버튼을 눌렀는데 화면이 한참 뒤에 반응하는 페이지라면 INP가 나쁘게 나옵니다.
| 지표 | 무엇을 측정하나 | ‘좋음’ 기준 |
|---|---|---|
| LCP | 가장 큰 콘텐츠가 표시되기까지 걸리는 시간 | 2.5초 이하 |
| INP | 사용자 상호작용 후 화면이 반응하기까지 걸리는 시간 | 200밀리초 이하 |
| CLS | 로딩 중 레이아웃이 밀리는 정도 | 0.1 이하 |
기준은 방문의 75번째 백분위 값으로 판단합니다. 대부분의 방문자가 이 범위 안에 들어와야 ‘좋음’으로 평가된다는 뜻이에요.
속도는 순위를 얼마나 좌우할까?
구글은 페이지 경험을 여러 순위 신호 중 하나로 설명하고, 콘텐츠의 관련성이 우선이라고 꾸준히 밝혀 왔습니다. 그러니 “속도만 올리면 상위 노출”은 과장이에요. 관련성이 비슷한 페이지끼리 비교될 때 차이를 만드는 요소로 보는 게 정확합니다. 실무에서는 다음 순서로 손대는 걸 권합니다.
- 이미지: WebP나 AVIF로 바꾸고 width·height를 지정해 CLS를 막습니다. 첫 화면의 대표 이미지는 지연 로딩(lazy)에서 빼야 LCP가 좋아져요.
- 서드파티 스크립트: 채팅 위젯, 중복된 추적 태그, 쓰지 않는 광고 스크립트를 정리합니다. INP 개선에 가장 직접적인 효과가 있어요.
- 캐싱: 브라우저 캐시와 CDN 캐시를 설정해 반복 방문과 서버 응답 속도를 개선합니다.
서버 응답 자체가 느리다면 호스팅부터 의심해 봐야 합니다. 고르는 기준은 워드프레스 호스팅 완벽 가이드에 정리해 두었어요.
구조화 데이터와 llms.txt, 효과는 어디까지 확인됐나?
구조화 데이터는 리치 결과와 정보 해석을 돕지만, AI 노출을 보장하는 장치는 아닙니다. llms.txt는 그보다 근거가 더 약한 제안 단계예요. 둘 다 “넣으면 AI에 뜬다”는 식으로 소개되는 경우가 많아서, 확인된 것과 아닌 것을 구분해 둘 필요가 있습니다.
스키마 마크업이 하는 일과 못 하는 일
구글의 “AI features and your website” 문서는 AI 개요나 AI 모드에 노출되기 위해 특별한 마크업이나 별도 파일을 만들 필요가 없다고 안내합니다. “스키마로 AI 노출 최적화”라고 단정하는 글들과는 출발점이 다른 셈이에요. 구조화 데이터의 역할은 리치 결과 자격을 얻고, 회사·상품·저자 같은 정보를 검색엔진이 명확하게 이해하도록 돕는 데까지입니다. 마크업 내용은 페이지에 실제로 보이는 정보와 일치해야 해요.
| 유형 | 쓰임새 | 참고 |
|---|---|---|
| Organization | 회사명·로고·연락처·공식 채널을 하나의 엔티티로 연결 | 홈페이지 또는 회사 소개 페이지에 1회 |
| Article | 블로그 글의 제목·게시일·수정일·저자 정보 | 콘텐츠 마케팅 블로그의 기본 |
| Product | 가격·재고·리뷰 정보로 리치 결과 자격 확보 | 쇼핑몰·상품 페이지 |
| FAQPage | 질문과 답변 구조 명시 | 2023년 8월 이후 FAQ 리치 결과는 정부·보건 등 일부 권위 사이트로 제한돼, 대부분의 사이트에서는 표시되지 않음 |
llms.txt, 지금 만들어야 할까?
llms.txt는 2024년 9월 제러미 하워드(Jeremy Howard)가 제안한 비공식 규격입니다. 사이트 루트에 핵심 페이지를 마크다운으로 요약한 파일을 두고, 언어 모델이 사이트를 쉽게 파악하게 하자는 아이디어예요. 표준 기구가 정한 규격은 아닙니다.
2025년에는 구글의 존 뮬러(John Mueller)가 “현재 llms.txt를 사용하는 주요 AI 시스템은 없다”는 취지로 언급했다는 보도가 업계 매체를 통해 나왔습니다. 정리하면 제안 단계이고, 주요 AI 검색의 채택은 확인되지 않은 상태예요.
효과가 확인된 것부터 하고, 확인되지 않은 것은 맨 마지막에 하세요. llms.txt는 만들어도 손해는 적지만 robots.txt와 렌더링 점검보다 앞설 이유는 없습니다.
AI 검색 유입은 어떻게 측정할까?
AI 검색 유입은 GA4 맞춤 채널 그룹으로 AI 리퍼러를 묶어서 따로 볼 수 있습니다. GA4 기본 설정에서는 이런 방문이 ‘추천(Referral)’ 채널에 다른 사이트 유입과 섞여 잡히기 때문에, 직접 분리해야 추세를 볼 수 있어요.
GA4에서 AI 리퍼러를 따로 보는 방법
아래 순서대로 설정하면 됩니다. 메뉴 이름은 GA4 업데이트에 따라 조금 다를 수 있어요.
- 관리 → 데이터 표시 → 채널 그룹으로 이동해 ‘새 채널 그룹 만들기’를 누릅니다. 기본 채널 그룹을 복사해 시작하면 기존 채널 구성이 유지돼요.
- ‘새 채널 추가’를 누르고 이름을 ‘AI 검색’으로 정합니다. 조건은 ‘소스’, ‘정규식과 일치’로 선택하고 아래 정규식을 넣습니다.
- 채널 순서 조정에서 ‘AI 검색’을 ‘추천(Referral)’보다 위로 올린 뒤 저장합니다. 순서가 아래에 있으면 추천 채널로 먼저 분류돼 버려요.
- 보고서 → 획득 → 트래픽 획득에서 기본 채널 그룹 대신 새로 만든 채널 그룹을 선택해 확인합니다.
.*(chatgpt\.com|chat\.openai\.com|perplexity\.ai|gemini\.google\.com|copilot\.microsoft\.com|claude\.ai).*한계도 분명합니다. 앱에서 링크를 열거나 리퍼러 정보가 전달되지 않으면 AI에서 온 방문도 direct로 잡혀요. 그래서 이 숫자는 AI 유입의 최소치로 보는 게 맞습니다. 절대 숫자보다는 월별 추세, 어떤 랜딩 페이지로 들어오는지, 다른 채널과 비교한 전환율을 보는 데 쓰세요.
Search Console에서 AI 개요 유입을 볼 수 있을까?
현재는 따로 볼 수 없습니다. 구글 공식 문서에 따르면 AI 개요와 AI 모드에서 생긴 노출과 클릭은 Search Console 실적 보고서의 ‘웹’ 검색 유형에 합산돼요. 별도 필터나 보고서는 없습니다.
그래서 AI 개요가 기여한 몫만 정확히 떼어낼 수는 없습니다. 노출은 늘었는데 클릭률이 떨어진 질문형 키워드를 살펴보면 AI 개요의 영향을 짐작해 볼 수는 있어요. 다만 이건 가설 수준의 관찰이라는 점을 기억하고 해석하세요.
사이트 유형별 테크니컬 SEO 우선순위 점검표
소규모 사이트는 접근과 색인부터, 자바스크립트 기반 사이트는 렌더링부터 확인하는 순서가 효율적입니다. 앞에서 다룬 내용을 실행 순서로만 압축했어요. ✅ 순서대로 하나씩 체크해 보세요.
워드프레스·빌더형 소규모 사이트라면 이 순서로
| 순위 | 점검 항목 | 확인 도구 | 담당 |
|---|---|---|---|
| 1 | robots.txt와 CDN의 AI 봇 차단 여부 | 브라우저로 /robots.txt 열기, CDN 대시보드 | 운영자 |
| 2 | 주요 페이지 색인과 캐노니컬 일치 | Search Console 페이지 색인 보고서, URL 검사 | 운영자 |
| 3 | 사이트맵 lastmod 정확성, IndexNow 적용 | SEO 플러그인 설정, Search Console 사이트맵 | 운영자 |
| 4 | 이미지·플러그인으로 인한 LCP·INP 저하 | PageSpeed Insights | 운영자, 필요 시 개발자 |
| 5 | AI 검색 맞춤 채널 그룹 | GA4 | 운영자 |
일부 사이트 빌더는 robots.txt나 서버 설정 수정을 제한합니다. 1순위 점검 전에 사용 중인 빌더의 지원 범위부터 확인하세요.
JS 프레임워크·대형 사이트는 무엇부터 볼까?
| 순위 | 점검 항목 | 확인 도구 | 담당 |
|---|---|---|---|
| 1 | 초기 HTML에 본문·가격·FAQ 포함 여부 | 페이지 소스 보기, curl, URL 검사 | 개발자 |
| 2 | WAF·봇 관리 설정과 실제 봇 방문 기록 | 서버 로그, CDN 대시보드 | 개발자 |
| 3 | 캐노니컬·리디렉션·사이트맵 신호 일치 | Search Console, 사이트 크롤링 도구 | 개발자 |
| 4 | INP와 서드파티 스크립트 정리 | PageSpeed Insights | 개발자 |
| 5 | AI 유입 측정 체계 | GA4 | 운영자 |
판단 기준은 하나입니다. 봇이 들어올 수 있는가, 들어와서 읽을 수 있는가, 읽은 걸 제대로 색인하는가. 이 세 가지가 해결된 다음에야 속도와 구조화 데이터가 의미를 가져요. 기술 점검을 마친 뒤의 순위 전략은 구글SEO 상위노출 전략 5가지에서, 외부 신호는 안전하게 상위 랭킹을 얻는 백링크 전략에서 이어서 볼 수 있습니다.
AI 검색 대응은 결국 내 사이트가 여러 봇에게 제대로 읽히는지 확인하는 일에서 시작합니다. 렌더링 방식이나 봇 차단 여부를 직접 확인하기 어렵다면 마케토리 무료상담을 신청해 주세요. 현재 사이트 구조를 함께 살펴보고, 어떤 항목부터 손대면 좋을지 정리해 드립니다.
자주 묻는 질문
AI 검색에 노출되려면 robots.txt에서 GPTBot을 허용해야 하나요?
ChatGPT 검색 노출에는 GPTBot보다 OAI-SearchBot 허용이 중요하며, GPTBot은 학습용입니다. OpenAI 공식 문서 기준으로 GPTBot은 모델 학습용 수집, OAI-SearchBot은 ChatGPT 검색 결과 노출용 수집을 맡아요. 그래서 GPTBot만 차단하고 OAI-SearchBot은 허용해서, 학습은 거부하면서 검색 노출은 유지하는 설정이 가능합니다.
Google-Extended를 차단하면 구글 AI 개요에서 빠지나요?
아니요, Google-Extended 차단은 구글 검색과 AI 개요 노출에 영향을 주지 않습니다. AI 개요는 Googlebot이 크롤링한 구글 검색 색인을 쓰기 때문이에요. AI 개요에 콘텐츠가 쓰이는 걸 제한하려면 구글 공식 문서가 안내하는 nosnippet 같은 스니펫 제어를 써야 합니다.
구조화 데이터를 넣으면 AI 검색 노출이 늘어나나요?
노출 증가가 보장되지는 않으며, 구글은 AI 기능용 특별한 마크업이 필요 없다고 밝혔습니다. 구조화 데이터는 리치 결과 자격을 얻고, 회사·상품·저자 같은 정보를 검색엔진이 명확하게 이해하도록 돕는 데 의미가 있어요.
llms.txt 파일을 만들어야 하나요?
현재 주요 AI 검색이 llms.txt를 사용한다는 근거가 확인되지 않아 우선순위는 낮습니다. 만드는 비용은 적지만, robots.txt와 방화벽 설정, 자바스크립트 렌더링 점검을 먼저 마치는 게 효과가 확인된 순서예요.
AI 검색에서 들어온 방문자는 어떻게 확인하나요?
GA4에서 chatgpt.com, perplexity.ai 등 AI 리퍼러를 묶은 맞춤 채널 그룹으로 확인할 수 있습니다. 다만 리퍼러가 빠진 방문은 direct로 잡힐 수 있어서 실제보다 적게 집계될 수 있어요. Search Console에서는 AI 개요와 AI 모드 유입이 웹 검색 실적에 합산되어 따로 분리되지 않습니다.
