다국어 홈페이지 SEO, hreflang 설정 방법 완벽 정리

목차

• 다국어 홈페이지 SEO, 일본어·영어 사이트 hreflang 설정 방법
• 다국어 홈페이지 SEO의 출발점은 URL 구조 결정입니다
• 언어별 디렉터리 방식
• 서브도메인 방식
• 별도 도메인 방식
• hreflang 태그는 무엇을 크롤러에 알리는가
• 상호 참조(양방향) 규칙
• x-default의 쓰임
• 언어 코드 표기법: ja, en, ko와 지역 결합
• WPML로 한국어·일본어·영어 사이트를 구성하는 순서
• 언어 추가와 주소 형식 지정
• 번역 편집기와 문자열 처리
• 사이트맵과 색인 신호 점검
• 자동 리디렉션이 색인을 망가뜨리는 이유
• 번역 품질과 중복 콘텐츠 판정
• 설정 후 검증 절차
• 다국어 사이트에서 자주 나타나는 오류 4가지
• 핵심 요약
• F.A.Q

다국어 홈페이지 SEO, 일본어·영어 사이트 hreflang 설정 방법

다국어 홈페이지 SEO의 출발점은 URL 구조 결정입니다

다국어 홈페이지 SEO는 언어마다 고유한 주소를 부여하고, 그 주소들을 hreflang 속성으로 묶어 "같은 문서의 언어 변형"임을 크롤러에 알리는 작업입니다. 번역문을 한 페이지 안에 나란히 쌓아 두거나 쿠키·세션으로 화면만 바꾸는 방식은 색인 대상 주소가 하나뿐이어서 언어별 노출이 성립하지 않습니다.

주소를 나누는 방법은 크게 세 가지입니다. 워드프레스에서 WPML을 쓰는 경우 언어 설정 단계에서 디렉터리, 서브도메인, 별도 도메인 중 하나를 고르게 되며 WPML 공식 문서는 이 세 형식을 혼용할 수 없다고 명시합니다(WPML Language URL format options). 한 번 정하면 되돌리기 위해 전면 301 리디렉션이 필요하므로, 착수 시점의 판단이 이후 몇 년의 운영 비용을 좌우합니다.

이노스톤이 국내 기업의 일본·영어 사이트를 구축할 때 가장 먼저 묻는 것은 "현지 법인이 있는가, 콘텐츠를 누가 관리하는가" 두 가지입니다. 이 답에 따라 아래 세 형식 중 합리적인 선택지가 사실상 하나로 좁혀지기 때문입니다.

언어별 디렉터리 방식

디렉터리 방식은 `example.com/ja/`, `example.com/en/`처럼 기존 도메인 하위 경로에 언어를 배치합니다. 원 도메인이 쌓아 온 신뢰 신호를 언어 버전이 그대로 이어받는다는 점이 가장 큰 장점입니다.

운영 부담도 가장 가볍습니다. 인증서, DNS, 서버 설정을 새로 만들 필요가 없고 사이트맵도 한 벌로 관리됩니다. 국내 중견기업이 일본 바이어와 영어권 문의를 함께 받으려는 상황이라면 이 구조가 무난합니다.

단점은 지역 타깃팅의 정밀도가 떨어진다는 점입니다. 디렉터리는 국가 단위 신호를 직접 전달하지 못하므로, 특정 국가 시장을 겨냥한다면 hreflang의 지역 결합 표기와 현지 콘텐츠로 신호를 보완해야 합니다.

서브도메인 방식

서브도메인 방식은 `ja.example.com`, `en.example.com` 형태로 언어를 분리합니다. 서버나 CDN을 언어별로 다르게 붙일 수 있어, 일본 사용자에게는 도쿄 리전을, 국내 사용자에게는 서울 리전을 배정하는 식의 분리 운영이 가능합니다.

구글은 서브도메인과 하위 디렉터리 중 어느 쪽이 순위에서 유리하다고 규정하지 않습니다. 다만 운영 관점에서는 인증서 와일드카드 발급, 로그 분리, 도구 등록 계정 분리 같은 관리 작업이 늘어납니다.

조직이 분리된 경우에 특히 유용합니다. 일본 지사가 자체 콘텐츠를 편성하고 본사와 발행 일정이 다르다면, 서브도메인이 권한 분리와 배포 사고 격리에 유리합니다.

