Google Search Console 고급 활용법: 구조화 데이터와 색인 최적화 실전

지난주 Google Search Console을 열었더니 ‘페이지 색인 생성’ 보고서에 노란색 경고 막대가 줄지어 있었습니다. Discovered - Currently Not Indexed 상태였습니다. Google 크롤러가 200개가 넘는 페이지를 발견했는데도 좀처럼 색인하지 않고 있었습니다. 마음이 조급해질 수밖에 없었습니다.

그뿐만이 아니었습니다. Enhancements 보고서로 넘어가니 몇 개의 Error가 유난히 눈에 띄었습니다. Article schema에는 필수 속성이 빠져 있었고 FAQ 마크업 구조에도 문제가 있었습니다. 블로그에 구조화 데이터를 추가하느라 며칠이나 썼는데 검색 결과에는 리치 결과가 하나도 나타나지 않았습니다.

비슷한 상황을 겪어 본 적이 있으신가요? 저도 처음 GSC에서 이런 오류를 마주했을 때는 무엇부터 해야 할지 막막했습니다. 온라인 튜토리얼은 너무 기초적이거나 ‘구조화 데이터를 추가하는 것이 중요하다’는 설명에 그쳤습니다. 정작 무엇을 어떻게 점검하고 수정해야 하는지는 한마디로 넘어가는 경우가 많았습니다.

이 글은 Google Search Console 가이드 시리즈의 세 번째 글입니다. 앞선 두 글에서는 GSC의 기본 사용법과 성능 보고서 해석을 다뤘습니다. 이번에는 한 단계 더 들어가 구조화 데이터 모니터링, 색인 문제 해결, 크롤링 예산 최적화, 그리고 2026년 AI 검색 시대에 주목해야 할 사항을 살펴보겠습니다.

그럼 이 문제들을 하나씩 함께 해결해 봅시다.

---

1장: 구조화 데이터 모니터링과 Enhancements 보고서 심층 분석

구조화 데이터는 쉽게 말해 Google에 건네는 ‘설명서’입니다. 이 페이지가 글인지, 질문과 답변인지, 제품인지 알려 주는 역할을 합니다. 설명서가 있으면 검색 결과도 더 풍부하게 표시될 수 있습니다. FAQ는 질문과 답변이 바로 펼쳐지고, 글에는 게시일이 나타나며, 제품에는 가격과 평점이 표시될 수 있습니다.

그런데 구조화 데이터를 추가한 뒤 Google이 제대로 이해했는지는 어떻게 알 수 있을까요?

1.1 Enhancements 보고서는 어떻게 구성되어 있나

GSC를 열고 왼쪽 탐색 메뉴에서 ‘개선사항’(영문 화면에서는 Enhancements)을 찾습니다. 클릭하면 다음과 같은 구조화 데이터 유형이 나열됩니다.

• Article(글)
• FAQ(자주 묻는 질문)
• HowTo(사용 방법 단계)
• Breadcrumb(탐색경로)
• Product(제품)
• Review snippet(리뷰 스니펫)

사이트에 특정 유형의 구조화 데이터가 없다면 해당 보고서도 나타나지 않습니다. 데이터가 없으니 보고서도 없는, 직관적인 방식입니다.

각 보고서에서는 페이지가 세 가지 상태로 분류됩니다.

상태	의미	후속 조치
Valid(유효함)	구조화 데이터에 문제가 없어 리치 결과로 표시될 수 있음	계속 모니터링하며 새 문제가 생기지 않는지 확인
Warning(경고)	속성이 빠졌거나 규격에 맞지 않지만 일부 결과는 표시될 수 있음	색인에는 영향을 주지 않아도 표시 효과에는 영향을 주므로 수정 권장
Error(오류)	구조화 데이터가 손상되어 리치 결과에 사용할 수 없음	전혀 표시되지 않으므로 반드시 수정

Error 상태의 빨간 막대는 무섭게 보이지만 당황할 필요는 없습니다. 대부분 필수 속성이 누락됐거나 형식이 잘못된 경우입니다. Google은 문제가 생긴 위치를 구체적으로 알려 줍니다. 오류 페이지를 열고 ‘문제 세부정보’를 확인하면 원인을 찾을 수 있습니다.

1.2 자주 사용하는 네 가지 구조화 데이터 설정법

Article Schema: 블로그 글의 기본 설정

블로그를 운영한다면 Article schema는 사실상 기본입니다. ‘필수 속성’은 없지만 Google은 표시 품질을 높이기 위해 몇 가지 핵심 필드를 추가할 것을 권장합니다.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "글 제목(110자 이하)",
  "author": {
    "@type": "Person",
    "name": "작성자 이름"
  },
  "datePublished": "2026-04-20",
  "dateModified": "2026-04-21",
  "image": "https://example.com/article-image.jpg"
}

솔직히 처음에는 headline과 author만 작성했습니다. 이후 datePublished와 dateModified를 추가하자 검색 결과의 글 제목 아래에 게시일이 표시되는 것을 확인했습니다. ‘2026년 4월 20일 · Easton’과 같은 표시가 클릭률에 도움이 됩니다.

