SEO и Google Ads на техническом B2B-сайте: как вести оба направления

В консультациях по SEO и Google Ads такие темы часто смешиваются.

• Сначала SEO или сначала реклама
• Вырастет ли поисковый трафик, если просто добавить статьи
• Можно ли массово генерировать статьи ИИ
• Достаточно ли вести Google Ads на главную
• Как разделить Search Console и Google Ads
• Почему хотели больше обращений, а выросли только просмотры

Это не сводится к лозунгам вроде «SEO важно» или «реклама быстрее». На практике почти всё решает другое: какие обращения вы хотите получать, на какой странице конвертировать визит и что считать конверсией.

flowchart TB
    accTitle: Три вопроса, от которых зависит подход к SEO и рекламе
    accDescr: Не важность SEO и не скорость рекламы задают подход, а три вопроса: какие обращения нужны, на какой странице конвертировать визит и что измерять как конверсию.
    q1["Какие обращения вы хотите получать"] --> q2["На какой странице конвертировать визит"]
    q2 --> q3["Что измерять как конверсию"]
    q3 --> r1["От этого почти целиком зависит подход к SEO и рекламе"]

Рис. 1: Сначала эти три вопроса — и тогда проще выбрать, что делать.

В этой статье SEO и Google Ads — не две отдельные инициативы, а способ закрывать один и тот же поисковый спрос с разных сторон. Ориентир — технический B2B-сайт вроде KomuraSoft / comcomponent.com. Подход практический, с опорой на официальные материалы Google.^1234567

Как читать эту статью

Текст длинный, поэтому сначала входы по задаче.

Термины, которые здесь встречаются

Маркетинговых слов сразу много, поэтому по одному предложению на термин.

1. Сначала вывод

Если сразу собрать выводы, практический порядок обычно такой.

• SEO и Google Ads — это не выбор одного из двух, а способ по отдельности закрывать запросы с разным намерением.
• В SEO важнее не приёмы под поисковик, а страницы, полезные людям, в форме, которую Google легко находит и понимает. Сама Google держит базовой линией helpful, reliable, people-first content и Search Essentials.³²
• Google умеет находить многие страницы сама, но внутренние ссылки, карта сайта, нормальные title, описания, URL и структурированные данные помогают и найти, и понять.^113141516
• Наоборот, плохо стыкуются попытка спрятать страницу через robots.txt, пачки похожих страниц, массовая генерация слабых статей ИИ, один и тот же title и описание на всех страницах.^1721814
• В Google Ads первым делом нужна не техника ставок, а наладка измерения. В официальных материалах Google на первом месте точные данные о конверсиях, прочная основа тегирования, enhanced conversions и Consent Mode.⁴⁶⁷
• Поисковую рекламу устойчивее вести в порядке схема конверсии → целевая страница → ключевые слова / поисковые запросы → текст объявления → ставки.
• Google продвигает связку Smart Bidding + broad match + responsive search ads, но это работает только при корректном измерении конверсий. Расширять охват при слабом измерении — почти всегда стрельба впустую.⁴¹¹
• На техническом B2B-сайте естественнее брать немного запросов с плотным намерением, а не широкий поверхностный трафик. Конкретно сильна схема, где в центре страницы услуг вроде разработка приложений для Windows, доработка и сопровождение существующего ПО для Windows, технические консультации и ревью архитектуры, повторное использование и перенос существующих активов, а вокруг них — технические статьи и кейсы.
• Короче: удобная рамка — SEO создаёт активы, Google Ads закрывает готовый спрос и проверяет гипотезы.

flowchart TB
    accTitle: Как смотреть на роли SEO и рекламы
    accDescr: SEO и Google Ads — не выбор одного из двух, а способ по отдельности закрывать запросы с разным намерением: SEO создаёт активы, Google Ads закрывает готовый спрос и проверяет гипотезы.
    s0["Один и тот же поисковый спрос"] --> s1["SEO"]
    s0 --> s2["Google Ads"]
    s1 --> s3["Создание активов (накапливается)"]
    s2 --> s4["Закрытие спроса и проверка гипотез (быстро)"]
    s3 --> s5["Запросы с разным намерением берём по отдельности"]
    s4 --> s5

Рис. 2: SEO — активы, реклама — закрытие спроса и проверка гипотез.

Карта знаний этой статьи

Статья — практическое руководство, которое раскладывает роли SEO и Google Ads на техническом B2B-сайте. SEO исходит из того, что выполнены базовые требования Google — helpful content, Search Essentials, Core Web Vitals, mobile-first indexing, — и помогает поисковой системе понять сайт внутренними ссылками, canonical URL, структурированными данными и картой сайта. Google Ads до запуска объявлений ставит в основу отслеживание конверсий, повышает точность через enhanced conversions и Consent Mode и ведёт кампанию, сочетая типы соответствия ключевых слов, интеллектуальное назначение ставок и адаптивные поисковые объявления. Через отчёт о поисковых запросах оба канала взаимно отражают спрос; на техническом B2B-сайте в роли главного источника обращений рекомендуется страница услуг, окружённая статьями и кейсами.

flowchart LR
    accTitle: Карта знаний SEO и Google Ads
    accDescr: Рисунок, показывающий, что SEO исходит из базовых требований к поисковой системе — helpful content, Search Essentials, Core Web Vitals, mobile-first indexing; что Google Ads опирается на отслеживание конверсий и сочетает типы соответствия ключевых слов и интеллектуальное назначение ставок; и как оба канала стыкуются через отчёт о поисковых запросах и страницу услуг
    seo["SEO (поисковая оптимизация)"]
    google_ads["Google Ads"]
    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["адаптивные поисковые объявления (RSA)"]
    quality_score_ads["показатель качества"]
    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 Ads

SEO и Google Ads могут стоять на одном экране выдачи. По характеру работы они сильно разные.

