Яндекс.WordStat — это только один из источников семантики. Можно сказать, базовый для тех, кто запускает контекст в Директе. Есть еще поисковые подсказки, слова конкурентов, отчеты о поисковых запросах из активных рекламных кампаний.
По поводу Key Collector — здесь есть нюансы. Надо учесть, что Key Collector стоит денег. Плата небольшая, если им пользоваться регулярно. А если собрать под одну-две кампании, то уже вопрос, нужен ли он. Другой момент — с Key Collector нужно научиться работать, и в этом плане он проигрывает "однокнопочным" сервисам. Обилие настроек — это вроде хорошо, но далеко не каждый захочет с ними возиться. Третий момент — в Key Collector нужно вводить капчу при парсинге Вордстата (решается подключением Антикапчи — там копейки, но все же). Далее — для Key Collector нужен "левый" аккаунт Яндекса, чтобы основной не заблокировали. Далее — например, для парсинга Вордстата из Украины в Key Collector нужно подключать прокси. Если добавить сюда парсинг статистики по Гуглу, то окажется, что получить данные можно только через аккаунты, которые Гугл считает "достаточно активными по части траты рекламных бюджетов" (а это риск блокировки).
Конечно, чем больше данных, тем лучше. С другой стороны, это 48 топовых интернет-магазинов. В контексте того, что именно топы задают тренды, всегда интересно посмотреть, как там у них.
Спасибо.
Поюзали VStat — это не совсем парсер. Это скорее анализатор статистики. Хотя в платной версии там вроде бы как есть функция парсинга ключей. Если вам нужно спарсить ключи бесплатно, велкам в наш SEO-модуль — здесь вы можете выгрузить ключи, по которым сайт стоит в ТОП-50 Яндекса/Google и ключи сайтов-конкурентов.
В тексте был указан вариант для xHTML. Но для HTML нужно указывать именно <html prefix="og: http://ogp.me/ns#"> — как в документации. Спасибо, что обратили внимание.
Open Graph описывается с помощью синтаксиса RDFa (JSON-LD — нет). JSON-LD подходит для семантической разметки на базе Schema.org (равно как и RDFa, как и Microdata). Open Graph и Schema.org решают разные задачи. Open Graph — грубо говоря, для красивых репостов, Schema.org — опять же, грубо говоря, для красивых сниппетов в поиске. Оба вида разметки прекрасно уживаются на одной странице, о дублировании переживать не стоит.
не всегда дело в процентах. Вот возьмем конкретный пример. Сравним наш основной блог https://blog.promopult.ru/ и этот блог на Хабре. Они решают несколько разные задачи. Первый — отличный трафико- и лидогенератор. Второй — больше для имиджевой составляющей, формирования репутации и узнаваемости в профессиональной среде. Хотя и отсюда лидов идет достаточно. Но тут вопрос ресурсов. Если у вас ресурсов достаточно (денежных и интеллектуальных), можно позволить себе разные каналы, даже если некоторые из них показывают меньшую эффективность. В противном случае приходится выбирать, и обычно лучшим решением становится именно собственный блог — хотя бы потому, что вам не нужно платить за размещение.
как, кроме пропорционального ограничения расходов на менее эффективные площадки?
еще количество и качество публикаций. Если площадка себя хорошо показывает, наращиваем количество публикаций, уделяем больше внимания качеству контента. А если плохо, то или сворачиваемся, или размещаемся для "галочки" — ссылки тоже полезны. Думаю, тут мы ничего нового не открываем.
Тут скорее дело не в продукте, а в задачах, которые он решает. Возьмем, к примеру, лопаты. Продукт вроде однообразный. Но можно копать на дачном участке, на огороде, весной и осенью, окоп или траншею, в конце концов) Это утрированно, но примерно так. Но даже если ваш продукт решает только одну задачу для одной ЦА, как минимум можно сделать одну или пару нишевых статей. Они точно не помешают. Кроме того, всегда можно подняться на уровень выше — взять более широкую тему и там уже показать, чем полезен ваш продукт. Если хотите, приведите пример продукта — сможем дать более предметный ответ.
Может быть, некорректно спрашивать, но что конкретно вы хотите узнать?
Различия в эффективности разных площадок? Они есть. И мы их учитываем при подготовке материала для публикации.
Тут не все так однозначно. Если посмотреть справку Гугла, то там сказано: "Этот файл (это про роботс — прим.) не предназначен для того, чтобы запрещать показ веб-страниц в результатах поиска Google. Если вы не хотите, чтобы какие-либо материалы с вашего сайта были представлены в Google, применяйте директивы noindex". Тем не менее ваш совет прописать «Disallow: /» применять не хотим). Но то, что в индекс "просачиваются" некоторые страницы, запрещенные в роботс, то это бывает. В контексте этого, скорее всего, корректней говорить именно о правилах сканирования, нежели индексации. Хотя для реальной практики это не столь важно)
спасибо за уточнение, вы правы. В robots.txt устанавливаются правила посещения разделов сайта роботами. Не просканируют — не проиндексируют. Это в идеале. Хотя на практике robots.txt отрабатывает не на 100%
Вот это вы копнули так копнули)
Какие именно опции вам интересны?
Спасибо, что читаете!
Спасибо, возьмем на заметку
Яндекс.WordStat — это только один из источников семантики. Можно сказать, базовый для тех, кто запускает контекст в Директе. Есть еще поисковые подсказки, слова конкурентов, отчеты о поисковых запросах из активных рекламных кампаний.
По поводу Key Collector — здесь есть нюансы. Надо учесть, что Key Collector стоит денег. Плата небольшая, если им пользоваться регулярно. А если собрать под одну-две кампании, то уже вопрос, нужен ли он. Другой момент — с Key Collector нужно научиться работать, и в этом плане он проигрывает "однокнопочным" сервисам. Обилие настроек — это вроде хорошо, но далеко не каждый захочет с ними возиться. Третий момент — в Key Collector нужно вводить капчу при парсинге Вордстата (решается подключением Антикапчи — там копейки, но все же). Далее — для Key Collector нужен "левый" аккаунт Яндекса, чтобы основной не заблокировали. Далее — например, для парсинга Вордстата из Украины в Key Collector нужно подключать прокси. Если добавить сюда парсинг статистики по Гуглу, то окажется, что получить данные можно только через аккаунты, которые Гугл считает "достаточно активными по части траты рекламных бюджетов" (а это риск блокировки).
что вы имеете в виду под uac?
Конечно, чем больше данных, тем лучше. С другой стороны, это 48 топовых интернет-магазинов. В контексте того, что именно топы задают тренды, всегда интересно посмотреть, как там у них.
Спасибо! Исправили
Хорошо, когда всем хорошо)
Спасибо за уточнение.
Спасибо.
Поюзали VStat — это не совсем парсер. Это скорее анализатор статистики. Хотя в платной версии там вроде бы как есть функция парсинга ключей. Если вам нужно спарсить ключи бесплатно, велкам в наш SEO-модуль — здесь вы можете выгрузить ключи, по которым сайт стоит в ТОП-50 Яндекса/Google и ключи сайтов-конкурентов.
В тексте был указан вариант для xHTML. Но для HTML нужно указывать именно
<html prefix="og: http://ogp.me/ns#">— как в документации. Спасибо, что обратили внимание.Open Graph описывается с помощью синтаксиса RDFa (JSON-LD — нет). JSON-LD подходит для семантической разметки на базе Schema.org (равно как и RDFa, как и Microdata). Open Graph и Schema.org решают разные задачи. Open Graph — грубо говоря, для красивых репостов, Schema.org — опять же, грубо говоря, для красивых сниппетов в поиске. Оба вида разметки прекрасно уживаются на одной странице, о дублировании переживать не стоит.
не всегда дело в процентах. Вот возьмем конкретный пример. Сравним наш основной блог https://blog.promopult.ru/ и этот блог на Хабре. Они решают несколько разные задачи. Первый — отличный трафико- и лидогенератор. Второй — больше для имиджевой составляющей, формирования репутации и узнаваемости в профессиональной среде. Хотя и отсюда лидов идет достаточно. Но тут вопрос ресурсов. Если у вас ресурсов достаточно (денежных и интеллектуальных), можно позволить себе разные каналы, даже если некоторые из них показывают меньшую эффективность. В противном случае приходится выбирать, и обычно лучшим решением становится именно собственный блог — хотя бы потому, что вам не нужно платить за размещение.
еще количество и качество публикаций. Если площадка себя хорошо показывает, наращиваем количество публикаций, уделяем больше внимания качеству контента. А если плохо, то или сворачиваемся, или размещаемся для "галочки" — ссылки тоже полезны. Думаю, тут мы ничего нового не открываем.
Тут скорее дело не в продукте, а в задачах, которые он решает. Возьмем, к примеру, лопаты. Продукт вроде однообразный. Но можно копать на дачном участке, на огороде, весной и осенью, окоп или траншею, в конце концов) Это утрированно, но примерно так. Но даже если ваш продукт решает только одну задачу для одной ЦА, как минимум можно сделать одну или пару нишевых статей. Они точно не помешают. Кроме того, всегда можно подняться на уровень выше — взять более широкую тему и там уже показать, чем полезен ваш продукт. Если хотите, приведите пример продукта — сможем дать более предметный ответ.
Может быть, некорректно спрашивать, но что конкретно вы хотите узнать?
Различия в эффективности разных площадок? Они есть. И мы их учитываем при подготовке материала для публикации.
Спасибо, что обратили наше внимание.
Недавно менялся формат, выгрузка в Директ скоро добавится.
решили сработать на упреждение — а то, мало ли, кто-то еще пойдет пробовать)
Тут не все так однозначно. Если посмотреть справку Гугла, то там сказано: "Этот файл (это про роботс — прим.) не предназначен для того, чтобы запрещать показ веб-страниц в результатах поиска Google. Если вы не хотите, чтобы какие-либо материалы с вашего сайта были представлены в Google, применяйте директивы noindex". Тем не менее ваш совет прописать «Disallow: /» применять не хотим). Но то, что в индекс "просачиваются" некоторые страницы, запрещенные в роботс, то это бывает. В контексте этого, скорее всего, корректней говорить именно о правилах сканирования, нежели индексации. Хотя для реальной практики это не столь важно)
да, спасибо, исправили)
спасибо за уточнение, вы правы. В robots.txt устанавливаются правила посещения разделов сайта роботами. Не просканируют — не проиндексируют. Это в идеале. Хотя на практике robots.txt отрабатывает не на 100%