AI 에이전트 SEO 검사: 에이전트가 페이지에서 실제로 보는 것

AI 에이전트에게 페이지의 SEO를 검사해 달라고 하면, 에이전트는 대개 텍스트로 변환된 페이지를 바탕으로 작업합니다. 제목과 본문은 전달되지만 HTTP 상태, 응답 헤더, 리디렉션 단계, head 태그, 구조화된 데이터는 대개 전달되지 않습니다. 그래서 에이전트는 글은 잘 검토할 수 있지만, 검색엔진이 그 페이지를 색인할지 결정하는 요소 대부분은 확인하지 못합니다.

가져오기 도구는 어시스턴트마다 다르고 시간이 지나며 바뀌므로, 중요한 질문은 에이전트가 무엇을 받았느냐입니다. 2026년 10월, 우리는 자사 페이지 하나로 이 질문에 답했습니다. 에이전트가 작업하는 텍스트 보기 옆에 전체 HTTP 교환을 기록했습니다. 이 글은 우리가 실행한 것, 각 보기에 들어 있던 것, 그리고 에이전트에게 빠진 증거를 건네는 방법을 그대로 보고합니다.

우리 페이지 하나를 두 방식으로 가져왔습니다

게시된 아티클인 리디렉션 체인 가이드를 골라, 사람이 채팅창에 붙여 넣을 법한 긴 주소인 http://www.seoreport.dev/articles/redirect-chains-guide/로 요청했습니다. 일반 HTTP, www 호스트, 후행 슬래시는 모두 사이트가 정규화하는 변형이므로 이 요청은 반드시 리디렉션됩니다.

이 페이지를 3가지 방식으로 읽었습니다.

1. 전체 HTTP 교환. curl로 모든 단계, 최종 상태 줄, 모든 응답 헤더, 원본 HTML을 기록했습니다.
2. 같은 HTML의 일반 텍스트 추출. 스크립트, 스타일, <head>를 제거하고 보이는 텍스트만 남겼습니다. 많은 가져오기 도구가 어시스턴트가 페이지를 읽기 전에 수행하는 변환입니다.
3. 한 AI 코딩 어시스턴트에 내장된 가져오기 도구. 받은 콘텐츠에 문자 그대로 들어 있는 것만 항목별로 보고하도록 요청했습니다.

여기서 중요한 모든 항목에서 보기 2와 3의 결과가 일치했으므로 표에서는 함께 보여 줍니다. 차이는 하나뿐이었습니다. 가져오기 도구는 페이지 제목을 전달했고, 일반 텍스트 추출은 같은 단어가 들어 있는 H1을 남겼습니다.

크기로 보면 텍스트 보기는 71 KB HTML 응답 중 약 10 KB였습니다. 빠진 것 대부분은 스크립트와 스타일 코드로, SEO 검토에는 필요 없습니다. 나머지가 바로 SEO 검토가 읽어야 할 증거입니다.

표에서 개수보다 중요한 세부 사항이 두 가지 있습니다. 첫째, 표준 태그에 대한 답은 질문 방식에 따라 달라졌습니다. 각 태그를 "있음 또는 없음"으로 표시하라고 하자, 가져오기 도구는 페이지에 실제로 있는 표준 태그를 "없음"으로 답했고, <head>에 관한 단서는 그 뒤에야 덧붙였습니다. "알 수 없음"이라는 선택지를 주자 그것을 골랐습니다. 첫 번째 답을 받고 그대로 행동하는 에이전트라면 이미 있는 태그를 추가하라고 권했을 것입니다. 둘째, Article JSON-LD와 article:modified_time 태그에는 모두 수정일 2026년 10월 3일이 들어 있지만, 화면에 보이는 작성자 줄에는 게시일인 2026년 9월 28일만 표시됩니다. 검색엔진이 '최종 업데이트'로 읽을 수 있는 날짜는 에이전트가 전혀 받지 못한 부분에만 있었습니다.

이 페이지에는 아무 문제도 없었습니다. 리디렉션 2단계는 Google 크롤링 문서가 크롤러가 따라간다고 밝힌 10단계 이내이고, 표준 태그는 페이지 자신을 가리킵니다. 핵심은 에이전트가 어느 쪽인지 알 수 없었다는 점입니다.

가져오기 도구는 페이지가 실패할 때만 상태를 보고했습니다

