측정 범위 설정은 무엇을 기록할지와 무엇을 판정할지를 나누어 정할 때 쉬워집니다. 대부분의 중·대규모 사이트에는 서버 기록을 사이트 전체로 남기는 방식이 맞습니다. 매주 확인하고 보고하는 대상만 핵심 페이지 목록으로 한정합니다.
담당자가 한 주 안에 모든 페이지를 검토할 수 있는 규모이고 변경이 드문 사이트는 다릅니다. 이런 사이트는 전체 페이지를 그대로 판정 대상으로 삼아도 됩니다.
전체 측정과 핵심 한정은 무엇이 다른가요?
두 방식은 데이터를 얼마나 모으느냐로 갈리지 않습니다. 누가 무엇을 얼마나 자주 판단하느냐로 갈립니다. 서버 접속 기록은 요청이 들어오면 페이지 구분 없이 남습니다. 따라서 기록 단계에서 범위를 좁힐 이유는 크지 않습니다.
범위 결정이 실제로 필요한 곳은 판정 단계입니다. 판정은 페이지마다 색인 상태, 대표 URL(canonical, 여러 주소 중 대표로 정한 주소), AI 봇 수집 여부, 인용 여부를 확인하는 일입니다. 확인한 결과로 조치 여부도 정합니다. 판정에는 사람의 시간과 도구의 조회 한도가 들어갑니다. 그래서 「어디까지 기록할까」보다 「어디까지 매번 확인할까」로 묻는 편이 정확합니다.
| 구분 | 전체 판정 | 핵심 한정 판정 | 전체 기록 + 핵심 판정 |
|---|---|---|---|
| 매주 확인하는 대상 | 모든 페이지 | 선정한 페이지만 | 선정한 페이지(나머지는 묶음 합계) |
| 장점 | 구조 문제를 빠짐없이 발견 | 검토 부담이 작고 보고가 간결 | 보고는 간결하고 나중에 다시 볼 기록도 남음 |
| 약점 | 규모가 커지면 검토가 밀림 | 목록 밖 문제를 놓칠 수 있음 | 목록 관리 규칙이 있어야 함 |
| 맞는 상황 | 소규모 사이트, 첫 진단 | 기록 보관이 어려운 환경 | 대부분의 중·대규모 사이트 |
어떤 조건이면 전체로, 어떤 조건이면 핵심으로 한정하나요?
Google 문서는 크롤링 예산 관리 안내가 어떤 사이트를 위한 것인지 밝힙니다. 첫째는 고유 페이지 100만 개 이상이면서 주 1회 정도 바뀌는 사이트입니다. 둘째는 1만 개 이상이면서 매일 바뀌는 사이트입니다. 셋째로, 전체 URL 중 상당 부분이 Search Console에서 「발견됨 - 현재 색인이 생성되지 않음」으로 분류된 사이트도 대상이라고 설명합니다. 같은 문서는 앞의 숫자가 사이트를 분류하기 위한 대략적인 추정이며 정확한 기준이 아니라고 덧붙입니다.
Page indexing report 도움말은 이 상태를 Google이 페이지를 찾았지만 아직 크롤링하지 않은 상태로 설명합니다. 보통은 사이트에 과부하를 줄 것으로 예상해 크롤링 일정을 미룬 경우라고 밝힙니다. Crawl Stats report 도움말은 페이지가 1,000개 미만인 사이트라면 이 보고서를 쓸 필요가 없다고 설명합니다.
이 숫자들은 Google 크롤링을 관리하기 위한 기준이고, 측정 범위를 정하는 기준은 아닙니다. 다만 규모와 변경 빈도에 따라 관리 방식이 달라진다는 점은 측정에도 그대로 적용됩니다. 실무에서는 아래 네 가지 조건으로 판단하는 방법을 권합니다.
| 판단 조건 | 전체 판정이 맞는 경우 | 핵심 한정이 맞는 경우 |
|---|---|---|
| 사이트 규모 | 담당자 한 명이 한 주 안에 모두 검토할 수 있는 수 | 한 주 안에 모두 검토하기 어려운 수 |
| 페이지 생성 방식 | 사람이 한 편씩 작성 | 상품·필터·검색 결과처럼 템플릿으로 대량 생성 |
| 변경 빈도 | 월 단위 이하로 추가·삭제 | 매일 추가·삭제 |
| 측정 목적 | 첫 진단, 구조 문제 탐색 | 정기 모니터링, 경영 보고 |
조건이 서로 엇갈리면 목적을 우선합니다. 예를 들어 가상의 B2B 제조 기업이 제품 페이지 300개로 측정을 시작한다고 하겠습니다. 이 기업은 첫 한 달 동안 전체를 판정 대상으로 삼고, 정기 보고로 넘어갈 때 핵심 목록으로 좁힙니다. 진단을 먼저 하고 모니터링을 나중에 하는 순서입니다.
「발견됨 - 현재 색인이 생성되지 않음」 URL이 많은 사이트라면 첫 진단 단계의 전체 판정이 특히 쓸모가 있습니다. 실무에서는 이 상태의 URL이 어느 템플릿·디렉터리에 몰려 있는지 묶음별로 세어 보는 방법을 권합니다. 그 결과로 핵심 목록에서 뺄 묶음과 넣을 묶음을 정합니다.
공식 도구의 조회 한도는 범위에 어떤 영향을 주나요?
페이지 단위로 판정할 때는 서버 기록과 함께 Search Console, Bing Webmaster Tools 자료를 씁니다. 이 도구들은 모든 페이지를 한꺼번에 보여 주지 않습니다. 각 도구의 한도를 알면 핵심 목록의 적정 크기를 정할 수 있습니다.
| 도구 | 공식 문서의 설명 | 범위 결정에 주는 의미 |
|---|---|---|
| URL 검사 API | 속성(사이트)당 하루 2,000회, 분당 600회 | 하루에 개별 조회할 수 있는 페이지는 속성당 2,000개 이내 |
| 페이지 색인 생성 보고서 | 예시 목록은 문제별 1,000행까지이고, 모든 URL 표시를 보장하지 않음 | 대규모 사이트는 보고서만으로 전체를 판정할 수 없음 |
| 크롤링 통계 보고서 | 예시 URL은 대표 예시일 뿐이고, 일부 요청이 집계되지 않아 사이트 요청 기록과 약간 다를 수 있음 | URL별 판정은 서버 기록으로, 합계 추세는 보고서로 확인 |
| 사이트맵 | 파일 하나에 URL 50,000개 또는 비압축 50MB까지 | 핵심 목록을 별도 파일로 분리할 수 있음 |
| Bing AI 성과 보고서 | 공개 미리보기 단계로 발표된 보고서. URL별 인용 횟수를 제공하고, 그라운딩 검색어(답변 근거를 찾을 때 쓴 문구)는 전체 인용 활동의 표본 | Bing 쪽 인용은 핵심 페이지 단위로 대조할 수 있음 |
Google 문서는 페이지 색인 생성 보고서에서 쓸 방법을 하나 안내합니다. 가장 중요한 페이지만 담은 사이트맵을 만들어 제출하고, 수정 확인을 요청하기 전에 그 사이트맵으로 보고서를 필터링하는 방법입니다. 영향받은 URL의 일부에 대한 확인 요청은 더 빨리 끝날 수 있다고 설명합니다. 확인은 보통 약 2주까지 걸리지만 훨씬 오래 걸리는 경우도 있다고 밝힙니다. 핵심 목록을 사이트맵 파일로 따로 만들면 Google 도구 안에서도 같은 범위로 볼 수 있습니다.
Google 문서에 따르면 AI 개요와 AI 모드 노출은 따로 집계되지 않습니다. Search Console 실적 보고서의 웹 검색 유형 안에 전체 검색 트래픽으로 함께 포함됩니다. 따라서 페이지 필터를 써도 AI 노출만 분리해 볼 수는 없습니다. 실무에서는 핵심 페이지의 웹 검색 실적 전체를 페이지 필터로 확인하고, AI 봇 수집은 서버 기록으로 따로 판정하는 방법을 권합니다.
Bing 발표 글은 이 보고서가 Microsoft Copilot, Bing의 AI 요약, 일부 파트너 연동에서의 인용을 보여 준다고 설명합니다. 평균 인용 페이지 수는 순위나 권위를 나타내지 않는다고도 밝힙니다. 실무에서는 URL별 인용 횟수를 핵심 목록과 대조해, 목록 밖에서 인용된 페이지를 후보로 올리는 데 씁니다.
핵심 페이지는 어떤 기준으로 고르나요?
핵심 목록은 다섯 가지 유형에서 고릅니다. 한 페이지가 여러 유형에 해당하면 선정 사유를 모두 적습니다.
- 성과로 이어지는 페이지: 제품·서비스·가격·문의 페이지처럼 매출이나 문의가 시작되는 페이지입니다.
- 사업 질문에 답하는 페이지: 고객이 AI 서비스에 물을 질문에 직접 답하는 안내·비교·용어 페이지입니다.
- 템플릿 대표 페이지: 같은 틀로 만든 페이지 묶음마다 대표 1~3개를 넣습니다. 템플릿에 생긴 문제는 묶음 전체에 퍼지므로 대표 몇 개로 감지할 수 있습니다.
- 변경 예정 페이지: 개편·주소 이전이 예정된 페이지입니다. 변경 전후를 비교하려면 변경 전에 목록에 넣어야 합니다.
- 이미 신호가 있는 페이지: 서버 기록에서 AI 봇 요청이 꾸준하거나 인용 보고에 나타난 페이지입니다.
목록의 주소는 대표 URL로 적습니다. Google 사이트맵 문서는 같은 콘텐츠에 여러 주소로 접근할 수 있으면 선호하는 주소 하나만 넣으라고 안내합니다. 목록 크기의 상한은 두 값 중 작은 쪽입니다. 하나는 담당자가 한 주 안에 한 행씩 검토할 수 있는 수입니다. 다른 하나는 앞 절의 도구 조회 한도입니다.
핵심 목록 기록 양식
| 대표 URL | 선정 사유 | 묶음(템플릿) | 담당자 | 등록일 | 다음 재검토일 |
|---|---|---|---|---|---|
| 제품 소개 페이지 A | 성과 연결, 질문 답변 | 제품 상세 | 웹 담당 | 등록한 날짜 | 3개월 뒤 |
| 도입 비용 안내 페이지 | 질문 답변, 개편 예정 | 안내 문서 | 마케팅 담당 | 등록한 날짜 | 개편 완료 1개월 뒤 |
범위 결정 회의에서 쓸 질문 목록
- 지난 분기 문의·매출로 이어진 페이지는 어느 것입니까?
- 고객이 AI 서비스에 물을 만한 질문 10개에 직접 답하는 페이지는 어느 것입니까?
- 템플릿으로 만든 페이지 묶음은 몇 종류이고, 묶음별 대표 페이지는 어느 것입니까?
- 앞으로 3개월 안에 개편·이전·삭제할 페이지가 있습니까?
- 이 목록을 매주 검토할 담당자와 투입 시간은 얼마입니까?
핵심 밖 페이지는 어떻게 관리하나요?
Google 문서는 별도 안내가 없으면 Google이 사이트에서 아는 URL의 전부 또는 대부분을 크롤링하려 한다고 설명합니다. 크롤러마다 크롤링 수요는 다르지만 크롤링 용량 한도는 모든 크롤러가 함께 쓴다고도 설명합니다. 이 설명은 Google 크롤러에 관한 것이며, 다른 AI 서비스의 봇에 같은 원리가 적용된다는 뜻은 아닙니다.
실무에서는 핵심 목록으로 한정하더라도 나머지 페이지의 기록을 지우지 않는 방법을 권합니다. 목록 밖 페이지로 요청이 늘어나는 변화는 묶음 합계로만 감지할 수 있기 때문입니다. 그래서 핵심 밖 페이지는 한 행씩 보지 않고 묶음 단위로 관리합니다. 순서는 아래와 같습니다.
- 템플릿·디렉터리별 AI 봇 요청 합계를 월 1회 비교합니다.
- 분기 1회 전체 판정을 실시해 목록 밖에서 생긴 구조 문제를 찾습니다.
- 묶음 안의 특정 페이지에서 AI 봇 요청이 연속으로 늘거나 인용 보고에 나타나면 핵심 목록에 추가합니다.
- 삭제·통합된 페이지나 선정 사유가 사라진 페이지는 목록에서 빼고 사유를 기록합니다.
목록을 바꾼 날짜는 빠짐없이 남깁니다. 목록이 바뀌면 핵심 페이지 합계도 함께 바뀝니다. 추세를 비교할 때는 같은 목록을 쓴 기간끼리 비교합니다.
정리
- 서버 기록이 사이트 전체 요청을 남기고 있는지 담당자와 확인합니다.
- 규모·생성 방식·변경 빈도·목적 네 가지 조건 표로 판정 범위를 정합니다.
- 회의 질문 다섯 개로 핵심 페이지 후보를 뽑아 기록 양식에 적습니다.
- 핵심 목록만 담은 사이트맵을 따로 만들어 Search Console 보고서 필터에 씁니다.
- 분기 1회 전체 판정 일정을 잡고, 목록 추가·제외 기준을 문서로 남깁니다.
참고 자료
- Large site owner's guide to managing your crawl budget (Google Search Central, 확인일 2026-10-20)
- Crawl Stats report (Search Console 도움말, 확인일 2026-10-20)
- Page indexing report (Search Console 도움말, 확인일 2026-10-20)
- Usage limits (Google Search Console API, 확인일 2026-10-20)
- Build and submit a sitemap (Google Search Central, 확인일 2026-10-20)
- AI features and your website (Google Search Central, 확인일 2026-10-20)
- Introducing AI Performance in Bing Webmaster Tools Public Preview (Bing Webmaster Blog, 확인일 2026-10-20)