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

티스토리 블로그를 운영하면서 Google Search Console의 페이지 색인 생성 보고서를 확인하다 보면 ‘소프트 404’라는 상태를 발견할 수 있습니다.

일반적인 404 오류는 어느 정도 익숙하지만 소프트 404는 처음 접하면 의미를 이해하기 어렵습니다.

“게시글이 정상적으로 열리는데 왜 404로 표시될까?”

“Google이 내 글을 가치 없는 콘텐츠로 판단한 걸까?”

“소프트 404가 있으면 게시글을 삭제해야 할까?”

하지만 소프트 404가 표시되었다고 해서 반드시 글의 품질이 낮거나 블로그 전체에 문제가 있다는 뜻은 아닙니다.

소프트 404는 서버가 페이지를 정상적으로 제공하는 것처럼 응답했지만, Google이 해당 페이지를 실제로는 존재하지 않거나 오류 페이지와 비슷한 상태라고 판단할 때 발생할 수 있습니다.

따라서 중요한 것은 오류 이름만 보고 게시글을 수정하는 것이 아니라 Google이 확인한 URL이 실제로 어떤 내용을 제공하는지 살펴보는 것입니다.

이번 글에서는 소프트 404와 일반 404의 차이부터 Search Console에서 URL을 확인하는 방법, 정상 게시글과 실질적으로 내용이 없는 페이지를 구분하는 기준까지 정리해 보겠습니다.

✓ 먼저 소프트 404가 무엇인지 이해합니다

소프트 404는 일반적인 404 오류와 다릅니다.

일반적인 404는 서버가 요청한 페이지를 찾을 수 없다는 의미의 HTTP 상태 코드입니다.

반면 소프트 404는 서버가 정상 응답을 반환했더라도 Google이 해당 페이지를 실질적으로 존재하지 않는 페이지처럼 판단한 상태입니다.

예를 들어 삭제된 게시글 주소에 접속했을 때 실제 콘텐츠 대신 “페이지를 찾을 수 없습니다”라는 안내가 표시된다고 가정하겠습니다.

그런데 서버가 404가 아닌 200 정상 응답을 반환한다면 Google은 이를 소프트 404로 판단할 수 있습니다.

즉, 소프트 404는 단순히 페이지가 열리는지보다 실제 내용과 서버 응답이 서로 맞는지를 함께 살펴봐야 하는 문제입니다.

✓ 일반 404와 소프트 404의 차이를 구분합니다

두 상태를 비교하면 이해하기 쉽습니다.

일반 404

요청한 페이지가 존재하지 않고 서버도 404 상태 코드를 반환합니다.

소프트 404

서버는 정상 응답을 반환했지만 실제 페이지 내용이 존재하지 않는 페이지와 비슷하다고 Google이 판단합니다.

예를 들어 삭제된 게시글 주소에서 정상적인 404 응답이 반환된다면 일반 404에 해당할 수 있습니다.

반면 같은 주소에서 “게시글이 없습니다”라는 화면을 보여주면서 200 응답을 반환한다면 소프트 404로 판단될 수 있습니다.

다만 Google은 페이지 내용과 다양한 신호를 함께 살펴보기 때문에 화면에 특정 문구가 있다는 사실 하나만으로 소프트 404가 결정되는 것은 아닙니다.

✓ Search Console에서 소프트 404 URL을 확인합니다

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

페이지 색인 생성 보고서를 열고 ‘소프트 404’ 항목을 확인합니다.

해당 항목을 선택하면 Google이 소프트 404로 판단한 예시 URL을 살펴볼 수 있습니다.

이때 URL 개수만 확인하지 않습니다.

어떤 종류의 주소가 포함되어 있는지 먼저 구분합니다.

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

이미 삭제한 게시글인가?

주소가 변경된 페이지인가?

블로그의 특정 기능성 URL인가?

실제로는 내용이 거의 없는 페이지인가?

소프트 404는 URL의 실제 상태에 따라 대응 방법이 달라지므로 이 구분이 중요합니다.

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

Search Console에 표시된 URL을 복사해 브라우저에서 직접 열어봅니다.

그리고 다음 내용을 확인합니다.

정상적인 게시글 본문이 표시되는가?

페이지를 찾을 수 없다는 안내가 나타나는가?

다른 주소로 자동 이동하는가?

제목만 있고 실제 본문이 없는가?

로그인이나 접근 제한 화면이 나타나는가?

현재도 검색에 노출시키려는 페이지인가?

브라우저에서 정상적으로 열린다고 해서 Google이 소프트 404로 판단한 이유가 자동으로 해결되는 것은 아닙니다.

