📖 11 분 읽기

Google Search Console에 사이트맵 제출하는 방법 (2026)

단계별 가이드: 사이트 소유권 확인, sitemap.xml 제출, 색인 요청, 그리고 “Couldn’t fetch” 상태 해결하기.

  • Google Search Console
  • Sitemap
  • Indexing

사이트를 배포했다. 페이지는 살아 있고, HTML은 깔끔하며, 콘텐츠도 좋다. 그런데도 site:yourdomain.com을 검색하면 아무것도 나오지 않는다. Google은 당신의 존재를 모른다.

사이트맵은 크롤링되기를 원하는 URL 목록을 기계가 읽을 수 있는 형태로 Google에 건네주는 방법이다. 이를 Google Search Console(GSC)을 통해 제출하면 Google에게 “이것이 내 사이트의 정식 인벤토리입니다 — 여기서부터 시작하세요”라고 알리는 셈이다. 색인을 보장해 주지는 않지만, 발견(discovery) 문제를 제거해 준다. 갓 만든 사이트에서는 이 발견이 가장 느린 부분이다.

이 가이드는 실용적이고 개발자 친화적인 버전이다: 소유권 확인, 사이트맵 제출, 중요한 페이지의 색인 요청, 헷갈리는 Couldn't fetch 상태 해독, 그리고 모든 크롤러가 찾을 수 있도록 사이트맵을 robots.txt에 연결하기. 군더더기 없이, 실제 명령어로 진행한다.

🧑‍💻 개발자 관점: 사이트맵은 그저 <loc> URL 목록과 선택적인 <lastmod> 힌트가 담긴 XML 문서일 뿐이다. GSC는 Google의 크롤/색인 파이프라인 위에 얹힌 대시보드다. 사이트맵 제출은 “내 URL 목록 여기 있습니다”라는 POST 같은 신호이며, 마법 같은 일은 일어나지 않는다. 단지 “페이지가 존재함”에서 “Googlebot이 가져감”까지의 경로를 짧게 줄여줄 뿐이다.

소유권 확인

GSC가 무언가를 보여주기 전에, 먼저 당신이 그 사이트의 소유자임을 증명해야 한다. GSC는 두 가지 **속성 유형(property type)**을 제공하며, 이 선택은 확인 방법과 볼 수 있는 데이터를 모두 결정하므로 중요하다.

도메인 속성URL 접두어 속성
범위모든 서브도메인 + http/https정확히 하나의 출처(origin)만
범위 예시example.com, www., blog., http & httpshttps://example.com/만
확인 방법DNS TXT 레코드HTML 태그, HTML 파일, GA, GTM, 또는 DNS
*.pages.dev에서 동작아니오 (DNS 편집 불가)예
적합한 경우DNS를 직접 제어하는 사이트서브도메인, 빠른 시작, 세분화된 데이터

도메인 속성은 DNS TXT 레코드로 확인하며, 그 후 도메인 아래의 모든 것 — 모든 서브도메인, 양쪽 프로토콜 — 을 포괄한다. DNS 영역(zone)을 소유하고 있다면 가장 깔끔한 선택지다. GSC가 추가할 토큰을 제공한다:

# Add this as a TXT record on the apex (@) of your zone
google-site-verification=AbC123dEf456GhI789jKl0mNoPqRsTuVwXyZ_example

대부분의 등록 대행업체나 Cloudflare DNS에서는 다음과 같이 추가한다:

Type:  TXT
Name:  @            (or yourdomain.com)
Value: google-site-verification=AbC123...
TTL:   Auto

GSC에서 “확인”을 클릭하기 전에 전파(propagation)가 완료되었는지 검증한다:

dig +short TXT yourdomain.com | grep google-site-verification
# or
nslookup -type=TXT yourdomain.com

