상세문의 아이콘 상세문의
간편문의 아이콘 × 간편문의
DEBUGGING LOG · 2026.09

리디렉션 규칙 한 줄이
발행글을 가렸습니다

주소가 틀린 것도, 글이 지워진 것도 아니었습니다.
발행 189일 전에 만들어 둔 규칙 하나가 이름이 비슷한 주소까지 끌어가고 있었습니다.

넥스트티 대표 홍은표 · 자체 사이트 실측 기록

DEFINITION · 한 문장 정의

부분 일치 리디렉션은 주소를 통째로 맞춰 보지 않고 일부만 들어 있어도 맞다고 보는 방식입니다. 짧은 규칙 하나가 그 글자로 시작하는 다른 주소까지 함께 끌고 갑니다.

1분 요약 · KEY TAKEAWAYS

  • 보존된 로그 11일 구간에서 그 글의 정상 응답은 0건이고, Googlebot도 8회 모두 301을 받아 갔습니다. 규칙이 발행보다 먼저 있었으므로 발행 시점부터 54일 내내 같은 상태였다고 봅니다. 다만 로그로 확인한 것은 11일입니다.
  • 원인은 규칙을 패턴으로 볼지 평문으로 볼지 가르는 조건 하나였습니다. 짧은 경로 하나가 그 글자로 시작하는 글까지 함께 이동시켰습니다.
  • 같은 상태인 규칙이 33개 중 12개였습니다. 같은 조건에 걸린 규칙이 12개였습니다.
  • 구글이 알려준 게 아닙니다. 사이트맵에 올린 주소를 전부 요청해 응답 코드를 세다가 잡았습니다.
  • 같은 점검에서 사이트맵 301 5건, 내부 링크 301 19건이 함께 나왔습니다.

THE INCIDENT

글은 있는데 아무도 볼 수 없었습니다

글을 쓰고, 검수하고, 발행했습니다. 목록에도 보이고 관리 화면에도 있습니다. 그런데 그 주소를 직접 열면 다른 페이지가 뜹니다.

화면만 보면 이상한 걸 못 느낍니다. 멀쩡한 페이지가 떠 있으니까요. 응답 코드를 봐야 보입니다.

WIREFRAME · 규칙이 만들어진 순서

1월 · 규칙을 만들다짧은 경로 한 개 → 다른 섹션으로 301
옛 주소를 정리하려고 넣은 평범한 규칙
▼  189일 뒤
7월 · 글을 발행하다주소가 같은 글자로 시작
규칙과는 아무 상관 없는 새 글
▼  규칙이 먼저 잡는다
규칙이 먼저 있었으므로 발행 첫날부터 막혀 있었다고 봅니다 — 로그로 확인한 구간은 11일입니다

규칙이 글보다 189일 먼저 있었습니다. 그래서 「어느 날부터 안 되기 시작했다」가 아니라 발행 첫날부터 막혀 있었다고 봅니다.

다만 이건 규칙이 먼저 있었다는 사실에서 나온 판단입니다. 로그로 직접 확인한 구간은 11일이고, 그 사이 배포나 설정이 바뀌었는지까지 대조하지는 않았습니다.

FIELD LOG · 서버 접근 기록

로그에 그대로 남아 있었습니다

서버가 보관하는 접근 기록을 날짜별로 세어 봤습니다. 보관 기간이 지나 그 이전은 남아 있지 않지만, 남아 있는 11일 동안 정상 응답이 한 건도 없습니다. 이 구간에 Googlebot 요청이 8건 있었고 전부 301이었습니다.

WIREFRAME · 날짜별 응답 코드

9월 06일301██
9월 07일301████
9월 08~15일301████████████
9월 16일301████
━━━━━ 9월 17일 · 규칙을 고침 ━━━━━
9월 17일200████████████████████████
11일 동안 200이 0건 · 고친 당일부터 정상 응답

※ 막대 길이는 해당 날짜의 요청 건수를 나타냅니다. 9월 6일 이전 기록은 보관 기간이 지나 확인할 수 없습니다. 다만 규칙이 글보다 189일 먼저 만들어져 있었다는 사실은 남아 있습니다.

ROOT CAUSE

규칙을 어떻게 읽을지 가르는 조건 하나

리디렉션 규칙은 두 종류로 쓸 수 있습니다. 주소를 통째로 맞춰 보는 평문과, 모양을 맞춰 보는 패턴입니다. 둘은 다루는 방식이 달라서, 규칙을 읽을 때 어느 쪽인지 먼저 갈라야 합니다.

저희는 그 판정을 맨 앞 글자로 하고 있었습니다. 그런데 갈림 조건 안에 슬래시가 들어 있었습니다. 주소는 원래 슬래시로 시작합니다. 그래서 모든 평문 경로가 패턴으로 분류됐습니다.

