기술계 B2B 사이트의 SEO 대책과 Google 광고 진행 방법

SEO와 Google 광고 상담에서는 다음 같은 이야기가 자주 섞입니다.

• 먼저 SEO를 해야 하는지, 광고를 해야 하는지
• 글을 늘리면 검색 유입이 늘어나는지
• AI로 글을 양산해도 되는지
• Google 광고는 홈으로 보내면 되는지
• Search Console과 Google 광고를 어떻게 나누어 쓰는지
• 문의를 늘리고 싶은데 PV만 늘어나고 끝나는 이유

이 이야기는 단순히 SEO가 중요하다거나 광고가 빠르다만으로는 정리되지 않습니다. 실제로는 어떤 문의를 가져오고 싶은지, 어느 페이지에서 전환시킬지, 무엇을 conversion으로 측정할지로 거의 결정됩니다.

flowchart TB
    accTitle: SEO와 광고의 진행 방식을 정하는 세 가지 질문
    accDescr: SEO가 중요한지 광고가 빠른지가 아니라, 어떤 문의를 가져오고 싶은지, 어느 페이지에서 전환시킬지, 무엇을 conversion으로 측정할지라는 세 가지 질문으로 진행 방식이 거의 결정된다는 것을 나타내는 그림.
    q1["어떤 문의를 가져오고 싶은지"] --> q2["어느 페이지에서 전환시킬지"]
    q2 --> q3["무엇을 conversion으로 측정할지"]
    q3 --> r1["SEO와 광고의 진행 방식이 거의 결정된다"]

그림1: 시책 논의보다 먼저, 이 세 가지 질문을 정하면 정리됩니다.

이 글에서는 SEO와 Google 광고를 별개의 시책이 아니라, 같은 검색 수요를 다른 각도에서 가져가는 구조로 정리합니다. 특히 KomuraSoft / comcomponent.com 같은 기술계 B2B 사이트를 염두에 두고, Google의 공식 정보를 전제로 한 실무 쪽 진행 방식을 정리합니다.^1234567

이 글의 읽는 법

긴 글이므로, 목적별 입구를 먼저 둡니다.

이 글에서 쓰는 용어

마케팅 쪽 용어가 한꺼번에 나오므로, 먼저 한 줄씩 정리합니다.

1. 먼저 결론

먼저 결론을 늘어놓으면, 실무에서의 진행 방식은 대체로 이렇게 됩니다.

• SEO와 Google 광고는 어느 한쪽을 고르는 것이 아니라, 의도가 다른 검색을 따로 가져가는 것입니다.
• SEO에서 중요한 것은 검색 엔진을 향한 잔기술보다, 사람에게 도움이 되는 페이지를 Google이 찾아 이해하기 쉬운 형태로 두는 것입니다. Google 자신도 helpful, reliable, people-first content와 Search Essentials를 기본선으로 제시합니다.³²
• Google은 많은 페이지를 자동 발견할 수 있지만, 내부 링크, 사이트맵, 적절한 제목, 설명, URL, 구조화 데이터는 발견과 이해를 돕습니다.^113141516
• 반대로 robots.txt로 비공개로 만들려 하기, 비슷한 페이지를 대량으로 만들기, AI로 가치 없는 글을 양산하기, 제목이나 설명을 모든 페이지에서 재사용하기 같은 운용은 궁합이 나쁩니다.^1721814
• Google 광고에서 가장 먼저 할 일은 입찰 기법이 아니라 측정을 갖추는 일입니다. Google 공식에서도 정확한 conversion 데이터, 강한 태그 기반, enhanced conversions, Consent Mode를 중시합니다.⁴⁶⁷
• 검색 광고 운용은 conversion 설계 → landing page → 키워드 / 검색어 → 광고문 → 입찰 순으로 보는 편이 무너지기 어렵습니다.
• Google은 Smart Bidding + broad match + responsive search ads를 밀지만, 이는 올바른 conversion 측정이 전제입니다. 측정이 약한 채로 넓히면 그냥 낭비 사격이 되기 쉽습니다.⁴¹¹
• 기술계 B2B 사이트에서는 넓고 얕은 유입보다 적어도 의도가 짙은 검색을 가져가는 편이 자연스럽습니다. 구체적으로는 Windows앱 개발, 기존 Windows 소프트의 개수·보수, 기술 상담·설계 리뷰, 기존 자산 활용·이전 지원 같은 서비스 페이지를 주역으로 두고, 그 주변에 기술 글과 사례를 두는 구성이 강합니다.
• 요컨대 SEO는 자산 만들기, Google 광고는 수요 수확과 가설 검증으로 보면 정리하기 쉽습니다.

flowchart TB
    accTitle: SEO와 광고의 역할을 보는 법
    accDescr: SEO와 Google 광고는 어느 한쪽을 고르는 것이 아니라 의도가 다른 검색을 따로 가져가는 것이며, SEO는 자산 만들기, Google 광고는 수요 수확과 가설 검증으로 보면 정리하기 쉽다는 것을 나타내는 그림.
    s0["같은 검색 수요"] --> s1["SEO"]
    s0 --> s2["Google 광고"]
    s1 --> s3["자산 만들기 (축적되기 쉽다)"]
    s2 --> s4["수요 수확과 가설 검증(빠르다)"]
    s3 --> s5["의도가 다른 검색을 따로 가져간다"]
    s4 --> s5

그림2: SEO는 자산 만들기, 광고는 수확과 가설 검증이라는 분담으로 봅니다.

이 글의 지식 맵

이 글은 기술 B2B 사이트에서 SEO와 Google 광고의 역할 분담을 정리한 실무 가이드입니다. SEO는 Google이 제시하는 helpful content나 Search Essentials, Core Web Vitals, mobile-first indexing과 같은 기본 요건을 충족하는 것을 전제로 하며, 내부 링크나 canonical URL, 구조화 데이터, 사이트맵으로 검색 엔진의 이해를 돕습니다. Google 광고는 전환 측정을 게재 전의 토대로 삼고, enhanced conversions나 Consent Mode로 정밀도를 높이며, 키워드의 매치 타입과 스마트 자동 입찰, 반응형 검색 광고를 조합해 운영합니다. 둘은 검색어 보고서를 통해 수요를 서로 반영하고, 기술 B2B 사이트에서는 글이나 사례에 둘러싸인 서비스 페이지가 문의를 만드는 주역으로 권장됩니다.

flowchart LR
    accTitle: SEO와 Google 광고의 지식 맵
    accDescr: SEO가 helpful content나 Search Essentials, Core Web Vitals, mobile-first indexing과 같은 검색 엔진 대상의 기본 요건을 충족하는 것을 전제로 하고, Google 광고가 전환 측정을 토대로 키워드의 매치 타입과 자동 입찰을 조합하며, 둘이 검색어 보고서와 서비스 페이지를 통해 연계하는 관계를 보여주는 그림.
    seo["SEO(검색 엔진 최적화)"]
    google_ads["Google 광고"]
    helpful_content["people-first content(사람을 위한 콘텐츠)"]
    search_essentials["Google Search Essentials"]
    scaled_content_abuse["scaled content abuse"]
    internal_link["내부 링크"]
    canonical_url["canonical URL"]
    xml_sitemap["사이트맵"]
    robots_txt["robots.txt"]
    noindex["noindex"]
    core_web_vitals["Core Web Vitals"]
    mobile_first_indexing["mobile-first indexing"]
    structured_data["구조화 데이터(Structured Data)"]
    search_console["Google Search Console"]
    conversion_tracking["전환 추적"]
    enhanced_conversions["enhanced conversions"]
    consent_mode["Consent Mode"]
    smart_bidding["스마트 자동 입찰"]
    keyword_match_type["키워드 일치 유형"]
    responsive_search_ads["반응형 검색 광고(Responsive Search Ads)"]
    quality_score_ads["품질 점수"]
    landing_page_experience["랜딩 페이지 품질(Landing Page Experience)"]
    search_terms_report["검색어 보고서"]
    service_page["서비스 페이지"]
    helpful_content -->|"권장되는 대응"| seo
    search_essentials -->|"권장되는 대응"| seo
    scaled_content_abuse -->|"양립하지 않는다"| helpful_content
    seo -->|"이용한다"| internal_link
    seo -.->|"이용한다"| canonical_url
    seo -->|"이용한다"| xml_sitemap
    seo -->|"이용한다"| robots_txt
    robots_txt -->|"사용은 비권장"| noindex
    core_web_vitals -->|"권장되는 대응"| seo
    mobile_first_indexing -->|"권장되는 대응"| seo
    seo -->|"이용한다"| structured_data
    seo -->|"이용한다"| search_console
    conversion_tracking -->|"권장되는 대응"| google_ads
    conversion_tracking -.->|"이용한다"| enhanced_conversions
    conversion_tracking -.->|"이용한다"| consent_mode
    google_ads -.->|"이용한다"| smart_bidding
    smart_bidding -.->|"전제로 한다"| conversion_tracking
    google_ads -->|"이용한다"| keyword_match_type
    keyword_match_type -.->|"전제로 한다"| conversion_tracking
    google_ads -->|"이용한다"| responsive_search_ads
    google_ads -->|"이용한다"| quality_score_ads
    quality_score_ads -->|"이용한다"| landing_page_experience
    google_ads -->|"이용한다"| search_terms_report
    search_terms_report -->|"권장되는 대응"| seo
    service_page -->|"권장되는 대응"| seo

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 25건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. SEO와 Google 광고는 무엇이 다른가

SEO와 Google 광고는 같은 검색 화면에 나올 수 있습니다. 다만 운용의 성질은 꽤 다릅니다.

기술계 B2B 사이트에서는 이 차이가 특히 뚜렷합니다.

예를 들면,

• Windows 앱 개발 수탁
• COM ActiveX 이전
• 기존 Windows 소프트 개수
• 기술 상담 설계 리뷰 Windows

같은 검색은 검색 횟수 자체는 크지 않아도 문의 의도가 꽤 짙습니다. 이런 말은 Google 광고와도 궁합이 좋고, SEO에서도 서비스 페이지를 중심으로 가져갈 가치가 있습니다.

한편,

• VBA 란
• WPF WinForms 차이
• 관리자 권한 언제 필요
• Media Foundation 카메라 열거

같은 말은 지금 당장 외주를 맡기고 싶은 사람과 그냥 찾아보는 사람이 섞입니다. 이 층은 SEO 글로 가져가고, 그 글에서 서비스 페이지나 문의로 자연스럽게 흘리는 편이 잘 먹힙니다.

