티스토리 404 페이지 확인하는 방법|Search Console에서 찾을 수 없음 URL 점검하기

티스토리를 운영하다 보면 Google Search Console의 페이지 색인 생성 보고서에서 ‘찾을 수 없음(404)’ 상태를 발견할 수 있습니다.
처음 확인하면 404가 있다는 사실 자체가 블로그 검색 노출에 문제가 되는 것은 아닌지 걱정하기 쉽습니다.
하지만 모든 404를 수정해야 하는 것은 아닙니다.
직접 삭제한 게시글처럼 실제로 존재하지 않아야 하는 URL이라면 404는 자연스러운 상태일 수 있습니다. 반대로 현재 정상적으로 존재해야 하는 게시글이 404로 확인된다면 원인을 점검해야 합니다.
따라서 404를 관리할 때 중요한 것은 개수를 줄이는 것이 아니라 해당 URL이 어떤 종류인지 구분하는 것입니다.
이번 글에서는 Search Console에서 404 URL을 확인하고 실제로 수정해야 할 페이지와 그대로 둘 수 있는 페이지를 구분하는 방법을 순서대로 정리해 보겠습니다.
✓ 404를 발견하면 먼저 네 가지로 구분합니다
Search Console에서 404를 발견했다면 가장 먼저 해당 URL이 어떤 상황에 해당하는지 확인합니다.
첫 번째는 직접 삭제한 게시글입니다.
게시글을 정상적으로 삭제했고 더 이상 제공할 필요가 없는 콘텐츠라면 기존 URL에서 페이지를 찾을 수 없는 것은 자연스러운 결과입니다.
두 번째는 현재 존재해야 하는 게시글입니다.
관리 화면에는 글이 있고 공개 상태인데 실제 URL이 열리지 않는다면 확인이 필요합니다.
세 번째는 만든 적이 없는 URL입니다.
주소 오타나 잘못된 링크 등으로 실제 존재하지 않는 URL을 Google이 발견했을 가능성이 있습니다.
네 번째는 삭제된 페이지를 다른 글에서 계속 연결하고 있는 경우입니다.
삭제 자체는 정상적이어도 내부 링크가 남아 있다면 방문자가 존재하지 않는 페이지로 이동할 수 있으므로 링크를 정리해야 합니다.
이 네 가지를 먼저 구분하면 모든 404를 같은 방식으로 처리하는 실수를 줄일 수 있습니다.
✓ 404가 있다고 무조건 SEO 문제가 되는 것은 아닙니다
404는 요청한 URL에서 페이지를 찾을 수 없을 때 사용되는 HTTP 상태 코드입니다.
예전에 존재했던 게시글을 정상적으로 삭제했고 앞으로도 해당 페이지가 필요하지 않다면 존재하지 않는 URL이 404 상태가 되는 것은 이상한 일이 아닙니다.
따라서 Search Console에 404가 있다는 이유만으로 새로운 페이지를 만들거나 모든 URL을 복구할 필요는 없습니다.
핵심은 해당 페이지가 원래 존재해야 하는지 확인하는 것입니다.
존재하지 않아야 하는 URL이라면 정상적인 404일 수 있고, 존재해야 하는 중요한 URL이라면 원인을 찾아야 합니다.
✓ Search Console에서 404를 확인하는 순서
실제 점검은 다음 순서로 진행하면 이해하기 쉽습니다.
Search Console에서 자신의 티스토리 속성을 선택합니다.
페이지 색인 생성 보고서로 이동합니다.
색인이 생성되지 않은 페이지의 사유에서 ‘찾을 수 없음(404)’과 관련된 항목을 확인합니다.
해당 항목을 열어 표시되는 예시 URL을 살펴봅니다.
다만 여기에 표시되는 URL을 사이트에 존재하는 모든 404의 완전한 목록이라고 생각할 필요는 없습니다.
보고서는 전체적인 상태와 점검할 URL을 찾는 자료로 활용하고, 중요한 개별 URL은 별도로 확인하는 것이 좋습니다.
✓ 예시 URL을 브라우저에서 직접 열어봅니다
404 목록에서 주소를 발견했다면 가장 먼저 브라우저에서 직접 열어봅니다.
이 단계만으로도 많은 상황을 구분할 수 있습니다.
정말 존재하지 않는 페이지인지 확인합니다.
현재 게시글이 정상적으로 표시되는지도 확인합니다.
다른 페이지로 이동하는지도 살펴봅니다.
주소에 오타나 이상한 경로가 포함되어 있지는 않은지도 확인합니다.
현재 브라우저에서는 정상적으로 열리는데 Search Console에는 과거 404 상태가 남아 있다면 Google이 마지막으로 확인했던 시점과 현재 상태가 다를 가능성도 있습니다.
✓ 삭제한 게시글이라면 복구부터 할 필요는 없습니다
직접 삭제한 게시글이고 더 이상 제공할 필요가 없는 콘텐츠라면 404를 발견했다고 무조건 복구할 필요는 없습니다.
예를 들어 오래된 테스트 글을 삭제했고 해당 콘텐츠를 다시 제공할 이유가 없다면 존재하지 않는 페이지가 된 것은 정상적인 결과입니다.
이때 더 중요한 것은 다른 게시글에서 삭제된 URL을 계속 연결하고 있지 않은지 확인하는 것입니다.
본문의 관련 글 링크, 함께 보면 좋은 글, 시리즈 연결 등에서 삭제된 주소가 남아 있다면 링크를 제거하거나 실제로 관련 있는 다른 게시글로 수정합니다.
✓ 현재 존재해야 하는 게시글이 404라면 확인이 필요합니다
현재 공개 중이어야 하는 중요한 게시글인데 실제 URL이 열리지 않는다면 정상적인 삭제 URL과 다르게 접근해야 합니다.
먼저 티스토리 관리 화면에서 해당 게시글이 존재하는지 확인합니다.
글이 공개 상태인지 살펴봅니다.
정확한 게시글 URL을 사용하고 있는지도 확인합니다.
브라우저에서 실제 주소가 열리는지 다시 확인합니다.
게시글 주소 형식을 변경했거나 링크를 잘못 입력하지 않았는지도 살펴봅니다.
현재 존재해야 하는 페이지가 실제로 열리지 않는다면 원인을 해결한 뒤 Search Console에서 상태를 다시 확인합니다.
✓ 만든 적 없는 URL은 먼저 출처를 확인합니다
Search Console에서 전혀 만든 기억이 없는 주소를 발견할 수도 있습니다.
이런 URL 하나를 발견했다고 바로 심각한 문제라고 판단할 필요는 없습니다.
주소 오타가 포함된 링크가 있었거나 외부에서 잘못된 주소가 만들어졌을 수도 있습니다.
Google이 웹에서 URL처럼 보이는 경로를 발견했을 가능성도 있습니다.
이 경우 실제 게시글 주소인지부터 확인하고 블로그 내부에서 해당 잘못된 URL을 연결하고 있지는 않은지 살펴봅니다.
원래 존재할 필요가 없는 URL이라면 Search Console에서 404를 없애기 위해 내용 없는 페이지를 새로 만들 필요는 없습니다.
✓ 잘못된 내부 링크는 수정합니다
404 가운데 실제로 적극적으로 확인할 부분은 잘못된 내부 링크입니다.
예를 들어 정상적인 게시글 주소가
example.tistory.com/123
인데 다른 게시글에서 실수로
example.tistory.com/1234
를 연결했다고 가정해 보겠습니다.
두 번째 주소에 페이지가 없다면 방문자는 링크를 클릭했을 때 원하는 콘텐츠를 볼 수 없습니다.
이런 경우에는 존재하지 않는 URL을 억지로 살리는 것이 아니라 링크를 정상적인 주소로 수정하는 것이 우선입니다.
이미 삭제한 게시글로 연결되는 링크도 같은 방법으로 점검합니다.
✓ URL 검사와 실시간 URL 테스트는 중요한 페이지에 사용합니다
현재 존재해야 하는 중요한 게시글이 404로 표시된다면 Search Console의 URL 검사를 활용할 수 있습니다.
확인하려는 전체 URL을 입력하고 Google이 해당 URL에 대해 알고 있는 상태를 살펴봅니다.
여기서 주의할 점은 URL 검사에 표시되는 정보와 현재 페이지 상태가 항상 동시에 바뀌는 것은 아니라는 것입니다.
최근 페이지를 복구했다면 Google이 아직 다시 확인하지 않았을 수 있습니다.
이때 필요하면 실시간 URL 테스트를 이용해 현재 Google의 검사 도구가 페이지에 접근할 수 있는지 확인할 수 있습니다.
페이지 문제가 해결됐고 정상적으로 접근 가능한 중요한 URL이라면 색인 생성 요청을 검토할 수 있습니다.
다만 색인 생성 요청이 즉시 색인을 보장하는 것은 아닙니다.
반대로 실제로 삭제했고 앞으로도 존재할 필요가 없는 404 URL에는 색인 생성 요청을 할 필요가 없습니다.
✓ 잘못 처리하면 안 되는 방법
404 숫자를 줄이는 것만 목표로 삼으면 오히려 불필요한 작업을 할 수 있습니다.
먼저 모든 404 URL을 홈페이지로 무조건 연결하지 않습니다.
삭제된 페이지와 실질적으로 관련 있는 대체 콘텐츠가 있다면 연결을 검토할 수 있지만 전혀 관계없는 홈페이지나 다른 게시글로 보내는 방식은 방문자가 기대한 정보와 맞지 않을 수 있습니다.
404 URL을 robots.txt로 막는 방식으로 해결하려고 하지 않는 것도 중요합니다.
검색엔진이 URL의 실제 상태를 확인해야 해당 페이지가 존재하지 않는다는 사실도 처리할 수 있기 때문입니다.
404를 없애기 위해 내용 없는 페이지를 새로 만드는 것도 피합니다.
원래 존재할 필요가 없는 주소라면 억지로 빈 페이지를 만드는 것보다 존재하지 않는 상태를 명확하게 처리하는 것이 자연스럽습니다.
또한 404와 소프트 404를 구분해야 합니다.
일반적인 404는 실제로 존재하지 않는 페이지가 그에 맞는 상태를 반환하는 경우입니다.
반면 소프트 404는 실질적으로 콘텐츠가 없거나 페이지를 찾을 수 없는 것처럼 보이는데 정상 페이지처럼 응답하는 등의 상황을 의미합니다.
✓ 삭제된 URL과 사이트맵도 구분해서 생각합니다
Google은 내부 링크뿐 아니라 사이트맵 등 여러 경로를 통해 URL을 발견할 수 있습니다.
일반적인 사이트에서는 삭제된 URL이 사이트맵에 계속 포함되어 있다면 사이트맵에서도 제거하는 것이 자연스럽습니다.
다만 티스토리처럼 플랫폼이 사이트맵을 자동으로 생성하고 관리하는 경우 사용자가 개별 URL을 자유롭게 수정하기 어려울 수 있습니다.
따라서 먼저 현재 사이트맵에 실제로 해당 주소가 남아 있는지를 확인하고 티스토리에서 지원하지 않는 설정을 억지로 변경하지 않는 것이 좋습니다.
✓ Search Console 보고서는 바로 바뀌지 않을 수 있습니다
잘못된 내부 링크를 수정하거나 중요한 페이지를 복구했다고 Search Console의 보고서가 즉시 변경되는 것은 아닙니다.
Google이 URL을 다시 확인하고 데이터를 처리하는 과정이 필요할 수 있습니다.
따라서 오늘 문제를 수정했는데 보고서에 기존 상태가 남아 있다는 이유만으로 설정을 반복해서 변경할 필요는 없습니다.
현재 상태 확인이 중요한 특정 URL이라면 URL 검사와 필요한 경우 실시간 URL 테스트를 활용합니다.
✓ 실제 404 상황을 네 가지 사례로 판단해 봅니다
A 사례
몇 달 전에 직접 삭제한 게시글입니다.
대체할 콘텐츠가 없고 다른 글에서도 연결하고 있지 않습니다.
이 경우 해당 URL이 404인 것은 자연스러울 수 있습니다. 단순히 Search Console에서 404를 없애기 위해 페이지를 다시 만들 필요는 없습니다.
B 사례
현재 공개 중이어야 하는 중요한 게시글입니다.
그런데 실제 URL을 열었더니 페이지를 찾을 수 없습니다.
이 경우 티스토리의 공개 상태와 정확한 URL을 확인하고 Search Console URL 검사 등을 이용해 현재 페이지 상태를 점검해야 합니다.
C 사례
한 번도 만든 적 없는 이상한 URL입니다.
실제 게시글도 없고 블로그 내부에서 해당 주소를 연결하고 있지도 않습니다.
원래 존재할 필요가 없는 주소라면 해당 URL을 위해 별도의 페이지를 만들 필요는 없습니다.
D 사례
예전에 게시글을 삭제했는데 다른 게시글 여러 개에서 삭제된 주소를 계속 연결하고 있습니다.
삭제한 페이지를 무조건 복구하기보다 기존 글에 남아 있는 링크를 제거하거나 실제로 관련 있는 콘텐츠로 수정합니다.
이 네 가지 사례를 기준으로 생각하면 404를 발견할 때마다 같은 조치를 반복하는 일을 줄일 수 있습니다.
✓ 404가 많다는 이유만으로 블로그 전체 문제라고 판단하지 않습니다
게시글을 여러 개 정리했거나 오래 운영한 블로그라면 존재하지 않는 URL이 발견될 수 있습니다.
외부에서 잘못된 주소가 만들어졌을 수도 있습니다.
따라서 404 개수만으로 블로그의 상태를 평가하지 않습니다.
확인해야 할 것은 비교적 명확합니다.
현재 존재해야 하는 중요한 페이지가 정상적으로 열리는가?
블로그 내부에서 존재하지 않는 주소를 계속 연결하고 있는가?
실제로 삭제한 URL은 더 이상 필요한 콘텐츠가 아닌가?
이 세 가지를 우선 확인하면 불필요하게 모든 404를 수정하려는 작업을 줄일 수 있습니다.
✓ 티스토리 404 최종 체크리스트
□ Search Console에서 404 URL을 확인했다.
□ 해당 URL을 브라우저에서 직접 열어봤다.
□ 원래 존재해야 하는 페이지인지 판단했다.
□ 직접 삭제한 게시글인지 확인했다.
□ 만든 적 없는 잘못된 URL인지 확인했다.
□ 내부 링크가 잘못된 주소를 가리키고 있지 않은지 확인했다.
□ 중요한 정상 페이지라면 URL 검사를 확인했다.
□ 필요할 경우 실시간 URL 테스트를 사용했다.
□ 삭제된 URL을 위해 불필요한 페이지를 만들지 않았다.
□ 수정 후 Search Console 반영에 시간이 걸릴 수 있다는 점을 고려했다.
자주 묻는 질문
Q1. Search Console에 404가 있으면 모두 수정해야 하나요?
아닙니다. 정상적으로 삭제했고 더 이상 존재할 필요가 없는 URL이라면 404가 자연스러운 상태일 수 있습니다. 현재 존재해야 하는 페이지가 404인지 먼저 구분하는 것이 중요합니다.
Q2. 삭제한 티스토리 글이 404로 나오면 다시 만들어야 하나요?
반드시 그럴 필요는 없습니다. 정상적으로 삭제한 콘텐츠이고 대체할 필요도 없다면 다시 만들 이유가 없습니다. 다만 다른 게시글에서 삭제된 주소를 계속 연결하고 있는지는 확인하는 것이 좋습니다.
Q3. 만든 적 없는 URL이 404로 표시되면 어떻게 하나요?
실제 게시글 주소인지 확인하고 블로그 내부에서 잘못 연결한 URL인지 살펴봅니다. 원래 존재할 필요가 없는 주소이고 내부 링크에도 문제가 없다면 단순히 404를 없애기 위해 새로운 페이지를 만들 필요는 없습니다.
Q4. 현재 정상적으로 열리는 글이 Search Console에서는 404로 보입니다.
최근 페이지를 복구했거나 상태가 변경됐다면 Search Console에 이전 정보가 남아 있을 수 있습니다. 중요한 URL이라면 URL 검사를 확인하고 필요한 경우 실시간 URL 테스트로 현재 접근 상태를 살펴볼 수 있습니다.
Q5. 404와 소프트 404는 같은 것인가요?
다릅니다. 일반적인 404는 존재하지 않는 페이지가 그에 맞는 상태를 반환하는 경우입니다. 소프트 404는 실제 콘텐츠가 없거나 페이지를 찾을 수 없는 것처럼 보이지만 정상 페이지와 비슷한 응답을 반환하는 등의 상황을 의미합니다.
마무리|404 개수보다 URL의 역할을 먼저 확인합니다
Search Console에서 ‘찾을 수 없음(404)’을 발견했다고 모든 URL을 복구할 필요는 없습니다.
삭제한 게시글처럼 실제로 존재하지 않아야 하는 URL이라면 404가 자연스러운 상태일 수 있습니다.
반대로 현재 정상적으로 제공되어야 하는 중요한 게시글이 404라면 실제 URL과 공개 상태를 확인하고 필요하면 URL 검사와 실시간 URL 테스트를 이용해 원인을 점검합니다.
또한 삭제된 게시글이나 잘못된 주소를 블로그 내부에서 계속 연결하고 있다면 해당 내부 링크를 정리합니다.
핵심은 Search Console의 404 숫자를 0으로 만드는 것이 아닙니다.
존재해야 하는 페이지는 정상적으로 열리고, 존재할 필요가 없는 URL은 불필요하게 복구하지 않으며, 방문자가 잘못된 내부 링크를 따라가지 않도록 관리하는 것이 더 중요합니다.
함께 보면 좋은 글
티스토리 게시글 삭제 전 확인할 것|검색 유입 있는 글을 실수로 지우지 않는 방법
티스토리 게시글 삭제 전 확인할 것|검색 유입 있는 글을 실수로 지우지 않는 방법
티스토리를 오래 운영하다 보면 삭제하고 싶은 게시글이 생깁니다.정보가 오래된 글도 있고, 지금 운영하는 블로그 주제와 맞지 않는 글도 있습니다. 비슷한 내용의 게시글을 다시 작성하면서
onsum.kr
다음 글 예고
티스토리 Search Console ‘크롤링됨 - 현재 색인이 생성되지 않음’ 확인 방법|기다릴 글과 개선할 글 구분하기
다음 글에서는 Google이 게시글을 크롤링했지만 아직 색인하지 않은 상태를 발견했을 때 무엇부터 확인해야 하는지 정리하겠습니다.
새로 작성한 글이라 기다려볼 수 있는 경우와 콘텐츠를 다시 점검해야 하는 경우를 구분하고, URL 검사와 색인 생성 요청을 어떻게 활용할지도 함께 살펴보겠습니다.