기술적 색인 생성 문제를 진단하는 방법

Search Console 페이지 색인 생성 보고서의 점검 순서입니다. 무엇부터 고칠지, URL 검사로 원인을 확인하는 방법, 어디까지 하고 멈출지를 다룹니다.

색인 생성 문제는 보고서의 총계가 아니라 사이트에 필요한 페이지에서 출발해 진단하세요. 중요한 URL 목록을 만들고, 그중 색인되지 않은 페이지와 그 이유를 찾은 다음, 심각도 순서대로 원인을 처리합니다. 서버 및 접근 오류를 가장 먼저 보고, 이어서 의도하지 않은 차단, canonical 충돌, 오류와 유사한 페이지를 확인하며, 마지막으로 Google이 단순히 색인하지 않기로 선택한 페이지를 살펴봅니다. Google에 수정 사항 검증을 요청하기 전에, 각 수정은 URL 검사의 라이브 테스트로 확인하세요.

이 플레이북은 색인 생성 이해하기에서 설명한 상태를 알고 있다는 전제로 작성되었습니다.

1단계: 중요한 URL 목록 만들기

페이지 색인 생성 보고서는 매개변수가 붙은 주소, 예전 주소, 게시할 의도가 없던 페이지까지 Google이 아는 모든 URL을 집계합니다. "색인되지 않음" 수치가 큰 것은 정상이며, Google도 모든 URL이 색인되어야 하는 것은 아니라고 분명히 밝히고 있습니다(페이지 색인 생성 보고서). 그러니 직접 만든 목록에서 시작하세요.

트래픽을 가져오는 페이지: 실적 → 페이지에서 최근 3개월 기준 상위 50~100개
수익을 가져오는 페이지: 트래픽과 무관하게 제품, 가격, 서비스, 지역 페이지
새 페이지: 최근 90일 이내에 게시한 모든 페이지
사이트맵: 색인되기를 원하는 canonical URL만 정확히 담고 있어야 합니다. 페이지 색인 생성 보고서를 사이트맵별로 필터링하면 그중 몇 개의 URL이 색인되었는지 볼 수 있고, 사이트맵 보고서에서는 각 사이트맵에 포함된 URL의 색인 생성 현황으로 바로 이동할 수 있습니다.

2단계: 색인되지 않은 페이지 찾기

목록이 짧다면 URL 검사에서 URL을 하나씩 검사하세요. 목록이 길다면 사이트맵으로 필터링한 페이지 색인 생성 보고서를 열고 사유별로 살펴보면서, 예시에 중요한 URL이 포함되어 있는지 확인합니다. 각 URL을 사유와 사유의 출처와 함께 기록하세요. Google의 경험칙은 이렇습니다. 일반적으로 출처가 "웹사이트"로 표시된 문제만 직접 고칠 수 있습니다.

3단계: 원인을 순서대로 처리하기

원인은 다음 순서로 고치세요. 앞 단계의 문제가 다음 단계의 문제를 가릴 수 있고, 앞쪽 원인일수록 한꺼번에 더 많은 페이지에 영향을 줍니다.

순서	상태	먼저 확인할 것	일반적인 해결 방법
1	서버 오류(5xx)	Google이 크롤링한 시각의 서버 로그와 호스팅 상태	서버 용량이나 비정상 종료를 해결합니다. 5xx 응답이 반복되면 Google이 크롤링 속도도 늦춥니다
2	리디렉션 오류	해당 URL의 전체 리디렉션 체인	최종 URL로 한 번에 리디렉션하고 루프를 제거합니다
3	승인되지 않은 요청(401)으로 차단됨, 액세스 금지됨(403) 또는 기타 4xx	로그인 벽, 방화벽 또는 봇 차단 규칙	공개 페이지에는 Googlebot이 접근할 수 있게 합니다
4	'noindex' 태그에 의해 제외됨	페이지의 robots meta 태그와 `X-Robots-Tag` 헤더	순위에 노출되어야 하는 페이지에서 noindex를 제거합니다
5	robots.txt에 의해 차단됨	일치하는 robots.txt 규칙	크롤링되어야 하는 페이지의 차단 규칙을 제거합니다
6	중복, Google이 사용자와 다른 canonical 선택	canonical 태그, 리디렉션, 사이트맵, 내부 링크가 각각 어떤 URL을 가리키는지	모든 신호가 같은 URL을 가리키게 합니다
7	소프트 404	Googlebot이 가져왔을 때 페이지가 보여주는 내용	없는 페이지는 실제 404로, 실제 페이지는 실제 콘텐츠로 처리합니다
8	크롤링됨 - 현재 색인이 생성되지 않음	다른 페이지나 경쟁 사이트에 없는 가치를 이 페이지가 더하는지	페이지를 개선하거나 더 강한 페이지로 통합합니다
9	발견됨 - 현재 색인이 생성되지 않음	크롤링된 페이지 중 이 페이지로 링크하는 곳이 있는지	크롤링되는 페이지에서 링크를 연결합니다. 매우 큰 사이트라면 크롤링을 관리합니다