상담에 가까운 검색은 광고로도 가져가고, 주변의 학습·비교 수요는 SEO로 줍는다. 이 역할 나누기가 가장 현실적입니다.

flowchart TB
    accTitle: 검색 의도별 가져가는 법
    accDescr: 문의 의도가 짙은 상담에 가까운 검색은 광고로도 가져가고 서비스 페이지에서도 가져갈 가치가 있으며, 지금 당장 외주를 맡기고 싶은 사람과 그냥 찾아보는 사람이 섞이는 학습·비교 검색은 SEO 글로 가져와 글에서 서비스 페이지나 문의로 흘리는 것이 현실적인 역할 나누기임을 나타내는 그림.
    k1{"검색의 의도는"}
    k1 -->|"상담에 가깝고 의도가 짙다"| a1["광고로도 가져가고, 서비스 페이지에서도 가져간다"]
    k1 -->|"학습·비교로 사람이 섞인다"| a2["SEO 글로 가져간다"]
    a2 --> a3["글에서 서비스 페이지나 문의로 흘린다"]

그림3: 고의도는 광고와 서비스 페이지, 섞이는 층은 글로 받아 흘립니다.

3. SEO의 베스트 프랙티스

3.1 먼저 「검색 엔진용」이 아니라 「사람용」으로 생각한다

Google Search Central의 기본선은 꽤 명확합니다. Google의 자동 랭킹 시스템은 사람을 위해 만든, 도움이 되고 신뢰할 수 있는 정보를 우선하는 방향으로 설계되어 있습니다.³

또한 Search Essentials에서는 사용자를 속이거나 랭킹을 부자연스럽게 조작하는 행위가 스팸 정책의 대상이 된다고 제시합니다.²

이 전제에서 SEO에서는 먼저 다음을 정해야 합니다.

1. 이 페이지는 누구의, 어떤 장면을 위한 페이지인가
2. 그 사람은 검색 시점에 무엇을 알고 싶은지 / 무엇을 하고 싶은지
3. 이 페이지를 읽은 뒤에 다음에 무엇을 해 주었으면 하는지

여기가 모호하면,

• 키워드만 채워 넣은 페이지
• 무엇을 위한 글인지 알 수 없는 글
• 검색 유입은 있지만 문의로 이어지지 않는 글

이 늘어납니다.

flowchart TB
    accTitle: 쓰기 전에 정하는 세 가지
    accDescr: SEO에서는 먼저 이 페이지가 누구의 어떤 장면을 위한 것인지, 그 사람은 검색 시점에 무엇을 알고 싶은지, 읽은 뒤에 다음에 무엇을 해 주었으면 하는지를 정해야 하며, 여기가 모호하면 키워드만 채워 넣은 페이지나 문의로 이어지지 않는 글이 늘어난다는 것을 나타내는 그림.
    p1["누구의, 어떤 장면을 위한 페이지인가"] --> p2["검색 시점에 무엇을 알고 싶은지 / 무엇을 하고 싶은지"]
    p2 --> p3["읽은 뒤에 다음에 무엇을 해 주었으면 하는지"]
    p3 -.-> p4["모호한 채로 두면 유입은 있어도 문의에 닿지 않는다"]

그림4: 사람용 SEO는 쓰기 전에 이 세 가지를 정하는 일에서 시작합니다.

특히 기술계 사이트에서는 넓은 일반론보다 구체적인 곤란에 맞추는 편이 강합니다.

예를 들면,

• 「Windows 개발이란」
• 「C#이란」

같은 거대한 테마를 넓게 다루기보다,

• 「Windows의 관리자 권한이 필요해지는 때는 언제인가」
• 「VBA는 앞으로 못 쓰게 되는가」
• 「Media Foundation으로 카메라에서 이미지를 가져오는 방법」

처럼 검색 이유가 분명한 테마가 SEO적으로도 상담 동선적으로도 다루기 쉽습니다.

3.2 AI로 글을 양산하면 되는 것은 아니다

Google은 생성 AI 이용 자체를 일률적으로 부정하지 않습니다. 한편 가치를 더하지 않는 대량 생성 콘텐츠는 scaled content abuse 관점에서 스팸 정책에 저촉될 수 있다고 명시합니다.¹⁸

이 선 긋기는 실무에서도 가볍게 보지 않는 편이 좋습니다.

AI를 쓴다면,

• 구성안 정리
• 비교 축 훑기
• 초안 작성
• 표현의 압축 / 전개
• FAQ 후보 추출

에는 맞습니다.

다만 다음이 없으면 약합니다.

• 자사 나름의 판단
• 실제 안건에서 자주 나오는 논점
• 실패 패턴
• 구체적인 전제 조건
• 누구에게 상담이 맞는지, 맞지 않는지

즉 AI를 쓴다면 원고 공수를 줄이기 위해 쓰는 것이지, 가치의 대용으로 쓰면 안 된다는 뜻입니다.

flowchart TB
    accTitle: AI를 쓸 곳과 선 긋기
    accDescr: AI는 구성안 정리나 초안 작성에는 맞지만, 자사 나름의 판단이나 실제 안건에서 자주 나오는 논점, 실패 패턴 같은 가치가 더해지지 않으면 약하고, 가치를 더하지 않는 대량 생성 콘텐츠는 scaled content abuse 관점에서 스팸 정책에 저촉될 수 있다는 것을 나타내는 그림.
    a1["AI에 맡겨도 되는 일"] --> a2["구성안·비교 축·초안·FAQ 후보"]
    b1["사람이 더해야 할 가치"] --> b2["자사 나름의 판단·실제 안건의 논점·실패 패턴"]
    a2 --> c1["원고 공수를 줄이는 도구로 쓴다"]
    b2 --> c1
    a2 -.-> c2["가치를 더하지 않는 양산은 스팸 정책 저촉 리스크"]

그림5: AI는 공수 절감 도구이지, 가치의 대용이 되지 않습니다.

3.3 페이지의 역할을 나눈다

SEO에서 성과가 나오기 어려운 사이트는 페이지 역할이 섞여 있는 경우가 많습니다. 기술계 B2B 사이트라면 적어도 다음 4층으로 나누면 정리하기 쉽습니다.

역할과 동선을 그림으로 두면 이렇게 됩니다. 서비스 페이지를 가운데에 두고, 글과 사례로 그 주변을 감싸는 형태입니다.

flowchart LR
    Q1["학습·비교 의도의 검색<br/>예 WPF와 WinForms의 차이"] --> A["기술 글<br/>검색의 입구를 만든다"]
    Q2["상담처를 찾는 의도의 검색<br/>예 기존 Windows 소프트 개수"] --> S["서비스 페이지<br/>문의를 가져가는 주역"]
    AD["Google 광고"] --> S
    A --> S
    A --> C["사례 페이지<br/>정말 진행할 수 있는지의 증거"]
    C --> S
    S --> F["문의 / 회사 정보<br/>마지막 불안을 줄인다"]
    C --> F

그림6: 서비스 페이지를 가운데에 두고, 글과 사례가 주변에서 흘려 넣는 4층의 동선.

화살표 방향이 중요합니다. 글은 사례와 서비스 페이지로 흘리고, 사례는 서비스 페이지와 문의로 흘린다. 반대로 서비스 페이지에서 글로 독자를 되돌려 보내는 동선을 주로 두면, 상담 의도로 온 사람을 정보 수집으로 되돌려 버립니다.

1. 서비스 페이지

문의를 가져가는 주력 페이지입니다.

예:

• Windows앱 개발
• 기술 상담·설계 리뷰
• 기존 Windows 소프트의 개수·보수
• 기존 자산 활용·이전 지원

여기에서는 무엇을 지원하는지, 누구에게 맞는지, 어떤 진행 방식인지, 어떤 안건과 궁합이 좋은지 를 분명히 합니다.

2. 사례 페이지

「정말 이 회사에서 진행할 수 있을 것 같은가」를 판단하기 위한 증거입니다.

• 어떤 배경인가
• 무엇이 어려웠는가
• 무엇을 남기고, 무엇을 바꿨는가
• 결과는 어떻게 되었는가

를 낼 수 있으면 강합니다.

3. 기술 글

검색 유입의 입구입니다. 다만 PV를 위한 글이 아니라 장래의 상담 테마에 가까운 글을 중심으로 합니다.

4. 문의 / 회사 정보

마지막 불안을 줄이는 페이지입니다. 실명, 거점, 대응 범위, 상담 입구, 상담 때 필요한 정보가 보이면 전환하기 쉬워집니다.

3.4 내부 링크는 꽤 중요하다

Google은 링크를 페이지 발견 수단이자 관련성의 단서로 쓴다고 설명합니다.¹⁹

그래서 기술 글을 쓰고 끝이 아니라,

• 부모가 되는 서비스 페이지로 링크한다
• 관련 사례로 링크한다
• 관련된 비교 글로 링크한다
• 최종적으로 문의나 관련 서비스로 잇는다

는 흐름을 만들어야 합니다.

그렇다고 링크를 그냥 늘리면 되는 것은 아닙니다. 중요한 것은 어느 페이지로 가는지가 보이는 앵커 텍스트로, 문맥 안에 자연스럽게 두는 것입니다.¹⁹

「여기」, 「자세한 내용은 여기」만 쓰기보다,

• 기존 Windows 소프트의 개수·보수
• 기술 상담·설계 리뷰
• COM / ActiveX를 포함한 기존 자산의 단계 이전

처럼 도착지의 의미가 보이는 링크가 강합니다.

flowchart TB
    accTitle: 내부 링크를 두는 법
    accDescr: Google은 링크를 페이지 발견 수단이자 관련성의 단서로 쓰므로, 기술 글에서 부모 서비스 페이지나 관련 사례로 잇는 흐름을 만들어야 하며, 링크는 그냥 늘리는 것이 아니라 도착지가 보이는 앵커 텍스트로 문맥 안에 자연스럽게 두는 것이 중요하다는 것을 나타내는 그림.
    l1["링크는 페이지 발견 수단이자 관련성의 단서"] --> l2["글에서 부모 서비스·사례·비교 글로 잇는다"]
    l2 --> l3{"앵커 텍스트는"}
    l3 -.->|"여기·자세한 내용은 여기"| l4["도착지가 안 보여 약하다"]
    l3 -->|"도착지의 의미가 보이는 말"| l5["문맥 안에서 자연스럽게 먹힌다"]

그림7: 내부 링크는 수가 아니라, 도착지가 보이게 두는 법이 먹힙니다.

3.5 제목, 메타 디스크립션, URL을 대충 두지 않는다

