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

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

처음 보면 Google이 내 페이지를 강제로 검색에서 제외한 것처럼 느껴질 수 있습니다.

“내 게시글에 문제가 생긴 걸까?”

“noindex를 바로 삭제해야 할까?”

“애드센스 신청 전에 제외된 페이지를 모두 색인시켜야 할까?”

하지만 noindex가 적용된 URL이 있다고 해서 무조건 문제가 발생한 것은 아닙니다.

검색 결과에 표시될 필요가 없는 페이지라면 noindex가 의도적으로 사용될 수 있습니다.

반대로 검색 유입을 받아야 하는 정상적인 정보성 게시글에 noindex가 적용되어 있다면 확인이 필요합니다.

따라서 중요한 것은 Search Console의 제외 URL 숫자를 0으로 만드는 것이 아니라 어떤 URL이 제외되었는지를 구분하는 것입니다.

이번 글에서는 ‘noindex 태그에 의해 제외됨’ 상태를 발견했을 때 정상적인 검색 제외인지, 실제 게시글을 점검해야 하는 상황인지 확인하는 방법을 정리해 보겠습니다.

✓ 먼저 noindex가 무엇인지 이해합니다

noindex는 검색엔진에 해당 페이지를 검색 색인에 포함하지 않도록 요청하는 지시입니다.

Google이 페이지를 크롤링하고 noindex 지시를 확인하면 해당 페이지를 검색 결과에서 제외할 수 있습니다.

따라서 일반적으로 검색 노출을 원하는 정보성 게시글에는 noindex가 적용되어 있지 않아야 합니다.

반대로 검색 결과에 표시할 필요가 없는 페이지라면 noindex가 의도적으로 사용될 수도 있습니다.

핵심은 noindex가 있다는 사실 자체보다 어떤 페이지에 적용되어 있는지를 확인하는 것입니다.

✓ 지난 글의 robots.txt와 noindex는 역할이 다릅니다

robots.txt와 noindex는 자주 혼동되지만 같은 기능이 아닙니다.

robots.txt는 검색엔진 크롤러가 특정 URL이나 경로를 크롤링할 수 있는지를 제어하는 데 사용됩니다.

noindex는 검색엔진이 페이지를 확인한 뒤 해당 페이지를 검색 색인에 포함하지 않도록 요청하는 지시입니다.

즉,

robots.txt → 크롤링 접근 제어

noindex → 검색 색인 제외 요청

으로 구분해서 이해하면 쉽습니다.

검색 결과에서 페이지를 제거하려고 robots.txt로 크롤링까지 막으면 Google이 페이지 내부의 noindex를 확인하지 못할 수 있으므로 두 기능을 같은 방식으로 사용하면 안 됩니다.

✓ Search Console에서 실제 제외 URL부터 확인합니다

페이지 색인 생성 보고서에서 noindex 관련 상태를 발견했다면 숫자만 보고 설정부터 변경하지 않습니다.

해당 항목을 열어 예시 URL을 확인합니다.

그리고 각각의 주소가 어떤 페이지인지 구분합니다.

내가 작성한 일반 게시글인가?

검색 유입을 받아야 하는 핵심 콘텐츠인가?

관리나 기능을 위한 페이지인가?

내가 만든 기억이 없는 주소인가?

티스토리에서 자동으로 생성하거나 관리하는 페이지인가?

삭제하거나 공개 상태를 변경했던 페이지인가?

이렇게 URL의 역할부터 확인해야 실제 문제가 있는지 판단할 수 있습니다.

✓ 검색에 노출될 필요가 없는 페이지인지 먼저 판단합니다

모든 URL이 Google 검색 결과에 나타나야 하는 것은 아닙니다.

블로그에도 검색 결과에서 독립적으로 노출될 필요가 없는 페이지가 있을 수 있습니다.

따라서 noindex 상태를 발견했다고 모든 페이지의 noindex를 제거하는 것은 적절하지 않습니다.

먼저 해당 페이지가 검색 결과에서 방문자를 받아야 하는 콘텐츠인지 생각합니다.

정보를 제공하기 위해 직접 작성한 정상 게시글이라면 검색 노출이 필요한 경우가 많습니다.

반면 검색 사용자가 독립적으로 찾아야 할 필요가 없는 기능성 페이지라면 제외 상태가 자연스러울 수도 있습니다.

✓ 중요한 게시글이라면 브라우저에서 직접 확인합니다

