SEOnext-intli18nNext.js

다국어 사이트, URL은 언어별로 따로 둬야 SEO에 유리하다

June 24, 20261 min read

"URL에서 /en, /ko 좀 빼면 안 되나?"

내 블로그(backtodev)는 한국어와 영어를 같이 서비스한다. URL은 이렇게 생겼다.

https://backtodev.com/ko/portfolio
https://backtodev.com/en/portfolio

포트폴리오를 공유할 때마다 고민이 됐다. 외국에 보낼지 한국에 보낼지에 따라 링크가 달라지니까. 그래서 "URL 하나(/portfolio)로 두고, 브라우저 언어에 따라 자동으로 한국어/영어를 보여주면 안 되나?" 하는 생각이 자연스럽게 들었다.

기술적으론 가능하다. 그런데 알아보니 SEO 관점에서는 하면 안 되는 짓이었다. 결론은 "언어별로 URL을 따로 유지하는 게 맞다"였고, 그 이유를 정리해 둔다. 다국어 사이트를 만드는 사람이라면 한 번은 부딪히는 갈림길이다.

검색엔진은 "URL = 페이지"로 본다

핵심 전제부터. 구글 같은 검색엔진은 하나의 URL을 하나의 페이지로 색인한다. URL이 곧 페이지의 주소이자 신원이다.

그런데 URL 하나(/portfolio)에 브라우저 언어에 따라 다른 콘텐츠를 보여주면 어떻게 될까?

같은 URL: https://backtodev.com/portfolio
  ├─ 한국어 브라우저로 열면 → 한국어 콘텐츠
  └─ 영어 브라우저로 열면   → 영어 콘텐츠

구글 크롤러는 보통 미국 IP + 영어 환경으로 사이트를 긁어간다. 그러면 구글은 /portfolio영어 페이지 하나로만 인식한다. 한국어 버전은 존재 자체를 모르게 된다. 한국어로 아무리 좋은 글을 써도 검색에 안 잡히는 것이다.

방식구글이 인식하는 것결과
URL 1개 + 브라우저 분기한 언어만 (보통 영어)다른 언어는 색인 안 됨
언어별 URL 분리두 페이지 각각양쪽 언어 모두 검색 노출

게다가 "cloaking" 위험까지 있다

URL 하나로 방문자마다 다른 콘텐츠를 보여주는 건, 자칫 클로킹(cloaking) 으로 의심받을 수 있다. 클로킹은 "검색엔진에게 보여주는 내용과 사용자에게 보여주는 내용이 다른 것"을 말하는데, 구글이 싫어하는 패턴이다.

물론 언어 분기는 악의적 클로킹과는 다르지만, "같은 URL인데 보는 사람마다 내용이 다르다"는 구조 자체가 검색엔진 입장에선 다루기 까다롭다. 굳이 이 위험을 떠안을 이유가 없다.

그래서 정답: 언어별로 URL을 분리한다

구글이 공식적으로 권장하는 방식이 바로 언어별 고유 URL이다. 그리고 그중에서도 subdirectory(하위 경로) 방식을 가장 추천한다.

https://backtodev.com/ko/portfolio   ← 한국어
https://backtodev.com/en/portfolio   ← 영어

다국어 URL을 나누는 방법은 크게 세 가지인데, 비교하면 이렇다.

방식예시평가
subdirectorybacktodev.com/en/...✅ 구글 권장, 관리 쉬움
subdomainen.backtodev.com/...가능하나 설정 복잡
국가 도메인(ccTLD)backtodev.kr, backtodev.com비용·관리 부담 큼

개인 블로그나 중소 사이트는 subdirectory(/en/)가 사실상 정답이다. 도메인 하나로 끝나고, 언어가 경로에 명확히 드러나서 검색엔진이 구분하기도 쉽다.

next-intl이 이걸 기본으로 해준다

Next.js에서 다국어를 붙일 때 많이 쓰는 next-intlpath 기반 라우팅을 기본으로 한다. 즉 처음부터 /en/, /ko/ 같은 subdirectory 구조를 전제로 설계돼 있다.