Google은 제목 링크를 자동 생성하지만, <title> 요소를 포함한 여러 정보원에서 판단하며, 각 페이지에 명확하고 간결한 제목을 붙일 것을 권장합니다.¹³

또한 스니펫은 페이지 본문에서 자동 생성되는 경우가 많지만, 페이지를 더 정확하게 설명할 때는 meta description이 쓰이는 경우가 있다고 되어 있습니다. 나아가 Google은 페이지마다 고유한 설명을 붙일 것을 권장합니다.¹⁴

URL에 대해서도 Google은 알기 쉽고 논리적이며, 사람이 이해하기 쉬운 구조를 권장하며, 설명적인 말을 쓸 것, audience의 언어를 쓸 것, 단어는 하이픈으로 나눌 것, 불필요한 파라미터를 줄일 것을 권합니다.²⁰

실무에서는 다음 선만 지켜도 꽤 달라집니다.

• 페이지마다 고유 제목을 붙인다
• 제목은 무슨 페이지인지 한눈에 보이게 한다
• 메타 디스크립션은 페이지 고유로 한다
• URL은 읽을 수 있는 형태로 한다
• 같은 내용을 여러 URL로 내지 않는다

특히 블로그에서는 글 제목, H1, meta description, 목록 제목이 미묘하게 어긋나면 검색 결과에서도 사이트 안에서도 알아보기 어려워집니다.

flowchart TB
    accTitle: 제목·설명·URL에서 지킬 선
    accDescr: 페이지마다 고유 제목과 고유 메타 디스크립션을 붙이고, URL은 읽을 수 있는 형태로 하며, 같은 내용을 여러 URL로 내지 않는다는 선만 지켜도 꽤 달라지고, 글 제목·H1·meta description·목록 제목이 어긋나면 검색 결과에서도 사이트 안에서도 알아보기 어려워진다는 것을 나타내는 그림.
    t1["페이지마다 고유한 제목과 설명을 붙인다"] --> t2["URL은 읽을 수 있는 형태로 한다"]
    t2 --> t3["같은 내용을 여러 URL로 내지 않는다"]
    t3 --> t4["검색 결과에서도 사이트 안에서도 무슨 페이지인지 한눈에 보인다"]
    t1 -.-> t5["제목·H1·설명·목록의 어긋남은 혼란의 원인"]

그림8: 제목·설명·URL을 페이지 고유로 맞추기만 해도 효과는 큽니다.

3.6 중복 URL과 canonical을 방치하지 않는다

Google은 같은 내용을 여러 URL로 볼 수 있는 경우, 대표 URL을 canonical로 고릅니다. 스스로 canonical을 명시하지 않으면 Google 쪽이 자동 판단합니다.¹²

그래서,

• /page
• /page/
• ?utm_source=...
• 정렬이나 필터 차이
• 대문자 / 소문자 차이
• HTTP/HTTPS나 www 있음 / 없음의 혼재

같은 상태는 의외로 천천히 먹힙니다.

내부 링크도 사이트맵도 자신이 canonical로 두고 싶은 URL로 통일해 두는 것이 기본입니다.¹²¹⁵

flowchart TB
    accTitle: 중복 URL과 canonical 다루기
    accDescr: 같은 내용이 끝 슬래시 차이나 파라미터 차이 등 여러 URL로 보일 때, canonical을 스스로 명시하지 않으면 Google 쪽이 자동으로 대표 URL을 고르므로, canonical을 명시하고 내부 링크도 사이트맵도 그 URL로 통일하는 것이 기본임을 나타내는 그림.
    c1["같은 내용이 여러 URL로 보이는 상태"] --> c2{"canonical을 명시하고 있는가"}
    c2 -->|"명시한다"| c3["자신이 정한 대표 URL에 평가가 모인다"]
    c2 -.->|"명시하지 않는다"| c4["Google 쪽이 자동으로 고른다"]
    c3 --> c5["내부 링크도 사이트맵도 같은 URL로 통일한다"]

그림9: 대표 URL은 스스로 정하고, 링크도 사이트맵도 그리로 맞춥니다.

3.7 사이트맵과 robots.txt를 올바르게 쓴다

Google은 많은 사이트를 자동으로 발견할 수 있지만, 사이트맵은 「어느 URL을 정규로 보여주고 싶은가」의 힌트가 됩니다. Search Console에서 보내면 Googlebot이 사이트맵을 읽은 시각이나 처리 오류도 보기 쉬워집니다.¹¹⁵

한편 robots.txt는 크롤 제어를 위한 구조이지, 검색 결과에서 지우는 구조가 아닙니다. Google도 검색 결과에 내고 싶지 않은 페이지는 noindex나 비밀번호 보호를 써야 한다고 설명합니다.¹⁷

여기는 꽤 오해되기 쉽습니다.

• 크롤시키고 싶지 않다 → robots.txt
• 검색 결과에 내고 싶지 않다 → noindex / 인증
• 스니펫의 일부만 제어하고 싶다 → nosnippet / data-nosnippet / max-snippet

라는 나눔입니다.¹⁴²¹

flowchart TB
    accTitle: robots.txt와 noindex의 나눔
    accDescr: robots.txt는 크롤 제어를 위한 구조이지 검색 결과에서 지우는 구조가 아니며, 크롤시키고 싶지 않으면 robots.txt, 검색 결과에 내고 싶지 않으면 noindex나 인증, 스니펫의 일부만 제어하고 싶으면 nosnippet 등을 쓴다는 나눔을 나타내는 그림.
    r0{"무엇을 하고 싶은가"}
    r0 -->|"크롤시키고 싶지 않다"| r1["robots.txt"]
    r0 -->|"검색 결과에 내고 싶지 않다"| r2["noindex / 인증"]
    r0 -->|"스니펫만 제어"| r3["nosnippet 등의 지정"]
    r1 -.-> r4["robots.txt는 검색 결과에서 지우는 구조가 아니다"]

그림10: 오해되기 쉬운 robots.txt는 목적별로 noindex나 인증과 나누어 씁니다.

3.8 모바일과 표시 속도는 「다른 테마」가 아니다

Google은 mobile-first indexing을 쓰며, 모바일 판 내용을 바탕으로 인덱스와 랭킹을 합니다. 나아가 반응형 디자인을 권장합니다.²²

볼 것은 「스마트폰에서도 보이는가」만이 아니라,

• 모바일에도 주요 콘텐츠가 있다
• 데스크톱과 모바일에서 내용이 거의 동등하다
• 모바일에서 noindex가 되어 있지 않다
• 주요 콘텐츠가 사용자 조작 없이는 나오지 않는 형태가 아니다
• 이미지나 구조화 데이터, 제목, 설명도 mobile 쪽에 있다

는 점입니다.²²

또한 Google은 Core Web Vitals를 실세계의 사용자 체험을 재는 지표로 두고, 양호한 상태를 강하게 권장합니다.²³

SEO를 위해서만 속도를 개선한다기보다, 광고에서도 자연 검색에서도 이탈이 줄어드는 기반으로 보는 편이 실무적입니다.

flowchart TB
    accTitle: 모바일과 표시 속도의 위치
    accDescr: Google은 mobile-first indexing으로 모바일 판 내용을 바탕으로 인덱스와 랭킹을 하고, Core Web Vitals를 실세계 사용자 체험을 재는 지표로 양호한 상태를 권장하므로, 속도 개선은 SEO만이 아니라 광고에서도 자연 검색에서도 이탈이 줄어드는 기반으로 보는 것이 실무적임을 나타내는 그림.
    m1["mobile-first indexing"] --> m2["모바일 판 내용으로 인덱스와 랭킹"]
    m3["Core Web Vitals"] --> m4["실세계 사용자 체험을 재는 지표"]
    m2 --> m5["광고에서도 자연 검색에서도 이탈이 줄어드는 기반"]
    m4 --> m5

그림11: 모바일 대응과 속도는 SEO 전용 이야기가 아니라 유입 전체의 기반입니다.

3.9 구조화 데이터는 「마법」은 아니지만, 할 가치는 있다

Google은 구조화 데이터를 페이지 이해와 리치 결과에 쓴다고 설명합니다. 다만 올바르게 쓴다고 반드시 표시되는 것은 아니다고도 명시합니다.¹⁶²⁴

그래서 구조화 데이터는 쓰면 이기는 것이 아니라, 써야 할 것을 올바르게 쓰는 것이 중요합니다.

기술계 B2B 사이트라면 적어도 다음이 후보입니다.

• Organization 회사명, 로고, URL, 연락처, SNS 등²⁵
• Article 블로그 글의 제목, 저자, 날짜, 이미지 등²⁶
• LocalBusiness 실제 거점이나 영업 시간을 앞에 내세울 경우²⁷

여기의 주의점은 분명합니다.

• 그 페이지의 보이는 내용과 일치시킨다
• 빈 페이지나 hidden content를 위해 마크업하지 않는다
• Rich Results Test와 URL Inspection으로 확인한다
• structured data는 eligible하게 만들 뿐이며, 표시 보장이 아님을 이해한다

flowchart TB
    accTitle: 구조화 데이터의 올바른 기대치
    accDescr: 구조화 데이터는 페이지 이해와 리치 결과의 단서가 되지만, 올바르게 쓴다고 반드시 표시되는 것은 아니며, 보이는 내용과 일치시키고 Rich Results Test와 URL Inspection으로 확인하며, eligible하게 만들 뿐 표시 보장이 아님을 이해하고 써야 한다는 것을 나타내는 그림.
    s1["구조화 데이터를 쓴다"] --> s2["보이는 내용과 일치시킨다"]
    s2 --> s3["Rich Results Test와 URL Inspection으로 확인"]
    s3 --> s4["리치 결과 대상이 될 수 있다(eligible)"]
    s4 -.-> s5["표시 보장은 아니다"]

그림12: 구조화 데이터는 「쓰면 이기는 것」이 아니라, 올바르게 써서 eligible하게 만드는 것입니다.

3.10 Search Console을 보고, 다음 페이지를 정한다

Google은 Search Console의 Performance 리포트에서 검색 쿼리, 페이지, 국가별 표시 횟수·클릭 수 등을 볼 수 있다고 설명합니다.²⁸

SEO는 쓴 직후보다 나온 데이터를 보고 고치는 쪽이 먹힙니다.

특히 보면 좋은 것은,

• 표시는 많은데 클릭률이 낮은 페이지 → 제목 / description / intent의 어긋남을 의심한다
• 클릭은 있지만 문의에 가까워지지 않는 페이지 → CTA와 내부 링크를 의심한다
• 관련 쿼리가 늘어난 페이지 → 후속 글이나 비교 글을 낸다
• 중요 서비스 페이지의 표시 자체가 적다 → 내부 링크, 사례, 주변 글로 보강한다