화면이 표시되는 것과 실제로 유효한 콘텐츠가 제공되는 것은 서로 다른 문제이기 때문입니다.

✓ 실제로 삭제된 게시글이라면 복구가 필요한지 판단합니다

소프트 404로 표시된 URL이 이미 삭제한 게시글이라면 먼저 복구할 필요가 있는지 판단합니다.

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

반대로 더 이상 제공할 이유가 없는 게시글이라면 검색 결과에 남겨둘 필요가 없을 수 있습니다.

이 경우 해당 주소가 실제로 존재하지 않는 페이지임을 올바르게 나타내는 것이 중요합니다.

다만 티스토리에서는 서버의 HTTP 응답 코드를 사용자가 직접 설정하기 어려울 수 있습니다.

따라서 삭제된 URL마다 임의로 다른 페이지를 만들거나 관련 없는 글로 이동시키는 방식은 피하는 것이 좋습니다.

✓ 정상 게시글인데 소프트 404라면 본문부터 확인합니다

검색에 노출시키려는 정상적인 정보성 게시글이 소프트 404로 표시된다면 실제 본문이 제대로 제공되는지 확인합니다.

예를 들어 제목은 있지만 본문이 거의 비어 있거나, 중요한 내용이 표시되지 않는 상황이라면 점검이 필요합니다.

본문이 정상적으로 표시되는지도 확인합니다.

이미지나 외부 콘텐츠에만 의존해 핵심 정보가 전달되고 있지는 않은지 살펴봅니다.

페이지를 열었을 때 실제로 해당 주제에 관한 내용을 확인할 수 있는지가 중요합니다.

하지만 글자 수가 적다는 이유만으로 소프트 404가 발생한다고 단정해서는 안 됩니다.

Google이 소프트 404로 판단하는 원인은 단순한 글자 수 부족만으로 설명되지 않습니다.

✓ 내용이 부족한 글과 소프트 404를 혼동하지 않습니다

블로그 운영 과정에서 자주 생기는 오해가 있습니다.

“소프트 404가 떴으니 글자 수를 늘리면 해결된다.”

하지만 소프트 404는 단순한 콘텐츠 분량 평가가 아닙니다.

예를 들어 짧더라도 질문에 정확하게 답하는 유용한 페이지가 있을 수 있습니다.

반대로 글자 수가 많아도 실제 페이지가 오류 안내나 빈 화면을 제공한다면 문제가 될 수 있습니다.

따라서 글자 수를 무작정 늘리기보다 해당 URL이 원래 제공하려던 콘텐츠를 실제로 보여주는지 확인해야 합니다.

필요한 경우에만 빠진 정보나 잘못된 표시를 개선하는 것이 좋습니다.

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

소프트 404로 표시된 중요한 게시글은 Search Console의 URL 검사를 이용합니다.

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

이때 검사한 URL이 실제 게시글 주소와 정확히 일치하는지 확인합니다.

다른 주소로 이동하는지 살펴봅니다.

현재 색인 상태가 어떻게 표시되는지도 확인합니다.

최근에 게시글을 복구하거나 내용을 수정했다면 Google이 알고 있는 상태가 이전 정보일 수 있습니다.

따라서 필요하면 실시간 URL 테스트를 함께 활용합니다.

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

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

예를 들어 과거에는 게시글이 비어 있었지만 지금은 정상적인 콘텐츠로 복구했다고 가정하겠습니다.

이 경우 현재 페이지가 정상적으로 제공되는지 실시간 테스트를 통해 추가로 확인할 수 있습니다.

다만 주의할 점이 있습니다.

실시간 URL 테스트에서 접근 가능하다고 표시된다고 해서 Google의 소프트 404 판단이 즉시 해제되는 것은 아닙니다.

실시간 접근 가능 여부와 최종 색인 판단은 구분해야 합니다.

✓ 다른 페이지로 이동하는 URL도 확인합니다

소프트 404가 발생한 URL이 다른 페이지로 이동한다면 최종 도착 페이지를 확인합니다.

예를 들어 삭제된 게시글 주소가 블로그 메인 페이지로 이동한다고 가정하겠습니다.

이 경우 원래 게시글을 찾으려던 방문자는 원하는 정보를 얻지 못할 수 있습니다.

Google도 이러한 이동을 정상적인 콘텐츠 대체로 판단하지 않을 수 있습니다.

특히 서로 관련이 없는 여러 삭제 URL을 모두 홈페이지로 보내는 방식은 적절하지 않습니다.

