![[구글 SEO 04] 색인이 무너졌다 회복하기까지, 전 과정](https://img.thenullpage.com/posts/5558/5558_1_9276bb.webp)
어느 날 GSC를 열었더니 색인 생성됨 그래프가 절벽처럼 꺾여 있었다. 잘 올라가던 색인 수가 급감하고, 발견됨-현재 색인 안 됨이 한때 700건대까지 치솟았다. 노출수도 바닥을 쳤다. 패닉이 오기 딱 좋은 상황인데, 이럴 때일수록 감으로 손대면 안 된다. 잘못 건드리면 회복은커녕 더 무너진다.
미리 말해두면, 색인 붕괴 대응의 제1원칙은 침착함이다. 무너졌다는 공포에 이것저것 동시에 바꾸면, 나중에 무엇이 원인이었고 무엇이 약이었는지 영영 분리할 수 없게 된다. 그러면 다음에 또 무너졌을 때 배운 게 하나도 없다. 진단, 단일 조치, 관찰. 이 순서를 지키는 게 회복의 핵심이자, 같은 사고를 두 번 안 겪는 유일한 방법이다. 이번 편은 색인이 무너진 원인을 감별진단으로 좁히고 다시 회복시킨 전 과정 기록이다.
1. 먼저 증상을 정확히 본다
제일 먼저 GSC 색인 리포트에서 어떤 사유 항목이 급증했는지를 본다. 색인 급감은 원인마다 나타나는 항목이 다르다. noindex에 의해 제외됨이 늘었는지, 대체 페이지(canonical)가 늘었는지, 찾을 수 없음(404)이 늘었는지, 서버 오류(5xx)가 늘었는지. 어느 항목이 튀었는지가 곧 범인의 지문이다.
이 항목 하나가 용의자를 좁히는 첫 단서다. 나는 이 단계에서 색인 급감과 동시에 특정 사유가 튄 걸 확인하고, 막연한 불안 대신 구체적인 용의자 목록을 만들 수 있었다. 그리고 급감이 시작된 날짜를 최근 배포 이력과 나란히 겹쳐봤다. 색인 붕괴는 거의 항상 어떤 코드 배포나 설정 변경 직후에 시작되기 때문이다. 그래프가 꺾인 지점과 배포 로그의 타임스탬프를 맞춰보는 것만으로 용의자가 절반으로 준다. 원인 모를 사고는 드물고, 대개는 내가 어제 만진 것이 범인이다.
실제로 나는 급감을 확인한 첫날, 아무것도 고치지 않고 딱 두 가지만 했다. 그래프를 캡처해 날짜를 기록하고, 최근 2주간의 배포 목록을 뽑아 나란히 놓았다. 이 30분이 이후 며칠의 삽질을 막아줬다. 패닉에 손부터 대는 대신 증거부터 모으는 게 언제나 회복의 첫 단추다.
2. 감별진단, 용의자를 하나씩 배제
색인 붕괴의 흔한 원인은 대략 다섯이다. noindex 오염, canonical 오류, 서버 5xx나 자산 fetch 실패, URL 변경 여파, 콘텐츠 품질. 이걸 하나씩 배제한다. 내 경우 결정적이었던 건 canonical과 noindex의 혼용이었다. 서로 싸우는 두 신호를 한 페이지에 같이 박아둔 것이다.
한 페이지에 대표 주소를 지정하는 canonical과 색인하지 말라는 noindex가 동시에 걸려 있으면, 구글은 모순된 신호 앞에서 안전한 쪽, 즉 색인에서 빼는 쪽을 택한다. 이 둘은 절대 한 페이지에 같이 두면 안 된다. 전수 검사로 오염된 페이지를 찾아 정리하는 게 1순위였다. 이런 전수 검사는 눈으로 몇천 페이지를 볼 수 없으니, 헤드리스 브라우저나 크롤러로 전 URL의 메타 태그를 긁어 자동으로 대조해야 한다. 나는 이 스크립트로 오염 페이지를 몇 분 만에 색출했다.
감별진단에서 유용한 습관 하나는, 정상인 페이지와 비정상인 페이지를 짝지어 비교하는 것이다. 색인된 글 하나와 색인 안 된 글 하나를 URL 검사로 나란히 열어 렌더링 HTML과 메타 태그를 비교하면, 무엇이 다른지가 눈에 띈다. 이 차이가 곧 원인이다. 혼자 노려보는 것보다 대조가 훨씬 빠르다.
감별진단에서 빼놓기 쉬운 용의자가 하나 더 있다. 사이트 전체에 영향을 주는 공통 요소, 예컨대 헤더나 공통 템플릿, 전역 미들웨어의 변경이다. 개별 글은 안 건드렸는데 색인이 통째로 흔들린다면 범인은 대개 이 공통 레이어에 있다. 개별 페이지만 노려보다 몇 시간을 허비한 뒤에야 나는 이걸 배웠다.
3. 자산 fetch 실패는 404가 아니라 503
또 하나 중요한 교훈. 서버 사이드 렌더링(SSR) 중에 CSS나 JS 같은 자산을 못 가져오는 순간, 실수로 404를 내보내면 안 된다. 자산 실패는 대개 일시적인 인프라 장애인데, 여기에 404를 주면 구글은 이 페이지가 영구히 없어졌다고 판단해서 기존에 잘 색인돼 있던 것까지 purge 한다. 순간의 장애가 영구 손실로 번지는 것이다.
정답은 503(Service Unavailable)에 Retry-After 헤더를 붙여, 지금 잠깐 문제가 있으니 이따 다시 오라고 알려주는 것이다. 마찬가지로 알맹이 없는 평문 200(소프트 404)도 금지다. 일시 장애엔 503, 영구 삭제엔 410, 정상이면 200. 이 상태 코드 세 개의 구분이 색인 방어의 핵심이다. 사소해 보이는 이 숫자 하나가 잘 색인된 수천 페이지를 지키기도 하고 한꺼번에 날리기도 한다. 그래서 SSR 분기에서 예외가 터졌을 때 무슨 코드를 내보내는지를 반드시 통제해야 한다.
상태 코드 이야기를 하나만 덧붙이면, robots.txt 자체가 일시적으로 5xx를 주는 상황도 위험하다. 구글은 robots.txt를 못 읽으면 안전을 위해 크롤을 통째로 멈추기도 한다. 그래서 자산뿐 아니라 robots.txt와 사이트맵 같은 인프라성 응답도 장애 시 404가 아니라 503으로 처리되게 해둬야 한다.
덧붙이면 503을 줄 때 Retry-After 값도 현실적으로 잡아야 한다. 몇 초 뒤 복구될 장애에 몇 시간짜리 Retry-After를 주면 그동안 크롤이 통째로 멈춘다. 반대로 너무 짧으면 봇이 장애 중에도 계속 두드려 서버를 더 힘들게 한다. 장애의 실제 성격에 맞춰 이 값을 조절하는 것까지가 503 처리의 완성이다.
4. 되돌릴 수 없는 조치일수록 신중히
원인을 좁혔으면 회복 조치를 한다. 죽은 URL은 410으로 정리하고, 정돈한 사이트맵을 재제출하고, 핵심 URL 몇 개만 골라 재색인을 요청하고, noindex 잔상을 걷어내고, 발행을 다시 규칙적으로 돌린다. 여기까지는 대부분 되돌릴 수 있는 조치들이다.
여기서 원칙 하나. URL을 또 바꾸거나 구조를 갈아엎는 식의 되돌리기 어려운 조치는 회복 중에 함부로 하면 안 된다. 색인은 무너지긴 쉽고 회복은 느리다. 큰 변경을 여러 개 동시에 배포하면 나중에 무엇이 효과였고 무엇이 독이었는지 분리할 수도 없다. 한 번에 하나씩, 관찰 가능하게 바꾼다. 조급함이 두 번째 사고를 부른다. 실제로 회복 중에 불안해서 이것저것 만지다 다시 무너뜨리는 경우가, 최초 사고보다 더 흔하다.
회복 조치의 우선순위를 정할 때 나는 되돌리기 쉬운 것부터, 효과가 확실한 것부터 손댔다. 죽은 URL 정리와 사이트맵 재제출은 위험이 낮고 효과가 분명하니 먼저, 구조 변경처럼 위험한 건 맨 뒤로 미뤘다. 이렇게 순서를 정해두면 급한 마음에 위험한 카드부터 꺼내는 실수를 막을 수 있다.
회복 조치를 할 때 나는 각 조치에 날짜 라벨을 붙여 기록했다. 며칠에 죽은 URL 410 처리, 며칠에 사이트맵 재제출, 이런 식이다. 그래야 며칠 뒤 지표가 움직였을 때 어느 조치가 효과였는지 되짚을 수 있다. 여러 조치를 뭉뚱그려 같은 날 몰아서 하면, 회복은 될지 몰라도 무엇 덕분인지는 영영 모른 채 다음 사고를 맞는다.
5. 회복은 지표로 확인한다
회복은 체감이 아니라 숫자로 확인해야 한다. 나는 발견됨-색인 안 됨이 700건대에서 500건대로, 약 26퍼센트 줄어드는 걸 보고 방향이 맞다고 판단했다. 이 항목이 꾸준히 감소하고, 색인 생성됨이 다시 우상향하며, 노출수가 살아나면 회복 신호다. 이 세 지표가 같은 방향을 가리킬 때 비로소 회복이라 부를 수 있다.
다만 하루 이틀로 판단하면 안 되고 몇 주 추세로 봐야 한다. GSC 데이터는 3일에서 5일씩 지연되기 때문이다. 오늘 조치의 효과는 다음 주에나 그래프에 나타난다. 그래서 매일 새로고침하며 일희일비하기보다, 주 단위로 추세선의 기울기를 보는 게 정신 건강에도 좋고 판단도 정확하다. 색인이 한 번 무너져 보면, 애초에 무너질 짓을 안 하는 게 최선이라는 걸 뼈저리게 느낀다. 그 첫걸음이 바로 다음 편 주제, URL을 절대 바꾸지 않는 것이다.
회복이 시작됐다고 방심하면 안 되는 이유가 하나 더 있다. 같은 실수가 재발하지 않게 재발 방지 장치를 심어야 진짜로 끝난 것이다. 나는 canonical과 noindex가 한 페이지에 같이 걸리면 배포 전에 걸러내는 검사를 파이프라인에 넣었다. 사고는 고치는 것보다 다시 안 나게 막는 게 훨씬 싸다.