는 흐름입니다.

flowchart TB
    accTitle: 나온 데이터로 고치는 루프
    accDescr: SEO는 쓴 직후보다 나온 데이터를 보고 고치는 쪽이 먹히며, 표시는 많은데 클릭률이 낮은 페이지는 제목이나 의도의 어긋남을 의심하고, 클릭은 있지만 문의에 가까워지지 않는 페이지는 CTA와 내부 링크를 의심하고, 관련 쿼리가 늘어난 페이지는 후속을 내고, 중요 페이지 표시가 적으면 내부 링크나 주변 글로 보강한다는 흐름을 나타내는 그림.
    d0["Search Console을 본다"] --> d1["CTR 낮음→제목을 의심한다"]
    d0 --> d2["전환하지 않음→CTA를 의심한다"]
    d1 --> d3["쿼리 증가→후속을 낸다"]
    d2 --> d4["표시 적음→내부 링크로 보강"]
    d3 --> d0
    d4 --> d0

그림13: SEO는 쓰고 끝이 아니라, 데이터를 보고 고치는 루프에서 먹혀 옵니다.

「클릭률이 낮다」는 몇 %부터인가

여기서 반드시 나오는 질문이 이것입니다.

솔직히 말해 업종이나 검색어를 가로질러 통하는 절대적 임계값은 Google에서 공표되지 않았습니다. 같은 CTR 3%라도 평균 게재 순위가 1위면 분명히 낮고, 9위면 오히려 보통입니다. 밖에서 가져온 벤치마크 값을 대입하면 대개 오진합니다.

대신 자사 사이트 안에서 상대 비교해 기준선을 만드는 쪽이 실용적입니다. Search Console의 Performance 리포트는 쿼리나 페이지마다 표시 횟수, 클릭 수, CTR, 평균 게재 순위를 동시에 낼 수 있습니다.²⁸

화면으로는 왼쪽 메뉴의 「검색 실적」에서 「검색결과」를 열고, 위쪽 지표 카드에서 「평균 CTR」과 「평균 게재순위」를 표시에 더한 뒤, 아래 「페이지」 탭을 봅니다. 절차는 이렇습니다.

1. 기간을 3개월 정도로 넓히고, 표시 횟수가 일정 수 이상인 페이지만 좁힌다(표시 횟수가 적으면 CTR은 쉽게 튀니다)
2. 평균 게재 순위로 그룹을 만든다(1〜3위, 4〜10위, 11위 이하 등)
3. 같은 순위 그룹 안에서 자사 사이트의 CTR 중앙값을 낸다
4. 그 중앙값을 분명히 밑도는 페이지를 「낮다」로 조사 대상으로 둔다

순위 그룹을 나누는 것이 핵심입니다. 이것을 하지 않으면 「순위가 낮아서 CTR도 낮을 뿐인」 페이지를 제목 문제라고 착각합니다.

flowchart TB
    accTitle: 자사 사이트 안에서 CTR 기준선을 만드는 절차
    accDescr: 절대적 CTR 임계값은 공표되지 않았으므로, 기간을 3개월 정도로 넓혀 표시 횟수가 일정 수 이상인 페이지로 좁히고, 평균 게재 순위로 그룹을 만들고, 같은 순위 그룹 안에서 자사 사이트의 CTR 중앙값을 내어, 그것을 분명히 밑도는 페이지를 조사 대상으로 두는 절차를 나타내는 그림.
    e1["기간을 넓히고, 표시 횟수가 일정 수 이상인 페이지로 좁힌다"] --> e2["평균 게재 순위로 그룹을 만든다"]
    e2 --> e3["같은 순위 그룹 안에서 CTR 중앙값을 낸다"]
    e3 --> e4["중앙값을 분명히 밑도는 페이지를 조사 대상으로 둔다"]
    e2 -.-> e5["순위 그룹을 나누지 않으면 순위 탓인 CTR 저하를 오진한다"]

그림14: CTR의 높낮이는 외부 임계값이 아니라, 자사 사이트의 순위 그룹 안에서 비교합니다.

같은 생각은 반대쪽 판단에도 쓸 수 있습니다. 「표시 횟수는 많은데, 그 페이지가 자사의 어느 서비스에도 이어지지 않는다」면 내부 링크 문제입니다. CTR 숫자를 보기 전에, 그 페이지에서 다음에 어디로 갈 수 있는지를 보는 편이 빠를 때도 있습니다.

3.11 AI Overviews / AI Mode 시대에도, 할 일은 기본적으로 같다

Google의 최신 가이드에서도 AI features에 나오기 위한 특별한 스키마나 전용 최적화는 불필요하며, 기존의 SEO 베스트 프랙티스가 그대로 중요하다고 되어 있습니다.²¹

AI 시대라고 해서,

• 정체 모를 AI용 태그를 더한다
• AI용 별도 파일을 만든다
• AI 요약만 의식한 부자연스러운 문장으로 만든다

필요는 없습니다.

오히려 Google의 설명은 반대이며,

• crawl을 허용한다
• 내부 링크로 찾기 쉽게 한다
• 중요 콘텐츠를 텍스트로 가진다
• page experience를 갖춘다
• 구조화 데이터를 visible text와 일치시킨다

같은 기본을 권합니다.²¹

또한 AI features에서의 유입도 Search Console의 전체 데이터에 포함됩니다.²¹ 따라서 SEO를 보는 법 자체를 크게 바꾸기보다, 검색 전체에서 도움이 되는 페이지를 만드는 방향이 자연스럽습니다.

flowchart TB
    accTitle: AI 시대 SEO에서 할 일
    accDescr: AI features에 나오기 위한 특별한 스키마나 전용 최적화는 불필요하며, crawl을 허용하고 내부 링크로 찾기 쉽게 하고 중요 콘텐츠를 텍스트로 가지며 page experience를 갖추고 구조화 데이터를 보이는 텍스트와 일치시킨다는 기존 SEO 기본이 그대로 중요하다는 것을 나타내는 그림.
    n1["AI용 특별한 태그나 전용 파일"] -.-> n2["불필요"]
    n3["기존 SEO의 기본"] --> n4["crawl 허용·내부 링크·텍스트로 가진다"]
    n4 --> n5["page experience와 구조화 데이터의 일치"]
    n5 --> n6["검색 전체에서 도움이 되는 페이지를 만든다"]

그림15: AI Overviews 시대에도, 할 일은 기존 SEO의 기본과 같습니다.

3장의 요점

• 누구의, 어떤 장면을 위한 페이지인지를 정한 뒤에 쓴다. 여기가 모호한 페이지는 유입이 있어도 문의에 닿지 않는다
• AI는 원고 공수를 줄이기 위해 쓰는 것이지, 가치의 대용이 되지 않는다
• 페이지 역할을 서비스 / 사례 / 글 / 문의의 4층으로 나누고, 글에서 사례와 서비스로 흘린다
• 내부 링크는 「여기」가 아니라, 도착지가 보이는 앵커 텍스트로 둔다
• 제목, meta description, URL, canonical은 페이지 고유로 한다
• 나온 데이터로 고친다. CTR의 높낮이는 외부 임계값이 아니라, 같은 순위 그룹 안의 중앙값과 비교해 판단한다

4. Google 광고의 베스트 프랙티스

4.1 가장 먼저 할 일은 「광고」가 아니라 「측정」

Google Ads의 공식 가이드에서도 먼저 중시되는 것은 정확한 conversion 데이터를 바탕으로 자동 입찰을 돌리는 것입니다.⁴¹¹

여기서 말하는 conversion은 기술계 B2B 사이트라면 단순한 pageview가 아닙니다.

예를 들면,

• 문의 폼 제출
• 자료 청구
• 상담 예약
• 전화 발신
• 첫 미팅 설정
• MQL / SQL 도달
• 수주 가망이 있는 오프라인 전환

처럼 사업에 의미 있는 행동을 두어야 합니다.

flowchart TB
    accTitle: conversion에 둘 것
    accDescr: 기술계 B2B 사이트의 conversion은 단순한 pageview가 아니라, 문의 폼 제출이나 자료 청구, 상담 예약, 첫 미팅 설정처럼 사업에 의미 있는 행동을 두어야 하며, 그것을 토대로 자동 입찰이 돌아간다는 것을 나타내는 그림.
    v0["conversion의 정의"] -.->|"두지 않는다"| v1["단순한 pageview"]
    v0 -->|"두어야 할 것"| v2["문의 제출·자료 청구·상담 예약 등의 행동"]
    v2 --> v3["정확한 conversion 데이터를 토대로 자동 입찰이 돌아간다"]

그림16: 가장 먼저 정하는 것은, 사업에 의미 있는 행동으로서의 conversion입니다.

나아가 Google은 측정 기반으로 다음을 명시적으로 권합니다.

• 강한 tagging foundation
• enhanced conversions
• Consent Mode
• conversion value 전송
• 자사에게 source of truth인 것을 Google Ads로 가져오는 것

⁴⁶⁷

결국 광고 운용의 토대는,

태그가 올바르게 들어가 있는가 동의 관리와 정합하는가 정말 보고 싶은 전환을 측정하고 있는가

입니다.

여기가 약한 채로 키워드나 입찰만 만져도 개선 폭은 작습니다.

flowchart TB
    accTitle: 광고 운용 토대의 세 질문
    accDescr: 광고 운용의 토대는 태그가 올바르게 들어가 있는가, 동의 관리와 정합하는가, 정말 보고 싶은 전환을 측정하고 있는가의 세 가지이며, 여기가 약한 채로 키워드나 입찰만 만져도 개선 폭은 작다는 것을 나타내는 그림.
    f1["태그가 올바르게 들어가 있는가"] --> f2["동의 관리와 정합하는가"]
    f2 --> f3["정말 보고 싶은 전환을 측정하고 있는가"]
    f3 --> f4["여기가 토대"]
    f4 -.-> f5["약한 채로 키워드나 입찰을 만져도 개선 폭은 작다"]

그림17: 가장 먼저 할 일은 광고가 아니라, 이 세 질문으로 측정을 굳히는 것입니다.

4.2 enhanced conversions와 Consent Mode는 뒤로 미루지 않는다

Google은 enhanced conversions를 측정 정밀도를 개선하고, 더 강한 입찰을 가능하게 하는 기능이라고 설명합니다. 이는 이메일 주소 같은 first-party customer data를 해시화해 보내는 구조입니다.⁶