별도 도메인 방식

별도 도메인 방식은 `example.jp`, `example.com`처럼 언어마다 독립된 도메인을 씁니다. 국가 코드 최상위 도메인(ccTLD)은 그 자체로 강한 국가 신호를 주기 때문에, 현지 시장에서의 신뢰 형성이 목적이라면 가장 확실한 선택입니다.

대가도 분명합니다. 도메인마다 권위를 처음부터 쌓아야 하고, 링크 자산이 분산되며, 갱신·인증서·법적 표기까지 별도로 챙겨야 합니다. WPML은 언어별 도메인 구성 시 각 도메인이 같은 워드프레스 설치를 가리키도록 서버에서 매핑해야 한다고 안내합니다(WPML 공식 문서).

구조	예시 주소	국가 신호	초기 구축 부담	적합한 상황
디렉터리	example.com/ja/	약함	낮음	본사 단일 운영, 문의 유입 확대
서브도메인	ja.example.com	중간	중간	지사 별도 운영, 인프라 분리
별도 도메인	example.jp	강함	높음	현지 법인 보유, 시장별 브랜드 분리

hreflang 태그는 무엇을 크롤러에 알리는가

hreflang은 "이 주소와 저 주소는 같은 내용의 다른 언어판"이라는 관계를 선언하는 속성입니다. 구글 문서는 이 관계를 통해 검색 결과에서 사용자의 언어·지역에 맞는 버전이 노출되도록 돕는다고 설명합니다(Google Search Central, Localized Versions of your Pages).

선언 위치는 세 곳 중 하나를 고르면 됩니다. HTML `head` 안의 link 요소, HTTP 응답 헤더, XML 사이트맵입니다. 구글은 이 세 방법을 동등하게 취급한다고 밝히고 있으므로, 구현 편의에 따라 고르되 한 사이트 안에서 방식을 섞어 신호가 어긋나지 않게 유지하는 편이 안전합니다.

PDF나 이미지처럼 HTML이 아닌 파일에는 헤더 방식만 쓸 수 있습니다. 카탈로그 PDF를 언어별로 제공하는 제조사라면 이 방법을 기억해 둘 만합니다.

상호 참조(양방향) 규칙

hreflang의 가장 중요한 조건은 상호 참조입니다. 구글은 A 페이지가 B를 가리키면 B도 반드시 A를 가리켜야 하며, 그렇지 않으면 해당 선언이 무시되거나 잘못 해석될 수 있다고 명시합니다(Google Search Central).

여기서 자기 자신도 목록에 포함해야 합니다. 각 언어 버전은 자신을 포함한 모든 언어 버전을 나열해야 하며, 주소는 프로토콜을 포함한 완전한 절대 주소여야 합니다. `//example.com/ja/` 같은 프로토콜 생략 표기나 상대 경로는 인정되지 않습니다.

세 언어 사이트라면 각 페이지가 세 줄의 선언을 갖게 됩니다. 한국어 페이지도, 일본어 페이지도, 영어 페이지도 동일하게 세 줄을 출력해야 관계가 닫힙니다.

선언 위치	형식 요약	사용 조건
HTML head	link 요소에 rel, hreflang, href 지정	HTML 문서 전용, 가장 일반적
HTTP 헤더	Link 응답 헤더에 동일 정보 기술	PDF 등 비HTML 파일
XML 사이트맵	url 항목마다 xhtml:link 자식 요소 추가	페이지 수가 많을 때 관리 유리

x-default의 쓰임

`x-default`는 사용자의 브라우저 언어 설정이 어느 언어판과도 맞지 않을 때 보여 줄 대체 페이지를 지정하는 예약값입니다. 구글은 이 값이 언어 선택 페이지를 위해 설계됐으며 그런 페이지에서 가장 잘 작동한다고 설명합니다(Google Search Central Blog, How x-default can help you).

의무 항목은 아닙니다. 다만 한국어·일본어·영어 세 언어만 운영하는 사이트에 독일어 사용자가 접근했을 때 어느 화면을 우선 보여 줄지 스스로 정해 두는 편이 낫습니다. 국내 기업 사이트라면 영어판을 대체값으로 지정하는 경우가 많습니다.

