GSC 색인 커버리지 개선: 30%에서 85%까지 올린 실전 진단과 오류 수정

글을 발행한 지 2주 뒤 Google Search Console을 열었는데, “제출되었지만 색인되지 않음” 상태가 보이는 경우가 있습니다. 꽤 많은 사람이 겪는 장면입니다.

더 나쁜 경우도 있었습니다. 예전에 한 프로젝트에서는 콘텐츠 42페이지 중 18페이지가 “Crawled - Currently Not Indexed”로 표시됐고, 비중은 42%였습니다. 정성껏 차린 밥상을 손님이 와서 보기만 하고 먹지 않는 느낌이었습니다.

그래도 다행히 21일 뒤 색인 페이지를 42개에서 71개로 늘렸고, 노출은 138% 증가했습니다. 이 글은 그 과정을 복기한 글입니다. 단순히 “색인 요청” 버튼을 누르는 법을 말하려는 것이 아닙니다. 그 버튼은 하루에 10번 누르면 Google이 전부 무시합니다. 대신 진단부터 수정까지 이어지는 하나의 체계를 정리했습니다.

GSC 커버리지 보고서 해석 - 5가지 오류 유형 비교

먼저 한 가지를 짚고 가겠습니다. GSC의 커버리지 보고서는 처벌 통지서가 아니라 진단 보고서입니다. 많은 사람이 빨간 경고 아이콘을 보면 당황하지만, 사실 Google은 문제가 어디에 있는지 알려주고 있습니다.

Pages 보고서는 어디에서 볼 수 있나

GSC에 로그인한 뒤 왼쪽 메뉴에서 “색인” > “Pages”를 찾습니다. 2026년 3월 이전 버전에서는 “커버리지”라고 불렸습니다. 이 페이지에서는 사이트의 모든 URL 색인 상태를 보여주며, 크게 몇 가지로 나뉩니다.

• 색인됨: 정상입니다. 크게 신경 쓰지 않아도 됩니다.
• 색인되지 않음: 여기가 핵심입니다.

색인되지 않음 아래에는 다시 여러 상태가 세분화되어 있습니다. 솔직히 처음 이 영어 라벨들을 봤을 때 저도 꽤 막막했습니다. 하지만 의미를 파악하고 나면 각 상태마다 대응하는 수정 경로가 있다는 것을 알 수 있습니다.

가장 흔한 색인 오류 5가지

아래 표에 다섯 가지 오류를 정리했습니다. 자신의 상황과 빠르게 대조해 볼 수 있습니다.

여기서는 특히 발목을 잡기 쉬운 두 가지를 집중해서 보겠습니다.

Crawled - Currently Not Indexed

쉽게 말해 Google 크롤러가 페이지에 와서 콘텐츠를 읽었지만, 색인 저장소에 넣지 않기로 판단한 상태입니다. 이는 “Discovered”보다 더 까다롭습니다. Google이 페이지를 봤지만 마음에 들어 하지 않았다는 뜻이기 때문입니다.

ClickRank 데이터에 따르면 전 세계 신규 페이지의 약 45%가 이 상태에 걸립니다. 보통 원인은 콘텐츠 품질 부족, 내부 링크 부족, 페이지 가치가 명확하지 않은 경우입니다.

Discovered - Currently Not Indexed

이 상태는 조금 가볍습니다. Google이 해당 URL의 존재를 알고 있지만(sitemap이나 외부 링크를 통해 발견했을 수 있습니다), 아직 크롤러를 보내 읽지는 않은 상태입니다. 대기 시간은 보통 “Crawled”보다 짧고, 5~10일 안에 해결되는 경우가 많습니다.

두 상태를 어떻게 구분할까요? 핵심은 Google이 실제로 페이지 내용을 “읽었는지”입니다. Crawled는 이미 읽은 상태이고, Discovered는 URL 존재만 아는 상태입니다.

핵심 오류 수정 실전 - 진단부터 해결까지의 전체 흐름

