Search Console에서 새 글이 색인되지 않았다고 보이면 먼저 요청 버튼을 누르고 싶어집니다. 하지만 운영자가 실제로 해야 할 일은 색인 요청보다 앞에 있습니다. 현재 Google이 알고 있는 상태와 지금 접속 가능한 페이지 상태를 나누어 보고, 차단 신호와 대표 URL, 발견 경로를 차례대로 확인해야 같은 문제를 반복하지 않습니다.
이 글에서 해결할 질문
- URL 검사에서 현재 색인 상태와 live test 결과를 어떻게 나누어 읽는지
- noindex, robots.txt, canonical, sitemap을 어떤 순서로 확인해야 하는지
- 색인 요청이 즉시 색인이나 노출 보장이 아니라는 점을 어떻게 판단해야 하는지
WordPress 버전과 테마는 환경 확인 필요. 메뉴 경로와 점검 절차를 검토했으며 특정 운영 사이트에서 해결됐다고 주장하지 않습니다.
먼저 URL 검사에서 같은 URL을 정확히 입력한다
Search Console 상단의 URL 검사 입력창에는 브라우저 주소창에 실제로 열리는 완전한 URL을 넣습니다. http와 https, www 유무, 끝 슬래시가 다른 주소는 Search Console에서 다른 URL로 다뤄질 수 있으므로 사이트가 대표로 쓰는 canonical 주소와 맞춰 입력합니다.
결과 화면에서 먼저 볼 것은 큰 상태 문구입니다. 페이지가 색인되어 있지 않다면 그 이유가 크롤링 오류인지, 사용자가 선택한 canonical과 Google이 선택한 canonical의 차이인지, noindex 같은 명시적 제외 신호인지 구분합니다. 이 단계에서 원인 문구를 기록하지 않고 색인 요청만 누르면 다음 점검의 기준이 사라집니다.
인덱스 데이터와 live test를 구분한다
URL 검사 화면의 기본 결과는 Google이 마지막으로 확인한 정보를 보여 줍니다. 반면 live test는 지금 Googlebot 관점에서 페이지를 가져올 수 있는지 확인하는 별도 테스트입니다. 최근에 글을 공개했거나 noindex를 제거했다면 두 결과가 다르게 보일 수 있습니다.
live test에서 가져오기 성공, 색인 생성 가능, 렌더링된 HTML 확인이 모두 긍정적으로 보인다면 최근 수정은 반영된 것입니다. 그래도 기존 인덱스 데이터가 바로 바뀌는 것은 아니므로, 현재 문제가 남아 있는지와 Google이 아직 다시 처리하지 않았는지를 분리해 봅니다.
크롤링 가능 여부를 HTTP 응답부터 확인한다
로그아웃 또는 시크릿 창에서 해당 URL을 직접 열어 200 응답으로 본문이 보이는지 확인합니다. 로그인 화면, 404, 5xx, 과도한 리디렉션, 빈 본문은 Search Console 이전에 해결해야 할 문제입니다.
Search Console의 live test가 실패한다면 서버 방화벽, 호스팅 접근 제한, 일시적 장애, 잘못된 리디렉션을 먼저 의심합니다. 이때 사이트 관리자 화면에서 글이 공개 상태인지 보는 것만으로는 충분하지 않습니다. 실제 공개 URL이 인증 없이 열리는지가 기준입니다.
noindex와 robots.txt를 서로 다르게 본다
페이지 HTML의 head 또는 HTTP 헤더에 noindex가 있으면 Google은 그 페이지를 색인하지 말라는 신호로 읽을 수 있습니다. CMS의 검색 노출 설정, SEO 플러그인, 개별 글 설정이 noindex를 만들 수 있으므로 페이지 소스와 Search Console의 페이지 색인 세부 정보를 함께 봅니다.
robots.txt는 크롤러가 어떤 URL을 요청할 수 있는지 안내하는 파일입니다. robots.txt로 HTML 페이지 크롤링을 막으면 Google이 페이지 안의 noindex나 canonical을 제대로 확인하지 못할 수 있습니다. 검색에서 제외하려는 목적이라면 noindex나 인증 제한처럼 목적에 맞는 방식을 써야 하며, 색인시키려는 페이지라면 robots.txt에서 해당 경로를 막지 않아야 합니다.
canonical이 다른 주소를 가리키는지 확인한다
페이지 소스의 canonical은 운영자가 선호하는 대표 URL입니다. 그러나 Google은 기술 신호와 콘텐츠 중복 상태를 보고 다른 canonical을 선택할 수 있습니다. URL 검사에서 사용자 선언 canonical과 Google 선택 canonical을 나누어 확인합니다.
글 URL이 색인되지 않은 이유가 '대체 페이지' 또는 '중복' 계열이라면, 현재 페이지가 다른 글과 충분히 다른지, canonical이 실수로 홈이나 카테고리로 향하지 않는지, 내부링크와 sitemap이 모두 같은 대표 URL을 가리키는지 봅니다. canonical을 바꾼 뒤에도 Google의 재평가는 시간이 걸릴 수 있습니다.
sitemap과 내부링크는 발견 경로다
sitemap.xml에 URL이 들어 있다는 사실은 색인을 보장하지 않습니다. 다만 Google이 새 URL을 발견하고 변경 시점을 이해하는 데 도움이 됩니다. Search Console의 사이트맵 보고서에서 올바른 속성에 제출했는지, 마지막으로 읽은 날짜와 발견된 URL 수가 이상하지 않은지 확인합니다.
내부링크도 중요합니다. 홈, 카테고리, 관련 글에서 새 글로 이동할 수 없다면 sitemap에만 의존하는 고립된 페이지가 됩니다. SEO & 검색 노출 Hub나 관련 가이드에서 자연스럽게 연결되어 있는지 확인하고, 링크가 404나 리디렉션 체인으로 끝나지 않는지 실제로 클릭해 봅니다.
색인 요청 전에 정리할 순서
색인 요청은 수정된 URL을 Google에 다시 크롤링해 달라고 요청하는 기능입니다. Google 문서에서도 요청이 색인 포함을 보장하지 않으며, 여러 페이지는 sitemap을 활용하는 편이 낫다고 설명합니다. 그래서 요청 버튼은 점검을 생략하는 지름길이 아니라 마지막 확인 후 쓰는 재검토 요청에 가깝습니다.
- 브라우저에서 공개 URL이 200으로 열리는지 확인합니다.
- URL 검사에서 기존 인덱스 상태와 원인 문구를 기록합니다.
- live test로 현재 페이지가 색인 가능하게 보이는지 확인합니다.
- noindex, robots.txt, canonical, sitemap, 내부링크를 같은 canonical URL 기준으로 맞춥니다.
- 수정한 내용이 실제 배포 HTML에 반영됐는지 확인한 뒤 필요한 경우 색인 요청을 보냅니다.
잘못된 해결 방법과 주의사항
날짜만 바꾸거나 같은 글을 다른 주소로 복제하는 방식은 문제를 해결하지 못하고 중복 신호만 늘릴 수 있습니다. 색인 요청을 반복한다고 우선순위가 보장되는 것도 아닙니다.
robots.txt에서 막은 뒤 noindex도 넣는 식의 혼합 설정은 의도와 다르게 작동할 수 있습니다. Google이 noindex를 확인하려면 해당 페이지를 크롤링할 수 있어야 하므로, 색인 제외와 크롤링 제한의 역할을 분리해서 결정합니다.
Search Console의 보고서가 늦게 바뀐다고 곧바로 실패로 단정하지 않습니다. 현재 live test와 실제 공개 HTML이 정상이라면, 남은 일은 원인 문구와 수정 시점을 기록하고 다음 크롤링을 기다리는 것입니다. 확인되지 않은 시간이나 순위를 보장하는 표현은 운영 기록에 남기지 않습니다.
운영자용 최종 체크리스트
아래 항목을 모두 확인하면 색인되지 않는 이유를 대부분의 실무 상황에서 좁힐 수 있습니다.
- URL 검사에 입력한 주소가 canonical과 완전히 같은가?
- 로그아웃 상태에서 URL이 200으로 열리고 본문이 보이는가?
- live test에서 가져오기와 색인 가능 여부가 긍정적인가?
- 페이지 HTML 또는 HTTP 헤더에 noindex가 남아 있지 않은가?
- robots.txt가 해당 글 경로를 차단하지 않는가?
- 사용자 선언 canonical과 내부링크, sitemap URL의 호스트와 경로가 일치하는가?
- Google 선택 canonical이 다른 주소라면 중복 또는 품질 문제를 검토했는가?
- sitemap.xml에 공개 URL이 포함되어 있고 Search Console에 올바른 속성으로 제출되어 있는가?
- 수정 후 실제 배포 HTML에 변경 내용이 반영됐는가?
- 색인 요청을 보냈다면 요청 일시와 당시 원인 문구를 기록했는가?
FAQ
Q. URL 검사에서 'URL을 Google에 등록할 수 있음'이라고 나오면 바로 검색에 보이나요? A. 아닙니다. 이는 큰 차단 문제가 감지되지 않았다는 뜻에 가깝고, 실제 색인 포함과 검색 노출은 별도 판단입니다.
Q. 색인 요청을 여러 번 누르면 더 빨라지나요? A. 반복 요청이 즉시 색인이나 우선 처리를 보장하지 않습니다. 먼저 차단 신호를 고치고 중요한 URL만 요청하는 편이 낫습니다.
Q. sitemap에 있으면 반드시 색인되나요? A. 아닙니다. sitemap은 발견과 변경 신호에 도움이 되지만, Google은 접근성, canonical, 중복, 품질 등 여러 신호를 보고 색인 여부를 결정합니다.
Q. robots.txt로 막으면 검색에서 완전히 사라지나요? A. HTML 페이지를 검색에서 제외하려는 목적이라면 robots.txt만으로는 부적절할 수 있습니다. Google 공식 문서는 robots.txt가 주로 크롤링 접근을 관리하는 파일이며, 페이지를 Google에서 제외하려면 noindex나 인증 제한을 사용하라고 설명합니다.
공식 참고 자료
기능·정책 설명을 확인할 때 참고한 1차 출처입니다.
Google Search Console · URL 검사 도구 ↗Google Search Console · 단일 페이지 검사와 문제 해결 ↗Google Search Central · robots.txt 소개 ↗Google Search Central · robots meta tag ↗Google Search Central · canonical 문제 해결 ↗Evidence · 확인 범위
문서·절차의 확인 범위
- Google 공식 문서의 URL 검사, 색인 요청, robots.txt, robots meta, canonical 설명을 기준으로 작성
- 현재 사이트의 SEO & 검색 노출 Hub에 연결되는 공개 Article 구조 사용
- 새 글을 published article 목록과 sitemap 생성 흐름에 포함
확인하지 않음
- 개별 Search Console 속성의 실제 URL 검사 결과
- Google의 다음 크롤링 시각과 색인 결정
- 특정 WordPress 플러그인이 생성하는 noindex 또는 canonical 값
테스트 환경
- WordPress 버전: 환경 확인 필요
- 테마: 현재 환경에서는 확인하지 않음
- 운영 환경 재현: 별도 확인 필요
- 확인 날짜: 2026-09-15
마지막 요약
Search Console에서 색인되지 않은 페이지는 URL 검사 결과, live test, 공개 HTTP 응답, noindex, robots.txt, canonical, sitemap, 내부링크 순서로 확인합니다. 색인 요청은 즉시 색인을 보장하는 버튼이 아니라, 차단 신호를 정리한 뒤 Google에 다시 확인을 요청하는 마지막 단계입니다.