티스토리 Search Console ‘robots.txt에 의해 차단됨’ 확인 방법｜크롤링 차단과 색인 상태 구분하기

Google Search Console의 페이지 색인 생성 보고서를 확인하다 보면 ‘robots.txt에 의해 차단됨’과 관련된 상태를 발견할 수 있습니다.

처음 보면 내 블로그가 Google 검색에서 차단된 것처럼 느껴질 수 있습니다.

“robots.txt를 바로 수정해야 할까?”

“이 URL은 검색에 절대 나오지 않는 걸까?”

“애드센스 신청 전에 차단된 URL을 모두 해결해야 할까?”

하지만 robots.txt에 의해 차단된 URL이 있다는 사실만으로 블로그 전체에 문제가 있다고 판단할 필요는 없습니다.

robots.txt는 검색엔진 크롤러가 사이트의 어떤 영역을 크롤링할 수 있는지 알려주는 파일입니다. 검색 결과에 반드시 노출되어야 하는 페이지가 차단된 것인지, 검색에 노출될 필요가 없는 URL이 차단된 것인지에 따라 판단이 달라집니다.

또한 robots.txt와 noindex는 같은 기능이 아닙니다.

이번 글에서는 Search Console에서 robots.txt 관련 상태를 발견했을 때 실제 게시글인지 먼저 구분하고, 크롤링 차단과 색인 제외를 혼동하지 않는 방법을 정리해 보겠습니다.

✓ 먼저 robots.txt의 역할을 이해합니다

robots.txt는 검색엔진 크롤러에게 사이트의 특정 경로나 URL을 크롤링해도 되는지 알려주는 규칙입니다.

쉽게 말하면

“이 영역은 크롤링해도 됩니다.”

“이 경로는 크롤링하지 마세요.”

와 같은 안내를 검색엔진에 제공하는 역할입니다.

여기에서 중요한 점은 robots.txt의 주된 역할이 ‘크롤링 제어’라는 것입니다.

따라서 robots.txt를 검색 결과에서 페이지를 완전히 제거하기 위한 기능으로만 이해하면 안 됩니다.

✓ 크롤링과 색인은 서로 다른 과정입니다

Search Console을 사용할 때 자주 혼동하는 부분입니다.

크롤링은 Google이 페이지에 접근해 내용을 가져가는 과정입니다.

색인은 Google이 페이지 정보를 검색 시스템에 저장하고 검색 결과에 활용할 수 있도록 처리하는 과정입니다.

두 과정은 관련되어 있지만 같은 의미는 아닙니다.

따라서

“크롤링 차단 = 무조건 색인 삭제”

처럼 단순하게 생각하면 안 됩니다.

robots.txt는 기본적으로 크롤링을 제어하는 수단이라는 점부터 기억하는 것이 좋습니다.

✓ robots.txt와 noindex는 같은 기능이 아닙니다

robots.txt와 함께 자주 등장하는 용어가 noindex입니다.

두 기능은 목적이 다릅니다.

robots.txt는 검색엔진 크롤러의 접근을 제어합니다.

noindex는 페이지가 검색 결과에 색인되지 않도록 요청하는 지시입니다.

여기서 중요한 문제가 하나 있습니다.

페이지를 robots.txt로 막아 Google이 해당 페이지를 크롤링할 수 없다면 페이지 안에 있는 noindex 지시도 확인하지 못할 수 있습니다.

따라서 검색 결과에서 특정 페이지를 제외하려는 목적으로 robots.txt와 noindex를 같은 기능처럼 사용해서는 안 됩니다.

✓ Search Console에서 어떤 URL이 차단됐는지 확인합니다

robots.txt 관련 상태를 발견했다면 숫자만 보고 설정부터 변경하지 않습니다.

페이지 색인 생성 보고서에서 해당 상태를 선택한 뒤 예시 URL을 확인합니다.

그리고 URL의 종류를 먼저 구분합니다.

일반 게시글인가?

관리 또는 시스템 성격의 주소인가?

검색 결과에 노출되어야 하는 중요한 콘텐츠인가?

내가 만든 기억이 없는 URL인가?

티스토리 플랫폼에서 자동으로 만들어지는 주소인가?

URL의 역할을 확인해야 차단을 해제해야 하는지 판단할 수 있습니다.

✓ 실제 게시글인지부터 확인합니다

가장 먼저 해야 할 일은 해당 URL을 직접 확인하는 것입니다.

예를 들어 Search Console에 robots.txt 차단 URL이 여러 개 표시되어 있다고 가정하겠습니다.

그중 대부분이 일반 게시글이 아닌 시스템성 주소라면 모든 URL을 검색에 노출시킬 이유가 없을 수 있습니다.

