Next.js 웹사이트 번역: 크롤링 가능한 언어별 경로와 SEO

Next.js 웹사이트 번역은 단순히 i18n 라이브러리를 적용하는 작업이 아닙니다. 검색 엔진이 각 언어 버전을 크롤링할 수 있도록 언어별로 고유한 URL이 있어야 하며, 최초 HTML 응답에 메타데이터와 본문이 렌더링되어야 합니다. 하나의 URL에서 쿠키로 로캘을 전환하거나 클라이언트 측에서만 언어를 바꾸면 Google이 언어별 페이지를 따로 색인할 수 없습니다.

핵심 요약: 쿠키 전환보다 크롤링 가능한 로캘 경로가 낫습니다

App Router 세그먼트를 살펴보기 전에 한 가지 원칙만 기억하세요. 모든 언어에 크롤링 가능한 고유 URL을 부여하세요. Google은 쿠키나 브라우저 언어에만 의존하지 말고 언어 또는 지역별로 서로 다른 URL을 사용할 것을 권장합니다. /en/, /de/ 같은 경로 접두사, 전용 하위 도메인, 별도 도메인은 모두 색인 가능한 주소를 만듭니다. 하나의 URL에서 쿠키만으로 언어를 전환하는 방식은 그렇지 않습니다.

쿠키 기반 로캘 전환은 경로를 중복해서 만들 필요가 없어 개발 중에는 편리하게 느껴질 수 있습니다. 하지만 실제 운영 환경의 SEO에서는 이 방식 때문에 크롤러가 다른 언어 버전을 찾지 못합니다. 경로 기반 로캘은 사이트맵에 나열하고, hreflang 주석을 추가하고, Search Console에서 모니터링할 수 있는 안정적인 주소를 제공합니다. 시장별 전략과 언어별 전략의 차이를 더 자세히 알아보려면 국제 SEO와 다국어 SEO 비교 가이드를 참고하세요.

Next.js의 언어별 URL 구조 선택하기

Next.js 팀은 일반적으로 크롤링 가능한 다음 세 가지 구조 중 하나를 선택합니다.

1. 하위 디렉터리 — example.com/en/docs, example.com/fr/docs. 하나의 호스트에 쉽게 배포할 수 있으며, hreflang을 위한 계층 구조가 명확합니다.
2. 하위 도메인 — en.example.com, fr.example.com. 지역별 팀이 어느 정도 독립적으로 운영될 때 유용합니다. 이 경우에도 상호 참조하는 hreflang이 필요합니다.
3. ccTLD 또는 전용 도메인 — 실제로 별도 사이트를 운영할 때 가장 강력한 지역 신호를 제공하지만, 운영 부담도 가장 큽니다.

Google은 주로 화면에 보이는 콘텐츠를 바탕으로 페이지의 언어를 판단합니다. 어떤 구조를 선택하든 탐색 메뉴, 푸터 링크, 오류 페이지를 포함해 각 URL의 콘텐츠는 대체로 하나의 언어로 유지하세요. 사용자에게 명확한 이유가 없다면 같은 템플릿 안에서 여러 언어를 섞지 마세요.

추정한 언어나 위치를 기준으로 방문자를 자동 리디렉션하지 마세요. Google은 이 동작이 크롤러의 접근을 막고 사용자에게 불편을 줄 수 있어 권장하지 않습니다. 대신 다른 로캘 URL로 연결되는 언어 선택기를 눈에 잘 띄게 제공하세요.

App Router와 로캘 세그먼트 설계

App Router에서는 동적 [locale] 세그먼트를 사용하는 방식이 일반적입니다. app/[locale]/layout.tsx 아래에 현지화된 페이지를 배치합니다. 지원할 로캘은 하나의 설정 객체에 정의하고, 레이아웃이나 미들웨어에서 params.locale의 유효성을 검증하세요. 유효하지 않은 로캘에는 같은 URL에서 조용히 영어로 대체하는 대신 404를 반환해야 합니다.

