개인 개발자가 Search Console을 볼 때 자주 착각하는 지점

제출은 색인이 아니다

Search Console에서 sitemap을 제출하면 뭔가 끝난 것처럼 느껴진다. 나도 처음엔 그랬다. 제출했으니 이제 기다리면 되겠지! 그런데 제출은 Google에게 위치를 알려준 것이다. 색인 생성, 노출, 클릭은 각각 다른 단계다. 특히 새 사이트는 sitemap이 성공이어도 발견된 페이지가 바로 늘지 않을 수 있다.

또 하나의 착각은 “페이지가 많으면 유리하다”는 생각이다. 색인되지 않는 다국어 URL이 넓게 퍼져 있으면 오히려 관리할 신호만 늘어난다. 처음에는 검증된 핵심 URL을 작게 제출하고, 실제로 색인과 노출이 생기는지 보는 편이 낫다.

숫자를 볼 때 나누는 기준

• - sitemap 성공은 제출 파일을 읽었다는 뜻이다
• - URL 검사 결과는 개별 페이지의 현재 상태다
• - 색인 생성 요청은 우선순위 크롤링 대기열에 넣는 행위다
• - 노출수는 검색결과에 보인 횟수다
• - 클릭수는 제목과 설명이 실제로 선택받은 횟수다

개인 개발자는 시간이 적다. 그래서 모든 문제를 동시에 해결하려고 하면 오히려 아무것도 안 끝난다. 먼저 404 sitemap을 없애고, canonical host를 고정하고, 실제로 제출할 URL 목록을 줄이는 식으로 우선순위를 잡아야 한다. 재미없는 일인데... 이걸 안 하면 다음 작업이 계속 흔들린다.

bobob.app에서 다시 나눈 표

이번에는 sitemap을 줄이는 쪽을 먼저 택했다. 짧은 제작 메모 100개를 전부 제출하면 숫자는 커 보이지만, 대표 글이 묻힌다. 대표 글, category hub, Play, trust 성격의 핵심 페이지 중심으로 줄이면 관찰할 신호도 선명해진다.

실제 운영 로그에서 분리한 것

Search Console을 볼 때 가장 위험한 순간은 성공처럼 보이는 단어를 만났을 때다. `성공`, `제출됨`, `요청됨`은 다 좋은 말처럼 보이지만 서로 다른 단계다. 그래서 bobob.app 운영 로그에는 아래처럼 분리해서 적는다.

이 표는 겁을 주려고 만든 게 아니다. 반대로 불필요한 수정을 줄이려고 만든 표다. 발견 수가 맞기도 전에 제목을 고치고, URL 검사 결과가 바뀌기도 전에 sitemap 범위를 또 넓히면 어느 변경이 영향을 줬는지 모른다. 작은 사이트는 데이터가 적기 때문에 더 천천히 나눠 봐야 한다.

다음 관찰 순서

Search Console을 볼 때는 바로 결론을 내리지 않는다. 먼저 `/sitemaps/en`을 새로 제출하고, discovered pages가 새 URL 수와 맞는지 본다. 그 다음 대표 pillar 글 몇 개를 URL 검사로 확인한다. 그 뒤 며칠을 두고 indexed pages, impressions, indexing reason 변화를 본다. 이 사이에 글을 또 대량으로 늘리면 어느 변경이 영향을 줬는지 알 수 없다.

2026-07-03 기준으로는 `/sitemaps/en`의 live URL 수와 발견 수가 77로 맞았다. 이것은 꽤 중요한 진전이었다. 하지만 그날 확인한 대표 pillar 글은 아직 `크롤링됨 - 현재 색인이 생성되지 않음` 상태였다. 즉, Google이 페이지를 가져올 수 있고 sitemap과도 연결되어 있지만, 검색 색인에 들어갔다고 말할 수는 없었다. 여기서 바로 “또 글을 20개 늘리자”로 가면 안 된다.

