Google 서치 콘솔 정기 점검, AI 에이전트로 운영하는 6단계 절차

Google 서치 콘솔(Search Console) 정기 점검을 AI 에이전트에게 맡기려면 먼저 점검 범위, 비교 기간, 조회 조건을 정합니다. 이 조건은 회차가 바뀌어도 바꾸지 않습니다.

에이전트는 확정된 데이터만 가져와 정해진 규칙으로 변화를 골라냅니다. 이어서 해당 페이지의 색인 상태를 확인하고 같은 양식으로 보고합니다. 수정 확인 요청과 사이트 변경은 담당자가 맡습니다.

정기 점검 절차는 어떤 단계로 구성하나요?

점검은 여섯 단계로 나눕니다. 단계마다 완료 조건이 있어야 에이전트가 다음 단계로 넘어갈지 판단할 수 있습니다. 조건을 채우지 못하면 그 단계에서 멈추고 보고하게 합니다.

점검 범위와 주기는 무엇부터 정하나요?

첫 단계에서는 어떤 데이터를 어떤 간격으로 비교할지 정합니다. 이 설정이 회차마다 달라지면 수치 변화가 실제 변화인지 조건 변화인지 구분할 수 없습니다.

속성과 검색 유형

Google 문서는 API에서 URL 접두어 속성을 끝에 슬래시를 붙여 지정하고, 도메인 속성은 sc-domain: 형식으로 지정한다고 설명합니다. 같은 사이트라도 두 속성의 집계 범위는 다릅니다. 따라서 점검에 쓸 속성을 하나로 정합니다.

검색 유형은 웹이 기본값이며 이미지, 동영상, 뉴스, 디스커버 등을 따로 지정할 수 있습니다. 실무 기준으로는 웹을 기본으로 점검하고, 유입 비중이 큰 유형만 따로 추가합니다.

주기와 비교 기간

Google의 트래픽 감소 분석 문서는 16개월 범위로 보면 감소를 맥락 속에서 분석하고 해마다 반복되는 패턴인지 알 수 있다고 설명합니다. 비교 탭에서 최근 3개월을 전년 같은 기간과 비교하는 방법도 안내합니다.

주기는 두 가지로 나누는 편이 운영하기 쉽습니다. 주간 점검으로 급한 변화를 찾고, 월간 점검에서 전년 같은 달과 비교합니다.

에이전트 계정의 권한

서치 콘솔 도움말은 제한된 사용자도 실적 보고서를 볼 수 있다고 설명합니다. 수정 확인 같은 도구는 전체 사용자 이상이 쓸 수 있습니다. 실무에서는 에이전트에 조회에 필요한 권한만 주고, 수정 확인 요청과 사이트맵 제출은 담당자 계정으로 하는 방법을 권합니다.

예를 들어 가상의 ○○ 기업이라면 설정표를 다음처럼 씁니다.

• 속성: 도메인 속성 1개
• 검색 유형: 웹
• 주간 점검: 직전 7일과 그 앞 7일 비교
• 월간 점검: 지난달과 전년 같은 달 비교
• 핵심 페이지 목록: 제품 소개 등 20개 주소
• 에이전트 권한: 조회 전용

어느 기간의 데이터를 가져와야 회차끼리 비교할 수 있나요?

두 번째와 세 번째 단계는 조회 기준을 맞추는 일입니다. 같은 날짜를 조회해도 조회 시점과 옵션에 따라 값이 달라질 수 있기 때문입니다.

날짜 기준과 확정 데이터

Search Analytics API 문서에 따르면 날짜는 미국 태평양 시간(PT) 기준입니다. 한국 시간과 날짜 경계가 다르므로 설정표의 기간은 PT 날짜로 적습니다.

API의 dataState 값을 생략하거나 final로 지정하면 확정 데이터만 돌려줍니다. all로 지정하면 아직 집계 중인 최신 데이터도 포함됩니다.

응답에는 first_incomplete_date(집계가 끝나지 않은 첫 날짜)가 올 수 있습니다. 문서는 이 날짜 이후의 값이 눈에 띄게 바뀔 수 있다고 설명합니다.

다만 이 값은 항상 오지 않습니다. 문서에 따르면 dataState를 all로 지정하고 날짜로 묶었을 때만 채워집니다. 요청 기간에 미완성 날짜가 있어야 한다는 조건도 붙습니다. 값이 없다는 사실만으로 확정 데이터라고 판단하지 않게 지시합니다.