이제 중요한 부분입니다. 이 장에서는 오류 유형별 수정 단계를 나누어 설명합니다. 모두 제가 직접 테스트해 본 방법입니다.

”Crawled - Currently Not Indexed”를 고치는 7가지 점검 포인트

이 오류는 가장 골치 아프지만, 수정 방향은 의외로 분명합니다. Google이 페이지에 가치가 있다고 느끼게 만들어야 합니다.

아래 체크리스트를 순서대로 점검해 보세요.

1. 콘텐츠 깊이가 충분한가

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

최소 기준은 800자입니다. 하지만 저는 1200자 이상을 권합니다. 글자 수를 억지로 채우라는 뜻이 아닙니다. 하나의 주제를 정말 충분히 설명해야 한다는 의미입니다. 예전에 600자짜리 글이 하나 있었는데, 1500자로 다시 쓴 뒤 일주일 만에 색인되었습니다.

2. 내부 링크 구조에 문제가 없는가

신규 페이지를 가리키는 내부 링크가 최소 3개는 있어야 합니다. 고립 페이지, 즉 어떤 내부 링크도 가리키지 않는 페이지는 색인 실패의 주요 원인 중 하나입니다. 저도 이 문제를 겪었습니다. 새 글을 발행했지만 홈, 글 목록 페이지 어디에서도 링크되지 않아 Google 크롤러가 들어올 입구를 찾지 못했습니다.

3. 권위 있는 외부 출처를 인용했는가

글 안에 Google 공식 문서, Wikipedia, 업계에서 잘 알려진 블로그처럼 권위 있는 출처를 1~2개 인용하세요. 페이지의 신뢰도를 높이는 데 도움이 됩니다. 단순 URL만 붙이지 말고, 앵커 텍스트로 링크하는 편이 좋습니다.

4. 페이지 로딩 속도

서버 응답 시간이 1초를 넘으면 크롤러가 크롤링을 포기할 수 있습니다. 제 사이트는 예전 응답 시간이 800ms였는데, 200ms까지 최적화한 뒤 크롤링 빈도가 눈에 띄게 늘었습니다.

5. canonical 태그 설정

페이지에 canonical이 올바르게 설정되어 있는지 확인합니다. 여러 URL이 같은 콘텐츠를 가리키면 Google이 그중 하나를 표준 페이지로 선택하고 나머지는 무시할 수 있습니다.

6. 구조화 데이터

Article, HowTo, FAQ 등 적절한 구조화 데이터를 추가하면 Google이 페이지 내용을 더 쉽게 이해합니다. Astro 블로그라면 JSON-LD 형식으로 삽입할 수 있습니다.

7. 마지막에만 “색인 요청” 사용

위 6가지를 모두 처리한 뒤 GSC의 URL Inspection 도구에서 수동으로 색인을 요청하세요. 하루 최대 10개 URL만 요청할 수 있고, 초과분은 무시됩니다.

”Discovered - Currently Not Indexed” 빠른 수정 3단계

이 상태는 비교적 간단합니다. 세 단계로 처리할 수 있습니다.

Step 1: sitemap 다시 제출

GSC의 “Sitemaps” 페이지로 가서 기존 sitemap을 삭제한 뒤 다시 제출합니다. sitemap 파일 자체에 문제가 있을 때가 있습니다. 예를 들어 형식 오류나 만료된 URL 때문에 Google이 페이지를 발견하고도 색인하지 않을 수 있습니다.

Step 2: 서버 응답 속도 개선

서버 로그를 확인해 Google 크롤러가 방문했을 때의 응답 시간을 봅니다. 1초를 넘는다면 CDN 활성화, 이미지 압축, 리디렉션 감소 같은 최적화를 진행하세요.

Step 3: 주제 권위 구축

이 말이 조금 추상적으로 들릴 수 있지만, 본질은 Google이 특정 주제에서 이 사이트가 권위 있다고 판단하게 만드는 것입니다. 방법은 간단합니다. 하나의 핵심 주제를 중심으로 콘텐츠를 지속 발행하고, 콘텐츠 클러스터를 만드는 것입니다. 예를 들어 저는 GSC 관련 글을 연속으로 4편 발행했고, 각 글을 서로 연결했습니다.

