ecbeing 대규모 리뉴얼의 URL·리다이렉트 설계
ecbeing 대규모 리뉴얼의 URL·리다이렉트 설계
- Category
- Guides
- Reading Time
- 9분 분량
- Topic
- 일본 EC 플랫폼별 검색·AI 검색 가이드
ecbeing 같은 대규모 사이트의 리뉴얼에서는 수만 개의 URL이 한 번에 바뀌어요. 전체 URL을 개별로 리다이렉트하는 건 현실적이지 않아서, 규칙 기반 설계와 예외의 개별 대응을 조합해요. URL 전수 조사, 규칙 설계, 예외 추출, 전환 당일의 절...
searchos.io/ko/blog
© 2026 Search OS
ecbeing으로 만든 사이트를 기간 시스템 연동까지 포함해 리뉴얼하는 경우가 있습니다. 상품 3만 점, 카테고리 2천 개, 콘텐츠 5천 개의 URL이 전부 바뀝니다. 리다이렉트를 손으로 다 설정하기는 어렵기 때문에 설계 방식을 먼저 정해야 합니다.
규칙으로 대응하고, 규칙에서 벗어나는 것만 개별로 대응합니다. 3만 개 상품 URL이 "구 상품 ID에서 신 상품 ID로" 같은 규칙으로 변환된다면 리다이렉트는 규칙 하나로 끝납니다. 규칙에 맞지 않는 예외만 개별 대응표로 만듭니다. 통합된 상품, 삭제된 카테고리, URL이 특수한 콘텐츠가 여기에 들어갑니다. 이 설계를 리뉴얼 초기에 하지 않으면 전환 당일에 수만 개의 404가 쏟아집니다.
이 글에서는 URL 전수 조사부터 이전 후 모니터링까지 시간 순으로 정리합니다. 규칙 설계, 예외 추출, 전환 당일 절차도 차례로 다룹니다.
결론: 규칙으로 9할, 대응표로 1할. 전환 전에 스테이징에서 전체 URL을 검증한다
단계 | 시기 | 할 일 |
|---|---|---|
전수 조사 | 3개월 전 | 구 사이트의 전체 URL을 종류별로 목록화. 검색 유입·백링크를 부여 |
규칙 설계 | 2개월 전 | 종류별로 구 URL → 신 URL의 변환 규칙을 정의 |
예외 추출 | 1개월 전 | 규칙으로 변환할 수 없는 URL을 추출해 개별 대응표를 작성 |
검증 | 2주 전 | 스테이징에서 전체 URL의 리다이렉트를 기계적으로 검증 |
전환 | 당일 | 리다이렉트를 활성화. 주력 URL을 수동 확인 |
모니터링 | 전환 후 3개월 | 404, 리다이렉트 체인, 색인 수, 유입을 모니터링 |
Search OS 가이드 01
수만 URL의 리다이렉트 설계: 전환 전후 6단계
규칙으로 9할, 대응표로 1할. 전환 전에 스테이징에서 전 URL 검증
| 시점 | 단계 | 상세 내용 |
|---|---|---|
| 3개월 전 | 재고 조사 | 전 URL 목록 유입·백링크 부여 |
| 2개월 전 | 규칙 설계 | 구 URL→새 URL 변환 규칙 |
| 1개월 전 | 예외 추출 | 규칙 밖 URL의 대응표 |
| 2주 전 | 검증 | 스테이징에서 전 URL 기계 검증 |
| 당일 | 전환 | 301 활성화 주력 URL 수동 확인 |
| +3개월 | 감시 | 404·체인 색인 수·유입 |
- POINT
- 검증하지 않은 리다이렉트는 없는 것과 같다
© 2026 Search OS
중요한 관점: 수만 URL을 옮길 때 손으로 확인하는 것은 주력 수십 개 URL뿐입니다. 나머지는 규칙과 기계적 검증으로 담보합니다. 검증하지 않은 리다이렉트는 없는 것과 같습니다.
전수 조사: 구 사이트의 전체 URL을 종류별로
수집할 것 | 방법 |
|---|---|
전체 URL | 구 사이트의 사이트맵, DB에서의 내보내기, 크롤러 도구. 3가지를 대조해 누락을 방지 |
종류 | 상품·카테고리·콘텐츠·캠페인·정적 페이지·기타 |
검색 유입 | Search Console의 검색 실적에서 과거 12개월의 클릭 수를 URL별로 |
백링크 | Search Console의 링크 보고서 |
색인 상태 | Search Console의 페이지 보고서 |
검색 유입과 백링크가 많은 URL은 리다이렉트 우선순위가 높습니다. 전환 당일에 손으로 확인할 URL을 이 기준으로 골라 둡니다.
Navigation
- Search OS
- 데이터
3.7만 URL의 내역
상품 3만·카테고리 2천·콘텐츠 5천. 규칙으로 9할, 대응표로 1할을 처리
| 구분 | URL 수 |
|---|---|
| 상품 | 30,000 |
| 카테고리 | 2,000 |
| 콘텐츠 | 5,000 |
출처: 본문의 상담 사례(상품 3만·카테고리 2천·콘텐츠 5천)
© 2026 Search OS
규칙 설계: 종류별 변환 규칙
종류 | 규칙의 예 | 규칙으로 대응 가능한 비율의 기준 |
|---|---|---|
상품 | 구 /item/{구ID} → 신 /products/{신ID}. 구 ID와 신 ID의 대응은 DB에서 보유 | 9할 이상 |
카테고리 | 구 /cat/{구코드} → 신 /category/{신경로}. 대응표가 필요 | 7~8할 |
콘텐츠 | 구 /content/{구ID} → 신 /contents/{신슬러그} | 5~7할 |
캠페인 | 종료된 것은 본체의 해당 카테고리로 | 개별 |
정적 페이지 | 개별 | 개별 |
Search OS 가이드 02
종별 변환 규칙과 규칙으로 건지는 비율
못 건지는 만큼이 예외(대응표)
| 번호 | 구분 | 변환 규칙 | 비율 |
|---|---|---|---|
| 1 | 상품 | /item/{구ID} → /products/{새ID} | 9할 이상 |
| 2 | 카테고리 | /cat/{구코드} → /category/{새경로} | 7~8할 |
| 3 | 콘텐츠 | /content/{구ID} → /contents/{새슬러그} | 5~7할 |
| 4 | 캠페인 | 종료된 것은 본체 해당 카테고리로 | 개별 |
| 5 | 정적 페이지 | 개별 |
© 2026 Search OS
규칙은 두 부분으로 이루어집니다. "구 URL 패턴 → 신 URL 패턴"과 "패턴 안 변수의 대응표"입니다. 상품 ID가 그대로라면 규칙만으로 끝납니다. ID가 바뀐다면 구 ID와 신 ID를 짝지은 대응표를 더합니다. 상품 ID가 바뀌는지부터 확인합니다.
예외를 골라내는 기준
규칙으로 변환할 수 없는 URL은 기계적으로 골라냅니다.
구 URL 목록에 규칙을 적용해 신 URL을 만듭니다
만든 신 URL이 신 사이트에 실제로 있는지 확인합니다(스테이징에서 200이 돌아오는지)
없는 것이 예외입니다. 예외마다 통합 대상·이동 대상·삭제(410)를 정합니다
예외는 세 군데에 몰립니다. 통합된 상품(구 2개 상품 → 신 1개 상품), 폐지된 카테고리, URL을 손으로 만들었던 콘텐츠입니다. 이 세 종류부터 예외 목록을 채웁니다.
검증: 스테이징에서 전체 URL을
구 URL 목록(수만 건)을 스테이징의 신 사이트에 요청합니다
각 URL의 응답 코드와 리다이렉트 대상을 기록합니다
301 이외(404, 다단계 301, 302, 200)를 골라냅니다
골라낸 것을 수정하고 다시 검증합니다
"전체 URL이 1회의 301로 200 페이지에 도달한다"가 될 때까지 반복합니다
다단계 리다이렉트(구 → 중간 → 신)는 평가가 새고 크롤이 낭비됩니다. 1회의 301로 최종 URL에 닿는 설계인지 확인합니다.
전환 당일의 절차
리다이렉트를 활성화합니다
검색 유입·백링크 상위 50건을 손으로 열어 제대로 리다이렉트되는지 확인합니다
Search Console에 사이트맵을 다시 등록합니다. 구 사이트맵은 삭제합니다
robots.txt가 신 사이트의 의도대로인지 확인합니다(스테이징의 Disallow가 남아 있지 않은지)
주력 페이지의 URL 검사에서 색인 등록을 요청합니다
스테이징에서 설정한 noindex 나 Disallow: / 가 운영 환경에 남는 사고는 대규모 리뉴얼에서 가장 흔한 실패입니다. 전환 직후 robots.txt와 noindex를 열어 확인합니다.
이전 후 모니터링
시기 | 지표 | 대처 |
|---|---|---|
1주 | Search Console의 404, 리다이렉트 오류 | 누락을 대응표에 추가 |
1주 | 주력 페이지의 색인 | 색인되어 있지 않으면 noindex·robots를 재확인 |
1개월 | 색인 수의 추이 | 구 URL이 줄고 신 URL이 늘고 있는지 |
3개월 | 검색 유입 | 이전 수준으로 돌아왔는지. 돌아오지 않으면 규칙의 누락을 재검증 |
이전 후의 운영
리다이렉트는 전환 당일로 끝나지 않습니다. 구 URL로 오는 백링크는 몇 년이고 남습니다. 404는 한참 뒤에 발견되기도 합니다. 기간 시스템 연동으로 상품 ID가 다시 발급될 수도 있습니다. 카테고리를 재편할 때도 새 리다이렉트가 필요해집니다.
Search OS는 ecbeing 같은 대규모 사이트를 계속 지켜봅니다. 404·리다이렉트 체인·canonical·색인 수의 변화를 살펴봅니다. 봇이 가져가는 구 URL과 신 URL의 대응도 확인합니다. 리뉴얼로 사라진 페이지는 수정 대상으로 정리합니다. 리뉴얼 작업을 대신하는 것이 아니라, 리뉴얼 후 놓친 구멍을 계속 찾아내는 층입니다. 이전 후 오류 페이지를 누가 볼지도 함께 정해 둡니다.
자주 묻는 질문
리다이렉트를 수만 건 설정하면 사이트가 느려지지 않나요?
규칙 기반 리다이렉트는 건수와 상관없이 가볍습니다. 개별 대응표가 수만 건이 된다면 웹 서버의 맵 기능이나 CDN의 리다이렉트 기능으로 처리합니다.
구 URL을 410(소멸)으로 처리해도 되는 건 어떤 경우인가요?
유입도 백링크도 없고 대응하는 신 페이지도 없는 URL입니다. 404보다 410을 검색 엔진이 더 빨리 색인에서 뺍니다.
이전 후 리다이렉트를 언제까지 유지하나요?
최소 1년입니다. 백링크가 남아 있는 한 영구적으로 두는 편이 좋습니다. 삭제하면 백링크의 평가가 사라집니다.
함께 읽기
참고 자료
Google Search Central: Site moves with URL changes
Google Search Central: Redirects and Google Search
Google Search Central: Large site owner's guide to managing your crawl budget