실적 보고서 도움말도 최신 데이터는 잠정치이며 바뀔 수 있다고 안내합니다. 정기 비교에는 확정 데이터만 쓰고, 최신 흐름은 별도 참고 항목으로 구분해 보고하게 합니다.

조회 설계와 한도

문서에 따르면 한 번에 받을 수 있는 행은 기본 1,000개, 최대 25,000개입니다. 나머지 행은 startRow로 이어서 받습니다. API는 모든 행이 아니라 상위 행을 돌려준다고 명시합니다.

Google 검색 센터 블로그는 API로 내보낼 수 있는 상한을 사이트별, 검색 유형별로 하루 50,000행으로 설명합니다. 대부분의 속성에는 영향이 없고 일부 대형 사이트에 해당한다고 덧붙입니다.

사용 한도 문서는 페이지나 검색어로 묶거나 거르는 조회의 부담이 크고, 두 가지를 함께 쓰는 조회가 가장 무겁다고 설명합니다. 기간이 길수록, 같은 데이터를 반복해 요청할수록 할당량을 더 씁니다.

그래서 조회 범위는 다음 순서로 좁힙니다.

1. 날짜 차원만으로 사이트 전체 추이를 받습니다.
2. 국가, 기기, 검색 노출 모습별로 나눕니다.
3. 페이지별, 검색어별 조회는 신호가 나온 범위로 한정합니다.
4. 받은 결과는 회차별로 저장하고 같은 조건으로 다시 조회하지 않습니다.

이 단계는 기간, dataState 값, 차원, 필터, 받은 행 수가 조회 기록에 남으면 끝난 것으로 봅니다.

에이전트는 어떤 변화를 이상 신호로 골라내나요?

네 번째 단계에서는 수치를 비교해 담당자가 볼 신호를 고릅니다. 먼저 데이터 구조 때문에 생기는 차이를 이상 신호로 오인하지 않게 규칙을 줍니다.

비교 전에 알려 줄 데이터 특성

• 익명 처리 검색어: Google 블로그에 따르면 일정 수 이상의 사용자가 검색하지 않은 검색어는 표에서 빠지지만 그래프 합계에는 포함됩니다. 검색어별 합이 전체보다 작은 것은 정상입니다.
• 집계 방식: 도움말은 속성 기준 집계에서 같은 검색어의 결과를 한 번으로 세고, 페이지 기준 집계는 주소마다 따로 센다고 설명합니다. 두 기준의 합계를 섞어 비교하지 않습니다.
• 빈 날짜: API 문서는 날짜로 묶으면 데이터가 없는 날은 결과에서 빠진다고 설명합니다. 빠진 날을 표에 명시하게 합니다.
• 평균 게재순위: 트래픽 감소 분석 문서는 절대 순위에 지나치게 집중하지 말라고 설명합니다. 사이트 성과의 척도는 결국 노출과 클릭이라고 안내합니다.

신호별 다음 확인 항목

신호를 판정하는 기준값은 사이트 규모에 맞게 담당자가 정합니다. 예를 들어 주간 클릭이 일정 비율 이상 줄면 신호로 표시하는 방식입니다. 아래 표는 Google의 트래픽 감소 분석 문서가 안내하는 확인 경로를 신호별로 정리한 것입니다.

신호마다 근거 수치, 비교 기간, 나눈 차원이 붙어 있으면 이 단계가 끝납니다. 신호가 없는 회차도 「신호 없음」으로 기록합니다.

색인 상태는 에이전트가 어디까지 확인하나요?

다섯 번째 단계에서는 신호가 나온 페이지와 핵심 페이지의 색인 상태를 조회합니다. 조치 판단에 필요한 사실을 모으는 데까지가 에이전트의 범위입니다.

URL 검사 API로 확인할 항목

URL 검사 API 문서는 검사할 주소가 지정한 속성 안에 있어야 한다고 설명합니다. 또한 현재는 Google 색인에 있는 버전의 상태만 볼 수 있고, 실제 페이지를 실시간 테스트할 수 없다고 명시합니다.

응답에서 기록할 항목은 다음과 같습니다.

• 색인 여부 판정(verdict)과 범위 상태(coverageState)
• robots.txt 차단 여부와 noindex 적용 여부
• 마지막 크롤링 시각과 페이지 가져오기 상태
• 사이트가 지정한 표준 주소와 Google이 선택한 표준 주소

