구글이 '선호 소스' 버튼 다는 법을 공개했습니다 — 우리 사이트가 붙일 대상인지 가리는 순서

"우리도 저 '선호 소스' 버튼이라는 걸 달아야 하냐"는 문의가 며칠 사이 늘었습니다. 구글이 2026년 8월 20일 자로 검색 센트럴 문서에 사이트에 직접 붙일 수 있는 선호 소스 버튼 설치 안내를 추가했기 때문입니다. 붙이는 것 자체는 스크립트 두 줄이라 십 분이면 끝납니다. 문제는 그 앞 단계입니다. 우리 사이트가 애초에 이 기능의 대상인지를 확인하지 않고 버튼부터 달면, 아무 일도 일어나지 않는 장식을 헤더에 붙여 두게 됩니다.

이 기능은 '추천'이 아니라 사용자의 '지정'입니다

먼저 성격을 정확히 잡아야 합니다. 선호 소스는 구글이 좋은 사이트를 골라 주는 제도가 아닙니다. 검색 사용자가 직접 특정 사이트를 자기 선호 목록에 넣는 기능입니다. 사용자가 우리 도메인을 지정해 두면, 그 사용자의 검색 결과에서 우리 콘텐츠가 톱 스토리에 더 나올 가능성이 생기고 '선호' 배지가 함께 표시됩니다. 구글 문서는 AI 모드와 AI 개요에서도 지정한 사용자에게 같은 배지가 붙을 수 있다고 안내합니다.

여기서 두 가지가 따라 나옵니다. 첫째, 이건 전체 순위를 올리는 장치가 아니라 이미 우리를 아는 사람에게만 작동하는 개인화 장치입니다. 신규 유입을 만드는 도구로 팔면 안 됩니다. 둘째, 지정하는 주체가 사용자이므로 성과는 우리가 얼마나 많은 독자에게 "지정해 달라"고 요청했는지에 달려 있습니다. 기술 작업이 아니라 캠페인에 가깝습니다.

톱 스토리 쪽 선호 소스는 구글 검색이 제공되는 모든 언어에서 이용할 수 있다고 문서에 적혀 있습니다. 한국어 사용자에게도 해당됩니다. AI 모드·AI 개요 쪽은 그 기능 자체가 제공되는 언어와 지역을 따릅니다.

대상 여부는 도메인 단위에서 갈립니다

붙일지 말지를 정하는 첫 관문은 단위입니다. 구글 문서는 도메인과 서브도메인만 선호 소스 설정 도구에 나타날 수 있다고 못 박습니다. example.com이나 news.example.com은 되지만 example.com/blog처럼 하위 디렉터리는 대상이 아닙니다.

이 한 줄이 실무에서 꽤 많은 것을 정리해 줍니다. 회사 홈페이지 안의 /blog 디렉터리로 콘텐츠를 운영하는 구조라면, 그 블로그만 따로 선호 소스로 지정받을 수 없습니다. 지정 대상은 회사 도메인 전체가 됩니다. 서브도메인으로 분리하면 이 기능과는 맞지만, 색인·내부링크·보고 체계를 전부 건드리는 결정이라 버튼 하나 때문에 구조를 바꿀 일은 아닙니다.

다음 관문은 실제 노출 여부입니다. 선호 소스 설정 도구에 우리 사이트가 검색돼 나와야 참여가 됩니다. 확인은 간단합니다. 구글 계정에 로그인한 상태에서 https://www.google.com/preferences/source?q=우리도메인 형식의 주소를 열어 우리 사이트가 목록에 잡히는지 봅니다. 잡히지 않는다면 버튼을 다는 것은 의미가 없고, 그 이유부터 따로 봐야 합니다.

설치 방식은 세 가지, 난이도가 다릅니다

문서가 제시하는 방식은 크게 셋입니다.

1. 표준 자바스크립트 버튼 — https://news.google.com/swg/js/v1/publisher.js 스크립트를 비동기로 불러오고, 버튼을 놓을 자리에 지정된 속성을 가진 빈 요소를 하나 두면 됩니다. 언어는 사용자 환경에 맞춰 자동으로 잡히고, 밝은·어두운 테마 선택과 언어 강제 지정도 지원합니다. 대부분은 여기서 끝납니다.
2. 커스텀 디자인 — 사이트 디자인에 맞춘 자체 UI에 동작만 연결하는 방식입니다. 모듈 임포트나 콜백 큐로 버튼 동작을 직접 호출합니다.
3. 딥링크 — 자바스크립트를 넣기 어려운 환경이면 https://www.google.com/preferences/source?q=도메인을 그냥 링크로 겁니다. 뉴스레터, 이메일 서명, 소셜 프로필처럼 스크립트를 못 넣는 자리에도 쓸 수 있어 오히려 활용도가 높습니다.