사이트에 존재하지 않는 주소로 테스트를 반복했습니다. 서버는 404로 응답했고, 가져오기 도구도 그렇게 말했습니다. "HTTP 404 Not Found"를 보고하고 페이지 텍스트는 반환하지 않았습니다. 정상 페이지에서는 200이 한 번도 언급되지 않았습니다.

오류는 드러나고 성공 응답은 조용히 넘어가는 이 패턴에서는, 가장 골치 아픈 경우가 빠집니다. 그런 경우는 200으로 응답하기 때문입니다.

• 없는 페이지처럼 읽히지만 200으로 응답하는 페이지. 우리 404 페이지에는 "Article Not Found. The article you are looking for does not exist."라고 적혀 있습니다. 서버가 같은 텍스트를 200 상태로 보냈다면 텍스트 보기는 똑같았을 것입니다. 어느 쪽인지 검색엔진에 알려 주는 것은 상태 줄뿐이며, Google이 200 버전을 감지하면 Search Console은 이를 'Soft 404'로 보고합니다.
• 완벽하게 읽히지만 검색엔진에 색인하지 말라고 하는 페이지. Google의 robots 메타 태그 문서(2026년 10월 확인)에 따르면 robots 메타 태그에 쓸 수 있는 규칙은 모두 X-Robots-Tag HTTP 헤더로도 보낼 수 있습니다. 이렇게 보낸 noindex는 텍스트에 아무 흔적도 남기지 않습니다. 이런 경우를 찾아 판단하는 방법은 Search Console의 URL이 'NOINDEX'로 표시됨에서 다룹니다.
• 표준 URL을 헤더로 선언한 페이지. Google은 HTML 태그의 대안으로, PDF 같은 HTML이 아닌 파일까지 포함해 rel="canonical"이 있는 Link 응답 헤더를 문서화하고 있습니다. 텍스트 보기로는 이를 볼 수 없습니다.

증거는 페이지가 아니라 교환 안에 있습니다

텍스트 보기가 버린 것은 모두 한 종류입니다. 서버와 크롤러가 주고받는 증거이며, 페이지를 읽는 방문자는 절대 보지 못하는 것입니다. 이 증거는 6곳에 있습니다.

상태와 리디렉션. 각 단계는 자체 상태 코드를 가진 별도의 응답입니다. 일부 가져오기 도구는 요청 전에 http://를 https://로 바꿔 쓰므로, HTTP에서 HTTPS로의 리디렉션은 아예 요청되지 않습니다. 어떤 단계를 유지해야 하는지는 리디렉션 및 URL 정규화 가이드에서 다룹니다.

응답 헤더. X-Robots-Tag, Link, Cache-Control, Vary, 보안 헤더는 모두 HTML 위에서 전달됩니다. 어느 것도 페이지의 텍스트가 아닙니다.

head 태그. 표준 태그, 메타 robots, hreflang, 메타 설명, Open Graph 태그는 <head>에 있으며, 텍스트 변환은 이를 제거합니다.

구조화된 데이터. JSON-LD는 <script> 요소 안에 있습니다. 텍스트 변환은 스크립트를 제거하고, JSON-LD도 함께 사라집니다. 무엇이 들어가야 하는지는 구조화된 데이터와 소셜 메타데이터 가이드에서 설명합니다.

원본 HTML과 렌더링된 HTML. 어떤 가져오기 도구는 페이지를 변환하기 전에 JavaScript를 실행하고 어떤 도구는 실행하지 않으며, 출력은 어느 쪽인지 거의 알려 주지 않습니다. JavaScript 실행 후에만 콘텐츠가 나타나는 페이지는 한 도구에는 완전하게, 다른 도구에는 비어 있게 보일 수 있습니다. 이 차이가 얼마나 자주 나타나는지는 AI 크롤러가 실제로 보는 것에서 측정했습니다.

URL 너머의 파일과 페이지. robots.txt는 요청받지 않는 한 에이전트가 절대 가져오지 않는 별도 파일입니다. Google 문서에 따르면 robots.txt가 페이지를 차단하면 Google은 그 페이지의 noindex를 아예 읽을 수 없으므로, 둘은 함께 확인해야 합니다. 사이트맵, 내부 링크, 중복 URL은 완전히 다른 페이지에 있습니다.