미들웨어로 기본 /를 /en/ 같은 기본 로캘 폴더로 리디렉션할 수 있지만, 다른 언어 버전에도 링크로 접근할 수 있어야 합니다. 마케팅 페이지를 정적으로 생성한다면 미들웨어와 generateStaticParams를 함께 사용해 각 로캘을 미리 빌드하세요.

쿠키 기반 로캘과 경로 기반 로캘 비교: 하나의 URL에서 쿠키나 헤더 기반 협상을 사용하면 주소는 그대로인 채 콘텐츠만 바뀝니다. 크롤러는 일반적으로 하나의 URL을 한 번 가져오므로 모든 언어 버전을 확인하지 못합니다. 경로 기반 로캘이나 이에 상응하는 하위 도메인·도메인 방식은 서로 다른 URL을 사용하라는 Google의 지침에 부합합니다. 공개 URL이 서로 구분된다면, 사용자가 언어를 선택한 후에 해당 환경설정을 쿠키에 저장해도 됩니다.

메시지 로딩에는 next-intl, next-i18next 또는 유사한 라이브러리를 사용하되, 공개 URL은 쿠키에만 의존하지 말고 라우팅으로 정의하세요.

메타데이터, Open Graph, 구조화된 데이터 현지화하기

각 로캘 경로의 서버 렌더링 HTML에는 해당 로캘에 맞는 <title>, 메타 설명, canonical, Open Graph 태그가 있어야 합니다. App Router에서는 페이지마다 generateMetadata를 사용해 메시지 파일에서 번역된 문자열을 읽어오세요. 현지화된 제목과 메타 설명이 하이드레이션 이후 클라이언트 측에서 언어를 바꾸는 방식에 의존해서는 안 됩니다.

JSON-LD에도 같은 원칙을 적용하세요. WebPage, Organization, FAQ 블록에는 번역된 문자열과 로캘에 적합한 inLanguage 값을 사용해야 합니다. hreflang 링크 요소를 출력한다면 레이아웃이나 페이지 메타데이터 헬퍼에서 상호 참조 링크 전체를 생성하세요. 되돌아오는 링크가 누락되면 hreflang 클러스터가 제대로 작동하지 않습니다.

Next.js의 hreflang, canonical, 사이트맵

hreflang은 다른 언어 또는 지역 버전의 URL을 Google에 알려줍니다. 클러스터 내 모든 URL은 자기 자신을 포함한 모든 구성원을 올바른 코드로 참조해야 합니다. <head>, HTTP 헤더 또는 XML 사이트맵의 xhtml:link 항목을 통해 hreflang을 구현할 수 있습니다. 사이트마다 한 가지 방식을 선택해 일관되게 적용하세요.

각 로캘 URL에는 중복 페이지가 있을 때 해당 언어의 대표 URL을 가리키는 canonical도 필요합니다. 예를 들어 추적 매개변수가 붙은 페이지나 인쇄용 보기가 이에 해당합니다. 프랑스어 페이지의 canonical이 영어 버전을 가리키게 하지 마세요. canonical은 같은 언어 내의 중복 페이지를 통합하기 위한 것입니다.

로캘별 사이트맵을 생성하거나 모든 언어 URL을 나열하는 하나의 사이트맵 색인을 만드세요. 사이트맵은 URL 발견을 돕고 hreflang 주석도 포함할 수 있습니다. 배포 후에는 Search Console의 URL 검사와 hreflang 테스트 절차로 샘플 페이지를 검증하세요. 다국어 SEO 플랫폼 개요에서는 SEO 팀이 여러 로캘에서 이러한 신호를 점검하는 방법을 설명합니다.

클라이언트 측에서만 언어를 바꾸는 페이지 골격 피하기

