한국어 영어 페이지를 섞어 두지 마세요

미국에서 한인 고객과 로컬 고객을 함께 받는 사장님들 사이트를 보다 보면, 첫 화면에서는 그럴듯한데 막상 문의 흐름이 자꾸 꼬이는 경우가 많습니다. 상단에는 한국어와 영어가 섞여 있고, 서비스 설명은 한글인데 버튼은 영어로 나가고, 어떤 페이지는 번역 버튼을 누를 때마다 주소는 그대로입니다. 사장님 입장에서는 "둘 다 보이면 된 것 아닌가" 싶지만, 실제로는 고객도 헷갈리고 검색엔진도 페이지 목적을 한 번에 읽기 어렵습니다.

손님은 같은 페이지를 다르게 읽습니다

한국어 고객이 보는 정보와 영어 고객이 찾는 정보는 생각보다 다릅니다. 한국어 고객은 상담 방식, 카카오톡이나 문자 가능 여부, 한인 업종 경험 같은 신호를 먼저 확인하는 경우가 많습니다. 반대로 영어 고객은 서비스 범위, 가격 문의 방식, 예약 절차, 영업지역 같은 기본 구조를 더 빠르게 찾습니다.

문제는 이 두 흐름을 한 화면 안에 억지로 포개 놓을 때 생깁니다. 한 문단 안에 한국어와 영어 문장을 섞어 넣거나, 한글 페이지에서 브라우저 번역만 믿고 넘어가면 읽는 리듬이 깨집니다. 문의 버튼까지 가기 전에 머뭇거리는 시간이 길어지고, 결국 전화로 다시 설명해야 하는 일이 늘어납니다. 검색 유입도 비슷합니다. 페이지 하나가 누구를 위한 것인지 흐리면, 검색 결과에서 제목과 설명이 선명하게 잡히기 어렵습니다.

한 문장으로 정리하면 이렇습니다. 한국어 고객용 페이지와 영어 고객용 페이지는 같은 디자인을 써도 되지만, 같은 한 URL 안에서 언어를 섞는 방식은 운영과 검색 모두에 불리합니다.

번역 버튼만으로는 해결되지 않는 이유

여기서 잠깐, 이런 의문이 드실 수 있습니다. "요즘은 자동 번역도 잘 되는데 굳이 페이지를 나눠야 하나요?" 실무에서는 이 질문이 정말 자주 나옵니다. 답은 단순합니다. 자동 번역 자체가 문제라기보다, 검색엔진과 고객이 안정적으로 이해할 수 있는 구조가 아니면 성과 관리가 어려워진다는 점이 핵심입니다.

Google Search Central은 언어별 페이지에 서로 다른 URL을 두는 방식을 권장합니다. 쿠키나 브라우저 설정만으로 언어를 바꾸는 구조보다, 언어별 고유 주소를 두고 hreflang 같은 신호로 관계를 알려 주는 편이 검색 결과 연결에 유리하다는 뜻입니다. 또 Google은 언어별로 내용이 바뀌는 locale-adaptive 페이지를 운영하면, Googlebot이 모든 변형을 안정적으로 크롤링하지 못할 수 있다고 안내합니다. 기본적으로 미국에서 접근하는 크롤러가 많고 Accept-Language 헤더도 항상 보내지지 않기 때문입니다.

즉, 사장님이 한국어와 영어를 한 주소 안에서 조건부로만 보여주면 사람은 대충 볼 수 있어도 검색엔진은 놓칠 여지가 생깁니다. 반대로 /services/web-design과 /en/services/web-design처럼 언어별 경로를 나누면, 고객도 주소만 보고 어느 버전인지 이해하고 운영자도 성과를 따로 볼 수 있습니다.

페이지를 나누면 문의 품질이 달라집니다

페이지를 나누는 목적은 번역을 예쁘게 보이게 하는 데 있지 않습니다. 문의의 질을 올리고, 설명 반복을 줄이고, 광고와 검색 흐름을 정리하는 데 있습니다.

예를 들어 치과, 미용실, 회계사무소, 리페어숍처럼 설명이 중요한 업종은 같은 서비스라도 강조점이 다릅니다. 한국어 페이지에서는 "처음 상담은 어떻게 진행되는지", "보험이나 서류 안내를 한국어로 받을 수 있는지" 같은 문장이 더 중요할 수 있습니다. 영어 페이지에서는 "service area", "appointment process", "request a quote"처럼 행동으로 바로 이어지는 구조가 더 효율적일 수 있습니다.

