37장. 블로그 저품질·색인 누락·로직 변동 대응법: 삭제 전에 확인할 점검 순서

검색 유입이 급락해도 글 삭제나 재발행부터 하지 마십시오. 먼저 Search Console에서 하락 범위와 URL의 색인 상태를 확인하고, 실제 페이지의 접속·리디렉션·noindex·canonical을 점검한 뒤, 검색 수요와 순위 하락을 분리해야 합니다. 사이트 전체 장애와 특정 글의 경쟁력 하락은 처방이 전혀 다릅니다.

“저품질”은 Google Search Console의 공식 진단명이 아닙니다. 원인을 모르는 여러 현상을 한 단어로 묶으면 정상적인 색인 제외까지 오류로 고치거나, 회복 가능한 URL을 지우게 됩니다. Google의 URL 검사 도구 안내와 Google 검색 작동 방식 안내를 기준으로 “발견, 크롤링, 색인, 노출, 클릭” 중 어디에서 끊겼는지 찾아야 합니다.

그래프가 꺾인 순간에 먼저 보존할 네 가지

문제를 고치기 전에 비교 기준을 남깁니다. Search Console 실적 보고서에서 하락 전후를 같은 요일 수와 길이로 비교하고, 날짜·영향 검색엔진·감소한 쿼리·감소한 페이지를 내보냅니다. 분석 도구의 자연 검색 세션과 서버 장애 기록, 최근 배포 내역도 같은 시간축에 놓습니다.

하락 시작일과 갑자기 떨어졌는지 서서히 떨어졌는지
전체 사이트, 디렉터리, 페이지, 쿼리 가운데 실제 영향 범위
최근 도메인 이전, 테마 변경, robots·canonical·리디렉션 수정
노출수만 줄었는지, 순위·클릭률·클릭이 각각 어떻게 변했는지

검색 결과의 개인화된 화면 몇 번만 보고 순위를 단정하지 않습니다. Search Console 수치는 처리 지연과 집계 차이가 있을 수 있으므로 실시간 장애 모니터처럼 쓰지 말고 추세와 범위를 찾는 데 사용합니다. 이 기록을 남겨야 수정 뒤 회복 여부도 같은 조건으로 비교할 수 있습니다.

비교 창은 짧은 전주 대비 하나로 끝내지 않습니다. 가능하면 실적 보고서의 장기 범위를 열어 최근 16개월 안에서 같은 계절이 반복됐는지 보고, 최근 기간 대 직전 기간과 전년 동기를 함께 비교합니다. 웹·이미지·동영상·뉴스 검색 유형도 나눕니다. 웹 클릭은 유지되는데 이미지만 줄었다면 사이트 전체 품질 문제로 확대할 근거가 약하고, 전년에도 같은 주에 내려갔다면 업데이트보다 수요 계절성을 먼저 검토할 수 있습니다.

Search Console 실제 화면을 따라 원인을 좁힙니다

실적 보고서에서 페이지와 검색어를 교차 확인합니다

먼저 검색 유형과 기간을 동일하게 맞춘 뒤 페이지 탭에서 감소 폭이 큰 URL을 찾습니다. 그 URL을 필터로 걸고 검색어 탭을 봅니다. 노출과 평균 게재순위가 함께 하락했다면 순위·수요·검색 결과 구성 변화를 의심할 수 있습니다. 노출은 비슷한데 클릭만 줄었다면 제목의 기대 일치, 경쟁 결과, 공식 사이트나 새 검색 기능의 등장처럼 클릭률 요인이 더 가깝습니다.

브랜드 검색어까지 사이트 전반에서 동시에 사라졌다면 기술 또는 큰 범위의 변화 가능성을 먼저 봅니다. 반면 지난해 같은 행사명이나 종료된 지원금 쿼리만 감소했다면 계절·마감 효과일 수 있습니다. “클릭 감소”라는 결과는 같아도 삭제 여부는 정반대가 됩니다.

페이지 색인 생성 보고서에서 ‘이유’를 읽습니다

색인되지 않음의 총개수만 보지 말고 사유와 URL 예시를 엽니다. 리디렉션되는 이전 주소, 중복 필터 URL, 로그인 페이지, 의도적으로 noindex한 페이지는 검색에 없어도 정상일 수 있습니다. 반대로 핵심 글이 robots.txt에 의해 막혔거나, 서버 오류를 내거나, 실수로 noindex되었다면 우선 복구 대상입니다.

Google은 색인을 보장하지 않습니다. 사이트맵 제출이나 색인 요청은 발견·재검토를 돕는 신호이지 노출 계약이 아닙니다. 모든 제외 URL을 반복 제출하는 대신 검색 결과에 반드시 있어야 하는 대표 콘텐츠가 어떤 사유로 빠졌는지부터 판단합니다.

