내 사이트는 성장했지만 한 페이지가 검색 가시성을 잃었습니다. 세 가지 Search Console 데이터 함정 설명

제가 처음 본 숫자는 좋은 소식이었습니다. Google Search를 통한 제 사이트의 클릭 수가 증가했기 때문입니다.

하지만 다음 숫자가 상황을 복잡하게 만들었습니다. 같은 사이트에 있는 한 아티클이 가장 많은 노출수(impressions)를 잃었기 때문입니다.

저는 Local Waifu를 운영하고 있으며, AI 어시스턴트를 통해 검색 데이터를 검토하는 MCP 커넥터인 GSC Magic을 구축했습니다. 저는 이 도구를 사용하여 오프라인에서 AI 동반자를 실행하는 방법에 대한 아티클을 조사하는 데 사용했습니다.

이것은 그 조사 과정에서 얻은 현장 기록입니다. 끝에 해결책이 제시되어 있지는 않습니다. 대신 제가 발견한 것은 에이전트가 무언가를 설명하려고 시도하기 전에 그 숫자가 어떻게 생성되었는지를 알아야 한다는 좋은 예시였습니다.

저는 연속된 두 개의 28일 기간을 비교했습니다:

속성 수준에서는 클릭 수가 증가하고 있었습니다. 하지만 아티클 수준에서는 노출수가 급격히 감소했습니다. 이 두 가지 관찰 모두 사실이었습니다.

그림 1. 속성과 아티클은 반대 방향으로 움직였습니다. 두 행은 독립적인 스케일을 사용하므로, 막대 하나를 다른 막대에 비교하지 말고 각 행을 시간 경과에 따라 비교해야 합니다.

함정 1: “사이트 클릭”은 데이터를 어떻게 그룹화했는지에 따라 달라졌다

페이지별로 그룹화하여 만든 저의 첫 트래픽 감소 보고서는 사이트 전체에 298 → 472 클릭을 보여주었습니다. 저는 거의 이 수치를 아티클에도 적용할 뻔했습니다.

그런 다음, 그룹화 차원 없이 속성(property)에 대해 Search Console을 조회했습니다:

{
  "site": "sc-domain:localwaifu.com",
  "start_date": "2026-09-02",
...
}

저는 9월 30일~10월 27일에 대해서도 동일한 호출을 반복했습니다. 속성 수준의 결과는 293 → 467이었으며, 298 → 472가 아니었습니다. 두 호출 모두 단일 행을 반환했으며 그 결과가 잘리지 않았다고 보고했습니다.

이것은 극적인 불일치가 아닙니다. 유용한 차이점입니다. 페이지별로 그룹화된 보고서와 속성 수준의 검색어는 총합을 정확히 동일한 방식으로 측정하지 않았습니다. 데이터가 속성별이 아닌 페이지별로 집계될 때 합계가 다를 수 있는 Google 문서를 참고하세요.

만약 제가 이를 기반으로 에이전트 워크플로우(agent workflow)를 구축한다면, 단순히 clicks라는 빈 값만 전달하는 것은 원치 않습니다. 답변은 최소한 다음을 유지해야 합니다:

• 속성 및 정확한 날짜 범위;
• 그룹화 차원(grouping dimension);
• 페이지 필터가 적용되었는지 여부;
• 반환된 행이 잘렸는지 여부.

그렇지 않으면 두 개의 합법적인 숫자가 잘못된 모순으로 변하거나—더 나쁜 경우, 출판된 사례 연구에서 하나가 다른 하나를 조용히 대체할 수 있습니다.

이 조사 나머지 부분에서는 전체 사이트에 대한 속성 수준의 총합과 정확한 기사 URL에 대한 페이지 수준 결과를 사용합니다.

함정 2: 28일 비교가 이상치(outlier)를 숨겼다

기사는 **476회에서 123회로 노출수(impressions)**가 감소했습니다. 이 수치를 곧바로 74% 급락에 대한 헤드라인으로 만드는 것이 유혹적입니다.

저는 하락의 의미를 결정하기 전에 date별로 페이지를 조회했습니다. 일별 시리즈를 확인한 결과, 9월 11일 하루만 142회의 노출수를 기록했음이 밝혀졌습니다. 그 하루가 이전 기간을 상당히 더 강력하게 보이게 만들었습니다.

하지만 전체 변화를 이상치로 치부하는 것도 잘못입니다. 이전 기간의 마지막 7일 동안, 해당 기사는 단지 30회의 노출수만 받았습니다. 다음 네 개의 7일 블록은 각각 24회, 37회, 23회, 그리고 39회를 기록했습니다.

그림 2. 9월 11일 급증이 부드럽게 처리되지 않고 보이는 실제 일별 노출수. 작은 막대들은 중첩되지 않는 7일 블록으로 동일한 데이터를 합산합니다.

유용한 관찰은 단순히 “두 달 사이에 트래픽이 갑자기 감소했다”는 것보다 더 정확합니다. 노출(Visibility)은 이미 첫 번째 기간 말부터 하락 추세였고, 다음 기간에서도 낮은 수준을 유지했습니다. 특이했던 9월 11일의 결과가 기간별 차이를 부각시켰지만, 전체 패턴을 만들어낸 것은 아니었습니다.

