색인 오류 해결: Blogger 라벨 URL 불일치 복구 기록

Blogger에서 특정 라벨을 눌렀을 때 글이 있는데도 목록이 비어 보인다면, 먼저 글 품질보다 메뉴 URL과 실제 라벨 매칭을 확인해야 한다. 이번 문제는 “AI 파헤치기” 색인 항목이 정상 글목록으로 이어지지 않았고, 최종적으로 깨진 라벨 아카이브 대신 작동이 확인된 /search 경로로 복구했다.

문제 상황
에러 증상
환경
시도했지만 실패한 방법
오류가 난 원인
최종 해결
사용한 코드
검증 결과
같은 문제 겪는 분들에게
관련 ToolSignal 기록

문제 상황

ToolSignal Pro는 현재 한국어 중심의 AI 코딩, 자동화, Blogger 오류 해결 기록을 쌓는 사이트로 운영 중이다. 문제는 사이트의 색인 또는 네비게이션에서 AI 파헤치기 항목을 눌렀을 때 발생했다. 홈이나 검색 목록에는 글이 존재하는데, 해당 색인 항목을 통해 들어가면 글 목록이 비어 보이거나 잘못된 fallback 페이지로 이동했다.

이 문제는 게시글 본문이 부족하거나 검색엔진이 색인을 거부한 문제가 아니었다. 사용자가 직접 클릭하는 메뉴 경로가 Blogger의 라벨 아카이브 동작과 안정적으로 맞지 않은 것이 핵심이었다. 따라서 해결 방향도 콘텐츠 재작성보다 테마 네비게이션과 URL 라우팅을 먼저 점검하는 쪽이 맞았다.

에러 증상

겉으로 보이는 메뉴명은 AI 파헤치기였다. 그러나 실제 링크는 특정 시점에서 /search/label/인공지능 또는 URL 인코딩된 /search/label/AI%20%ED%8C%8C%ED%97%A4%EC%B9%98%EA%B8%B0 계열로 연결되었다. 사용자는 같은 메뉴를 누른다고 생각하지만, Blogger는 표시 글자가 아니라 href에 들어간 라벨 경로를 기준으로 글을 찾는다.

/search/label/인공지능
/search/label/AI 파헤치기
/search/label/AI%20%ED%8C%8C%ED%97%A4%EC%B9%98%EA%B8%B0
/p/archive.html

반대로 실제로 글 목록이 출력되는 안전한 목적지는 다음 경로였다.

/search

환경

운영 환경: Google Blogger 기반 ToolSignal Pro
현재 언어 운영 기준: 한국어 중심
문제가 발생한 UI: 상단 또는 색인 영역의 AI 파헤치기 네비게이션
문제가 발생한 영역: Blogger 라벨 아카이브 URL과 테마 메뉴 href
확인된 정상 목적지: /search

여기서 중요한 구분은 화면에 보이는 메뉴 텍스트, 실제 href, URL 인코딩된 라벨명, Blogger 글 관리자에 붙어 있는 실제 라벨명이 모두 다르다는 점이다. 메뉴에 “AI 파헤치기”라고 보이더라도 href가 인공지능 라벨을 가리키면 Blogger는 “AI 파헤치기” 글이 아니라 “인공지능” 라벨 글을 찾는다.

시도했지만 실패한 방법

처음에는 테마 XML 안에서 /search/label/인공지능으로 연결된 항목을 /search/label/AI%20%ED%8C%8C%ED%97%A4%EC%B9%98%EA%B8%B0로 바꾸는 방식이 자연스러워 보였다. 표시명과 라벨명을 맞추는 접근이기 때문이다.

그러나 이 방식은 항상 충분하지 않다. Blogger의 LinkList 위젯이나 메뉴 위젯은 테마 XML을 업로드해도 기존 설정값을 보존할 수 있다. 이 경우 XML 파일에는 수정된 href가 들어 있어도, 실제 라이브 메뉴는 Blogger 관리자에 저장된 기존 링크를 계속 사용할 수 있다. 그래서 단순한 문자열 교체만으로는 사용자가 보는 클릭 경로까지 반드시 바뀐다고 단정할 수 없다.

또 다른 실패 지점은 /p/archive.html fallback이었다. fallback은 반드시 실제 존재하는 URL이어야 한다. 존재하지 않는 페이지로 보내면 빈 라벨 페이지보다 상황이 나빠진다. 원래는 글목록이 비어 보이는 문제였는데, 잘못된 fallback이 붙으면 사용자는 실제 404에 가까운 깨진 페이지를 보게 된다.

오류가 난 원인

