회사 소개서비스프로젝트아티클
← Back to Articles직접 하기 번거로우시다면, 정액 요금으로 사이트 등록을 대행해 드립니다.바이두 사이트 등록 대행 보기 →

Baidu 사이트 소유권 확인: HTML 파일, meta 태그, CNAME

Beijing central business district skyline at dusk

Baidu 관련 업무가 하나 떨어졌는데, 가장 먼저 앞을 막는 것이 소유권 확인 화면입니다. 도메인이 내 것이라는 확신이 서기 전까지 Baidu는 사이트맵을 받지 않고, 색인 리포트도 열어 주지 않으며, URL 하나조차 제출하게 두지 않습니다. 증명하는 방법은 세 가지이고 각각 동작이 다릅니다. 실패하는 방식도 Google Search Console에서 익숙해진 것과는 다릅니다.

이 글에서는 세 가지 방법의 구현 세부사항과 확인이 실패하는 흔한 원인, 그리고 터미널에서 각각을 점검하는 방법을 정리합니다.

소유권 확인이 놓인 자리

Baidu의 웹마스터 도구는 百度搜索资源平台(Baidu 검색 리소스 플랫폼)이고, 주소는 ziyuan.baidu.com입니다. 지금도 百度站长(Baidu Zhanzhang)이라는 이름으로 더 자주 불립니다. 사이트를 추가하고 확인 방법을 고르면 Baidu가 도메인에서 무언가를 가져가 관리 권한을 확인합니다. 링크 제출, 사이트맵 업로드, 크롤링 진단은 그 뒤에야 열립니다.

방법을 고르기도 전에 사이트(property) 개념에서 걸려 넘어지는 지점이 두 가지 있습니다.

  • 프로토콜과 호스트도 사이트 식별자의 일부입니다. Baidu에게 https://example.com과 https://www.example.com은 서로 다른 사이트이고, http:// 버전도 또 다른 사이트입니다. canonical URL이 실제로 쓰는 origin을 그대로 등록하십시오. 엉뚱한 쪽을 확인해 두면, 이후에 제출하는 모든 것이 트래픽이 전혀 없는 사이트에 쌓입니다.
  • 가져가는 쪽은 중국 본토입니다. 소유권을 증명하는 대상은 중국 본토에서 공용 인터넷을 통해, 앞을 가로막는 검증 페이지 없이 닿을 수 있어야 합니다. 이 한 가지가 글 끝부분에 나열한 실패 사례 대부분을 설명합니다.

그 전에 계정 문제가 있습니다. 확인 화면에 들어가려면 Baidu 계정이 반드시 필요하고, 가입은 중국 본토 휴대전화 번호로 오는 SMS 확인을 거칩니다. 유럽이나 영국 기업에게는 실질적인 장벽이고, DNS에 반나절을 쏟기 전에 알아 둘 만한 사실입니다. 이 이야기는 마지막에 다시 다룹니다.

방법 1: HTML 확인 파일

가장 많이 쓰는 방법이고, 정적 파일을 배포할 수 있다면 우선 이것을 고르십시오.

Baidu가 사이트마다 파일을 만들어 내려받게 해 줍니다. 이름은 이런 형태입니다.

baidu_verify_codeva-XXXXXXXXXX.html

예전에 추가된 사이트에는 baidu_verify_XXXXXXXXXX.html 형식으로 발급된 것도 있고, 패널에 따라 codeva- 대신 code- 접두사가 붙기도 합니다. 블로그 글을 보고 파일 이름이나 토큰을 짐작해서 만들지 마십시오. Baidu가 주는 파일을 그대로 내려받거나, 패널의 문자열을 한 글자씩 복사하십시오. 파일 내용은 짧고, 보통 토큰 하나뿐입니다.

파일은 등록한 origin의 루트에서 제공되어야 합니다.

https://example.com/baidu_verify_codeva-XXXXXXXXXX.html

하위 디렉터리도 안 되고, 언어 접두사 안쪽도 안 되며, 다른 호스트는 더더욱 안 됩니다.

스택별 위치