URL 검사로 URL 하나 진단하기

목록의 중요한 URL마다 다음 다섯 가지를 똑같이 확인하세요(URL 검사 도구).

판정과 사유를 읽습니다. "URL이 Google에 등록되어 있지 않음"은 Google이 해당 주소를 전혀 본 적이 없다는 뜻이므로, 과제는 발견입니다. Google이 이미 크롤링하는 페이지에서 링크를 연결하고 사이트맵에 포함하세요.
canonical을 비교합니다. Google이 선택한 canonical이 사용자가 선언한 canonical과 다르다면, Google은 이 URL 대신 다른 URL을 색인하고 있는 것입니다. 무엇이든 바꾸기 전에 그 다른 URL부터 확인하세요.
크롤링 상태를 확인합니다. 마지막 크롤링 날짜, Google이 스마트폰 또는 데스크톱 중 어느 쪽으로 크롤링했는지, 크롤링이 허용되었는지, 페이지 가져오기가 성공했는지를 확인하세요. 한 가지 주의할 점이 있습니다. robots.txt가 크롤링을 막고 있으면 "색인 생성 허용됨?"은 항상 '예'로 표시됩니다. Google은 가져오도록 허용되지 않은 페이지의 noindex를 볼 수 없기 때문입니다.
라이브 URL 테스트를 실행합니다. 기본 보기는 마지막으로 색인된 버전을 설명하며, 이는 오래된 것일 수 있습니다. 라이브 테스트는 페이지를 지금 가져와서 렌더링된 페이지의 스크린샷을 보여줍니다. 로그인한 사용자에게만 보이거나 스크립트 실패 후에야 나타나는 콘텐츠를 가장 빠르게 찾아내는 방법입니다.
수정한 뒤에만 색인 생성을 요청합니다. Google은 하루 할당량을 두고 있으며, 같은 URL을 반복해서 요청해도 처리가 빨라지지 않는다고 밝히고 있습니다(Google에 재크롤링 요청).

까다로운 상태에 대한 참고 사항

robots.txt에 의해 차단됨은 색인에서 제외됨과 같지 않습니다. robots.txt는 색인 생성이 아니라 크롤링을 제어합니다. 다른 페이지에서 링크하는 차단된 URL은 콘텐츠 없이도 색인될 수 있습니다. 페이지를 Google에서 빼려면 크롤링을 허용하고, meta 태그나 X-Robots-Tag 헤더로 noindex를 사용하세요(색인 생성 차단). 제거는 Google이 해당 페이지를 다시 크롤링해야 이루어지므로 시간이 걸릴 수 있다는 점을 기억하세요.