URL 검사에서 현재 URL과 Google이 본 상태를 비교합니다

영향 URL을 정확히 입력해 색인 여부, 마지막 크롤링, 사용자 선언 canonical과 Google 선택 canonical, 크롤링 허용 여부를 봅니다. 실제 URL 테스트는 현재 페이지가 Googlebot에 접근 가능한지 확인하는 데 도움이 되지만, “현재 접근 가능”과 “색인됨”은 같은 말이 아닙니다. 검사 결과의 각 항목과 검사 날짜를 기록합니다.

Google이 다른 canonical을 선택했다면 두 페이지가 실제로 비슷한지, 내부링크·사이트맵·canonical이 서로 다른 주소를 가리키는지 확인합니다. https와 http, www 유무, 끝 슬래시, 매개변수 주소가 섞여 있으면 대표 신호를 일관되게 정리합니다. canonical은 명령이 아니라 신호이므로 내용이 서로 다른 페이지를 억지로 한 URL에 지정하는 용도로 쓰지 않습니다. 공식 기준은 중복 URL 통합 문서에서 확인할 수 있습니다.

수동 조치와 보안 문제를 별도 확인합니다

알고리즘 변화와 수동 조치를 같은 것으로 취급하지 않습니다. Search Console의 수동 조치 보고서에 표시가 있다면 설명된 문제와 영향 범위를 기준으로 수정하고 재검토 절차를 따릅니다. 보안 문제 보고서에 해킹·악성 다운로드 징후가 있다면 콘텐츠 리라이트보다 사이트 복구와 보안이 우선입니다. 보고서에 아무 표시가 없다는 사실만으로 순위가 보장되는 것은 아니지만, 적어도 대응 경로를 구분할 수 있습니다.

브라우저에서 기술 상태를 재현합니다

Search Console을 닫기 전에 영향 URL을 모바일과 시크릿 창에서 직접 엽니다. 정상 본문이 200 상태로 표시되는지, 로그인이나 홈으로 잘못 이동하지 않는지, SSL 경고·무한 로딩·쿠키 팝업 가림이 없는지 봅니다. 소스 또는 SEO 설정에서 robots meta의 noindex, canonical 대상, 구조화 데이터보다 앞서 기본 본문이 실제 HTML에 존재하는지 확인합니다.

최근 플러그인이나 테마를 바꿨다면 “변경했다”는 사실만으로 범인을 정하지 말고 영향을 재현합니다. 캐시가 이전 noindex를 제공하는지, 모바일 사용자 에이전트에 다른 응답을 주는지, 서버 로그에 5xx가 급증했는지 확인합니다. 명백한 차단은 수정한 뒤 사이트맵과 내부링크를 정리하고 필요한 URL만 재검토 요청합니다.

URL 검사의 저장된 크롤링본과 실시간 테스트도 나란히 봅니다. 저장된 화면에서는 Google이 당시 받은 HTML, HTTP 응답 헤더, 차단·지연된 리소스와 JavaScript 콘솔 메시지를 확인하고, 실시간 테스트에서는 현재 배포가 같은 본문과 지시문을 내는지 확인합니다. 라이브 화면 하나가 성공했다고 과거 색인 문제가 없었다는 뜻은 아니며, 반대로 부수 이미지나 추적 스크립트의 일시 실패만으로 본문 색인 실패를 확정해서도 안 됩니다. 핵심 본문, canonical, robots 지시문, 주요 CSS·JavaScript가 어느 시점부터 달라졌는지를 변경 기록과 연결해야 합니다.

영향 범위를 세 단계로 나누면 조사 비용이 줄어듭니다

사이트 전체에서 브랜드 검색과 여러 디렉터리의 노출이 같은 날 함께 줄었다면 서버 장애, 도메인·프로토콜 변경, 전역 noindex, robots 설정, 수동 조치와 보안 문제를 먼저 확인합니다. 홈만 검사하고 끝내지 말고 서로 다른 템플릿의 대표 URL을 뽑아 응답과 canonical을 비교합니다. 사이트 전체처럼 보여도 한 국가나 한 기기만 감소했다면 분석 측정 오류나 모바일 렌더링 문제일 수 있어 필터를 다시 나눕니다.

페이지군만 하락했다면 공통점을 찾습니다. 같은 카테고리, 작성 시기, 템플릿, 언어, 구조화된 경로, 주제, 내부링크 깊이를 기준으로 묶고 정상 페이지군과 대조합니다. 특정 디렉터리에만 잘못된 canonical이 배포됐는지, 종료된 제도를 다룬 글만 수요가 줄었는지, 유사 지역 페이지가 대표 URL 하나로 묶였는지에 따라 기술·수요·품질 처방이 갈립니다.