URL 접두어 속성은 정확히 하나의 출처를 확인한다 (프로토콜 + 호스트 + 끝의 슬래시가 모두 중요하다 — https://example.com/와 https://www.example.com/는 서로 다른 속성이다). DNS를 건드리지 않고 여러 방법으로 확인할 수 있다:

<!-- Option A: meta tag in the <head> of your homepage -->
<meta name="google-site-verification" content="AbC123dEf456GhI789jKl0..." />
# Option B: upload a verification file to the site root
# GSC gives you something like: google1234567890abcdef.html
# It must be reachable at:
https://example.com/google1234567890abcdef.html

확인하기 전에 파일이 실제로 제공되고 있는지 점검한다:

curl -sI https://example.com/google1234567890abcdef.html | head -n 1
# Expect: HTTP/2 200

⚠️ pages.dev(그리고 유사한 *.vercel.app, *.netlify.app, *.workers.dev)의 함정: DNS를 제어하지 못하는 서브도메인에 대해서는 도메인 속성을 만들 수 없다. pages.dev 영역은 당신이 아니라 Cloudflare가 소유하므로 그 레벨에 추가할 수 있는 TXT 레코드가 없다. 미리보기/스테이징 서브도메인의 경우 URL 접두어 속성을 사용하고 HTML meta 태그나 업로드 파일로 확인하라. 사이트를 자신의 커스텀 도메인에 올리고 나면 도메인 속성으로 전환하라(또는 추가하라).

커스텀 도메인을 쓰는 대부분의 프로덕션 사이트라면 도메인 속성을 사용하라. *.pages.dev URL이나 기타 플랫폼 서브도메인이라면 파일/meta 확인을 쓰는 URL 접두어 속성을 사용하라.

사이트맵 제출

빌드가 사이트맵 인덱스를 생성한다면(대부분의 프레임워크가 그렇다 — 예를 들어 Astro의 sitemap 통합은 하나 이상의 sitemap-0.xml 청크를 가리키는 sitemap-index.xml을 내보낸다), 개별 파일이 아니라 인덱스를 제출한다. Google은 인덱스를 따라가며 모든 자식 파일을 읽는다.

먼저, 파일이 실제로 살아 있고 형식이 올바른지 기본 점검을 한다:

curl -s https://example.com/sitemap-index.xml | head -n 20
# Should return XML, not an HTML 404 page

# Check the status code and content type explicitly
curl -sI https://example.com/sitemap-index.xml | grep -iE 'HTTP/|content-type'
# Expect:
#   HTTP/2 200
#   content-type: application/xml   (or text/xml)

유효한 사이트맵 인덱스는 다음과 같이 생겼다:

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap>
    <loc>https://example.com/sitemap-0.xml</loc>
    <lastmod>2026-06-23T00:00:00.000Z</lastmod>
  </sitemap>
</sitemapindex>

그런 다음 GSC에서:

  1. Search Console → 속성 → 색인 생성 → Sitemaps(왼쪽 사이드바)를 연다.

  2. 새 사이트맵 추가 필드에 속성 루트 기준 상대 경로를 입력한다. 대부분의 사이트에서는 그냥 sitemap-index.xml이다. GSC가 도메인을 미리 채워주므로 경로만 입력하면 된다:

    sitemap-index.xml

  3. 제출을 클릭한다.

  4. 행이 성공(Success) 상태로 나타난다(또는 처음에는 종종 일시적인 상태로 나타난다 — 다음 섹션 참고). 행을 클릭하면 Google이 발견한 URL 수를 볼 수 있다.

💡 인덱스 파일은 한 번만 제출하고, 자식 파일마다 제출하지 마라. Google은 자체 일정에 따라 인덱스를 다시 읽으므로 새 페이지를 게시할 때 다시 제출할 것이 없다. 빌드가 XML을 다시 생성하기만 하면 Google이 다음 패스에서 새 <loc> 항목을 가져간다.

색인 요청

사이트맵을 제출하면 URL이 Google의 발견 대기열에 들어간다. 가장 중요한 몇몇 페이지(홈페이지, 핵심 랜딩 페이지, 최고의 콘텐츠)에 대해서는 URL 검사(URL Inspection) 도구로 Google을 직접 재촉할 수 있다:

  1. GSC 최상단의 검색창(”…에서 URL 검사”라고 표시됨)에 전체 URL을 붙여넣는다.
  2. GSC가 색인에서 해당 URL을 가져와 이미 색인되었는지 보여준다.
  3. **실제 URL 테스트(Test Live URL)**를 클릭해 Google이 현재 버전을 가져올 수 있는지 확인한다(이때 렌더링 문제, robots 차단, noindex 태그도 함께 드러난다).
  4. 문제없어 보이면 **색인 생성 요청(Request Indexing)**을 클릭한다. 이렇게 하면 해당 URL이 우선 크롤 대기열에 추가된다.
Inspect:  https://example.com/                 → "URL is not on Google" → Request Indexing
Inspect:  https://example.com/pricing           → "URL is not on Google" → Request Indexing
Inspect:  https://example.com/blog/launch-post  → "URL is not on Google" → Request Indexing

⚠️ 색인 생성 요청은 속도 제한이 있고(하루 소량 할당량) 개별적으로 중요한 URL을 위한 것이지, 5,000페이지짜리 사이트를 강제로 밀어넣기 위한 것이 아니다. 대량 처리에는 사이트맵이 올바른 도구이며, 크롤링이 알아서 규모에 맞게 일어나도록 두면 된다. 수동 요청은 지금 당장 가장 중요한 5~20개 페이지를 위한 것이다.

”Couldn’t fetch”는 대개 거짓 경보다

새 사이트 소유자들이 가장 흔히 당황하는 순간: sitemap-index.xml을 제출하고 새로고침했는데 상태가 **Couldn't fetch**라고 뜨는 것이다. XML을 다시 쓰기 시작하기 전에 알아둘 것이 있다: 제출 직후 이 상태는 일시적인 경우가 많다. Google이 가져오기를 대기열에 넣었지만 아직 실제로 가져와 처리하지는 않았고, 대시보드가 임시 표시를 보여주는 것이다. 상당수의 경우 당신 쪽에서 아무것도 바꾸지 않아도 몇 시간에서 며칠 안에 **Success**로 바뀐다.

그러니 첫 단계는 진심으로: 1~3일 기다렸다가 다시 확인하라.

그래도 계속된다면 이 체크리스트를 점검하라 — 이것들이 진짜 원인이며, 각각 터미널에서 검증할 수 있다:

  • 200을 반환한다. 사이트맵 URL은 리디렉션 체인, 403, 404, 5xx가 아니라 200 OK로 응답해야 한다.

    curl -sI https://example.com/sitemap-index.xml | head -n 1
# HTTP/2 200   = good   |   anything else (301/302/403/404/5xx) is a problem

  • 올바른 콘텐츠 타입. application/xml 또는 text/xml로 제공하라. 서버가 text/html을 보낸다면(파일 대신 SPA 폴백이나 404 페이지가 반환될 때 흔하다) Google이 거부할 수 있다.

    curl -sI https://example.com/sitemap-index.xml | grep -i content-type
# content-type: application/xml   = good
# content-type: text/html         = bad (you're serving an HTML page, not the sitemap)

  • robots.txt가 차단하지 않는다. 잘못 들어간 Disallow: /sitemap이나 지나치게 광범위한 규칙이 Googlebot의 파일 읽기를 막을 수 있다. robots를 가져와 읽어보라:

    curl -s https://example.com/robots.txt
# Make sure nothing disallows the sitemap path for Googlebot

  • 프로토콜 / 호스트 불일치 없음(교차 출처 함정). 사이트맵 안의 모든 <loc>은 속성 및 사이트맵 파일 자체와 동일한 프로토콜과 호스트에 있어야 한다. 속성이 https://example.com URL 접두어인데 <loc> 항목이 http://나 www.example.com을 가리킨다면, Google은 이를 교차 사이트로 간주하고 무시한다. 몇 개를 표본 점검하라:

    curl -s https://example.com/sitemap-0.xml | grep -oE '<loc>[^<]+' | head
# Every URL should start with https://example.com/ — no http://, no bare www mismatch

  • 사이트맵 경로에 noindex / 인증 장벽 없음. 스테이징 사이트는 종종 HTTP 기본 인증이나 Cloudflare Access 정책 뒤에 있다. 사이트맵에 로그인이 필요하면 Googlebot은 401/403을 받고 가져올 수 없다.

다섯 가지가 모두 통과했는데도 일주일이 지나도록 상태가 풀리지 않으면, URL 검사에서 사이트맵 URL에 대해 실제 URL 테스트를 사용하라 — Googlebot이 보는 정확한 응답을 보여주므로 대개 불일치를 즉시 짚어낸다.

색인되기까지 얼마나 걸리나

솔직하게 기대치를 설정하라. 조급함은 멀쩡한 것을 “고치게” 만들기 때문이다:

사이트 상황첫 페이지가 색인되기까지 일반적인 시간
갓 만든 도메인, 백링크 없음며칠에서 몇 주
자주 크롤링되는 기존 사이트의 새 페이지몇 시간에서 며칠
대형 사이트, 빈약하거나 중복된 콘텐츠느림 / 부분적 — Google이 페이지를 건너뛸 수 있음

발견(Google이 URL의 존재를 아는 것)은 사이트맵을 제출하면 빠르다. 색인 생성(Google이 페이지를 가져오고, 렌더링하고, 평가하고, 저장하기로 결정하는 것)이 시간이 걸리는 부분이며, 단순한 대기열이 아니라 품질과 신뢰 판단이다. 링크도 이력도 없는 새 도메인은 우선순위가 낮은 자리에 놓인다 — 이는 정상이지 버그가 아니다. 계속 게시하고, 몇 개의 링크를 얻으면 크롤 빈도는 알아서 올라간다.

💡 페이지 보고서의 “발견됨 - 현재 색인이 생성되지 않음(Discovered – currently not indexed)“과 “크롤됨 - 현재 색인이 생성되지 않음(Crawled – currently not indexed)“은 오류가 아니다. Google이 URL을 발견(또는 가져오기)했지만 아직 색인하기로 선택하지 않았다는 뜻이며 — 새 사이트에서는 대개 빈약한 콘텐츠나 낮은 우선순위 신호다. 다시 제출하기보다 페이지를 개선하거나 링크를 얻어라.

robots.txt에서 연결하기

GSC 제출은 Google에게만 알린다. robots.txt에 Sitemap: 줄을 추가하면 표준을 준수하는 모든 크롤러 — Bing, DuckDuckGo, 그 외 무엇이든 — 에게 엔진별 대시보드 없이 알릴 수 있다. 한 줄짜리 이중 안전장치이자, 사이트맵을 알리는 정식 방법이다.

# robots.txt
User-agent: *
Allow: /

# Absolute URL, one per line; you can list multiple sitemaps
Sitemap: https://example.com/sitemap-index.xml

사람들이 걸려 넘어지는 몇 가지 규칙:

  • Sitemap: URL은 상대 경로가 아니라 절대 URL(전체 https://...)이어야 한다.
  • 이는 User-agent 블록과 독립적이다 — 파일 어디에 두어도 되며, 관례적으로 맨 위나 맨 아래에 둔다.
  • 사이트맵을 섹션이나 언어별로 나눴다면 여러 개의 Sitemap: 줄을 나열할 수 있다.

살아 있는지 검증하라:

curl -s https://example.com/robots.txt | grep -i sitemap
# Sitemap: https://example.com/sitemap-index.xml

🧑‍💻 이 사이트에서 우리가 한 방법: 바로 이 구성 — 자동 생성된 sitemap-index.xml, robots.txt의 Sitemap: 줄, GSC의 도메인 속성, 그리고 핵심 페이지 몇 개에 대한 색인 생성 요청 재촉. XML을 손으로 편집하지 않고 깔끔한 robots.txt와 사이트맵 항목을 생성하고 싶다면, 우리의 robots & sitemap 도구가 대신 해준다. 그리고 Google이 크롤링을 시작하면, 로그 분석과 크롤 예산 가이드에서 Googlebot이 사이트맵이 알린 URL을 실제로 가져오고 있는지 확인하는 방법을 보여준다.

마무리

전체 흐름을 순서대로:

  1. 소유권 확인 — DNS를 제어한다면 도메인 속성(DNS TXT); pages.dev 및 기타 플랫폼 서브도메인에는 URL 접두어(HTML 태그/파일).
  2. sitemap-index.xml 제출 — 색인 생성 → Sitemaps에서. 자식이 아니라 인덱스를 제출하라.
  3. URL 검사를 통해 가장 중요한 5~20개 URL에 대해 색인 생성 요청.
  4. Couldn't fetch에 당황하지 마라 — 1~3일 기다린 다음 200 / 콘텐츠 타입 / robots / 교차 출처 / 인증 체크리스트를 실행하라.
  5. 인내심을 가져라 — 발견은 빠르지만, 새 도메인의 색인 생성은 며칠에서 몇 주가 걸린다.
  6. 모든 크롤러가 찾을 수 있도록 robots.txt에 Sitemap: 줄을 추가하라.

다음 단계: robots & sitemap 도구로 robots.txt와 사이트맵 구성을 생성한 다음, 크롤 예산 가이드로 서버 로그에서 Googlebot의 동작을 관찰하라. 제출은 Google과의 대화의 시작일 뿐이다 — 로그가 Google이 귀 기울이고 있는지 말해준다.