canonical 충돌은 대개 스스로 만든 문제입니다. Google은 리디렉션과 rel="canonical"을 강한 신호로, 사이트맵 포함을 약한 신호로 보며 HTTPS를 선호합니다(중복 URL 통합). 흔한 충돌은 canonical 태그는 한 URL을 가리키는데 내비게이션, 사이트맵, 내부 링크는 모두 다른 변형(끝 슬래시, 대문자, 추적 매개변수, http://)을 쓰는 경우입니다. 이를 일치시키면 다음 크롤링 때 충돌이 해소되는 경우가 많습니다.

소프트 404는 두 종류입니다. 하나는 200을 반환하는 "항목을 찾을 수 없음" 템플릿처럼 실제로 없는 페이지로, 404나 410을 반환해야 합니다. 다른 하나는 상품이 없는 카테고리나 스크립트 실패로 콘텐츠가 로드되지 않는 페이지처럼 실제 페이지인데 Google에는 비어 보이는 경우로, Google이 볼 수 있는 콘텐츠가 필요합니다. 라이브 테스트의 스크린샷으로 확인할 수 있습니다.

크롤링됨 - 현재 색인이 생성되지 않음은 오류가 아니라 판단입니다. Google이 페이지를 크롤링한 뒤 당분간 보관하지 않기로 결정한 것이며, 나중에 색인될 수도 있고 아닐 수도 있습니다. 이 페이지가 무엇을 더하는지 솔직하게 따져 보세요. 다른 페이지를 조금씩 바꾼 얇은 페이지, 글이 두 개뿐인 태그 페이지, 다른 열 개 사이트와 같은 이야기를 반복하는 글이 흔히 여기에 속합니다. 페이지를 분명히 더 낫거나 다르게 만들거나, 이미 그런 페이지에 통합하세요.

발견됨 - 현재 색인이 생성되지 않음은 대개 링크의 문제입니다. Google이 URL은 알지만 아직 크롤링하지 않은 상태입니다. 대부분의 사이트에서는 Google이 이미 크롤링하는 페이지에서 링크를 연결하고 사이트맵에 유지하는 것이 해결책입니다. Google의 크롤링 예산 가이드는 더 좁은 대상을 위해 쓰였습니다. 매주 변경되는 페이지가 100만 개를 넘는 사이트, 또는 매일 변경되는 페이지가 1만 개를 넘는 사이트입니다(크롤링 예산 관리). 여기에 해당한다면 URL 목록을 줄이세요. 중복을 통합하고, 가져올 필요가 없는 URL은 크롤링을 차단하고, 삭제한 페이지는 404나 410을 반환하고, 계속 크롤링되는 소프트 404를 고치세요.

4단계: 수정 사항 검증하기

어떤 사유에 해당하는 URL을 모두 고쳤다면, 페이지 색인 생성 보고서에서 해당 사유를 열고 수정사항 검증을 한 번 누르세요. Google은 먼저 샘플 페이지 몇 개를 확인하며, 문제가 그대로라면 검증이 중단됩니다. 그렇지 않으면 영향을 받는 모든 알려진 URL을 다시 확인하고 각각 통과 또는 실패로 표시합니다. Google은 검증에 보통 최대 2주 정도 걸리고 때로는 훨씬 더 오래 걸린다고 밝히고 있습니다. 검증을 요청하지 않아도 일반 크롤링 중에 수정 사항을 알아차리기도 합니다.

멈춰야 할 때

상태 뒤에 있는 URL이 색인할 필요가 없는 것(매개변수, 필터링된 보기, 내부 검색 결과, 오래된 리디렉션)일 때, 또는 페이지를 개선하고 링크를 연결하고 다시 제출했는데도 두어 달이 지나도록 Google이 계속 색인하지 않을 때는 그 상태를 더 쫓지 마세요. 그 시점에서는 색인 생성을 다시 요청하기보다 페이지를 더 강한 페이지로 통합하고 리디렉션하는 것이 대개 유용한 방법입니다.

AutoPSEO가 돕는 방법

AutoPSEO는 2단계를 상시 점검으로 바꿔 줍니다. Index Tracker는 직접 고른 URL을 최대 1,800개까지 보관하고, URL Inspection API를 통해 그중 최대 200개를 매일 다시 검사합니다(가장 오래전에 검사한 것부터, Google이 허용하는 속성당 하루 2,000회 검사 한도 이내). 그리고 최근 30일 안에 색인에서 제외된 페이지와 120일 동안 Google이 크롤링하지 않은 페이지를 표시합니다. 추적 중인 URL이 색인에서 빠지거나 다시 돌아오면 Index flip 알림이 Slack, Microsoft Teams 또는 웹훅으로 전송됩니다(알림). URL 검사와 사이트맵은 앱 안에서 바로 사용할 수 있고, Bing 크롤링 문제에서는 같은 종류의 문제를 Bing 쪽에서 볼 수 있습니다.

새 페이지의 경우 IndexNow가 변경된 URL을 Bing과 IndexNow를 지원하는 다른 검색엔진에 알립니다. Google은 IndexNow에 참여하지 않으므로 Google에 알리려면 계속 사이트맵과 내부 링크를 사용해야 합니다. 콘텐츠 엔진에서 만든 글은 사용자의 사이트로 전달되며, 사이트가 다른 페이지와 똑같이 게시하고 링크를 연결합니다. 사이트에 IndexNow 키가 선언되어 있으면 AutoPSEO는 게시되거나 업데이트된 호스트 내 주소마다 IndexNow에 핑을 보내고 IndexNow의 응답을 기록합니다(전달).