На техническом B2B-сайте эта разница видна особенно ясно.

Например, запросы вроде:

• Windows Custom Software Development
• миграция COM ActiveX
• доработка существующего Windows-ПО
• техническая консультация ревью архитектуры Windows

могут иметь небольшой объём, зато намерение обратиться очень плотное. Такие формулировки хорошо стыкуются с Google Ads, и в 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#»

проще и для SEO, и для пути к сделке брать темы, где причина поиска уже видна:

• «Когда на Windows действительно нужны права администратора»
• «Перестанет ли VBA работать»
• «Как получить кадр с камеры через Media Foundation»

3.2 Массовая генерация статей ИИ сама по себе не работает

Google не запрещает генеративный ИИ как таковой. При этом прямо пишет: массовый контент без добавленной ценности может попасть под политику по спаму как scaled content abuse.¹⁸

Эту границу на практике лучше не считать мелочью.

Если пользоваться ИИ, он хорошо подходит для:

• сборки каркаса
• перечисления осей сравнения
• черновика
• сжатия / развёртывания формулировок
• вытягивания кандидатов в FAQ

Но без следующего текст слабый:

• собственной экспертной оценки компании
• вопросов, которые часто всплывают в реальных проектах
• типичных провалов
• конкретных предпосылок
• кому консультация подходит, а кому нет

То есть ИИ берут, чтобы сократить трудозатраты на черновик, а не чтобы подменить ценность.

flowchart TB
    accTitle: Где ИИ уместен и где проходит граница
    accDescr: ИИ удобен для каркаса и черновика, но без собственной экспертной оценки, типичных вопросов из проектов и типичных провалов текст слабый; массовый контент без ценности может попасть под политику по спаму как scaled content abuse.
    a1["Что можно отдать ИИ"] --> a2["Каркас, оси сравнения, черновик, кандидаты в FAQ"]
    b1["Ценность, которую добавляет человек"] --> b2["Своё суждение, вопросы из проектов, типичные провалы"]
    a2 --> c1["Инструмент, который сокращает трудозатраты на черновик"]
    b2 --> c1
    a2 -.-> c2["Массовая генерация без ценности — риск политики по спаму"]

Рис. 5: ИИ — инструмент сокращения трудозатрат, а не замена ценности.

3.3 Развести роли страниц

Сайты, где SEO буксует, часто смешивают роли страниц. Для технического B2B удобно держать хотя бы четыре слоя.

Если нарисовать роли и пути, получится так. В центре — страница услуги, вокруг — статьи и кейсы.

flowchart LR
    Q1["Поиск с намерением изучить или сравнить<br/>пример: чем WPF отличается от WinForms"] --> A["Техническая статья<br/>вход из поиска"]
    Q2["Поиск с намерением найти, кому поручить работу<br/>пример: доработка существующего Windows-ПО"] --> S["Страница услуги<br/>главная страница для обращений"]
    AD["Google Ads"] --> S
    A --> S
    A --> C["Страница кейса<br/>доказательство, что работу реально довести"]
    C --> S
    S --> F["Обращение / о компании<br/>снимает последние сомнения"]
    C --> F

Рис. 6: Четыре слоя: страница услуги в центре, статьи и кейсы подводят к ней.

Направление стрелок важно. Статья ведёт к кейсу и к странице услуги, кейс — к странице услуги и к обращению. Если основной путь наоборот, со страницы услуги обратно в статьи, человек, который уже пришёл с намерением проконсультироваться, возвращается к сбору информации.

1. Страницы услуг

Главные страницы, на которых берут обращения.

Примеры:

• Разработка приложений для Windows
• Технические консультации и ревью архитектуры
• Доработка и сопровождение существующего ПО для Windows
• Повторное использование и перенос существующих активов

Здесь нужно ясно сказать, что вы делаете, кому это подходит, как идёт работа и с какими проектами она стыкуется.

2. Страницы кейсов

Доказательство, «можно ли с этой компанией реально довести дело».

Сильно работает, если видно:

• какой был фон
• что было трудным
• что оставили, что изменили
• чем закончилось

3. Технические статьи

Вход из поиска. Но это не статьи ради просмотров, а в первую очередь статьи рядом с будущими темами консультаций.

4. Обращение / о компании

Страницы, которые снимают последние сомнения. Конверсия проще, когда видны реальные имена, площадка, границы работ, вход в консультацию и что нужно подготовить к разговору.

3.4 Внутренние ссылки важны сильнее, чем кажется

Google пишет, что ссылки использует и как способ находить страницы, и как сигнал связанности.¹⁹

Поэтому техническая статья на этом не заканчивается. Нужно выстроить ход:

• ссылка на родительскую страницу услуги
• ссылка на связанный кейс
• ссылка на связанную сравнительную статью
• в конце — выход на обращение и связанные услуги

При этом ссылок «чем больше, тем лучше» нет. Важно естественное место в тексте и анкор, из которого понятно, куда ведёт ссылка.¹⁹

Вместо бесконечных «здесь» и «подробнее» сильнее работают ссылки, из которых видно смысл перехода:

• доработка и сопровождение существующего ПО для Windows
• технические консультации и ревью архитектуры
• поэтапная миграция существующих активов, включая COM / ActiveX

flowchart TB
    accTitle: Как ставить внутренние ссылки
    accDescr: Google использует ссылки и чтобы находить страницы, и как сигнал связанности, поэтому от статьи нужен путь к родительской услуге и кейсам; важно не число ссылок, а анкор, из которого понятно куда идти, естественно вписанный в текст.
    l1["Ссылка — способ найти страницу и сигнал связанности"] --> l2["От статьи — к родительской услуге, кейсу, сравнению"]
    l2 --> l3{"Анкорный текст"}
    l3 -.->|"здесь / подробнее"| l4["Не видно, куда ведёт, слабо"]
    l3 -->|"слова, из которых понятен переход"| l5["В тексте работает естественно"]

