서치콘솔 URL 검사, 색인 요청 전에 볼 4가지

2026-09-06 · 글쓴이 딸깍이 아저씨 (Mr. Ddalkak Uncle)

새 글을 발행한 뒤 Search Console에서 색인 생성 요청부터 누르는 경우가 많습니다.
하지만 요청 버튼은 오류를 고치는 버튼이 아닙니다.
페이지를 가져올 수 없거나 noindex가 걸려 있거나 다른 URL이 표준으로 잡혔다면, 먼저 원인을 고쳐야 합니다.
URL 검사 화면에서 네 가지만 순서대로 보면 어디서 막혔는지 훨씬 빨리 찾을 수 있습니다.

실제 사례: 미색인 182개가 모두 오류는 아니었다

2026년 8월 14일 우리 사이트의 Search Console에는 색인됨 65, 색인되지 않음 182가 표시됐습니다. 하지만 사유를 나눠 보니 당장 고칠 후보는 크롤링됨 - 현재 색인 생성되지 않음 29건과 404 18건, 합계 47건이었습니다.

나머지에는 목적지가 맞는 리디렉션 51건, 대표 URL로 합쳐진 대체 페이지 26건, 발견 후 크롤링 순서를 기다리는 주소 56건이 섞여 있었습니다. 그래서 미색인 총합만 보고 모든 URL에 요청 버튼을 누르면 원인은 그대로 남습니다.

URL 검사는 사이트 전체 숫자를 한 번에 고치는 기능이 아닙니다. 중요한 대표 URL 하나를 열어 아래 네 상태를 확인하고, 잘못된 서버 응답·차단·canonical을 먼저 고치는 도구입니다.

1. Google이 페이지를 가져올 수 있는가

첫 번째는 크롤링 가능 여부입니다.
서버 오류, 로그인 요구, 잘못된 리디렉션, 존재하지 않는 주소라면 검색엔진이 내용을 읽을 수 없습니다.

Search Console의 색인된 버전은 Google이 마지막으로 저장한 상태입니다.
방금 수정한 페이지와 다를 수 있으므로 실제 URL 테스트를 함께 봅니다.
실시간 테스트에서도 가져오기에 실패하면 색인 요청을 반복하기보다 서버 응답과 주소부터 고쳐야 합니다.

브라우저에서 잘 열린다는 사실만으로 Googlebot도 같은 내용을 본다고 단정할 수는 없습니다.
모바일 화면, 리디렉션 도착지, HTTP 상태 코드가 의도한 대로인지 같이 살펴보세요.

2. 색인 생성을 막는 설정이 있는가

페이지를 가져와도 색인을 허용하지 않으면 검색결과에 들어가기 어렵습니다.
대표적인 신호는 HTML의 noindex와 HTTP 응답 헤더의 X-Robots-Tag입니다.

robots.txt는 주로 크롤링 접근을 제어합니다.
noindex는 페이지를 읽은 뒤 색인에 넣지 말라는 신호이고요.
두 개를 같은 설정으로 생각하면 원인을 찾기 어렵습니다.

비공개 테스트 페이지에는 의도적으로 차단을 둘 수 있습니다.
반대로 공개 글이라면 배포 템플릿이나 플러그인이 noindex를 남기지 않았는지 확인합니다.
실제 URL 테스트에서 색인 생성 허용 상태가 달라졌다면 수정된 페이지가 다시 처리될 시간을 둬야 합니다.

3. Google이 선택한 표준 URL은 무엇인가

같은 내용이 여러 주소에서 열리면 검색엔진은 대표 주소인 canonical을 고릅니다.
내가 선언한 표준 URL과 Google이 선택한 표준 URL이 다르면, 검사한 주소 대신 다른 주소가 색인될 수 있습니다.

자주 생기는 경우는 다음과 같습니다.

• http와 https가 모두 열림
• www 유무가 섞임
• 목록 필터나 추적 매개변수가 별도 주소를 만듦
• 모바일·인쇄용 주소에 같은 내용이 있음
• canonical이 예전 글이나 홈페이지를 잘못 가리킴

중복 URL을 대표 주소로 모으려는 정상적인 선택이라면 문제가 아닙니다.
하지만 새 글이 엉뚱한 페이지를 표준으로 가리킨다면 canonical, 내부 링크, 사이트맵 주소를 같은 URL로 정리해야 합니다.

4. 마지막 크롤링과 실시간 상태가 언제인가

URL 검사 화면의 결과에는 시점이 있습니다.
마지막 크롤링이 글 수정 전이라면 오래된 제목이나 본문 상태가 보이는 것이 자연스럽습니다.
반면 실제 URL 테스트는 현재 접근 가능한 페이지를 확인하지만, 그 결과가 이미 색인에 반영됐다는 뜻은 아닙니다.

둘을 이렇게 나눠 읽으면 됩니다.

색인 생성 요청은 언제 누를까?

위 네 항목에 문제가 없고 새 글을 공개했거나 중요한 내용을 수정했다면 색인 생성을 요청할 수 있습니다.
Google의 재크롤링 안내는 요청이 검색결과 포함을 보장하지 않으며, 같은 URL을 반복 요청해도 처리 속도가 빨라지지 않는다고 설명합니다.

소수의 새 글이나 수정 글은 URL 검사 도구가 편합니다.
주소가 많다면 한 개씩 요청하기보다 사이트맵을 최신 상태로 제출하는 편이 맞습니다.
발행 후 기본 점검은 글 발행 후 해야 할 5가지와 함께 묶어두면 빠뜨리기 어렵습니다.

요청 뒤에도 색인이 안 되면 콘텐츠까지 본다

기술 오류가 없는데도 색인이 늦을 수 있습니다.
사이트 내부에서 연결되지 않은 고립 페이지, 기존 글과 거의 같은 내용, 검색자가 얻을 새 정보가 적은 페이지는 우선순위가 낮아질 수 있습니다.

관련 글에서 자연스러운 내부 링크를 만들고, 사이트맵에 정확한 URL을 넣고, 중복 문단을 걷어내세요.
오래된 글을 새로 다듬는 경우라면 날짜만 바꾸는 대신 오래된 글 리라이팅 원칙처럼 실제 답의 범위와 근거를 갱신해야 합니다.

자주 묻는 질문

색인 생성 요청을 여러 번 누르면 빨라지나요?

같은 URL을 반복 요청한다고 처리 속도가 빨라지지는 않습니다. 가져오기, 색인 허용, canonical 문제를 먼저 고치고 한 번 요청한 뒤 기다리는 편이 낫습니다.

실제 URL 테스트가 통과하면 이미 색인된 건가요?

아닙니다. 실시간 테스트는 현재 페이지를 가져올 수 있는지 보여줍니다. 검색 색인에 저장되고 검색결과에 노출됐다는 뜻과는 다릅니다.

글이 많을 때도 URL마다 요청해야 하나요?

개별 중요 URL은 검사 도구를 쓸 수 있지만, 많은 주소는 사이트맵 제출과 내부 링크 정리가 더 적합합니다.

글쓴이 딸깍이 아저씨 (Mr. Ddalkak Uncle) · 글감 찾다 지쳐서 직접 도구를 만든 콘텐츠 운영자. 소개 보기

이 글 수정