WIREFRAME · 같은 규칙, 두 가지 해석

의도한 해석 · 평문주소가 정확히 같을 때만
→ 그 주소 하나만 이동
실제 해석 · 패턴그 글자가 들어 있기만 하면
→ 비슷한 주소 전부 이동
▼  그 결과
규칙이 노린 주소/옛경로
+ 덤으로 딸려온 것
아무 상관 없는 발행글/블로그/…/옛경로-로-시작하는-제목
글자가 들어 있다는 이유만으로
규칙은 33개인데, 같은 상태인 것이 12개였습니다

한 건으로 끝날 문제가 아니었습니다. 평문으로 적은 경로 12개가 전부 부분 일치로 돌고 있었습니다. 나머지가 아직 문제가 드러나지 않은 건 우연히 겹치는 주소가 없었기 때문입니다.

고치는 방법은 간단했습니다. 패턴으로 볼 조건을 좁히면 됩니다. 진짜 패턴은 모양을 나타내는 기호로 시작하거나 그런 기호를 품고 있습니다. 그것만 패턴으로 보고 나머지는 평문으로 되돌렸습니다.

CODE · 무엇이 달라졌나

# 문제 — 맨 앞 글자로 갈랐는데 그 안에 슬래시가 있었다
isPattern = /^[#\/^]/.test(rule)
  모든 경로가 / 로 시작하므로 "/aeo" 도 패턴이 된다
  → /blog/geo/aeo-... 까지 함께 걸린다

# 수정 — 우리 규칙 형식에 맞춰 패턴 분류 조건을 좁힌다
isPattern = /^[#^]/.test(rule) || /[()\[\]*+?{}|\\]/.test(rule)
  "/aeo" 는 평문 → 주소가 정확히 같을 때만 이동

# 패턴을 꼭 써야 한다면 앞뒤를 고정한다
/aeo/       경로 어디에 있어도 걸림
/^\/aeo$/  그 주소 하나만

# 점검 — 리디렉션을 따라가지 말고 첫 응답만 본다
curl -o /dev/null -sw "%{http_code} %{redirect_url}\n" \
     "https://example.com/some/post/"
  301·302·307·308 이면 Location 의 이동 목적지를 확인한다
  404·500 도 200 이 아니지만 리디렉션은 아니다 — 응답 코드로 갈라 본다

※ 실제 코드가 아니라 판정 방식을 옮긴 예시입니다. 저희가 쓰는 표현은 다르지만, 갈림 조건에 슬래시가 들어가 있었다는 점은 같습니다.

🟢 공식 문서 · 리디렉션은 검색엔진에 주소 변경을 알리는 신호이며, 잘못 걸면 의도하지 않은 페이지까지 영향을 받습니다 — Google Search Central, Redirects and Google Search

🟠 자체 관측 · 위 숫자는 저희 사이트 한 곳의 기록입니다. 다른 사이트에서 같은 비율이 나온다는 뜻은 아닙니다.

BLAST RADIUS

한 글만의 일이 아니었습니다

글 하나를 되살리려고 시작한 점검이었는데, 같은 방법으로 점검하니 다른 종류의 어긋난 곳이 함께 나왔습니다.

WIREFRAME · 같은 점검에서 나온 것

사이트맵올린 주소 중 301  5건
색인해 달라고 내민 목록에 다른 데로 넘어가는 주소가 섞임
내부 링크주요 페이지 링크 중 301  19건
목록 카드가 전부 한 형태로 잘못 걸려 있었음
사이트맵 중복같은 페이지가 두 형태로  2건
슬래시 유무만 다른 주소가 한 목록에 함께
▼  공통점
셋 다 사람 눈에는 정상으로 보입니다. 화면은 멀쩡히 뜨니까요

내부 링크가 301을 거치면 한 번에 갈 길을 두 번에 갑니다. 저희 규모에서 19건이 크롤 총량에 큰 영향을 준다고 보기는 어렵습니다 — 구글도 크롤 예산은 대형 사이트의 문제라고 설명합니다. 이번 19건에서 신호가 실제로 갈렸는지는 따로 확인하지 않았습니다. 확실한 손해는 불필요한 이동과 내부 주소 표기의 불일치입니다. 관리 위생의 문제로 보는 편이 맞습니다. 그 구조는 앞선 기록인 canonical과 트레일링 슬래시 실록에 정리해 두었습니다.

사이트맵은 색인해 달라고 내미는 목록입니다. 거기에 다른 곳으로 넘어가는 주소가 들어 있으면, 검색엔진은 그 주소를 색인 대상에서 빼고 넘어간 곳을 봅니다. 목록과 실제가 어긋나는 셈입니다.

HOW WE FOUND IT

어떻게 찾았나 — 목록을 전부 요청해 본다

구글이 알려준 게 아닙니다. 사이트맵에 올린 주소를 하나씩 전부 요청해 응답 코드를 세다가 확인됐습니다. 사람이 페이지를 하나씩 여는 방식으로는 놓치기 쉽습니다. 최종 화면만 보면 멀쩡해 보이기 때문입니다. 주소창이나 내용이 달라진 것을 알아채면 찾을 수도 있습니다.

WIREFRAME · 점검 파이프라인

1단계사이트맵의 주소를 전부 뽑는다
2단계하나씩 요청해 응답 코드만 센다
화면은 안 본다 · 리디렉션을 따라가지 않는다
3단계200이 아닌 것을 추린다
사이트맵에는 바로 열리는 주소만 있어야 한다
4단계내부 링크에도 같은 방법을 쓴다
주요 페이지의 링크를 모아 같은 절차로
사람이 못 보는 종류를 기계가 한 번에 찾아냅니다

핵심은 리디렉션을 따라가지 않는 것입니다. 따라가면 최종 결과가 200이라 정상으로 보입니다. 첫 응답만 봐야 중간에 끼어든 이동이 드러납니다.

저희는 이 절차를 스크립트로 만들어 발행할 때마다 실행합니다. 사람이 틀려도 스크립트가 먼저 잡게 하려는 것입니다.

덧붙이자면 이 점검에서 나온 것은 두 가지 다른 사고였습니다. 글이 열리지 않은 것은 규칙을 읽는 조건의 문제였고, 내부 링크 19건이 301을 타고 있던 것은 사람이 손으로 주소를 쓰면서 형태를 맞추지 않은 문제였습니다. 원인이 다르니 막는 방법도 다릅니다 — 앞은 조건을 좁혀서, 뒤는 기계가 검사하게 해서 막습니다.

HOW WE DEBUG · 넥스트티 방식

넥스트티는 “떴는지”가 아니라 “무엇으로 응답했는지”를 봅니다

화면이 뜨는 것과 그 주소가 살아 있는 것은 다릅니다. 발행 후 54일이 지나 문제를 발견했습니다. 그 주소를 열면 다른 페이지가 대신 떴습니다.

그래서 저희는 점검할 때 눈으로 보는 대신 응답 코드를 셉니다. 그리고 고친 뒤에는 검색 크롤러가 실제로 어떤 응답을 받아 갔는지 서버 기록으로 확인합니다. 순위가 올랐는지는 저희가 정하지 못하지만, 크롤러가 정상 응답을 받아 갔다는 사실은 기록으로 남습니다.

보장과 관측은 다릅니다. 저희가 드리는 리포트에 무엇을 언제 어떻게 측정했는지가 함께 들어가는 이유입니다. 그 경계는 측정의 경계에 적어 두었습니다.

5 RULES · 재현 가능한 원칙

같은 실수를 막는 5가지

원칙 1한 주소를 옮기는 규칙은 정확 일치로 쓴다
일부만 맞아도 되는 방식은 짧은 규칙일수록 위험하다. 여러 주소를 한꺼번에 옮길 때만 패턴을 쓰고, 그때는 앞뒤를 고정한다
원칙 2규칙을 넣기 전에 그 문자열이 들어간 주소를 전부 센다
앞이 아니라 경로 중간에 들어가도 걸린다. 길게 쓰는 것으로는 안 풀리고, 통째로 맞추는 방식으로 바꿔야 한다
원칙 3사이트맵에는 바로 열리는 주소만 넣는다
301로 넘어가는 주소는 목록에서 뺀다
원칙 4내부 링크도 최종 주소로 건다
한 번에 갈 길을 두 번에 가게 만들지 않는다
원칙 5사람이 손으로 쓴 주소는 기계가 검사한다
발행할 때마다 목록 전체에 요청을 보내는 절차를 둔다

COMMON MYTHS · 자주 보는 오해

리디렉션에 대해 자주 듣는 세 가지 오해

MYTH 01

“화면이 뜨면 정상이다”

이번 글은 발행 후 54일이 지나 문제를 발견했습니다. 그 주소를 열면 다른 페이지가 대신 떴습니다. 최종 화면만 보면 놓치기 쉽습니다 — 응답 코드를 봐야 합니다.

MYTH 02

“301은 안전한 이동이니 몇 개 있어도 된다”

이동 자체는 안전합니다. 문제는 어디에 있느냐입니다. 사이트맵과 내부 링크에 들어 있으면 색인해 달라고 내민 목록이 스스로 어긋나 있는 셈입니다.

MYTH 03

“문제가 생기면 검색엔진이 알려준다”

정확히 말하면 경고 메일은 오지 않았고, 우리가 보고서를 들여다보지 않았습니다. Search Console의 페이지 색인 보고서에는 「리디렉션이 포함된 페이지」 항목이 있습니다. 거기에 들어가 있었을 가능성이 큽니다. 알림이 와서 아는 종류가 아니라, 찾아 들어가야 보이는 종류입니다.

FAQ

자주 묻는 질문

리디렉션 규칙이 엉뚱한 주소까지 바꾸는 일이 흔한가요?+
규칙을 어떻게 해석하느냐에 달려 있습니다. 주소를 통째로 맞춰 보는 방식이면 이런 일이 생기지 않습니다. 그런데 주소의 일부만 들어 있어도 맞다고 보는 방식이라면, 짧은 규칙 하나가 이름이 비슷한 주소를 모두 끌고 갑니다. 저희 경우 짧은 경로 하나가 그 글자로 시작하는 다른 글까지 함께 이동시켰습니다.
글이 안 열리는데 사이트는 멀쩡해 보입니다. 어디부터 봐야 하나요?+
주소를 직접 요청해 응답 코드를 먼저 보십시오. 화면만 보면 다른 페이지가 대신 떠서 정상처럼 보일 수 있습니다. 301·302·307·308이 온다면 어딘가에서 주소를 바꾸고 있다는 뜻이고(404나 500이면 다른 문제입니다), 그다음은 어느 규칙이 그 주소에 걸렸는지 찾는 순서입니다.
사이트맵에 301되는 주소가 들어 있으면 문제인가요?+
사이트맵은 색인해 달라고 내미는 목록입니다. 거기에 다른 곳으로 넘어가는 주소가 들어 있으면, 검색엔진은 그 주소를 색인 대상에서 빼고 넘어간 곳을 봅니다. 목록과 실제가 어긋나는 셈이라, 사이트맵에는 바로 열리는 주소만 넣는 편이 좋습니다.
내부 링크가 301을 거치면 무엇이 손해인가요?+
한 번에 갈 길을 두 번에 가게 됩니다. 크롤 총량 자체는 대형 사이트가 아니면 큰 영향을 받지 않습니다. 확실한 손해는 불필요한 이동과, 사이트 안에서 같은 글을 두 형태로 적게 된다는 점입니다. 저희는 이번 19건에서 신호가 실제로 갈렸는지까지는 확인하지 않았습니다. 사람 눈에는 똑같이 보이기 때문에 오래 방치되기 쉽습니다.
이런 문제를 미리 잡으려면 무엇을 봐야 하나요?+
사이트맵에 올린 주소를 전부 요청해 응답 코드를 세어 보는 것이 가장 빠릅니다. 200이 아닌 것이 하나라도 있으면 목록과 실제가 어긋난 것입니다. 내부 링크도 같은 방식으로 점검할 수 있습니다. 사람이 페이지를 하나씩 여는 방식으로는 놓치기 쉽습니다 — 최종 화면이 멀쩡해 보이기 때문입니다.
규칙을 고치면 빠졌던 글이 바로 돌아오나요?+
주소가 다시 열리는 것은 즉시입니다. 다만 검색 결과에 다시 나타나는 시점은 저희가 정하지 못합니다. 저희가 확인한 것은 고친 날부터 크롤러가 그 주소에서 정상 응답을 받아 갔다는 사실까지이고, 그 뒤 순위나 유입이 어떻게 되는지는 단정하지 않습니다.

CONCLUSION

고친 것은 조건 하나, 배운 것은 절차

글을 되살린 건 조건 하나를 좁힌 일이었습니다. 하지만 이 사고가 남긴 건 사람이 손으로 쓴 주소를 기계가 검사하게 만든 절차입니다. 규칙은 만들어진 뒤 243일 동안 조용히 있었고, 경고 메일은 오지 않았습니다.

화면이 뜬다고 살아 있는 게 아닙니다. 무엇으로 응답했는지를 봐야 합니다 — 그게 이 글이 말하려던 전부입니다.

덧붙이자면, 이 글의 주소도 목록 전체에 요청을 보내는 그 절차를 통과했습니다(/seo/redirect-rule-trap). 우리가 정한 규칙을 이 페이지부터 지킵니다.

DIAGNOSE · URL HEALTH

우리 사이트의 목록과 실제는 맞아떨어지는가

넥스트티는 페이지가 ‘떴는지’로 판단하지 않습니다 — 사이트맵에 올린 주소가 바로 열리는지, 내부 링크가 최종 주소로 걸려 있는지까지 응답 코드로 확인합니다.
사이트맵 전수 점검 · 내부 링크 감사 · 리디렉션 규칙 검토부터 시작합니다.