또한 Consent Mode는 사용자의 동의 상태를 Google에 전해, 태그의 동작을 조정하는 구조라고 되어 있습니다. Consent Mode 자체가 동의 배너를 제공하는 것은 아니며, 자사의 배너 / CMP와 연동해 움직입니다.⁷

현장에서는 이 둘을 「대기업용」으로 보고 뒤로 미루기 쉽습니다. 하지만 지금은 오히려 반대로, 작은 계정일수록 관측 가능한 데이터를 정성껏 쌓는 것이 중요합니다.

flowchart TB
    accTitle: enhanced conversions와 Consent Mode의 위치
    accDescr: enhanced conversions는 이메일 주소 같은 first-party 데이터를 해시화해 보내 측정 정밀도를 개선하는 기능이고, Consent Mode는 사용자의 동의 상태를 Google에 전해 태그의 동작을 조정하는 구조이며, 둘 다 대기업용이 아니라 작은 계정일수록 먼저 갖추어야 한다는 것을 나타내는 그림.
    g1["enhanced conversions"] --> g2["해시화한 first-party 데이터를 보낸다"]
    g3["Consent Mode"] --> g4["동의 상태를 전해 태그의 동작을 조정"]
    g2 --> g5["관측 가능한 데이터를 정성껏 쌓는다"]
    g4 --> g5
    g5 -.-> g6["작은 계정일수록 뒤로 미루지 않는다"]

그림18: 이 둘은 「대기업용」이 아니라, 작은 계정일수록 먼저 갖춥니다.

4.3 키워드보다 먼저, landing page를 정한다

Google 광고는 키워드 이야기로 보이지만, 실제로는 어느 검색 의도를 어느 페이지로 보낼지가 먼저입니다.

Google도 landing page 체험을 Quality Score의 요소 중 하나로 두고, 페이지의 usefulness / relevance / navigation 등이 관련된다고 설명합니다. 나아가 최종 URL의 landing page와 display URL은 동일 도메인이어야 합니다.⁸⁹

따라서 기술계 B2B 사이트에서는 먼저 다음을 정하는 편이 앞입니다.

• Windows앱 개발을 찾는 사람은 어느 페이지로 보낼지
• 기존 Windows 소프트의 개수를 찾는 사람은 어느 페이지로 보낼지
• 기술 상담·설계 리뷰를 찾는 사람은 어느 페이지로 보낼지
• COM / ActiveX 이전을 찾는 사람은 어느 페이지로 보낼지

이것을 정하지 않은 채로 광고를 내면 대개 전부 홈으로 보내게 됩니다. 그리고 그 구성은 꽤 약합니다.

flowchart TB
    accTitle: 키워드보다 먼저 landing page
    accDescr: Google 광고는 키워드 이야기로 보이지만 실제로는 어느 검색 의도를 어느 페이지로 보낼지가 먼저이며, landing page 체험은 Quality Score의 요소이기도 하고, 도착지를 정하지 않은 채로 광고를 내면 전부 홈으로 보내는 꽤 약한 구성이 된다는 것을 나타내는 그림.
    h1["어느 검색 의도를 어느 페이지로 보낼지"] -->|"먼저 정한다"| h2["의도마다 착지 페이지가 정해진다"]
    h1 -.->|"정하지 않은 채로 게재"| h3["전부 홈으로 보내는 약한 구성이 된다"]
    h2 --> h4["LP 체험은 Quality Score의 요소 중 하나이기도 하다"]

그림19: 광고는 키워드보다 먼저, 의도와 도착지 페이지의 대응을 정합니다.

4.4 광고 그룹은 「검색 의도」와 「LP」로 가른다

너무 잘게 나누는 것도, 너무 거칠게 나누는 것도 좋지 않습니다. 기술계 B2B라면 다음처럼 의도와 LP를 맞추는 가르기가 다루기 쉽습니다.

• Windows앱 개발 계열
• 기존 소프트 개수 계열
• 기술 상담 / 설계 리뷰 계열
• 기존 자산 이전 계열

이 가르기의 이점은 다음이 맞춰진다는 점입니다.

• 검색어
• 광고문
• LP 제목
• 사례
• 문의 CTA

반대로 하나의 광고 그룹에

• Windows 앱 개발
• COM 이전
• 불량 조사
• VBA 연동
• 산업용 카메라

를 전부 넣으면, 무엇이 먹혔는지 보기 어려워집니다.

flowchart TB
    accTitle: 광고 그룹을 가르는 법
    accDescr: 광고 그룹은 검색 의도와 landing page를 맞춰 가르면 검색어·광고문·LP 제목·사례·문의 CTA가 맞춰지고, 반대로 다른 테마를 하나의 광고 그룹에 전부 넣으면 무엇이 먹혔는지 보기 어려워진다는 것을 나타내는 그림.
    i1["검색 의도와 LP로 광고 그룹을 가른다"] --> i2["검색어·광고문·LP 제목이 맞춰진다"]
    i2 --> i3["사례와 문의 CTA까지 한 줄이 된다"]
    i4["다른 테마를 한 그룹에 전부 넣는다"] -.-> i5["무엇이 먹혔는지 보기 어려워진다"]

그림20: 광고 그룹은 의도와 LP의 단위로 맞춰 가릅니다.

4.5 Responsive Search Ads는 「일단 1개」로는 약하다

Google은 각 광고 그룹에 적어도 1개, Ad Strength가 Good 또는 Excellent인 Responsive Search Ad를 넣을 것을 베스트 프랙티스로 안내합니다.⁵

다만 단순히 headline 개수를 채우는 것이 목적은 아닙니다.

기술계 B2B라면 예를 들어 다음 축으로 variation을 만들면 강해집니다.

• 누구를 향한가 예: 기존 Windows 소프트의 개수에
• 무엇을 해결하는가 예: 전면 쇄신 없이 단계 이전
• 무엇이 강점인가 예: COM / ActiveX / 32bit / 64bit에 대응
• 어떻게 진행하는가 예: 먼저 설계 정리부터 상담 가능
• CTA 예: 기술 상담은 여기

광고문은 검색어를 바꿔 말하기에 머물지 말고, 상담하는 이유의 압축판으로 만드는 것이 좋습니다.

flowchart TB
    accTitle: 반응형 검색 광고의 variation 만드는 법
    accDescr: 반응형 검색 광고는 제목 개수를 채우는 것이 목적이 아니라, 누구를 향한가·무엇을 해결하는가·무엇이 강점인가·어떻게 진행하는가·CTA라는 축으로 variation을 만들고, 검색어를 바꿔 말하기가 아니라 상담하는 이유의 압축판으로 광고문을 만들면 강해진다는 것을 나타내는 그림.
    j0["제목 개수를 채운다"] -.-> j1["그 자체는 목적이 아니다"]
    j2["variation의 축"] --> j3["누구를 향한가·무엇을 해결하는가"]
    j2 --> j4["무엇이 강점인가·어떻게 진행하는가·CTA"]
    j3 --> j5["상담하는 이유의 압축판으로서의 광고문"]
    j4 --> j5

그림21: RSA는 축을 갖고 variation을 만들며, 상담하는 이유를 압축해 전합니다.

4.6 Smart Bidding은 강하지만, 전제를 빼면 위태롭다

Google은 Smart Bidding을 conversion이나 conversion 값에 최적화하는 자동 입찰이라고 설명하며, auction-time signals를 써서 입찰을 최적화한다고 합니다.¹¹

또한 Google의 계정 설정 베스트 프랙티스에서는 broad match, Smart Bidding, responsive search ads의 조합이 밀립니다.⁴

다만 여기서 중요한 것은 순서입니다.

• conversion 정의가 거칠다
• 태그가 깨져 있다
• LP가 약하다
• 문의의 질이 낮다
• 무엇을 가치로 볼지 정해져 있지 않다

이 상태에서 broad match를 넓게 쓰면, 학습 재료가 나쁜 채로 자동화를 강하게 하게 됩니다.

그래서 현실적으로는 다음 순으로 생각하면 무너지기 어렵습니다.

1. conversion을 정의한다
2. 태그와 Consent Mode를 갖춘다
3. LP를 갖춘다
4. 고의도 테마로 캠페인을 시작한다
5. 검색어를 보면서 낭비를 깎는다
6. 그다음에 자동화를 강하게 한다

flowchart TB
    accTitle: 자동화를 강하게 하기 전의 순서
    accDescr: conversion을 정의하고, 태그와 Consent Mode를 갖추고, LP를 갖추고, 고의도 테마로 캠페인을 시작하고, 검색어를 보면서 낭비를 깎은 뒤, 그다음에 자동화를 강하게 한다는 순으로 생각하면 무너지기 어렵고, 측정이 약한 채로 broad match를 넓히면 나쁜 재료 그대로 자동화를 강하게 하게 된다는 것을 나타내는 그림.
    o1["1. conversion을 정의"] --> o2["2. 태그와 Consent Mode를 갖춘다"]
    o2 --> o3["3. LP를 갖춘다"]
    o3 --> o4["4. 고의도 테마로 시작한다"]
    o4 --> o5["5. 검색어를 보고 낭비를 깎는다"]
    o5 --> o6["6. 그다음에 자동화를 강하게 한다"]
    o1 -.-> o7["측정이 약한 채로 넓히면 나쁜 재료로 학습한다"]

그림22: Smart Bidding과 broad match는 이 순서를 지킨 뒤에 강하게 합니다.

4.7 Search terms report는 반드시 본다

Google은 search terms report를 광고를 띄운 실제 검색어와 그 성과를 아는 리포트라고 설명합니다. 나아가 creative나 landing page의 개선 아이디어에도 쓸 수 있다고 합니다.²⁹

여기는 광고 운용의 요지입니다.

이 리포트를 보면,

• 생각한 대로의 검색에 나오고 있는가
• 불필요한 검색에 나오고 있지 않은가
• LP 문구와 검색 의도가 어긋나지 않았는가
• 새로 갈라내야 할 테마가 없는가

가 보입니다.

또한 Search terms insights는 어구를 테마나 subtheme으로 묶어 보여 주므로, 수요의 묶음을 보는 데 맞습니다.²⁹

즉 광고는 집객 수단인 동시에 수요 조사 장치이기도 합니다.

