색인 (Indexing) 이해하기

🤔 크롤러는 다녀갔는데 검색되지 않을 때

페이지 내용을 가져온 것과 검색할 수 있도록 저장한 것은 다릅니다. 색인(Indexing)은 검색엔진이 내용을 분석해 검색에 사용할 정보를 데이터베이스에 정리하는 과정입니다. 주소를 알고 방문하는 크롤링과 구분합니다.

📚 도서관의 책과 목록으로 이해하기

도서관에 책이 도착했다고 바로 대출 가능한 목록에 오르는 것은 아닙니다. 사서가 내용과 분류를 확인하고 목록에 등록하는 과정이 필요합니다. 웹페이지를 가져오는 일은 책의 도착에, 색인은 목록을 만드는 일에 비유할 수 있습니다.

같은 내용의 책이 있거나 비치하지 말라는 요청이 있으면 처리 방식이 달라질 수 있습니다. 다만 실제 도서관이 같은 책을 여러 권 보유하기도 하듯, 이 비유로 검색엔진의 모든 규칙을 설명할 수는 없습니다. 짧은 글이나 중복된 주제라는 이유만으로 무조건 제외된다고 단정하지 않습니다.

🕷️ 크롤러와 구글봇(Googlebot)이 페이지를 찾아오는 방법

검색엔진 크롤러(Crawler)는 웹페이지를 자동으로 방문해 내용을 가져오는 프로그램입니다. Google 검색에서 이 일을 하는 크롤러의 이름이 Googlebot(구글봇)입니다. Google은 검색이 크롤링, 색인 생성, 검색결과 게재의 세 단계로 이루어진다고 설명하며, 구글봇은 첫 단계인 크롤링을 맡습니다. 도서관 비유로 보면 구글봇은 새 책을 찾아 도서관으로 가져오는 일을 합니다.

구글봇이 새 페이지를 가져오려면 먼저 그 주소를 알아야 합니다. Google이 새 주소를 알게 되는 대표 경로는 세 가지입니다.

Google 문서는 검색 정책을 지킨 페이지라도 크롤링, 색인, 게재를 보장하지 않는다고 밝힙니다. 주소를 알아도 바로 방문하지 않을 수 있고, 방문해도 색인까지 끝난 것은 아닙니다. 구글봇은 사람처럼 로그인하지 않으므로 로그인 뒤에만 보이는 본문을 가져갈 것이라고 기대하지 않습니다.

크롤링 예산(Crawl Budget)은 구글봇이 한 사이트에서 가져올 수 있고 가져오려는 페이지의 분량을 뜻합니다. Google의 크롤링 예산 안내는 고유 페이지가 100만 개 이상이면서 일주일에 한 번쯤 내용이 바뀌는 사이트, 1만 개 이상이면서 매일 내용이 바뀌는 사이트 같은 큰 사이트를 대상으로 합니다. 그보다 작은 사이트는 사이트맵을 최신으로 유지하고 서치 콘솔의 페이지 색인 생성 보고서를 주기적으로 보는 것으로 충분하다고 안내합니다.

🚦 발견과 크롤링 및 색인 상태

Google의 Search Console은 사이트 처리 상태를 보여 주는 도구입니다. 다음은 상태 이름을 읽는 기본 방법입니다. 표시 언어와 화면에 따라 문구가 다를 수 있습니다.

크롤링에도 언제 무엇을 가져올지 정하는 판단이 있습니다. 색인 단계에서는 내용과 메타 정보, 중복과 대표 URL 등을 처리합니다. 대표 URL(canonical)은 비슷한 여러 주소 중 대표로 삼을 주소입니다. 사이트가 제안한 주소와 Google이 선택한 주소가 다를 수 있습니다.

주소 발견과 내용 수집 및 색인 상태를 나눠 확인합니다. 상태 이름만으로 원인을 확정하지 않습니다.

🔎 서치 콘솔 URL 검사로 확인하고 색인 생성 요청하기

URL 검사는 서치 콘솔에 주소 하나를 넣어 Google이 그 페이지를 어떻게 처리했는지 보는 기능입니다. 서치 콘솔을 쓰려면 사이트 소유권을 확인하거나, 이미 등록된 사이트의 소유자에게 권한을 받아야 합니다. 권한이 있는 사이트를 고른 뒤 URL 검사에 그 사이트의 전체 주소를 넣으면 결과가 나옵니다.

처음 나오는 결과는 Google이 색인에 저장해 둔 기록입니다. 서치 콘솔 도움말도 이 결과가 실시간 테스트가 아니라고 밝힙니다. 결과 화면에서 아래 항목을 읽습니다.