세 방식 모두 선택 사항입니다. 구글 문서는 이런 방법들이 독자를 모으는 예시일 뿐이며, 선호 소스로 나타나기 위해 반드시 해야 하는 일은 아니라고 명시합니다. 그러니 "안 달면 불이익이 있다"는 식의 제안서를 받으셨다면 그 문장부터 걸러 내시기 바랍니다.

붙이기 전에, 우리 콘텐츠가 톱 스토리에 뜨는 종류인지 봅니다

가장 실질적인 판단 기준입니다. 선호 소스가 가장 직접적으로 작동하는 자리는 톱 스토리이고, 톱 스토리는 뉴스성 질의에서 나타납니다. 발행 주기가 분기에 한 번인 회사 소개형 사이트라면 버튼을 달아도 배지가 뜰 화면 자체가 거의 없습니다.

반대로 이런 곳은 검토할 값이 있습니다. 업계 소식을 주 단위 이상으로 내는 매체형 사이트, 특정 분야에서 반복 검색되는 브랜드, 뉴스레터 구독자처럼 이미 우리를 찾아오는 고정 독자층이 있는 곳입니다. 지정은 결국 아는 사람이 하는 행동이기 때문에, 구독자 명단이 없는 상태에서 버튼만 다는 것은 순서가 없습니다.

참고로 이 기능은 우리 콘텐츠가 AI 검색 화면에 어떻게 실리느냐와도 맞닿아 있습니다. 노출 자체를 통제하는 문제는 서치콘솔의 AI 검색 제외 토글을 끄기 전에 확인할 것들에서 다뤘고, 인용되는 쪽에서 실제로 손댈 수 있는 범위는 AI 검색에 내 사이트가 인용되게 하려면에 정리해 두었습니다. 선호 소스는 그 둘 사이에 있는, 사용자 쪽에서 여는 통로입니다.

효과는 무엇으로 보고할 것인가

여기서 대행사가 자주 미끄러집니다. 우리 사이트를 선호 소스로 지정한 사람이 몇 명인지 직접 세어 주는 화면이 서치콘솔에 보이지 않는다면, 성과는 간접 지표로 잡을 수밖에 없습니다. 지정한 사용자에게만 표시가 바뀌는 구조라 A/B 비교도 깔끔하게 나오지 않습니다.

현실적인 접근은 셋입니다. 첫째, 버튼을 노출한 페이지의 클릭 이벤트를 GA4에 이벤트로 심어 버튼을 누른 횟수를 셉니다. 이건 우리 쪽 데이터라 확실합니다. 둘째, 서치콘솔 성과 보고서에서 재방문 성격이 강한 브랜드 검색어군의 클릭·노출 추이를 봅니다. 브랜드와 비브랜드를 갈라 보는 방법은 대행사 보고서의 클릭 수가 브랜드 검색어를 빼고도 올랐는지 가리는 법에 정리해 두었습니다. 셋째, 이건 캠페인이므로 뉴스레터 발송 시점과 클릭 수를 붙여 놓고 봅니다.

보고서 문장은 이 선에서 끝내는 것이 안전합니다. "지정한 사용자에게 노출 우선순위와 배지가 붙는 기능이고, 우리는 지정 요청 경로를 열었으며, 버튼 클릭은 몇 건이다." 여기서 더 나아가 순위 상승이나 유입 배수를 약속하는 순간, 검증할 수 없는 숫자를 떠안게 됩니다.

점검 순서 요약

1. 우리 콘텐츠가 뉴스성 질의에서 톱 스토리에 나타나는 종류인지 먼저 판단한다. 아니면 여기서 끝낸다.
2. 지정 단위를 확인한다. 하위 디렉터리는 대상이 아니고 도메인·서브도메인만 된다.
3. 선호 소스 설정 도구 주소에 우리 도메인을 넣어 목록에 잡히는지 본다. 안 잡히면 버튼을 달아도 소용없다.
4. 설치는 표준 자바스크립트 버튼으로 시작한다. 스크립트를 못 넣는 자리에는 딥링크를 쓴다.
5. 버튼 위치는 헤더 구석이 아니라 기사 하단·구독 안내 옆처럼 이미 우리 글을 다 읽은 사람이 지나가는 자리에 둔다.
6. 버튼 클릭을 GA4 이벤트로 심는다. 이 숫자가 유일하게 확실한 지표다.
7. 뉴스레터·소셜 채널에 딥링크를 한 번 돌려 초기 지정을 만든다.
8. 4~6주 뒤 브랜드 검색어군 추이와 버튼 클릭 수를 함께 놓고 계속할지 판단한다.

정리하면, 이 기능은 설치 난이도가 낮고 위험도 거의 없지만 효과는 우리가 이미 가진 독자 규모에 정확히 비례합니다. 붙일지 말지는 개발 일정이 아니라 구독자 명단을 보고 결정하시면 됩니다.