| 스택 | 위치 | | --- | --- | | Vite, Create React App, SvelteKit(static), Nuxt | 프로젝트 루트의 public/ 또는 static/ | | Next.js(두 라우터 모두) | public/ | | Hugo, Astro | 각각 static/와 public/ | | Laravel | public/ | | Django | collectstatic이 모으는 static/ 디렉터리, 또는 nginx가 직접 제공하는 위치 | | ASP.NET Core | wwwroot/ | | WordPress | wp-config.php가 있는 웹 루트에 SFTP로 업로드 | | 순수 nginx 또는 Apache | 문서 루트 |

Baidu가 하는 방식 그대로 확인하기

curl -sSI https://example.com/baidu_verify_codeva-XXXXXXXXXX.html
curl -sS  https://example.com/baidu_verify_codeva-XXXXXXXXXX.html

HTTP/2 200, text/html인 content-type, location 헤더 없음, 그리고 본문이 정확히 토큰인 상태여야 합니다. 다음 세 가지 결과가 나오면 아직 끝난 것이 아닙니다.

  • 301 또는 302. 무언가가 경로를 정규화하고 있습니다. 대개는 마지막 슬래시 규칙이거나, 매칭되지 않는 모든 경로를 /en/...으로 보내는 로케일 리디렉션입니다. catch-all보다 앞에 예외를 추가하십시오.
  • 앱 셸을 돌려주는 200. 통과한 것처럼 보이지만 아닌 경우 중 압도적으로 흔한 유형입니다. catch-all 라우트를 둔 SPA는 어떤 경로에도 index.html을 200으로 응답하므로 파일이 존재하는 것처럼 보이지만, 본문은 여러분의 React 마크업입니다. Baidu는 본문을 읽고 토큰이 없으니 거부합니다. 정적 파일을 SPA 폴백보다 먼저 제공하십시오.
  • 배포 후에도 사라지지 않는 404. 대개 CDN이 부정 응답을 캐시한 경우입니다. 그 경로만 정확히 퍼지한 뒤 curl -H 'Cache-Control: no-cache'로 다시 확인하십시오.

확인이 끝난 뒤에도 파일은 저장소에 남겨 두십시오. Baidu는 주기적으로 소유권을 다시 확인하고, 확인 파일을 잃은 사이트는 조용히 패널에서 사라집니다.

방법 2: HTML meta 태그

웹 루트에 파일을 올릴 수는 없지만 템플릿은 고칠 수 있을 때 쓰는 방법으로, 관리형 CMS나 플랫폼 호스팅에서는 이쪽이 보통입니다.

Baidu가 이런 형태의 태그를 줍니다. 홈페이지의 <head>에 넣습니다.

<meta name="baidu-site-verification" content="codeva-XXXXXXXXXX" />

name 속성은 언제나 baidu-site-verification이고, 하이픈까지 정확히 이 철자여야 합니다. content 값은 패널에 나온 토큰입니다.

동작 여부를 가르는 규칙이 세 가지 있습니다.

  1. <head> 안에 있어야 합니다. 파서가 <body>에서 이 태그를 만나면 head는 이미 닫힌 것으로 처리됩니다. head가 아닌 첫 요소 뒤에 주입된 것은 전부 늦습니다.
  2. 서버가 보내는 HTML에 있어야 합니다. view-source:로 열어 보거나, 더 나은 방법으로 curl -sS https://example.com | grep baidu-site-verification을 돌리십시오. DevTools 요소 탭에만 보인다면 하이드레이션 이후 JavaScript가 붙인 것이고, 인정되지 않습니다. 클라이언트 렌더링 React나 Vue 앱이 여기서 막히며, SPA에서 파일 방식이 더 편한 이유이기도 합니다.
  3. 프레임워크를 통과해 살아남아야 합니다. head 관리 라이브러리는 중복을 제거하고 태그를 정리합니다. Next.js는 컴포넌트에 흩어진 <meta> 대신 metadata export에 쓰기를 기대합니다. React Helmet은 provider 밖에서 렌더링된 태그를 버립니다. 일부 CMS 보안 플러그인은 이름을 모르는 meta 태그를 제거합니다. 태그 매니저로는 넣을 수 없습니다. 태그 매니저는 클라이언트에서 실행되기 때문입니다.