크롤링이 막힌 주소는 구글봇이 본문의 noindex를 읽지 못하므로, 색인 생성 허용 여부 한 항목만 보고 판단하지 않습니다. 사용자 선언 표준 URL과 Google에서 선택한 표준 URL이 다르면 정규 URL 수업의 신호들을 함께 봅니다.

페이지를 고친 뒤에는 실제 URL 테스트 버튼으로 실시간 테스트를 실행해 지금 상태를 다시 검사합니다. 실시간 테스트는 그 순간 페이지를 새로 가져와 보는 검사이므로, 저장된 기록과 결과가 다를 수 있습니다. 실시간 테스트에서 가져오기에 성공해도 고친 내용이 색인에 반영됐다는 뜻은 아닙니다.

고친 내용을 Google이 다시 가져가 주기를 바라면 색인 생성 요청 버튼을 누릅니다. 요청하려면 서치 콘솔에 등록된 그 사이트(속성)의 소유자나 전체 사용자 권한이 필요하고, 하루에 보낼 수 있는 요청 수에 제한이 있습니다. Google 문서는 같은 주소를 여러 번 요청해도 더 빨리 크롤링되지 않는다고 안내합니다. 바뀐 주소가 많으면 주소를 하나씩 요청하는 대신 아래 사이트맵 절의 방법으로 알립니다.

여러 주소의 상태를 한꺼번에 보려면 서치 콘솔의 페이지 색인 생성 보고서를 엽니다. 이 보고서는 색인되지 않은 주소를 사유별로 묶어 보여 줍니다. 앞 절의 발견됨, 크롤링됨 상태 외에도 다른 대표 주소로 처리된 경우, noindex로 제외된 경우, robots.txt에 막힌 경우가 사유로 따로 나옵니다.

🚫 색인되지 않을 때 확인할 항목

noindex는 색인하지 말라는 설정입니다. Google이 이 지시를 읽으려면 noindex가 적힌 페이지를 가져올 수 있어야 합니다. 크롤러의 접근 규칙 파일인 robots.txt로 크롤링부터 차단하면 페이지 안의 noindex를 읽지 못할 수 있습니다. 두 설정의 차이는 아래 robots.txt 절에서 자세히 다룹니다. 비공개 자료의 보안은 이 설정만으로 해결하지 않습니다.

정규 URL과 중복도 확인합니다. 대표 주소를 지정하는 canonical은 강한 신호이지만 반드시 그대로 따르는 명령은 아닙니다. 비슷한 페이지의 대표가 다른 주소라면 원래 검사한 주소와 선택된 대표 주소를 함께 봅니다. 모든 변형 주소가 따로 색인되는 것이 목표는 아닙니다.

실제 내용과 렌더링을 확인합니다. 렌더링은 HTML과 코드를 처리해 페이지의 내용과 화면을 구성하는 과정입니다. 제목은 있는데 중요한 본문이 비어 있거나 오류 화면을 돌려줄 수 있습니다. 사람이 보는 결과와 검색엔진이 처리한 내용을 비교합니다. 글자 수를 채우는 것보다 페이지가 필요한 정보를 제공하는지와 고유한 역할이 있는지를 봅니다.

처리 시점도 봅니다. 새 페이지나 수정된 페이지를 처리하는 데 시간이 걸릴 수 있고 정해진 완료 기한은 없습니다. 수정 전 기록을 보고 현재도 같은 상태라고 판단하지 않도록 마지막 크롤링과 검사 시점을 확인합니다.

🤖 robots.txt로 크롤링 막기와 noindex의 차이

robots.txt는 사이트 최상위 주소에 두는 텍스트 파일로, 크롤러에게 어느 경로를 방문하지 말라고 알리는 규칙 목록입니다. 파일은 https://example.com/robots.txt처럼 사이트 최상위에 두어야 하고, 규칙은 robots.txt 파일과 호스트, 프로토콜, 포트 번호가 모두 같은 주소에만 적용됩니다. 호스트는 example.com이나 shop.example.com 같은 사이트 이름, 프로토콜은 http나 https 같은 통신 방식, 포트 번호는 서버가 요청을 받는 번호입니다. 그래서 https://example.com/robots.txt의 규칙은 http://example.com이나 하위 도메인인 shop.example.com에는 적용되지 않습니다.

아래는 규칙을 읽기 위한 가상 예시이며 운영 파일에 그대로 붙여 넣지 않습니다.