언어 선택 화면을 따로 만들지 않았다면 대표 언어판 하나를 대체값으로 지정하면 됩니다. 값을 지정하지 않았다고 해서 색인이 거부되지는 않습니다.

언어 코드 표기법: ja, en, ko와 지역 결합

언어 코드는 ISO 639-1 두 글자를 씁니다. 일본어는 `ja`, 영어는 `en`, 한국어는 `ko`입니다. 일본을 뜻하는 `jp`나 한국을 뜻하는 `kr`은 국가 코드이므로 언어 자리에 단독으로 넣으면 값이 인정되지 않습니다.

지역을 함께 지정할 때만 국가 코드를 덧붙입니다. 형식은 `en-US`, `en-GB`, `ja-JP`처럼 언어 코드 뒤에 하이픈과 ISO 3166-1 알파-2 국가 코드를 붙이는 것입니다. 국가 코드만 단독으로 쓰는 표기는 허용되지 않습니다.

지역 결합은 필요할 때만 쓰는 편이 좋습니다. 미국과 영국 사용자에게 다른 가격을 보여 주는 상거래 사이트라면 `en-US`와 `en-GB`를 나누는 의미가 있지만, 영어 콘텐츠가 한 벌뿐인 기업 소개 사이트에서 굳이 지역을 붙이면 관리 지점만 늘어납니다.

언어만: `ko`, `ja`, `en` — 언어가 같으면 지역과 무관하게 매칭

언어+지역: `ja-JP`, `en-US`, `en-SG` — 언어와 지역이 모두 맞을 때 우선 매칭

대체값: `x-default` — 어느 조합과도 맞지 않을 때의 기본 화면

잘못된 표기: `jp`, `kr`, `en_us`(밑줄), `ja-jp` 대소문자 혼용은 피하는 편이 안전

WPML로 한국어·일본어·영어 사이트를 구성하는 순서

WPML 기반 3개 언어 사이트는 언어 설정, 콘텐츠 번역, 문자열 번역, 색인 신호 점검 순으로 진행합니다. 이노스톤은 신규 구축에 Bricks Builder, 기존 유지보수 사이트에 Elementor Pro 트랙을 적용하는데, 어느 쪽이든 WPML 설정 순서 자체는 동일합니다.

순서를 지키는 이유는 되돌리기 비용 때문입니다. 콘텐츠를 먼저 번역한 뒤에 주소 형식을 바꾸면 이미 색인된 주소가 전부 무효가 됩니다.

언어 추가와 주소 형식 지정

설치 직후 마법사에서 사이트의 기본 언어를 한국어로 지정하고, 추가 언어로 일본어와 영어를 선택합니다. 그다음 화면에서 주소 형식을 고르게 되는데, 이 단계가 사실상 되돌리기 어려운 결정 지점입니다.

기본 언어에도 디렉터리를 붙일지 결정해야 합니다. `example.com/ko/` 형태로 기본 언어까지 경로를 부여하면 세 언어가 대칭 구조가 되어 관리가 단순해지지만, 기존 한국어 주소 전부에 리디렉션이 필요합니다. 운영 중인 사이트에 언어를 얹는 경우라면 기본 언어는 루트에 두는 편이 안전합니다.

번역 편집기와 문자열 처리

WPML은 글·페이지 본문을 번역 편집기에서 다루고, 테마·플러그인이 출력하는 고정 문구는 별도의 문자열 번역 화면에서 다룹니다. 이 구분을 모르면 본문은 일본어인데 버튼과 폼 라벨만 한국어로 남는 상태가 됩니다.

WPForms로 만든 문의 폼이 대표적입니다. 필드 라벨, 오류 메시지, 발송 완료 문구가 모두 문자열 영역에 속하므로 본문 번역과는 별개로 처리해야 합니다.

메뉴와 위젯도 마찬가지입니다. 언어별로 메뉴 항목 구성이 달라야 하는 경우가 흔한데, 일본 시장용 페이지가 국내용보다 적다면 메뉴를 그대로 복제하지 말고 언어별로 재구성하는 편이 이탈을 줄입니다.

사이트맵과 색인 신호 점검

정규 주소(canonical) 값도 함께 봅니다. 일본어 페이지의 정규 주소가 한국어 원문을 가리키고 있으면 일본어판은 색인 대상에서 밀려납니다. 언어판마다 자기 자신을 정규 주소로 갖는 것이 정상 상태입니다.