// i18n/routing.ts
import { defineRouting } from "next-intl/routing";

export const routing = defineRouting({
  locales: ["en", "ko"],
  defaultLocale: "ko",
});

폴더 구조도 자연스럽게 app/[locale]/...로 잡힌다.

app/
  └─ [locale]/          ← en / ko 가 여기 들어감
       ├─ portfolio/page.tsx
       └─ posts/[slug]/page.tsx

별다른 꼼수 없이 라이브러리 기본만 따라가도 SEO 친화적인 언어별 URL이 만들어진다. 굳이 URL 하나로 합치려고 역행할 필요가 없다는 뜻이다.

두 페이지를 "형제"로 묶어주기 — hreflang & canonical

언어별로 URL을 나눴으면, 검색엔진에게 "이 둘은 같은 내용의 다른 언어 버전이야"라고 알려주는 게 좋다. 그래야 구글이 사용자 언어에 맞는 버전을 검색 결과에 보여준다. 이때 쓰는 게 hreflang 태그다.

<!-- /ko/portfolio 페이지의 <head> -->
<link rel="alternate" hreflang="ko" href="https://backtodev.com/ko/portfolio" />
<link rel="alternate" hreflang="en" href="https://backtodev.com/en/portfolio" />
<link rel="alternate" hreflang="x-default" href="https://backtodev.com/ko/portfolio" />
  • hreflang="ko", hreflang="en" : 각 언어 버전의 위치를 알려줌
  • hreflang="x-default" : 어디에도 안 맞는 사용자에게 보여줄 기본 버전

여기에 canonical(정규 URL)도 각 페이지가 자기 자신을 가리키게 둔다. 그러면 "한국어 페이지와 영어 페이지가 내용이 비슷하다"는 이유로 중복 콘텐츠(duplicate content) 취급받는 걸 막을 수 있다.

<!-- /ko/portfolio 의 canonical 은 자기 자신 -->
<link rel="canonical" href="https://backtodev.com/ko/portfolio" />

그럼 공유 고민은 어떻게 풀까

다시 처음 고민으로 돌아가자. "공유할 때 언어를 미리 정해야 하는 게 번거롭다"는 문제. 이건 URL 구조를 망가뜨리지 않고도 풀 수 있다.

  • 접두사 없는 링크를 공유 → 미들웨어에서 방문자 브라우저 언어를 감지해 /ko/ 또는 /en/로 자동 리디렉션
  • 즉 SEO용 고유 URL은 그대로 두고, 사람이 클릭할 때만 적절한 언어로 보내주면 된다

SEO(고유 URL 유지)와 사용자 편의(자동 언어 선택)는 충돌하는 게 아니라 역할을 나누면 둘 다 가질 수 있다. 색인은 언어별 URL로, 진입 경험은 리디렉션으로.

정리

다국어 사이트 URL 설계, 핵심만 추리면 이렇다.

  1. URL 하나로 합치고 브라우저로 콘텐츠만 바꾸기 → 하지 말 것 (한 언어만 색인됨 + 클로킹 위험)
  2. 언어별 고유 URL 유지 → 구글이 양쪽 언어를 각각 색인
  3. 형태는 subdirectory(/en/, /ko/) 가 권장 (next-intl 기본값)
  4. hreflang으로 언어 버전을 묶고, canonical로 중복 방지
  5. 공유 편의는 자동 리디렉션으로 따로 해결

처음엔 /en, /ko가 URL에 붙는 게 지저분해 보여서 빼고 싶었다. 하지만 그게 사실 검색엔진이 양쪽 언어를 다 읽게 해주는 장치였다. 깔끔함보다 검색에 노출되는 것이 블로그엔 훨씬 중요하니, 언어별 URL은 남겨두기로 했다.

PM

backtodev

40대 PM, 다시 개발자로 돌아갑니다. 실패하고 배우며 성장하는 기록.

다국어 사이트, URL은 언어별로 따로 둬야 SEO에 유리하다 | backtodev