Duplicate Canonical 처리 방법

이 상황은 보통 여러 URL의 콘텐츠가 같거나 비슷한데, Google이 자체적으로 하나를 표준 페이지로 골랐고, 나는 다른 URL을 지정하고 싶은 경우입니다.

해결 방법은 각 페이지 헤드에 canonical 태그를 추가하는 것입니다.

<!-- 표준 페이지로 삼고 싶은 URL -->
&lt;link rel="canonical" href="https://yourdomain.com/preferred-url/" /&gt;

예를 들어 블로그에 /blog/post-title/과 /posts/post-title/ 두 경로가 같은 콘텐츠를 가리킨다면, 하나를 표준 URL로 선택하고 모든 페이지가 그 URL을 가리키게 합니다.

Soft 404의 올바른 처리

Soft 404란 무엇일까요? 페이지는 200 상태 코드를 반환하지만, 콘텐츠가 비어 있거나 거의 가치가 없는 상태입니다. Google은 이 페이지가 “404처럼 보인다”고 판단합니다.

수정 방식은 두 가지입니다.

방법 1: 실제 404 반환

이 페이지가 정말 존재할 필요가 없다면 404 상태 코드를 반환하도록 바꿉니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

방법 2: 가치 있는 콘텐츠 추가

페이지를 유지해야 한다면 실제로 유용한 콘텐츠를 보강합니다. 최소 800자 이상, 이미지와 텍스트, 내부 링크를 갖추는 것이 좋습니다.

예전에 제 사이트에는 태그 이름만 있고 글 목록은 없는 태그 페이지가 있었습니다. 글 목록과 태그 설명을 추가하자 Soft 404가 사라졌습니다.

자동화 색인 가속 - Indexing API와 IndexNow 실전

여기까지 읽으면 이런 생각이 들 수 있습니다. 위의 수정 방법들은 모두 5~14일을 기다려야 하는데, 더 빠른 방법은 없을까?

있습니다. Indexing API입니다.

sitemap 제출만으로는 충분히 효율적이지 않은 이유

솔직히 2026년의 상황은 달라졌습니다. ClickRank 보고서에 따르면 전통적인 sitemap 제출 대기 기간은 2024년의 11일에서 23일로 길어졌습니다. Google은 크롤링 예산을 더 엄격하게 관리하고 있고, AI 개요가 도입된 뒤 콘텐츠 품질 요구도 더 높아졌습니다.

sitemap은 여전히 제출해야 합니다. 하지만 그것에만 의존해서는 안 됩니다. 능동적으로 “문을 두드리는” 방식이 필요합니다.

Indexing API: 48시간 85% 색인율

Indexing API는 무엇일까요? 쉽게 말하면 Google 크롤러에게 VIP 초대장을 보내는 것입니다. “이 URL이 업데이트됐으니 빨리 와서 크롤링해 달라”고 직접 알려주는 방식입니다.

실측 데이터는 이렇습니다. 하루에 신규 페이지 50개를 전송했고, 48시간 뒤 85%가 색인되었습니다. sitemap보다 훨씬 빠릅니다.

누가 사용할 수 있나

전자상거래 사이트, 채용 사이트, 라이브 스트리밍 플랫폼입니다. Google 공식 문서에서는 이 세 유형으로 제한합니다. 하지만 실제 운영에서는 블로그도 신청할 수 있습니다. Google Cloud Console에서 프로젝트를 만들고 권한을 신청하면 됩니다.

설정 단계(간단 버전)

1. Google Cloud Console에 로그인합니다.
2. 새 프로젝트를 만들고 “Indexing API” 서비스를 활성화합니다.
3. 서비스 계정(Service Account)을 만들고 JSON 키 파일을 생성합니다.
4. GSC에서 서비스 계정을 사이트 소유자로 추가합니다.
5. API로 URL을 전송합니다.

코드 예시(Node.js):

const { google } = require('googleapis');