검색에 노출되어야 하는 게시글이 noindex 상태로 표시된다면 해당 URL을 브라우저에서 직접 열어봅니다.

게시글이 정상적으로 표시되는지 확인합니다.

공개 상태인지 확인합니다.

잘못된 페이지로 이동하지 않는지도 살펴봅니다.

삭제된 게시글이 아닌지도 확인합니다.

현재도 검색에 노출시키고 싶은 콘텐츠인지 다시 판단합니다.

Search Console의 상태만 보고 수정하기보다 실제 페이지의 현재 상태를 먼저 확인하는 것이 좋습니다.

✓ URL 검사에서 Google이 알고 있는 상태를 확인합니다

중요한 게시글은 Search Console의 URL 검사를 이용해 개별적으로 확인합니다.

Google이 해당 URL에 대해 알고 있는 색인 상태와 관련 정보를 살펴봅니다.

특히 최근 설정을 변경했거나 페이지를 수정했다면 Search Console에 저장된 정보와 현재 페이지 상태가 다를 수 있습니다.

이 경우 필요하면 실시간 URL 테스트를 통해 현재 Google의 검사 도구가 페이지를 어떻게 확인하는지도 살펴볼 수 있습니다.

다만 실시간 테스트 결과가 정상이라고 해서 바로 검색 결과에 색인되는 것은 아닙니다.

✓ 과거 noindex와 현재 상태가 다를 수도 있습니다

예전에 비공개였거나 검색 제외 설정이 적용된 페이지를 나중에 정상적으로 공개한 경우를 생각해 보겠습니다.

현재는 문제가 해결됐더라도 Search Console 보고서에는 이전 상태가 일정 기간 남아 있을 수 있습니다.

따라서 중요한 것은 현재 페이지가 어떤 상태인지 확인하는 것입니다.

현재 noindex가 제거되어 있고 페이지 접근에도 문제가 없다면 같은 설정을 계속 수정하기보다 Google이 페이지를 다시 처리하고 Search Console 보고서가 갱신되는지 확인할 수 있습니다.

보고서가 즉시 변경되지 않는다는 이유만으로 설정을 반복해서 바꿀 필요는 없습니다.

✓ 실제 게시글에 noindex가 있다면 원인을 확인합니다

검색에 노출하려는 정상 게시글이 현재도 noindex 상태라면 조금 더 자세한 점검이 필요합니다.

먼저 해당 게시글 하나에서만 나타나는 문제인지 확인합니다.

같은 시기에 작성한 다른 게시글에서도 나타나는지 살펴봅니다.

특정 카테고리나 특정 형태의 URL에 집중되어 있는지도 확인합니다.

직접 스킨 HTML이나 검색엔진 관련 코드를 수정한 적이 있다면 그 부분도 점검 대상이 될 수 있습니다.

중요한 것은 원인을 모른 채 noindex 관련 코드를 무작정 삭제하는 것이 아니라 어디에서 적용되고 있는지를 먼저 파악하는 것입니다.

✓ 페이지 소스를 확인할 때는 정확한 의미를 알아야 합니다

직접 HTML을 확인할 수 있다면 robots 관련 메타 태그에서 noindex 지시가 존재하는지 살펴볼 수 있습니다.

하지만 HTML이나 메타 태그에 익숙하지 않다면 인터넷에서 찾은 코드를 임의로 추가하거나 삭제하지 않는 것이 좋습니다.

특히 스킨 전체에 적용되는 부분을 잘못 수정하면 게시글 하나가 아니라 여러 페이지에 영향을 줄 수 있습니다.

검색 노출 문제가 특정 글 하나에서 발생한 것인지 블로그 전체에서 발생한 것인지 먼저 구분한 뒤 접근하는 것이 안전합니다.

✓ noindex를 제거해도 즉시 색인되는 것은 아닙니다

이 부분도 자주 오해할 수 있습니다.

noindex를 제거하면 Google이 해당 페이지를 색인할 수 있는 조건 중 하나가 달라진 것입니다.

하지만

“noindex 제거 = 즉시 색인”

을 의미하지는 않습니다.

Google이 페이지를 다시 크롤링하고 변경된 상태를 확인해야 할 수 있으며, 최종적으로 해당 페이지를 색인할지는 별도의 과정에서 결정됩니다.

따라서 noindex 문제를 수정한 직후 검색 결과에 나타나지 않는다고 같은 설정을 반복해서 변경할 필요는 없습니다.