반대로 내가 직접 작성한 핵심 정보성 게시글이 차단 상태라면 조금 더 자세한 확인이 필요합니다.

따라서 차단 URL 개수보다 어떤 종류의 URL이 포함되어 있는지가 더 중요합니다.

✓ 브라우저에서 URL을 직접 열어봅니다

Search Console에 표시된 주소를 브라우저에서 직접 열어봅니다.

페이지가 실제로 존재하는지 확인합니다.

정상적인 게시글이 표시되는지도 살펴봅니다.

삭제된 주소인지 확인합니다.

로그인이나 별도의 권한이 필요한 페이지인지도 확인합니다.

검색에 노출될 필요가 없는 기능성 페이지인지도 살펴봅니다.

브라우저에서 정상적으로 열린다고 해서 Googlebot도 반드시 크롤링할 수 있다는 뜻은 아닙니다.

사용자의 브라우저 접근과 검색엔진 크롤러에 적용되는 robots.txt 규칙은 구분해야 합니다.

✓ 중요한 게시글이라면 URL 검사로 확인합니다

검색에 노출되기를 원하는 실제 게시글이 robots.txt와 관련된 상태로 표시된다면 Search Console의 URL 검사를 이용합니다.

URL 검사를 통해 Google이 알고 있는 해당 주소의 상태를 확인합니다.

중요한 것은 Search Console에 표시된 한 문장만 보는 것이 아니라 다른 문제가 함께 존재하는지도 확인하는 것입니다.

실제 게시글이 정상적으로 공개되어 있는지, 현재 접근 상태는 어떤지, Google이 알고 있는 색인 상태는 무엇인지 함께 살펴봅니다.

필요한 경우 실시간 URL 테스트를 이용해 현재 상태도 확인할 수 있습니다.

✓ 실시간 URL 테스트 결과도 구분해서 봅니다

실시간 URL 테스트는 현재 Google의 검사 도구가 페이지에 접근할 수 있는지 확인하는 데 도움이 됩니다.

예전에 robots.txt 차단 문제가 있었지만 현재 설정이 달라졌다면 저장된 Search Console 보고서와 현재 상태가 다를 수도 있습니다.

이럴 때 실시간 테스트가 도움이 될 수 있습니다.

하지만 실시간 테스트에서 접근 가능하다고 표시된다고 해서 바로 색인이 보장되는 것은 아닙니다.

접근 가능 여부와 최종 색인 여부는 별개의 판단입니다.

✓ 검색에 필요 없는 URL이라면 무조건 차단을 해제하지 않습니다

Search Console에 차단된 URL이 있다고 모든 주소의 크롤링을 허용해야 하는 것은 아닙니다.

사이트에는 검색 결과에 반드시 나타날 필요가 없는 URL도 존재할 수 있습니다.

특히 플랫폼이 자동으로 사용하는 기능성 주소나 관리 목적의 영역이라면 검색 노출이 목적이 아닐 수 있습니다.

따라서

“차단된 URL 숫자를 0으로 만들자.”

라는 목표로 robots.txt 설정을 변경하면 안 됩니다.

먼저 해당 URL이 검색 결과에 나타나야 하는 페이지인지 판단하는 것이 우선입니다.

✓ 실제 게시글이 차단됐다면 원인을 더 확인합니다

반대로 내가 작성한 중요한 정보성 게시글이 robots.txt 때문에 크롤링되지 않는다면 확인이 필요합니다.

이 경우 다음 순서로 살펴봅니다.

해당 URL이 실제 게시글 주소인지 확인합니다.

게시글이 공개 상태인지 확인합니다.

브라우저에서 정상적으로 열리는지 확인합니다.

URL 검사에서 현재 상태를 확인합니다.

필요하면 실시간 URL 테스트를 확인합니다.

특정 게시글 하나만 문제인지 비슷한 경로 전체에서 발생하는지 비교합니다.

이 과정을 거치면 개별 게시글 문제인지 URL 경로와 관련된 문제인지 판단하는 데 도움이 됩니다.

✓ 한 URL보다 경로의 공통점을 살펴봅니다

robots.txt는 개별 페이지 하나가 아니라 특정 경로 패턴을 기준으로 크롤링을 제한하는 경우가 있습니다.

따라서 여러 URL이 같은 이유로 차단되어 있다면 주소의 공통점을 확인하는 것이 좋습니다.

예를 들어 차단된 URL이 모두 특정 형태의 경로를 사용한다면 각각의 글에 문제가 있는 것이 아니라 해당 경로에 적용되는 규칙 때문일 수 있습니다.

반대로 일반 게시글 가운데 특정 URL 하나에서만 문제가 나타난다면 다른 원인도 함께 살펴볼 필요가 있습니다.

여러 URL을 비교하면 문제의 범위를 파악하기가 쉬워집니다.