자동 리디렉션이 색인을 망가뜨리는 이유

접속자의 IP나 브라우저 언어를 보고 다른 언어판으로 강제 이동시키는 처리는 크롤링을 가로막습니다. 구글 크롤러는 주로 미국 IP에서 접근하고 언어 설정을 특정하지 않은 상태로 요청하는 경우가 많아, 국가·언어 기반 강제 이동이 걸려 있으면 일부 언어판을 아예 만나지 못합니다.

사용자 경험 측면에서도 손해입니다. 일본에 출장 중인 한국인 담당자가 한국어 페이지 링크를 받고 눌렀는데 일본어 화면으로 튕기면, 원하는 정보에 도달하지 못한 채 이탈합니다.

권장되는 방식은 안내와 선택입니다. 접속 정보에 따라 "일본어 페이지로 이동하시겠습니까"를 배너로 제안하고, 이동 여부는 사용자가 누르게 하는 구조가 색인과 경험을 모두 지킵니다. 구글도 로케일 적응형 처리에 관한 문서에서 크롤러가 다양한 조건으로 접근할 수 있음을 전제로 설계하라고 안내합니다.

선택 결과를 쿠키에 저장하되, 저장된 값이 크롤러 요청에는 적용되지 않도록 캐시 계층을 분리해야 합니다. Breeze 같은 캐시 플러그인을 쓰는 환경이라면 언어별 캐시 키가 분리돼 있는지 반드시 확인하는 항목입니다.

번역 품질과 중복 콘텐츠 판정

언어가 다른 페이지는 서로 중복 콘텐츠로 판정되지 않습니다. 구글은 여러 언어로 같은 내용을 제공하는 것 자체를 문제 삼지 않으며, hreflang은 순위를 낮추기 위한 장치가 아니라 적합한 버전을 고르기 위한 신호로 쓰입니다.

문제가 되는 지점은 다른 곳입니다. 같은 언어로 거의 동일한 페이지를 여러 주소에 두는 경우, 예를 들어 `en-US`와 `en-GB` 페이지의 문구가 완전히 같다면 검색엔진은 둘 중 하나만 골라 노출합니다. 지역을 나눴다면 통화, 배송 조건, 연락처처럼 실제로 다른 정보가 담겨야 분리가 의미를 갖습니다.

기계 번역을 손보지 않고 대량 발행하는 것은 별개의 위험입니다. 구글의 스팸 정책은 사용자에게 도움을 주려는 의도 없이 자동 생성된 텍스트를 대량으로 만드는 행위를 문제로 봅니다. 번역 자체가 금지되는 것이 아니라, 검수 없이 쏟아 내는 방식이 문제입니다.

현장에서 체감하는 차이는 용어와 표기입니다. 일본어판에서 회사 형태 표기, 주소 표기 순서, 금액 단위, 존대 수준이 어색하면 체류 시간이 눈에 띄게 짧아집니다. 이노스톤이 일본어 페이지를 넘길 때 원어민 감수를 최소 1회 거치도록 공정을 잡아 둔 이유가 여기에 있습니다.

설정 후 검증 절차

hreflang 설정은 배포 직후 반드시 실측으로 확인합니다. 브라우저에서 소스를 열어 선언 줄이 몇 개인지 세는 것이 가장 빠른 1차 점검입니다.

각 언어판 소스에서 선언 개수가 운영 언어 수와 일치하는지 확인합니다.

선언에 포함된 주소를 하나씩 열어, 그 페이지도 같은 목록을 출력하는지 대조합니다.

주소가 모두 절대 경로이며 프로토콜과 호스트까지 포함하는지 확인합니다.

각 페이지의 정규 주소가 자기 자신을 가리키는지 확인합니다.

서치콘솔 URL 검사로 언어판 개별 주소를 조회해 색인 상태와 대표 주소를 확인합니다.

사이트맵을 제출한 뒤 언어별 색인 페이지 수 추이를 2~4주 단위로 비교합니다.

리디렉션 점검도 빠뜨리지 않습니다. 시크릿 창에서 언어판 주소를 직접 입력했을 때 다른 언어로 튕기지 않는지, 그리고 캐시가 초기화된 상태에서 동일한 결과가 나오는지 두 번 확인합니다.