실제로 대체할 수 있는 관련 페이지가 있는지 먼저 판단해야 합니다.

티스토리에서는 서버 수준의 리디렉션을 자유롭게 설정하기 어려울 수 있으므로 임의의 이동 코드를 추가하기 전에 현재 URL의 동작부터 확인하는 것이 좋습니다.

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

소프트 404가 특정 게시글 하나에서만 발생하는 경우와 여러 URL에서 발생하는 경우는 구분해야 합니다.

특정 게시글 하나라면 해당 페이지의 실제 내용을 확인합니다.

여러 게시글에서 비슷한 시기에 발생했다면 공통점을 살펴봅니다.

예를 들어 특정 스킨 변경 이후 본문이 정상적으로 표시되지 않는 문제가 발생했는지 확인할 수 있습니다.

또는 삭제된 URL이 여러 개 포함되어 있는지도 살펴봅니다.

다만 여러 URL에서 소프트 404가 발생했다고 해서 반드시 스킨이나 티스토리 플랫폼 자체가 원인이라고 단정할 수는 없습니다.

실제 페이지 내용을 비교하면서 원인을 좁혀가는 것이 좋습니다.

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

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

따라서 서버 응답 코드를 자유롭게 수정하거나 모든 리디렉션 규칙을 직접 관리하기 어려울 수 있습니다.

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

게시글 공개 상태

실제 게시글 URL

본문 표시 여부

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

최근 수정한 스킨이나 HTML

내부 링크가 올바른 주소를 가리키는지 여부

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

중요한 것은 정확한 원인을 모른 채 서버 설정을 변경하려고 하거나 스킨 코드를 무작정 수정하지 않는 것입니다.

✓ 실제 문제가 해결됐다면 다시 확인합니다

정상 게시글에서 발생한 문제를 해결했다면 현재 페이지 상태를 다시 확인합니다.

브라우저에서 실제 콘텐츠가 정상적으로 표시되는지 살펴봅니다.

필요하면 URL 검사와 실시간 URL 테스트를 활용합니다.

검색에 노출되어야 하는 중요한 게시글이라면 수정 후 색인 생성 요청을 검토할 수 있습니다.

다만 색인 생성 요청이 소프트 404 판단 해제나 색인을 보장하는 것은 아닙니다.

Google이 페이지를 다시 크롤링하고 내용을 평가하는 과정이 필요할 수 있습니다.

따라서 같은 URL에 반복적으로 요청할 필요는 없습니다.

✓ 소프트 404를 발견했을 때 피해야 할 대응

소프트 404가 표시되었다고 다음과 같은 방식으로 대응하지 않습니다.

정상 게시글을 바로 삭제합니다.

글자 수만 무작정 늘립니다.

같은 내용을 새로운 URL로 다시 발행합니다.

삭제된 URL을 모두 홈페이지로 이동시킵니다.

정상적으로 존재하지 않는 페이지를 억지로 유지합니다.

원인을 확인하지 않고 스킨 전체를 수정합니다.

모든 URL에 색인 생성 요청을 반복합니다.

Search Console의 소프트 404 숫자를 0으로 만드는 것을 목표로 합니다.

먼저 실제 페이지 상태를 확인하고 필요한 부분만 개선하는 것이 중요합니다.

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

A 사례｜이미 삭제한 게시글

Search Console에 소프트 404가 표시됩니다.

확인해 보니 오래전에 삭제한 게시글 주소입니다.

현재도 복구할 필요가 없는 콘텐츠라면 해당 URL을 억지로 검색에 노출시키려 하지 않습니다.

실제로 존재하지 않는 페이지가 적절한 상태로 처리되는지 확인합니다.

B 사례｜제목만 남아 있는 게시글

정상적으로 공개된 게시글이 소프트 404로 표시됩니다.

브라우저에서 열어보니 제목은 있지만 본문이 비어 있습니다.

이 경우 해당 게시글이 제공하려던 실제 정보를 복구하거나 정상적인 콘텐츠로 완성할 필요가 있습니다.

단순히 글자 수만 늘리는 것이 아니라 페이지의 목적에 맞는 내용을 제공해야 합니다.

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

과거에는 페이지가 정상적으로 표시되지 않았지만 현재는 본문이 복구되어 있습니다.

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

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

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

D 사례｜삭제된 글이 홈페이지로 이동하는 경우

삭제된 게시글 주소에 접속하면 블로그 홈페이지로 이동합니다.

하지만 홈페이지에는 원래 게시글과 관련된 정보가 없습니다.