Next.js에서 자주 발생하는 실수는 영어 HTML 골격을 렌더링한 다음 useEffect에서 문자열을 바꾸는 것입니다. 크롤러가 이 교체 작업을 항상 실행하는 것은 아니며, 사용자에게는 잘못된 언어가 잠깐 표시됩니다. 서버 컴포넌트, 정적 생성 또는 SSR을 통해 첫 응답부터 번역된 문구를 렌더링해야 합니다. 클라이언트 컴포넌트는 상호작용 요소를 하이드레이션할 수 있지만, 마케팅 문구와 제목은 서버 트리에 포함되어야 합니다.

경로나 하위 도메인 기반의 로캘 경로는 크롤링 가능한 고유 URL을 만듭니다. 쿠키만으로 로캘을 전환하는 방식은 Google의 권장사항을 충족하지 못합니다. 미리보기에 번역 프록시를 사용한다면 실제 운영 환경에서도 로캘별 URL마다 완전한 HTML이 제공되는지 확인하세요.

콘텐츠 워크플로: 용어집, 번역 메모리, 검토

번역이 제품 용어와 어긋나면 기술적 선택이 좋아도 시장에서 성과를 내기 어렵습니다. Next.js i18n 파일에 용어집, 번역 메모리(TM), 사람의 검토를 결합하세요. Google의 유용한 콘텐츠 가이드라인은 사람을 우선하는 페이지를 중시합니다. 내용이 빈약하거나 상투적인 문구만 담긴 언어 버전은 SEO에도 불리하고 답변의 출처로서도 가치가 낮습니다.

워크플로 개요:

• JSON 또는 PO 파일에서 문자열을 추출해 CAT 도구와 호환되는 파이프라인으로 전달하세요.
• 제품명과 UI 레이블에 용어집의 용어를 일관되게 적용하세요.
• 소스 파일의 차이만 비교하지 말고 스테이징 URL에서 언어 품질을 검수하세요.
• 영어 원문이 변경되면 다시 동기화하세요. 오래된 번역은 신뢰를 떨어뜨립니다.

구현 체크리스트

출시 전에 크롤링 경로, 메타데이터, 주석을 확인하세요.

• 로캘별로 구분되는 공개 URL(경로, 하위 도메인 또는 도메인)
• 다른 언어 URL로 연결되는 눈에 잘 띄는 언어 선택기
• 로캘별로 서버에서 렌더링되는 제목과 설명
• 전체 클러스터에서 상호 참조하는 hreflang
• 다른 언어를 가리키지 않는 언어별 canonical
• 로캘을 반영한 사이트맵 항목
• 크롤러의 접근을 막는 지역·언어 기반 자동 리디렉션 없음
• 스테이징 환경에서 실제로 페이지를 탐색하며 대상 언어 품질 검수

Bing 웹마스터 가이드라인도 크롤링 가능한 유용한 콘텐츠와 명확한 구조를 강조합니다. Google에 도움이 되는 방식은 대체로 Bing의 색인 생성에도 도움이 됩니다.

흔히 하는 실수

하나의 URL에서 쿠키만으로 로캘 전환 — 크롤러가 다른 언어 버전을 찾지 못하게 합니다.

되돌아오는 hreflang 링크 누락 — 상호 참조가 끊기고 클러스터링이 약해집니다.

번역된 페이지의 대표 URL을 영어 페이지로 지정 — 페이지 통합에 관한 잘못된 신호를 보냅니다.

클라이언트 측에서만 제공되는 메타데이터 — 초기 HTML에 제목과 설명이 없습니다.

IP 또는 Accept-Language에 따른 자동 리디렉션 — 크롤러의 접근을 막고 사용자의 선택을 무시합니다.

번역되지 않은 공통 UI — 여러 언어가 섞인 탐색 메뉴는 언어 감지에 혼란을 줍니다.

검수 없이 제공되는 부실한 기계 번역 — 유용한 콘텐츠에 대한 기대 수준을 충족하지 못합니다.

기존 검색 엔진과 답변 엔진을 위한 기본 원칙

