SEO 에이전시를 위한 대량 리디렉션: 마이그레이션 맵을 통제하며 배포하는 방법

대량 리디렉션은 단순 구현 작업으로 취급되는 순간 위험해집니다. SEO 에이전시가 사이트 이전을 맡는다면 redirect map은 고객 승인 기록이자 SEO 리스크 표이며, 개발팀 handoff 문서이고, 런칭 후 문제가 생겼을 때 되돌리기 위한 롤백 계획입니다.

그래서 큰 이전 작업을 스프레드시트, 메신저 대화, 워드프레스 플러그인, Nginx 설정, .htaccess 파일 안에만 두면 안 됩니다. DNS 변경, CDN 전환, 쇼핑몰 이전, 도메인 변경 전에 이 맵 자체를 운영 설정처럼 검토해야 합니다.

이 글은 카페24, 고도몰, Shopify, WordPress, 자체 CMS, headless commerce, 여러 브랜드 사이트를 이전하는 SEO 에이전시와 기술 SEO 팀을 위한 실무 가이드입니다. 네이버 검색광고, 카카오톡 채널, 이메일, 제휴 링크, 인플루언서 게시물, 이미 배포된 QR 코드가 남아 있는 프로젝트에도 적용됩니다.

에이전시용 워크플로

안전한 흐름은 복잡하지 않습니다. 다만 런칭 직전에 생략하기 쉽습니다.

1. 아직 가치 있는 트래픽을 보내는 모든 URL 소스를 수집한다
2. URL을 비즈니스 리스크와 SEO 리스크로 분류한다
3. 담당자, 검토 상태, 결정 메모가 있는 redirect map을 만든다
4. 가져오기 전에 맵을 검증한다
5. 런칭 전에 batch를 가져오고 대표 URL을 테스트한다
6. 런칭 후 모니터링과 롤백 경로를 준비한다

스프레드시트와 마이그레이션 산출물의 차이는 책임입니다. 스프레드시트는 행을 저장합니다. 산출물은 누가 목적지를 승인했는지, 왜 그 status code가 맞는지, 어떤 parameter를 보존해야 하는지, 너무 넓은 규칙이 문제를 만들면 어떻게 되돌릴지를 보여줍니다.

여러 소스에서 URL 인벤토리 만들기

CMS나 쇼핑몰 관리자 export만으로 충분하다고 보면 안 됩니다. 런칭 당일에 문제가 되는 URL은 플랫폼 export 밖에 있는 경우가 많습니다. 오래된 광고, 카카오톡 발송 링크, 이메일, 제휴 링크, 인플루언서 콘텐츠, 오프라인 QR 코드, Search Console에서 아직 노출되는 예전 landing page가 여기에 들어갑니다.

최소한 다음 소스를 함께 수집하세요.

작은 사이트라면 검토된 CSV 하나로 충분할 수 있습니다. 대형 커머스나 여러 브랜드 프로젝트라면 작업 파일을 소스별로 나눠도 됩니다. 하지만 실제 배포는 통합된 redirect map에서만 해야 합니다.

운영 질문에 답할 수 있는 맵으로 만들기

에이전시의 redirect map은 old_url과 new_url만으로 부족합니다. 두 컬럼만 있어도 redirect는 만들 수 있지만, 고객, SEO, 마케팅, 개발이 합의한 결정으로 남기기에는 부족합니다.

다음과 같은 컬럼을 사용하세요.

old_url,new_url,status,priority,owner,query_policy,rule_type,review_status,notes
https://old.example.kr/pricing,https://new.example.kr/pricing,301,high,marketing,preserve,exact,approved,주요 리드 경로
https://old.example.kr/blog/legacy-guide,https://new.example.kr/resources/guide,301,medium,seo,preserve,exact,needs-review,콘텐츠 통합 예정
https://old.example.kr/products/*,https://new.example.kr/shop/*,301,high,ecommerce,preserve,wildcard,approved,상품 path 구조 유지

이 정도 정보가 있으면 런칭 직전에 나오는 질문에 답할 수 있습니다.

• 영구 이전인가, 임시 캠페인 변경인가
• 목적지가 사용자의 의도와 맞는가, 아니면 편의상 홈으로 보내는가
• query string, UTM, 쿠폰, 제휴 ID를 보존해야 하는가
• exact, wildcard, regex 중 어떤 규칙인가
• 단종 상품, 통합 카테고리, 삭제 콘텐츠 예외는 누가 승인하는가
• 아직 production에 넣기 위험한 행은 무엇인가

이 답이 맵에 없다면, 팀은 런칭 창 안에서 다시 판단하게 됩니다.

가져오기 전에 리스크로 나누기

모든 행을 같은 깊이로 검토할 필요는 없습니다. 3만, 5만, 10만 URL짜리 맵도 핵심 URL과 기계적으로 처리할 URL을 나누면 관리할 수 있습니다.

많은 에이전시 이전은 여기서 흔들립니다. wildcard는 수천 개 URL을 처리할 수 있지만, 매출이나 backlink, 광고비가 걸린 몇 개 URL을 숨길 수도 있습니다. wildcard와 regex는 속도를 올리는 도구이지 검토를 대신하는 도구가 아닙니다.

라우팅 계층이 되기 전에 검증하기

검증은 두 번 필요합니다. 가져오기 전 정적 검증과, staging 또는 제한된 환경에서 규칙이 실제로 동작한 뒤의 행동 검증입니다.

가져오기 전에 확인할 항목은 다음과 같습니다.