sequenceDiagram
    participant U as 사용자
    participant A as AI 에이전트
    participant F as 가져오기 도구
    participant S as 귀하의 사이트
    U->>A: 이 페이지의 SEO를 검사해 줘
    A->>F: URL 가져오기
    F->>S: GET http://www.example.com/page/
    S-->>F: 301과 Location 헤더
    F->>S: GET https://example.com/page/
    S-->>F: 301과 Location 헤더
    F->>S: GET https://example.com/page
    S-->>F: 200, 응답 헤더, 전체 HTML
    Note over F: 리디렉션 단계, 상태, 헤더, head 태그, JSON-LD 삭제
    F-->>A: 보이는 텍스트를 Markdown으로 전달
    A-->>U: 텍스트만 근거로 한 조언

우리가 지적하는 SEO 문제 대부분은 페이지 텍스트 밖에 있습니다

우리 감사 데이터는 검토의 얼마나 많은 부분이 텍스트 보기가 버리는 것에 달려 있는지 보여 줍니다. 2026년 5월부터 10월 사이에 SEOReport가 감사한 외부 웹사이트 45곳에서 지적된 문제 506건 중 94%는 페이지를 읽는 사람이 절대 보지 못하는 곳에 있었습니다. 응답 헤더, head 태그, 구조화된 데이터, XML 사이트맵, robots.txt, 리디렉션, 페이지 간 관계입니다.

아래 차트는 같은 506건을, 사람이 증거를 보려면 확인해야 하는 한 곳을 기준으로 나눈 것입니다.

텍스트 보기가 남기는 종류의 증거는 '보이는 페이지 콘텐츠'에 해당하는 5.9%뿐입니다. 에이전트가 이를 보려면 무엇을 받아야 하는지를 기준으로 나머지 위치를 묶으면 3개 그룹이 됩니다. HTTP 상태와 헤더, head 태그, 구조화된 데이터를 합치면 506건의 69%입니다. 페이지 자체의 응답 안에 도착하지만 텍스트 변환이 버리는 증거입니다. 텍스트 추출을 개선한다고 되찾을 수 있는 것이 아니며, 응답 자체를 읽어야 합니다. XML 사이트맵, 전체로 읽은 아티클 라이브러리, 페이지 간 관계, robots.txt를 합치면 약 20%입니다. 어떤 단일 페이지의 응답에도 들어 있지 않은 증거입니다. 나머지 5.6%는 페이지나 주소를 한 번 더 봐야 합니다. 원본 HTML 옆의 렌더링된 페이지, 데스크톱 응답 옆의 스마트폰 응답, 또는 페이지 앞의 리디렉션 단계입니다.

같은 표본에서 사이트별 영향도 보입니다. 45곳 모두 페이지의 보이는 텍스트 밖에 있는 문제가 하나 이상 지적되었고, 그중 24곳(53%)은 지적된 문제가 모두 텍스트 밖에 있었습니다. 이 24곳에서는 보이는 텍스트만 검토했다면 지적된 증거를 하나도 보지 못했을 것입니다.

에이전트에게 빠진 증거를 건네는 방법

에이전트는 볼 수 있는 증거에 대해서는 추론을 잘합니다. 해결책은 교환 내용을 에이전트 앞에 놓아 주는 것입니다.

에이전트가 셸을 쓸 수 있다면, 결론을 내리기 전에 다음 명령을 실행하고 원본 출력을 보여 달라고 요청하십시오. 셸이 없다면 직접 실행해 출력을 채팅에 붙여 넣으십시오.

# 1. Every hop, every status, the headers that matter (GET, following redirects)
curl -sL -D - -o /dev/null http://www.example.com/page/ \
  | grep -iE '^(HTTP/|location|x-robots-tag|link|content-type|cache-control|vary)'

# 2. Canonical, hreflang and meta robots tags from the raw HTML
curl -s https://example.com/page \
  | grep -oiE '<link[^>]*rel="(canonical|alternate)"[^>]*>|<meta[^>]*name="robots"[^>]*>'

# 3. How many JSON-LD blocks the raw HTML contains
curl -s https://example.com/page | grep -o 'application/ld+json' | wc -l

# 4. The crawl rules that apply to the page
curl -s https://example.com/robots.txt

답을 믿을 만하게 만드는 습관 세 가지가 있습니다.

