티스토리 Search Console ‘다른 4xx 문제로 인해 차단됨’ 확인 방법｜400·401·410 오류 구분하기

티스토리 블로그를 운영하면서 Google Search Console의 페이지 색인 생성 보고서를 확인하다 보면 ‘다른 4xx 문제로 인해 차단됨’이라는 항목을 발견할 수 있습니다.

이전에 살펴본 404 오류나 액세스 금지(403)와 달리, 이 항목은 이름만으로 어떤 문제가 발생했는지 파악하기 어렵습니다.

“다른 4xx는 무슨 뜻일까?”

“게시글이 삭제된 것도 아닌데 왜 차단됐을까?”

“검색에 노출되지 않는 글은 모두 수정해야 할까?”

이런 의문이 생길 수 있습니다.

하지만 4xx 오류가 있다고 해서 반드시 티스토리 블로그 전체에 문제가 생긴 것은 아닙니다.

4xx는 요청한 주소나 접근 조건과 관련된 HTTP 응답을 나타내는 상태 코드입니다.

그중에는 잘못된 요청을 의미하는 400, 인증이 필요하다는 의미의 401, 페이지가 더 이상 제공되지 않는다는 의미의 410 등이 있습니다.

중요한 것은 오류 코드 자체보다 해당 URL이 검색에 노출되어야 하는 페이지인지, 현재도 문제가 발생하는지를 확인하는 것입니다.

이번 글에서는 Search Console의 ‘다른 4xx 문제로 인해 차단됨’을 발견했을 때 400·401·410 오류를 구분하고 티스토리에서 확인할 수 있는 점검 방법을 정리해 보겠습니다.

✓ 먼저 4xx 오류가 무엇인지 이해합니다

웹사이트에 접속하면 서버는 요청에 대한 HTTP 상태 코드를 반환합니다.

일반적으로 페이지가 정상적으로 제공되면 200 상태 코드가 반환됩니다.

반면 4xx 계열은 클라이언트 요청이나 접근 조건과 관련된 문제를 나타냅니다.

예를 들어 요청 주소의 형식이 잘못되었거나, 인증이 필요하거나, 요청한 페이지가 더 이상 제공되지 않는 경우가 있습니다.

여기서 중요한 점은 모든 4xx 오류가 동일한 원인으로 발생하지 않는다는 것입니다.

따라서 Search Console에서 ‘다른 4xx 문제로 인해 차단됨’을 발견했다면 정확한 응답 상태를 확인하는 과정이 필요합니다.

✓ 다른 4xx와 일반 404·403은 구분해서 봅니다

Search Console은 일부 HTTP 오류를 별도의 사유로 분류합니다.

404는 요청한 페이지를 찾을 수 없는 상태입니다.

403은 서버가 요청에 대한 접근을 거부한 상태입니다.

반면 ‘다른 4xx 문제로 인해 차단됨’은 별도 항목으로 분류되지 않은 다른 4xx 응답과 관련될 수 있습니다.

따라서 해당 항목을 발견했다고 무조건 400 오류라고 판단해서는 안 됩니다.

실제 URL과 응답 상태를 확인해야 어떤 문제인지 구분할 수 있습니다.

✓ 400 오류는 잘못된 요청을 의미합니다

400 Bad Request는 서버가 요청을 올바르게 처리할 수 없다고 판단했을 때 반환할 수 있는 상태 코드입니다.

주소 형식이나 요청 내용에 문제가 있는 경우 등이 원인이 될 수 있습니다.

예를 들어 URL에 잘못된 문자가 포함되거나 요청 형식이 정상적이지 않다면 400 응답이 발생할 수 있습니다.

하지만 Search Console에 400 오류가 기록되었다고 해서 반드시 게시글 제목이나 본문에 문제가 있다는 뜻은 아닙니다.

먼저 실제 URL이 올바른지 확인해야 합니다.

특히 내부 링크를 통해 연결된 주소라면 링크가 잘못 작성되지 않았는지 살펴보는 것이 좋습니다.

✓ 401 오류는 인증이 필요한 상태입니다