Рис. 7: Во внутренних ссылках работает не число, а понятное место назначения.

3.5 Title, meta description и URL нельзя делать наспех

Google сам собирает title link, опираясь на несколько источников, включая элемент <title>, и рекомендует давать каждой странице ясный и короткий title.¹³

Сниппет чаще берётся из текста страницы, но meta description могут взять, если он точнее описывает страницу. Google также рекомендует своё описание у каждой страницы.¹⁴

Про URL Google рекомендует понятную, логичную структуру, которую человек читает без труда, и советует описательные слова, язык аудитории, дефис между словами и меньше лишних параметров.²⁰

На практике уже заметно, если держать хотя бы такую линию:

• свой title у каждой страницы
• из title сразу видно, что это за страница
• meta description тоже свой у каждой страницы
• URL читаемый
• одно и то же содержимое не отдавать по нескольким URL

В блоге особенно путает, когда title статьи, H1, meta description и заголовок в списке чуть-чуть разъехались: и в выдаче, и внутри сайта уже неясно, что перед вами.

flowchart TB
    accTitle: Какую линию держать для title, описания и URL
    accDescr: У каждой страницы свои title и meta description, URL читаемый, одно содержимое не отдаётся по нескольким адресам; если title, H1, описание и заголовок в списке разъехались, путаница и в выдаче, и на сайте.
    t1["Свои title и описание у каждой страницы"] --> t2["URL читаемый"]
    t2 --> t3["Одно содержимое не отдавать по нескольким URL"]
    t3 --> t4["И в выдаче, и на сайте сразу видно, что это за страница"]
    t1 -.-> t5["Разъезд title, H1, описания и списка путает"]

Рис. 8: Даже согласовать title, описание и URL на уровне страницы уже даёт заметный эффект.

3.6 Не оставлять дубли URL и canonical без решения

Если одно и то же содержимое видно по нескольким URL, Google выбирает канонический. Если вы сами его не задали, решение принимает Google.¹²

Поэтому состояния вроде:

• /page
• /page/
• ?utm_source=...
• разные сортировки и фильтры
• разный регистр букв
• смесь HTTP/HTTPS и www / без www

медленно, но ощутимо вредят.

И внутренние ссылки, и карту сайта стоит свести к тому URL, который вы хотите видеть каноническим.¹²¹⁵

flowchart TB
    accTitle: Как обращаться с дублями URL и canonical
    accDescr: Если одно содержимое видно по нескольким URL из-за слэша, параметров и подобного, и canonical не задан, Google выберет канонический сам; базовое правило — задать его явно и свести к нему ссылки и карту сайта.
    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 часто путают с удалением из поиска; цель выбирает инструмент.

3.8 Мобильная версия и скорость — не «отдельная тема»

Google использует mobile-first indexing и индексирует и ранжирует по содержимому мобильной версии. Отдельно рекомендует адаптивный дизайн.²²

Смотреть нужно не только «открывается ли на телефоне», а:

• основной контент есть и в мобильной версии
• десктоп и мобильная версия почти эквивалентны
• на мобильной нет noindex
• основной контент не прячется за действием пользователя
• изображения, структурированные данные, title и описание тоже есть на мобильной стороне

²²

Core Web Vitals Google ставит как метрики реального пользовательского опыта и настоятельно рекомендует держать их в зелёной зоне.²³

Ускорение страницы практичнее видеть не как работу «ради 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, контакты, соцсети и подобное²⁵
• Article title статьи, автор, даты, изображения и подобное²⁶
• LocalBusiness если на первый план выносите площадку и часы работы²⁷

Ограничения здесь прямые.

• разметка совпадает с тем, что видно на странице
• не размечать пустые страницы и скрытый контент
• проверять в 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 пишет, что в отчёте Performance в Search Console видны показы и клики по запросу, странице и стране.²⁸

SEO сильнее работает не сразу после публикации, а когда вы смотрите на вышедшие данные и правите.

Особенно полезны такие ходы:

• показов много, CTR низкий → подозревать разъезд title / description / намерения
• клики есть, к обращению не приближает → подозревать CTA и внутренние ссылки
• вокруг страницы растут связанные запросы → выпустить продолжение или сравнительную статью
• у важной страницы услуги мало показов → усилить внутренними ссылками, кейсами и соседними статьями

flowchart TB
    accTitle: Цикл правок по вышедшим данным
    accDescr: SEO сильнее работает не сразу после публикации, а когда правят по данным: низкий CTR — подозревать title и намерение, нет конверсии — CTA и ссылки, рост запросов — продолжение, мало показов у важной страницы — внутренние ссылки и соседние статьи.
    d0["Смотрим Search Console"] --> d1["Низкий CTR → подозревать title"]
    d0 --> d2["Нет конверсии → подозревать CTA"]
    d1 --> d3["Растут запросы → выпускать продолжение"]
    d2 --> d4["Мало показов → усиливать внутренними ссылками"]
    d3 --> d0
    d4 --> d0

Рис. 13: SEO не заканчивается публикацией: работает цикл «данные → правка».

С какого процента CTR считать «низким»

Этот вопрос появляется всегда.

Честный ответ: универсального порога по отраслям и запросам Google не публикует. Один и тот же CTR 3% при средней позиции 1 — явно низкий, при позиции 9 — скорее обычный. Внешний бенчмарк, приложенный к своему сайту, почти всегда ставит неверный диагноз.

Практичнее собрать опорную линию сравнением внутри своего сайта. Отчёт Performance в Search Console одновременно отдаёт показы, клики, CTR и среднюю позицию по запросу и по странице.²⁸

На экране: в левом меню «Эффективность» откройте «Результаты поиска», в карточках показателей сверху включите «Средний CTR» и «Средняя позиция», затем смотрите вкладку «Страницы» внизу. Порядок такой.