FAQ Schema: 질문과 답변 콘텐츠의 필수 설정

FAQ에는 필수 속성이 있습니다. 각 Question에는 반드시 acceptedAnswer가 있어야 합니다. 빠지면 유효하지 않습니다.

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "질문 텍스트",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "답변 텍스트"
      }
    }
  ]
}

제가 직접 겪은 함정이 하나 있습니다. Question과 Answer의 텍스트는 페이지에 실제로 표시되는 문구와 반드시 일치해야 하며, 임의로 ‘요약’하거나 ‘다듬으면’ 안 됩니다. Google은 구조화 데이터와 페이지 내용을 대조하고, 일치하지 않으면 바로 Error로 판정합니다.

HowTo Schema: 튜토리얼 단계의 표준 작성법

튜토리얼 글에는 HowTo가 적합하며, 검색 결과에 단계 미리보기를 바로 표시할 수 있습니다.

{
  "@context": "https://schema.org",
  "@type": "HowTo",
  "name": "튜토리얼 제목",
  "step": [
    {
      "@type": "HowToStep",
      "text": "첫 번째 단계의 구체적인 내용",
      "name": "1단계 이름"
    },
    {
      "@type": "HowToStep",
      "text": "두 번째 단계의 구체적인 내용",
      "name": "2단계 이름"
    }
  ]
}

Breadcrumb Schema: 탐색 경로의 구조화

탐색경로 구조화 데이터는 검색 결과의 경로 표시를 개선해 사용자가 글이 사이트의 어느 계층에 있는지 한눈에 알 수 있게 합니다.

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "홈",
      "item": "https://example.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "기술 개발",
      "item": "https://example.com/dev/"
    }
  ]
}

1.3 오류가 발생했다면? 수정 절차 따라가기

첫 번째 단계는 구체적인 문제를 찾는 것입니다. Enhancements 보고서에서 Error 항목을 클릭하면 GSC가 오류가 발생한 URL을 모두 보여 줍니다. 하나를 선택해 ‘문제 세부정보’를 확인하면 ‘필수 속성 name 누락’처럼 구체적인 안내를 볼 수 있습니다.

두 번째 단계는 검증 도구로 확인하는 것입니다. Google은 두 가지 무료 도구를 제공합니다.

• Rich Results Test(search.google.com/test/rich-results): URL을 입력하거나 JSON-LD를 직접 붙여 넣어 리치 결과 생성 가능 여부를 테스트합니다.
• Schema.org Validator(validator.schema.org): 각 속성이 규격에 맞는지 더 자세히 검사합니다.

저는 보통 Rich Results Test로 빠르게 확인한 뒤, 오류가 계속되면 Schema.org Validator로 더 깊이 살펴봅니다.

세 번째 단계는 수정 후 다시 배포하는 것입니다. 코드를 고친 뒤 배포합니다.

네 번째 단계는 재검증을 요청하는 것입니다. GSC Enhancements 보고서로 돌아가 오류 항목 오른쪽 위의 ‘수정 결과 확인’을 클릭합니다. Google은 표시된 페이지를 다시 크롤링해 문제가 해결되었는지 확인합니다. 이 과정에는 며칠이 걸릴 수 있습니다.

한 가지 세부 사항이 있습니다. 수정한 직후 ‘색인 생성 요청’을 누를 필요는 없습니다. Enhancements 보고서의 검증 절차가 자동으로 재크롤링을 시작합니다. 검증을 요청하면 Google이 알아서 확인합니다.

자주 발생하는 오류 빠른 참조표:

오류 유형	대표적인 원인	해결 방법
필수 속성 누락	required 필드가 비어 있음	해당 속성 값을 추가
속성 유형 불일치	예: datePublished를 ISO 날짜 형식이 아닌 문자열로 작성	표준 형식(YYYY-MM-DD)으로 변경
내용 불일치	Schema 텍스트와 페이지 표시 내용이 다름	‘다듬지’ 말고 100% 일치하도록 수정
형식 오류	JSON-LD의 쉼표나 괄호가 잘못됨	JSON 검증 도구로 먼저 문법 검사

---

2장: 색인 생성 범위 보고서의 고급 활용법

많은 사이트 운영자가 가장 골치 아파하는 부분입니다. Google이 페이지를 발견했는데도 색인에 추가하지 않습니다. 색인 생성 범위 보고서의 빈틈을 보면 콘텐츠에 문제가 있는지, 사이트 구조에 문제가 있는지 걱정하게 됩니다.

먼저 관점을 바꿔야 합니다. 색인 생성 범위가 100%일 필요는 없습니다. 그 이유는 뒤에서 자세히 설명하겠습니다. 우선 이 보고서가 정확히 무엇을 말하는지부터 알아봅시다.

2.1 ‘Discovered - Currently Not Indexed’는 정확히 무엇을 뜻하나