// 서비스 계정 키 로드
const auth = new google.auth.GoogleAuth({
  keyFile: './service-account-key.json',
  scopes: ['https://www.googleapis.com/auth/indexing'],
});

// URL 전송
async function publishUrl(url) {
  const client = await auth.getClient();
  const indexing = google.indexing({ version: 'v3', auth: client });

  await indexing.urlNotifications.publish({
    requestBody: {
      url: url,
      type: 'URL_UPDATED',
    },
  });
}

// 일괄 전송
const urls = [
  'https://yourdomain.com/post-1/',
  'https://yourdomain.com/post-2/',
];
urls.forEach(publishUrl);

제한 사항

• 하루 최대 200개 URL까지 전송할 수 있습니다. 실제 테스트에서는 50개가 가장 효과적이었습니다.
• 전송 후 48시간을 기다렸다가 결과를 확인합니다.
• 같은 URL을 반복 전송하지 마세요. 무시될 수 있습니다.

IndexNow 프로토콜: Microsoft와 Yandex의 대안

IndexNow는 또 다른 즉시 색인 프로토콜이며, Microsoft Bing과 Yandex가 지원합니다. Google은 아직 지원하지 않지만, Bing 검색 트래픽도 늘고 있으므로 설정할 가치가 있습니다.

장점

• 설정이 더 간단합니다. 사이트 루트에 API Key 파일 하나만 두면 됩니다.
• 즉시 효과가 나타납니다. 제출 후 몇 시간 안에 Bing이 크롤링합니다.

설정 방법

1. IndexNow 공식 사이트에서 API Key를 생성합니다.
2. key 파일을 사이트 루트에 둡니다: /.well-known/indexnow-key.txt
3. URL을 IndexNow 엔드포인트로 제출합니다.

Astro 블로그라면 public/ 디렉터리 아래에 key 파일을 두면 빌드 후 루트로 자동 복사됩니다.

URL 제출 API:

POST https://www.bing.com/indexnow
?url=https://yourdomain.com/new-post/&key=YOUR_API_KEY

많은 CMS와 정적 블로그 프레임워크에는 이미 플러그인이 있습니다. 예를 들어 WordPress의 IndexNow 플러그인, Astro의 indexnow-integration 패키지가 있습니다.

Search Console API: URL 상태 일괄 확인

GSC 웹 버전에서는 하루에 수십 개 URL만 수동으로 확인할 수 있지만, Search Console API는 하루 2000회까지 조회할 수 있습니다. 정기적인 일괄 진단에 적합합니다.

사용 시나리오

• 매주 모든 글의 색인 상태 확인
• 어떤 페이지가 “색인됨”에서 “색인되지 않음”으로 바뀌었는지 찾기
• 커버리지 변화 추세 통계화

코드 예시:

const { google } = require('googleapis');

async function checkIndexStatus(url) {
  const client = await auth.getClient();
  const searchconsole = google.searchconsole({ version: 'v1', auth: client });

  const result = await searchconsole.urlInspection.index.inspect({
    requestBody: {
      inspectionUrl: url,
      siteUrl: 'https://yourdomain.com/',
    },
  });

  return result.data.inspectionResult.indexStatusResult;
}

반환 결과를 보면 해당 URL이 색인되었는지, 색인되지 않았는지, 또는 어떤 오류가 있는지 알 수 있습니다.

주간 모니터링 전략 - 지속 가능한 색인 건강 체계 만들기

한 차례 문제를 수정한 뒤 가장 중요한 것은 문제가 다시 생기지 않게 하는 것입니다. 저는 주간 모니터링 프로세스를 만들었고, 21일 동안 실측했을 때 효과가 꽤 좋았습니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

핵심 지표: 색인 커버리지

계산법은 간단합니다.

색인 커버리지 = 색인된 페이지 수 / 전체 페이지 수

제 프로젝트는 21일 동안 42/100(42%)에서 71/100(71%)까지 올라갔습니다. 목표는 85% 정도가 현실적입니다. 너무 높은 목표는 비현실적입니다. 일부 페이지는 원래 가치가 낮아 색인이 필요하지 않기 때문입니다.