✓ 정상적으로 수정했다면 URL 검사를 다시 활용합니다

검색에 노출되어야 하는 중요한 게시글에서 잘못된 noindex가 제거된 것을 확인했다면 URL 검사를 다시 활용할 수 있습니다.

현재 페이지가 정상적으로 공개되어 있는지 확인합니다.

필요하면 실시간 URL 테스트로 현재 상태를 점검합니다.

페이지가 정상적으로 접근 가능하고 색인 방해 요소가 해결된 것을 확인했다면 중요한 URL에 대해 색인 생성 요청을 검토할 수 있습니다.

다만 색인 생성 요청 역시 색인을 보장하거나 즉시 처리하는 기능은 아닙니다.

같은 URL에 반복적으로 요청할 필요도 없습니다.

✓ robots.txt로 noindex 페이지를 동시에 막지 않습니다

검색에서 제외하려는 페이지에 noindex를 사용하면서 동시에 robots.txt로 Google의 크롤링까지 차단하는 방식은 주의해야 합니다.

Google이 페이지를 크롤링하지 못하면 페이지 내부의 noindex 지시를 직접 확인하지 못할 수 있기 때문입니다.

따라서

“검색에서 빼고 싶으니 robots.txt도 막고 noindex도 넣으면 더 확실하다.”

라고 단순하게 생각하지 않는 것이 좋습니다.

크롤링 제어와 색인 제외는 서로 다른 목적을 가진 기능입니다.

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

티스토리는 자체 서버를 직접 운영하는 사이트와 다릅니다.

플랫폼에서 관리하는 페이지와 운영자가 직접 관리할 수 있는 영역이 함께 존재합니다.

따라서 noindex URL이 발견됐다고 모든 기술적 설정을 직접 수정하려고 할 필요는 없습니다.

먼저 확인할 것은 다음과 같습니다.

게시글이 공개 상태인지

정상적인 게시글 URL인지

스킨 HTML을 직접 수정한 적이 있는지

검색엔진 관련 메타 태그를 추가한 적이 있는지

특정 플러그인이나 코드 변경 후 문제가 시작됐는지

검색에 노출되어야 할 실제 게시글에서 문제가 발생했는지

이 범위를 먼저 확인한 뒤 필요한 경우에만 수정하는 것이 좋습니다.

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

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

모든 noindex를 무조건 제거합니다.

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

검색에 필요 없는 페이지까지 색인 생성 요청을 합니다.

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

HTML 코드를 이해하지 못한 상태에서 스킨 전체를 수정합니다.

noindex를 제거한 뒤 몇 시간마다 색인 생성 요청을 반복합니다.

색인이 바로 되지 않는다는 이유로 게시글을 삭제하고 다시 발행합니다.

중요한 것은 Search Console 숫자를 줄이는 것이 아니라 검색에 필요한 페이지가 올바른 상태인지 확인하는 것입니다.

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

A 사례

Search Console에 noindex로 제외된 URL이 있습니다.

확인해 보니 검색 결과에 독립적으로 노출될 필요가 없는 기능성 페이지입니다.

이 경우 제외되어 있다는 이유만으로 noindex를 제거할 필요는 없습니다.

B 사례

직접 작성한 핵심 정보성 게시글이 noindex로 제외되어 있습니다.

현재도 검색 유입을 받아야 하는 글입니다.

이 경우 페이지 공개 상태와 URL 검사를 확인하고 현재도 noindex가 적용되어 있는지 점검해야 합니다.

C 사례

과거에는 noindex 상태였지만 현재 실시간 URL 테스트에서는 색인 가능 상태로 확인됩니다.

이 경우 과거 상태가 Search Console 보고서에 아직 남아 있을 가능성을 고려합니다.

설정을 반복해서 변경하기보다 Google이 다시 처리할 시간을 두고 확인할 수 있습니다.

D 사례

여러 정상 게시글이 동시에 noindex로 제외되기 시작했습니다.

최근 스킨이나 검색엔진 관련 코드를 수정한 적이 있습니다.

이 경우 각 게시글을 하나씩 수정하기보다 여러 페이지에 공통적으로 적용되는 설정이 있는지 먼저 확인하는 것이 좋습니다.

✓ noindex 최종 체크리스트

□ noindex가 색인 제외를 요청하는 지시라는 점을 이해했다.