• old_url 중복
• 비어 있거나 잘못된 목적지 URL
• protocol 또는 hostname 오류
• 기존 URL이 이미 다른 redirect를 포함하는 경우
• 목적지가 404, 410, 5xx 또는 예상 밖 redirect를 반환하는 경우
• wildcard가 exact rule과 겹치는 경우
• 너무 넓거나 anchor가 없는 regex
• 캠페인 reporting과 충돌하는 query string 처리

가져온 뒤에는 문법이 아니라 실제 행동을 확인하세요. 대표 URL은 Redirect Checker로 테스트하고, 마이그레이션이 크면 전체 batch를 crawl합니다.

QA의 목표는 "redirect가 있다"가 아닙니다. 목표는 "기존 URL이 의도한 status code로, chain이나 loop 없이, 필요한 parameter를 잃지 않고 가장 적절한 새 목적지에 도착한다"입니다.

런칭 당일을 릴리스처럼 계획하기

에이전시 프로젝트의 런칭 당일은 정리 작업이 아닙니다. 누가 무엇을 보고, 언제 판단하고, 어디까지 되돌릴 수 있는지 정해져 있어야 합니다.

롤백은 전체 이전을 되돌리는 것만 의미하지 않습니다. 문제가 있는 batch를 끄거나, 이전 snapshot을 복구하거나, 잘못된 패턴을 더 높은 우선순위의 exact rule로 덮는 것일 수 있습니다. 중요한 것은 그 경로가 런칭 전에 정해져 있어야 한다는 점입니다.

에이전시 시간을 잡아먹는 실수

결정되지 않은 행을 배포하기

담당자나 검토 상태가 없는 행을 batch 안에 숨기면 안 됩니다. 미해결로 표시하고, 누군가 목적지를 승인할 때까지 production에서 제외하세요.

단종 상품이나 삭제 콘텐츠를 모두 홈으로 보내기

홈페이지는 안전해 보이지만 사용자 경험과 마이그레이션 연속성에는 약할 때가 많습니다. 단종 상품은 대체 상품, 카테고리, 지원 문서, 단종 안내 페이지가 더 나을 수 있습니다.

여러 계층이 같은 redirect를 소유하게 두기

고객 환경에는 Nginx, Apache .htaccess, Cloudflare, 카페24, Shopify, WordPress, SEO 플러그인, 앱 middleware에 redirect가 동시에 남아 있을 수 있습니다. 이전용 redirect를 어느 계층이 소유하는지 정하지 않으면 디버깅이 느려지고 책임도 흐려집니다.

캠페인과 제휴 parameter를 잊기

crawler에서는 정상처럼 보여도 reporting이 깨질 수 있습니다. utm_source, utm_medium, utm_campaign, 쿠폰, 제휴 ID, 카카오톡 발송 parameter, 네이버 광고 parameter처럼 실제로 쓰는 query를 포함해 테스트하세요.

UrlEdge가 들어가는 위치

UrlEdge는 redirect map이 서버 설정이나 CMS 플러그인 안에 묻히기에는 너무 중요할 때 맞습니다. 기본 흐름은 다음과 같습니다.

1. 맵을 만들고 승인한다
2. Bulk URL Management로 규칙을 가져온다
3. 핵심 URL을 Redirect Checker로 검증한다
4. 검토된 snapshot을 edge에 배포한다
5. 트래픽을 모니터링하고 rollback을 유지한다

영구 이전에는 Permanent 301 Redirects와 함께 사용하세요. 오래된 routing 계층이 많다면 Redirect Chains and Loops를 보면서 정리하는 것이 좋습니다. 도메인 변경이 포함된다면 path와 UTM을 잃지 않는 도메인 redirect 가이드도 함께 확인하세요.

가치는 redirect가 edge에서 실행된다는 점만이 아닙니다. 에이전시 입장에서는 이전 작업이 검토 가능하고, 테스트 가능하고, 배포 가능하고, 필요하면 복구 가능한 운영으로 바뀌는 것이 핵심입니다.

FAQ

모든 마이그레이션에 301을 써야 하나요?

아니요. 영구 URL 이전에는 보통 301 또는 308을 씁니다. 임시 캠페인 변경에는 302 또는 307이 더 적합할 수 있습니다. status code는 설정 습관이 아니라 비즈니스 의도에 맞춰야 합니다.

수동 설정으로는 몇 개부터 위험한가요?

정해진 숫자는 없습니다. 검토, 담당자, 검증, analytics, rollback이 문법보다 중요해지는 순간이 신호입니다. 그 시점부터는 여러 계층을 손으로 수정하는 것보다 전용 workflow가 안전합니다.

오래된 redirects는 오래 유지해야 하나요?

중요한 이전 URL은 오래 유지해야 합니다. backlink, 오래된 이메일, 인쇄된 QR 코드, 파트너 문서, 고객 bookmark는 런칭 후에도 오래 이전 URL로 트래픽을 보낼 수 있습니다.

wildcard 하나로 큰 CSV 맵을 대체할 수 있나요?

때로는 가능합니다. 기존 path와 새 path가 예측 가능하게 맞아떨어질 때 wildcard를 쓰세요. 고가치 페이지, 단종 상품, 병합 카테고리, 판단이 필요한 목적지는 명시적 매핑으로 남기는 편이 안전합니다.

참고 자료

• Google Search Central: Site move with URL changes
• Google Search Central: Redirects and Google Search
• MDN: Redirections in HTTP