한 마켓플레이스의 SEO 팀은 "매물 3개 미만 = noindex"라는 단순한 정책 때문에 카테고리 페이지가 Google에서 사라지고 다시 나타나기까지 몇 주가 걸리는 현상이 발생하자 인덱싱 규칙을 재작성했습니다. 페이지가 noindex에서 index로 이동할 수는 있지만 다시 돌아갈 수는 없는 단방향 "언락(unlock)" 레코드를 추가함으로써, 사이트의 깜빡임 현상을 멈췄습니다.

기존 규칙이 역효과를 낸 이유

이 분류 광고 플랫폼은 수많은 카테고리 및 지역 페이지를 생성합니다. 페이지가 처음 생성될 때는 매물이 몇 개 없는 경우가 많기 때문에, 팀은 매물이 최소 임계값인 3개에 도달할 때까지 검색 결과에서 숨기기로 결정했습니다. 논리는 간단했습니다:

  • 매물 < 3개 → noindex 메타 태그 추가
  • 매물 ≥ 3개 → 태그 제거 (인덱싱 허용)

초기에는 이 방식 덕분에 가치가 낮은 빈약한(thin) 페이지들이 Google 검색 결과에 노출되지 않았습니다. 문제는 매물의 만료 기간이 지나면서 발생했습니다. 어느 날 매물이 5개였던 페이지가 다음 날 2개로 줄어들면 즉시 noindex로 전환되었습니다. Google은 이를 따랐고, 인덱스에서 해당 URL을 제거했으며, 이로 인해 페이지가 쌓아온 모든 순위가 사라졌습니다. 새로운 매물이 들어오면 페이지는 다시 인덱싱이 가능해지지만, 다시 검색 결과에 진입하는 데는 몇 주가 걸렸습니다.

그 결과, 페이지가 인덱스에 들어갔다가 사라지고, 다시 들어오는 식의 끊임없는 "온-오프(on-off)" 사이클이 반복되었습니다.

단방향 "언락(unlock)" 해결책

핵심적인 결함은 규칙에 '기억'이 없었다는 점이었습니다. 매 요청마다 임계값을 다시 계산했습니다. 팀은 페이지가 처음으로 매물 3개 기준에 도달했을 때를 기록하는 seo_unlocks라는 작은 데이터베이스 테이블을 도입했습니다. 새로운 워크플로우는 다음과 같습니다:

  1. 매물 수 확인. 페이지에 활성 매물이 3개 이상이면 진행합니다.
  2. 언락 행(row) 작성. seo_unlocks 테이블에 해당 페이지에 대한 레코드를 삽입합니다.
  3. 페이지를 영구적으로 인덱싱 가능하게 취급. 나중에 매물 수가 3개 미만으로 떨어지더라도, 언락 행이 존재하면 페이지가 noindex 흐름으로 들어가는 것을 방지합니다.

언락은 단 한 번만 작성될 수 있으므로, 페이지는 "noindex"에서 "index"로 이동할 수는 있지만 다시 돌아갈 수는 없습니다. 팀은 필터링된 URL(예: 가격 범위가 적용된 검색 결과)이 상위 카테고리에 대해 언락을 생성할 수 없도록 안전장치를 추가했으며, 데이터베이스 오류가 사이트 전체를 중단시키지 않도록 데이터베이스 호출을 try/catch 블록으로 감쌌습니다.

크롤링 예산(crawl budget)과 빈약한 페이지(thin pages)에 미치는 영향

흔한 오해 중 하나는 noindex가 크롤링 예산을 절약해 준다는 것입니다. Google은 여전히 페이지를 가져와서 태그를 읽은 다음 인덱스에서 제거해야 합니다. 만약 목표가 Google이 특정 URL 패턴 전체를 요청하지 못하게 하는 것이라면, 올바른 도구는 robots.txt입니다. noindex는 Google이 페이지를 확인하되 검색 결과에는 표시하지 않기를 원할 때만 사용하십시오.

대량의 자동 생성 페이지에 의존하는 디렉토리, 채용 게시판, 마켓플레이스의 경우 교훈은 명확합니다. 빈약한 페이지 규칙은 페이지가 인덱스에 진입할 자격을 얻었을 때를 기억하는 지속성 계층(persistence layer)과 결합되어야 합니다. 이러한 기억 장치가 없다면, 콘텐츠의 일시적인 감소로 인해 페이지가 쌓아온 순위를 잃을 수 있으며, 다시 진입하는 데 몇 주가 걸릴 수 있습니다.

요약

정적인 "매물 < 3이면 noindex" 규칙은 동적인 매물 사이트에서 SEO 변동성을 초래합니다. 단방향 언락 레코드를 추가하면 규칙에 기억력이 생겨, 매물 수가 변동되더라도 페이지가 인덱스 상태를 획득하고 유지할 수 있게 됩니다. 이를 진정한 크롤링 예산 절약을 위한 robots.txt의 적절한 사용과 결합하면, 순위와 서버 리소스를 모두 보호할 수 있습니다.