1. Возьмите период около трёх месяцев и оставьте только страницы с достаточным числом показов (на малом числе показов CTR легко прыгает)
2. Разбейте страницы на группы по средней позиции (1–3, 4–10, 11 и ниже)
3. Внутри одной позиционной группы посчитайте медиану CTR своего сайта
4. Страницы, которые эту медиану явно не дотягивают, считайте «низкими» и разбирайте

Группы по позиции — суть приёма. Без них страницу, у которой CTR низкий просто потому, что позиция низкая, легко принять за проблему title.

flowchart TB
    accTitle: Как собрать опорную линию CTR внутри своего сайта
    accDescr: Абсолютного порога CTR нет, поэтому период расширяют примерно до трёх месяцев, оставляют страницы с достаточным числом показов, группируют по средней позиции, внутри группы считают медиану CTR своего сайта и разбирают страницы, которые её явно не дотягивают.
    e1["Расширить период и оставить страницы с достаточным числом показов"] --> e2["Собрать группы по средней позиции"]
    e2 --> e3["Внутри группы посчитать медиану CTR"]
    e3 --> e4["Страницы ниже медианы — в разбор"]
    e2 -.-> e5["Без групп низкий CTR из-за позиции принимают за проблему title"]

Рис. 14: Высокий и низкий CTR смотрят не по внешнему порогу, а внутри позиционной группы своего сайта.

Та же логика работает и в обратную сторону. Если показов много, а страница не ведёт ни к одной вашей услуге — это проблема внутренних ссылок. Иногда быстрее сначала посмотреть, куда со страницы можно уйти, и только потом смотреть цифру CTR.

3.11 В эпоху AI Overviews / AI Mode делать нужно в основном то же самое

В актуальном руководстве Google сказано: для попадания в AI features не нужны особая схема и отдельная оптимизация — работают те же практики SEO, что и раньше.²¹

Из того, что наступила эпоха ИИ, не следует:

• добавлять загадочные «AI-теги»
• заводить отдельные файлы «для ИИ»
• писать неестественный текст только под сводку ИИ

У Google скорее обратное:

• разрешить обход
• сделать страницы находимыми через внутренние ссылки
• держать важный контент текстом
• привести в порядок page experience
• сверить структурированные данные с видимым текстом

²¹

Трафик из AI features тоже входит в общие данные Search Console.²¹ Поэтому сам взгляд на SEO лучше не ломать, а делать страницы, полезные во всём поиске.

flowchart TB
    accTitle: Что делать для SEO в эпоху ИИ
    accDescr: Для AI features не нужны особая схема и отдельная оптимизация: по-прежнему важны разрешение обхода, находимость через внутренние ссылки, важный контент текстом, page experience и совпадение структурированных данных с видимым текстом.
    n1["Особые теги и файлы под ИИ"] -.-> n2["Не нужны"]
    n3["Обычные основы SEO"] --> n4["Разрешить обход, внутренние ссылки, контент текстом"]
    n4 --> n5["page experience и совпадение структурированных данных"]
    n5 --> n6["Страницы, полезные во всём поиске"]

Рис. 15: В эпоху AI Overviews делать нужно те же основы SEO, что и раньше.

Кратко по главе 3

• Сначала решить, для кого и в какой ситуации страница. Размытая страница может приносить трафик и не доводить до обращения
• ИИ сокращает трудозатраты на черновик и не подменяет ценность
• Роли страниц развести на четыре слоя: услуга / кейс / статья / обращение, и вести со статьи к кейсу и услуге
• Во внутренних ссылках не «здесь», а анкор, из которого видно, куда идти
• Title, meta description, URL и canonical — свои у каждой страницы
• Править по вышедшим данным. Высокий и низкий CTR смотрят не по внешнему порогу, а по медиане внутри той же позиционной группы

4. Практики Google Ads

4.1 Первым делом не «реклама», а «измерение»

В официальном руководстве Google Ads тоже на первом месте крутить автоматические ставки на точных данных о конверсиях.⁴¹¹

Конверсия здесь для технического B2B-сайта — не обычный pageview.

Например:

• отправка формы обращения
• заявка на материалы
• запись на консультацию
• звонок
• назначение первой встречи
• достижение MQL / SQL
• офлайн-конверсия с шансом сделки

Нужно ставить действия, которые что-то значат для бизнеса.

flowchart TB
    accTitle: Что ставить конверсией
    accDescr: Конверсия технического B2B-сайта — не просмотр страницы, а действие вроде отправки формы, заявки на материалы, записи на консультацию или назначения первой встречи; на этих данных крутятся автоматические ставки.
    v0["Определение конверсии"] -.->|"не ставить"| v1["Обычный pageview"]
    v0 -->|"ставить"| v2["Отправка формы, заявка на материалы, запись на консультацию"]
    v2 --> v3["Автоматические ставки крутятся на точных данных о конверсиях"]

Рис. 16: Сначала решить, какое действие, значимое для бизнеса, считать конверсией.

Дальше Google явно рекомендует как основу измерения:

• прочную tagging foundation
• enhanced conversions
• Consent Mode
• передачу conversion value
• загрузку в Google Ads собственного source of truth

⁴⁶⁷

В итоге фундамент рекламы — это

корректно ли стоят теги, согласовано ли это с управлением согласием, измеряете ли вы ту конверсию, которую действительно хотите видеть.

Пока здесь слабо, крутить только ключевые слова и ставки почти ничего не даёт.

flowchart TB
    accTitle: Три вопроса фундамента рекламы
    accDescr: Фундамент рекламы — корректные теги, согласие и измерение той конверсии, которую вы действительно хотите видеть; пока это слабо, правки только в ключевых словах и ставках дают мало.
    f1["Корректно ли стоят теги"] --> f2["Согласовано ли это с управлением согласием"]
    f2 --> f3["Измеряете ли вы ту конверсию, которую действительно хотите видеть"]
    f3 --> f4["Это фундамент"]
    f4 -.-> f5["Пока слабо, ключевые слова и ставки почти ничего не дают"]