이때 중요한 원칙이 하나 있습니다. 언어만 바꾸고 핵심 내용이 비어 있으면 안 됩니다. Google 문서도 본문이 번역되지 않고 템플릿만 바뀐 페이지는 제대로 된 지역화 버전으로 보기 어렵다고 설명합니다. 결국 한국어 페이지도 독립적으로 읽혀야 하고, 영어 페이지도 독립적으로 문의를 만들 수 있어야 합니다.

사장님이 기억하실 포인트는 이것입니다. 이중언어 사이트의 핵심은 "번역 기능"이 아니라 "언어별로 목적이 분명한 페이지 세트"입니다.

먼저 손봐야 할 최소 구조는 네 가지입니다

그렇다면 어디서부터 시작해야 할까요. 처음부터 모든 페이지를 두 언어로 다시 만드는 것보다, 문의와 직결되는 페이지부터 나누는 편이 훨씬 현실적입니다.

첫째, 홈이 아니라 핵심 서비스 페이지부터 분리해야 합니다. 실제 문의는 대개 서비스 상세 페이지에서 결정됩니다. 웹사이트 제작, 예약, 상담, 견적 같은 핵심 페이지가 한글과 영어로 각각 있어야 합니다.

둘째, 언어 전환 버튼이 단순히 화면 번역이 아니라 대응 페이지로 이동해야 합니다. 한국어 서비스 상세를 보고 있다면 영어 버튼을 눌렀을 때 영어 홈으로 보내지 말고, 같은 주제의 영어 상세 페이지로 이동해야 합니다.

셋째, 각 페이지의 제목, 설명, 본문 첫 문장, 버튼 문구를 언어별로 따로 써야 합니다. 메타데이터만 번역해 두고 본문은 뒤섞여 있으면 고객 경험도 어색하고, 검색 스니펫도 흔들릴 수 있습니다.

넷째, 언어별 페이지 관계를 기술적으로 알려 줘야 합니다. Google은 hreflang과 사이트맵 같은 방법으로 언어 버전 관계를 명시할 수 있다고 안내합니다. 한 문장으로 말하면, "이 한국어 페이지의 영어 짝은 여기입니다"를 코드나 사이트맵으로 알려 주는 작업입니다.

사장님들이 가장 많이 묻는 부분이 이겁니다

실제로 현장에서 사장님들이 가장 많이 묻는 부분이 이겁니다. "페이지를 두 벌로 만들면 중복 콘텐츠 취급을 받지 않나요?" 이 질문에는 조금 안심하셔도 됩니다. Google 문서에 따르면, 본문이 실제로 번역된 다국어 페이지는 단순 중복으로 보지 않습니다. 오히려 언어별 페이지가 있는데도 관계를 명확히 표시하지 않거나, 본문은 그대로 두고 메뉴와 푸터만 바꾸는 쪽이 더 애매합니다.

또 하나 많이 나오는 질문은 "영어 페이지는 아직 약한데 먼저 만들어도 되나요?"입니다. 제 답은 늘 같습니다. 얇아도 구조가 분명한 한 페이지가, 모든 언어를 한 장에 몰아넣은 긴 페이지보다 운영하기 쉽습니다. 다만 얇다는 말은 정보가 적다는 뜻이지, 번역기 문장을 붙여 넣는다는 뜻은 아닙니다. 최소한 서비스 설명, 대상 고객, 문의 방식, 지역 범위, 다음 행동은 각각 언어로 자연스럽게 읽혀야 합니다.

그리고 언어 선택 페이지를 따로 둘지 묻는 경우도 있습니다. 선택 페이지 자체는 나쁠 이유가 없습니다. 다만 고객이 그 페이지에서 멈추지 않게 해야 합니다. Google은 x-default 같은 fallback 개념도 안내합니다. 다시 말해, 특정 언어가 딱 맞지 않을 때 보내 줄 기본 페이지는 둘 수 있지만, 실제 서비스 설명은 결국 언어별 상세 페이지가 맡아야 합니다.

사장님이 오늘 바로 확인할 리스트

오늘 해야 할 일은 거창하지 않습니다. 문의가 가장 많이 들어오는 서비스 페이지 한 장만 골라 한국어와 영어 버전을 분리해 보시면 됩니다. 그다음 언어 전환 버튼이 서로의 짝 페이지로 오가는지 확인하고, 제목과 첫 문장, 버튼 문구만 다시 써도 체감이 꽤 큽니다.

사이트를 키우는 일은 페이지를 많이 만드는 일보다, 고객이 자기 언어로 덜 망설이게 만드는 일에 더 가깝습니다. 한국어와 영어를 한곳에 욱여넣는 대신, 각 고객이 편하게 읽고 바로 움직일 수 있게 길을 나눠 두십시오. 그 한 번의 정리가 문의 품질과 운영 효율을 같이 바꿉니다.