Shopify URL을 headless로 이전하면서 SEO 트래픽 지키기

Shopify URL 이전이 깨지는 이유

Shopify Liquid에서 Next.js, Hydrogen, 자체 스택 기반 headless storefront로 이동할 때 가장 위험한 부분은 디자인이 아닙니다. 위험은 URL 계층에 있습니다.

Shopify는 보통 이런 구조를 강제합니다.

• /products/{handle}
• /collections/{handle}
• /pages/{handle}

Headless 빌드에서는 더 짧거나 유연한 route를 도입하는 경우가 많습니다.

• /shop/{handle}
• /c/{handle}
• /{handle}

새 storefront에는 좋을 수 있습니다. 하지만 Google, 이메일, 카카오톡 공유, 유료 광고, 제휴 링크, QR 코드, 고객 bookmark에 여전히 예전 Shopify URL이 남아 있다면 출시일에 문제가 됩니다.

이전 리스크

리디렉션 맵 없이 headless 이전을 진행하면 보통 세 가지 문제가 생깁니다.

1. 404 오류: Googlebot과 실제 구매자가 더 이상 존재하지 않는 상품, 컬렉션, 콘텐츠 URL에 도착합니다.
2. 검색 신호 손실: backlink, 내부 링크, 오래된 검색 결과가 가장 알맞은 새 목적지로 연결되지 않습니다.
3. 캠페인 단절: 이메일, paid social, creator, affiliate link가 상품이나 카테고리로 제대로 이어지지 않습니다.

[!WARNING] DNS 전환 당일에 리디렉션을 만들기 시작하면 늦습니다. 리디렉션 맵은 새 storefront가 production traffic을 받기 전에 준비, 가져오기, 스테이징 크롤링까지 끝나야 합니다.

1. 기존 Shopify URL 내보내기

리디렉션 규칙을 만들기 전, 이미 트래픽을 받고 있는 URL을 모으세요. Shopify에서 시작하고 SEO/analytics 데이터로 보강합니다.

Shopify Admin

Products > Export에서 “All products”를 선택하면 Handle 컬럼이 있는 CSV를 받을 수 있습니다.

Handle,Title,Variant Price
cool-tshirt,Cool T-Shirt,29.99
blue-jeans,Blue Jeans,49.99

Sitemap 파싱

상품, 컬렉션, 페이지, 블로그 글까지 더 넓게 보려면 Shopify sitemap.xml을 파싱하세요.

npm install -g sitemap-to-csv
sitemap-to-csv https://store.example/sitemap.xml > urls.csv

검색과 분석 데이터 내보내기

Shopify만으로는 중요한 URL을 모두 알 수 없습니다. 다음 데이터도 함께 가져오세요.

• Google Search Console impressions/clicks가 있는 페이지
• GA4 또는 warehouse landing-page report
• UTM이 붙은 유료 매체 URL
• 제휴 및 파트너 링크
• 고객 이메일과 lifecycle 캠페인

이 URL들은 리디렉션 맵에서 높은 우선순위로 표시해야 합니다.

2. 리디렉션 맵 설계

모든 URL에 1:1 규칙이 필요한 것은 아닙니다. 예측 가능한 Shopify 구조는 패턴 규칙으로 처리하고, 단종 상품이나 통합 카테고리, 가치가 높은 예외는 개별 규칙으로 처리합니다.

시나리오 A: prefix 변경

• Old: https://shop.example/products/blue-jeans
• New: https://shop.example/shop/blue-jeans

UrlEdge rule

• Source: ^/products/(.*)$
• Destination: /shop/$1
• Type: 301

시나리오 B: prefix 제거

• Old: https://shop.example/products/blue-jeans
• New: https://shop.example/blue-jeans

UrlEdge rule

• Source: ^/products/(.*)$
• Destination: /$1

[!TIP] root-level product URL은 조심해야 합니다. 새 router가 /about, /contact, /cart 또는 collection slug와 충돌하지 않는지 확인하세요.

시나리오 C: 캠페인 파라미터 보존

캠페인 링크는 이메일, SMS, creator post, 유료 광고 안에서 몇 달 동안 살아 있습니다.

https://shop.example/products/blue-jeans?utm_source=newsletter&utm_campaign=spring

는 다음으로 이동해야 합니다.

https://shop.example/shop/blue-jeans?utm_source=newsletter&utm_campaign=spring

리디렉션이 query parameter를 실수로 제거하면 crawl tool에서는 성공처럼 보여도 캠페인 attribution은 조용히 깨집니다.

3. Edge에서 리디렉션 구현

Headless 앱 안에서 리디렉션을 처리할 수도 있습니다. 하지만 그렇게 하면 이전 라우팅이 frontend deployment에 묶입니다. 큰 리디렉션 맵은 전용 edge layer에 두는 편이 운영하기 쉽습니다.

UrlEdge에서는 CSV 맵을 가져오거나 regex 규칙을 직접 정의할 수 있습니다.

{
  "rules": [
    {
      "source": "^/products/(.*)",
      "destination": "/shop/$1",
      "type": 301
    },
    {
      "source": "^/pages/contact-us",
      "destination": "/contact",
      "type": 301
    }
  ]
}

4. 검증

DNS를 전환하기 전에 기존 URL 인벤토리를 새 리디렉션 계층에 대해 테스트하세요.

1. 스테이징 도메인: staging hostname을 UrlEdge에 연결하고 가치가 높은 URL부터 테스트합니다.
2. curl 테스트:

curl -I https://staging.shop.example/products/old-product
 
# 예상 출력:
# HTTP/2 301
# location: /shop/old-product
# x-urledge-rule: regex-product-match

3. 크롤링 테스트: Screaming Frog 같은 crawler로 기존 URL 목록을 staging 환경에서 검사합니다.
4. 캠페인 테스트: utm_source, utm_medium, utm_campaign, coupon, affiliate parameter가 붙은 URL을 샘플링합니다.
5. 예외 검토: 단종 상품이 무조건 홈페이지로 가지 않고 가장 가까운 컬렉션, 대체 상품, 지원 페이지로 가는지 확인합니다.

결론

Headless Shopify 이전에는 두 개의 출시가 있습니다. 새 storefront 출시와, 오래된 트래픽을 살려두는 리디렉션 계층 출시입니다. 리디렉션 맵을 사후 정리 작업이 아니라 출시 인프라로 다루세요.

리디렉션 로직을 edge로 옮기면 팀은 다음을 할 수 있습니다.

• 큰 리디렉션 맵을 frontend code 밖에 둡니다.
• DNS 전환 전에 규칙을 검증합니다.
• 상품, 컬렉션, 캠페인 경로를 보존합니다.
• storefront를 재배포하지 않고 예외를 업데이트합니다.

리디렉션 맵을 준비하려면 무료 UrlEdge 계정으로 시작해 출시일 전에 첫 batch를 가져와 보세요.