AI SEO 감사: 세션 하나로 웹사이트 전체를 감사할 수 없는 이유

AI 어시스턴트는 페이지 검토를 잘합니다. 주어진 제목, 소제목, 본문을 읽고 무엇을 바꿔야 할지 설명합니다. 하지만 AI 세션 하나로는 웹사이트 전체를 감사할 수 없으며, 이유는 두 가지입니다. 첫째, SEO 감사에 필요한 증거 대부분은 어시스턴트가 읽는 페이지 텍스트에 없습니다. 응답 헤더, robots.txt, XML 사이트맵, 리디렉션, 페이지 간 관계에 있습니다. 둘째, 사이트가 어느 정도 규모를 넘으면 세션 하나가 한 번에 읽고 비교할 수 있는 것보다 URL이 더 많습니다. 더 큰 이유는 첫 번째이며, 모델이 커진다고 줄어들지 않습니다.

2026년 5월부터 10월 사이에 SEOReport가 감사한 외부 웹사이트 45곳에서 지적된 문제 506건 중 94%는 페이지를 읽는 사람이 절대 보지 못하는 곳에 있었습니다. 이 글은 감사 범위의 산술, 그 증거가 있는 위치, 그리고 어시스턴트가 수정을 시작하기 전에 사이트 수준 진단을 건네는 방식으로 AI를 활용해 웹사이트를 감사하는 방법을 다룹니다. 두 방법을 비교한 AI 스팟 체크가 체계적인 SEO 감사를 대신할 수 없는 이유를 바탕으로 하며, 여기서 다루는 주제는 숫자입니다.

채팅 세션 하나가 다루는 것과 사이트 감사가 기록하는 것

채팅으로 하는 AI 웹사이트 감사는 대개 URL 하나에서 시작합니다. 어시스턴트의 가져오기 도구가 그 페이지를 요청해 받은 내용을 돌려주는데, 흔히 읽기 쉬운 텍스트로 변환된 형태이며, 대화는 그 텍스트를 바탕으로 추론합니다. 체계적인 감사는 한 단계 위인 사이트에서 시작합니다. 호스트 전체를 관장하는 파일을 읽고, 요청하는 URL마다 HTTP 응답을 기록하고, 원본 HTML과 렌더링된 페이지를 비교한 다음, 페이지끼리, 그리고 페이지와 사이트맵을 비교합니다.

URL 하나를 따라가는 경로도 유용한 작업입니다. 다만 여러 경로가 있는 사이트에서 그중 하나일 뿐이고, 단계마다 무언가를 잃을 수 있습니다. 텍스트 변환은 방문자가 읽는 단어는 남기지만 head 태그와 응답 헤더는 버릴 수 있습니다. 그리고 다음 세션은 이번 세션이 읽은 페이지 없이 시작합니다.

어시스턴트에게 감사를 맡기려는 사이트는 얼마나 큰가요?

2026년 5월부터 10월 사이에 SEOReport가 감사한 외부 웹사이트 45곳 중 15곳(33%)은 robots.txt에 명시된 주소나 /sitemap.xml에 XML 사이트맵이 없었습니다. 사이트맵에 URL이 하나 이상 있는 29곳의 사이트맵 URL 수 중앙값은 약 90개였습니다. 하위 4분의 1은 20개 이하, 상위 4분의 1은 440개 초과였고, 가장 큰 상위 10%는 3,000개가 넘었습니다.

이들은 웹 전체의 무작위 표본이 아니라 SEOReport 감사를 위해 제출된 웹사이트이며, 작은 사이트 쪽으로 치우쳐 있습니다. 그래도 편차는 큽니다. 가장 큰 상위 10%의 사이트는 가장 작은 하위 4분의 1보다 150배 이상 많은 URL을 나열합니다. 예상 위치에 사이트맵이 없는 3분의 1의 사이트도 중요합니다. 이런 사이트에는 어시스턴트나 크롤러가 찾아볼 곳에 페이지 목록이 없으므로, 링크를 따라가며 한 번에 하나씩 페이지를 찾아야 합니다.

사이트 전체 AI SEO 감사에는 세션이 몇 개 필요한가요?

아래 표는 측정이 아니라 모델입니다. 위의 사이트맵 크기를, 세션 하나가 전부 읽고도 나란히 비교할 수 있다고 가정한 페이지 수로 나눈 것입니다. 가정은 다음과 같습니다.