다국어 사이트에서 자주 나타나는 오류 4가지

배포 후 발견되는 문제는 대체로 네 가지 유형으로 수렴합니다. 이노스톤이 유지보수 중인 다국어 사이트에서 반복적으로 마주친 순서대로 정리하면 다음과 같습니다.

첫째, 한쪽 방향만 선언된 경우입니다. 한국어 페이지에는 일본어판 주소가 있는데 일본어 페이지에는 한국어판 주소가 없으면 관계가 성립하지 않습니다. 번역을 나중에 붙인 페이지에서 특히 자주 생깁니다.

둘째, 국가 코드를 언어 자리에 넣은 경우입니다. `jp`나 `kr`은 언어 코드가 아니어서 해당 선언 자체가 무효 처리됩니다.

셋째, 번역이 없는 페이지까지 목록에 넣은 경우입니다. 존재하지 않는 주소를 가리키면 404가 반환되고 선언은 무시됩니다. 번역이 완료된 페이지끼리만 묶는 것이 원칙입니다.

넷째, 정규 주소와 언어 선언이 충돌하는 경우입니다. 일본어 페이지가 한국어 원문을 정규 주소로 가리키면서 동시에 자신을 일본어판으로 선언하면 신호가 서로를 부정합니다. 플러그인 두 개가 각각 정규 주소를 출력하는 환경에서 흔히 발생합니다.

핵심 요약

다국어 홈페이지 SEO의 뼈대는 언어별 고유 주소와 상호 참조가 닫힌 hreflang 선언입니다. 주소 구조는 디렉터리·서브도메인·별도 도메인 중 조직 형태와 시장 전략에 맞는 하나를 골라 끝까지 유지해야 하며, 중간 변경은 색인 손실을 동반합니다. 언어 코드는 ISO 639-1 두 글자를 쓰고 지역이 필요할 때만 `en-US` 형식으로 결합하며, 대체 화면이 필요하면 `x-default`를 지정합니다. IP·브라우저 언어에 따른 강제 이동은 크롤러의 접근을 막으므로 배너 제안 방식으로 바꾸는 편이 안전합니다. 배포 후에는 선언 개수, 상호 참조, 절대 경로, 정규 주소, 색인 상태를 순서대로 실측해 신호가 서로 어긋나지 않는지 확인합니다.

F.A.Q

번역본이 아직 완성되지 않은 페이지도 언어 선언 목록에 넣어야 하나요?

넣지 않는 것이 원칙입니다. 존재하지 않는 주소를 선언하면 크롤러가 404를 받고 해당 선언 전체를 무시할 수 있습니다. 번역이 실제로 발행된 페이지끼리만 묶고, 새 번역이 공개되는 시점에 목록을 갱신하는 방식이 안전합니다.

새 언어를 붙인 뒤 검색 결과에 잡히기까지 얼마나 걸리나요?

사이트 규모와 크롤링 빈도에 따라 다르며 며칠에서 몇 주까지 편차가 큽니다. 사이트맵 제출과 URL 검사 요청을 병행하면 초기 수집이 앞당겨지는 경향이 있습니다. 색인 페이지 수 추이는 2~4주 간격으로 비교해야 변화가 의미 있게 읽힙니다.

다국어 운영에 추가로 드는 비용은 어떤 항목인가요?

번역·감수 인건비, 언어별 문자열 유지 공수, 인프라 증설 세 항목이 주를 이룹니다. 별도 도메인 구조를 택하면 도메인 갱신비와 인증서 비용이 언어 수만큼 늘어납니다. 디렉터리 구조는 이 중 인프라 항목이 거의 발생하지 않아 초기 부담이 가장 작습니다.

잘못 지정한 hreflang을 구글이 무시하면 어떻게 되나요?

언어 관계 신호만 사라지고 페이지 자체가 색인에서 제거되지는 않습니다. 다만 사용자의 언어와 다른 버전이 검색 결과에 노출될 확률이 높아집니다. 선언이 무시된 상태는 서치콘솔의 개별 주소 검사와 소스 대조로 확인할 수 있습니다.

일본 시장만 노린다면 .jp 도메인이 유리한가요?