2026-07-07에는 상황을 한 줄 더 나눠 적었다. `/sitemaps/en`은 다시 제출됐고 Search Console sitemap row는 `성공`, discovered pages `85`, last read `2026. 7. 7.`까지 맞았다. 반대로 Page indexing report는 아직 `2026. 6. 30.` 스냅샷이었고 indexed pages `1`, not indexed pages `32`였다. 같은 Search Console 안에서도 sitemap report와 page indexing report의 갱신 시간이 다르다. 그래서 “sitemap은 오늘 읽혔다”와 “page indexing 숫자는 아직 지난 스냅샷이다”를 같은 성공/실패로 섞지 않는다.

이 표가 있으면 “오늘 왜 숫자가 그대로냐”를 조금 덜 뭉개서 볼 수 있다. 오늘의 할 일은 sitemap 파일을 다시 흔드는 것이 아니라 Page indexing report 날짜가 바뀌는지, `크롤링됨 - 현재 색인이 생성되지 않음` URL이 줄어드는지, Search performance의 impressions가 어느 페이지와 쿼리로 잡히는지 보는 일이다.

실제로는 Search Console 안에서도 날짜 네 개를 따로 적어야 한다. 같은 화면 묶음처럼 보여도 데이터가 같은 속도로 새로고침되지 않는다.

여기에 한 줄을 더 넣는다. Search Console이 맞는 Google 계정과 맞는 property에서 열린 화면인지다. `이 속성에 액세스할 수 없습니다`가 보이면 Page indexing이 나쁜 것이 아니라 관찰 계정이 틀린 것이다. 패스키나 본인 확인 화면에서 멈춘 것도 마찬가지다. 이 상태에서는 sitemap을 다시 제출하지 않고, 색인 실패라고 적지도 않는다. 먼저 유효한 계정/property 관찰을 복구해야 한다.

그래서 언제 업데이트를 기다리나

Search Console 숫자가 안 움직이면 제일 먼저 하고 싶은 말은 "대체 언제 업데이트되나"다. 이 질문도 한 줄로 답하면 안 된다. Google의 URL 검사 도움말은 색인 요청을 넣어도 처리가 1-2주 걸릴 수 있고, 누락 페이지 도움말은 크롤링과 색인 처리에 며칠에서 몇 주가 걸릴 수 있다고 설명한다. 그래서 bobob.app에서는 같은 날 sitemap을 또 흔들기보다 아래 표처럼 기다릴 줄을 정한다.

이 기준이면 2026-07-07 같은 날에는 결론이 꽤 차갑다. `/sitemaps/en`은 읽혔다. live sitemap도 85개다. IndexNow도 85개를 다시 받았다. 하지만 Page indexing report는 아직 2026. 6. 30. 화면이고, Blog/Play/tool 대표 URL은 색인 완료가 아니다. 이 상태에서 하루 안에 같은 sitemap을 다시 제출하거나 제목을 갈아엎으면, 다음 숫자가 움직여도 무엇 때문에 움직였는지 모른다.

그래서 기다림은 포기가 아니라 비교 가능한 상태를 유지하는 작업이다. 오늘 고칠 수 있는 것은 공개 URL의 최종 응답, sitemap 포함 여부, robots와 canonical, 본문 밀도, 내부 검색 흐름이다. Search Console의 리포트 날짜와 실제 색인 판단은 외부 시스템이 다시 읽은 뒤에야 비교할 수 있다.

며칠 기다릴 때 손대지 않는 것

• - `/sitemaps/en` 범위를 매일 바꾸지 않는다. 제출 표면이 계속 바뀌면 discovered pages 비교가 흐려진다.
• - 대표 글 제목과 설명을 근거 없이 계속 바꾸지 않는다. impressions와 click이 충분히 쌓이기 전에는 판단이 어렵다.
• - archive/noindex 후보를 갑자기 다시 제출하지 않는다. 얇은 메모가 대표 글 옆에 섞이면 품질 신호가 흐려진다.
• - URL 검사 요청을 했다고 바로 성공으로 기록하지 않는다. 요청은 요청이고 색인은 색인이다.
• - Bing이나 Naver에서 보이는 등록 화면도 indexing proof로 쓰지 않는다. 제출, 수집, 색인, 노출을 따로 적는다.
• - Naver에 오래된 locale sitemap row가 남아 있으면 그 row가 404인지, 축소된 `/sitemaps/en`으로 308 되는지부터 확인한다.