두 표준 주소가 다르면 별도 항목으로 보고하게 합니다. 사용 한도 문서에 따르면 URL 검사는 사이트당 하루 2,000회, 분당 600회까지입니다. 그래서 조회 대상은 신호 페이지와 핵심 페이지 목록으로 한정합니다.

페이지 색인 보고서와 수정 확인

페이지 색인 도움말은 사이트의 모든 주소가 색인될 것이라고 기대하지 말라고 설명합니다. 색인되지 않은 주소가 곧 문제는 아닙니다. 사이트에서 고칠 수 있는 것은 원인이 「웹사이트」로 표시된 문제뿐이라고 도움말은 안내합니다.

도움말은 수정 확인에 대체로 최대 약 2주가 걸리며, 훨씬 오래 걸리는 경우도 있다고 설명합니다. 다시 크롤링하는 대상도 사이트 전체가 아니라 해당 문제가 확인된 주소뿐입니다.

문제는 마지막 사례가 사라진 것으로 표시된 뒤 90일 동안 보고서에 남습니다. 그 90일 동안 다시 나타나지 않으면 문제 목록에서 빠진다고 도움말은 설명합니다.

수정 확인 버튼은 담당자가 누르게 합니다. 에이전트는 회차마다 검증 상태(시작됨, 통과, 실패 등)만 기록합니다. 신호 페이지마다 확인 결과가 기록되면 이 단계가 끝납니다.

보고 양식과 지시 문안은 어떻게 정하나요?

마지막 단계의 목표는 담당자가 보고서만 보고 바로 조치 여부를 정할 수 있게 하는 것입니다. 양식이 매번 같아야 회차끼리 비교할 수 있습니다.

회차 보고 양식

• 회차와 조회 기간(PT 기준), 데이터 상태
• 요약 3줄: 전체 클릭, 노출, 신호 수
• 신호 목록: 신호, 근거 수치, 비교 기간, 색인 확인 결과, 조치 후보
• 조회하지 못한 항목과 그 이유
• 진행 중인 수정 확인의 상태
• 담당자 판단 칸: 조치, 보류, 다음 회차 재확인 중 선택

따라 쓸 지시 문안

1. 설정표의 속성, 검색 유형, 기간으로만 조회합니다. 설정표와 다른 조건이 필요하면 조회 전에 멈추고 보고합니다.
2. 정기 비교에는 확정 데이터만 씁니다. 최신 잠정치는 「참고」로 분리합니다.
3. first_incomplete_date가 없다는 이유만으로 기간을 확정 데이터로 판단하지 않습니다.
4. 검색어별 합계와 전체 합계의 차이는 신호로 보지 않습니다.
5. 신호 페이지는 URL 검사 결과의 색인 여부, 표준 주소, 마지막 크롤링 시각을 기록합니다.
6. 사이트 설정 변경, 사이트맵 제출, 수정 확인 요청은 하지 않고 조치 후보로만 제시합니다.
7. 보고서는 회차 보고 양식의 순서대로 작성합니다.

담당자가 판단 칸을 채우면 한 회차가 끝납니다. 보류한 신호는 다음 회차 신호 목록의 첫 줄에 다시 올리게 합니다.

정리

1. 점검 설정표에 속성, 검색 유형, 주간과 월간 비교 기간, 핵심 페이지 목록을 적고 승인합니다.
2. 에이전트 계정에 조회 범위 권한만 주고, 수정 확인과 사이트맵 제출은 담당자 계정으로 정합니다.
3. 확정 데이터만 쓰는 조회 기록 양식과 신호 판정 기준값을 정합니다.
4. 위 지시 문안과 회차 보고 양식으로 첫 주간 점검을 실행하고, 결과를 담당자가 직접 대조합니다.

참고 자료

• Search Analytics: query (Google for Developers, 확인일 2026-10-20)
• Usage limits, Search Console API (Google for Developers, 확인일 2026-10-20)
• URL Inspection: index.inspect (Google for Developers, 확인일 2026-10-20)
• UrlInspectionResult (Google for Developers, 확인일 2026-10-20)
• Performance report (Search results) (Search Console 고객센터, 확인일 2026-10-20)
• About the performance data (Search Console 고객센터, 확인일 2026-10-20)
• Page indexing report (Search Console 고객센터, 확인일 2026-10-20)
• Managing owners, users, and permissions (Search Console 고객센터, 확인일 2026-10-20)
• Debugging drops in Google Search traffic (Google Search Central, 확인일 2026-10-20)
• A deep dive into Search Console performance data filtering and limits (Google Search Central 블로그, 확인일 2026-10-20)