다국어 사이트 SEO 실무 — KO·EN·FR 사이트를 직접 운영하며 배운 것
임재복
다국어 사이트 SEO의 핵심은 “번역을 많이 푸는 것”이 아니라 각 언어 버전이 검색엔진에 서로를 정확히 가리키도록 구조를 잡는 것입니다. 실무에서 결정해야 할 것은 크게 세 가지입니다. ① 도메인 구조(ccTLD·서브도메인·서브디렉토리 중 무엇을 쓸지), ② hreflang 정합성(각 언어 URL이 상호 참조로 묶이는지), ③ 콘텐츠 전략(전부 번역할지, 시장별로 우선순위를 둘지)입니다. 이 글은 일반론이 아니라, 저희 성장(growthmk.com)이 한국어·영어·프랑스어 3개 언어 사이트를 단일 도메인의 서브디렉토리(/en, /fr)로 직접 운영하면서 부딪힌 문제와 해결 과정을 기록한 것입니다. 구글 다지역 사이트 공식 가이드의 원칙을 기준선으로 두되, 그 원칙이 실제 운영에서 어떻게 깨지고 어떻게 복구했는지를 함께 적었습니다.
다국어 SEO에서 진짜로 어려운 것은 무엇일까요?
다국어 사이트를 처음 만들 때 대부분의 팀은 “번역 품질”을 가장 큰 변수로 봅니다. 그러나 실제로 검색 성과를 무너뜨리는 것은 번역의 자연스러움이 아니라 구조의 정합성입니다. 같은 글의 한국어판과 영어판이 검색엔진 눈에 서로 다른 페이지로 인식되거나, 반대로 전혀 다른 글이 같은 페이지의 번역으로 잘못 묶이면, 번역이 아무리 좋아도 올바른 언어가 올바른 독자에게 노출되지 않습니다.
이 문제가 흔하다는 것은 통계로도 확인됩니다. Ahrefs가 374,756개 도메인을 분석한 연구에서 hreflang을 구현한 사이트의 67%가 어떤 형태로든 오류를 갖고 있었습니다(Ahrefs hreflang 연구). 핵심 신호인 hreflang은 “넣기는 쉽지만 정확히 넣기는 어려운” 영역이고, 저희도 예외가 아니었습니다. 아래 세 가지 결정은 모두 이 정합성을 지키기 위한 것이며, 각 항목은 구글 공식 원칙(공식문서)과 저희의 실제 선택·이유(운영 경험)를 나란히 정리했습니다. 다만 다국어 SEO는 크롤링·인덱싱·렌더링이라는 기본기 위에서만 작동하므로, 토대 자체가 궁금하시다면 기술 SEO 완전 가이드를 먼저 보시길 권합니다.
결정 1 — 도메인 구조: 서브디렉토리 vs 서브도메인 vs ccTLD
원칙: 구글은 세 가지를 모두 허용하되, 각각의 트레이드오프를 명시합니다
구글의 다지역 사이트 가이드는 언어·지역별 URL 구조로 세 가지를 제시합니다. 국가별 도메인(ccTLD, 예: example.fr), gTLD 하위의 서브도메인(fr.example.com), gTLD 하위의 서브디렉토리(example.com/fr)입니다. 공식문서는 어느 하나를 정답으로 못 박지 않고 장단점을 비교합니다. ccTLD는 지역 타겟팅 신호가 가장 명확하지만 도메인마다 인프라가 따로 필요해 비용이 큽니다. 서브도메인은 설정이 쉽고 서버 위치를 분리할 수 있지만 URL만 봐서는 지역 타겟을 인지하기 어렵습니다. 서브디렉토리는 설정이 쉽고 같은 호스트를 공유해 유지보수 부담이 낮다는 것이 구글의 설명입니다(Managing multi-regional and multilingual sites). 같은 문서는 URL 파라미터(?lang=fr)로 언어를 구분하는 방식은 “권장하지 않는다(Not recommended)”고 분명히 밝힙니다.
우리의 선택: 단일 도메인 + 서브디렉토리, 그리고 구 서브도메인의 301 정리
저희는 growthmk.com 단일 도메인 아래 /en, /fr 서브디렉토리로 3개 언어를 운영하기로 결정했습니다. 이유는 세 가지였습니다.
- 도메인 권위(authority)의 통합 — 한 도메인에 모든 언어 콘텐츠가 쌓이면 한국어로 얻은 신뢰가 영어·프랑스어 디렉토리에도 같은 호스트 자산으로 작동합니다. 도메인이 셋으로 쪼개지면 백링크와 신뢰도 셋으로 흩어집니다.
- 운영 단순성 — 저희는 헤드리스 구조(프론트엔드·CMS 분리)로 운영하며, 서브디렉토리는 같은 애플리케이션이 경로만으로 언어를 분기하므로 도메인·인증서·배포 파이프라인을 언어 수만큼 늘리지 않아도 됩니다. 구글이 말한 “낮은 유지보수(same host)”의 이점입니다.
- 언어와 국가의 분리 — 저희 영어·프랑스어판은 특정 국가를 겨냥한 지역 사이트가 아니라 언어 단위 콘텐츠입니다. 목표가 “프랑스어를 읽는 잠재 고객”이지 “프랑스 거주자”가 아니므로, 국가 타겟에 강한 ccTLD의 강점이 비용을 정당화하지 못했습니다.
중요한 실무 포인트가 하나 더 있습니다. 저희는 과거 영어 콘텐츠를 en.growthmk.com이라는 서브도메인으로 운영한 이력이 있었습니다. 서브디렉토리로 전환하면서 구 서브도메인을 방치하지 않고, 모든 경로를 growthmk.com/en/*으로 301 영구 리다이렉트해 정리했습니다. 도메인만 바꾼 게 아니라 구 URL의 카테고리 접두사(예: /insight/{slug})를 제거해 새 구조 /en/{slug}로 매핑하고, 운영하지 않는 태그·작성자 페이지는 상위로 보내고, 구 서브도메인의 robots.txt는 전체 색인 차단(Disallow: /)으로 응답하게 했습니다. 핵심 교훈은 이것입니다. 도메인 구조를 바꿀 때 가장 위험한 것은 옛 구조를 어중간하게 살려 두는 것입니다. 옛 URL과 새 URL이 둘 다 200으로 응답하면 검색엔진은 같은 콘텐츠가 두 곳에 있다고 보고 정본 판단이 흔들립니다. 한 곳을 정본으로 정하고 나머지는 301로 합치는 것이, 구조 변경에서 가장 먼저 할 일입니다.
| 구조 | 지역 타겟 신호 | 권위 통합 | 운영 비용 | 우리 판단 |
|---|---|---|---|---|
| ccTLD (example.fr) | 가장 강함 | 도메인별로 분산 | 높음(도메인·인프라 별도) | 국가 타겟이 분명할 때. 우리 목표는 언어 단위라 과함 |
| 서브도메인 (fr.example.com) | 약함(URL로 인지 어려움) | 호스트 분리로 일부 분산 | 중간 | 구 en. 운영 → 서브디렉토리로 통합 후 301 정리 |
| 서브디렉토리 (example.com/fr) | 약함(canonical·hreflang로 보완) | 한 도메인에 통합(최대) | 낮음(same host) | 채택 — 권위 통합 + 헤드리스 운영 단순성 |
| URL 파라미터 (?lang=fr) | — | — | — | 구글이 비권장 — 후보에서 제외 |
결정 2 — hreflang: 상호 참조와 그룹 정합성
원칙: hreflang은 양방향이어야 하고, 어긋나면 무시됩니다
hreflang은 “이 페이지의 다른 언어 버전은 여기 있다”고 검색엔진에 알리는 신호입니다. 구글은 이를 알리는 방법으로 세 가지를 동등하게 인정합니다. ① HTML <head> 안의 <link rel="alternate" hreflang="...">, ② HTTP Link: 헤더, ③ XML 사이트맵의 <xhtml:link> 요소입니다. 그리고 가장 중요한 규칙은 상호 참조(return link)입니다. 공식문서는 이렇게 못 박습니다. “두 페이지가 서로를 가리키지 않으면, 그 태그는 무시된다(If two pages don’t both point to each other, the tags will be ignored).” 즉 한국어 페이지가 영어 페이지를 가리킨다면, 영어 페이지도 반드시 한국어 페이지를 되가리켜야 합니다. 또한 각 언어 버전은 자기 자신을 포함해 모든 변형을 나열해야 하며, 어느 언어에도 맞지 않는 사용자를 위한 x-default를 함께 두는 것이 권장됩니다(Tell Google about localized versions).
우리의 선택: “같은 언어 다중 URL” 충돌을 그룹 정규화로 해결
이론은 단순합니다. KO ↔ EN ↔ FR를 서로 가리키게 하면 됩니다. 그런데 실제 운영에서 만난 문제는 더 까다로웠습니다. 같은 언어에 URL이 여러 개 잡히는 상황입니다. 어떤 글이 마이그레이션 과정에서 한국어 슬러그를 두 개 갖거나, 번역 연결(translation) 정보가 한쪽에만 입력되어 같은 그룹 안에 “한국어 후보가 둘”인 경우가 생겼습니다. 그러면 hreflang 세트에 동일 언어가 중복으로 들어가고, 검색엔진은 어느 한국어 URL이 진짜 짝인지 판단하지 못합니다. 앞서 말한 “67% 사이트가 겪는 오류”의 전형입니다.
저희 해법은 hreflang을 페이지마다 즉석 조립하지 않고, 번역으로 연결된 글들을 하나의 그룹으로 묶은 뒤(그룹 정규화) 그 그룹이 단일 hreflang 세트를 공유하게 만든 것입니다. 동작은 이렇습니다.
- 연결 관계로 그룹을 만든다 — 각 글의 번역 연결 정보를 따라가며 서로 이어진 글들을 한 묶음으로 합칩니다. A가 B의 번역이고 B가 C의 번역이면, A·B·C는 같은 그룹입니다.
- 그룹 안에서 언어당 URL을 1개로 강제한다 — 한 그룹에 같은 언어 URL이 둘 이상 들어오면, 하나만 정본으로 채택하고 나머지는 버리며 그 충돌을 로그로 남깁니다. “조용히 무시”가 아니라 “기록하고 정리”하는 것이 핵심입니다. 어떤 글의 hreflang이 왜 빠졌는지 나중에 추적할 수 있어야 하기 때문입니다.
- 그룹 전체가 같은 alternates 세트를 쓴다 — 정리된 “언어 → URL” 매핑을 그룹의 모든 페이지가 공유하므로, KO·EN·FR 페이지가 자동으로 서로를, 그리고 자기 자신을 포함해 가리킵니다. 상호 참조 규칙이 구조적으로 보장됩니다.
- x-default를 일관되게 채운다 — 어느 언어에도 매칭되지 않는 사용자를 위해 한국어를 기본값으로 두되, 한국어가 없는 글이면 영어로 폴백하도록 규칙을 고정했습니다.
이 접근의 장점은 hreflang이 “사람이 페이지마다 손으로 맞추는 대상”에서 “데이터에서 한 번에 계산되는 결과물”로 바뀐다는 데 있습니다. 글이 200건이든 500건이든 같은 규칙이 전 페이지에 동일하게 적용되므로, 일부만 맞고 일부는 어긋나는 사태가 구조적으로 사라집니다. 게다가 이 그룹 세트는 사이트맵에도 그대로 반영됩니다. 사이트맵의 각 URL이 같은 그룹의 alternates를 함께 싣기 때문에, 페이지 <head>의 hreflang과 사이트맵의 hreflang이 어긋나지 않습니다. 둘이 모순되면(head는 A를, 사이트맵은 B를 가리키면) 검색엔진은 혼란스러운 신호를 받는데, 단일 진실원(그룹 세트)에서 둘 다 생성하면 이 모순이 원천 차단됩니다.
결정 3 — 콘텐츠 전략: 전부 번역이 아니라, 시장별 우선순위
원칙: 지역별 중복 콘텐츠는 canonical과 hreflang으로 정리한다
같거나 비슷한 콘텐츠를 여러 언어·지역 URL로 제공할 때, 구글은 “선호 버전을 정하고 rel="canonical"과 hreflang으로 올바른 언어·지역 URL이 검색자에게 노출되도록 하라”고 안내합니다(Managing multi-regional and multilingual sites). 즉 다국어 운영에서 약간의 중복은 불가피하며, 숨기거나 회피하는 게 아니라 정본을 정하고 신호로 묶어 정리하는 것이 정석입니다. 단, 사람의 검수 없이 기계번역만 대량으로 푸는 것은 구글 스팸 정책이 경계하는 영역이라는 분명한 선이 있습니다(다음 장에서 다룹니다).
우리의 선택: EN은 KO의 부분집합 + 시장 독자 콘텐츠
저희가 일찍 내린 가장 중요한 콘텐츠 결정은 “모든 한국어 글을 영어·프랑스어로 1:1 번역하지 않는다”였습니다. 이유는 명확합니다. 한국어 콘텐츠 중 상당수는 한국 시장의 맥락(예: 국내 검색 환경, 국내 규제, 국내 매체 생태계)에 강하게 묶여 있어, 영어권·프랑스어권 독자에게는 검색 수요 자체가 없거나 매우 작습니다. 수요가 없는 글을 번역해 색인에 올리면, 독자에게도 도움이 안 되고 사이트 전체의 “도움이 되는 콘텐츠” 평판에도 마이너스입니다.
그래서 저희의 영어판은 한국어 콘텐츠의 부분집합입니다. 언어와 무관하게 보편적으로 통하는 주제(SEO·GEO의 원리, B2B 마케팅 방법론, 측정 체계)는 영어로 제공하고, 한국 시장에 특수한 주제는 한국어로만 둡니다. 여기에 영어·프랑스어 시장에만 의미가 있는 독자(獨自) 콘텐츠를 더합니다. 즉 부분집합이면서 동시에 교집합 밖으로 확장되는 구조입니다.
이를 기술적으로 떠받치는 것이 콘텐츠 언어 메타데이터입니다. 저희는 글마다 CMS에 “이 글의 언어는 ko/en/fr 중 무엇인가”를 메타 필드로 명시하고, 프론트엔드는 이 필드를 기준으로 목록·아카이브·사이트맵을 언어별로 필터링합니다. 과거에는 언어를 태그(tag)로 구분했지만 한 글이 실수로 두 언어 태그를 갖는 등 모호함이 커, 전용 언어 메타 필드 기반으로 전환했습니다. 이 필드는 두 일을 동시에 합니다. ① 화면에서 “한국어 목록엔 한국어 글만” 보이도록 필터링하고, ② 언어별 사이트맵을 생성할 때 어떤 글을 어떤 언어 섹션에 넣을지 결정합니다.
그 결과 사이트맵은 언어별로 동적으로 생성됩니다. 한국어 글은 growthmk.com/{slug}, 영어 글은 growthmk.com/en/{slug}, 프랑스어 글은 growthmk.com/fr/{slug} 형태로 각자의 경로에 실리고, 그룹 정규화 덕분에 각 항목이 자기 그룹의 다른 언어 버전을 hreflang으로 함께 가리킵니다. 정적 페이지(홈·소개·서비스)와 토픽 클러스터 페이지도 같은 원리로 존재하는 언어 버전만 모아 세트를 만듭니다. 한국어에만 있는 글은 단독으로, KO·EN 둘 다 있는 글은 묶여 사이트맵에 들어갑니다.
| 콘텐츠 유형 | KO | EN | FR | 판단 기준 |
|---|---|---|---|---|
| 보편 방법론 (SEO·GEO·B2B 원리) | ○ | ○ | 일부 | 언어 무관 수요 → 다국어 제공 |
| 한국 시장 특수 주제 (국내 검색·규제) | ○ | × | × | 해외 검색 수요 없음 → KO 단독 |
| 영어·프랑스어권 독자 콘텐츠 | 경우에 따라 | ○ | ○ | 해당 시장에만 의미 → 시장별 신규 제작 |
| 서비스·회사 정보 (정적 페이지) | ○ | ○ | ○ | 전 시장 공통 → 3개 언어 모두 |
핵심 사고방식은 이것입니다. 다국어 SEO는 “번역 프로젝트”가 아니라 “시장별 콘텐츠 우선순위 결정”입니다. 저희가 늘 강조하는 “트래픽의 양보다 매출이 될 1명”이라는 기준은 언어를 넘어 그대로 적용됩니다. 영어판의 목표는 한국어 글 개수를 그대로 복제하는 것이 아니라, 영어권에서 저희 서비스의 잠재 고객이 될 사람이 실제로 검색하는 주제에 정확히 닿는 것입니다.
흔한 함정 세 가지 — 우리가 실제로 겪었거나 피한 것
함정 1 — 자동번역을 그대로 색인에 올리는 것
다국어 사이트를 빠르게 늘리려 할 때 가장 유혹적인 선택은 기계번역으로 전 페이지를 찍어내는 것입니다. 그러나 구글 스팸 정책은 “스크래핑한 콘텐츠를 자동 변환(동의어 치환, 번역 등)해 사용자에게 거의 가치를 주지 못하는 페이지를 양산하는 것”을 스팸으로 명시하고, “어떻게 만들어졌든 가치가 거의 없는 대량의 비독창적 콘텐츠”를 scaled content abuse로 규정합니다(Google Search spam policies). 기계번역 자체가 금지는 아니지만, 사람의 검수·편집·시장 맥락 보강 없이 대량으로 푸는 순간 위험해집니다. 저희가 “전부 번역하지 않는다”를 택한 이유 중 하나입니다. 다듬을 여력이 없는 글은 아예 번역하지 않는 편이 안전합니다.
함정 2 — hreflang 상호 참조 누락
가장 흔하고 가장 조용한 실패입니다. 한국어 페이지에는 영어판을 가리키는 hreflang을 넣었는데 영어 페이지에서 한국어판으로 되가리키는 링크를 빠뜨리면, 구글은 그 쌍을 통째로 무시합니다. 화면상 멀쩡해 보여 더 위험합니다. 저희는 “페이지마다 손으로 hreflang을 넣는” 방식 자체를 폐기해 이를 막았습니다. 그룹 세트는 한쪽 방향만 채우는 것이 구조적으로 불가능합니다 — 한 그룹의 모든 페이지가 같은 세트를 공유하므로 A가 B를 가리키면 B도 A를 가리킬 수밖에 없습니다.
함정 3 — 정리되지 않은 중복 콘텐츠
도메인 구조를 바꾸거나(서브도메인 → 서브디렉토리) URL 규칙을 정비할 때, 옛 URL을 살려 둔 채 새 URL을 추가하면 같은 콘텐츠가 두 곳에서 200으로 응답하게 됩니다. 검색엔진은 이를 중복으로 보고 어느 쪽을 색인할지 분산시킵니다. 해법은 평범하지만 반드시 지켜야 합니다. 정본을 하나 정하고, 나머지는 301로 합치며, 비슷하지만 합칠 수 없는 경우엔 canonical로 선호 버전을 지정하는 것입니다. 저희가 구 en. 서브도메인을 301로 정리하고, 운영하지 않는 옛 영어 카테고리·태그 경로까지 함께 매핑한 것이 이 함정을 피하기 위한 작업이었습니다.
다국어 SEO 점검 체크리스트
아래 표는 저희가 실제로 점검하는 항목을 정리한 것입니다. 새 언어를 추가하거나 구조를 바꿀 때, 그리고 정기 감사 때 같은 순서로 확인합니다.
| 영역 | 점검 항목 | 통과 기준 |
|---|---|---|
| 도메인 구조 | 언어 URL 형식이 일관적인가 | 모든 언어가 같은 규칙(서브디렉토리 등)을 따름. 파라미터 방식 없음 |
| 구 구조(옛 도메인·옛 경로)가 정리됐는가 | 옛 URL은 301로 정본에 합쳐짐. 두 곳이 동시에 200으로 응답하지 않음 | |
| hreflang | 상호 참조가 양방향인가 | KO↔EN↔FR가 서로, 그리고 자기 자신을 포함해 가리킴 |
| 같은 언어가 세트 안에 중복되지 않는가 | 한 그룹에 언어당 URL 1개. 충돌은 로그로 기록·정리 | |
| x-default가 있는가 | 매칭 없는 사용자를 위한 기본값(예: KO) 지정 | |
| 사이트맵 | 언어별로 올바른 경로에 실리는가 | KO=/slug, EN=/en/slug, FR=/fr/slug. 누락·오경로 없음 |
| 사이트맵 hreflang과 head hreflang이 일치하는가 | 단일 진실원에서 생성 → 두 신호가 모순되지 않음 | |
| 콘텐츠 | 각 언어판이 시장 수요에 맞는가 | 수요 없는 글의 기계번역 대량 색인 없음. 사람 검수 거침 |
| 언어 메타데이터가 정확한가 | 글마다 언어 필드 단일 지정. 목록·사이트맵 필터링의 기준 |
다국어 SEO는 이 표를 한 번 통과시키는 일이 아니라, 글이 추가될 때마다 표가 계속 통과되도록 구조를 만드는 일입니다. 손으로 맞추면 글이 늘수록 어긋나고, 데이터에서 규칙으로 생성하면 글이 늘어도 일관성이 유지됩니다. 검색 전반의 토대를 더 넓게 다지려면 기술 SEO 완전 가이드와 구글 SEO 최적화 콘텐츠 체크리스트를, 글로벌 진출의 시장 관점은 글로벌 기업의 한국 시장 마케팅을, AI 검색 대비는 GEO(생성형 엔진 최적화) 완전 가이드를 이어서 보시길 권합니다. 다국어 사이트는 검색엔진뿐 아니라 AI 답변 엔진에서도 “어떤 언어 사용자에게 무엇을 보여줄지”를 가르는 신호로 작동하며, 구조가 정합적일수록 사람이든 AI든 올바른 언어 버전을 정확히 인용합니다. 다국어 운영은 결국 올바른 콘텐츠를 올바른 독자에게 — 그중에서도 매출이 될 1명에게 — 닿게 하는 구조의 문제입니다.
다국어 SEO 구조를 직접 운영하며 검증한 저희의 경험을 귀사의 사이트에 적용해 드립니다. 도메인 구조 진단부터 hreflang 정합성 점검, 시장별 콘텐츠 우선순위 설계까지 함께 설계합니다. SEO 서비스에서 접근 방식을 확인하시고, 현재 다국어 사이트의 문제를 구체적으로 점검받고 싶으시다면 상담 문의로 연락 주시기 바랍니다.
이 주제의 전체 그림은 「해외 진출 마케팅 가이드 — 시장 선정부터 현지화·글로벌 SEO까지」에서 한눈에 보실 수 있습니다.
자주 묻는 질문 (FAQ)
다국어 사이트는 서브디렉토리와 서브도메인 중 무엇이 SEO에 유리한가요?
구글은 정답을 규정하지 않고 트레이드오프를 제시합니다. ccTLD는 지역 타겟 신호가 가장 강하지만 비용이 크고, 서브도메인은 서버를 분리할 수 있지만 URL만으로는 지역 인지가 약하며, 서브디렉토리는 같은 호스트를 공유해 유지보수가 쉽고 도메인 권위가 한곳에 통합됩니다. 국가 타겟이 분명하면 ccTLD가, 언어 단위로 운영하며 권위 통합과 운영 단순성을 중시하면 서브디렉토리가 합리적입니다. 저희는 후자의 이유로 단일 도메인 + 서브디렉토리(/en, /fr)를 택했습니다.
hreflang에서 가장 흔한 실수는 무엇인가요?
상호 참조(return link) 누락입니다. 구글은 두 페이지가 서로를 가리키지 않으면 hreflang을 무시한다고 명시합니다. 한 방향만 채우면 화면상 멀쩡해 보여도 신호가 통째로 버려지며, Ahrefs 연구에서도 hreflang 구현 사이트의 67%가 오류를 갖고 있었습니다. 페이지마다 손으로 넣지 말고, 번역으로 연결된 글을 한 그룹으로 묶어 같은 세트를 공유시키면 한쪽만 채우는 것이 구조적으로 불가능해집니다.
모든 콘텐츠를 모든 언어로 번역해야 하나요?
아니요. 한 시장에만 의미 있는 주제(특정 국가의 검색·규제 환경 등)는 그 언어로만 두고, 보편적인 주제만 다국어로 제공하는 편이 낫습니다. 수요 없는 글을 기계번역으로 대량 색인하면 독자에게 도움이 안 될 뿐 아니라, 구글 스팸 정책이 경계하는 “가치 없는 대량 콘텐츠”에 해당할 위험이 있습니다. 저희 영어판은 한국어의 부분집합이면서 영어권 독자만을 위한 독자 콘텐츠를 더한 구조입니다.
도메인 구조를 서브도메인에서 서브디렉토리로 바꾸면 검색 순위가 떨어지나요?
옛 URL을 정리하지 않으면 떨어질 수 있습니다. 핵심은 정본을 하나 정하고 옛 URL을 301 영구 리다이렉트로 새 URL에 합치는 것입니다. 둘 다 살아 있으면 중복 콘텐츠로 색인이 분산됩니다. 저희는 구 en.growthmk.com의 모든 경로를 growthmk.com/en/*으로 301 처리하고, 옛 카테고리 접두사 제거·운영 종료 페이지 매핑·구 도메인 robots.txt 색인 차단까지 함께 정리했습니다. 이렇게 합치면 옛 URL이 쌓은 신호가 새 URL로 이전되어 순위 하락을 최소화할 수 있습니다.
