404 목록은 숫자만 보고 줄이려고 하면 오히려 더 헷갈렸습니다. 저는 먼저 어떤 주소가 왜 생겼는지 메모하고, 공개 글 안에 남은 링크인지 예전 테스트 흔적인지 나눠 보기로 했습니다.
- 어떤 URL에서 404가 나오는지 목록으로 봅니다.
- 삭제한 글인지 주소가 바뀐 글인지 나눕니다.
- 내부 링크가 아직 이전 주소를 가리키는지 확인합니다.
- 필요한 경우에만 이동 처리를 고민합니다.
Search Console 화면만 보고 판단하면 헷갈린다
Search Console에는 결과가 짧게 표시되지만, 운영자는 그 주소가 어떤 작업에서 나온 것인지 알고 있어야 했습니다. 화면의 문구보다 제가 남긴 변경 기록이 더 도움이 될 때가 있었습니다.
- 처음에는 404가 보이면 모두 나쁜 신호라고 생각했습니다.
- 테스트 글을 지운 흔적까지 같은 문제로 묶어 보았습니다.
- 내부 링크 확인을 늦게 해서 원인을 다시 찾아야 했습니다.
404를 정리할 때 남긴 메모 방식
404를 발견하면 바로 리디렉션부터 만들지 않고, 남겨둘 필요가 있는 주소인지 먼저 판단했습니다. 단순히 사라져도 되는 테스트 글이라면 과하게 손대지 않는 쪽이 더 깔끔했습니다.
404를 오류 이름보다 주소 기록으로 봤다
HTTP 오류 관련 자료는 오류가 무조건 나쁘다는 식으로 읽지 않으려고 했습니다. 제 사이트에서 실제로 사라진 URL인지, 크롤러가 오래된 주소를 다시 본 것인지 구분하는 데 참고했습니다.
제가 본 화면만으로 판단하면 놓치는 부분이 있을 것 같아 Search Console 페이지 색인 도움말도 참고했습니다. 404를 바로 지우려 하지 않은 이유를 확인할 때 주소 오류를 추적할 때 제가 실제로 본 404 목록과 도움말의 용어를 맞춰 보기 위한 링크입니다.
삭제한 URL을 따로 빼서 봐야 했던 이유
삭제 테스트 글을 정리한 기록과 이 글은 서로 이어져 있습니다. 글을 지운 순간보다 지운 뒤 어디에 흔적이 남는지를 보는 쪽이 더 중요했습니다.
Search Console의 404를 보기 전에 색인 제외 설정이 먼저 정리되어 있어야 했습니다. noindex 설정을 확인하면서 알게 된 워드프레스 색인 문제에서 그 기준을 먼저 남겼습니다.
404를 다시 만났을 때 열어볼 메모
다음에 404를 보면 먼저 날짜, URL, 직전에 바꾼 설정을 같이 적을 생각입니다. 이렇게 세 가지를 묶어두면 나중에 같은 주소를 다시 만났을 때 해석이 빨라집니다.
404가 보이면 바로 큰 문제일까?
Q. Search Console에 404가 보이면 바로 큰 문제가 생긴 건가요?
A. 꼭 그렇지는 않았습니다. 테스트 글을 지웠거나, 예전에 있던 URL이 사라졌다면 404가 자연스럽게 보일 수 있었습니다. 다만 공개 글 안에서 그 URL로 계속 연결되고 있다면 문제라고 봤습니다. 저는 404 숫자 자체보다 어디에서 그 URL로 가는 길이 남아 있는지를 먼저 확인하려고 했습니다.