• 세션은 사이트맵의 각 URL을 한 번, 전부 읽고, 다른 URL과 비교할 수 있도록 계속 보관합니다.
• 세션당 25페이지와 100페이지의 2가지 용량을 보여 줍니다. 둘 다 예시일 뿐입니다. 실제 용량은 어시스턴트, 가져오기 도구, 페이지의 무게에 따라 달라지며, 우리는 이를 측정하지 않았습니다.
• 사이트맵 URL만 셉니다. robots.txt, 응답 헤더, 리디렉션 단계, 렌더링된 페이지는 작업을 더 늘리므로, 모든 수치는 하한값입니다.

사이트맵이 있는 29곳 중 약 절반은 넉넉한 가정에서라면 사이트맵 전체가 세션 하나에 들어갑니다. 채팅 기반 검토가 가장 타당한 범위가 여기입니다. 중앙값을 넘으면 세션 수가 사이트 규모에 따라 늘어나며, 여러 세션을 합친다고 하나의 감사가 되지는 않습니다.

어시스턴트에 메모리 기능이 있거나 귀하가 메모를 다음 세션에 붙여 넣지 않는 한, 새 세션은 이전 세션이 읽은 페이지 없이 시작합니다. 메모에는 결론이 담깁니다. 나중에 비교하려면 증거 자체가 필요합니다. 12번째 페이지의 정확한 표준 URL, 340번째 페이지의 리디렉션 뒤에 있는 상태 코드 같은 것입니다. 또한 매번 스스로 접근 방식을 고르는 세션은 묶음마다 다른 것을 확인할 수 있으므로, 7번째 묶음과 8번째 묶음은 같은 방식으로 측정되지 않습니다.

SEO 증거 대부분은 붙여 넣은 페이지에 없습니다

세션 수는 더 작은 문제입니다. 아래 차트는 2026년 5월부터 10월 사이에 SEOReport가 감사한 외부 웹사이트 45곳에서 지적된 문제 506건을, 사람이 그 증거를 보려면 확인해야 하는 위치별로 나눈 것입니다. 94%는 페이지를 읽는 사람이 절대 보지 못하는 곳에 있었습니다. 응답 헤더, head 태그, 구조화된 데이터, XML 사이트맵, robots.txt, 리디렉션, 페이지 간 관계입니다.

같은 45곳(2026년 5월–10월) 모두 페이지의 보이는 텍스트 밖에 있는 문제가 하나 이상 지적되었고, 그중 24곳(53%)은 지적된 문제가 모두 텍스트 밖에 있었습니다. 사이트별로 문제가 지적된 증거 위치 수의 중앙값은 5곳이었고, 4분의 1은 6곳 이상이었습니다. 보안 헤더를 완전히 빼고 보더라도, 나머지 지적 사항의 91%가 여전히 보이는 페이지 텍스트 밖에 있었습니다.

위치마다 확인 방법이 다릅니다.

• HTTP 응답. 색인 생성 차단에 관한 Google 문서(2026년 10월 확인)에 따르면 noindex는 X-Robots-Tag 응답 헤더로 보낼 수 있고, 표준 URL 지정에 관한 문서에 따르면 rel="canonical"은 HTTP Link 헤더로 보낼 수 있습니다. 둘 다 페이지 텍스트 어디에도 나타나지 않습니다.
• robots.txt. Google의 robots.txt 문서(2026년 10월 확인)에 따르면 이 파일은 최상위 디렉터리에 있어야 하며, 규칙은 파일을 제공하는 호스트, 프로토콜, 포트에만 적용됩니다. robots.txt와 크롤링 접근 가이드에서 설명하듯 www.example.com과 shop.example.com은 각자 자기 파일을 따릅니다.
• 원본 HTML과 렌더링된 페이지. Google의 JavaScript SEO 문서(2026년 10월 확인)에 따르면 Google은 렌더링된 HTML로 페이지를 색인하고, 표준 URL을 두기에 가장 좋은 곳은 HTML이며, JavaScript로 이를 다른 URL로 바꾸면 안 되고, Google은 noindex를 만나면 렌더링을 건너뛸 수 있습니다. 2026년 5월부터 10월 사이에 SEOReport가 서버의 원본 HTML과 렌더링된 페이지를 비교한 외부 사이트 34곳 중 7곳(21%)은 검색엔진이 먼저 읽는 요소를 JavaScript에 의존했습니다. 제목, 메타 설명, 표준 태그, H1이 JavaScript 실행 후에만 나타나거나, 원본 HTML에 페이지 텍스트가 거의 없었습니다. 변환된 텍스트를 읽는 어시스턴트는 두 버전 중 하나만 보며, 대화에서 어느 쪽인지 밝혀지는 일은 드뭅니다.