• User-agent: 규칙을 적용할 크롤러의 이름입니다. *는 파일 안에 자기 이름으로 된 User-agent 줄이 따로 없는 크롤러 모두를 뜻합니다.
• Disallow: 방문하지 말라고 지정하는 경로입니다.
• Allow: 방문을 허용하는 경로입니다. 위 예시에서는 막아 둔 /admin/ 안의 예외입니다.
• Sitemap: 사이트맵 파일의 주소를 알립니다. 차단과 상관없이 주소 발견을 돕는 줄입니다.

한 경로에 Disallow와 Allow가 함께 해당하면 Google은 경로가 더 긴 규칙, 즉 더 구체적인 규칙을 따릅니다. 경로 길이가 같은 Disallow와 Allow가 충돌하면 Google은 덜 제한적인 Allow 규칙을 씁니다. 위 예시 파일에 구글봇(Googlebot) 이름으로 된 User-agent 줄이 따로 없다고 가정하면, 구글봇은 경로 세 개를 아래처럼 처리합니다.

robots.txt와 noindex는 막는 대상이 다릅니다. robots.txt는 크롤러의 방문을 막고, noindex는 가져온 페이지를 검색 색인에 넣지 말라고 지시합니다.

그래서 페이지를 검색 결과에서 빼려면 robots.txt로 막지 않고 noindex를 씁니다. Google 문서도 noindex가 작동하려면 그 페이지가 robots.txt로 막혀 있지 않아야 한다고 안내합니다. robots.txt는 접근을 막는 보안 장치가 아니고 누구나 열어 볼 수 있는 공개 파일이므로, 비공개 자료는 로그인이나 서버의 접근 제한으로 보호합니다.

robots.txt에서 자주 생기는 사고는 세 가지입니다.

• 개발 중 쓴 전체 차단이 그대로 배포되는 사고: 모든 경로를 막는 Disallow: / 줄이 공개 사이트에 남으면 구글봇이 사이트 전체를 가져가지 못합니다.
• 스타일과 스크립트 폴더를 막는 사고: 페이지 모양을 정하는 CSS 파일이나 동작을 만드는 JavaScript 파일을 막으면 Google이 페이지를 제대로 구성해 보지 못할 수 있습니다.
• 검색 결과에서 지우려고 차단만 거는 사고: 구글봇이 페이지에 들어가지 못해 noindex를 읽지 못하므로 주소가 검색 결과에 남을 수 있습니다.

GPTBot이나 ClaudeBot 같은 AI 크롤러를 이름별로 허용하거나 막는 방법은 AI 크롤러와 페이지 구조 수업에서 이어집니다.

🗺️ 사이트맵(sitemap.xml)으로 주소 알리기

사이트맵(Sitemap)은 검색엔진에 알려 줄 페이지 주소를 모은 목록 파일입니다. 보통 태그로 구조를 표시하는 텍스트 형식인 XML로 만들고, https://example.com/sitemap.xml 같은 주소에 둡니다. 링크가 적은 페이지도 사이트맵에 적어 두면 Google이 주소를 알 수 있습니다.

아래는 주소 하나를 담은 사이트맵 예시입니다. example.com은 설명용 주소입니다.

urlset은 목록 전체를 감싸고, url은 주소 하나의 묶음입니다. loc에는 페이지의 전체 주소를 적으며 빠뜨릴 수 없는 항목입니다.

lastmod는 그 페이지를 마지막으로 의미 있게 고친 날짜입니다. Google은 lastmod 값이 일관되고, 페이지의 실제 수정 시점과 대조했을 때 정확할 때 이 값을 활용합니다. 사이트맵 파일을 다시 만든 날짜를 넣거나 내용은 그대로인데 날짜만 매일 바꾸면 값이 부정확해집니다. 예를 들어 10월 2일에 모임 장소를 고치고 10월 3일에 사이트맵 파일만 다시 만들었다면 lastmod는 10월 2일입니다. 변경 빈도를 적는 changefreq와 상대적 중요도를 적는 priority는 Google이 무시하는 항목이므로, 순위를 올리려고 값을 바꿀 필요가 없습니다.

사이트맵을 Google에 알리는 방법은 두 가지이며 함께 써도 됩니다.

Google은 사이트맵 제출이 힌트일 뿐이며, 사이트맵을 내려받거나 크롤링에 쓰는 것을 보장하지 않는다고 안내합니다. 사이트맵 제출에 성공한 것과 그 안의 페이지가 색인된 것은 다른 일이므로 페이지별 상태는 URL 검사로 따로 봅니다. 운영 사이트맵에는 검색에 내보낼 대표 주소만 넣습니다. noindex를 건 페이지를 사이트맵에 넣으면 색인하지 말라는 지시와 이 페이지가 있다는 안내를 동시에 보내게 됩니다.