✓ 티스토리에서는 직접 수정할 수 있는 범위를 구분합니다

티스토리는 사용자가 웹 서버 전체를 직접 관리하는 서비스가 아닙니다.

따라서 자체 서버를 운영하는 사이트처럼 모든 robots.txt 설정을 자유롭게 변경할 수 있다고 생각하면 안 됩니다.

Search Console에서 robots.txt 관련 상태를 발견했을 때는 먼저 티스토리 운영자가 직접 관리할 수 있는 범위를 확인합니다.

게시글 공개 상태

실제 게시글 URL

내부 링크

스킨이나 HTML에서 직접 추가한 설정

내가 추가한 검색엔진 관련 코드

이런 부분을 먼저 확인합니다.

플랫폼에서 관리하는 영역을 정확한 이유 없이 억지로 변경하려고 하기보다 검색에 노출되어야 할 실제 게시글에 문제가 있는지를 중심으로 판단하는 것이 좋습니다.

✓ robots.txt를 임의로 수정하기 전에 목적부터 확인합니다

검색 노출 문제가 생기면 인터넷에서 robots.txt 설정 예제를 찾아 그대로 적용하고 싶어질 수 있습니다.

하지만 사이트마다 구조와 운영 환경이 다릅니다.

특히 티스토리처럼 플랫폼이 관리하는 서비스에서는 다른 웹사이트의 robots.txt 설정을 그대로 적용하는 방식이 적절하지 않을 수 있습니다.

무엇을 허용하고 무엇을 차단하는 규칙인지 이해하지 못한 상태에서 설정을 변경하면 원하지 않는 영역의 크롤링에 영향을 줄 수 있습니다.

따라서 실제 중요한 페이지가 차단된 것이 확인되지 않았다면 설정부터 변경하지 않습니다.

✓ 이런 방식으로 대응하지 않습니다

robots.txt 관련 상태를 발견했을 때 다음과 같은 대응은 피하는 것이 좋습니다.

차단된 URL을 모두 검색에 노출시키려고 합니다.

인터넷에서 찾은 robots.txt 코드를 그대로 복사합니다.

robots.txt와 noindex를 같은 기능으로 생각합니다.

차단 URL 숫자를 0으로 만드는 것을 목표로 합니다.

일반 게시글인지 확인하지 않고 설정부터 변경합니다.

검색에 필요 없는 시스템성 URL까지 색인 생성 요청을 합니다.

실시간 URL 테스트가 정상이라는 이유만으로 색인이 보장된다고 생각합니다.

정확한 원인을 모른 채 스킨이나 검색엔진 관련 코드를 반복해서 수정합니다.

✓ 실제 상황별로 판단해 봅니다

A 사례

Search Console에 robots.txt 차단 URL이 표시됩니다.

확인해 보니 일반 게시글이 아니라 검색에 노출될 필요가 없는 기능성 주소입니다.

이 경우 단순히 차단 URL이 존재한다는 이유로 설정을 변경할 필요는 없습니다.

B 사례

내가 작성한 핵심 정보성 게시글이 robots.txt 관련 상태로 표시됩니다.

브라우저에서는 정상적으로 열립니다.

이 경우 URL 검사와 실시간 테스트를 이용해 Google의 현재 접근 상태를 확인하고 같은 형태의 다른 게시글에서도 문제가 나타나는지 비교합니다.

C 사례

과거에는 차단 상태였지만 현재 실시간 URL 테스트에서는 접근이 가능한 것으로 확인됩니다.

이 경우 Search Console 보고서의 갱신이 아직 반영되지 않았을 가능성도 고려할 수 있습니다.

설정을 계속 변경하기보다 현재 페이지 상태를 유지하면서 보고서가 갱신되는지 확인합니다.

D 사례

차단된 URL 수가 많지만 모두 비슷한 경로를 가지고 있습니다.

이 경우 수백 개의 URL을 각각 수정하려 하지 말고 해당 경로가 어떤 목적으로 사용되는지 먼저 확인합니다.

검색에 노출될 필요가 없는 영역이라면 차단 자체가 의도된 상태일 수 있습니다.

✓ robots.txt 최종 체크리스트

□ robots.txt가 크롤링을 제어하는 파일이라는 점을 이해했다.

□ 크롤링과 색인을 같은 의미로 생각하지 않았다.

□ robots.txt와 noindex의 차이를 확인했다.

□ Search Console에서 실제 차단 URL을 확인했다.

□ 일반 게시글인지 기능성 URL인지 구분했다.

□ 중요한 URL은 브라우저에서 직접 열어봤다.

□ 검색에 필요한 게시글은 URL 검사에서 상태를 확인했다.

□ 필요한 경우 실시간 URL 테스트로 현재 접근 상태를 확인했다.