페이지 사이에만 존재하는 문제

같은 외부 사이트 45곳(2026년 5월–10월) 중 32곳(71%)에는 어떤 단일 URL에서도 보이지 않는 문제가 하나 이상 있었습니다. 사이트맵을 거기 나열된 페이지와 비교하거나, 페이지끼리 비교하거나, 아티클 라이브러리를 전체로 읽을 때만 드러나는 문제입니다. 아티클 라이브러리를 빼면 45곳 중 28곳(62%)입니다.

예시 사이트에서 이런 증거는 다음과 같은 모습입니다.

# https://www.example.com/robots.txt
User-agent: *
Disallow: /checkout/

# https://www.example.com/sitemap.xml lists
https://www.example.com/checkout/
https://www.example.com/old-services/      (answers 301)

# https://www.example.com/en/services/ declares
hreflang="es" -> https://www.example.com/es/servicios/

# https://www.example.com/es/servicios/ declares
no hreflang link back to /en/services/

각 파일은 따로 보면 올바릅니다. 문제는 함께 읽을 때만 드러납니다.

• 사이트맵이 페이지와 모순됩니다. Google의 사이트맵 문서(2026년 10월 확인)에 따르면 사이트맵이 그 URL의 크롤링과 색인 생성을 보장하지는 않으며, 표준 URL 문서는 사이트맵 포함을 약한 표준 신호로 봅니다. 리디렉션되거나, 차단되었거나, noindex가 있는 URL을 나열하면 엇갈린 신호를 보냅니다. 2026년 5월부터 10월 사이에 SEOReport가 사이트맵 페이지를 가져온 외부 사이트 29곳 중 8곳(28%)에는 리디렉션되거나, noindex가 지정되었거나, robots.txt로 차단된 사이트맵 URL이 하나 이상 있었습니다.
• robots.txt가 noindex를 가립니다. Google 문서에 따르면 robots.txt로 차단된 크롤러는 페이지의 noindex를 절대 보지 못하며, 다른 페이지가 링크하면 URL이 색인될 수 있습니다. 이를 보려면 robots.txt와 페이지를 함께 봐야 하며, 색인 생성 가능성 충돌 분석에서 자세히 다룹니다.
• 돌아오는 링크가 없는 hreflang. 현지화된 버전에 관한 Google 가이드(2026년 10월 확인)는 이렇게 말합니다. "두 페이지가 서로를 가리키지 않으면 태그가 무시됩니다." hreflang 구현 가이드에서 보여 주듯, 이를 확인하려면 두 페이지가 모두 필요합니다.
• 잘못된 대상을 가리키는 표준 태그. 리디렉션되거나 noindex가 있는 페이지를 가리키는 표준 태그는 대상 페이지까지 가져와야만 보입니다.

채팅 세션은 우연히 양쪽을 모두 가지고 있다면 이 중 어느 것이든 잡아낼 수 있습니다. 하지만 세션이 여러 개면 양쪽이 서로 다른 대화에 들어가기 쉽고, 어느 대화에서도 문제가 보이지 않습니다.

AI 웹사이트 감사가 실제로 무엇을 다뤘는지 확인하는 방법

어시스턴트의 감사 결과에 따라 행동하기 전에 네 가지를 물어보십시오. 가져온 URL 목록, 읽은 robots.txt 줄, 홈페이지의 상태 코드와 헤더, 그리고 원본 HTML과 렌더링된 페이지를 비교했는지입니다. 보여 주지 못한다면 감사가 그 부분을 다루지 않은 것으로 보십시오. 그다음 어시스턴트의 URL 목록을 사이트맵과 비교합니다.

같은 증거는 명령 세 개로 직접 모을 수 있습니다.

curl -s https://www.example.com/robots.txt
curl -s -D - -o /dev/null https://www.example.com/ | grep -iE '^(HTTP/|location|x-robots-tag|link)'
curl -s https://www.example.com/sitemap.xml | grep -o '<loc>' | wc -l