flowchart TB
    accTitle: search terms report의 쓰는 법
    accDescr: search terms report에서는 광고를 띄운 실제 검색어와 그 성과를 알 수 있고, 생각한 대로의 검색에 나오고 있는지, 불필요한 검색에 나오고 있지 않은지, LP 문구와 검색 의도가 어긋나지 않았는지, 새로 갈라내야 할 테마가 없는지가 보이므로, 광고는 집객 수단인 동시에 수요 조사 장치이기도 하다는 것을 나타내는 그림.
    p1["search terms report를 본다"] --> p2["실제 검색어와 성과가 보인다"]
    p2 --> p3["불필요한 검색이나 의도 어긋남을 찾는다"]
    p2 --> p4["새로 갈라내야 할 테마를 찾는다"]
    p3 --> p5["광고는 집객 수단이자 수요 조사 장치"]
    p4 --> p5

그림23: 검색어 리포트는 광고 운용의 요지이며, 수요 조사 장치이기도 합니다.

4.8 Quality Score는 「진단」에 쓴다

Google은 Quality Score를 광고 품질을 파악하기 위한 진단 도구라고 설명하며, KPI가 아니고, 경매의 입력값도 아니다고 명시합니다.⁹

이 위치는 놓치기 쉽지만, 중요한 곳입니다.

Quality Score를 볼 의미는 있습니다. 다만 그것은 개선점의 방향을 보기 위해서입니다.

볼 것은 주로 다음입니다.

• expected CTR
• ad relevance
• landing page experience

⁹

Quality Score 자체를 쫓는 것이 아니라,

• 광고문이 intent에 맞는가
• LP가 도움이 되는가
• 검색어에 대해 promise가 맞는가

를 고치기 위한 보조 정보로 쓰는 것이 자연스럽습니다.

flowchart TB
    accTitle: Quality Score의 올바른 쓰는 법
    accDescr: Quality Score는 KPI도 경매 입력값도 아닌 진단 도구이며, expected CTR·ad relevance·landing page experience를 보고, 광고문이 의도에 맞는지, LP가 도움이 되는지를 고치기 위한 보조 정보로 쓰는 것이 자연스럽다는 것을 나타내는 그림.
    q0["Quality Score"] -.-> q1["KPI나 경매 입력값이 아니다"]
    q0 --> q2["진단 도구로 본다"]
    q2 --> q3["expected CTR / ad relevance / LP experience"]
    q3 --> q4["광고문과 LP를 고치기 위한 보조 정보에 쓴다"]

그림24: Quality Score는 쫓는 숫자가 아니라, 고칠 곳을 찾는 진단입니다.

4장의 요점

• 순서는 conversion 정의 → 태그와 Consent Mode → LP → 키워드 / 검색어 → 광고문 → 입찰
• conversion은 pageview가 아니라, 문의 제출이나 상담 예약처럼 사업상의 행동을 둔다
• enhanced conversions와 Consent Mode는 「대기업용」이 아니다. 작은 계정일수록 먼저 갖춘다
• 광고 그룹은 검색 의도와 LP로 맞춰 가른다
• Smart Bidding과 broad match는 강하지만, 측정이 약한 채로 두면 나쁜 재료로 학습한다
• search terms report는 운용의 요지이며, 동시에 수요 조사 장치이기도 하다
• Quality Score는 KPI가 아니라 진단 도구. 볼 것은 expected CTR, ad relevance, landing page experience

5. SEO와 Google 광고를 어떻게 연계하는가

SEO와 Google 광고는 별도 팀·별도 시책으로 단절되기 쉽습니다. 하지만 실무에서 강한 것은 같은 검색 수요를 양쪽에서 이해하고 있는 상태입니다.

5.1 광고에서 알게 된 수요를 SEO로 되돌린다

Google 광고에서는 search terms report가 바로 보입니다. 거기서 반응이 좋았던 검색 테마는 SEO의 글이나 서비스 페이지 강화의 우선 후보가 됩니다.²⁹

예를 들어 광고에서,

• 기존 windows 소프트 개수
• activeX 이전
• windows 앱 설계 리뷰

가 강하다고 알았다면, SEO 쪽에서도

• 서비스 페이지 제목
• 사례 제목
• 기술 글 테마
• FAQ
• meta description

에 반영하기 쉬워집니다.

flowchart TB
    accTitle: 광고에서 알게 된 수요를 SEO로 되돌린다
    accDescr: search terms report에서 반응이 좋았던 검색 테마는 SEO 쪽의 서비스 페이지 제목·사례 제목·기술 글 테마·FAQ·meta description으로 반영하는 우선 후보가 된다는 것을 나타내는 그림.
    r1["search terms report에서 반응이 좋은 말이 보인다"] --> r2["SEO의 우선 후보가 된다"]
    r2 --> r3["서비스 페이지 제목이나 사례 제목으로 반영"]
    r2 --> r4["기술 글 테마·FAQ·meta description으로 반영"]

그림25: 광고에서 보인 수요는 SEO 쪽의 제목·글·FAQ로 되돌립니다.

5.2 SEO로 키운 페이지가 광고의 계약률을 받친다

반대로 SEO로 만든 페이지 군은 Google 광고에서도 먹힙니다.

예를 들어 LP에,

• 관련 기술 글
• 도입 사례
• FAQ
• 대표자나 회사 정보
• 상담의 진행 방식

이 있으면, 광고 경유 방문에서도 불안을 줄이기 쉬워집니다.

SEO는 무료 유입만을 위한 것이 아니라, 광고의 landing page experience와 설득 재료를 강하게 하는 자산이기도 합니다.

flowchart TB
    accTitle: SEO 자산이 광고를 받친다
    accDescr: SEO로 만든 관련 기술 글·도입 사례·FAQ·회사 정보·상담의 진행 방식이 LP 주변에 있으면 광고 경유 방문에서도 불안을 줄이기 쉽고, SEO는 무료 유입만이 아니라 광고의 landing page experience와 설득 재료를 강하게 하는 자산이기도 하다는 것을 나타내는 그림.
    s1["SEO로 키운 페이지 군"] --> s2["관련 글·사례·FAQ·회사 정보"]
    s2 --> s3["광고 경유 방문에서도 불안이 줄어든다"]
    s3 --> s4["landing page experience와 설득 재료가 강해진다"]

그림26: SEO로 키운 자산은 광고의 계약률을 받치는 쪽에서도 일합니다.

5.3 Search Console과 Google 광고로 「같은 테마」를 본다

Search Console에서는 어떤 query로 표시되고, 어느 페이지가 클릭되었는지를 볼 수 있습니다.²⁸ Google 광고에서는 어떤 검색어로 광고가 표시되고, 무엇이 conversion했는지를 볼 수 있습니다.²⁹

이 둘을 나란히 두면 같은 테마에 대해

• SEO에서 강한가
• 광고에서 강한가
• 둘 다 약한가
• 서비스 페이지보다 글이 먼저 평가되고 있는가

가 보입니다.

이 비교는 다음 우선순위를 정하는 데 꽤 편리합니다.

flowchart TB
    accTitle: Search Console과 광고로 같은 테마를 본다
    accDescr: Search Console에서는 어떤 query로 표시되고 어느 페이지가 클릭되었는지를 보고, Google 광고에서는 어떤 검색어로 광고가 표시되고 무엇이 conversion했는지를 보므로, 둘을 나란히 두면 같은 테마가 SEO에서 강한지 광고에서 강한지 둘 다 약한지가 보여 다음 우선순위를 정하기 쉽다는 것을 나타내는 그림.
    t1["Search Console (query·페이지·클릭)"] --> t3["같은 테마를 나란히 본다"]
    t2["Google 광고 (검색어·conversion)"] --> t3
    t3 --> t4["SEO에서 강함 / 광고에서 강함 / 둘 다 약함이 보인다"]
    t4 --> t5["다음 우선순위가 정해진다"]

그림27: 같은 검색 수요의 두 가지 보이는 방식을 나란히 두면, 우선순위가 보입니다.

6. 기술계 B2B 사이트라면, 무엇을 주역으로 두어야 하는가

기술계 B2B 사이트는 EC나 미디어와 이기는 법이 다릅니다.

검색 볼륨이 큰 일반 워드보다,

• 문제가 깊다
• 단가가 높다
• 비교 검토가 길다
• 하지만 검색 수는 많지 않다

는 테마가 많기 때문입니다.

그래서 주역은 서비스 페이지입니다. 글은 주역이 아니라, 서비스 페이지를 강하게 하는 주변 자산으로 쓰는 편이 맞물립니다.

6.1 서비스 페이지를 먼저 강하게 한다

기술계 사이트에서 흔한 실패는 블로그 글만 늘고 서비스 페이지가 얇은 것입니다.

하지만 실제로 문의가 필요하다면, 먼저 강하게 해야 하는 것은 3.3의 제1층에 든 서비스 페이지입니다. 즉 지금 당장 상담처를 찾는 사람이 착지하는 페이지입니다.

여기서 필요한 것은,

• 무엇을 맡길 수 있는가
• 어떤 안건에 맞는가
• 어떤 진행 방식인가
• 무엇을 남기고, 무엇을 바꾸는 생각인가
• 상담 때 무엇을 전하면 되는가

입니다.

flowchart TB
    accTitle: 먼저 강하게 하는 것은 서비스 페이지
    accDescr: 기술계 사이트에서 흔한 실패는 블로그 글만 늘고 서비스 페이지가 얇은 것이며, 문의가 필요하다면 지금 당장 상담처를 찾는 사람이 착지하는 서비스 페이지를 먼저 강하게 해야 한다는 것을 나타내는 그림.
    u1["블로그 글만 늘어난다"] -.-> u2["서비스 페이지가 얇으면 문의에 닿지 않는다"]
    u3["지금 당장 상담처를 찾는 사람"] --> u4["착지하는 것은 서비스 페이지"]
    u4 --> u5["무엇을 맡길 수 있는지·진행 방식·궁합을 분명히 한다"]

그림28: 글보다 먼저, 상담자가 착지하는 서비스 페이지를 강하게 합니다.

6.2 사례 페이지는 강하다

기술계 안건은 문장만이 아니라 전례가 꽤 먹힙니다.

• 기존 자산을 버리지 않고 어떻게 진행했는가
• 32bit / 64bit를 어디에서 넘었는가
• 불량 조사를 어떻게 갈라냈는가
• UI / 통신 / 백그라운드 처리를 어떻게 나눴는가

같은 이야기는 영업 자료보다 사례가 전해지는 경우가 많습니다.

SEO적으로도 사례는 고유 정보가 많고, 비슷한 페이지가 되기 어렵습니다.

6.3 블로그는 「손님 끌기」가 아니라 「판단 재료」로 둔다

기술 글은 PV를 가져가기보다 상담 한 걸음 전의 판단 재료에 맞추는 편이 강합니다.

예를 들면 이런 역할 나누기입니다.