프레임워크별 위치는 이렇습니다.

// Next.js App Router, app/layout.js
export const metadata = {
  other: { 'baidu-site-verification': 'codeva-XXXXXXXXXX' },
}

// WordPress, 자식 테마의 functions.php
add_action('wp_head', function () {
  echo '<meta name="baidu-site-verification" content="codeva-XXXXXXXXXX" />' . "\n";
}, 1);

서버 렌더링 사이트라면 charset, viewport 태그 옆 기본 템플릿에 넣어 두고 잊으면 됩니다. Hugo는 layouts/_default/baseof.html, Django는 모든 페이지가 상속하는 기본 템플릿입니다.

방법 3: CNAME 레코드

DNS 방식은 배포 자체가 불가능할 때, 사이트가 손댈 수 없는 장비 뒤에 있을 때, 또는 앞으로의 모든 재배포에서도 확인이 유지되기를 바랄 때 고르는 방법입니다. 문서 하나가 아니라 도메인 전체의 통제권을 증명한다는 차이도 있습니다.

Baidu가 도메인 아래에 만들 임의의 호스트 레이블을 보여 주고, 대상은 Baidu입니다.

abcdef123456.example.com.  3600  IN  CNAME  ziyuan.baidu.com.

대부분의 DNS 패널에서는 존이 자동으로 붙기 때문에 왼쪽 레이블만 입력합니다.

| 항목 | 값 | | --- | --- | | 유형 | CNAME | | 이름 / 호스트 | abcdef123456 | | 값 / 대상 | ziyuan.baidu.com | | TTL | 3600, 테스트 중이라면 패널이 허용하는 최솟값 |

여기서 반복해서 어긋나는 것이 네 가지입니다.

  • 도메인이 두 번 붙습니다. 존이 자동으로 붙는 패널에 abcdef123456.example.com을 입력하면 abcdef123456.example.com.example.com이 만들어집니다. 저장 후 전체 도메인 이름을 보여 주는 패널이라면 반드시 다시 읽어 보십시오.
  • 대상 끝의 점. 원본 존 파일에서 마지막 점이 빠진 ziyuan.baidu.com은 존에 대한 상대 이름으로 해석되어 ziyuan.baidu.com.example.com이 됩니다. 패널은 알아서 처리해 주지만, named 설정이나 Terraform 파일은 그렇지 않습니다.
  • 레코드 앞에 프록시가 있습니다. Cloudflare에서 프록시가 켜진(주황색 구름) 레코드는 외부에서 더 이상 CNAME으로 해석되지 않습니다. 권위 응답이 Cloudflare의 A 레코드로 바뀌기 때문입니다. 확인용 레코드는 DNS only로 두십시오.
  • TTL보다 짧게 기다립니다. 리졸버가 그 이름에 대한 부정 응답을 이미 캐시했다면 예전 TTL이 적용됩니다. 패널에 적힌 값이 아니라 바깥에서 실제로 보이는 값을 확인하십시오.
dig +short abcdef123456.example.com CNAME
# ziyuan.baidu.com.

dig +short @8.8.8.8 abcdef123456.example.com CNAME

레코드는 그대로 두십시오. 확인이 끝났다고 지우면 나중에 재확인에서 실패하기 쉽습니다.

설정은 맞아 보이는데 확인이 실패할 때