🔍 상태에 맞게 다음 행동 정하기

공개할 회사 소개 페이지에 noindex가 남았다면 의도한 공개 범위를 확인하고 설정을 수정합니다. 수정 후 Google이 다시 가져와 처리했는지 확인해야 합니다. 설정을 지운 순간 검색에 표시됐다고 보고하지 않습니다.

상품 페이지가 비슷하다면 실제 차이가 무엇인지와 대표 주소 선택이 맞는지 확인합니다. 문장 한 문단을 추가하면 색인된다는 정답은 없습니다. 원래 같은 상품의 정렬 주소라면 중복을 더 만드는 대신 대표 주소와 링크를 정리할 수 있습니다.

태그 페이지도 역할에 따라 판단합니다. 글 두 개를 묶었어도 명확한 안내를 제공한다면 유용할 수 있습니다. 반대로 의미 없는 자동 목록을 늘리는 것은 도움이 되지 않습니다. 색인 수를 무조건 늘리기보다 검색에 제공할 페이지가 적절히 처리됐는지 확인합니다.

❓ 자주 묻는 질문

크롤링됐는데 색인되지 않으면 링크를 고칠 필요가 없나요?

그렇게 단정할 수 없습니다. 내용과 기술적 조건 및 대표 주소를 함께 확인합니다. 링크는 페이지의 발견과 관계를 이해하는 데 도움이 되지만 링크 추가나 사이트맵 재제출만으로 색인을 보장하지는 않습니다.

며칠 기다리면 반드시 색인되나요?

보장된 기간은 없습니다. 크롤링과 처리가 늦을 수도 있고 다른 원인이 있을 수도 있습니다. 현재 보고서와 URL 검사 결과를 보고 필요한 수정과 재확인 시점을 정합니다. 크롤링됨 상태라는 이유만으로 같은 주소를 반복 제출할 필요는 없습니다.

색인됐는데도 검색 결과에서 못 찾을 수 있나요?

있습니다. 검색어와 관련성 및 결과 선택에 따라 노출이 달라집니다. 실제 클릭과 노출은 검색 실적 보고서로 확인하며 특정 검색 화면 하나만으로 색인 여부를 확정하지 않습니다.

robots.txt로 막으면 검색 결과에서 사라지나요?

사라진다고 보장할 수 없습니다. robots.txt로 막아도 다른 사이트의 링크로 알려진 주소는 색인될 수 있고, 구글봇이 페이지에 들어가지 못하면 페이지 안의 noindex도 읽지 못합니다. 검색 결과에서 빼려면 robots.txt 차단을 풀고 noindex를 읽을 수 있게 둡니다.

📝 같은 상태에서 다른 원인 찾기

메모장에 가상 자료를 적습니다. 실제 사이트 설정을 바꾸지 않습니다.

A는 공개 범위를 확인한 뒤 noindex를 검토할 근거가 있습니다. B는 C가 의도한 대표인지부터 확인합니다. 둘 다 “글을 길게 쓰기”로 처리하면 확인한 차이를 무시한 것입니다.

이번에는 A의 공개 조건을 “회원만 볼 비공개 자료”로 바꿉니다. 검색에 안 나온다고 noindex나 로그인을 해제하면 안 됩니다. 유지할 접근 제한과 색인 정책을 확인합니다. 같은 미색인 상태라도 다음 행동이 달라지는 이유를 설명하면 첫 연습을 마친 것입니다.

실제 사이트의 상태를 확인할 권한이 있다면 앞의 서치 콘솔 URL 검사 절 순서대로 주소 하나를 검사합니다.

📋 3줄 요약

1. 색인 생성은 페이지 내용을 분석해 검색에 사용할 정보를 저장하는 과정이며 크롤링과 구분합니다.

2. 미색인 상태만으로 원인을 단정하지 않고 설정과 대표 주소 및 실제 내용과 처리 시점을 확인합니다.

3. 필요한 수정을 한 뒤 재처리 상태를 확인하며 색인 수나 특정 검색어의 순위를 자동으로 보장하지 않습니다.

참고 자료

• Google 색인 처리 과정
• 페이지 색인 생성 보고서
• noindex 적용 조건
• 대표 URL 지정의 신호
• Google 크롤링 예산 안내
• 서치 콘솔 URL 검사 도구
• Google 재크롤링 요청
• Google의 robots.txt 해석
• robots.txt의 용도와 한계
• Google 사이트맵 작성과 제출

공식 문서 확인: 2026년 10월 3일. 크롤러, URL 검사, robots.txt, 사이트맵 문서 확인: 2026년 10월 24일.