• 비교 글 예: WinForms / WPF / WinUI의 고르는 법
• 판단 글 예: VBA는 바꿔야 하는가
• 문제 해결 글 예: 관리자 권한이 필요해지는 때는 언제인가
• 구현 글 예: Media Foundation으로 카메라에서 이미지를 가져오는 방법

이런 글은 SEO의 입구가 될 뿐 아니라, 「이 회사는 표면적인 이야기가 아니라, 실무의 논점으로 생각하고 있다」고 전해집니다.

flowchart TB
    accTitle: 블로그 글의 역할
    accDescr: 기술 글은 PV를 가져가기보다 상담 한 걸음 전의 판단 재료에 맞추는 편이 강하며, 비교·판단·문제 해결·구현 글은 SEO의 입구가 될 뿐 아니라 실무의 논점으로 생각하는 회사라고 전해진다는 것을 나타내는 그림.
    w0["기술 글의 겨냥"] -.->|"맞추지 않는다"| w1["PV를 위한 손님 끌기"]
    w0 -->|"맞춘다"| w2["상담 한 걸음 전의 판단 재료"]
    w2 --> w3["SEO의 입구가 된다"]
    w2 --> w4["실무의 논점으로 생각하는 회사라고 전해진다"]

그림29: 글은 손님 끌기가 아니라 판단 재료로 쓰면 입구와 신뢰 둘 다가 됩니다.

6.4 이것을 자사에 바꾸는 절차

여기까지의 설명도 다음 7장도, 예로서 comcomponent.com을 씁니다. 다만 할 일 자체는 업종이 바뀌어도 같습니다. 다음 4단계로 자사 버전으로 바꿀 수 있습니다.

스텝 1: 제공하고 있는 것을, 발주 쪽 말로 훑는다

사내 호칭이 아니라 상담하러 오는 사람이 쓰는 말로 적어 냅니다. 여기서 사내 용어나 제품 코드명을 쓰면, 이후의 검색 의도 가설이 통째로 어긋납니다.

나누는 단위의 가늠은 1 서비스 = 1개의 강한 상담 의도입니다. 너무 잘게 나누면 착지 페이지가 얇아지고, 너무 거칠면 검색 의도와 맞물리지 않습니다.

스텝 2: 서비스마다, 검색 의도의 가설을 세운다

훑어 낸 각 서비스에 대해 다음 표를 한 장씩 채웁니다. 이 시점에서는 가설이면 되고, 정답일 필요는 없습니다. 나중에 search terms report와 Search Console이 답을 맞춰 줍니다.²⁹²⁸

가령 업무용 재고 관리 시스템을 만드는 회사라면, 「기존 시스템의 개수」라는 서비스에 대해 상황은 「다시 만들 예산은 없지만 지금 업체가 대응해 주지 않는다」, 검색어는 「재고 관리 시스템 개수 위탁」「기간 시스템 인수 개발 회사」 정도, 라는 채우기가 됩니다.

스텝 3: 검색어를 「상담 의도」와 「학습 의도」로 가른다

스텝 2에서 낸 검색어를 2장의 나누는 법에 따라 나눕니다.

판단이 애매한 말은 실제로 그 말로 검색해 상위에 나온 페이지의 형을 보면 빠릅니다. 서비스 소개 페이지가 많으면 상담 의도, 해설 글이 많으면 학습 의도입니다.

스텝 4: 모자란 페이지를 하나만 정해 착수한다

전부 맞추려 하면 대개 중간에 멈춥니다. 스텝 2의 표에서 「착지시키고 싶은 페이지가 없다」고 쓴 행 중, 가장 상담 의도가 짙은 것 하나부터 만듭니다.

여기까지 정해지면 9장의 90일 플랜에 그대로 합류할 수 있습니다.

flowchart TB
    accTitle: 자사에 바꾸는 4스텝
    accDescr: 제공하고 있는 것을 발주 쪽 말로 훑고, 서비스마다 검색 의도의 가설을 세우고, 검색어를 상담 의도와 학습 의도로 가르고, 모자란 페이지를 하나만 정해 착수한다는 4스텝으로 자사 버전으로 바꿔 90일 플랜에 합류할 수 있다는 것을 나타내는 그림.
    v1["스텝1: 발주 쪽 말로 제공물을 훑는다"] --> v2["스텝2: 서비스마다 검색 의도의 가설을 세운다"]
    v2 --> v3["스텝3: 상담 의도와 학습 의도로 가른다"]
    v3 --> v4["스텝4: 모자란 페이지를 하나만 정해 착수"]
    v4 --> v5["90일 플랜에 합류"]

그림30: 업종이 바뀌어도 할 일은 같고, 이 4스텝으로 자사 버전이 됩니다.

7. comcomponent.com이라면 이렇게 짠다

여기부터는 6.4의 4스텝을 실제로 한 회사에 대입하면 어떻게 되는지의 예입니다. 자사에 바꿔 읽을 때는 서비스명과 검색 의도의 내용만 바꾸면, 구조는 그대로 쓸 수 있습니다.

comcomponent.com은 이미

• 서비스 페이지
• 기술 사례
• 기술 블로그
• 문의

라는 기본 구조를 갖고 있습니다. 이 토대는 꽤 좋습니다.

여기서 문의로 잇기 위해서는 다음 짜임이 자연스럽습니다.

7.1 먼저, 주력 서비스마다 검색 의도를 고정한다

서비스 페이지를 중심으로 다음 테마를 명확히 합니다.

Windows앱 개발

가져가고 싶은 검색 의도:

• 신규로 Windows 소프트를 만들고 싶다
• 장치 연동 도구를 만들고 싶다
• 감시 / 통신 / 장표를 포함한 업무 앱을 만들고 싶다

기술 상담·설계 리뷰

가져가고 싶은 검색 의도:

• 방침 정리만 상담하고 싶다
• 구현 전에 설계를 봐 주었으면 한다
• 기존 자산을 남길지 / 감쌀지 / 바꿀지의 판단이 필요하다

기존 Windows 소프트의 개수·보수

가져가고 싶은 검색 의도:

• 다시 만들기가 아니라 개수하고 싶다
• 기존 소프트를 연명하고 싶다
• 장애 대응하면서 조금씩 다듬고 싶다

기존 자산 활용·이전 지원

가져가고 싶은 검색 의도:

• COM / ActiveX / OCX를 포함한 구성을 정리하고 싶다
• 32bit / 64bit 문제를 넘고 싶다
• 단계 이전의 다리를 만들고 싶다

이렇게 1 서비스 페이지 = 1개의 강한 상담 의도로 보면, SEO도 광고도 흔들리기 어려워집니다.

flowchart TB
    accTitle: 1 서비스 페이지=1개의 강한 상담 의도
    accDescr: 주력 서비스마다 가져가고 싶은 검색 의도를 고정하고, 1 서비스 페이지에 1개의 강한 상담 의도를 대응시키면 SEO도 광고도 흔들리기 어려워진다는 것을 나타내는 그림.
    x1["주력 서비스 페이지"] --> x2["가져가고 싶은 검색 의도를 하나로 고정한다"]
    x2 --> x3["SEO의 제목·글의 묶는 법이 정해진다"]
    x2 --> x4["광고의 말 묶음과 도착지가 정해진다"]
    x3 --> x5["SEO도 광고도 흔들리지 않는다"]
    x4 --> x5

그림31: 의도를 하나로 고정한 서비스 페이지가, SEO와 광고의 공통 축이 됩니다.

7.2 글은 서비스 페이지 주변에 묶는다

블로그 글은 단발로 늘리기보다, 서비스 페이지 주변에 묶습니다.

예를 들어 기존 자산 활용·이전 지원을 부모로 둔다면,

• VBA는 앞으로 못 쓰게 되는가
• ActiveX / OCX를 지금 어떻게 다루는가
• .NET으로 이전하기 전에 확인할 것
• 32bit / 64bit 문제를 어떻게 가르는가

같은 글 군으로 감싸면 테마의 묶음이 나옵니다.

기술 상담·설계 리뷰를 부모로 둔다면,

• 관리자 권한이 필요한 처리만 어떻게 분리하는가
• 예외 설계나 로그 설계를 어떻게 생각하는가
• 스레드 / 수명 / 자식 프로세스 설계를 어떻게 정리하는가

처럼 맞출 수 있습니다.

이 형태가 되면, 글 단독으로는 정보 수집이어도, 사이트 전체로는 이 테마에 강한 회사라고 전해집니다.

flowchart TB
    accTitle: 글을 서비스 페이지 주변에 묶는다
    accDescr: 블로그 글은 단발로 늘리는 것이 아니라, 부모가 되는 서비스 페이지 주변에 테마가 가까운 글 군으로 묶으면 테마의 묶음이 나오고, 글 단독으로는 정보 수집이어도 사이트 전체로는 이 테마에 강한 회사라고 전해진다는 것을 나타내는 그림.
    y1["부모의 서비스 페이지"] --> y2["테마가 가까운 글 군으로 주변을 감싼다"]
    y2 --> y3["테마의 묶음이 나온다"]
    y3 --> y4["사이트 전체에서 「이 테마에 강한 회사」라고 전해진다"]
    y1 -.-> y5["단발로 글을 늘려도 묶음은 나오지 않는다"]

그림32: 글은 단발이 아니라, 부모 서비스 페이지 주변에 묶습니다.

7.3 Google 광고는 고의도 페이지만부터 시작한다

광고는 모든 테마를 동시에 시작할 필요는 없습니다. 오히려 처음에는 문의 의도가 짙고, 착지 페이지가 강한 테마만으로 좁히는 편이 좋습니다.

예로는 이런 말 묶음입니다.

• Windows 앱 개발 수탁
• 기존 Windows 소프트 개수
• Windows 기술 상담
• 설계 리뷰 Windows 앱
• COM ActiveX 이전

이들은 어디까지나 방향 예이지만, 공통된 것은 상담의 의도가 있다는 점입니다.

반대로 처음부터

• C#
• WPF
• VBA
• Media Foundation

같은 너무 넓은 말로 광고를 넓히면, 교육적 클릭이 많아지기 쉽습니다.

flowchart TB
    accTitle: 광고는 어느 말 묶음부터 시작하는가
    accDescr: 광고는 모든 테마를 동시에 시작할 필요는 없고, 문의 의도가 짙고 착지 페이지가 강한 테마만으로 좁혀 시작하는 것이 좋으며, 반대로 너무 넓은 기술 단어로 처음부터 넓히면 교육적 클릭이 많아지기 쉽다는 것을 나타내는 그림.
    z1{"처음에 내는 말 묶음은"}
    z1 -->|"상담 의도가 짙고 착지 페이지가 강하다"| z2["좁혀 시작한다"]
    z1 -.->|"너무 넓은 기술 단어"| z3["교육적 클릭이 많아지기 쉽다"]
    z2 --> z4["성과를 보고 나서 넓혀 간다"]