페이지군 비교는 하락한 URL만 모은 목록이 아니라 같은 시점에 노출된 코호트로 만듭니다. 예를 들어 새 템플릿을 받은 URL, 이전 템플릿을 유지한 URL, 같은 주제지만 수정하지 않은 URL을 나누고 각 군에서 대표 표본을 고릅니다. 발행 월, 디렉터리, 언어, 기기, 내부링크 깊이가 크게 다른 페이지를 한 군에 섞으면 템플릿 효과와 오래된 수요를 구분하기 어렵습니다. 각 코호트에는 URL 수, 변경 노출일, 배포 전후 응답·canonical·색인 상태, 클릭·노출 비교 기간을 붙이고 상승·유지·하락 표본을 모두 남깁니다. 수정하지 않은 군을 보존해야 전체 시장 변화와 내 배포의 영향을 비교할 수 있습니다.

단일 URL이라면 사이트를 전면 개편하지 않습니다. 정확한 주소의 URL 검사, 현재 응답, 선택된 canonical, 내부링크, 해당 쿼리의 노출과 순위를 확인하고 비슷한 정상 URL 하나와 비교합니다. 한 글의 날짜가 낡았거나 제목이 현재 의도와 어긋난 문제를 전체 도메인의 벌점으로 확대하면 불필요한 삭제가 시작됩니다. 반대로 단일 URL에서 발견한 템플릿 오류가 같은 페이지군에도 재현되는지 한 번은 표본 검사합니다.

Search Console 메뉴는 같은 순서로 순회합니다

실적의 검색결과: 비교 기간을 맞추고 클릭·노출·평균 CTR·평균 게재순위를 켠 뒤 페이지, 검색어, 국가, 기기 순으로 범위를 좁힙니다.
페이지 색인 생성: 감소 페이지가 실제로 제외됐는지, 제외 사유가 의도한 리디렉션·중복인지 오류인지 URL 예시에서 확인합니다.
URL 검사: 대표 피해 URL과 정상 비교 URL을 각각 넣어 색인 상태, 크롤링 허용, 마지막 크롤링, 선언·선택 canonical을 기록합니다. 필요할 때만 실제 URL 테스트를 사용합니다.
사이트맵과 링크: 대표 주소가 사이트맵에 있고 내부에서 연결되는지 확인하되, 발견 신호를 순위 보장으로 해석하지 않습니다.
수동 조치와 보안 문제: 표시된 항목이 있다면 그 지침을 우선하고, 없다면 기술·수요·품질 진단으로 돌아갑니다.

이 순서를 지키면 “노출이 줄었다”는 현상에서 바로 색인 요청 버튼으로 뛰어가는 일을 막을 수 있습니다. 화면 캡처에는 선택한 속성, 검색 유형, 필터와 날짜를 함께 담아 나중에 다른 조건의 그래프를 잘못 비교하지 않게 합니다.

기술·수요·품질 가설은 서로 다른 증거를 요구합니다

기술 원인은 URL 접근과 처리에서 재현됩니다. 4xx·5xx, 차단, 잘못된 리디렉션, 빈 렌더링, 전역 canonical처럼 운영자가 직접 확인할 신호가 있고 수정 뒤에도 재검사가 가능합니다. 수요 원인은 페이지가 정상 색인된 상태에서 관련 쿼리 전체의 노출이 계절·마감·사회 관심 변화와 함께 줄어드는 모습에 가깝습니다. 이 경우 내용을 늘려도 사라진 검색량이 돌아오는 것은 아니므로 다음 공고 경로나 상시 질문으로 역할을 바꿉니다.

품질과 의도 문제는 같은 질문에서 다른 결과가 더 직접적이고 최신의 답을 제공하는지 비교해야 합니다. 오래된 조건, 출처 없는 단정, 답보다 긴 서론, 여러 지역명을 바꾼 유사 본문, 작성 목적을 벗어난 광고성 추천이 단서가 됩니다. 알고리즘 업데이트 시점과 겹쳤다는 사실만으로 품질 결함을 확정하지 말고, 유지된 페이지와 하락한 페이지 사이에서 반복되는 차이를 찾습니다. 세 원인이 동시에 있을 수도 있으므로 명백한 기술 오류부터 제거한 뒤 수요와 내용 평가를 이어갑니다.

삭제 전에 복구 가능한 자산을 봉인합니다