Рис. 17: Первым делом не реклама, а эти три вопроса про измерение.

4.2 enhanced conversions и Consent Mode не откладывать «на потом»

Google описывает enhanced conversions как функцию, которая улучшает точность измерения и даёт более сильные ставки. Это отправка хешированных first-party данных клиента, например адреса почты.⁶

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 Целевую страницу решить раньше ключевых слов

Google Ads выглядит как история про ключевые слова, но сначала решается другое: какой поисковый интент на какую страницу вести.

Google включает опыт целевой страницы в Quality Score и связывает его с usefulness / relevance / navigation. Конечный URL (landing page) и display URL должны быть на одном домене.⁸⁹

Поэтому на техническом B2B-сайте сначала стоит решить:

• человека, который ищет разработку приложений для Windows, на какую страницу вести
• человека, который ищет доработку существующего ПО для Windows, на какую страницу вести
• человека, который ищет технические консультации и ревью архитектуры, на какую страницу вести
• человека, который ищет миграцию COM / ActiveX, на какую страницу вести

Если запускать рекламу без этого решения, почти всегда весь трафик ведут на главную. И эта схема довольно слабая.

flowchart TB
    accTitle: Целевая страница раньше ключевых слов
    accDescr: Google Ads выглядит как история про ключевые слова, но сначала решают, какой интент на какую страницу вести; опыт целевой страницы входит в 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: Если группу объявлений разбивать так, чтобы совпадали интент и целевая страница, совпадают и запросы, текст, заголовок LP, кейсы и CTA; если разные темы сложить в одну группу, уже не видно, что сработало.
    i1["Разбивать группу объявлений по интенту и LP"] --> i2["Совпадают запросы, текст объявления, заголовок LP"]
    i2 --> i3["Кейсы и CTA обращения тоже встают в одну линию"]
    i4["Разные темы в одну группу"] -.-> i5["Не видно, что именно сработало"]

Рис. 20: Группу объявлений разбивают единицей «интент + LP».

4.5 Одно Responsive Search Ad «на всякий случай» — слабо

Google как лучшую практику указывает: в каждой группе объявлений хотя бы одно Responsive Search Ad с Ad Strength Good или Excellent.⁵

Но цель не в том, чтобы просто заполнить слоты заголовков.

В техническом B2B варианты сильнее, если собирать их по таким осям:

• для кого пример: для доработки существующего ПО для Windows
• что закрывает пример: поэтапная миграция без полной переделки
• в чём сила пример: COM / ActiveX / 32bit / 64bit
• как идёт работа пример: можно начать с разбора архитектуры
• CTA пример: техническая консультация

Текст объявления лучше делать не перефразом поискового запроса, а сжатой причиной обратиться.

flowchart TB
    accTitle: Как собирать варианты адаптивного поискового объявления
    accDescr: У адаптивного поискового объявления цель не заполнить слоты заголовков, а собрать варианты по осям «для кого / что закрывает / в чём сила / как идёт работа / CTA» и писать текст как сжатую причину обратиться, а не как перефраз запроса.
    j0["Заполнить слоты заголовков"] -.-> j1["Само по себе это не цель"]
    j2["Оси вариантов"] --> j3["Для кого и что закрывает"]
    j2 --> j4["В чём сила, как идёт работа, CTA"]
    j3 --> j5["Текст объявления как сжатая причина обратиться"]
    j4 --> j5

Рис. 21: У RSA варианты держатся на осях, а текст сжимает причину обратиться.

4.6 Smart Bidding силён, но без предпосылок опасен

Google описывает Smart Bidding как автоматические ставки под конверсии или ценность конверсий и говорит, что оптимизирует ставку по auction-time signals.¹¹

В практиках настройки аккаунта Google также продвигает связку broad match, Smart Bidding, responsive search ads.⁴

Но здесь важен порядок.

• определение конверсии размыто
• теги сломаны
• LP слабый
• качество обращений низкое
• не решено, что считать ценностью

Если в таком состоянии широко включить broad match, автоматизация усиливается на плохих данных для обучения.

Поэтому реалистичный порядок, который меньше разъезжается, такой:

1. Определить конверсии
2. Наладить теги и Consent Mode
3. Довести LP
4. Запустить кампании по темам с высокой готовностью обратиться
5. Смотреть поисковые запросы и убирать лишнее
6. И только потом усиливать автоматизацию

flowchart TB
    accTitle: Порядок до того, как усиливать автоматизацию
    accDescr: Устойчивее сначала определить конверсии, наладить теги и Consent Mode, довести LP, начать с тем с высокой готовностью обратиться, убрать лишнее по поисковым запросам и лишь потом усиливать автоматизацию; расширять broad match при слабом измерении значит учить систему на плохих данных.
    o1["1. Определить конверсии"] --> 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 как отчёт о реальных запросах, по которым сработало объявление, и об их результате. Отдельно говорит, что из него можно брать идеи для креатива и целевой страницы.²⁹

Это узел эксплуатации рекламы.

По отчёту видно:

• показываетесь ли вы по тем запросам, которые ждали
• не показываетесь ли по лишним
• не разъехались ли формулировка 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 не нужно. Естественнее взять его как вспомогательную информацию, чтобы поправить:

• совпадает ли текст объявления с интентом
• полезен ли LP
• совпадает ли обещание объявления с запросом

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

• Порядок: определение конверсии → теги и Consent Mode → LP → ключевые слова / поисковые запросы → текст объявления → ставки
• Конверсия — не 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 Ads

SEO и Google Ads легко разъезжаются по разным командам и разным инициативам. На практике сильно другое: один и тот же поисковый спрос понимают с обеих сторон.

5.1 Спрос, увиденный в рекламе, возвращать в SEO