GSC의 ‘페이지 색인 생성’(Page Indexing) 보고서를 열면 원형 차트와 몇 가지 분류가 표시됩니다. 그중 특히 신경 쓰이는 상태가 발견됨 - 현재 색인이 생성되지 않음(Discovered - Currently Not Indexed)입니다.

이 상태는 Google 크롤러가 이 페이지를 이미 발견해 존재를 알고 있지만 검색 색인에는 당분간 넣지 않기로 결정했다는 뜻입니다.

왜 그럴까요? 몇 가지 일반적인 원인이 있습니다.

콘텐츠 품질 문제

페이지 콘텐츠가 너무 짧거나 중복이 많고 다른 페이지와 매우 유사하거나 사용자에게 주는 가치가 분명하지 않을 수 있습니다. Google의 판단 기준을 전부 알 수는 없지만 한 가지는 분명합니다. 가치가 낮은 콘텐츠는 크롤러가 방문해도 색인하려 하지 않습니다.

크롤링 예산 제한

Google은 사이트마다 크롤링 예산을 둡니다. 하루에 크롤링할 수 있는 횟수에 상한이 있다는 뜻입니다. 사이트에 페이지가 수천 개라면 크롤러는 일부만 처리하고 나머지는 아직 차례가 오지 않았을 수 있습니다.

기술적 장애물

페이지 로딩이 너무 느리거나 서버 응답 시간이 초과되거나 robots.txt가 특정 경로를 실수로 차단했을 수 있습니다. 크롤러가 접속에 실패했거나 거부당했을 가능성이 있습니다.

새 사이트의 콜드 스타트

새 사이트를 막 공개했을 때는 색인 생성 속도가 비교적 느립니다. 일정한 콘텐츠 양과 백링크가 쌓여야 Google의 크롤링 빈도가 높아집니다.

중요한 인식 전환이 필요합니다. ‘현재 색인이 생성되지 않음’이 ‘영원히 색인되지 않음’을 뜻하지는 않습니다. 사이트 권위가 쌓이고 콘텐츠를 개선하면 몇 달 뒤 자연스럽게 색인되는 페이지도 많습니다. 서두를 필요는 없습니다.

2.2 색인 문제를 체계적으로 점검하기

‘현재 색인이 생성되지 않음’ 상태의 페이지가 수백 개라면 무엇부터 처리해야 할까요?

첫 번째 단계: URL 검사 도구로 하나씩 확인

GSC 상단 검색창에 페이지 URL을 입력하고 ‘검사’를 클릭합니다. 다음 정보를 확인할 수 있습니다.

• 색인 상태: 색인되었는지, 색인되지 않았다면 그 이유가 무엇인지
• 크롤링 상태: 마지막 크롤링 시간과 크롤링 성공 여부
• 표준 URL: Google이 판단한 ‘대표 버전’(페이지에 비슷한 버전이 여러 개라면 이 주소로 통합됨)

페이지의 ‘표준 URL’이 다른 주소를 가리킨다면 Google이 이 페이지를 중복 콘텐츠로 보고 다른 버전에 통합했다는 뜻입니다. 이 경우에는 걱정할 필요가 없습니다. 원래 페이지가 색인되지 않는 것이 정상입니다.

두 번째 단계: 가치가 낮은 페이지 식별

색인 보고서에서 ‘발견됨 - 현재 색인이 생성되지 않음’ 목록을 열고 경로별로 분석합니다.

• 태그 페이지, 아카이브 페이지, 페이지네이션이 대량으로 포함되어 있나요? 이런 페이지는 원래 색인 가치가 낮습니다.
• 매개변수만 다른 중복 페이지가 있나요? 예를 들어 ?sort=가 붙은 버전과 붙지 않은 버전이 있을 수 있습니다.
• 비어 있거나 콘텐츠가 거의 없는 테스트 페이지가 있나요?

이 페이지들은 애초에 색인될 필요가 없습니다. 어떻게든 색인시키려고 하기보다 robots.txt로 크롤링을 막아 크롤러가 실제로 가치 있는 콘텐츠에 집중하게 하는 편이 낫습니다.

세 번째 단계: 내부 링크 구조 확인

중요한 페이지를 가리키는 사이트 내부 링크가 충분한가요? 내부 링크는 크롤러가 페이지를 발견하는 주요 경로입니다. 3단계 디렉터리 구석에 숨겨진 페이지는 크롤러의 차례가 영영 오지 않을 수 있습니다.

제 경험상 핵심 글은 홈페이지나 1차 카테고리 페이지에서 바로 연결되어야 합니다. 주기적으로 사이트 탐색 메뉴와 사이드바를 확인해 가치 있는 콘텐츠가 ‘너무 깊이 묻히지’ 않도록 하세요.

2.3 색인 최적화 전략(‘색인 생성 요청’부터 누르지 마세요)

페이지가 색인되지 않은 것을 보면 많은 사람이 먼저 ‘색인 생성 요청’ 버튼을 누릅니다. 일부 문제는 해결할 수 있지만 근본 원인까지 해결하지는 못합니다.

색인 생성 요청의 제한