삭제 후보의 현재 HTML 또는 편집 원고, 제목과 설명, 공개일·수정일, Search Console의 페이지·검색어 내보내기, 외부 링크와 내부링크, 첨부 이미지의 출처를 보존합니다. 기존 URL이 받은 링크와 댓글, 과거에 해결했던 검색 의도, 다른 글에서 참조하는 위치도 기록합니다. 백업은 다시 대량 발행하기 위한 복제품이 아니라 결정 근거와 필요한 문장을 되살릴 수 있는 편집 자료입니다.

그 다음 최신화, 역사 자료로 유지, 관련 글과 통합, 리디렉션, 404 또는 410 중 목적에 맞는 선택을 문서화합니다. 대체 페이지가 실제로 같은 과업을 해결할 때만 리디렉션하고 모든 삭제 주소를 홈으로 보내지 않습니다. 통합한다면 고유한 조건과 근거를 대표 글에 먼저 옮기고 내부링크·사이트맵을 갱신한 뒤 이전 주소를 처리합니다. 삭제 직전과 처리 후 응답, canonical, 링크를 확인해 원본과 신호를 동시에 잃는 실수를 막습니다.

색인되어 있다면 검색 의도와 수요를 진단합니다

페이지가 색인되어도 검색 수요가 끝나거나 더 적합한 결과가 등장하면 방문자는 줄 수 있습니다. 쿼리를 직접 검토해 현재 결과가 공식 신청 페이지, 쇼핑, 지도, 동영상, 최신 뉴스 중심으로 바뀌었는지 봅니다. 자신의 글이 제공하는 답과 결과 화면이 요구하는 답이 달라졌다면 글자 수 추가가 아니라 의도 재설계가 필요합니다.

경쟁 문서를 베끼지 말고 누락된 판단 요소를 찾습니다. 공식 출처의 적용일, 대상과 제외 조건, 실제 메뉴 위치, 실패했을 때의 다음 경로처럼 독자의 작업 시간을 줄이는 정보가 있는지 비교합니다. Google은 사람을 위한 유용하고 신뢰할 수 있는 콘텐츠 제작을 권장합니다. 자세한 자기 점검 질문은 유용하고 신뢰할 수 있는 콘텐츠 만들기에서 확인할 수 있습니다.

관찰 결과별로 수정·유지·통합·삭제를 결정합니다

접속·차단 오류가 확인되면 기술 복구를 먼저 합니다

핵심 페이지가 noindex, robots 차단, 잘못된 리디렉션, 5xx 때문에 접근되지 않았다면 본문을 고치지 말고 설정을 바로잡습니다. 복구 후 실제 URL 테스트와 내부링크, 사이트맵을 확인합니다. 원인이 명확하므로 변경 내용과 시간을 남기고 크롤링이 다시 일어날 시간을 둡니다.

기술 롤백은 기억에 의존해 설정을 되돌리는 일이 아닙니다. 배포 ID나 테마·플러그인 버전, 변경 파일, CDN·캐시 갱신 시각, robots·헤더·리디렉션의 전후 값을 변경표에 남기고 복원 가능한 이전 버전을 확보합니다. 장애 범위가 새 배포를 받은 코호트와 일치하고 이전 버전에서 재현되지 않을 때, 콘텐츠 원고는 건드리지 않은 채 원인 후보인 설정만 되돌립니다. 롤백 뒤에는 브라우저에서 열리는지만 보지 말고 200 응답, 최종 URL, 렌더링된 핵심 본문, noindex와 X-Robots-Tag 부재, 선언 canonical, 내부링크와 사이트맵을 다시 확인합니다. 문제가 사라지지 않으면 무작정 재배포를 반복하지 말고 원래 상태로 복귀한 뒤 다음 가설을 별도 변경으로 시험합니다.

색인은 정상이고 일부 쿼리만 하락하면 해당 의도를 보강합니다

제목과 첫 문단이 현재 질문에 답하는지, 오래된 날짜·조건이 남았는지, 공식 근거가 가까이 있는지 고칩니다. 한 번에 여러 변수와 수십 페이지를 바꾸지 말고 대표 URL 몇 개에서 가설별로 수정합니다. 수정했다고 특정 기간 안에 순위가 돌아온다고 보장할 수는 없습니다.

유사 URL끼리 경쟁하면 대표 문서 중심으로 통합합니다

지역명이나 연도만 다르고 실질 정보가 같은 페이지가 많다면 각각을 억지로 늘리지 않습니다. 유효한 트래픽·링크·고유 정보가 있는 URL을 검토해 대표 문서에 통합하고, 폐기 URL은 상황에 맞는 리디렉션 또는 제거를 선택합니다. 서로 다른 의도가 있다면 각 문서에 독립적인 조건과 행동 경로를 제공해 분리합니다.