Next.js의 로케일별 라우트와 서버 렌더링 HTML을 위한 공통 기본 원칙은 Google, Bing, 답변 엔진 모두에서 여전히 중요합니다. 크롤링 가능한 언어별 버전, 명확한 엔터티, 근거가 뒷받침된 주장, 사실에 부합하는 구조화된 데이터, 그리고 영어 중심의 외형만 갖춘 페이지가 아닌 실질적인 현지화가 필요합니다. 아래 가이드는 동일한 다국어 제공 기준을 플랫폼별 관점에서 살펴보는 자료로 활용하세요.

플랫폼별 가이드: Google 검색

Google 검색에서 페이지가 발견되려면 해당 언어에 맞는 HTML과 정확한 제목·헤딩을 갖춘 크롤링 가능한 로케일별 URL이 필요하며, 대체 언어 버전이 있다면 상호 참조하는 hreflang도 필요합니다. 기술적 기반에는 쿠키로만 언어를 전환하는 방식이 아닌 색인 가능한 콘텐츠, 현지화된 메타데이터, 사이트맵, 일관된 대표 URL 관리가 포함됩니다. 콘텐츠 품질은 각 언어로 제공되는 사용자 중심의 본문 콘텐츠를 뜻합니다. 권위는 번역 도구의 마케팅이 아니라 명확한 조직 정체성과 이를 뒷받침하는 출처에서 나옵니다. 다국어 운영의 핵심은 시장별 또는 언어별 URL이 각각 독립적으로 완결성을 갖춰야 한다는 것입니다. Search Console의 색인 생성 범위와 URL 검사를 통해 로케일별로 측정하세요. 확인된 사실과 불확실한 점을 구분해야 합니다. Google은 다국어 및 hreflang의 작동 방식을 문서화하고 있지만, 특정 CMS나 기계 번역 후편집(MTPE) 워크플로가 검색 순위를 보장한다고 명시하지는 않습니다.

플랫폼별 가이드: Bing

Bing은 구조가 명확하고 크롤링 가능한 다국어 페이지를 발견하고 색인합니다. 이는 URL과 콘텐츠의 명확성에 대한 Google의 요구와 유사합니다. 기술적 기반에는 가져올 수 있는 로케일별 URL, 유용한 콘텐츠, Bing Webmaster Tools를 통한 모니터링이 포함됩니다. 공통 UI만 번역하기보다는 헤딩, 주장, FAQ까지 현지화하세요. 권위 신호는 여전히 신뢰할 수 있는 출처와 일관된 엔터티에 달려 있습니다. 다국어 운영 시 언어별 콘텐츠를 클라이언트 측에서만 작동하는 전환 기능 뒤에 숨기지 마세요. Bing Webmaster Tools에서 색인 현황과 크롤링 통계를 측정하세요. 확인된 사실과 불확실한 점을 구분해야 합니다. Bing 가이드라인은 크롤링 가능하고 유용한 콘텐츠를 강조합니다. 번역 도구에 적용되는 Bing만의 순위 요인을 임의로 만들어내서는 안 됩니다.

플랫폼별 가이드: ChatGPT

ChatGPT는 언어별 버전이 명확하고 답변에 활용하기 좋은 형태로 정리된 공개 페이지를 인용하거나 요약할 수 있습니다. 여기서 콘텐츠 발견은 기존의 크롤링 기반 검색 순위와는 다르며, 노출은 출처로 선택되거나 답변에서 참조되는 형태로 나타납니다. 기술적 기반은 여전히 콘텐츠를 숨기는 위젯 오버레이가 아니라 접근 가능한 HTML 페이지 URL에서 시작됩니다. 직접적인 답변, FAQ, 용어집을 기반으로 한 일관된 용어 사용은 도움이 되는 콘텐츠 특성입니다. 권위는 근거와 로케일 전반에 걸쳐 일관된 엔터티에서 나옵니다. 다국어 운영 시 각 로케일 페이지는 그 자체로 읽고 이해할 수 있어야 합니다. 측정에는 한계가 있으므로 인용 여부 확인은 가설을 검증하는 수준으로 다루세요. 확인된 사실과 불확실한 점을 구분해야 합니다. MTPE나 특정 CMS 연동이 ChatGPT의 인용으로 이어진다는 문서화된 보장은 없습니다.