401 Unauthorized는 요청한 리소스에 접근하기 위해 유효한 인증 정보가 필요하다는 의미입니다.

일반적으로 로그인이나 인증 절차와 관련된 상황에서 발생할 수 있습니다.

다만 401과 403은 구분해야 합니다.

401은 인증이 필요하거나 인증이 유효하지 않은 상황과 관련됩니다.

403은 서버가 요청을 이해했지만 접근을 허용하지 않는 상태입니다.

따라서 정상적인 공개 게시글에서 401 오류가 발생했다면 해당 URL이 실제로 공개되어 있는지 확인할 필요가 있습니다.

반대로 원래 인증이 필요한 URL이라면 검색에 노출되지 않는 것이 자연스러울 수 있습니다.

✓ 410 오류는 페이지가 더 이상 제공되지 않는다는 의미입니다

410 Gone은 요청한 리소스가 더 이상 제공되지 않으며 그 상태가 영구적이라는 의미를 나타내는 HTTP 상태 코드입니다.

404와 비슷하게 보일 수 있지만 의미에는 차이가 있습니다.

404는 요청한 페이지를 찾을 수 없다는 의미입니다.

410은 해당 리소스가 더 이상 제공되지 않는다는 사실을 명확하게 나타냅니다.

예를 들어 더 이상 제공하지 않을 페이지에서 410 응답을 반환할 수 있습니다.

다만 티스토리 운영자가 삭제한 게시글에 대해 410 상태 코드를 자유롭게 설정할 수 있다고 생각해서는 안 됩니다.

티스토리는 플랫폼에서 서버 응답을 관리하므로 실제 응답 코드와 운영자가 변경할 수 있는 범위를 구분해야 합니다.

✓ Search Console에서 오류 URL을 확인합니다

먼저 Google Search Console에서 자신의 티스토리 속성을 선택합니다.

페이지 색인 생성 보고서를 열고 ‘다른 4xx 문제로 인해 차단됨’ 항목이 있는지 확인합니다.

해당 항목을 선택한 뒤 예시 URL을 살펴봅니다.

이때 다음 사항을 확인합니다.

직접 작성한 정상 게시글인가?

이미 삭제한 게시글인가?

블로그 메인 주소인가?

특정 기능을 위한 URL인가?

잘못된 주소가 내부 링크에 포함되어 있는가?

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

오류 URL의 개수보다 실제로 어떤 주소에서 문제가 발생했는지 확인하는 것이 우선입니다.

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

Search Console에 표시된 주소를 브라우저에 입력해 직접 확인합니다.

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

오류 화면이 나타나는지도 확인합니다.

로그인이 필요한 페이지인지 확인합니다.

다른 URL로 이동하는지도 살펴봅니다.

이미 삭제한 주소인지도 확인합니다.

다만 브라우저에서 정상적으로 열린다고 해서 Google이 과거에 받은 4xx 응답이 잘못된 기록이라는 뜻은 아닙니다.

현재는 정상이어도 Google이 접근했던 시점에는 다른 응답이 반환되었을 수 있습니다.

✓ 브라우저 화면만으로 정확한 상태 코드를 판단하지 않습니다

여기서 중요한 점이 있습니다.

브라우저에 “페이지를 찾을 수 없습니다”라는 문구가 표시된다고 해서 반드시 HTTP 404 응답이 반환되는 것은 아닙니다.

반대로 오류 화면의 모양이 비슷해도 실제 응답 코드는 다를 수 있습니다.

따라서 400·401·410 중 어떤 코드가 반환되었는지 정확히 구분하려면 HTTP 응답 상태를 확인해야 합니다.

브라우저 개발자 도구의 네트워크 기능이나 HTTP 상태 확인 도구를 활용할 수 있습니다.

이때 URL 자체와 최종 응답 코드를 구분해서 살펴보는 것이 좋습니다.

다만 이러한 도구에 익숙하지 않다면 무리하게 설정을 변경하지 말고 Search Console의 URL 검사와 실제 페이지 상태를 먼저 확인해도 됩니다.

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