□ robots.txt와 noindex의 역할을 구분했다.

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

□ 일반 게시글과 기능성 페이지를 구분했다.

□ 해당 페이지가 검색에 노출될 필요가 있는지 판단했다.

□ 중요한 게시글은 브라우저에서 직접 확인했다.

□ 중요한 URL은 URL 검사에서 상태를 확인했다.

□ 필요하면 실시간 URL 테스트로 현재 상태를 확인했다.

□ 최근 스킨이나 메타 태그를 수정했는지 확인했다.

□ noindex 제거 후 즉시 색인된다고 생각하지 않았다.

□ 색인 생성 요청을 반복하지 않았다.

자주 묻는 질문

Q1. ‘noindex 태그에 의해 제외됨’은 오류인가요?

반드시 오류는 아닙니다. 검색에 노출할 필요가 없는 페이지라면 의도적으로 noindex가 사용될 수 있습니다. 검색 유입을 받아야 하는 정상 게시글에 적용되어 있을 때 확인이 필요합니다.

Q2. noindex를 제거하면 바로 Google 검색에 나오나요?

바로 검색에 노출된다고 보장할 수 없습니다. Google이 페이지를 다시 크롤링하고 변경 사항을 확인해야 할 수 있으며 최종 색인 여부도 별도로 결정됩니다.

Q3. robots.txt와 noindex 중 어느 것이 검색 제외 기능인가요?

noindex는 페이지를 검색 색인에 포함하지 않도록 요청하는 지시입니다. robots.txt는 기본적으로 크롤러의 접근을 제어합니다. 두 기능의 목적을 구분해서 사용해야 합니다.

Q4. noindex 상태의 URL에 색인 생성 요청을 하면 해결되나요?

현재도 noindex가 적용되어 있다면 색인 생성 요청부터 반복할 것이 아니라 noindex가 의도된 것인지 먼저 확인해야 합니다. 검색 노출이 필요한 페이지에서 잘못 적용된 noindex를 해결한 뒤 현재 상태를 확인하는 순서가 좋습니다.

Q5. noindex 페이지가 있으면 애드센스 신청에 문제가 되나요?

noindex URL이 존재한다는 사실 하나만으로 애드센스 승인 여부를 판단할 수 없습니다. 검색에 노출되어야 할 핵심 콘텐츠가 정상적으로 공개되고 있는지와 블로그 전체의 콘텐츠 상태를 중심으로 점검하는 것이 좋습니다.

마무리｜noindex를 없애기 전에 제외된 페이지부터 확인합니다

Search Console에서 ‘noindex 태그에 의해 제외됨’을 발견하면 가장 먼저 noindex를 제거하고 싶어질 수 있습니다.

하지만 모든 페이지가 검색 결과에 노출되어야 하는 것은 아닙니다.

따라서 먼저 어떤 URL이 제외되어 있는지 확인합니다.

검색에 노출될 필요가 없는 기능성 페이지라면 제외 상태가 정상일 수 있습니다.

반대로 직접 작성한 핵심 정보성 게시글이 noindex 상태라면 현재 페이지 상태, URL 검사, 스킨이나 메타 태그 설정 등을 확인할 필요가 있습니다.

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

robots.txt는 크롤링을 제어하고 noindex는 색인 제외를 요청한다는 차이를 이해해야 합니다.

잘못 적용된 noindex를 해결했더라도 즉시 검색 결과에 나타난다고 생각하지 않는 것이 좋습니다. Google이 페이지를 다시 확인하고 처리하는 시간이 필요할 수 있습니다.

Search Console 관리의 목표는 noindex로 제외된 URL을 모두 없애는 것이 아닙니다.

검색에 노출되어야 할 중요한 게시글이 실수로 제외되지 않았는지를 확인하는 것이 더 중요합니다.

함께 보면 좋은 글

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

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

다음 글 예고

티스토리 Search Console ‘서버 오류(5xx)’ 확인 방법｜일시적 오류와 반복되는 접속 문제 구분하기

다음 글에서는 Google이 티스토리 페이지에 접근하는 과정에서 서버 오류(5xx)를 발견했을 때 확인할 내용을 정리하겠습니다.

일시적으로 발생한 오류와 반복해서 확인해야 할 문제를 구분하고, 실제 URL 확인부터 URL 검사, 여러 게시글에서 동시에 발생할 때 살펴볼 부분까지 알아보겠습니다.