• HEAD가 아니라 GET을 사용합니다. 일부 서버는 두 요청에 다르게 응답합니다. 우리 서버도 그랬습니다. 테스트의 첫 단계는 GET 요청에는 301로, HEAD 요청에는 308로 응답했습니다.
• 무엇이 잘못되었는지 묻기 전에 무엇을 받았는지 묻습니다. "보이는 상태 코드, 헤더, head 태그를 나열해 줘"라고 하면 숨은 공백이 드러나며, 어떤 "없음"이 실제로는 "받지 못함"인지 알 수 있습니다.
• HTML이 렌더링되었는지 묻습니다. 에이전트의 도구가 JavaScript를 실행했다면 그 보기는 서버가 보내는 것과 다를 수 있습니다. JavaScript 렌더링 가이드에서 설명하듯 명령 2의 원본 HTML과 비교하십시오.

한 페이지를 완벽히 확인해도 여전히 한 페이지입니다

전체 교환 내용이 앞에 있으면 에이전트는 페이지 하나를 제대로 검토할 수 있습니다. 응답에 담길 수 없는 것은 사이트의 나머지입니다. 사이트맵에 그 페이지가 있는지, 다른 페이지가 그 페이지로 링크하는지, 다른 URL이 그 페이지와 중복되는지, robots.txt가 사이트맵이 알리는 페이지를 차단하는지입니다. 위 표본에서 지적된 문제 다섯 건 중 약 한 건은 어떤 단일 페이지의 응답으로도 보여 줄 수 없는 곳에 있었습니다. 이를 다루려면 매번 같은 방법으로 여러 세션에 걸쳐 많은 페이지에서 작업을 반복해야 하며, 이것이 AI 세션 하나로 웹사이트 전체를 감사할 수 없는 이유의 주제입니다.

SEOReport 전체 진단은 이런 사이트 수준 작업의 상당 부분을 보고서 하나로 처리합니다. 사이트맵에 나열된 페이지를 요청하고, 제출한 주소를 모든 리디렉션 단계까지 추적하고, robots.txt를 읽고, 홈페이지의 원본 HTML을 렌더링된 페이지와 비교합니다. 각 항목에는 증거(상태 코드, 헤더 값, 영향을 받은 URL)가 함께 있으며, 페이지 표본에서 나온 항목에는 살펴본 페이지 수가 명시됩니다. 에이전트는 MCP 서버와 REST API로 이 보고서를 만들고 읽을 수 있으므로, 텍스트가 아니라 사이트의 증거에서 출발할 수 있습니다.

자주 묻는 질문

ChatGPT로 웹사이트 SEO를 검사할 수 있나요?

전달받은 콘텐츠는 무엇이든 검토할 수 있습니다. 제목, 본문, 그리고 도구가 전달한다면 페이지 제목까지입니다. 상태 코드, 헤더, head 태그, 구조화된 데이터도 보는지는 그 순간 사용하는 가져오기 도구에 달려 있으며, 이는 경우마다 다르고 거의 명시되지 않습니다. 먼저 무엇을 받았는지 나열해 달라고 하거나, 위 명령의 출력을 붙여 넣으십시오.

AI SEO 검사 도구는 SEO 감사와 같은 것인가요?

AI SEO 검사 도구는 대개 도구가 반환한 콘텐츠로 페이지 하나를 검토합니다. 감사는 HTTP 교환, robots.txt, 사이트맵, 페이지 간 관계를 읽고, 결과를 검증하고 반복할 수 있도록 항목마다 증거를 기록합니다. 둘은 서로 다른 질문에 답합니다. 하나는 페이지의 글을 검토하고, 다른 하나는 사이트가 크롤러에 무엇을 제공하는지 확인합니다.

표준 태그가 있는데 에이전트는 왜 없다고 했나요?

표준 태그는 <head>에 있고, 텍스트 변환은 이를 제거합니다. 우리 테스트에서도 가져오기 도구는 실제로 있는 표준 태그를 "없음"으로 답했습니다. 그런 조언을 따르기 전에 위의 명령 2나 브라우저의 페이지 소스 보기로 확인하십시오.

에이전트의 가져오기 도구가 JavaScript를 실행하는지가 중요한가요?

콘텐츠나 태그가 JavaScript에 의존한다면 중요합니다. 페이지를 렌더링하는 도구는 원본 HTML에 없는 제목이나 H1을 보고할 수 있고, 렌더링하지 않는 도구는 브라우저에서는 온전히 보이는 페이지를 거의 비어 있다고 보고할 수 있습니다. 원본 HTML과 렌더링된 페이지를 비교하면 검색엔진과 다른 크롤러가 어느 쪽을 먼저 받는지 판가름할 수 있습니다.