그림33: 광고의 시작은 의도의 짙음과 착지 페이지의 강함으로 좁힙니다.

7.4 보낼 곳은 홈이 아니라, 의도에 맞는 페이지

문의를 늘리고 싶을수록 홈에 모으고 싶어집니다. 하지만 Google 광고의 관점에서도 검색 의도에 맞는 landing page가 자연스럽습니다.⁸⁹

따라서 광고의 도착지는 원칙적으로

• 서비스 페이지
• 서비스 특화 LP
• 서비스 + 사례를 모은 페이지

중 하나로 모아야 합니다.

flowchart TB
    accTitle: 광고 도착지를 정하는 법
    accDescr: 문의를 늘리고 싶을수록 홈에 모으고 싶어지지만, 검색 의도에 맞는 landing page가 자연스러우며, 광고의 도착지는 원칙적으로 서비스 페이지·서비스 특화 LP·서비스와 사례를 모은 페이지 중 하나로 모아야 한다는 것을 나타내는 그림.
    a0["광고의 도착지"] -.->|"모으지 않는다"| a1["홈에 모은다"]
    a0 -->|"원칙"| a2["서비스 페이지"]
    a0 -->|"원칙"| a3["서비스 특화 LP"]
    a2 --> a4["서비스+사례를 모은 페이지도 가능"]

그림34: 도착지는 홈이 아니라, 검색 의도에 맞는 페이지로 모읍니다.

7.5 문의까지의 거리를 짧게 한다

기술 글의 끝에,

• 이 테마에 가까운 상담은 여기
• 관련 서비스는 여기
• 사례는 여기
• 문의는 여기

를 매번 두면, 입구에서 출구까지의 선이 보이기 쉬워집니다.

comcomponent.com에는 이미 문의, 기술 사례, 블로그가 있으므로, 글 → 서비스 → 사례 → 문의의 동선을 더 분명히 해 가는 편이 좋습니다.

8. 자주 있는 실패

8.1 블로그만 늘리고, 서비스 페이지가 약하다

검색 유입은 늘어도, 상담하고 싶은 사람이 착지하는 페이지가 얇으면 문의에 닿지 않습니다.

8.2 AI로 비슷한 글을 대량으로 낸다

양은 늘어도 검색 의도마다의 차이가 약해지고, 가치를 더하지 않은 페이지가 늘어납니다. Google의 가이드와도 궁합이 나쁩니다.¹⁸²

8.3 robots.txt로 비공개로 만들려 한다

robots.txt는 검색 결과에서 지우는 구조가 아닙니다. 내고 싶지 않으면 noindex나 인증입니다.¹⁷

8.4 Google 광고를 홈으로 보낸다

검색 의도와 LP가 어긋나, CVR도 learning도 약해집니다.

8.5 conversion 측정이 pageview에 가깝다

문의의 질과 무관한 시그널로 자동화하면 성과가 보이지 않습니다.⁴¹¹

8.6 Quality Score를 KPI로 둔다

Quality Score는 진단용입니다. 점수 자체를 쫓기보다 ad relevance와 landing page experience를 고치는 편이 본래의 방향입니다.⁹

8.7 Search Console과 광고를 별개로 다룬다

둘 다 같은 검색 수요의 다른 보이는 방식입니다. 이어서 보지 않으면 시책이 중복되거나 우선순위가 흔들립니다.

9. 90일 동안 할 일

전부를 한 번에 할 필요는 없습니다. 기술계 B2B 사이트라면 처음 90일은 다음 순으로 충분합니다.

flowchart TB
    accTitle: 90일 플랜의 흐름
    accDescr: 처음 90일은 1〜2주차에 문의의 정의나 사이트맵 등의 토대를 갖추고, 3〜4주차에 측정과 광고의 최소 구성을 만들고, 2개월째에 서비스 페이지로 이어지는 글이나 사례 등 SEO의 버팀을 늘리고, 3개월째에 광고와 SEO의 데이터를 오가게 해 둘을 잇는다는 순으로 진행하면 충분하다는 것을 나타내는 그림.
    n1["1〜2주차: 토대를 갖춘다"] --> n2["3〜4주차: 측정과 광고의 최소 구성을 만든다"]
    n2 --> n3["2개월째: SEO의 버팀을 늘린다"]
    n3 --> n4["3개월째: 광고와 SEO를 잇는다"]

그림35: 90일은 토대→측정과 광고→SEO의 버팀→연계 순으로 진행합니다.

1〜2주차: 토대를 갖춘다

• 문의의 정의를 정한다
• Search Console을 확인한다
• 사이트맵과 robots / noindex의 정리를 한다
• 주력 서비스 페이지의 title / description / CTA를 다시 본다
• 광고에 쓸 landing page를 정한다

3〜4주차: 측정과 광고의 최소 구성을 만든다

• Google Ads의 conversion tracking을 갖춘다
• enhanced conversions를 설정한다
• Consent Mode를 자사의 동의 관리와 맞춘다
• 고의도 테마만으로 검색 광고를 시작한다
• search terms report를 보기 시작한다

2개월째: SEO의 버팀을 늘린다

• 서비스 페이지로 이어지는 기술 글을 3〜5편 추가한다
• 사례 페이지를 늘리거나, 기존 사례를 강화한다
• Organization / Article 등 필요한 structured data를 다시 본다
• 내부 링크를 정리한다

3개월째: 둘을 잇는다

• 광고에서 반응이 좋았던 말을 글이나 LP에 반영한다
• Search Console에서 표시되고 있는 query를 바탕으로 후속 글을 만든다
• 문의에 가까운 페이지의 CTA를 조정한다
• 상담의 질까지 포함해 conversion 정의를 다시 본다

10. 정리

SEO와 Google 광고의 베스트 프랙티스를 한 마디로 말하면, 검색 의도에 맞는 페이지를 만들고, 그 성과를 올바르게 재고, 양쪽 데이터를 오가게 하는 것입니다.

SEO의 기본은 다음과 같습니다. 어느 가이드에 근거한 이야기인지도 나란히 두므로, 원전을 보고 싶을 때는 여기서 따라가십시오.

Google 광고의 기본도 같이 늘어놓으면 이렇게 됩니다.

그리고 기술계 B2B 사이트에서는 글을 늘리는 것 자체를 목적으로 두지 않는 편이 좋습니다.

• 먼저 서비스 페이지를 강하게 한다
• 사례로 신뢰를 보탠다
• 기술 글로 입구를 늘린다
• 광고로 고의도 수요를 수확한다
• Search Console과 Ads의 데이터로 서로 강화한다

이 흐름이 꽤 재현성 높은 진행 방식입니다.

flowchart TB
    accTitle: 재현성 높은 진행 방식
    accDescr: 먼저 서비스 페이지를 강하게 하고, 사례로 신뢰를 보태고, 기술 글로 입구를 늘리고, 광고로 고의도 수요를 수확하고, Search Console과 Ads의 데이터로 서로 강화한다는, 기술계 B2B 사이트에서 재현성 높은 흐름을 나타내는 그림.
    b1["서비스 페이지를 강하게 한다"] --> b2["사례로 신뢰를 보탠다"]
    b2 --> b3["기술 글로 입구를 늘린다"]
    b3 --> b4["광고로 고의도 수요를 수확한다"]
    b4 --> b5["Search Console과 Ads의 데이터로 서로 강화"]
    b5 -.-> b3

그림36: 글을 늘리는 것 자체를 목적으로 두지 않고, 이 순으로 돌리는 것이 재현성 높은 형태입니다.

11. 관련 페이지

• Windows앱 개발
• 기술 상담·설계 리뷰
• 기존 자산 활용·이전 지원
• 기술 사례
• 기술 블로그
• 문의

12. 참고 자료

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

SEO와 Google 광고 중 어느 쪽을 먼저 해야 하나요?

어느 한쪽을 고르는 것이 아니라, 의도가 다른 검색을 따로 가져가는 것입니다. SEO는 자리 잡는 데 시간이 걸리는 대신 축적되기 쉽고, 광고는 빨리 자리 잡는 대신 게재를 멈추면 끊깁니다. 실무에서는 상담에 가까운 고의도 검색은 광고로도 가져가고, 주변의 학습·비교 수요는 SEO로 줍는 역할 나누기가 현실적입니다. SEO는 자산 만들기, Google 광고는 수요 수확과 가설 검증으로 보면 정리하기 쉽습니다.

Google 광고를 시작할 때 가장 먼저 해야 할 일은 무엇인가요?

입찰 기법이 아니라 측정을 갖추는 일입니다. Google 공식에서도 정확한 conversion 데이터, 강한 태그 기반, enhanced conversions, Consent Mode를 중시합니다. conversion은 단순한 pageview가 아니라, 문의 폼 제출이나 상담 예약처럼 사업에 의미 있는 행동을 두어야 합니다. 측정이 약한 채로 키워드나 입찰만 만져도 개선 폭은 작고, broad match나 Smart Bidding의 자동화도 나쁜 재료로 학습하게 됩니다.

AI로 글을 양산하면 SEO에 효과가 있나요?

효과가 적고 위험도 있습니다. Google은 생성 AI 이용 자체를 부정하지는 않지만, 가치를 더하지 않는 대량 생성 콘텐츠는 scaled content abuse 관점에서 스팸 정책에 저촉될 수 있다고 명시합니다. AI는 구성안 정리나 초안 작성에는 맞지만, 자사 나름의 판단, 실제 안건에서 자주 나오는 논점, 실패 패턴 같은 가치가 더해지지 않으면 약합니다. 원고 공수를 줄이기 위해 쓰는 것이지, 가치의 대용으로 쓰면 안 됩니다.

기술계 B2B 사이트에서는 무엇을 주역으로 두어야 하나요?

서비스 페이지입니다. 기술계 B2B 테마는 검색 수는 많지 않아도 문제가 깊고 단가가 높기 때문에, 넓고 얕은 유입보다 의도가 짙은 검색을 가져가는 편이 자연스럽습니다. 글은 PV 목적이 아니라 서비스 페이지를 강하게 하는 주변 자산으로, 부모 서비스 페이지 주변에 묶습니다. 광고의 도착지도 홈이 아니라, 검색 의도에 맞는 서비스 페이지나 서비스 특화 LP로 모아야 합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.