블로그를 운영하다 보면 가장 답답한 순간 중 하나가 새 글을 발행했는데도 Google에 전혀 잡히지 않는 상황입니다. Search Console에서는 Page is not indexed라고 나오고, site: 검색에서도 보이지 않는데, 막상 브라우저에서는 글이 잘 열리니 어디가 문제인지 감이 안 옵니다. 이때 흔히 하는 실수가 두 가지 있습니다. 하나는 원인도 모른 채 색인 요청 버튼만 계속 누르는 것, 다른 하나는 Search Console의 큰 그래프만 보고 불안해하는 것입니다.
Google 공식 문서를 기준으로 보면, 새 글 색인 문제는 대체로 몇 가지 축으로 나뉩니다. Google이 아직 그 URL을 모르는 경우, 크롤링은 했지만 색인하지 않은 경우, noindex나 robots 규칙 때문에 접근이 제한된 경우, canonical이나 중복 구조 때문에 다른 URL을 대표로 본 경우, 또는 단순히 기다려야 하는 경우입니다. 중요한 건 이 원인들이 Search Console에서 비슷해 보여도 실제 해결 순서는 다르다는 점입니다.
그래서 저는 새 글이 안 잡힐 때 무작정 추측하지 않고, 항상 1개 URL을 기준으로 원인을 좁혀갑니다. 이 글에서는 그 순서를 그대로 정리해보겠습니다.
새 글이 Google에 잡히지 않을 때 무엇부터 확인해야 하는지 순서대로 정리합니다. URL Inspection, noindex, robots.txt, canonical, sitemap, 내부 링크를 차례대로 좁혀가며 원인을 구분하는 방식입니다. 핵심 1 핵심 2 핵심 3새 글이 색인되지 않을 때 직접 확인하는 순서
먼저 기억할 것: 색인 요청은 만능 해결책이 아니다
가장 먼저 할 일은 URL Inspection으로 그 URL 하나를 보는 것
Test live URL로 지금 접근 가능한지 확인한다
먼저 기억할 것: 색인 요청은 만능 해결책이 아니다
Google Search Central은 URL Inspection 도구로 개별 URL의 크롤링을 요청할 수 있다고 설명합니다. 하지만 같은 문서에서, 크롤링 요청이 즉시 또는 반드시 검색 결과 포함으로 이어지는 것은 아니라고 분명히 적고 있습니다. 또 동일 URL을 여러 번 재요청한다고 더 빨라지지도 않는다고 말합니다.
즉 초반에 꼭 기억해야 할 기준은 이렇습니다.
- 색인 요청은 “힌트”이지 강제 명령이 아니다
- 반복 제출은 속도를 보장하지 않는다
- 우선 원인을 확인한 뒤 요청해야 한다
이 기준을 먼저 잡아두면, 새 글이 안 잡힐 때 괜히 버튼만 여러 번 누르는 일을 줄일 수 있습니다.
1. 가장 먼저 할 일은 URL Inspection으로 그 URL 하나를 보는 것
Search Console의 Page Indexing report는 사이트 전체 추세를 보는 데 좋지만, 개별 글 문제를 해결할 때는 URL Inspection이 더 빠릅니다. Google 도움말도 특정 URL의 인덱스 상태를 보려면 URL Inspection을 쓰라고 안내합니다.
여기서 제가 가장 먼저 확인하는 건 아래 네 가지입니다.
Page is not indexed인지, 아니면 아예URL is unknown to Google인지- 마지막 크롤링 날짜가 있는지
Test live URL이 성공하는지- Google이 본 canonical 정보가 무엇인지
Google 문서에 따르면 URL Inspection에서 Page is not indexed: URL is unknown to Google이 보이면, Google이 그 URL을 아직 본 적이 없다는 뜻입니다. 이 경우엔 크롤링 유도 신호를 먼저 봐야 합니다. 반대로 이미 크롤링했는데 색인하지 않은 경우라면 noindex, 중복, 품질, canonical 같은 쪽을 봐야 합니다.
2. Test live URL로 지금 접근 가능한지 확인한다
URL Inspection 도움말은 새 글 문제를 볼 때 live test를 명확히 구분해서 보라고 말합니다. live test는 현재 웹에서 그 페이지에 접근 가능한지 보는 도구이고, 인덱스 상태와는 별개입니다. Google은 live test가 색인을 보장하지 않으며, 품질이나 수동 조치 같은 모든 조건을 검사하지도 않는다고 설명합니다.
그래도 이 단계가 중요한 이유는 명확합니다. live test가 실패하면 그 다음 단계는 거의 다 의미가 줄어듭니다.
확인 포인트는 보통 이렇습니다.
- 로그인 없이 접근 가능한가
Page fetch가 성공하는가- HTML이 정상적으로 내려오는가
- 리다이렉트가 이상하게 꼬이지 않았는가
특히 Google 문서에는 live test가 리다이렉트가 있는 경우 최종 대상만 테스트할 수 있고, 중복이나 canonical 문제는 live test에서 충분히 드러나지 않을 수 있다고 적혀 있습니다. 그래서 이 단계는 “접근 가능성 확인”으로 생각하는 편이 맞습니다.
3. noindex가 있는지 가장 먼저 찾는다
새 글이 안 잡히는 가장 명확한 이유 중 하나가 noindex입니다. Search Console Page Indexing 도움말은 Google이 noindex가 붙은 페이지를 색인하지 않는다고 설명하고, URL Inspection에서 Indexing allowed? 항목으로 확인할 수 있다고 안내합니다.
이건 정말 우선순위가 높습니다. noindex가 있으면 다른 점검은 대부분 뒤로 밀립니다.
직접 확인할 때는 Search Console 말고 HTML도 같이 봅니다.
curl.exe https://www.example.com/blog/new-post-not-indexed | Select-String "noindex"
또는 응답 헤더에서 X-Robots-Tag를 볼 수도 있습니다.
curl.exe -I https://www.example.com/blog/new-post-not-indexed
Google 문서도 HTML 소스나 응답 헤더에서 noindex를 찾아볼 수 있다고 설명합니다. 특히 템플릿에서 초안 페이지에만 넣으려던 noindex가 실제 발행 글에도 남아 있는 경우가 꽤 자주 생깁니다.
이 레포도 아직 작성되지 않은 글 페이지에는 noindex가 들어가도록 설계되어 있습니다. 이런 구조는 좋지만, 발행 상태로 전환된 뒤에도 noindex가 남아 있지 않은지는 꼭 확인해야 합니다.
4. robots.txt를 잘못 의심하지 말고, 정확히 해석한다
robots.txt는 자주 오해되는 파일입니다. Google Search Central은 robots.txt가 크롤러가 어떤 URL에 접근할 수 있는지를 알려주는 파일이라고 설명하면서, 동시에 이것이 페이지를 Google에서 숨기는 메커니즘은 아니라고 분명히 말합니다. 페이지를 Google에서 빼고 싶다면 noindex나 인증이 필요합니다.
이 말은 색인 문제를 볼 때 두 가지 의미가 있습니다.
- robots.txt가 막고 있으면 Google이 크롤링 자체를 못 할 수 있다
- robots.txt가 열려 있다고 해서 색인이 보장되지는 않는다
즉 robots는 “충분조건”이 아니라 “가능 조건”에 가깝습니다.
확인할 건 단순합니다.
- 해당 경로가
Disallow에 걸려 있지 않은가 - sitemap 자체가 robots에 의해 막히지 않았는가
특히 Google의 Sitemaps report 문서에는 sitemap이 robots.txt에 막혀 있으면 Google이 가져오지 못한다고 적혀 있습니다. 그래서 새 글이 안 잡힐 때는 글 URL뿐 아니라 /sitemap.xml 자체도 같이 점검하는 편이 좋습니다.
5. canonical이 다른 URL을 가리키고 있지 않은지 본다
이 단계는 생각보다 많이 놓칩니다. Google의 canonical 문서는 리다이렉트, rel="canonical", sitemap을 함께 써서 대표 URL을 명확히 할 수 있다고 설명하고, 내부 링크도 canonical URL로 일관되게 연결하라고 권장합니다.
새 글이 색인되지 않는다고 느끼는 상황 중 일부는 사실 “색인이 안 된 것”이 아니라 “다른 URL이 canonical로 선택된 것”일 수 있습니다. 예를 들어:
www와 non-www가 섞여 있다- 쿼리 파라미터 버전이 있다
- 같은 글이 카테고리 경로와 기본 경로 둘 다 열린다
- canonical이 실수로 다른 글을 가리킨다
Google 도움말도 URL Inspection에서 선언된 canonical 정보를 보여주며, Google이 항상 사용자의 선호 canonical을 선택한다고 보장하지는 않는다고 설명합니다.
그래서 저는 새 글이 안 잡히면 아래를 같이 봅니다.
curl.exe https://www.example.com/blog/new-post-not-indexed | Select-String 'rel="canonical"'
여기서 보고 싶은 결과는 이 글 자신을 가리키는 canonical입니다.
<link rel="canonical" href="https://www.example.com/blog/new-post-not-indexed" />
만약 다른 호스트나 다른 경로를 가리키고 있다면, Google 입장에서는 지금 내가 보고 있는 URL이 대표가 아닐 수 있습니다. 이 경우에는 www, non-www, canonical 정리 글을 함께 보면서 구조를 맞추는 편이 좋습니다.
6. sitemap에 실제로 들어가 있는지도 확인한다
새 글이 안 잡힐 때 sitemap은 아주 좋은 힌트가 됩니다. Google은 sitemap이 canonical URL을 포함해야 한다고 설명하고, 새 페이지를 Google이 찾도록 돕는 방법 중 하나로 sitemap 게시를 언급합니다.
그래서 저는 새 글을 발행한 뒤 sitemap에 그 URL이 들어갔는지 확인합니다.
curl.exe https://www.example.com/sitemap.xml | Select-String "new-post-not-indexed"
이 단계에서 확인하고 싶은 건 두 가지입니다.
- 새 글 URL이 sitemap에 포함되는가
- sitemap에 들어간 URL이 대표 호스트 기준인가
이전 글에서 정리한 sitemap.xml과 robots.txt 자동 생성 글처럼 발행 글만 sitemap에 들어가게 만들어 두면 이 단계가 훨씬 단순해집니다.
7. 내부 링크가 충분한지 본다
Google의 “Has Google found all your pages?” 문서는 새 페이지를 발견하도록 도우려면 sitemap을 게시하거나 크롤링을 요청할 수 있고, 중요한 오류는 유형별로 살펴보라고 설명합니다. 여기에 canonical 문서의 “내부 링크를 canonical URL로 일관되게 연결하라”는 조언을 같이 놓고 보면, 내부 링크는 생각보다 강한 발견 신호입니다.
새 글이 안 잡힐 때 저는 보통 이런 걸 봅니다.
- 홈이나 아카이브에서 새 글로 링크가 있는가
- 관련 글에서 새 글로 연결되는가
- 내부 링크가 canonical URL을 가리키는가
특히 블로그 초반에는 새 글이 단일 고립 페이지처럼 존재하는 경우가 많습니다. sitemap에는 들어갔지만, 사이트 안 어디에서도 연결되지 않으면 발견과 평가가 느려질 수 있습니다. 그래서 새 글을 하나 발행하면 최소한 아카이브, 관련 글, 홈 중 하나에서는 노출되게 만드는 편이 좋습니다.
8. Page Indexing reason을 해석할 때 “바로 고칠 것”과 “기다릴 것”을 나눈다
Search Console Page Indexing 도움말은 원인별로 대응이 다르다는 점을 분명히 보여줍니다. 특히 Crawled - currently not indexed에 대해서 Google은 이미 크롤링했지만 색인하지 않았으며, 이 URL을 다시 제출할 필요는 없다고 설명합니다.
이 문장은 꽤 중요합니다. 왜냐하면 많은 운영자가 이 상태를 보면 색인 요청을 반복하기 때문입니다.
제가 해석하는 기준은 이렇습니다.
URL is unknown to Google- 발견 신호 부족 가능성
- sitemap, 내부 링크, 요청 여부 확인
Blocked by noindex- 즉시 수정 대상
- 템플릿, 메타태그, 응답 헤더 확인
Blocked by robots.txt- 즉시 수정 대상
- robots 규칙과 적용 경로 확인
Crawled - currently not indexed- 다시 제출만 반복하지 말 것
- canonical, 중복, 품질, 내부 링크, 기다림을 함께 봐야 함
Duplicate또는 alternate 계열- canonical 구조 점검 필요
Google 문서도 Page Indexing report의 라이브 테스트가 모든 문제를 검사하지는 않으며, 특히 duplicate나 canonical 조건은 live test에서 드러나지 않을 수 있다고 말합니다. 그래서 이 단계에서는 URL Inspection과 Page Indexing report를 같이 봐야 합니다.
9. 그래도 문제가 없으면 마지막에 색인 요청을 한다
모든 기본 조건을 점검한 뒤에야 저는 색인 요청을 사용합니다.
- live test 성공
- noindex 없음
- robots 차단 없음
- canonical 정상
- sitemap 포함
- 내부 링크 존재
이 상태라면 URL Inspection에서 요청을 넣을 수 있습니다. 다만 Google은 다시 한 번, 크롤링 요청이 즉시 포함을 보장하지 않으며 며칠에서 몇 주까지 걸릴 수 있다고 설명합니다. 그래서 요청 후에는 조급하게 같은 URL을 반복 제출하지 않는 편이 좋습니다.
오히려 요청 뒤에는 아래를 봅니다.
- 며칠 뒤 URL Inspection 상태 변화
- Page Indexing reason 변화
- site: 검색에서 대표 URL 등장 여부
제가 실제로 쓰는 점검 순서
새 글이 안 잡히면 저는 보통 이 순서로 10분 안에 원인을 좁힙니다.
- URL Inspection에서 그 URL 상태 확인
Test live URL로 접근 가능성 확인- noindex 메타/헤더 확인
- robots.txt 차단 여부 확인
- canonical이 자기 자신을 가리키는지 확인
- sitemap에 포함됐는지 확인
- 홈, 아카이브, 관련 글에서 내부 링크가 있는지 확인
- Page Indexing reason이
고쳐야 하는 이유인지기다려야 하는 이유인지 구분 - 모든 조건이 맞으면 마지막에 색인 요청
간단한 shell 확인도 같이 하면 빠릅니다.
curl.exe -I https://www.example.com/blog/new-post-not-indexed
curl.exe https://www.example.com/blog/new-post-not-indexed | Select-String "noindex"
curl.exe https://www.example.com/blog/new-post-not-indexed | Select-String 'rel="canonical"'
curl.exe https://www.example.com/sitemap.xml | Select-String "new-post-not-indexed"
이 정도만 해도 “정말 접근 문제인지”, “메타데이터 문제인지”, “발견 신호 문제인지”가 꽤 빨리 갈립니다.
마무리
새 글이 색인되지 않을 때 가장 중요한 건 막연히 기다리거나, 반대로 색인 요청만 반복하지 않는 것입니다. Google 공식 문서를 기준으로 보면, 색인 문제는 접근 가능성, noindex, robots, canonical, sitemap, 내부 링크, 그리고 단순한 시간 지연으로 나뉘어 생각해야 합니다.
제 기준에서는 그래서 항상 URL Inspection -> live test -> noindex -> robots -> canonical -> sitemap -> 내부 링크 -> 마지막에 요청 순서로 봅니다. 이 순서는 작은 블로그일수록 특히 잘 맞습니다. 사이트 전체 그래프보다 문제의 URL 하나를 정확히 해부하는 편이 훨씬 빨리 원인을 좁힐 수 있기 때문입니다.
Search Console 초기 화면이 아직 익숙하지 않다면 먼저 Search Console 등록 직후 체크리스트 글을 함께 보고, 구조 자체가 흔들리는 경우에는 www, non-www, canonical 정리 글이나 sitemap/robots 자동화 글까지 이어서 보는 흐름을 추천합니다.