검색에 노출되어야 하는 중요한 게시글이라면 Search Console의 URL 검사를 이용합니다.

해당 URL을 입력하고 Google이 알고 있는 색인 상태와 크롤링 관련 정보를 확인합니다.

특히 다음 사항을 살펴봅니다.

Google이 마지막으로 확인한 상태는 무엇인가?

현재 색인되어 있는가?

최근 크롤링 정보가 표시되는가?

다른 색인 제외 사유가 함께 나타나는가?

검사한 URL이 실제 게시글 주소와 일치하는가?

이 과정에서 현재 상태와 과거 기록이 다를 수 있다는 점도 기억해야 합니다.

✓ 실시간 URL 테스트로 현재 상태를 확인합니다

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

예를 들어 과거에는 4xx 오류가 발생했지만 현재는 정상적인 게시글로 복구된 상황이 있을 수 있습니다.

이 경우 실시간 테스트에서 정상적으로 접근 가능한 상태가 나타날 수 있습니다.

반대로 현재도 접근 문제가 발생한다면 추가 확인이 필요합니다.

다만 실시간 테스트 한 번이 정상이라고 해서 모든 문제가 해결되었다고 확정할 수는 없습니다.

또한 실시간 테스트가 정상이라는 이유만으로 즉시 색인되는 것도 아닙니다.

✓ 삭제된 URL이라면 복구가 필요한지 판단합니다

다른 4xx 오류로 표시된 주소가 이미 삭제한 게시글이라면 먼저 복구할 필요가 있는지 판단합니다.

검색 유입이 있었고 현재도 유용한 정보를 제공할 수 있는 콘텐츠라면 복구를 검토할 수 있습니다.

반대로 더 이상 제공할 이유가 없는 게시글이라면 무조건 다시 발행할 필요는 없습니다.

특히 410 응답이 확인되었다면 해당 URL이 더 이상 제공되지 않는 상태인지 살펴봅니다.

이때 검색에 노출시키기 위해 삭제된 주소를 억지로 유지하거나 관련 없는 페이지로 이동시키는 것은 적절하지 않습니다.

URL의 실제 목적과 현재 상태에 맞게 판단하는 것이 중요합니다.

✓ 정상 게시글이라면 내부 링크도 확인합니다

검색에 노출되어야 하는 정상 게시글이 4xx 오류로 표시된다면 내부 링크도 확인하는 것이 좋습니다.

예를 들어 다른 글에서 해당 게시글로 연결한 링크가 잘못 작성되어 있을 수 있습니다.

이 경우 방문자나 검색엔진이 실제 게시글 주소가 아닌 잘못된 URL로 이동할 수 있습니다.

따라서 다음 사항을 확인합니다.

내부 링크가 정확한 주소를 가리키는가?

주소를 복사하는 과정에서 문자가 누락되지 않았는가?

오래된 주소가 그대로 남아 있지는 않은가?

삭제된 게시글로 연결되는 링크가 있는가?

다른 URL로 이동한다면 최종 도착 페이지가 적절한가?

내부 링크를 수정할 수 있는 상황이라면 실제로 정상적인 콘텐츠가 제공되는 주소로 연결하는 것이 좋습니다.

✓ 특정 URL 하나인지 여러 URL의 공통 문제인지 구분합니다

다른 4xx 오류가 특정 URL 하나에서만 발생하는 경우와 여러 URL에서 동시에 발생하는 경우는 구분해야 합니다.

특정 게시글 하나라면 해당 주소와 현재 응답 상태를 확인합니다.

반대로 여러 URL에서 비슷한 시기에 오류가 발생했다면 공통점을 살펴봅니다.

예를 들어 특정 경로의 URL에서만 문제가 발생하는지 확인할 수 있습니다.

또는 최근 게시글 주소나 스킨 관련 설정을 변경한 적이 있는지도 살펴볼 수 있습니다.

다만 여러 URL에서 오류가 발생했다는 사실만으로 티스토리 플랫폼 자체에 문제가 있다고 단정해서는 안 됩니다.

실제 URL과 응답 상태를 비교하면서 원인을 좁혀가는 것이 좋습니다.

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

