사이트 성능 최적화, GEO에서는 ‘수집 속도’까지 봐야 합니다
사이트 속도는 이용자 경험에만 영향을 주는 것이 아닙니다. 검색 로봇이 사이트를 얼마나 원활하게 둘러볼 수 있는지와도 관계가 있습니다.
페이지가 100개인 사이트와 1만 개인 사이트는 상황이 다릅니다. 규모가 작은 사이트는 검색 로봇이 비교적 빠르게 전체 페이지를 확인할 수 있습니다. 하지만 페이지가 수천 개 이상이고 서버 응답까지 느리다면 전체 사이트를 다시 살펴보는 데 훨씬 오랜 시간이 걸릴 수 있습니다.
새 글을 올리거나 기존 글을 수정해도 검색 시스템이 이를 늦게 발견한다면 최신 정보를 담았다는 장점을 제대로 살리기 어렵습니다. GEO에서 사이트 성능을 점검할 때는 화면이 빨리 열리는지만 볼 것이 아니라, 중요한 페이지가 얼마나 빠르고 안정적으로 수집되는지도 함께 확인해야 합니다.
사이트 속도가 GEO에서 중요한 이유
검색 로봇은 사이트에 무리를 주지 않는 범위에서 페이지를 요청합니다. 서버가 빠르고 안정적으로 응답하면 원활하게 사이트를 둘러볼 수 있습니다. 반대로 응답이 느리거나 서버 오류가 반복되면 요청 속도가 낮아질 수 있습니다.
이때 함께 알아야 할 개념이 ‘크롤링 예산’입니다.
크롤링 예산은 검색 로봇이 일정 기간 동안 한 사이트에서 수집할 수 있거나 수집하려는 페이지의 범위를 뜻합니다. 모든 사이트에 고정된 숫자가 배정되는 것은 아닙니다. 사이트 규모, 페이지의 중요도, 갱신 빈도, 서버 상태 등에 따라 달라질 수 있습니다.
따라서 성능 개선의 효과는 검색 순위보다 먼저 수집 과정에서 나타날 수 있습니다.
새 글이 더 빨리 발견됩니다.
수정한 내용이 검색 시스템에 반영되는 시간이 줄어듭니다.
오랫동안 방문받지 못했던 페이지가 다시 수집될 수 있습니다.
같은 시간 동안 더 많은 유효 페이지를 확인할 수 있습니다.
다만 속도가 빨라졌다고 검색 순위가 자동으로 올라가는 것은 아닙니다. 콘텐츠의 품질과 관련성이 부족하면 수집만 빨라질 뿐입니다.
사이트 규모에 따른 차이도 큽니다. 페이지가 100개 안팎인 사이트에서는 수집 측면의 효과가 크지 않을 수 있습니다. 반면 상품, 뉴스, 자료실, 지점 페이지가 수천 개 이상 쌓인 사이트에서는 서버 상태와 중복 주소 문제가 전체 색인 속도에 영향을 줄 수 있습니다.
AI 서비스의 정보 수집 방식도 따로 살펴봐야 합니다. 검색엔진의 일반 검색 로봇과 AI 서비스가 사용하는 수집 에이전트는 방문 목적과 패턴이 같지 않을 수 있습니다. 일반 검색 수집이 원활하다고 해서 모든 AI 관련 수집도 같은 상태라고 단정할 수 없습니다.
서버 로그에서 접속 주체를 나누어 살펴봐야 이러한 차이를 확인할 수 있습니다. 다만 AI 수집 에이전트의 방문이 곧바로 AI 답변 노출이나 인용을 보장하는 것은 아닙니다. 수집 여부는 여러 조건 가운데 하나입니다.
▶ 핵심 정리: 사이트 성능 개선은 이용자 경험뿐 아니라 중요한 페이지가 얼마나 빠르고 안정적으로 수집되는지에도 영향을 줍니다. 페이지가 많은 사이트일수록 수집 효율을 따로 확인해야 합니다.
‘사이트가 빨라진다’는 설명만으로는 투자 효과를 구체적으로 보여 주기 어렵습니다. 반면 일평균 수집 페이지 수, 서버 응답 시간, 신규 글의 최초 수집 시점처럼 확인할 수 있는 지표를 제시하면 개선 효과를 비교하기 쉬워집니다.
최신 정보가 중요한 업종이라면 수집 지연은 더 큰 문제가 됩니다. 정책, 가격, 상품 재고, 채용, 행사, 뉴스처럼 시점이 중요한 콘텐츠는 늦게 발견될수록 가치가 떨어질 수 있습니다.
수집 예산은 어디에서 낭비될까?
서버 속도만큼 중요한 것이 불필요한 요청을 줄이는 일입니다.
검색 로봇이 방문하는 주소 중에는 검색 결과에 포함할 가치가 거의 없는 페이지도 있습니다. 이런 주소가 지나치게 많으면 중요한 콘텐츠를 확인하는 데 사용할 수 있는 시간과 요청이 낭비될 수 있습니다.
낭비 유형 | 발생 원인 | 확인 방법 |
매개변수 중복 | 정렬, 필터, 추적 코드에 따라 주소가 계속 생성됨 | 서버 로그에서 ? 뒤에 값이 붙은 주소 집계 |
페이지 나눔 과다 | 목록 페이지가 필요 이상으로 길게 이어짐 | 실제 콘텐츠 수와 목록 페이지 수 비교 |
내부 검색 결과 | 사이트 검색어에 따라 새로운 주소가 계속 생성됨 | 내부 검색 주소의 수집 여부 확인 |
오류 페이지 반복 | 삭제된 주소로 향하는 내부 링크가 남아 있음 | 서버 로그에서 4xx·5xx 응답 비율 확인 |
내용이 거의 없는 목록 | 게시물이 한두 개뿐인 태그·분류 페이지가 다수 존재 | 목록 페이지별 콘텐츠 수 집계 |
리디렉션 연쇄 | 주소 변경이 누적돼 여러 페이지를 거쳐 이동함 | 최종 주소까지 거치는 단계 확인 |
가장 흔한 문제는 매개변수가 붙은 중복 주소입니다.
예를 들어 상품 목록에 가격순, 인기순, 색상, 크기, 브랜드, 지역 등 여러 필터가 있다면 수많은 주소 조합이 만들어집니다. 화면에 표시되는 상품은 비슷하지만 주소만 다른 페이지가 수백 개 또는 수천 개 생길 수 있습니다.
서버 로그를 확인하면 검색 로봇이 실제로 어떤 주소를 방문했는지 알 수 있습니다. 경우에 따라 전체 요청 가운데 상당수가 검색에 포함할 필요가 없는 중복 주소에 사용되고 있을 수 있습니다.
목록 페이지도 살펴봐야 합니다. 게시물 목록이 수백 페이지까지 이어지면 검색 로봇은 내부 링크를 따라 뒤쪽 페이지까지 방문할 수 있습니다. 하지만 뒤쪽 목록이 중복에 가깝거나 독립적인 검색 가치가 없다면 효율을 다시 검토해야 합니다.
그렇다고 일정 번호 이후의 목록 페이지를 무조건 막아서는 안 됩니다. 오래된 콘텐츠를 찾는 유일한 경로라면 차단했을 때 오히려 중요한 문서의 발견이 어려워질 수 있습니다. 내부 링크와 사이트맵 등 다른 발견 경로가 있는지 먼저 확인해야 합니다.
이런 상태에서 서버부터 증설하면 효과가 제한적일 수 있습니다. 불필요한 주소를 그대로 둔 채 처리 능력만 키우면 검색 로봇이 중복 페이지를 더 빠르게 수집하는 결과가 생길 수 있기 때문입니다.
물론 서버 로그를 확보하는 것부터 어려운 사이트도 있습니다.
접속 기록을 아예 저장하지 않거나 보관 기간이 너무 짧을 수 있습니다. 콘텐츠 전송 네트워크인 CDN을 거치면서 원래의 접속 정보가 구분되지 않는 경우도 있습니다.
이때는 로그 분석에 앞서 다음 사항부터 확인해야 합니다.
서버 또는 CDN 로그를 보관하고 있는가?
검색 로봇을 구분할 수 있는 정보가 남아 있는가?
로그 보관 기간이 분석에 충분한가?
개인정보와 보안 정책에 맞게 저장하고 있는가?
검색 로봇을 단순한 사용자 에이전트 문자열만으로 판단하고 있지는 않은가?
사용자 에이전트 문자열은 위조될 수 있습니다. 중요한 분석에서는 공식 문서가 안내하는 확인 방법을 함께 적용해야 합니다.
수집 효율을 높이는 단계별 개선 순서
아래 순서는 비교적 적은 비용으로 확인할 수 있는 작업부터 배치한 것입니다. 사이트의 구조와 운영 목적에 따라 세부 순서는 달라질 수 있습니다.
1단계. 서버 로그를 확보합니다
먼저 검색 로봇이 실제로 방문한 주소를 종류별로 나눕니다.
정상 콘텐츠
매개변수가 붙은 주소
내부 검색 결과
태그와 분류 페이지
리디렉션 주소
삭제된 페이지
서버 오류 페이지
이 작업 없이 시작하면 무엇이 문제인지 알기 어렵습니다. 단순히 속도가 느리다는 이유만으로 서버를 증설하거나 사이트 구조를 바꾸면 비용만 커질 수 있습니다.
2단계. 중복 주소를 정리합니다
정렬, 필터, 추적 코드 때문에 같은 내용의 주소가 여러 개 생기는지 확인합니다.
대표 주소를 알리는 캐노니컬 설정, 내부 링크 정리, 매개변수 처리 방식 개선 등을 함께 검토합니다. 모든 매개변수 주소를 로봇 배제 파일에서 일괄 차단하는 방식은 주의해야 합니다.
robots.txt에서 주소를 차단하면 검색 로봇이 그 페이지 안의 설정을 읽지 못할 수 있습니다. 이미 검색 결과에 포함된 주소를 제외하려면 먼저 해당 페이지를 수집할 수 있게 둔 상태에서 noindex 등 적절한 조치를 적용해야 할 수 있습니다.
즉, ‘수집 차단’과 ‘검색 결과 제외’는 같은 작업이 아닙니다.
3단계. 내부 검색 결과 페이지를 관리합니다
사이트 내부 검색은 검색어마다 새로운 주소를 만들 수 있습니다. 검색어 조합에 따라 사실상 무한한 주소가 생길 수도 있습니다.
내부 검색 결과 페이지가 외부 검색엔진의 검색 결과에 포함될 필요가 있는지 판단하고, 필요하지 않다면 색인 제외와 내부 링크 구조를 정리합니다.
4단계. 오류 주소로 향하는 내부 링크를 없앱니다
삭제된 페이지가 404 응답을 보내는 것 자체는 정상입니다. 문제는 사이트 곳곳에 그 페이지로 향하는 링크가 계속 남아 있는 경우입니다.
검색 로봇은 내부 링크를 따라 같은 오류 주소를 반복해서 방문할 수 있습니다. 메뉴, 본문, 관련 글, 사이트맵에서 잘못된 링크를 찾아 제거하거나 적절한 새 주소로 수정해야 합니다.
5단계. 리디렉션 연쇄를 줄입니다
A 주소가 B로 이동하고, B가 다시 C로 이동하는 구조를 정리합니다. 가능하면 A에서 최종 주소인 C로 바로 연결합니다.
리디렉션이 여러 번 이어지면 서버 요청이 늘고 최종 페이지에 도달하는 시간도 길어집니다. 내부 링크 역시 중간 주소가 아니라 최종 주소를 직접 가리키도록 수정하는 것이 좋습니다.
6단계. 내용이 부족한 태그와 분류 페이지를 정리합니다
게시물이 한두 개뿐인 태그 페이지가 수백 개 생성돼 있다면 통합하거나 검색 노출 대상에서 제외하는 방안을 검토합니다.
단, 이용자가 실제로 탐색하는 중요한 분류 페이지까지 일괄 삭제해서는 안 됩니다. 페이지별 콘텐츠 수, 방문 기록, 내부 링크 역할을 확인한 뒤 결정해야 합니다.
7단계. 사이트맵을 정리합니다
XML 사이트맵에는 실제로 검색에 포함시키고 싶은 대표 주소만 넣는 것이 좋습니다.
다음 주소가 남아 있는지 확인합니다.
삭제된 페이지
오류 응답을 보내는 페이지
리디렉션되는 주소
중복 페이지
noindex가 적용된 페이지
중요하지 않은 매개변수 주소
사이트맵에 주소를 넣는다고 반드시 색인되는 것은 아닙니다. 하지만 운영자가 어떤 페이지를 중요하게 생각하는지 전달하는 데 도움이 되므로 실제 정책과 일치해야 합니다.
8단계. 서버 응답과 페이지 용량을 개선합니다
불필요한 주소를 정리한 뒤 서버와 페이지 성능을 개선합니다.
주요 작업은 다음과 같습니다.
캐시 적용
이미지 크기와 형식 최적화
불필요한 스크립트 제거
데이터베이스 조회 개선
CDN 설정 점검
서버 오류 원인 제거
정적 파일 전송 최적화
이미지는 비교적 적은 비용으로 개선 효과를 얻기 쉬운 항목입니다. 원본 크기의 이미지를 그대로 올리는 사이트라면 화면에 필요한 크기로 줄이고, 적절한 형식과 압축을 적용하며, 필요할 때 불러오는 지연 로딩을 사용할 수 있습니다.
다만 이미지 최적화만으로 서버의 최초 응답 시간이 해결되는 것은 아닙니다. 데이터베이스나 애플리케이션 처리 속도가 문제라면 별도의 개발 작업이 필요합니다.
9단계. 렌더링 방식을 검토합니다
페이지의 핵심 내용과 내부 링크가 자바스크립트 실행 이후에만 나타난다면 수집과 처리 과정이 복잡해질 수 있습니다.
필요에 따라 서버사이드 렌더링, 정적 생성, 동적 렌더링 구조 등을 검토할 수 있습니다. 다만 렌더링 방식 변경은 개발 범위가 크고 부작용도 생길 수 있으므로 가장 먼저 선택할 해결책은 아닙니다.
중복 주소와 오류 링크, 사이트맵부터 정리한 뒤에도 중요한 콘텐츠의 수집과 렌더링 문제가 계속될 때 검토하는 편이 합리적입니다.
앞 단계의 작업은 설정과 링크 수정만으로 처리할 수 있는 경우가 많습니다. 반면 서버 구조와 렌더링 방식 변경은 개발 조직의 일정과 예산이 필요한 작업입니다.
실무에서는 서버를 증설하지 않고도 중복 주소와 오류 링크를 줄이는 것만으로 수집 효율이 개선될 수 있습니다. 처리 능력을 늘린 것이 아니라 불필요한 요청을 줄였기 때문입니다.
무엇을 측정해야 할까?
사이트 성능 작업은 눈으로만 판단하기 어렵습니다. 시작 전에 측정할 항목과 비교 기간을 정해 두어야 합니다.
지표 | 확인 위치 | 기대하는 변화 |
일평균 수집 페이지 수 | 검색 콘솔의 크롤링 통계 | 중요한 페이지의 수집 증가 여부 확인 |
평균 응답 시간 | 검색 콘솔 크롤링 통계·서버 모니터링 | 감소 |
오류 응답 비율 | 서버 로그·크롤링 통계 | 감소 |
검색에 포함된 유효 페이지 수 | 검색 콘솔 페이지 보고서 | 가치 있는 페이지 중심으로 증가 |
신규 글의 최초 수집 시간 | 발행 시점과 서버 로그 비교 | 단축 |
중복·매개변수 주소 요청 비율 | 서버 로그 | 감소 |
AI 관련 수집 에이전트 방문 | 서버 로그 | 변화 추적 |
실무에서 가장 이해하기 쉬운 지표는 새 글의 최초 수집 시간입니다.
콘텐츠를 발행한 시각과 검색 로봇이 처음 방문한 시각의 차이를 기록합니다. 개선 전에는 평균 5일이 걸렸고 개선 후에는 평균 2일이 걸렸다면 변화를 비교하기 쉽습니다.
다만 수집 시점과 색인 시점은 다릅니다. 검색 로봇이 페이지를 방문했다고 해서 반드시 검색 결과에 포함되는 것은 아닙니다. 따라서 신규 글의 최초 방문 시간과 실제 색인 상태를 함께 봐야 합니다.
AI 관련 수집 에이전트도 별도로 나눠 볼 수 있습니다. 하지만 방문 횟수가 증가했다는 사실만으로 GEO 성과가 좋아졌다고 결론 내려서는 안 됩니다.
다음 항목을 함께 살펴야 합니다.
실제 중요 페이지를 방문했는가?
반복해서 같은 주소만 요청하지 않았는가?
서버가 정상 응답했는가?
최신 콘텐츠까지 도달했는가?
주요 질문에서 브랜드나 콘텐츠가 실제로 인용되는가?
수집 페이지 수와 색인 페이지 수도 함께 비교해야 합니다.
수집량은 늘었지만 유효한 색인 페이지 수가 그대로라면 검색 로봇이 중복 주소나 가치가 낮은 페이지를 더 많이 방문하고 있을 가능성이 있습니다. 단순히 숫자가 증가했는지가 아니라 어떤 주소의 방문이 늘었는지를 확인해야 합니다.
개선 효과는 바로 나타나지 않을 수 있습니다. 검색 로봇이 사이트를 다시 방문하고 변경된 구조를 파악하는 데 시간이 필요하기 때문입니다.
사이트 규모와 기존 방문 빈도에 따라 차이가 있으므로 무조건 4~8주가 걸린다고 단정할 수는 없습니다. 다만 너무 짧은 기간만 보고 결론을 내리지 말고, 최소 몇 주 동안 같은 기준으로 전후 변화를 관찰하는 편이 좋습니다.
이용자 경험을 무시해도 된다는 뜻은 아닙니다. 페이지가 빨리 열리면 방문자의 이탈을 줄이고 전환율을 높이는 데 도움이 될 수 있습니다. GEO에서는 여기에 더해 검색 로봇이 중요한 페이지를 안정적으로 발견하고 처리할 수 있는지도 함께 보는 것입니다.
한 번 정리한 뒤에도 다시 점검해야 합니다
사이트는 한 번 정리했다고 계속 깨끗하게 유지되지 않습니다.
새로운 기능을 추가하면 매개변수 주소가 다시 생길 수 있습니다. 광고 캠페인의 추적 코드가 붙은 주소가 내부 링크로 들어갈 수도 있습니다. 콘텐츠를 삭제한 뒤 관련 글과 메뉴에 예전 주소가 남을 수도 있습니다.
따라서 일회성 대청소보다 정기적인 점검이 필요합니다.
페이지가 많은 사이트라면 분기마다 한 번 정도 다음 내용을 살펴보는 방식을 고려할 수 있습니다.
주소 유형별 수집 요청
오류 응답 비율
중복·매개변수 주소 증가 여부
리디렉션 단계
사이트맵 오류
신규 글의 최초 수집 시간
검색 및 AI 관련 수집 에이전트의 방문 변화
성능 개선 효과는 콘텐츠 발행을 계속할 때 확인하기 쉽습니다. 새로 올라오는 글이 전혀 없다면 수집 속도가 빨라져도 눈에 띄는 변화를 찾기 어렵습니다.
가능하면 기술 정비와 콘텐츠 발행을 같은 기간에 진행하고, 새 글이 발행된 뒤 처음 수집되고 색인되기까지 걸린 시간을 기록하는 것이 좋습니다.
수집 효율 진단과 개선 문의
geoseonow.net은 서버 로그를 바탕으로 검색 로봇이 실제로 방문한 주소를 유형별로 분석합니다.
정상 콘텐츠, 중복 주소, 내부 검색 결과, 오류 페이지, 리디렉션, 태그와 분류 페이지 등을 나누어 수집 요청이 어디에 사용되고 있는지 확인합니다. 검색 로봇과 확인 가능한 AI 관련 수집 에이전트도 구분해 살펴봅니다.
진단 결과를 바탕으로 중복 주소, 오류 링크, 사이트맵, 서버 응답, 렌더링 문제의 우선순위를 정하고 실제 설정과 구조 개선까지 이어서 진행합니다.
리퍼블릭미디어는 서울 종로구 새문안로에 있으며 소프트웨어사업자 확인을 보유하고 있습니다. GEO와 SEO의 기술 진단부터 콘텐츠 전략 수립, 원고 제작과 운영까지 한곳에서 진행합니다.
출처 및 참고 자료
Google Search Central, 「대규모 사이트 소유자를 위한 크롤링 예산 관리 가이드」
Google Search Central, 「크롤링 통계 보고서」
Google Search Central, 「자바스크립트 SEO 기본사항」
Google Search Central, 「AI features and your website」
Robots Exclusion Protocol, RFC 9309
리퍼블릭미디어(Republik Media)는 기업이 쌓아 온 경험과 사업 성과를 체계적으로 정리해 오래 활용할 수 있는 지식 자산으로 만드는 기록 설계(Record Design) 콘텐츠 기업입니다.
댓글