장애를 복구해 홈페이지가 다시 열린 날에도 검색 유입은 이전 수준으로 돌아오지 않을 수 있습니다. 이때 ‘복구 실패’라고 단정하기 전에 서버가 콘텐츠를 정상 제공하는지와 검색 시스템이 그 상태를 다시 처리했는지를 구별해야 합니다. 여기서는 검색 유입 감소가 관찰된 기간에 실제 서버 오류 기록도 있는 경우를 다룹니다. 오류 증거가 없는 모든 감소를 서버 탓으로 설명하는 글은 아닙니다.
기술 담당자에게는 홈 화면 캡처만 요청하지 않습니다. 감소한 주요 페이지의 정확한 주소, 오류가 확인된 시간, HTTP 응답 코드를 모읍니다. 홈페이지는 열려도 특정 경로가 계속 오류일 수 있으므로 실제 검색 방문이 들어오던 주소에서 확인해야 합니다. 이동 응답이 있다면 출발 주소와 최종 도착 주소를 따로 적습니다. 이 글만으로 서버 설정이나 주소를 바꾸라는 뜻은 아니며 먼저 현재 응답을 확인하는 단계입니다.
Google의 공식 HTTP 상태 설명에 따르면 5xx 서버 오류와 429 응답은 크롤러가 수집 속도를 일시적으로 낮추게 하는 신호입니다. 계속 오류를 반환하는 URL은 Google 검색 색인에서 결국 제외될 수 있습니다. 서버가 다시 2xx로 응답하면 수집 속도는 점진적으로 늘어날 수 있습니다. 따라서 복구 직후 방문이 적다는 관찰만으로 새로운 원고가 부족하다고 판단하기 어렵습니다. 이 설명은 Google의 처리 방식이며 다른 검색 서비스의 동일한 일정이나 결과를 뜻하지 않습니다.
정상 응답 코드만으로 확인을 끝내지도 않습니다. 가상의 복구 사례에서 상품 안내 주소가 200으로 응답하지만 실제 내용은 ‘잠시 후 다시 접속해 주세요’라는 화면뿐일 수 있습니다. 이 경우 요청은 성공으로 표시돼도 독자에게 필요한 본문은 돌아오지 않은 것입니다. Google도 2xx가 색인을 보장하지 않으며 오류 내용이나 빈 화면은 soft 404로 처리될 수 있다고 설명합니다. 응답 코드와 함께 제목, 핵심 본문, 필요한 연결이 복원됐는지를 확인합니다.
Search Console의 URL 검사를 사용할 수 있다면 저장된 색인 정보와 실제 URL 테스트 결과를 구별해 읽습니다. 실제 URL 테스트는 현재 접근 가능성을 확인하는 데 쓰고, 저장된 색인 정보에서는 Google이 기록한 색인 등록 상태와 마지막 크롤링 시점을 확인합니다. 색인에 등록됐다는 표시와 실제 테스트 통과 중 어느 것도 검색결과에 표시됐다는 증거로 바꾸어 보고하지 않습니다. 실제 검색결과에서 해당 주소가 보였는지는 관찰한 검색어와 시각을 붙여 별도로 기록합니다. 그런 관찰이 없다면 검색 노출 확인은 미확인 상태로 둡니다. 마지막 크롤링 시점이 복구 전이라면 저장된 정보와 현재 테스트가 다른 시점을 설명할 수 있다는 점도 남깁니다.
운영 기록에는 서버 복구 확인, 본문 제공 확인, 검색 도구의 관찰, 검색 유입을 서로 다른 시점으로 적습니다. 첫 두 항목이 확인됐다면 기술 복구에서 확인한 범위를 보고할 수 있습니다. 검색에서 다시 처리됐다는 증거가 아직 없다면 그 부분을 대기로 남깁니다. ‘며칠 안에 원래 순위로 돌아온다’는 약속을 만들거나 유입 숫자를 맞추려고 같은 글을 다른 주소로 복제하지 않습니다.
오류가 재발하면 정상 상태를 기다리던 기록과 분리해 재발 주소와 시간을 전달합니다. 반대로 정상 본문과 검색 상태를 확인한 뒤에도 유입이 낮다면 그때는 노출 기회나 검색어별 변화 등 다른 근거를 살펴볼 수 있습니다. 서버 장애의 종료 시각과 검색 유입 회복 시각을 하나로 취급하지 않아야, 실제로 해결한 문제와 아직 설명되지 않은 감소를 구별할 수 있습니다.
응답 처리의 근거: Google Crawling Infrastructure의 HTTP 상태 안내 https://developers.google.com/crawling/docs/troubleshooting/http-status-codes 검사 결과를 구분하는 근거: Google Search Console URL 검사 도움말 https://support.google.com/webmasters/answer/9012289?hl=ko