티스토리는 블로그 운영자가 서버 전체를 직접 관리하는 서비스가 아닙니다.

따라서 자체 서버를 운영하는 웹사이트처럼 모든 HTTP 상태 코드를 자유롭게 설정하기 어려울 수 있습니다.

먼저 운영자가 확인할 수 있는 부분부터 살펴봅니다.

게시글 공개 상태

실제 게시글 URL

본문이 정상적으로 표시되는지 여부

내부 링크 주소

삭제하거나 변경한 게시글인지 여부

최근 수정한 스킨이나 HTML

특정 URL에서만 발생하는 문제인지 여부

이러한 부분을 확인한 뒤 플랫폼에서 관리하는 영역의 문제가 의심된다면 티스토리 고객지원에 문의하는 방법도 고려할 수 있습니다.

정확한 원인을 모른 채 서버 관련 설정을 임의로 변경하려고 할 필요는 없습니다.

✓ 현재 정상이라면 무작정 수정하지 않습니다

과거에는 4xx 오류가 발생했지만 현재는 정상적인 게시글이 표시되는 상황을 생각해 보겠습니다.

URL 검사와 실시간 테스트에서도 현재 접근 문제가 발견되지 않습니다.

이 경우 Search Console에 오류 기록이 남아 있다는 이유만으로 게시글을 삭제하거나 다시 발행할 필요는 없습니다.

제목을 변경하거나 글자 수를 늘리는 것도 HTTP 4xx 오류를 직접 해결하는 방법이 아닙니다.

현재 정상적으로 접근 가능한 상태라면 이후 Google이 다시 확인하고 보고서가 갱신되는지 살펴볼 수 있습니다.

필요한 경우 Search Console에서 제공하는 수정 결과 확인 기능을 활용할 수 있지만 즉시 결과가 반영되는 것은 아닙니다.

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

A 사례｜잘못된 주소에서 발생한 400 오류

Search Console에 다른 4xx 오류가 표시됩니다.

확인해 보니 URL에 잘못된 문자가 포함되어 있고 정상적인 게시글 주소와 다릅니다.

이 경우 실제 게시글이 문제가 아니라 잘못 작성된 URL에서 오류가 발생했을 가능성을 확인합니다.

내부 링크에 같은 주소가 사용되고 있다면 올바른 URL로 수정합니다.

B 사례｜인증이 필요한 URL의 401 오류

특정 URL에서 401 응답이 확인됩니다.

해당 주소는 일반 방문자에게 공개되는 게시글이 아니라 인증이 필요한 페이지입니다.

이 경우 검색에 노출될 필요가 있는 URL인지 먼저 판단합니다.

원래 접근 제한이 필요한 페이지라면 무조건 공개할 필요는 없습니다.

C 사례｜삭제된 게시글의 410 오류

오래전에 삭제한 게시글 주소에서 410 응답이 확인됩니다.

현재도 해당 콘텐츠를 복구할 계획이 없습니다.

이 경우 검색에 노출시키기 위해 무조건 다시 발행할 필요는 없습니다.

실제로 더 이상 제공하지 않는 페이지라면 그 상태에 맞게 처리되는 것이 자연스러울 수 있습니다.

D 사례｜현재는 정상적으로 복구된 게시글

과거에는 다른 4xx 오류가 발생했지만 현재는 게시글이 정상적으로 열립니다.

실시간 URL 테스트에서도 접근 문제가 발견되지 않습니다.

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

설정을 계속 변경하기보다 Google이 다시 확인하고 보고서가 갱신되는지 살펴봅니다.

✓ 다른 4xx 오류 최종 체크리스트

□ 4xx가 요청이나 접근 조건과 관련된 상태 코드라는 점을 이해했다.

□ 400·401·410의 차이를 구분했다.

□ 일반 404와 403 오류를 혼동하지 않았다.

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

□ 해당 URL이 정상 게시글인지 삭제된 주소인지 구분했다.

□ 브라우저에서 URL을 직접 열어봤다.

□ 필요한 경우 실제 HTTP 응답 상태를 확인했다.

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