현지 신뢰 형성이 최우선이라면 유리한 선택입니다. 국가 코드 최상위 도메인은 그 자체로 국가 신호를 전달하기 때문입니다. 다만 새 도메인은 권위를 처음부터 쌓아야 하므로, 기존 사이트의 축적된 신호를 활용해야 하는 상황에서는 손해가 될 수 있습니다.

언어 전환 버튼은 어디에 두는 편이 좋나요?

헤더 우측 상단처럼 모든 페이지에서 같은 위치에 노출되는 자리가 일반적입니다. 국기 아이콘만 쓰기보다 언어명을 해당 언어 표기로 병기하는 편이 오인을 줄입니다. 전환 시 같은 내용의 대응 페이지로 이동하도록 연결해야 하며, 무조건 첫 화면으로 보내면 이탈이 늘어납니다.

국가별 가격이 다른 상품 페이지에도 같은 규칙을 적용하나요?

적용합니다. 이때는 언어만 지정하는 대신 지역을 결합한 값을 써서 통화와 배송 조건이 다른 버전을 구분해야 합니다. 문구까지 동일하면 검색엔진이 한 버전만 골라 노출하므로, 가격·배송·연락처 등 실제 차이가 페이지에 드러나야 분리가 유지됩니다.

서치콘솔에 언어 버전을 각각 등록해야 하나요?

주소 구조에 따라 달라집니다. 디렉터리 구조라면 도메인 속성 하나로 전체가 포함되고, 서브도메인이나 별도 도메인 구조라면 각각을 별도 속성으로 등록해야 데이터가 분리돼 보입니다. 도메인 속성으로 등록하면 하위 서브도메인이 함께 집계됩니다.

이미지 안에 들어간 글자는 번역 대상에서 빠지나요?

빠집니다. 이미지에 새겨진 텍스트는 번역 편집기가 다루지 못하므로 언어별 이미지 파일을 따로 제작해야 합니다. 배너와 인포그래픽에 문구를 새기는 관행이 다국어 전환 시 가장 큰 재작업 요인이 됩니다.

일부 페이지만 다국어로 만들어도 문제가 없나요?

문제없습니다. 회사 소개와 제품 페이지만 번역하고 공지사항은 한국어로 두는 구성도 흔합니다. 다만 번역된 페이지끼리만 언어 관계를 선언하고, 번역이 없는 페이지에는 아무 선언도 넣지 않아야 신호가 어긋나지 않습니다.

기계 번역 결과를 그대로 올리면 순위에 손해인가요?

검수 없이 대량 발행하면 손해가 될 수 있습니다. 구글 스팸 정책은 사용자에게 도움을 주려는 의도 없이 자동 생성된 텍스트를 대량으로 만드는 행위를 문제로 규정합니다. 초벌을 기계로 만들고 사람이 용어·수치·법적 표기를 손보는 방식은 이 기준에 저촉되지 않습니다.

x-default는 반드시 넣어야 하는 값인가요?

필수는 아닙니다. 지정하지 않아도 색인과 노출은 정상적으로 이뤄집니다. 다만 운영 중인 언어와 맞지 않는 사용자가 유입될 때 어느 화면을 보여 줄지 스스로 정해 두면 첫 화면의 이탈률을 관리하기 쉬워집니다.

참고자료

1. Google Search Central – Localized Versions of your Pages – https://developers.google.com/search/docs/specialty/international/localized-versions

2. Google Search Central – Managing Multi-Regional and Multilingual Sites – https://developers.google.com/search/docs/specialty/international/managing-multi-regional-sites

3. Google Search Central Blog – How x-default can help you – https://developers.google.com/search/blog/2023/05/x-default

4. Google Search Central – How Google Crawls Locale-Adaptive Pages – https://developers.google.com/search/docs/specialty/international/locale-adaptive-pages

5. WPML – Language URL format options – https://wpml.org/documentation/getting-started-guide/language-setup/language-url-options/

6. WPML – How to use WPML with different domains per language – https://wpml.org/documentation/getting-started-guide/language-setup/language-url-options/how-to-use-wpml-with-different-domains-per-language/

7. WPML – Language Setup – https://wpml.org/documentation/getting-started-guide/language-setup/

태그: 다국어 SEO, hreflang, WPML, URL 구조, 국제화