이것이 제가 단순히 두 개의 총합에 대한 에이전트 요약본이 아닌 일별 데이터를 원했던 이유입니다. 요약은 어떤 지표가 변했는지를 알려줄 수 있습니다. 하지만 시계열 데이터는 질문 자체가 언제 바뀌었는지를 알려줍니다.

그럼에도 불구하고, 이것만으로는 급증이나 그 이후의 낮은 수준을 유발한 원인을 알 수는 없습니다.

함정 3: 검색어 테이블(query table)이 페이지 총합보다 훨씬 작았다

저는 다음으로 이전 기간에 대해 페이지별로 정확한 기사 URL을 조회했습니다. 결과는 12클릭과 476노출이었습니다.

그런데 이 페이지의 데이터를 검색어별(query)로 그룹화했을 때, 보이는 행들을 모두 합쳐도 겨우 1클릭과 79노출에 불과했습니다. 이후 기간에는 해당 페이지가 4클릭과 123노출을 기록했지만, 보이는 검색어 행들은 단지 1노출에 클릭은 없었습니다.

_그림 3. 이전 기간의 페이지 수준 총합 옆에 표시된 노출 수는 보이는 검색어 행들의 합계입니다. 항목별로 분류되지 않은 나머지 수치는 알려진 손실 키워드 목록이 ""아닙니다."

Google은 사용자 개인정보 보호를 위해 일부 희귀한 검색어는 생략한다고 안내합니다. 또한 이 문서는 행 제한이나 집계 효과를 포함하여 검색어 테이블의 총합이 더 광범위한 총합과 다를 수 있는 다른 이유들도 문서화하고 있습니다.

이러한 구별은 AI 지원 조사에 있어 중요합니다. “어떤 키워드가 353노출을 잃었나요?”라고 질문하기는 쉽습니다. 하지만 사용 가능한 행들은 그 질문에 답할 수 없습니다. 이들은 어느 기간의 페이지 노출 전체를 모두 계산하지 못합니다.

저는 보이는 검색어들을 단서로 사용할 수는 있습니다. 그것들을 감소분의 완전한 회계 장부로 취급하거나, 모델에게 누락된 검색어를 재구성하도록 요청할 수는 없습니다.

마지막 점검: 해당 페이지가 Google의 색인(index)에서 제외되었는가?

색인 수정(indexing fix)을 권장하기 전에, 저는 gsc_inspect_url을 사용하여 해당 URL 자체를 검사했습니다.

결과는 **제출 및 색인됨(submitted and indexed)**으로 보고되었습니다. 크롤링이 허용되었고, 페이지 가져오기(page fetch)가 성공했으며, Google의 선택된 정규화(selected canonical)가 기사 URL과 일치했습니다. 기록된 마지막 크롤은 10월 27일이었습니다.

이 확인을 통해 간단한 설명 하나가 제거되었습니다. 즉, 해당 페이지가 단순히 색인에서 사라진 것은 아니었습니다. 하지만 왜 노출수(impressions)가 감소했는지는 밝혀내지 못했습니다.

6.7에서 7.0으로 이동한 평균 순위 역시 이 문제를 해결해주지 못합니다. 이는 각 기간의 검색에 대한 평균일 뿐이며, 해당 기사가 모든 관련 검색어에 대해 동일한 순위를 유지했다는 증거가 아닙니다.

실제 조사 결과물

저는 기사를 다시 작성하거나, 색인을 요청하거나, 회복을 측정하지 않았습니다. 여기서 성공적인 SEO 수정(SEO fix)을 주장하는 것은 허구일 것입니다.

제가 말할 수 있는 것은 다음 단계가 더 명확하게 정의되었다는 것입니다. 저는 기사의 관련 주제에 대한 검색 결과를 검토하고, 현재 그곳에 나타나는 내용과 비교하며, 유용한 장치(device) 또는 국가별 분할(country splits)을 조사한 후, 또 다른 유사 기간 동안 관찰할 것입니다.

이 워크플로우는 또한 에이전트 답변을 위한 유용한 표준을 제공했습니다:

관찰됨(Observed): 정확한 URL의 노출수와 클릭수가 손실되었습니다.

확인됨(Checked): 여전히 색인되어 있습니다.

제한적임(Limited): 보이는 검색어 행이 페이지 전체를 설명하지 못합니다.

알 수 없음(Unknown): 낮은 가시성(lower visibility)의 원인.

이것은 데이터가 결코 입증하지 못한 알고리즘 업데이트에 대한 자신감 넘치는 단락보다 더 유용한 답변입니다.

저는 GSC Magic을 구축하여 도구들 사이에서 내보내기(exports)를 수동으로 이동할 필요 없이 AI 클라이언트에서 이러한 검사를 실행할 수 있게 했습니다. 이 사례는 또한 경계에 대한 상기시켜주는 역할을 합니다: 에이전트를 실제 데이터에 연결하는 것은 질문을 더 좋게 만들지만, 불완전한 데이터를 완전하게 만들지는 못합니다.

방법론: Search Console 속성 sc-domain:localwaifu.com을 2026년 10월 29일 GSC Magic을 통해 조회함. 기간은 9월 2일29일과 9월 30일10월 27일임. 전체 사이트 수치는 속성 수준의 집계(aggregation)를 사용하며, 기사 수치는 해당 정확한 URL을 사용함. 그래픽은 반환된 데이터를 재구성한 것이며, 앱의 스크린샷이 아님.