이번 문제의 핵심은 보이는 메뉴명, 실제 href, Blogger 라벨 아카이브, 위젯 저장값이 한 번에 맞지 않았다는 점이다. “AI 파헤치기”라는 이름은 사이트의 현재 주제와 맞았지만, 실제 이동 경로는 다른 라벨명 또는 깨진 fallback으로 이어질 수 있었다.

/search/label/... 경로는 Blogger에서 라벨별 글 목록을 보여주는 정상적인 형식이다. 하지만 실무에서는 라벨 문자열이 조금만 달라도 결과가 달라진다. 예를 들어 인공지능과 AI 파헤치기는 운영자가 보기에는 같은 분류처럼 느껴질 수 있지만, Blogger에는 서로 다른 라벨이다.

한글과 공백이 포함된 라벨은 URL 인코딩 형태로 표시된다. 인코딩 자체가 문제는 아니지만, 사람이 테마 XML을 점검할 때 실제 라벨명과 인코딩된 경로를 헷갈리기 쉽다. 여기에 위젯 저장값 보존까지 겹치면 “파일은 고쳤는데 사이트는 그대로인” 상태가 생긴다.

최종 해결

최종 해결은 완벽한 라벨 체계 복원이 아니라, 사용자가 빈 페이지를 보지 않도록 하는 실무적 복구였다. 작동이 확인된 전체 검색 목록 /search를 AI 파헤치기 네비게이션의 목적지로 사용했다.

수정 전:
AI 파헤치기 → /search/label/인공지능
AI 파헤치기 → /search/label/AI%20%ED%8C%8C%ED%97%A4%EC%B9%98%EA%B8%B0
fallback → /p/archive.html

수정 후:
AI 파헤치기 → /search

이 방식은 특정 라벨만 정확히 필터링하는 정교한 해결은 아니다. 하지만 글목록이 정상적으로 출력되는 경로를 사용하므로, 방문자에게 빈 화면이나 404를 보여주는 문제를 먼저 차단할 수 있다. 운영 중인 사이트에서는 이 순서가 더 안전할 때가 있다.

사용한 코드

아래 코드는 이미 잘못된 경로로 들어온 사용자를 /search로 보내는 방어 예시다. 다만 이 코드는 임시 보호 장치에 가깝다. 가장 좋은 해결은 메뉴 링크와 실제 라벨을 먼저 정리하는 것이다.

<script>
(function () {
  var path = decodeURIComponent(window.location.pathname);
  var badPaths = [
    "/search/label/인공지능",
    "/search/label/AI 파헤치기",
    "/p/archive.html"
  ];

  if (badPaths.indexOf(path) !== -1) {
    window.location.replace("/search");
  }
})();
</script>

리다이렉트 코드를 사용할 때도 모든 /search 트래픽을 무조건 돌리면 안 된다. 검색 페이지 자체가 정상 동작하는 경로이므로, 특정 잘못된 경로만 좁게 지정해야 한다.

검증 결과

상단 또는 색인 메뉴에서 AI 파헤치기를 클릭한다.
주소창이 존재하지 않는 /p/archive.html로 가지 않는지 확인한다.
/search/label/인공지능 같은 이전 라벨 경로가 메뉴 href에 남아 있지 않은지 확인한다.
/search에서 글 목록이 실제로 출력되는지 확인한다.
모바일 메뉴에서도 동일한 경로로 이동하는지 확인한다.

최종적으로 AI 파헤치기 색인 항목은 빈 라벨 아카이브나 존재하지 않는 fallback으로 가지 않고, 정상 글목록이 출력되는 /search로 이동하도록 정리했다.

같은 문제 겪는 분들에게

메뉴에 보이는 이름과 실제 href를 분리해서 확인한다.
한글 라벨은 인코딩된 URL과 원문 라벨을 함께 대조한다.
테마 XML 수정 후에도 Blogger 위젯 설정이 기존 링크를 유지할 수 있음을 감안한다.
fallback은 반드시 실제 존재하고 글목록을 보여주는 URL로만 지정한다.
리다이렉트 스크립트는 임시 방어 수단으로만 사용한다.

이번 수정은 완벽한 라벨 taxonomy 복구가 아니라, 방문자에게 깨진 페이지를 보여주지 않기 위한 실무적 복구다. 진짜 라벨 전용 복구를 하려면 Blogger 글 관리자에서 실제 글에 붙은 라벨명을 확인해야 한다. 글 라벨이 AI 파헤치기인지, 인공지능인지, 또는 둘이 섞여 있는지 확인한 뒤 하나로 통일해야 한다.

같은 아카이브의 다른 운영 기록입니다. 지금 겪는 문제와 가까운 기록을 골라 보세요.