7편. 다국어 사이트 런칭 전 체크리스트: hreflang부터 크로스 브라우저 테스트까지
URL 구조를 잡고 언어 선택 UI를 설계했다. CMS와 번역 도구를 고르고 기술 설정을 마치고 템플릿도 완성했다. 운영 구조까지 설계했다. 이제 출시 직전이다. 잠깐, 여기서 멈춰야 한다. 출시 전 테스트를 건너뛰면 독자가 직접 오류를 발견한다. 기사가 깨진 채 검색에 노출되고 SEO 작업이 허공으로 사라진다. 출시 후 수정은 출시 전 점검보다 항상 비용이 크다.
이 편은 다국어 사이트 출시 전 반드시 확인해야 할 테스트 항목을 6개 영역으로 나눠 정리한다. 항목마다 체크박스로 구성했다. 출력해서 실제 점검에 사용해도 좋다.
다국어 웹사이트 구조와 기술 설계
2편. 언어 선택 UI는 설계방법
3편. CMS와 번역 도구 선택 기준
5편. 다국어 사이트 기술 체크리스트
7편. 구축 전 반드시 확인할 테스트 항목←현재글
테스트 영역 1. SEO 기술 설정 검증
출시 전 가장 먼저 확인해야 할 영역이다. 설정 오류가 하나만 있어도 수개월 치 SEO 작업이 무의미해진다.
hreflang 검증
□ 모든 언어 페이지가 서로를 hreflang으로 상호 참조하는가?
□ x-default가 지정되어 있는가?
□ 언어 코드가 ISO 표준을 따르는가? (ko, en, ja, zh-CN 등)
□ hreflangchecker.com에 URL을 입력해 오류 항목이 없는가?
hreflang 오류는 눈에 잘 보이지 않는다. 사이트가 정상적으로 보여도 구글이 잘못된 언어 버전을 엉뚱한 나라 독자에게 노출할 수 있다. 반드시 전용 도구로 검증해야 한다.
canonical 검증
□ 각 언어 페이지가 자기 자신을 canonical로 가리키는가?
□ 한국어 페이지가 영어 페이지를 canonical로 가리키는 경우가 없는가?
□ 브라우저에서 페이지 소스를 열어 <link rel="canonical"> 태그를 직접 확인했는가?
사이트맵 및 robots.txt 검증
□ 언어별 사이트맵이 생성되어 있는가?
□ robots.txt에 각 사이트맵 URL이 명시되어 있는가?
□ robots.txt에서 언어 디렉터리가 실수로 차단되지 않았는가?
□ Google Search Console의 robots.txt 테스터로 확인했는가?
□ 언어별 사이트맵을 Google Search Console에 제출했는가?
메타 태그 검증
□ 각 언어 페이지의 <title>이 해당 언어로 작성되어 있는가?
□ 각 언어 페이지의 <meta description>이 해당 언어로 작성되어 있는가?
□ 이미지 alt 태그가 해당 언어로 작성되어 있는가?
□ <html lang=""> 속성이 각 언어에 맞게 설정되어 있는가?
테스트 영역 2. 언어 전환 기능 검증
언어 선택기가 제대로 작동하지 않으면 독자가 원하는 언어를 찾지 못하고 이탈한다.
□ 언어 전환 버튼이 헤더에서 쉽게 보이는가?
□ 언어를 전환했을 때 URL이 올바르게 바뀌는가? (/ko/ → /en/)
□ 언어 전환 후 같은 기사의 해당 언어 버전으로 이동하는가? (엉뚱한 페이지로 가지 않는가?)
□ 번역이 없는 기사에서 언어를 전환했을 때 적절한 안내 페이지로 이동하는가? (404가 뜨지 않는가?)
□ 선택한 언어가 쿠키로 저장되어 재방문 시 유지되는가?
□ 모바일에서도 언어 선택기가 쉽게 찾아지고 작동하는가?
테스트 영역 3. 콘텐츠·번역 품질 검증
번역 품질은 독자 신뢰도에 직결된다. 특히 뉴스 기사는 단어 하나가 의미를 바꾼다.
텍스트 품질
□ 기계 번역 초안을 그대로 올린 기사가 없는가?
□ 모든 번역 기사가 원어민 또는 해당 언어 능숙자의 교열을 거쳤는가?
□ 고유명사(인명, 지명, 기관명)가 올바르게 번역 또는 표기되었는가?
□ 날짜 형식이 언어별 관행에 맞게 표시되는가? (미국: Jan 2, 2025 / 한국: 2025년 1월 2일)
□ lorem ipsum 같은 더미 텍스트가 남아 있지 않은가?
UI 텍스트
□ '더 보기', '댓글', '공유하기' 등 인터페이스 텍스트가 모두 번역되어 있는가?
□ 에러 메시지, 폼 안내 문구가 해당 언어로 되어 있는가?
□ 404 페이지가 각 언어로 제공되는가?
□ 이메일 구독 확인 메시지가 해당 언어로 되어 있는가?
테스트 영역 4. 레이아웃·시각적 검증
텍스트 팽창이나 폰트 문제로 레이아웃이 깨지는 경우를 사전에 잡아야 한다.
텍스트 팽창 확인
□ 헤드라인이 독일어, 프랑스어처럼 긴 언어에서 잘리거나 줄 바꿈이 부자연스럽지 않은가?
□ 내비게이션 메뉴가 번역된 텍스트에서 레이아웃을 유지하는가?
□ 버튼 텍스트가 번역 후 버튼 영역 안에 들어가는가?
□ 사이드바, 카드, 캡션 등 좁은 공간에서 텍스트가 넘치지 않는가?
폰트·문자 렌더링
□ CJK 언어(한국어, 일본어, 중국어) 페이지에서 글자가 깨지지 않는가?
□ 특수 문자(ü, ñ, é, ç, ø 등)가 올바르게 표시되는가?
□ 폰트가 해당 언어에서 가독성이 있는가? (라틴 폰트가 한글에 적용되지 않았는가?)
□ 페이지 소스에서 <meta charset="UTF-8">이 <head> 최상단에 있는가?
RTL 언어 (아랍어·히브리어 지원 시)
□ <html dir="rtl">이 RTL 언어 페이지에 적용되어 있는가?
□ 내비게이션, 사이드바가 올바르게 거울 반전되는가?
□ 방향성 아이콘(화살표 등)이 RTL 방향으로 반전되어 있는가?
□ 숫자, URL, 이메일 주소가 LTR 방향으로 표시되는가? (RTL 문장 안에서도)
테스트 영역 5. 기능·기술 검증
언어와 관계없이 사이트의 기술적 기능이 모든 언어판에서 작동해야 한다.
링크·내비게이션
□ 모든 내부 링크가 해당 언어판 URL로 연결되는가? (한국어판 링크가 영어판으로 가지 않는가?)
□ 깨진 링크(404)가 없는가? Broken Link Checker 도구로 검사했는가?
□ 언어별 홈페이지, 카테고리 페이지, 기사 페이지 URL이 모두 정상 작동하는가?
폼·입력 기능
□ 뉴스레터 구독 폼이 각 언어에서 정상 제출되는가?
□ 검색 기능이 해당 언어 문자로 검색했을 때 올바른 결과를 반환하는가?
□ 댓글 기능(사용 시)이 각 언어 문자 입력을 지원하는가?
□ UTF-8 인코딩이 설정되어 있어 CJK, 아랍어, 키릴 문자가 DB에 올바르게 저장되는가?
성능
□ PageSpeed Insights에서 언어별 URL을 각각 테스트했는가?
□ LCP 2.5초, INP 200ms, CLS 0.1 기준을 모든 언어판에서 충족하는가?
□ CJK 폰트 파일이 필요한 언어에서만 로드되는가?
□ CDN이 설정되어 있어 글로벌 독자에게 빠르게 콘텐츠가 전달되는가?
테스트 영역 6. 크로스 브라우저·기기 검증
같은 언어라도 브라우저와 기기에 따라 렌더링이 다를 수 있다.
브라우저 테스트
언어별로 아래 브라우저에서 최소 한 번씩 확인한다.
□ Chrome (데스크톱·모바일)
□ Safari (맥·iOS)
□ Firefox
□ Samsung Internet (안드로이드 사용자 비중이 높은 아시아 언어 필수)
특히 한국어, 일본어, 중국어 페이지는 Samsung Internet에서 한 번 더 확인하는 것이 좋다. 아시아 시장에서 점유율이 높기 때문이다.
기기 테스트
□ iOS 기기(아이폰)에서 언어 전환과 폰트 렌더링을 확인했는가?
□ 안드로이드 기기에서 CJK 폰트가 올바르게 표시되는가?
□ 태블릿 화면 크기에서 레이아웃이 깨지지 않는가?
□ 화면 크기 320px(구형 스마트폰 기준)에서 레이아웃이 유지되는가?
무료 도구 BrowserStack의 기본 플랜이나 Chrome DevTools의 Device Mode로 다양한 기기를 시뮬레이션할 수 있다.
무료 테스트 도구 정리
| 도구 | 용도 |
| hreflangchecker.com | hreflang 오류 진단 |
| Google Search Console | 색인 상태, robots.txt 오류, hreflang 경고 |
| PageSpeed Insights | Core Web Vitals 언어별 점검 |
| W3C Validator | HTML 오류 검증 |
| Broken Link Checker (온라인) | 깨진 링크 일괄 검사 |
| Chrome DevTools | 레이아웃, 폰트 렌더링, 모바일 시뮬레이션 |
| Google Rich Results Test | 스키마 마크업 유효성 검사 |
모두 무료다. 비용 없이 대부분의 기술 오류를 잡아낼 수 있다.
출시 전 최종 단계: 스테이징 환경에서 테스트하라
위 항목들을 실제 운영 서버(Production)에서 테스트하면 안 된다. 오류를 수정하는 동안 실제 독자에게 깨진 화면이 노출되기 때문이다.
워드프레스를 쓴다면 스테이징 환경을 만드는 것이 좋다. 대부분의 호스팅 서비스(SiteGround, WP Engine, Cloudways 등)는 클릭 몇 번으로 스테이징 환경을 제공한다. 스테이징에서 모든 테스트를 마친 뒤 운영 서버에 배포한다.
스테이징 환경은 noindex 설정을 반드시 해야 한다. 테스트 페이지가 구글에 색인되지 않도록 막는 것이다. 배포 직후 운영 서버에서 noindex가 제거됐는지도 꼭 확인한다.
출시 직후 확인해야 할 항목
출시 후 24~48시간 내에 아래를 점검한다.
□ Google Search Console에서 색인 오류가 새로 발생하지 않았는가?
□ 언어별 Search Console 속성에서 hreflang 경고가 없는가?
□ 구글에 site:example.com/ko/를 검색해 한국어 페이지가 색인됐는가?
□ 실제 해당 언어권 독자 IP에서 접속 테스트를 했는가? (VPN 활용 가능)
□ 구글 애널리틱스(또는 GA4)에서 언어별 트래픽이 집계되는가?
테스트는 비용이 아니라 보험이다
출시 전 테스트에 들이는 하루이틀이 출시 후 몇 주의 수정 작업을 막는다. SEO 오류는 발견하고 수정해도 구글이 재크롤링하기까지 수 주에서 수개월이 걸린다. 그 사이에 잘못된 페이지가 노출된다. 독자 신뢰도도 떨어진다.
테스트는 비용이 아니라 보험이다. 이 체크리스트를 출시 전 하루 동안 팀 전원이 함께 점검하면 대부분의 오류를 막을 수 있다.
시리즈 2. 구조와 기술 설계 완료 | 다음 시리즈 3. 다국어 SEO 1편: 다국어 SEO의 기본 원리 → 다음 글 보기
댓글
댓글 쓰기