매주 월요일 모니터링 체크리스트

저는 이 프로세스를 체크리스트로 고정해 매주 월요일 아침에 실행합니다.

1. Pages 보고서 확인

커버리지가 변했는지 봅니다. 5% 넘게 하락했다면 경고 신호이므로 점검해야 합니다.

2. 크롤링 통계 확인

GSC의 “설정” > “크롤링 통계”에서는 크롤러 방문 빈도와 응답 시간을 보여줍니다. 특히 다음을 봅니다.

• 일일 크롤링 횟수가 갑자기 줄었는가
• 평균 응답 시간이 늘었는가(1초를 넘으면 최적화 필요)

3. 새로 발행한 글 확인

최근 일주일 동안 발행한 콘텐츠가 색인되었는지 봅니다. 연속으로 3편이 색인되지 않았다면 콘텐츠 전략에 문제가 있을 수 있습니다.

4. 최적화 전후 비교

Search Console API로 데이터를 내보내 간단한 비교표를 만듭니다.

이렇게 하면 최적화 효과를 명확하게 볼 수 있습니다.

경고 신호와 처리 방법

아래 상황이 나타나면 즉시 처리해야 합니다.

• 커버리지 5% 초과 하락: 어떤 페이지가 “색인됨”에서 “색인되지 않음”으로 바뀌었는지 확인합니다.
• 서버 응답 시간 1초 초과: CDN과 리소스 압축을 최적화합니다.
• 신규 콘텐츠가 연속으로 색인되지 않음: 콘텐츠 품질과 내부 링크 구조를 점검합니다.
• 크롤링 빈도 급감: robots.txt나 서버 문제가 원인일 수 있습니다.

A/B 테스트 접근법

특정 최적화가 실제로 효과가 있는지 검증하고 싶다면 간단한 테스트를 해볼 수 있습니다.

• 색인되지 않은 글 10편을 고릅니다.
• 그중 5편만 최적화합니다(내부 링크 추가, 콘텐츠 수정).
• 두 그룹의 색인 속도를 비교합니다.

제가 한 번 테스트했을 때 최적화 그룹은 평균 7일 만에 색인되었고, 미최적화 그룹은 평균 14일이 걸렸습니다. 차이가 꽤 뚜렷했습니다.

결론

많은 내용을 이야기했지만, 이번 주 바로 실행할 수 있는 10단계 간단 체크리스트로 정리하면 다음과 같습니다.

1. GSC > Pages 보고서를 열어 현재 커버리지를 확인합니다.
2. 색인되지 않은 페이지 목록을 내보내 오류 유형별로 분류합니다.
3. “Crawled Not Indexed”를 우선 처리합니다(콘텐츠와 내부 링크 최적화).
4. canonical 태그 설정을 확인하고 수정합니다.
5. Soft 404와 Redirect 오류를 처리합니다.
6. Indexing API 또는 IndexNow를 설정합니다(선택 사항).
7. sitemap을 다시 제출합니다.
8. 수동 색인 요청을 보냅니다(하루 최대 10개).
9. 5~14일 기다린 뒤 결과를 확인합니다.
10. 주간 모니터링 프로세스를 구축합니다.

기대 효과는 21일 안에 커버리지를 30% 이상 높이고, 그에 따라 노출도 늘리는 것입니다.

한 가지를 강조하고 싶습니다. GSC의 커버리지 보고서는 Google이 당신을 처벌하는 것이 아니라 문제가 어디에 있는지 알려주는 도구입니다. 체계적으로 진단하고 수정하는 것이 하루에 “색인 요청” 버튼을 10번 누르는 것보다 훨씬 효과적입니다.

다음 글에서는 GSC의 검색 분석 보고서를 활용해 콘텐츠 전략을 최적화하는 방법을 다룰 예정입니다. 어떤 키워드를 써야 하는지, 어떤 콘텐츠를 업데이트해야 하는지 이야기해 보겠습니다. 관심이 있다면 이 시리즈를 계속 따라와 주세요.