가만히 있는 것도 운영이다. 손을 놓는다는 뜻은 아니다. 관찰 기간에는 live sitemap, feed, robots, canonical, h1, title, description 같은 기본 표면을 하네스로 확인하고, 외부 도구에서 바뀐 신호만 따로 기록한다. 코드나 콘텐츠를 계속 뒤집는 대신 비교 가능한 상태를 유지하는 쪽이 더 어렵다.

이번에는 Naver도 같은 방식으로 적었다. Search Advisor에는 `26.06.16`에 제출된 오래된 `sitemaps/ar`, `sitemaps/th`, `sitemaps/zh-CN` 같은 locale sitemap row가 남아 있었고, 최신 `/sitemaps/en` row는 화면에 추가되지 않았다. 그래서 route 쪽에서는 known retired locale sitemap path를 404로 두지 않고 `/sitemaps/en`으로 308 redirect하게 했다. 이것도 색인 proof가 아니다. 다만 오래된 외부 webmaster row가 죽은 XML route를 계속 보지 않게 하는 crawl-surface cleanup이다.

Bing, IndexNow, Naver는 다른 줄로 본다

Google 쪽 Page indexing report가 늦게 움직이는 동안 다른 webmaster 화면도 같이 보고 싶어진다. 이때도 같은 규칙을 쓴다. 제출 성공, dashboard 접근, public search 결과, 수집 상태를 한 줄로 섞으면 다음 판단을 못 한다.

그래서 IndexNow를 다시 보냈다는 말은 Bing 쪽 발견 신호를 갱신했다는 뜻까지만 쓴다. Naver에서 HTTPS가 정상이라고 보이는 것도 site access와 redirect 쪽 proof일 뿐이다. `사이트맵을 찾을 수 없습니다`가 남아 있으면 그 줄은 실패 확정이 아니라 다음 관찰 항목이다. 반대로 그 줄이 사라져도 바로 색인 완료가 아니다. collection, index, impressions를 따로 적어야 한다.

바로 해보기

오늘 일감 세 칸 보드는 들어오는 일을 막힌 일, 시간 잡기, 오늘 판 밖으로 나누는 게임이다. Search Console에서도 같은 방식이 필요하다. 모든 경고를 같은 무게로 보면 중요한 신호를 놓친다.

작은 사이트에서 특히 조심할 점

큰 사이트라면 일부 URL이 늦게 읽혀도 전체 신호가 남는다. 작은 사이트는 다르다. 제출 URL이 수십 개뿐이면 noindex 후보 하나, 중복 제목 하나, 너무 짧은 글 하나가 더 크게 보인다. 그래서 Search Console 숫자를 볼 때는 “왜 아직 색인이 안 됐지”보다 “내가 제출한 표면이 정말 대표 세트인가”를 먼저 묻는 편이 낫다.

이번 정리는 그 질문에서 시작했다. 짧은 메모를 모두 제출하는 대신 대표 글과 Play, category hub로 줄이면 관찰할 숫자는 작아지지만 판단은 쉬워진다. 이 상태에서 며칠을 둬야 다음 변경의 효과를 읽을 수 있다.

내가 다음에 볼 질문

다음 확인에서는 단순히 “색인됐나?”만 보지 않는다. 먼저 `/sitemaps/en` 발견 수가 계속 현재 URL 수와 맞는지 본다. 그 다음 대표 pillar 글 두세 개의 URL 검사 사유가 `크롤링됨 - 현재 색인이 생성되지 않음`에서 바뀌는지 본다. 이어서 impressions가 늘었을 때 어떤 쿼리와 어떤 페이지가 보였는지 확인한다. 마지막으로 Bing Webmaster나 Naver Search Advisor에서 추천, 수집, 색인 관련 신호가 따로 생겼는지 본다.

이 순서를 지키면 “무언가 안 됐다”가 아니라 “발견은 됐고, fetch도 됐고, 색인 판단만 아직이다”처럼 상태를 나눌 수 있다. 그 차이가 크다. 상태를 나눠야 고칠 것도 나뉜다. sitemap 문제면 sitemap을 고치고, 콘텐츠 깊이 문제면 대표 글을 보강하고, 제목 선택 문제면 충분한 노출 데이터가 쌓인 뒤 제목과 설명을 본다. 한 번에 다 고치려는 마음이 제일 위험하다.