이 경우 해당 이동이 방문자에게 적절한 대체 콘텐츠를 제공하는지 확인해야 합니다.

관련 없는 페이지로의 이동은 소프트 404 판단으로 이어질 수 있으므로 무조건적인 홈페이지 이동을 해결책으로 생각하지 않습니다.

✓ 소프트 404 최종 체크리스트

□ 일반 404와 소프트 404의 차이를 이해했다.

□ Search Console에서 실제 소프트 404 URL을 확인했다.

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

□ 브라우저에서 페이지를 직접 열어봤다.

□ 본문이 실제로 정상 표시되는지 확인했다.

□ 다른 URL로 이동한다면 최종 도착 페이지를 확인했다.

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

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

□ 여러 URL에서 발생한다면 공통점을 살펴봤다.

□ 글자 수를 늘리는 것만으로 해결된다고 생각하지 않았다.

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

자주 묻는 질문

Q1. 소프트 404가 발생하면 게시글이 삭제된 건가요?

반드시 그렇지는 않습니다. 페이지가 정상 응답을 반환하더라도 Google이 실질적으로 존재하지 않는 페이지처럼 판단하면 소프트 404가 발생할 수 있습니다. 실제 URL을 열어 현재 상태를 확인해야 합니다.

Q2. 글자 수가 적으면 소프트 404가 발생하나요?

글자 수가 적다는 이유만으로 소프트 404가 발생한다고 단정할 수 없습니다. 중요한 것은 페이지가 실제로 유효한 콘텐츠를 제공하는지입니다. 본문이 비어 있거나 오류 안내만 표시되는 상황이라면 점검이 필요합니다.

Q3. 소프트 404가 발생하면 무조건 글을 수정해야 하나요?

그럴 필요는 없습니다. 이미 삭제한 페이지라면 복구가 필요하지 않을 수 있습니다. 반대로 검색에 노출되어야 하는 정상 게시글이라면 실제 콘텐츠가 제대로 표시되는지 확인해야 합니다.

Q4. 소프트 404를 수정하면 바로 색인되나요?

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

Q5. 소프트 404가 있으면 애드센스 신청에 문제가 되나요?

Search Console에 소프트 404가 있다는 사실 하나만으로 애드센스 승인 여부를 판단할 수 없습니다. 다만 실제 방문자가 중요한 게시글에서 정상적인 정보를 확인할 수 없는 상태라면 블로그 운영 측면에서 개선이 필요합니다.

마무리｜소프트 404는 페이지가 실제로 무엇을 보여주는지 확인해야 합니다

Search Console에서 ‘소프트 404’를 발견했다고 정상 게시글을 바로 삭제하거나 다시 발행할 필요는 없습니다.

먼저 해당 URL이 어떤 페이지인지 확인합니다.

이미 삭제한 게시글인지, 검색에 노출되어야 하는 정상 게시글인지 구분합니다.

그리고 브라우저에서 실제 페이지를 열어 본문이 정상적으로 표시되는지 살펴봅니다.

중요한 게시글이라면 URL 검사와 실시간 URL 테스트를 활용해 현재 상태를 확인할 수 있습니다.

특히 소프트 404는 단순히 글자 수를 늘린다고 해결되는 문제가 아닙니다.

실제 페이지가 방문자에게 필요한 정보를 제공하는지, 존재하지 않는 페이지를 정상 페이지처럼 응답하고 있지는 않은지 확인하는 것이 중요합니다.

티스토리에서는 서버 응답 코드를 직접 관리하기 어려울 수 있으므로 운영자가 확인할 수 있는 게시글 상태와 콘텐츠 표시 문제부터 점검하는 것이 좋습니다.

Search Console 관리의 목표는 소프트 404 숫자를 무조건 없애는 것이 아닙니다.

검색에 노출되어야 할 중요한 게시글이 실제로 정상적인 콘텐츠를 제공하고 있는지 확인하는 것이 더 중요합니다.

함께 보면 좋은 글

티스토리 Search Console ‘액세스 금지(403)’ 확인 방법｜접근 권한 문제와 일시적 차단 구분하기

티스토리 Search Console ‘액세스 금지(403)’ 확인 방법｜접근 권한 문제와 일시적 차단 구분하기

다음 글 예고

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

다음 글에서는 일반적인 404나 403과 달리 다른 4xx 오류로 분류된 URL을 발견했을 때 확인할 내용을 정리하겠습니다.

HTTP 상태 코드의 차이를 이해하고, 실제 게시글과 더 이상 존재하지 않는 URL을 구분하는 방법을 살펴보겠습니다.