기간이 끝난 글은 즉시 삭제하지 말고 상태를 바꿉니다

종료된 행사나 지원금은 “현재 신청 가능”처럼 오해시키는 문장을 제거하고 마감 사실, 다음 공고 확인 경로, 과거 자료의 적용 범위를 명시합니다. 향후 동일 URL에서 업데이트할 가치가 있으면 보존하고, 다시 쓸 가능성도 없고 독자 가치도 없는 페이지라면 내부링크와 유입을 확인한 뒤 제거를 검토합니다.

설명을 위한 가상 사례: 40개 글 가운데 12개가 급락한 경우

아래 수치는 실제 운영 결과가 아니라 진단 분기를 보여 주기 위한 가상 사례입니다. 한 사이트의 지원금 글 40개 중 12개의 클릭이 같은 주에 크게 줄었습니다. 운영자는 사이트 전체 저품질로 단정하지 않고 감소 URL과 쿼리를 내보냈습니다. 확인 결과 8개는 접수 기간이 끝난 지역 공고였고, 3개는 지자체명만 다른 유사 본문이었으며, 1개는 테마 변경 뒤 canonical이 카테고리 주소를 가리키고 있었습니다.

이 상황에서 40개를 모두 재작성하면 원인이 섞입니다. canonical 오류 한 건은 기술적으로 복구하고, 종료 글은 마감 상태와 다음 공식 확인 경로를 추가합니다. 유사한 세 글은 지역별로 실제 조건이 없다면 공통 안내로 통합합니다. 나머지 정상 글은 손대지 않고 비교 기준으로 둡니다. 이렇게 해야 무엇이 회복과 관련 있었는지 해석할 수 있습니다.

알고리즘 업데이트가 의심될 때의 운영 원칙

Google Search Status Dashboard와 Search Central의 공식 공지를 확인해 실제 업데이트나 장애가 발표되었는지 봅니다. 공식 대시보드는 Google Search Status Dashboard에서 확인할 수 있습니다. 공지가 있어도 내 사이트 하락이 반드시 그 업데이트 때문이라고 확정할 수는 없습니다.

핵심 업데이트가 진행 중이라면 하루 단위 등락으로 결론을 내리지 않습니다. 공식적으로 전개가 끝났는지 확인한 뒤에도 데이터가 안정될 시간을 두고, 전후의 같은 길이 구간을 페이지·검색어·검색 유형별로 비교합니다. 업데이트는 특정 사이트에 보낸 수동 처벌 통지가 아니라 웹 전반의 상대적 재평가일 수 있으므로, 하락 URL만 보지 말고 유지·상승 URL에서 어떤 답과 근거가 계속 선택됐는지도 대조합니다.

초기 변동 중에는 제목 전체 교체, 카테고리 삭제, 도메인 이전을 동시에 하지 않습니다. 유지된 페이지와 하락한 페이지의 차이를 비교하고, 얇은 요약·오래된 정보·출처 부재·의도 불일치 같은 사이트 내부의 개선점을 찾습니다. 알고리즘을 속이는 형식보다 독자가 과업을 끝내는 데 필요한 사실과 절차를 보강하는 편이 장기적으로 검증 가능한 대응입니다.

오늘 실행할 복구 순서

Search Console 실적에서 하락 전후를 같은 기간으로 비교해 영향 페이지와 쿼리를 저장합니다.
페이지 색인 생성 보고서와 URL 검사에서 대표 피해 URL의 제외 사유·canonical·크롤링 상태를 확인합니다.
모바일 브라우저에서 접속, 리디렉션, 본문, noindex, 최근 배포 문제를 재현합니다.
기술 문제, 시즌 종료, 중복, 의도 변화, 원인 불명으로 URL을 분류합니다.
원인이 명확한 소수 페이지부터 수정하고 변경일·수정 항목을 기록합니다.
수정하지 않은 비교 페이지를 남긴 채 충분한 재크롤링과 데이터 누적 뒤 같은 보고서로 판단합니다.

삭제는 진단의 첫 단계가 아니라 마지막 선택지입니다. “저품질 탈출 비법”을 찾기 전에 검색 시스템이 페이지를 발견하고 읽을 수 있는지, 대표 URL을 제대로 이해하는지, 현재 질문에 가장 유용한 답을 주는지 차례대로 확인하십시오. 이 순서를 지키면 하락을 모두 복구할 수 있다고 약속할 수는 없지만, 적어도 회복 단서를 스스로 지우는 공포 수정은 피할 수 있습니다.

공부스닷컴