두 번째 명령은 일반 GET 요청을 보내고 응답 헤더만 출력합니다. robots.txt에 명시된 사이트맵 주소가 /sitemap.xml과 다르다면 그 주소를 사용하십시오. 사이트맵이 색인 파일이라면 마지막 숫자는 페이지 수가 아니라 하위 사이트맵 수입니다. 어시스턴트가 페이지를 제대로 받았는지도 확인하십시오. 2026년 5월부터 10월 사이에 SEOReport에 제출된 외부 웹사이트 377곳 중 최소 51곳(13.5%)은 자동화된 크롤러가 홈페이지를 평가하지 못하게 했고, 최소 34곳(9%)은 봇 챌린지나 CAPTCHA로 응답했습니다. 어시스턴트의 가져오기 도구도 자동화된 클라이언트이므로, 챌린지 페이지를 만났다면 검토한 것은 그 챌린지입니다. 이 경우는 크롤러를 막는 봇 보호 아티클에서 다룹니다.

어시스턴트에게 사이트 수준 감사를 건넨 뒤 수정을 맡기십시오

어시스턴트는 진단 다음에 오는 작업에 강합니다. 항목 설명, 템플릿 수정 작성, 리디렉션 맵 초안, 제목 고쳐 쓰기 같은 일입니다. 세션에 없는 것은 사이트 수준의 반복 가능한 입력입니다. SEOReport 전체 진단이 바로 그것을 제공합니다. robots.txt와 사이트맵을 읽고, 홈페이지와 함께 사이트맵에 나열되고 내부 링크가 가리키는 페이지 표본을 살펴보며, 요청하는 각 페이지의 HTTP 상태를 기록하고, 홈페이지의 원본 HTML을 렌더링된 페이지와 비교합니다. 나열된 페이지와 모순되는 사이트맵 항목, 없는 페이지로 가는 내부 링크, 거의 같은 아티클처럼 페이지 사이에서만 존재하는 문제도 보고합니다. 각 항목에는 증거와 영향을 받은 URL이 함께 있고, 표본에서 나온 항목에는 살펴본 페이지 수가 명시됩니다. 모든 진단은 정해진 같은 검사를 같은 방식으로 실행하므로, 같은 사이트의 보고서 두 개를 항목별로 비교할 수 있습니다.

에이전트는 MCP 서버와 REST API로 보고서를 만들고, 상태를 확인하고, 모든 항목을 읽을 수 있습니다. 그러면 에이전트의 세션은 진단에서 출발해, 항목 하나씩 수정하는 데 용량을 쓸 수 있습니다. 이 구성은 에이전트 페이지에서 설명합니다.

자주 묻는 질문

ChatGPT로 SEO 감사를 할 수 있나요?

성능 좋은 어시스턴트라면 주어지거나 가져올 수 있는 페이지는 무엇이든 검토할 수 있고, 문제를 명확하게 설명합니다. 사이트 전체 SEO 감사에는 그 외에도 robots.txt, 사이트맵, 응답 헤더, 원본 HTML과 렌더링된 HTML, 페이지 간 비교가 필요합니다. 채팅 감사는 읽은 페이지에 대한 검토로 보고, 그 페이지 목록을 요청하십시오.

AI 모델이 커지면 이 차이가 해소되나요?

용량이 커지면 위 모델에서 세션당 페이지 수가 늘어납니다. 하지만 증거가 페이지 텍스트 안으로 옮겨 오지는 않습니다. 헤더, robots.txt, 페이지 간 충돌은 여전히 의도적으로 가져와 비교해야 합니다. 고정된 방법은 용량만큼 중요합니다. 두 번의 실행 결과가 일치하게 만드는 것이 바로 고정된 방법이기 때문입니다.

작은 사이트라면 AI 세션 하나로 충분한가요?

URL이 20개 안팎인 사이트라면 세션 하나로 모든 페이지를 읽을 수 있습니다. 그래도 robots.txt, 사이트맵, 응답 헤더, 원본 HTML이 눈앞에 있어야 하므로 명시적으로 요청하십시오. 규모는 문제의 쉬운 절반입니다.

사이트맵 전체를 채팅에 붙여 넣어야 하나요?

붙여 넣은 사이트맵은 세션에 URL 목록을 줄 뿐, 페이지 자체나 헤더, 상태 코드를 주지는 않습니다. 어시스턴트는 여전히 URL마다 요청해야 하며, 그러면 위의 세션 산술로 다시 돌아갑니다.