spider.es

Google이 페이지를 무시하는 이유: 흔한 색인 문제와 해결법

게시일

Google이 페이지를 무시하는 이유: 흔한 색인 문제와 해결법

페이지를 게시합니다. 기다립니다. 며칠이 몇 주가 되고, 페이지가 Google에 나타나지 않습니다. Search Console에 노출이 없고, 트래픽도 없으며, Google이 페이지의 존재를 알고 있다는 징후조차 없습니다. 이것은 SEO에서 가장 답답한 경험 중 하나이며—동시에 가장 흔한 경험 중 하나입니다.

좋은 소식: Google은 거의 항상 페이지를 무시한 이유를 알려줍니다. 나쁜 소식: 신호가 여러 도구와 보고서에 분산되어 있고, 근본 원인은 명백한 설정 오류부터 미묘한 구조적 결함까지 다양합니다. 이 가이드는 Google이 콘텐츠 색인을 거부할 수 있는 모든 주요 이유를 각각에 대한 실질적인 진단 단계와 함께 설명합니다.

1. noindex 지시어

가장 직접적인 원인입니다. 페이지에 noindex 지시어가 있으면 Google은 크롤링하지만 인덱스에서 명시적으로 제외합니다.

noindex가 나타날 수 있는 위치:

  • 메타 태그: HTML <head> 내의 <meta name="robots" content="noindex">.
  • X-Robots-Tag 헤더: HTTP 응답 헤더로 전송되는 X-Robots-Tag: noindex. 이것은 페이지 소스에서 보이지 않기 때문에 특히 위험합니다 — 응답 헤더를 직접 검사해야 합니다.

진단 방법

  • Google Search Console에서 페이지 보고서로 이동합니다. "'noindex' 태그로 제외됨" 상태를 찾습니다.
  • URL 검사 도구를 사용하여 특정 URL을 확인합니다. Google이 noindex를 감지했는지 보여줍니다.
  • 도메인에 대한 Spider.es 보고서를 실행하여 어떤 봇이 noindex 지시어를 만나는지, 그리고 그 출처가 어디인지 확인합니다.
  • curl -I 또는 브라우저 DevTools로 HTTP 응답 헤더를 확인합니다. 서버나 CDN 수준에서 설정된 X-Robots-Tag가 CMS의 의도를 무시할 수 있습니다.

흔한 원인: 스테이징 환경의 noindex 설정이 프로덕션에 그대로 적용된 경우, CMS 플러그인이 페이지네이션이나 아카이브 페이지에 noindex를 추가하는 경우, CDN이나 리버스 프록시 레이어가 X-Robots-Tag 헤더를 주입하는 경우.

2. 다른 곳을 가리키는 canonical

rel="canonical" 태그는 Google에게 페이지의 "선호" 버전이 어떤 URL인지 알려줍니다. 페이지 A가 자신의 canonical을 페이지 B로 선언하면, Google은 페이지 A에 고유한 콘텐츠가 있더라도 페이지 B를 색인하고 페이지 A를 무시할 수 있습니다.

흔한 canonical 실수

  • 잘못된 자기 참조 canonical: 쿼리 파라미터를 포함하거나, 프로토콜이 다르거나(http vs https), 후행 슬래시가 일치하지 않는 canonical 태그.
  • CMS가 생성한 canonical: 일부 시스템은 페이지네이션 페이지, 필터 보기, AMP 버전을 잘못된 canonical 대상으로 지정합니다.
  • 크로스 도메인 canonical: 콘텐츠를 신디케이션하고 신디케이션 파트너의 canonical이 자체 URL을 가리키면, Google은 여러분의 버전 대신 그들의 버전을 선택할 수 있습니다.
  • 충돌하는 신호: HTML의 canonical은 한 가지를 말하고, HTTP 헤더는 다른 것을 말하며, 사이트맵은 세 번째 URL을 나열합니다. Google은 추측해야 하며—잘못 추측할 수 있습니다.

진단 방법

Search Console의 URL 검사 도구를 사용합니다. "페이지 색인" 아래에서 사용자가 선언한 canonical과 Google이 선택한 canonical을 보여줍니다. 다르다면 문제가 있는 것입니다.

3. 크롤 버짓 낭비