□ 필요한 경우 실시간 URL 테스트를 활용했다.

□ 내부 링크가 올바른 주소를 가리키는지 확인했다.

□ 현재 정상적인 게시글을 무작정 삭제하거나 다시 발행하지 않았다.

자주 묻는 질문

Q1. ‘다른 4xx 문제로 인해 차단됨’은 무조건 400 오류인가요?

아닙니다. 해당 항목은 다른 4xx 응답과 관련된 상태를 나타냅니다. 따라서 실제 URL과 HTTP 응답 상태를 확인해야 어떤 오류인지 구분할 수 있습니다.

Q2. 401 오류가 발생하면 게시글이 삭제된 건가요?

반드시 그렇지는 않습니다. 401은 일반적으로 인증이 필요하거나 인증 정보가 유효하지 않은 상황과 관련됩니다. 페이지가 삭제되었다는 의미의 404나 410과는 구분해야 합니다.

Q3. 410 오류가 발생하면 무조건 게시글을 복구해야 하나요?

그럴 필요는 없습니다. 410은 해당 리소스가 더 이상 제공되지 않는다는 의미입니다. 실제로 삭제한 콘텐츠이고 복구할 필요가 없다면 무조건 다시 발행할 이유는 없습니다.

Q4. 다른 4xx 오류를 수정하면 바로 색인되나요?

오류가 해결되었다고 해서 즉시 색인되는 것은 아닙니다. Google이 페이지를 다시 크롤링하고 상태를 확인해야 할 수 있으며 최종 색인 여부는 별도로 결정됩니다.

Q5. 다른 4xx 오류가 있으면 애드센스 신청에 문제가 되나요?

Search Console에 다른 4xx 오류 기록이 있다는 사실 하나만으로 애드센스 승인 여부를 판단할 수 없습니다. 다만 중요한 정보성 게시글에 실제 접근 문제가 지속된다면 블로그 운영 측면에서 개선이 필요합니다.

마무리｜다른 4xx 오류는 정확한 코드와 URL 상태를 확인해야 합니다

Search Console에서 ‘다른 4xx 문제로 인해 차단됨’을 발견했다고 바로 게시글을 삭제하거나 다시 작성할 필요는 없습니다.

먼저 어떤 URL에서 오류가 발생했는지 확인합니다.

그다음 해당 주소가 검색에 노출되어야 하는 정상 게시글인지, 이미 삭제된 주소인지, 접근 제한이 필요한 페이지인지 구분합니다.

400은 잘못된 요청과 관련될 수 있습니다.

401은 인증이 필요한 상황과 관련됩니다.

410은 해당 리소스가 더 이상 제공되지 않는다는 의미입니다.

이처럼 4xx 상태 코드는 각각 의미가 다르므로 같은 방법으로 해결하려고 해서는 안 됩니다.

특히 티스토리에서는 서버 응답 코드를 자유롭게 관리하기 어려울 수 있으므로 운영자가 확인할 수 있는 게시글 상태와 내부 링크부터 점검하는 것이 좋습니다.

Search Console 관리의 목표는 모든 4xx 오류 기록을 무조건 없애는 것이 아닙니다.

검색에 노출되어야 할 중요한 게시글이 정상적으로 접근 가능한 상태인지 확인하는 것이 더 중요합니다.

함께 보면 좋은 글

티스토리 Search Console ‘소프트 404’ 확인 방법｜페이지는 열리는데 없는 페이지로 판단되는 이유

티스토리 Search Console ‘소프트 404’ 확인 방법｜페이지는 열리는데 없는 페이지로 판단되는 이

다음 글 예고

티스토리 Search Console ‘크롤링 이상’ 확인 방법｜Google이 페이지를 가져오지 못했을 때 점검할 것

다음 글에서는 Search Console에서 명확한 404나 5xx 오류가 아닌 크롤링 이상 상태를 발견했을 때 확인할 내용을 정리하겠습니다.

URL 검사에서 크롤링 정보를 확인하는 방법과 일시적인 접근 실패, 반복되는 페이지 수집 문제를 구분하는 기준을 살펴보겠습니다.