파일을 curl해 보면 200이 오는데 Baidu는 계속 아니라고 합니다. 아래 목록을 위에서부터 짚어 보십시오.

  • 봇 챌린지나 WAF 규칙. Cloudflare Bot Fight Mode, AWS WAF 관리형 규칙, 그리고 대부분의 공격 대응 모드는 스크립트를 실행하지 않는 클라이언트에 403이나 503과 함께 JavaScript 중간 페이지를 돌려줍니다. Baidu의 수집기는 스크립트를 실행하지 않습니다. 확인용 경로나 크롤러 자체를 허용 목록에 넣으십시오.
  • 지역 차단. 스크래핑을 줄이려고 중국 본토 트래픽을 막거나 속도를 제한하는 유럽 사이트가 적지 않습니다. 확인 요청은 정확히 그 대역에서 옵니다. 엣지에서 떨어뜨리는 것이 없는지 확인하십시오.
  • User-Agent 필터링. 크롤러는 Baiduspider로 자신을 밝힙니다. 낯선 크롤러 문자열을 스크래퍼로 취급하는 보안 스택도 있습니다. 허용 목록에 넣기 전에 요청이 진짜인지 확인하고 싶다면, 출발지 IP의 역방향 조회 결과가 *.baidu.com 또는 *.baidu.jp로 나오고 정방향 조회가 이와 일치하는지 보면 됩니다.
  • robots.txt가 막고 있습니다. 와일드카드 User-Agent 아래의 Disallow: /, 또는 누군가 남겨 둔 User-agent: Baiduspider 차단 규칙이 있으면 수집은 시작조차 되지 않습니다.
  • 브라우저가 가려 주던 TLS 문제. 중간 인증서 누락은 데스크톱 브라우저가 조용히 메워 주지만, 단순한 수집기는 그러지 않습니다. 초록색 자물쇠를 믿지 말고 외부 TLS 검사 도구로 도메인을 한 번 돌려 보십시오.
  • 엉뚱한 origin을 확인한 경우. 파일은 www.example.com에 있는데 Baidu의 사이트는 example.com으로 등록되어 있습니다. 오류 메시지는 이 사실을 전혀 알려 주지 않습니다.
  • 첫 바이트가 느림. 중국에 거점이 없는 유럽 서버는 베이징에서 오는 요청에 느리게 응답하고, 여기에 서버리스 콜드 스타트까지 겹치면 수집 타임아웃을 넘길 수 있습니다. 시간대를 바꿔 다시 시도하는 것이 실제로 도움이 됩니다.

어떤 방법을 고를까

빌드 파이프라인이 있다면 정적 파일을 배포하십시오. 가장 망가질 일이 적고 테스트도 가장 쉽습니다. CMS 안에서 일하고 페이지가 서버 렌더링이라면 meta 태그를 쓰십시오. 사이트에 손을 전혀 댈 수 없거나, 도메인 단위로 한 번 증명해 두고 다시 들여다보고 싶지 않다면 CNAME입니다.

무엇을 고르든 영구적으로 남겨 두고, 다른 DNS 레코드 옆에 인프라 문서로 적어 두십시오. 열여덟 달 뒤에 정체 모를 파일을 지우는 사람은 아마 본인일 것입니다.

이 방법들로는 풀리지 않는 부분

세 가지 방법 모두 Baidu 계정에 이미 로그인해 있다는 것을 전제로 합니다. 가입은 중국 본토 휴대전화 번호로 오는 SMS로 확인되고, 사이트에 따라 Baidu는 중국 국민신분증이나 중국 사업자등록증을 통한 실명 인증(实名认证)까지 요구합니다. 프랑크푸르트나 맨체스터의 회사는 DNS 존을 완벽하게 설정해 두고도 확인 화면에 닿지 못합니다.

그 지점을 저희 바이두 사이트 등록 대행이 메웁니다. 도메인만 알려 주시고 고객사 쪽에서 도메인 소유권 확인을 한 번만 마치면, 등록은 저희가 진행하고 바이두가 실제로 무엇을 색인했는지 보고해 드립니다. 도메인당 정액 요금입니다. 중국 전화번호도, 중국 법인도, 고객사 명의의 바이두 계정도 필요하지 않습니다.

큰 그림을 먼저 보고 싶다면 바이두 사이트 등록 완전 가이드에서 사이트맵, 푸시 API, 그리고 바이두의 랭킹이 실제로 무엇에 점수를 주는지 다룹니다. 직접 이야기하는 편이 낫다면 상담을 예약해 주세요.

서비스

이 과정을 대신 처리해 드립니다

도메인 소유권 확인, 사이트맵과 URL 제출, 2주 뒤 색인 리포트까지. 도메인 1개, 고정 요금이며 중국 휴대전화 번호도, 중국 법인도, 고객사 명의의 바이두 계정도 필요하지 않습니다.

바이두 사이트 등록 대행 보기
← Back to All Articles