Google은 각 사이트에 유한한 크롤 버짓을 할당합니다 — 크롤링 빈도(수요)와 서버가 처리할 수 있는 속도(용량)의 조합입니다. 사이트가 가치 없는 페이지에 버짓을 낭비하면, 중요한 페이지가 전혀 크롤링되지 않을 수 있습니다.

버짓 킬러

  • 패싯 내비게이션: 수천 개의 필터 조합이 거의 중복인 페이지를 생성합니다 (/shoes?color=red&size=10&brand=nike&sort=price).
  • 내부 검색 결과 페이지: 모든 쿼리가 Google이 크롤링을 시도할 수 있는 새 URL을 생성합니다.
  • 무한 달력 또는 페이지네이션: 크롤러가 "다음" 링크를 무한정 따라갈 수 있습니다.
  • URL의 세션 ID: 각 세션이 모든 페이지의 복제본을 생성합니다.
  • 소프트 404: 200 상태 코드를 반환하지만 "결과 없음" 콘텐츠를 표시하는 페이지. Google은 이를 크롤링하는 데 버짓을 낭비하고 나서 비어 있다는 것을 파악해야 합니다.

진단 방법

Search Console의 크롤링 통계 보고서는 총 요청 수, 평균 응답 시간, 응답 코드 분류를 보여줍니다. 크롤링된 URL의 대부분이 가치 낮은 필터 페이지라면 버짓이 새고 있는 것입니다. 서버 로그 분석은 더 깊은 통찰을 제공합니다 — Googlebot이 가장 많이 접근하는 경로를 파악하세요.

4. 씬 또는 중복 콘텐츠

Google은 페이지를 크롤링한 후 색인할 가치가 없다고 판단할 수 있습니다. 페이지 색인 보고서에서 이를 "크롤링됨 — 현재 색인되지 않음" 또는 "발견됨 — 현재 색인되지 않음"이라고 합니다.

이유는 다음과 같습니다:

  • 씬 콘텐츠: 고유 텍스트가 매우 적은 페이지 — 최소한의 콘텐츠가 있는 보일러플레이트 템플릿, 스텁 기사, 설명 없는 자동 생성 카테고리 페이지.
  • 유사 중복 콘텐츠: 거의 유사한 텍스트를 가진 여러 페이지. Google은 하나를 선택하고 나머지를 제외합니다.
  • 저품질 또는 낮은 수요: Google은 단순히 페이지가 인덱스에 포함될 만큼 충분한 가치를 더하지 못한다고 판단할 수 있습니다.

해결 방법

씬 페이지를 더 적고 풍부한 페이지로 통합하세요. 템플릿 페이지에 고유하고 실질적인 콘텐츠를 추가하세요. canonical 태그를 사용하여 중복을 선호 버전으로 지정하세요. 페이지에 진정한 가치가 없다면 제거하거나 robots.txt에서 차단하여 중요한 페이지를 위한 크롤 버짓을 확보하세요.

5. 서버 오류 (5xx)

Googlebot이 지속적인 5xx 서버 오류를 만나면 크롤링 속도를 줄이고 결국 영향받는 페이지를 인덱스에서 제거할 수 있습니다. 일회성 장애 중 단일 500 오류는 괜찮습니다 — Google이 재시도합니다. 그러나 반복되는 서버 오류는 신뢰할 수 없는 호스트를 나타내며, Google은 덜 자주, 덜 깊이 크롤링하는 것으로 대응합니다.

진단 방법

  • Search Console > 크롤링 통계: 5xx 응답의 급증을 찾습니다.
  • Search Console > 페이지 보고서: "서버 오류(5xx)" 항목을 확인합니다.
  • 서버 모니터링: 가동 시간 모니터링 도구를 사용하여 Googlebot보다 먼저 장애와 느린 응답을 감지합니다.

6. 리다이렉트 체인과 루프

리다이렉트 체인은 URL A가 B로, B가 C로, C가 D로 리다이렉트될 때 발생합니다. Google은 체인에서 최대 10개의 리다이렉트를 따르지만, 각 홉은 크롤 버짓을 낭비하고 링크 자산을 희석합니다. 긴 체인이나 루프는 Google이 완전히 포기하게 합니다.