플랫폼별 가이드: Gemini

일관된 엔터티, 정확한 구조화된 데이터, 색인 가능한 현지화 페이지는 Gemini와 관련 Google AI 서비스에 도움이 됩니다. 노출이란 참조되거나 인식되는 것을 뜻하며, Gemini의 순위 요인을 임의로 만들어내는 것이 아닙니다. 기술적 기반은 Google 검색의 크롤링 가능성 및 메타데이터 품질 요건과 겹칩니다. 콘텐츠는 언어별로 명확한 주장과 정의를 제시해야 합니다. 권위는 조직 정보의 일관성과 이를 뒷받침하는 근거에 달려 있습니다. 다국어 운영 시 용어집으로 제품명을 관리하면 로케일 간 혼란을 줄일 수 있습니다. 기존 방식대로 Search Console에서 측정하고, AI 답변을 표본으로 살펴 정성적으로 평가하세요. 확인된 사실과 불확실한 점을 구분해야 합니다. Gemini의 동작 방식은 hreflang과 언어별 버전에 관한 Google 검색의 공식 문서 지침을 대체하지 않습니다.

플랫폼별 가이드: Google AI Overviews

Google AI Overviews는 답변을 뒷받침하는 페이지로 연결되는 링크를 제공할 수 있습니다. 여기에 포함되기 위한 기본 조건은 여전히 사용자 중심의 색인 가능한 콘텐츠입니다. AI Overviews는 언어 전환 기능이 아니며 hreflang을 대체하지도 않습니다. 기술적 기반은 크롤링 가능한 로케일별 HTML과 사실에 부합하는 구조화된 데이터입니다. 콘텐츠에는 각 언어로 된 간결한 답변과 명확한 헤딩이 필요합니다. 권위 신호도 유용한 콘텐츠에 대한 기대 기준과 같습니다. 다국어 운영 시 어떤 번역 페이지도 AI Overviews에 포함된다고 보장할 수 없습니다. Search Console에서 생성형 AI 관련 보고서를 제공하는 경우 이를 활용해 측정하되, 기존 색인 지표와는 구분해 관리하세요. 확인된 사실과 불확실한 점을 구분해야 합니다. 어떤 번역 워크플로도 AI Overviews 노출을 약속할 수 없습니다.

GlotEO의 역할

Next.js의 i18n을 직접 구현하는 방식은 소규모 사이트에 적합합니다. 규모가 커지면 용어집 관리, 검수 대기열, 로케일 전반의 SEO 검증이 필요해집니다. GlotEO는 최신 기술 스택과 연동되어 마케터가 번역을 관리하는 동안 엔지니어는 App Router 구조를 유지할 수 있도록 합니다.

현지화를 단순한 문자열 교체가 아니라 라우팅과 콘텐츠 품질의 문제로 다루는 팀은 크롤링 경로를 손상시키지 않으면서 더 빠르게 개선 사항을 배포할 수 있습니다. 번역을 시작하기 전에 용어집을 공유하고, 스테이징 환경에서 실제 맥락에 맞춰 페이지를 검수하며, 라우트를 추가할 때마다 hreflang을 다시 확인하세요. 사이트 전체의 통합 수치에만 의존하지 말고 Search Console에서 로케일별 폴더 또는 하위 도메인 단위로 색인 현황을 측정하세요.

GlotEO 웹사이트 현지화에서 웹사이트 현지화 플랫폼을 살펴보고, 도입 범위를 계획할 때 GlotEO 요금 및 플랜을 비교해 보세요.