□ 여러 URL이 차단됐다면 주소의 공통점을 살펴봤다.

□ 차단 URL 숫자를 0으로 만들기 위해 무작정 설정을 변경하지 않았다.

□ 티스토리에서 직접 관리할 수 있는 범위를 구분했다.

자주 묻는 질문

Q1. robots.txt에 의해 차단되면 검색에 절대 나오지 않나요?

robots.txt는 기본적으로 크롤링을 제어하는 수단입니다. 따라서 단순히 ‘robots.txt 차단 = 검색 결과에서 완전 삭제’라고 생각하면 안 됩니다. 검색에서 특정 페이지를 제외하는 문제와 크롤링 차단은 구분해서 이해하는 것이 좋습니다.

Q2. robots.txt와 noindex는 같은 기능인가요?

아닙니다. robots.txt는 크롤러의 접근을 제어하고 noindex는 페이지를 검색 결과에 색인하지 않도록 요청하는 지시입니다. 페이지가 robots.txt로 차단되어 Google이 페이지를 크롤링하지 못한다면 페이지 안의 noindex를 확인하지 못할 수도 있습니다.

Q3. 차단된 URL은 모두 허용해야 하나요?

그럴 필요는 없습니다. 검색 결과에 노출될 필요가 없는 URL이라면 크롤링이 제한되어 있어도 문제가 아닐 수 있습니다. 실제 게시글처럼 검색 노출이 필요한 페이지가 차단된 것인지 먼저 확인해야 합니다.

Q4. robots.txt 상태를 수정했는데 Search Console에는 계속 표시됩니다. 왜 그런가요?

Search Console 보고서는 변경 사항이 즉시 반영되지 않을 수 있습니다. 현재 상태가 달라졌다면 중요한 URL에서 실시간 테스트 등을 이용해 확인하고 보고서가 다시 처리될 시간을 두고 살펴보는 것이 좋습니다.

Q5. robots.txt 차단 URL이 있으면 애드센스 신청에 문제가 되나요?

차단된 URL이 존재한다는 사실 하나만으로 애드센스 승인 여부를 판단할 수 없습니다. Search Console의 색인·크롤링 상태와 애드센스 심사는 별개의 시스템입니다. 검색에 노출되어야 할 핵심 콘텐츠가 정상적으로 접근 가능한지를 중심으로 점검하는 것이 좋습니다.

마무리｜차단을 없애기 전에 검색에 필요한 URL인지 확인합니다

Search Console에서 ‘robots.txt에 의해 차단됨’이라는 상태를 발견하면 가장 먼저 설정을 변경하고 싶어질 수 있습니다.

하지만 먼저 해당 URL의 역할을 확인해야 합니다.

검색에 노출될 필요가 없는 기능성 URL이라면 크롤링이 제한되어 있는 것이 문제가 아닐 수 있습니다.

반대로 직접 작성한 중요한 정보성 게시글이 차단되어 있다면 실제 URL을 확인하고 URL 검사와 현재 접근 상태를 살펴볼 필요가 있습니다.

또한 robots.txt는 크롤링을 제어하는 수단이며 noindex와 같은 기능이 아닙니다.

검색에서 제외하고 싶은 페이지를 robots.txt로 막는 것과 검색엔진이 페이지를 크롤링한 뒤 noindex를 확인하는 것은 서로 다른 과정입니다.

티스토리에서는 모든 서버 설정을 직접 관리할 수 있는 것도 아니므로 정확한 원인을 확인하지 않은 상태에서 robots.txt 관련 설정을 무작정 변경하지 않는 것이 좋습니다.

Search Console 관리의 목표는 차단된 URL을 모두 없애는 것이 아닙니다.

검색에 노출되어야 할 핵심 게시글을 Google이 정상적으로 크롤링할 수 있는지를 확인하는 것이 더 중요합니다.

함께 보면 좋은 글

티스토리 Search Console ‘리디렉션이 포함된 페이지’ 확인 방법｜정상 이동과 점검할 URL 구분하기

티스토리 Search Console ‘리디렉션이 포함된 페이지’ 확인 방법｜정상 이동과 점검할 URL 구분하

다음 글 예고

티스토리 Search Console ‘noindex 태그에 의해 제외됨’ 확인 방법｜검색 제외가 정상인지 점검하기

다음 글에서는 noindex가 적용된 URL을 발견했을 때 해당 페이지가 원래 검색에서 제외되어야 하는 페이지인지, 실제 정보성 게시글이 잘못 제외된 것인지 구분하는 방법을 정리하겠습니다.

robots.txt와 noindex의 차이를 실제 점검 과정에 적용하고, URL 검사와 페이지 상태를 통해 확인할 부분까지 살펴보겠습니다.