사용자마다 하루에 요청할 수 있는 색인 생성 횟수에 제한이 있습니다. Google은 구체적인 수치를 공개하지 않았지만 대략 수십 회입니다. 요청할 페이지가 100개가 넘는다면 하루에 모두 처리할 수 없습니다. 더 중요한 점은 페이지 자체의 품질이 부족하면 요청해도 색인되지 않는다는 것입니다.

올바른 최적화 접근법:

1. 가치가 높은 페이지에 집중합니다. 가장 중요하고 콘텐츠 품질이 좋다고 판단되는 페이지 10~20개를 고릅니다. URL 검사 도구로 문제를 우선 분석하고 맞춤형으로 최적화한 뒤 색인 생성을 요청합니다.

2. 근본 원인을 해결합니다. 다음 사항을 확인하세요.

   • 콘텐츠가 충분히 충실한가(1,500자 이상 권장)
   • 독창적인 관점이나 고유한 가치가 있는가
   • 페이지 로딩이 충분히 빠른가(서버 응답 <500ms)
   • 내부 링크가 충분한가

3. 가치가 낮은 페이지는 과감히 포기합니다. 태그 페이지, 페이지네이션, 중복 콘텐츠는 robots.txt로 크롤링을 차단합니다.

User-agent: Googlebot
Disallow: /tag/
Disallow: /page/
Disallow: /*?sort=

4. 추세를 정기적으로 모니터링합니다. 매주 색인 생성 범위 보고서를 열어 ‘색인됨’ 수가 늘고 있는지 살펴봅니다. 계속 증가한다면 최적화가 효과를 내고 있는 것이고, 정체되거나 줄어들면 새로운 문제가 생겼는지 확인해야 합니다.

색인 최적화에 필요한 관점: 모든 페이지를 색인시키는 데 집착하지 마세요. Google의 크롤링 예산은 한정되어 있습니다. 가장 가치 있는 콘텐츠에 예산을 쓰게 하는 것이 올바른 전략입니다. 100페이지 규모의 사이트에서 60페이지만 색인되더라도 모두 고품질 콘텐츠라면, 100페이지가 전부 색인됐지만 절반이 쓸모없는 사이트보다 훨씬 낫습니다.

---

3장: URL 검사 도구의 고급 활용법

URL 검사 도구(URL Inspection)는 GSC에서 가장 실용적인 기능 중 하나라고 생각합니다. Google이 개별 페이지를 어떻게 이해하는지, 무엇을 크롤링하고 색인했으며 어떤 구조화 데이터를 인식했는지 들여다볼 수 있는 ‘투시경’과 같습니다.

사용법은 간단합니다. GSC 상단 검색창에 전체 URL을 입력하고 Enter 키나 ‘검사’ 버튼을 누르면 됩니다. 하지만 많은 사람이 ‘이 페이지가 색인됐는지’를 확인하는 데만 사용합니다. 실제로는 훨씬 더 많은 일을 할 수 있습니다.

3.1 도구에서 제공하는 정보 한눈에 보기

URL을 입력하면 몇 개의 영역이 표시됩니다.

색인 상태

• Google 색인에 포함되어 있는지
• 포함되지 않았다면 그 이유가 무엇인지(중복 콘텐츠, robots.txt 차단, 품질 부족 등)
• 표준 URL(Canonical): 비슷한 페이지가 여러 개일 때 Google이 판단한 ‘대표 버전’

크롤링 정보

• 마지막 크롤링 시간
• 크롤링 상태(성공, 실패, 리디렉션 등)
• 페이지 다운로드 크기와 응답 시간

구조화 데이터

• 페이지에 있는 구조화 데이터 유형
• Error 또는 Warning 존재 여부

모바일 사용 편의성

• 모바일에서 페이지에 문제가 있는지

두 가지 고급 기능은 ‘실제 URL 테스트’ 버튼 안에 있습니다.

• Live Test: 페이지를 실시간으로 크롤링해 현재 Google에 무엇이 보이는지 확인합니다. 페이지를 방금 수정하고 결과를 확인하고 싶을 때 특히 유용합니다. GSC 보고서가 업데이트될 때까지 기다릴 필요 없이 Live Test로 바로 볼 수 있습니다.
• 크롤링된 페이지 보기: Google 크롤러가 가져온 원본 HTML을 볼 수 있습니다. 페이지가 JavaScript 렌더링에 의존한다면 이 기능으로 Google이 동적으로 불러온 콘텐츠를 실제로 확인했는지 판단할 수 있습니다.

3.2 일곱 가지 실전 활용 사례

사례 1: 새 페이지의 색인 여부 확인

새 글을 게시한 뒤 색인되었는지 확인하려면 URL을 입력해 검사합니다. ‘URL이 Google에 등록되어 있지 않음’으로 표시되면 Live Test로 페이지에 문제가 없는지 확인하고, 문제가 없다면 ‘색인 생성 요청’을 누릅니다. 며칠 후 다시 확인하세요.

사례 2: 구조화 데이터 인식 여부 확인

Article schema나 FAQ schema를 추가한 뒤 Google이 이해했는지 확인하려면 URL을 입력하고 ‘구조화 데이터’ 영역을 봅니다. Valid라면 문제가 없습니다. Warning이나 Error가 있다면 세부정보를 열고 안내에 따라 수정합니다.

사례 3: 페이지 렌더링 문제 디버깅

일부 페이지는 JavaScript로 콘텐츠를 동적으로 불러옵니다. 크롤러가 이 콘텐츠를 볼 수 있을까요? ‘크롤링된 페이지 보기’ 기능으로 원본 HTML에 필요한 콘텐츠가 있는지 확인합니다. 내용이 비어 있다면 JavaScript 렌더링이 처리되지 않은 것이므로 기술 방식을 바꿔야 합니다.

사례 4: Canonical 설정이 올바른지 확인

<link rel="canonical" href="...">을 설정한 뒤 Google이 어떤 URL을 표준으로 판단했는지 알고 싶다면 URL 검사 도구에서 ‘Google이 선택한 표준 URL’을 확인합니다. 설정한 값과 다르다면 콘텐츠 중복이나 다른 기술적 이유로 Google이 별도의 판단을 내린 것입니다.

사례 5: robots.txt의 크롤링 차단 여부 확인

특정 페이지가 계속 색인되지 않아 robots.txt가 실수로 차단한 것은 아닌지 의심되나요? URL 검사에서 ‘robots.txt에 의해 차단되었는지’를 알려 줍니다. 차단되었다면 robots.txt 규칙을 수정합니다.

사례 6: 페이지 업데이트 후 재색인 확인

페이지 제목이나 내용을 수정한 뒤 Google이 다시 크롤링했는지 확인하려면 URL 검사에서 ‘마지막 크롤링’ 시간을 봅니다. 날짜가 오래됐다면 아직 재크롤링하지 않은 것이므로 ‘색인 생성 요청’을 사용할 수 있습니다.

사례 7: 모바일 사용 편의성 문제 해결

페이지가 모바일에서 제대로 표시되지 않으면 URL 검사의 ‘모바일 사용 편의성’ 영역에 오류가 표시됩니다. 흔한 문제로는 너무 작은 글꼴, 부족한 요소 간격, 화면 너비를 벗어나는 콘텐츠가 있습니다. 안내에 따라 수정한 뒤 다시 검증하세요.

3.3 URL Inspection API 자동화 활용

개발자이거나 많은 페이지를 정기적으로 모니터링해야 한다면 하나씩 수동으로 확인하는 것은 너무 느립니다. Google은 자체 도구에 연동할 수 있는 URL Inspection API를 제공합니다.

API 기본 정보:

• Google Cloud 프로젝트를 신청하고 Search Console API를 활성화해야 합니다.
• 호출할 때마다 URL 하나의 색인 및 크롤링 정보를 반환합니다.
• 호출 빈도 제한이 있습니다. 구체적인 제한은 Google Cloud 할당량 설정을 확인하세요.

자동화 활용 예시:

블로그에 새 글을 게시할 때마다 색인 상태를 자동으로 확인하고 싶다고 가정해 봅시다. 다음과 같은 스크립트를 만들 수 있습니다.

1. 글 게시 시 트리거
2. URL Inspection API를 호출해 해당 URL 조회
3. ‘색인되지 않음’이 반환되면 24시간 후 다시 조회
4. 7일이 지나도 색인되지 않으면 수동 검사를 요청하는 이메일 자동 발송

또는 모니터링 대시보드를 만들 수도 있습니다. API를 정기적으로 호출해 핵심 페이지의 색인 상태와 구조화 데이터 상태를 확인하고, 문제가 있으면 자동으로 표시합니다.

이러한 자동 모니터링은 대규모 사이트에서 특히 유용합니다. 페이지가 수백, 수천 개라면 수동으로 모두 확인할 수 없습니다.

API 상세 문서는 Google Developers 공식 사이트에서 확인할 수 있습니다: developers.google.com/webmaster-tools/v1/api_reference_index

주의: API를 호출할 때 URL은 프로토콜과 도메인을 포함한 전체 주소여야 하며, GSC에서 확인된 사이트와 일치해야 합니다. 잘못된 버전(예: http와 https, www와 non-www)을 사용하면 유효하지 않은 데이터가 반환됩니다.

---

4장: 크롤링 통계와 예산 최적화

크롤링 예산(Crawl Budget)이라는 말은 기술적으로 들리지만 개념은 어렵지 않습니다. Google은 사이트마다 크롤링 횟수에 상한을 두며, 이 한도가 바로 ‘예산’입니다. 사이트에 아무리 페이지가 많아도 Google이 하루에 크롤링할 수 있는 양에는 한계가 있습니다.

소규모 블로그라면 크롤링 예산이 병목이 되는 경우는 드뭅니다. 페이지가 수십 개에서 수백 개라면 Google이 하루 안에 모두 크롤링할 수 있습니다. 하지만 페이지가 수천 개에 달하는 대규모 사이트에서는 크롤링 예산이 핵심 자원이 됩니다. Google이 태그 페이지, 페이지네이션, 매개변수로 중복된 페이지가 아니라 가장 가치 있는 콘텐츠에 예산을 쓰게 해야 합니다.

4.1 크롤링 통계 보고서 읽는 법

GSC의 ‘크롤링 통계’(Crawl Stats) 보고서를 열면 몇 가지 주요 차트가 나타납니다.

일일 크롤링 횟수 추세

지난 90일 동안 Google이 매일 몇 페이지를 크롤링했는지 보여 줍니다. 이 수치가 오르내리는 것은 정상입니다. 주말에는 조금 줄고 사이트가 업데이트될 때는 늘어날 수 있습니다. 하지만 지속적으로 감소한다면 사이트에 문제가 없는지 확인해야 합니다.

평균 다운로드 시간과 다운로드 크기

크롤링 한 번에 걸린 평균 시간과 다운로드한 데이터의 양입니다. 이 두 지표는 사이트 성능을 보여 줍니다.

• 평균 다운로드 시간 >500ms라면 서버 응답이 느려 크롤러가 기다리지 못하고 포기할 수 있습니다.
• 다운로드 크기가 특히 크다면(예: 수백 KB) 페이지가 비대하다는 뜻이므로 압축과 최적화가 필요할 수 있습니다.

크롤링 응답 분포

성공, 리디렉션, 찾을 수 없음, 기타 오류의 비율입니다. ‘기타 오류’ 비율이 높다면 서버가 불안정하거나 robots.txt 설정에 문제가 있을 수 있습니다.

파일 유형별 크롤링

HTML, 이미지, CSS, JS가 각각 몇 번 크롤링됐는지 보여 줍니다. 정적 리소스의 크롤링 횟수가 비정상적으로 높다면 불필요한 리소스가 반복해서 요청되고 있는지 확인해야 합니다.

4.2 크롤링 예산 최적화 실전

최적화의 핵심 목표는 크롤러가 중요한 페이지를 더 빠르게 처리하고 가치가 낮은 페이지에는 시간을 덜 쓰게 하는 것입니다.

첫 번째 단계: 서버 성능 최적화

서버 응답 시간을 500ms 이내로 유지하는 것을 목표로 삼습니다. 방법은 다음과 같습니다.

• CDN으로 정적 리소스 가속(Cloudflare, Vercel 모두 좋은 선택)
• 데이터베이스 쿼리를 최적화해 느린 쿼리 줄이기
• 동적 렌더링 페이지라면 캐시 도입 고려

두 번째 단계: robots.txt 감사

robots.txt를 확인해 차단해야 할 경로가 빠져 있지 않은지 살펴봅니다.

# 일반적으로 차단해야 하는 경로
User-agent: Googlebot
Disallow: /admin/          # 관리자 페이지
Disallow: /search/         # 검색 결과 페이지
Disallow: /tag/            # 태그 모음 페이지
Disallow: /page/           # 페이지네이션
Disallow: /*?utm=          # tracking 매개변수가 있는 URL
Disallow: /*?sort=         # 정렬 매개변수
Disallow: /*?filter=       # 필터 매개변수

이 페이지들은 원래 색인 가치가 낮습니다. 크롤링을 차단하면 크롤러가 본문 콘텐츠에 집중할 수 있습니다.

세 번째 단계: 내부 링크 구조 최적화

중요한 페이지에는 내부 링크 진입점이 충분해야 합니다. 크롤러는 링크를 따라 이동하므로 페이지를 가리키는 경로가 하나뿐이라면 발견까지 오랜 시간이 걸릴 수 있습니다.

저는 핵심 글을 홈페이지 추천 영역에 배치하고, 카테고리 페이지에서 바로 연결하며, 관련 글끼리 서로 참조하도록 합니다. 이렇게 하면 크롤러가 어느 지점에 도착하더라도 여러 경로를 따라 중요한 콘텐츠를 찾을 수 있습니다.

네 번째 단계: sitemap.xml 유지 관리

sitemap은 어떤 페이지가 중요하고 얼마나 자주 업데이트되는지 크롤러에 알려 주는 ‘지도’입니다. sitemap을 정기적으로 업데이트하고 새 글을 추가하며 삭제한 페이지는 제거합니다. GSC의 ‘Sitemaps’ 보고서에서 제출한 sitemap이 올바르게 인식됐는지 확인하세요.

4.3 지속적인 모니터링 워크플로

크롤링 예산 최적화는 한 번으로 끝나는 작업이 아니므로 정기적인 확인이 필요합니다. 2026년 SEO 실무에서는 다음과 같은 주기를 권장합니다.

매주 검토

• 색인 생성 범위 보고서를 열어 추세 변화 확인
• 새로운 Error 또는 Warning이 나타났는지 확인
• 크롤링 통계의 크롤링 횟수가 안정적인지 확인

매월 감사

• robots.txt 업데이트 필요 여부 확인
• 가치가 낮은 페이지(내용 없음, 중복 콘텐츠) 정리
• ‘발견됐지만 색인되지 않음’ 상태가 60일 이상인 페이지를 분석하고 최적화 또는 포기 여부 판단

분기별 종합 분석

• 크롤링 효율과 색인 생성 범위의 관계 비교
• 어떤 최적화 조치가 효과적이었는지 평가
• 장기 전략 조정

간단한 체크리스트로 매번 검토한 결과를 기록하고, 문제를 발견하면 즉시 처리하세요. 이런 지속적인 모니터링 습관이 사이트의 건전한 색인 상태를 장기적으로 유지해 줍니다.

크롤링 예산 최적화의 본질: Google이 더 많은 페이지를 크롤링하게 만드는 것이 아니라 ‘올바른’ 페이지를 크롤링하게 만드는 것입니다. 예산을 가장 필요한 곳에 쓰면 핵심 콘텐츠가 자연스럽게 더 쉽게 색인되고 노출됩니다.

---

5장: 2026년 AI 검색 시대의 새로운 요구 사항

최근 Google 검색을 사용해 봤다면 한 가지 변화를 눈치챘을 것입니다. 검색 결과 상단에 AI가 생성한 요약이 자주 나타나 질문에 바로 답해 줍니다. 이것이 AI Overviews입니다. 이전에는 SGE(Search Generative Experience)라고 불렸습니다.

이 변화는 SEO에 상당한 영향을 줍니다. 기존 검색 결과에서는 사용자가 링크를 클릭해야 콘텐츠를 볼 수 있었습니다. 이제는 AI가 답변을 직접 ‘묶어서’ 보여 줍니다. 그렇다면 웹사이트가 노출될 기회는 여전히 있을까요?

답은 ‘있다’입니다. 다만 전략을 조정해야 합니다.

5.1 AI 검색 시대에 구조화 데이터가 더 중요해진 이유

AI Overviews는 Google의 AI 모델이 검색 결과에서 정보를 추출하고 하나의 답변으로 통합해 생성합니다. 이 ‘추출’ 과정에서 구조화 데이터가 중요한 역할을 합니다.

왜일까요? 구조화 데이터가 콘텐츠에 이미 ‘표시’를 붙여 놓기 때문입니다. AI는 ‘이 문장이 무슨 뜻인지’ 추측할 필요가 없습니다. Schema가 글 제목, 게시일, 질문에 대한 답변을 직접 알려 줍니다.

다른 관점에서 생각해 봅시다. AI 모델은 방대한 정보를 처리해야 하며 구조화 데이터는 AI를 위한 ‘속독 노트’와 같습니다. 콘텐츠에 이 노트가 있으면 AI가 더 빠르고 정확하게 처리할 수 있으므로 인용될 가능성도 자연스럽게 높아집니다.

5.2 전통적인 SEO에서 AI SEO로: 사고방식의 전환

전통적인 SEO의 목표는 높은 순위를 얻어 사용자가 클릭하게 만드는 것입니다. AI SEO의 목표는 AI가 콘텐츠를 정확하게 이해하고 인용해 AI Overviews에 나타나게 하는 것입니다.

이러한 전환은 몇 가지 중요한 변화를 가져왔습니다.

콘텐츠 명확성이 더 중요해짐

AI 모델은 구조와 논리가 명확한 콘텐츠를 잘 이해합니다. 글의 흐름이 산만하면 AI가 핵심 주장을 추출하지 못할 수 있습니다. 해결 방법은 글의 시작 부분에 주제를 분명하게 제시하고, 단락마다 명확한 소제목을 두며, 핵심 결론을 완전한 문장으로 표현하는 것입니다.

FAQ와 HowTo 콘텐츠의 기회가 더 큼

FAQ Schema와 HowTo Schema 콘텐츠는 본래 AI가 인용하기 좋은 형태입니다. 질문과 답변의 형식이 명확하고 단계가 잘 구분되어 있습니다. 사이트에 이런 콘텐츠가 있다면 구조화 데이터를 반드시 올바르게 설정하세요.

인용 출처의 신뢰도

AI Overviews는 답변을 생성할 때 출처를 표시합니다. 공식 문서, 전문 콘텐츠, 실제 데이터 등 사이트에 권위 있는 정보가 있다면 인용 출처로 선택될 가능성이 더 높습니다.

실제 사례에서 얻은 관찰

한 SEO 실무자가 공유한 경험이 있습니다. 사이트에 FAQ Schema를 올바르게 설정한 뒤 관련 질문의 AI Overviews에 자신의 콘텐츠 요약이 나타나기 시작했고 출처 링크도 표시됐다고 합니다. 직접 클릭 수가 급증한 것은 아니지만 브랜드 노출과 인용 빈도는 뚜렷하게 늘었습니다.

5.3 2026년 검증 워크플로 업그레이드

과거에는 구조화 데이터를 검증할 때 코드를 작성하고 Rich Results Test로 확인한 뒤 문제가 없으면 공개했습니다.

이제는 검증과 모니터링을 더 체계적으로 수행하도록 워크플로를 개선하는 것이 좋습니다.

개발 단계 검증

• 구조화 데이터 코드를 작성한 뒤 Schema.org Validator로 문법 검사
• Rich Results Test로 리치 결과가 올바르게 생성되는지 확인
• 로컬에서 페이지 렌더링을 테스트해 JavaScript 렌더링 콘텐츠도 크롤러에 보이는지 확인

공개 후 모니터링

• GSC Enhancements 보고서에서 Error와 Warning을 정기적으로 확인
• GSC API를 모니터링 대시보드에 연동해 구조화 데이터 상태를 자동 수집
• 새 Error가 발생하면 자동으로 알리는 경고 설정

지속적인 최적화

• 구조화 데이터 유형을 업데이트해야 하는지 분기마다 확인(Google은 지원 유형을 새로 추가할 수 있음)
• AI Overviews에 비슷한 콘텐츠가 표시되는 방식을 관찰하고 참고해 구조화 데이터 설정 조정

구체적인 제안 한 가지: 블로그에 FAQ나 질문과 답변 형식의 콘텐츠가 있다면 FAQPage Schema를 설정하세요. 튜토리얼 콘텐츠에는 HowTo Schema를 설정합니다. 이 두 유형은 AI 검색 시대에 기회가 가장 크므로 우선 투자할 가치가 있습니다.

AI SEO의 본질: AI와 맞서는 것이 아니라 AI가 콘텐츠를 더 잘 이해하고 인용하도록 돕는 것입니다. 구조화 데이터는 바로 이 ‘도움’을 주는 도구입니다. 제대로 활용해야 콘텐츠가 AI Overviews에 표시되고 출처로 표기될 기회를 얻습니다.

---

요약

이 글에서는 Google Search Console의 몇 가지 고급 기능을 살펴봤습니다. 구조화 데이터 모니터링, 색인 생성 범위 문제 해결, URL 검사 도구, 크롤링 예산 최적화, 그리고 AI 검색 시대의 새로운 전략입니다.

핵심 내용을 다시 정리해 보겠습니다.

구조화 데이터: 추가만 하고 끝내서는 안 됩니다. GSC Enhancements 보고서로 계속 모니터링해야 합니다. Error는 반드시 수정하고 Warning은 수정하는 것이 좋습니다. FAQ, HowTo, Article은 블로그에서 자주 사용하는 세 가지 유형이며 각각 설정 시 주의할 점이 있습니다.

색인 문제: ‘Discovered - Not Indexed’를 보고 당황할 필요는 없습니다. 먼저 페이지 자체에 가치가 있는지 판단하세요. 가치가 낮은 페이지는 과감히 포기하고, 가치가 높은 페이지는 맞춤형으로 최적화합니다. 색인 생성 범위 100%에 집착하지 마세요.

URL 검사 도구: 단순히 ‘색인 여부를 확인’하는 기능이 아닙니다. 색인 확인, Schema 검사, 렌더링 디버깅, Canonical 확인, robots.txt 문제 해결, 업데이트 확인, 모바일 검사라는 일곱 가지 실전 상황에서 활용할 수 있습니다. 제대로 사용하면 문제 해결 효율이 두 배로 높아집니다.

크롤링 예산: 핵심은 ‘크롤러가 올바른 페이지를 처리하게 하는 것’입니다. 서버 응답 <500ms, robots.txt로 가치가 낮은 경로 차단, 합리적인 내부 링크 구조, 정기적인 sitemap 관리가 필요합니다. 매주 모니터링하고 매월 감사하며 분기마다 종합 분석하세요.

AI 검색 시대: AI Overviews가 콘텐츠를 올바르게 이해하고 인용하도록 돕는 구조화 데이터가 더 중요해졌습니다. FAQ와 HowTo 콘텐츠의 기회가 가장 큽니다. 검증 워크플로도 개발 단계 테스트, 공개 후 자동 모니터링, 지속적인 최적화로 업그레이드해야 합니다.

다음으로 할 수 있는 일:

1. GSC Enhancements 보고서를 열어 Error나 Warning이 있는지 확인합니다.
2. URL 검사 도구로 핵심 페이지 몇 개를 분석해 색인 상태와 구조화 데이터를 확인합니다.
3. robots.txt를 확인해 차단해야 할 경로가 빠져 있지 않은지 살펴봅니다.
4. FAQ나 튜토리얼 콘텐츠가 있다면 해당 구조화 데이터를 우선 설정합니다.

이 작업을 하루 안에 모두 끝낼 필요는 없습니다. 다만 계획을 세워 일주일 안에 기본 점검을 마치는 것이 좋습니다. 문제가 있는 페이지는 이 글의 절차에 따라 하나씩 수정하세요.

문제가 생기면 댓글로 함께 이야기해 주세요. 다음 글에서는 GSC API 연동과 자동 모니터링을 다룹니다. 관리할 페이지가 많다면 특히 유용할 것입니다.

---