В Google Ads search terms report виден сразу. Темы, которые там сработали, становятся приоритетными кандидатами для статей SEO и усиления страниц услуг.²⁹

Если реклама показала, что сильны, например:

• доработка существующего windows-по
• миграция activex
• ревью архитектуры windows-приложения

это легко перенести и в SEO:

• в заголовки страниц услуг
• в названия кейсов
• в темы технических статей
• в FAQ
• в meta description

flowchart TB
    accTitle: Как вернуть в SEO спрос, увиденный в рекламе
    accDescr: Темы, которые хорошо сработали в search terms report, становятся приоритетными кандидатами для заголовков страниц услуг, названий кейсов, тем статей, FAQ и meta description на стороне SEO.
    r1["В search terms report видны формулировки, которые сработали"] --> r2["Они становятся приоритетом для SEO"]
    r2 --> r3["Переносим в заголовки услуг и названия кейсов"]
    r2 --> r4["Переносим в темы статей, FAQ и meta description"]

Рис. 25: Спрос, увиденный в рекламе, возвращают в заголовки, статьи и FAQ SEO.

5.2 Страницы, выращенные SEO, держат долю сделок в рекламе

Наоборот, набор страниц, собранный SEO, работает и в Google Ads.

Если вокруг LP есть, например:

• связанные технические статьи
• кейсы внедрения
• FAQ
• сведения о руководителе и компании
• как проходит консультация

человеку, пришедшему из рекламы, проще снять сомнения.

SEO — не только бесплатный трафик. Это ещё и актив, который усиливает landing page experience и аргументы рекламы.

flowchart TB
    accTitle: Как активы SEO поддерживают рекламу
    accDescr: Связанные статьи, кейсы, FAQ, сведения о компании и описание консультации вокруг LP снижают сомнения у визитов из рекламы; SEO — не только бесплатный трафик, но и актив, который усиливает landing page experience и аргументы.
    s1["Набор страниц, выращенный SEO"] --> s2["Связанные статьи, кейсы, FAQ, сведения о компании"]
    s2 --> s3["У визита из рекламы меньше сомнений"]
    s3 --> s4["Сильнее landing page experience и аргументы"]

Рис. 26: Активы, выращенные SEO, работают и на долю сделок в рекламе.

5.3 Одну и ту же тему смотреть в Search Console и в Google Ads

В Search Console видно, по каким query были показы и какие страницы кликали.²⁸ В Google Ads видно, по каким поисковым запросам показывалось объявление и какие из них дали conversion.²⁹

Если положить оба источника рядом, по одной теме видно:

• сильны ли вы в SEO
• сильны ли в рекламе
• слабы ли в обоих
• не оценили ли статью раньше страницы услуги

Такое сравнение очень удобно, чтобы решить, что делать следующим.

flowchart TB
    accTitle: Одну тему смотреть в Search Console и в рекламе
    accDescr: Search Console показывает query, страницы и клики, Google Ads — поисковые запросы и conversion; рядом по одной теме видно, где вы сильны в SEO, где в рекламе, где слабы в обоих, и проще выбрать следующий приоритет.
    t1["Search Console (query, страница, клики)"] --> t3["Одну тему кладём рядом"]
    t2["Google Ads (поисковые запросы, conversion)"] --> t3
    t3 --> t4["Видно: сильны в SEO / сильны в рекламе / слабы в обоих"]
    t4 --> t5["Появляется следующий приоритет"]

Рис. 27: Два взгляда на один поисковый спрос рядом — и приоритеты проявляются.

6. Что должно быть центром технического B2B-сайта

Технический B2B-сайт выигрывает иначе, чем магазин или медиа.

Тем чаще не «большой общий запрос», а:

• задача глубокая
• чек высокий
• сравнение долгое
• объём поиска при этом небольшой

Поэтому в центре должны стоять страницы услуг. Статьи — не главные герои. Они лучше работают как окружение, которое усиливает страницу услуги.

6.1 Сначала усиливать страницы услуг

Частая ошибка технических сайтов: блог растёт, страницы услуг остаются тонкими.

Если нужны обращения, первым усиливать стоит страницы услуг из первого слоя в 3.3. То есть страницы, на которые попадает человек, который прямо сейчас ищет, кому поручить работу.

Здесь нужно:

• что можно поручить
• каким проектам это подходит
• как идёт работа
• что оставляют, что меняют и почему
• что сказать при обращении

flowchart TB
    accTitle: Первым усиливать страницу услуги
    accDescr: Частая ошибка технического сайта — растёт только блог, а страницы услуг тонкие; если нужны обращения, первым усиливают страницу услуги, на которую попадает человек, прямо сейчас ищущий, кому поручить работу.
    u1["Растут только статьи блога"] -.-> u2["Тонкая страница услуги не доводит до обращения"]
    u3["Человек, который сейчас ищет, кому поручить работу"] --> u4["Попадает на страницу услуги"]
    u4 --> u5["Ясно сказать, что можно поручить, как идёт работа, кому подходит"]

Рис. 28: Раньше статей усиливать страницу услуги, на которую попадает тот, кто ищет консультацию.

6.2 Страницы кейсов работают сильно

В технических проектах прецедент часто весит больше связного текста.

• как шли, не выбрасывая существующие активы
• где перешли границу 32bit / 64bit
• как разбирали сбой
• как разделили UI / связь / фоновую обработку

Такие истории чаще доходят кейсом, а не коммерческим материалом.

Для SEO кейсы ещё и удобны тем, что в них много собственной информации, и они редко превращаются в почти одинаковые страницы.

6.3 Блог делать «материалом для решения», а не «приманкой»

Технические статьи сильнее работают как материал для решения за шаг до консультации, а не как гонка за просмотрами.

Например, такое разделение ролей:

• Сравнительные статьи пример: как выбрать между WinForms / WPF / WinUI
• Статьи-суждения пример: стоит ли менять VBA
• Статьи про решение задачи пример: когда нужны права администратора
• Статьи про реализацию пример: как получить кадр с камеры через Media Foundation

Такие статьи не только вход SEO. Они ещё показывают: «эта компания думает практическими вопросами, а не по верхам».

flowchart TB
    accTitle: Какую роль играют статьи блога
    accDescr: Технические статьи сильнее работают как материал для решения за шаг до консультации, а не как приманка ради просмотров; сравнение, суждение, решение задачи и реализация становятся и входом SEO, и сигналом, что компания думает практическими вопросами.
    w0["Задача технической статьи"] -.->|"не туда"| w1["Приманка ради просмотров"]
    w0 -->|"сюда"| w2["Материал для решения за шаг до консультации"]
    w2 --> w3["Становится входом SEO"]
    w2 --> w4["Видно, что компания думает практическими вопросами"]

Рис. 29: Статья как материал для решения даёт и вход, и доверие; статья как приманка — нет.

6.4 Как переложить это на свою компанию

И объяснение досюда, и глава 7 дальше используют comcomponent.com как пример. Сама работа при смене отрасли та же. Четыре шага ниже переписывают схему под себя.

Шаг 1. Выписать, что вы делаете, словами заказчика

Не внутренними названиями, а словами человека, который приходит советоваться. Если здесь поставить внутренний жаргон или кодовые имена продуктов, гипотезы поискового намерения дальше разъедутся целиком.

Ориентир по зерну: одна услуга = одно сильное намерение проконсультироваться. Слишком мелко — принимающая страница станет тонкой. Слишком крупно — не попадёт в поисковое намерение.

Шаг 2. По каждой услуге собрать гипотезу поискового намерения

На каждую услугу из шага 1 заполните одну такую таблицу. На этом этапе достаточно гипотезы, правильность не обязательна. Потом search terms report и Search Console её проверят.²⁹²⁸

Если компания делает складской учёт для предприятий, услуга «доработка существующей системы» может выглядеть так: ситуация — «бюджета на переписывание нет, нынешний подрядчик не берётся», запросы — вроде «система складского учёта доработка на заказ», «передача сопровождения учётной системы».

Шаг 3. Разложить запросы на «намерение проконсультироваться» и «намерение разобраться»

Запросы из шага 2 разложите так же, как в главе 2.

Если сомневаетесь, быстрее всего поискать эту формулировку и посмотреть тип страниц в топе. Сплошные страницы услуг — намерение проконсультироваться. Сплошные объясняющие статьи — намерение разобраться.

Шаг 4. Выбрать ровно одну недостающую страницу и начать с неё

Попытка закрыть всё сразу обычно ломается на середине. Из строк шага 2, где «принимающей страницы нет», берите одну с самым плотным намерением проконсультироваться и делайте её.

Когда это решено, можно сразу влиться в 90-дневный план главы 9.

flowchart TB
    accTitle: Четыре шага, чтобы переложить схему на свою компанию
    accDescr: Схему под себя переписывают за четыре шага: выписать предложение словами заказчика, собрать гипотезу намерения по каждой услуге, разложить запросы на консультацию и изучение, выбрать одну недостающую страницу и влиться в 90-дневный план.
    v1["Шаг 1. Выписать предложение словами заказчика"] --> v2["Шаг 2. Собрать гипотезу намерения по каждой услуге"]
    v2 --> v3["Шаг 3. Разложить на консультацию и изучение"]
    v3 --> v4["Шаг 4. Выбрать одну недостающую страницу и начать"]
    v4 --> v5["Влиться в 90-дневный план"]

Рис. 30: При смене отрасли делать нужно то же самое; эти четыре шага дают вашу версию.

7. Как бы мы собрали это для comcomponent.com

Дальше — пример, как четыре шага из 6.4 выглядят на одной конкретной компании. Когда перекладываете на себя, меняете названия услуг и содержимое намерения; конструкция остаётся.

У comcomponent.com уже есть базовая структура:

• страницы услуг
• технические кейсы
• технический блог
• страница обращения

Эта основа уже хорошая.

Чтобы довести её до обращений, естественна такая сборка.

7.1 Сначала закрепить поисковое намерение за каждой основной услугой

Вокруг страниц услуг проясняем такие темы.

Разработка приложений для Windows

Какое намерение брать:

• хочет новое Windows-ПО с нуля
• хочет инструмент связки с оборудованием
• хочет бизнес-приложение с мониторингом / связью / отчётностью

Технические консультации и ревью архитектуры

Какое намерение брать:

• хочет обсудить только направление
• хочет, чтобы архитектуру посмотрели до реализации
• нужно суждение: существующие активы оставить / обернуть / заменить

Доработка и сопровождение существующего ПО для Windows

Какое намерение брать:

• хочет доработку, а не переписывание с нуля
• хочет продлить жизнь существующему ПО
• хочет понемногу приводить в порядок, параллельно закрывая сбои

Повторное использование и перенос существующих активов

Какое намерение брать:

• хочет разобрать конфигурацию с COM / ActiveX / OCX
• хочет перейти границу 32bit / 64bit
• хочет мост для поэтапной миграции

Если смотреть как одна страница услуги = одно сильное намерение проконсультироваться, и SEO, и реклама меньше разъезжаются.

flowchart TB
    accTitle: Одна страница услуги = одно сильное намерение проконсультироваться
    accDescr: Если за каждой основной услугой закрепить одно поисковое намерение, которое хотите брать, и держать одну страницу услуги как одно сильное намерение проконсультироваться, 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 Ads начинать только со страниц с высоким намерением

Рекламу не обязательно запускать по всем темам сразу. Наоборот, на старте лучше сузиться до тем, где намерение обратиться плотное, а принимающая страница сильная.

Пример таких групп формулировок:

• Windows Custom Software Development
• доработка существующего 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 Ads естественнее 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 Пачками публиковать похожие статьи ИИ

Объём растёт, различие между намерениями слабеет, страниц без добавленной ценности становится больше. С руководствами Google это тоже плохо стыкуется.¹⁸²

8.3 Пытаться спрятать страницу через robots.txt

robots.txt не убирает страницу из выдачи. Если показывать не нужно — noindex или аутентификация.¹⁷

8.4 Вести Google Ads на главную

Поисковое намерение и LP разъезжаются, слабеют и CVR, и обучение.

8.5 Измерение конверсий, близкое к 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 — минимальная схема измерения и рекламы, второй месяц — статьи и кейсы вокруг страниц услуг, третий месяц — данные рекламы и SEO сверяют друг с другом.
    n1["Недели 1–2: привести фундамент в порядок"] --> n2["Недели 3–4: собрать минимум измерения и рекламы"]
    n2 --> n3["Второй месяц: нарастить опору SEO"]
    n3 --> n4["Третий месяц: связать рекламу и SEO"]

Рис. 35: 90 дней идут в порядке фундамент → измерение и реклама → опора SEO → связка.

Недели 1–2: привести фундамент в порядок

• решить, что считается обращением
• проверить Search Console
• привести в порядок карту сайта и robots / noindex
• пересмотреть title / description / CTA основных страниц услуг
• выбрать landing page для рекламы

Недели 3–4: собрать минимум измерения и рекламы

• наладить conversion tracking в Google Ads
• настроить enhanced conversions
• согласовать Consent Mode с вашим управлением согласием
• запустить поисковую рекламу только по темам с высокой готовностью обратиться
• начать смотреть search terms report

Второй месяц: нарастить опору SEO

• добавить 3–5 технических статей, которые ведут на страницы услуг
• добавить страницы кейсов или усилить существующие
• пересмотреть нужные structured data вроде Organization / Article
• привести в порядок внутренние ссылки

Третий месяц: связать оба направления

• перенести формулировки, которые сработали в рекламе, в статьи и LP
• по query из Search Console сделать статьи-продолжения
• поправить CTA на страницах, близких к обращению
• пересмотреть определение conversion, включая качество консультаций

10. Итог

Если практики SEO и Google Ads сказать одной фразой, это делать страницы под поисковое намерение, корректно измерять результат и сверять данные обеих систем.

Основы SEO такие. Рядом — гид Google Search Central, на который опирается каждый пункт: если нужно к первоисточнику, идите отсюда.

Основы Google Ads в том же виде выглядят так.

И на техническом B2B-сайте лучше не делать целью само по себе увеличение числа статей.

• сначала усилить страницы услуг
• кейсами закрыть доверие
• техническими статьями умножить входы
• рекламой закрыть спрос с высокой готовностью обратиться
• данными Search Console и Ads усиливать друг друга

Этот ход довольно воспроизводим.

flowchart TB
    accTitle: Воспроизводимый ход работы
    accDescr: Воспроизводимый ход для технического B2B-сайта: сначала усилить страницы услуг, кейсами закрыть доверие, статьями умножить входы, рекламой закрыть спрос с высокой готовностью обратиться и взаимно усиливать оба направления данными Search Console и Ads.
    b1["Усилить страницы услуг"] --> b2["Кейсами закрыть доверие"]
    b2 --> b3["Техническими статьями умножить входы"]
    b3 --> b4["Рекламой закрыть спрос с высокой готовностью"]
    b4 --> b5["Данными Search Console и Ads усиливать друг друга"]
    b5 -.-> b3

Рис. 36: Целью не ставить само увеличение числа статей; крутить в этом порядке — воспроизводимая форма.

11. Связанные страницы

• Разработка приложений для Windows
• Технические консультации и ревью архитектуры
• Повторное использование и перенос существующих активов
• Примеры проектов
• Технический блог
• Связаться с нами

12. Источники

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Что делать раньше — SEO или Google Ads?

Это не выбор одного из двух. Это способ по отдельности закрывать запросы с разным намерением. SEO разгоняется медленно, зато накапливается; реклама встаёт быстро, но останавливается, как только выключают показы. На практике реалистично так: запросы, близкие к сделке и с высокой готовностью обратиться, брать ещё и рекламой, а соседний спрос на изучение и сравнение — статьями SEO. Удобная рамка: SEO создаёт активы, Google Ads закрывает готовый спрос и проверяет гипотезы.

С чего начинать Google Ads?

Не с техники ставок, а с измерения. В официальных материалах Google тоже на первом месте точные данные о конверсиях, прочная основа тегирования, enhanced conversions и Consent Mode. Конверсия — не просмотр страницы, а действие, которое что-то значит для бизнеса: отправка формы, заявка на материалы, запись на консультацию. Пока измерение слабое, крутить только ключевые слова и ставки почти бесполезно: автоматизация вроде broad match и Smart Bidding будет учиться на плохих данных.

Если массово генерировать статьи ИИ, SEO вырастет?

Скорее нет, плюс есть риск. Google не запрещает генеративный ИИ как таковой, но прямо пишет: массовый контент без добавленной ценности может попасть под политику по спаму как scaled content abuse. ИИ удобен, чтобы собрать каркас или черновик, но без собственной экспертной оценки компании, типичных вопросов из реальных проектов и типичных провалов текст слабый. Им сокращают трудозатраты на черновик, а не подменяют ценность.

Что должно быть центром технического B2B-сайта?

Страницы услуг. В техническом B2B объём поиска часто небольшой, зато задача глубокая и чек высокий: естественнее брать немного запросов с плотным намерением, чем широкий поверхностный трафик. Статьи пишут не ради просмотров, а как окружение, которое усиливает страницу услуги, и собирают их вокруг родительской страницы услуги. Трафик рекламы тоже лучше вести не на главную, а на страницу услуги или отдельный LP под это намерение.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.