흔한 시나리오

  • HTTP-to-HTTPS 마이그레이션이 www에서 non-www로의 리다이렉트 위에 계층화: http://www.example.com → https://www.example.com → https://example.com. 모든 이전 링크에 대해 두 홉이 발생합니다.
  • CMS 슬러그 변경으로 체인 생성: 이전 슬러그가 중간 슬러그로 리다이렉트되고, 이것이 현재 슬러그로 리다이렉트됩니다.
  • 리다이렉트 루프: A가 B로 리다이렉트되고 B가 다시 A로 리다이렉트됩니다. Googlebot은 즉시 포기합니다.

해결 방법

체인을 평탄화하여 모든 리다이렉트가 최종 목적지를 직접 가리키도록 합니다. 모든 마이그레이션 후 리다이렉트를 감사합니다. Spider.es, Screaming Frog 또는 명령줄 curl -L을 사용하여 전체 리다이렉트 경로를 추적합니다.

7. 고아 페이지

고아 페이지는 서버에 존재하지만 이를 가리키는 내부 링크가 없는 URL입니다. 사이트의 어떤 페이지도 이 URL에 링크하지 않고 사이트맵에도 없다면, Google은 콘텐츠가 아무리 훌륭해도 이를 발견할 방법이 없습니다.

진단 방법

사이트맵과 서버 로그의 URL을 전체 사이트 크롤에서 발견된 URL과 비교합니다. 사이트맵에는 있지만 크롤 그래프에 없는 URL은 사실상 고아 상태입니다. 또한 Search Console의 "발견됨 — 현재 색인되지 않음" 보고서를 확인하세요: Google이 URL을 찾았지만(외부 링크나 이전 사이트맵을 통해) 다시 방문하지 않는다면, 내부 링크가 약한 것이 원인일 수 있습니다.

해결 방법

관련성 있고 잘 크롤링되는 페이지에서 맥락에 맞는 내부 링크를 추가합니다. 고아 페이지가 XML 사이트맵에 포함되어 있는지 확인합니다. 사이트 구조를 정기적으로 감사하세요 — 특히 리디자인, 마이그레이션 또는 대규모 콘텐츠 삭제 후 기존 링크가 깨질 수 있습니다.

8. robots.txt에 의한 차단

robots.txt가 Googlebot의 URL 접근을 차단하면, Google은 페이지를 크롤링할 수 없습니다. 다른 페이지가 링크하면 URL을 색인할 수 있지만 콘텐츠 없이 — 결과적으로 최소한의, 도움이 되지 않는 목록이 됩니다. Search Console 페이지 보고서에서 이를 "robots.txt에 의해 차단됨"으로 표시합니다.

이것은 식별하고 수정하기 가장 쉬운 문제 중 하나입니다. Spider.es 보고서를 실행하여 모든 경로에서 Googlebot에 영향을 미치는 정확한 규칙을 확인한 다음, robots.txt를 적절히 업데이트하세요.

진단 체크리스트

페이지가 색인되지 않을 때 다음 순서를 따르세요:

  1. Search Console의 URL 검사: Google이 페이지를 알고 있는가? 어떤 상태를 보고하는가?
  2. noindex 확인: 메타 태그 및 HTTP 응답 헤더를 검사합니다.
  3. canonical 확인: 자기 자신을 가리키는가 아니면 다른 곳을 가리키는가?
  4. robots.txt 확인: URL이 차단되었는가? Spider.es를 사용하여 봇별 분석을 확인합니다.
  5. HTTP 상태 코드 확인: 200인가? 리다이렉트인가? 404 또는 5xx인가?
  6. 내부 링크 확인: 홈페이지에서 링크를 따라 페이지에 도달할 수 있는가?
  7. 사이트맵 확인: URL이 포함되어 있는가?
  8. 콘텐츠 품질 확인: 색인을 정당화할 만큼 충분히 고유하고 가치 있는 콘텐츠가 있는가?

마치며

Google이 페이지를 무시하는 것은 거의 무작위적이지 않습니다. 크롤러에게 건너뛰거나, 미루거나, 우선순위를 낮추라고 지시하는 기술적 신호가 거의 항상 존재합니다. 문제는 수십 가지 가능한 원인 중에서 해당 신호를 찾는 것입니다. Search Console에서 시작하고 Spider.es 같은 크롤러 관점을 보여주는 도구로 보완하는 체계적인 진단이 불투명한 문제를 해결 가능한 것으로 바꿉니다. 근본 원인을 수정하고, URL을 다시 제출하고, Google이 수집할 때까지 모니터링하세요.

블로그 목록으로 돌아가기