Search Console의 '제출됨'은 완료가 아니었습니다 — 작은 기술 블로그의 SEO 점검 기록
Search Console에서 사이트맵을 다시 제출하자 "사이트맵이 제출됨"이라는 안내가 떴습니다. 그런데 제출 기록 목록에는 "가져올 수 없음"과 발견된 페이지 0이 그대로 남아 있었습니다. 그 안내는 제출을 받았다는 뜻이었지, 처리가 끝났다는 뜻이 아니었습니다.
이번 점검은 Claude Code에서 쓸 수 있는 오픈소스 SEO 점검 도구 모음을 설치하면 검색 유입이 늘까 하는 질문에서 시작했습니다. 결론부터 적자면, 도구보다 먼저 할 일이 있었습니다. 크롤러의 접근과 오류 응답, 사이트맵과 색인 처리 상태를 바로잡고 방문이 전환으로 이어지는지 잴 수 있게 만드는 일입니다. 이 글은 그 과정에서 Search Console과 GA4의 숫자를 읽은 기준, 그리고 '접수'와 '완료'를 나눠 적게 된 이야기입니다.
SEO 도구가 대신 봐 주지 못하는 것
도구가 쓸모없다는 뜻은 아닙니다. 제목, canonical, robots, 구조화 데이터, 내부 링크처럼 반복 점검할 항목을 훑는 데는 유용합니다. 다만 실제 검색 수요 데이터를 주지는 않아서, Search Console과 GA4를 들여다보는 일을 대신하지 못합니다.
0~100점도 도구의 내부 기준일 뿐 Google의 공식 점수가 아닙니다. 1,500단어 같은 분량 기준을 한국어 글에 기계적으로 대지 않기로 한 것도 그래서입니다. Google은 선호하는 단어 수가 없다고 적어 두었고, AI 검색 기능에 노출되려고 별도의 AI용 파일이나 특별한 스키마를 더할 필요도 없다고 안내합니다. 기존 설정과 충돌할 수 있다는 점도 걸려서 설치는 하지 않았습니다.
먼저 확인해 보니 기본 SEO가 없는 사이트도 아니었습니다. 글마다 제목·설명·canonical·OG가 있었고, 구조화 데이터(글은 BlogPosting, 홈은 WebSite)와 서버 렌더링도 이미 있었습니다. 그래서 방향을 '기본 태그 추가'가 아니라 '응답과 처리 상태 점검'으로 잡았습니다. 응답을 고친 이야기, 예컨대 없는 글이 200을 돌려주던 문제는 별도로 정리했습니다.
Search Console 성과 — 작은 숫자 앞에서는 해석을 아꼈습니다
최근 3개월을 직전 3개월과 비교했습니다. 클릭과 노출이 둘 다 조금 늘었지만, 3개월 검색 클릭이 두 자릿수 초반이고 노출은 1천 회 안팎이었습니다. 작은 표본도 전체를 닮았으리라고 믿어 버리는 착각을 트버스키와 카너먼은 작은 수의 법칙이라고 불렀는데, 이번에 숫자를 읽으며 계속 조심한 것이 그 착각이었습니다. 표본이 작을 때 비율이 쉽게 흔들린다는 것은 검색 급락 경보를 만들 때도 따져 봤습니다.
평균 게재순위는 크게 나빠진 것처럼 보였습니다. 하지만 평균은 어떤 검색어로 노출됐는지가 달라지면 개별 순위가 그대로여도 움직입니다. 흔히 구성 효과라고 부르는 착시입니다. 그래서 사이트 전체 순위가 떨어졌다고 읽지 않고, 같은 검색어와 같은 URL끼리 비교하기로 했습니다.
나머지는 결론이 아니라 후보로 적었습니다. 클릭의 대부분이 글 하나에 몰려 있었고, 그 글은 내용 보완과 관련 글 내부 링크를 실험할 후보입니다. 노출은 많은데 클릭이 0인 글은 제목·설명·검색 의도·도입부를 검토할 후보이지, 수요가 높다는 증거는 아닙니다.
덜어 낼 숫자도 있었습니다. 제가 확인하려고 한 site: 검색의 노출은 독자 수요와 떼어 봤고, 검색어 표는 일부가 가려지므로 표의 클릭 합이 전체와 달라도 오류가 아닙니다. 이번 수정은 비교한 기간이 끝난 뒤에 했으니, 효과는 아직 이 숫자로 평가할 수 없습니다.
색인 보고서 — 색인되지 않은 페이지가 전부 오류는 아닙니다
페이지 색인 생성 보고서도 사유별로 나눠 읽었습니다.
- 리디렉션이 있는 페이지: 정규화나 주소 이동이면 정상입니다.
- Soft 404: 앞서 말한 그 문제라, 진짜 404를 돌려주도록 고쳤습니다.
- 찾을 수 없음(404): 삭제가 의도였는지, 대체할 주소가 있는지로 나눠야 다음 할 일이 정해집니다.
- 크롤링됨 - 현재 색인이 생성되지 않음: 글과 페이지네이션, favicon, 사이트맵 파일이 섞여 있어서 일괄 색인 요청은 하지 않았습니다.
수동 조치와 보안 문제 보고서는 둘 다 "감지된 문제 없음"이었습니다.
Search Console 사이트맵 '가져올 수 없음' 앞에서 판단을 미뤘습니다
첫머리의 장면을 조금 더 적겠습니다. 다시 제출하기 전에 URL 검사의 실시간 테스트로 크롤링 허용, 페이지 가져오기 성공, 색인 허용을 확인했습니다. 그런데도 제출한 뒤 목록은 이전 상태 그대로였습니다. 사이트맵 XML 자체를 일반 글처럼 색인 요청하지는 않았습니다.
그래서 이 자리에서 결론을 내리지 않았습니다. 처리가 끝난 뒤에도 실패로 남으면, 그때 Search Console의 상세 오류와 서버의 접근 기록을 나란히 대조할 생각입니다. 예전에 API로 사이트맵을 제출했을 때 받은 204 역시 제출을 받았다는 대답이었지, 그 이상은 아니었습니다.
접수와 완료는 다른 대답입니다
돌이켜 생각해보면 이번 점검에서 Google 쪽에 넘긴 일은 모두 같은 모양이었습니다.
| Search Console에 뜬 문구 | 그 시점에 끝난 일 | 완료를 확인할 곳 |
|---|---|---|
| 사이트맵이 제출됨 | 제출 접수 | 사이트맵 목록의 상태와 발견된 페이지 수 |
| 유효성 검사 시작됨 (Soft 404) | 검증 시작 | 유효성 검사 결과 |
| 우선순위 크롤링 대기열에 추가됨 | 색인 요청 접수 | 그 URL의 실제 색인 여부 |
유효성 검사는 일반적으로 최대 2주가 걸리고 더 오래 걸리기도 한다고 도움말에 적혀 있습니다. 재크롤링은 며칠에서 몇 주가 걸리고, 요청했다고 해서 곧바로 또는 반드시 색인된다는 보장도 없습니다. 개발자의 말로 옮기면 세 문구는 모두 HTTP 202 Accepted에 가깝습니다. 요청은 받아들였지만 처리는 끝나지 않았다는 응답이고, 200 OK처럼 읽으면 안 되는 대답이었습니다.
그래서 작업 기록에 '완료'와 '대기'를 나눠 적었습니다. 제가 끝낸 일과 Google이 처리할 일을 한 칸에 적지 않기 위해서입니다.
GA4 — 숫자보다 속성부터 확인했습니다
GA4에서는 숫자를 보기 전에 속성부터 확인했습니다. 같은 계정에 다른 서비스의 속성이 함께 있어서, 잘못 고르면 다른 서비스의 숫자가 섞일 수 있었습니다.
28일 기준으로는 직접 방문이 가장 많았고 인스타그램 같은 소셜이 그다음이었으며, 구글 검색은 세션이 한 자릿수인 작은 유입원이었습니다. 검색으로 들어온 세션의 참여 시간이 길어 보였지만, 이 표본으로 더 나은 채널이라고 확정하지는 않았습니다. 홈 조회의 비중이 컸고, 특정 도구 페이지의 조회는 소수 사용자의 반복 사용에 크게 좌우됐습니다. 솔직히 말하면, 제 방문을 걸러 내는 방법을 예전에 정리해 두고도 이번 기간에 실제로 걸러졌는지는 아직 검증하지 못했습니다.
Search Console의 클릭과 GA4의 검색 세션도 직접 맞춰 보지 않았습니다. 둘은 집계 기간도 정의도 다릅니다. 두 데이터를 한 리포트에 모아 받는 구조를 만든 적이 있지만, 한 화면에 나란히 놓인다고 같은 잣대가 되지는 않았습니다.
GA4 주요 이벤트가 0이었던 이유 — 클릭은 전환이 아니었습니다
이유는 단순했습니다. 등록된 주요 이벤트가 purchase 하나뿐이었고, 그마저 최근에 수집된 기록이 없었습니다. 그러면 무엇을 주요 이벤트로 삼을지가 남는데, 후보를 하나씩 보니 전환이라고 부를 만한 신호가 없었습니다.
서비스 문의 버튼은 메일 작성 창을 여는 mailto 링크라, 메일이 실제로 보내졌는지 알려 주는 신호가 없습니다. 서비스 페이지로 가는 메뉴 클릭은 진입일 뿐 문의가 아니고, 외부 판매 페이지로 가는 버튼 클릭은 아예 측정되지 않고 있었습니다.
GA4 도움말은 주요 이벤트를 비즈니스에 의미 있는 행동을 재는 것으로 설명합니다. 그래서 클릭이나 양식 노출을 전환으로 임의 지정하지 않았습니다. 그렇게 하면 0은 금방 사라지겠지만, 그 숫자가 세는 것은 문의가 아니라 진입입니다.
접수 성공 이벤트를 보내는 폼도 있었습니다. 다만 봇이 보낸 요청도 성공 응답을 받으면 같은 이벤트가 찍힐 수 있습니다. 그래서 실제 접수 건을 확인한 뒤, 정상적인 접수 번호 형식 같은 조건으로 봇을 걸러 낸 파생 이벤트를 검토하기로 했습니다.
완료 페이지에 도착했다는 사실만으로 성공을 정의하지도 않았습니다. 성공 응답이 곧 진짜 문의는 아니니까요.
다음 점검 일정 — 날짜는 완료 보장이 아니라 점검 시점입니다
그 사이 콘텐츠 쪽에서도 손본 것이 있습니다. 최근 글 세 편의 대표 이미지와 공유 이미지가 기본 이미지로 나가고 있어서, 글마다 이미지를 새로 만들고 본문 이미지에는 설명형 alt와 캡션을 달았습니다. 공개 HTML에서 og:image가 바뀐 것을 확인한 뒤 세 글의 색인 생성을 요청했는데, 이것도 아직 접수 단계입니다. 확인할 날짜는 이렇게 적어 두었습니다.
- 1주 뒤: 사이트맵 처리 상태, Soft 404 유효성 검사 결과, 색인을 요청한 글의 실제 색인 여부
- 2주·4주 뒤: 같은 URL, 같은 검색어, 같은 길이의 기간으로 클릭·노출·CTR 비교
자동 알림은 만들지 않았고, 날짜가 되면 직접 들여다볼 생각입니다. 이 날짜들은 그때까지 끝난다는 보장이 아니라, 확인하러 갈 시점일 뿐입니다.
정리하며 — 접수와 완료를 나눠 적기
이번 점검에서 남은 것은 세 가지입니다. 숫자가 작을수록 해석을 아낍니다. 접수와 완료를 나눠 기록합니다. 그리고 도구가 매기는 점수보다 실제 응답과 측정의 정의를 먼저 확인합니다.
AI SEO 도구를 설치할지에서 시작한 질문은, 결국 무엇이 끝났고 무엇이 아직인지를 나눠 적는 일로 끝났습니다. 다음 점검 날 목록의 상태가 바뀌어 있다면, 그때 그 줄을 '대기'에서 '완료'로 옮겨 적을 생각입니다.
관련 글
검색 트래픽 급락을 '수요 없음'으로 오진한 이유 — 분석 창이 진단을 바꿉니다
최근 28일 데이터만 보고 '이 주제엔 수요가 없다'고 진단했다가, 분석 창을 넓혀 다시 보니 특정 하루에 무너진 절벽이었습니다. 분석 윈도우의 크기가 원인 진단을 통째로 바꾼 오진 복기와, 독립 소스 교차검증·배제법으로 급락 원인을 좁히는 방법을 정리했습니다.
Claude Code에 Google Search Console MCP를 추가하고, OAuth 토큰 만료를 해결한 경험
GA4 MCP를 운영하다 OAuth 토큰이 만료되고, GSC MCP를 추가하면서 gcloud CLI 설치 오류까지 겪었습니다. ADC 토큰 갱신부터 Python 호환성 문제까지, 실전에서 마주친 트러블슈팅 과정을 정리했습니다.
Next.js 사이트맵은 최신 100편만 알고 있었습니다 — 페이지네이션과 ISR 재검증
Next.js 블로그의 사이트맵에 최신 100편만 들어 있었고 에러는 없었습니다. 목록 API를 한 번만 부른 페이지네이션 누락과 여러 경로에서 조용히 빠져 있던 ISR 온디맨드 재검증을 고치고, 주기적 재생성이라는 교란 변수를 피해 저장 직후에 확인한 기록입니다.