Специалисты ЮИК «Передсудом» продолжают развивать наш проект по сбору и анализу данных «Юридического Директа», но, как я заметил в ходе общения с коллегами, возникла проблема с практическим применением полученных нами данных и сделанных выводов. Судя по всему для практических, адресных заключений всё ещё мало информации. В настоящее время ежедневно мы снимаем сотни показателей в рамках «Юридического Директа», по этому уходить ещё глубже в Директ (детализировать запросы или регионы) я не вижу смысла. Нам нужно научиться обрабатывать имеющиеся у нас показатели, прежде чем увеличивать их количество в десятки раз. Кроме этого для того чтобы давать конкретные рекомендации нам недостаёт не информации о контекстной рекламе или ситуации в поисковой выдаче, а статистических данных самих юридических сайтов. Вот где можно найти и обобщить всесторонний опыт реализации Интернет-проектов юридических компаний

Я решил попробовать расширить проект не в глубь, а в ширь. И так:

ЮИК «Передсудом» приглашаем юридические компании, владеющие собственными Интернет-сайтами к сотрудничеству по сбору и объединению обезличенных статистических данных счётчиков Яндекс.Метрики и Google Analytics, а также Яндекс.Вебмастер и Google Webmaster tools. Сотрудничество осуществляется в соответствии с двусторонним соглашением о конфиденциальности.

Полученные данные дополненные статистикой «Юридического Директа» значительно расширят Ваши возможности по обоснованной корректировке Ваших Интернет-сайтов. Вы сможете не только ликвидировать свои ошибки в Интернет-проектах, но и избежать чужие. Кроме этого данный проект позволит Вам повысить точность постановки целей, определения показателей и т.д.

Данный проект – это возможность получить большое конкурентное преимущество в Интернете.

В настоящий момент я обсуждаю условия сотрудничества с партнёрам ЮИК «Передсудом» и иными заинтересованными лицами. Буду рады обсудить данное предложение и с Вами или выслушать Ваши предложения!

С уважением,

А. Никифоров

(реплика Императора Византийского Василевса (голос Табакова)

м/ф «Илья Муромец и Соловей-Разбойник»)

Добрый день, уважаемые читатели!

Сегодня я наконец-то разместил очередной аналитический отчёт по «юридическому» Директу. В течение первых трех недель выяснилось, что работа по сбору статданных, занесение в таблицу и формирование отчётов отнимает много времени. По этому я решил дальше вести учёт статистики в специальной базе данных. Данные также как и раньше собирались и откладывались. Как только база данных была готова я заполнил её всей статистикой, собранной с начала запуска проекта 6 марта и до настоящего времени.

Приношу Вам свои извинения за длительное ожидание. Теперь у нас есть удобный инструмент для сбора и анализа статистических данных, а главное – есть формат хранения имеющихся данных.

So! Главный вопрос на миллион. Зачем всё это?

Как я уже писал здесь, задача проекта помочь в оценке эффективности (как по переходам, так и по деньгам) Вашей контекстной рекламы. Обрабатываемые в рамках данного проекта запросы, в основном, высокочастотные и общие. За основу для списка отслеживаемых запросов был взят так набор поисковых запросов (пакет) по юридической тематике, подготовленный специалистами Яндекса для баннерной рекламы. Этого пакета достаточно, чтобы дать оценку эффективности «юридического» Директа в целом.

В Facebook я видел запрос на сбор статистики по короткому списку конкретных запросов. Учитывая специфику сбора и анализа данной статистики такая работа имеет смысл при условии определения конкретных задач, например, контроль за менеджером по контексту, определение бюджетного коридора в Директе для конкурентов (как по РФ, так и в конкретном округе или субъекте РФ) и т.д. Зная Ваши задачи сбора статистики мы сможем дать Вам наиболее точные данные. Так что если у Вас есть такая необходимость, обращайтесь.

Думаю, что подобная аналитика будет развиваться. Всегда и всё с чем-то надо сравнивать (особенно деньги) и аналитика может служить индикатором. В конце концов контекстная реклама (и Яндекс.Директ не исключение) это биржа, где проходят торги. А на биржах по всему миру есть индикаторы, которые рассчитываются по специальным формулам.

А чем Директ хуже ММВБ?

С уважением,

А. Никифоров

P.S. Не смотря на то что пакет поисковых запросов охватывает большую часть «юридического» Директа и для оценки эффективности этого достаточно, идёт работа по сбору всех «юридических» поисковых запросов, чтобы получить картину на 100%.

Представляем Вашему вниманию новую публикацию в рубрике «Чужой опыт». Основой для поста послужил материал из рассылки №94 проекта SeoPult. Исходный текст ниже, комментарии ЮИК «Передсудом» выделены курсивом.

«Яндекс» и Schema.org

Мы уже писали в нашей рассылке (выпуск №52) о семантической разметке страниц, которая многократно упрощает обработку информации для поисковых машин. Прошло меньше года, но с тех пор утекло много воды и многое изменилось – если раньше микроданные стандарта Schema.org использовала тройка крупнейших поисковых систем, Google, Yahoo и Bing, а отечественный поисковик №1 начинал применять микроформаты класса hProduct, то позже руководство «Яндекса» решило не отставать от мировых трендов и также развиваться в сторону общепринятого стандарта Schema.org.

Принятие стандарта Schema.org

Сложившаяся ситуация по сути требовала двойной оптимизации кода страниц для разных стандартов семантической разметки, чтобы она работала в разных поисковых системах. Осенью 2011 года в «Яндексе» была запущена поддержка тегов Microdata стандарта Schema.org, что стало подарком для многих специалистов – именно с того времени отпала необходимость создавать семантическую разметку для разных стандартов или жертвовать ей для одного из поисковиков.

Стандарт Schema.org развивается, появляются новые варианты разметки, его поддерживают наиболее популярные поисковики, делает его наиболее предпочтительным вариантом при выборе разметки. На сайте Schema.org представлен словарь атрибутов одноименного стандарта и примеры разметки в HTML-коде. В данный момент даже существуют проекты перевода этого сайта на русский язык. А сам «Яндекс» в официальном хелпе дает подробную инструкцию.

Для чего нужна семантическая разметка?

Представьте страницу, на которой размещена текстовая информация. Обычный человек, прочитав ее, может составить краткое резюме в одной двух фразах, выделив самое необходимое. А как при этом быть бездушной машине поисковика? Конечно, он использует фразы с ключевыми словами, но всю суть не сможет передать в емкой короткой фразе, так как он не сможет понять смысла. В случае же применения семантической разметки, где информация четко структурирована, и тегами выделены нужные категории, обработка будет под силу алгоритмам поисковика. Таким образом ему можно подсказать в какой части текста размещена информация определенной категории.

Применяя стандарт Schema.org при верстке страницы, вы можете рассчитывать на то, что поисковая система сформирует отличный информативный сниппет, что является одним из определяющих факторов выбора сайта пользователем в выдаче. Достоверных сведений о влиянии применения такой разметки на естественное ранжирование нет, но зато она дает поисковику гораздо больше информации, что в итоге является большим плюсом. Кроме того, поисковые системы не стоят на месте – те теги и схемы, которые не поддерживаются сейчас, с большей долей вероятности смогут пригодиться в будущем.

Разработка сайтов в соответствии с Scheme.org представляется работой на опережение.  В самом деле, если сайт разрабатывается с нуля почему бы не учесть условия данного стандарта на этапе разработки? Не даёт покоя только один вопрос: как долго проживёт данный стандарт?

Примеры использования Schema.org

Одна из полезных категорий схем разметки для коммерческих компаний – для организаций. «Яндекс» использует подобные схемы для сервиса «Яндекс.Справочник», данные из которого используются в другом популярном сервисе «Яндекс.Карты», весьма который актуален с точки зрения приносимого трафика. Также применение данной схемы будет полезно и для других сервисов.

Подробно разберем схему Organization:

• description – описание деятельности организации;
• image – URL изображения логотипа или любое другое актуальное для организации;
• name – полное название компании в текстовом формате;
• url – URL сайта;
• address – это поле предназначено для указания полного адреса, в том числе в поле addressCountry пишется название страны в текстовом формате, либо по стандарту ISO в двухбуквенном обозначении. В поле addressLocality пишется название населенного пункта, в addressRegion – регион или область, в postOfficeBoxNumber – номер абонентского ящика, в postalCode – почтовый индекс, в streetAddress – улица, номер дома и прочая необходимая информация.
• aggregateRating – это поле предназначено для указания рейтинга организации, если этого предусматривает специфика деятельности;
• contactPoints – контактная информация отдельного сотрудника или компании, это поле удобно в случае уточнения каких-то данных, которые не совпадают с общими контактными данными;
• email – электронная почта;
• employees – данные отдельных сотрудников;
• events – здесь можно указать информацию о мероприятиях, которые связаны с организацией, например, о конференциях и выставках;
• faxNumber, telephone – номера факсов и телефонов;
• founders – основатель компании;
• foundingDate – дата основания;
• interactionCount – это поле предназначено для описания количества взаимодействий с пользователями (лайки, комментарии, загрузки);
• location – место, где расположена компания;
• geo – поле для указания географических координат (latitude – широта, longitude – долгота, указывается цифрами через точку);
• members – члены организации;
• reviews – отзывы или обзоры;
• openingHours – часы работы организации. Сначала указываются дни, после часы работы в эти дни. Перечисление дней делается через запятую, а промежутки через дефис.

Готовый код выглядит примерно следующим образом:

<div itemscope itemtype=»http://schema.org/Organization»>
<span itemprop=»name»>SeoPult</span>
Контакты:
<div itemprop=»address» itemscope itemtype=»http://schema.org/PostalAddress»>
Адрес:
<span itemprop=»streetAddress»>Свободы, 50</span>
<span itemprop=»postalCode»> 125364</span>
<span itemprop=»addressLocality»>Москва</span>,
</div>
Телефон:<span itemprop=»telephone»>+7 495 000-00-00</span>,
Факс:<span itemprop=»faxNumber»>+7 495 000-00-00</span>,
Электронная почта: <span itemprop=»email»>support@seopult.ru</span>
<time itemprop=»openingHours» datetime=»Mo-Fr 10:00-19:00″>С понедельника по пятницу с 10 утра до 7 вечера</time>
</div>

Аналогичным образом осуществляется разметка и по другим схемам.

Специальные сервисы для создания семантической разметки Семантическая разметка с использованием Schema.org требует дополнительных трудовых затрат, что может стать серьезной проблемой при большом количестве страниц. Эту проблему отчасти могут решить специальные сервисы, облегчающие создание кода. Schema Creator – один из инструментов, который позволяет обходиться без ручного ввода тегов. Достаточно лишь вписать текст в соответствующие поля, а код будет сгенерирован автоматически.

Для различных популярных CMS существуют специальные плагины, которые также упрощают создание семантической разметки:

• модуль Schema.org для Drupal;
• расширение Joomla4Schema.org для Joomla;
• плагин Schema для WordPress.

Отечественные CMS оказываются за бортом? Как быстро среагируют на рост интереса к новому стандарту разработчики CMS Bitrix и NetCat? А как будут обстоять дела с другими CMS?

В заключении хотелось бы заметить, что как было сказано в публикации введение семантической разметки сделает работу по наполнению сайта более трудоёмкой и требующей определённой квалификации. В тоже время не постигнет ли семантическую разметку судьба метатегов? Первое время оптимизаторы так активно и грубо использовали метатеги (в частности метатего «ключевые слова»), что поисковики или понизили их вес или просто стали игнорировать тот же метатег «ключевые слова».

Как только у нас будет первый опыт применения данной разметки мы с Вами поделимся.

С уважением,

А. Никифоров

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

Получаю интересные ответы: «Были в старой почте, потерял», «Не помню где файл», «А у Васи [заказчик]всё есть. Пусть он вышлет» и т.д. В итоге этим исполнителям абсолютно всё равно как Вы будете восстанавливать доступ (последний финт ушами) и как будет работать следующий исполнитель. Страдаете только Вы и Ваши интересы.

Но, этой ситуации можно избежать:

1. У Вас должны быть Ваши собственные, никому не известные доступы, т.е. логины и пароли.
   1. Хостинг. Желательно не давать исполнителю, который берёт Ваш сайт на сопровождение доступы в персональный кабинет хостинг-провайдера. Оптимально, когда Ваш исполнитель является партнёром Вашего хостинг-провайдера. Именно по этому ЮИК «Передсудом» подписало партнёрские соглашения с ведущими хостерами: РуЦентр, Мастерхост и Мастернэйм, а также небольшим хостером Timeweb. Нам не нужны Ваши доступы в контрольную панель хостинга (ну только разве для того чтобы перевести Вас к себе на обслуживание, если Вы этого не сможете сделать, после чего Вы можете сменить пароли), мы управляем Вашим хостингом через партнёрский аккаунт. Исключение, как правило, доступ к ftp-серверу, базе данных и в SSH – доступ к каждому сервису только по одной комбинации логин-пароль. Но в случае необходимости Вы, имея доступ к контрольной панели хостинга можете сменить всё пароли. Кроме этого мы, как партнёр хостера, следим, чтобы баланс Вашего счёта был всегда положительным, быстрее можем решать проблемы с хостером на прямую (а не дёргать Вас, чтобы Вы дёрнули их). Не делайте автосохранение логина и пароля в браузере или в другой программе. Такие пароли можно вытащить из базы данных программы. И из под партнёрской опеки выйти совсем не сложно, при этом ничего не теряя.
   2. Регистратор доменных имен. Здесь тоже самое, что и с хостингом. Не делайте автосохранение логина и пароля в браузере или в другой программе.
   3. Система управления сайтом (CMS). Я ещё не встречал такой CMS где не было бы возможности открыть доступы с разными правами разным пользователям. При этом у Вас должны быть самые широкие полномочия в системе управления, что значит, что Вы можете определять полномочия всех других пользователей. Не делайте автосохранение логина и пароля в браузере или в другой программе. В случае необходимости неугодного пользователя можно удалить из системы, но контроль Вы не потеряете.
   4. Сервисы Яндекса (Метрика, Вебмастер, Директ) и Google (Analytics, Webmaster, AdWords). Вы должны иметь доступ к основному аккаунту, а исполнителей добавлять в свой аккаунт как дополнительных пользователей, пусть и с максимально широкими правами. В случае необходимости Вы просто лишаете пользователя доступа и всё.
   5. Комбинации логинов и паролей не должны храниться в:
      1. почте. Со временем их будет сложнее найти, они могут потеряться, могут быть удалены и т.д.
      2. в doc- и xls-файлах . Хотя это вариант, если файлы зашифрованы и закрыты паролем, но всё же они не очень подходят для этих целей.
      3. в блокноте в ящике стола. Трудно структурировать, нельзя тоскать с собой и безопасность минимальная.

Я рекомендую Вам хранить все пароли в специальной зашифрованной базе данных, например, KeePass. Бесплатная кросплатформенная программа. Мои пароли всегда со мной, зашифрованы и закрыты длинным паролем. База позволяет структурировать пароли по папкам, делать подписи, комментарии, примечания, без труда генерировать новые пароли и видеть их взломостойкость, установить напоминалки периодичности обновления паролей и многое другое.

1. Ещё один момент пароль не должен быть связан с Вами и не должен быть простым. Вот, например, хороший пароль mecb*+W\J?lx  и качество неплохое 77 бит, т.е. это пароль вполне безопасный.

Замечу, что в случае необходимости пароли можно пересылать по почте, Skype, ICQ и т.д. (для большей уверенности можно после пересылки пароли сменить).

Следует также помнить, что все эти меры направлены в первую очередь на оперативную и качественную работу над Интернет-сайтом. Потому что от того как оперативно происходит замена исполнителя может зависеть многое – вплоть до стабильности работы сайта и именно в этом контексте здесь понимается слово «безопасность».

Безопасность же в смысле исключения доступа злоумышленника здесь тоже играет важную роль (и именно по этому лучше не хранить ключевые пароли в браузере, не использовать Word и Excel или записную книжку, а также не хранить пароли на почтовом сервере), но все же это вторично потому как кража доступа очень может произойти многими иными способами и путями: клавиатурный перехватчик (keyloger), перехват трафика, фейковый сайт и ещё много чего.

С уважением,

А. Никифоров

Представляем Вашему вниманию новый аналитический отчёт по «юридическому» Директу за неделю 12 – 19 марта. Вы можете также скачать полный отчёт в pdf-формате (с динамикой бюджетов по спецразмещению, а также 1му месту и гарантированным показам).

CTR

Как и в прошлые выходные средний показатель CTR по словам понизился. Но в этот раз произошло более сильное понижение показателя – на 0,1 вместо 0,02 в прошлый выходной. Правда всё это касается только показателя CTR по спецразмещениям. Относительно 1го места и гарантированных показов можно сказать, что они остались неизменны. Также на выходные никак не отреагировал CTR по рубрикам – показатели также остались очень ровными.

Вообще вся неделя прошла под флагом «пониженного CTR». Показатели CTR для 1го места и гарантированных показов лишь чуть-чуть скорректировались вверх 13 марта, а 11 и 12 продолжали планомерное снижение. По спецразмещению 13 марта CTR также достиг своего пика после праздников (хотя этот пик был выше показателей предыдущей недели), после чего также начал снижаться и в пятницу 16 марта уже был ниже праздничных показателей.

Выводы:

Такое «резкое» снижение CTR по спецразмещению на выходные 17-18 марта было на руку действующим рекламным компаниям с более низкими показателями эффективности. И опять же подтверждается наше прошлое предложение – задумайтесь, а стоит ли отключать Директ на выходные?

Ставки

В финансовой сфере наблюдалась иная ситуация. После выходных ставки пошли вверх. По словам торги за 1е место завели ставки на уровень выше ставок спецразмещения (как это не странно, но такая ситуация не редкость). Даже средние ставки по гарантированным показам оказались дешевле средних ставок по спецразмещению чуть меньше чем 0,50 у.е. Этот пик наблюдался 12 марта, после чего ставки за 1е место и гарантированные показы начали снижаться и достигли минимума за неделю как раз в выходные. Возможно менеджеры по контексту (кто боролся за 1е место и гарантированные показы) вошли в раж и торговались до предела, а когда подвели итоги понедельника, то увидели, что сильно поиздержались за день, и на оставшиеся четыре рабочих дня умерили свой пыл.

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

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

Выводы:

Главный вывод: не надо рвать когти и повышать ставки, пытаясь вытеснить соперника с места. Руководство (рискну предположить, что агентство не будет так бездумно и импульсивно тратить средства клиента, скорее всего это удел штатных менеджеров) спасибо не скажет за завышенные ставки. Может быть лучше поработать с поисковыми запросами и уйти от высоко конкурентных слов? Поправить объявления? И в конце концов если клик на 1м месте стоит дороже чем в спецразмещении, то почему Вы ещё не в спецразмещении, а бьётесь за первое место?

С уважением,

А. Никифоров

Сегодня мы приступаем к наполнению в блоге новой рубрики – «Чужой опыт». Здесь (с согласия правообладателей) мы будем размещать материалы коллег по различным вопросам, связанным с IT- и Интернет-технологиями. По возможности и с любезного разрешения коллег мы будем сопровождать данные материалы нашими комментариями и дополнениями.

За основу для нашего первого материала мы взяли статью «Как писать хорошие заголовки в TITLE» из рассылки «Продвижение сайтов. Профессиональные советы экспертов». Ниже исходный текст статьи, комментарии ЮИК «Передсудом» выделены курсивом:

Как хорошо известно даже начинающим оптимизаторам, заголовки, попадающие в верхнюю часть сниппетов поисковой выдачи, формируются из содержимого тэга title. Рик ДеЖарнетт, пишущий для издания Search Engine Land, считает этот тэг критически важным по трём причинам:

• у него самый большой вес для установления релевантности ключевых слов;
• его содержание является самой заметной частью сниппета в SERP;
• это идеальное место для размещения сжатого описания сути страницы (в теории).

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

В идеальном мире утверждение в последнем пункте всегда является истинным. Но реальная жизнь как правило далека от идеала, и во многих случаях вместо этого в тэге прописано что-то вроде «Страница 1» или «Домашняя страница», а то и вовсе ничего нет. Такое содержимое тэга конечно же надо переписывать.

Есть ещё один вариант. На всех страницах в тэге прописано название компании и, возможно, телефон. И такой тэг присутствует на всех страницах.

Также возможно дублирование в тэге хлебных крошек (путь пользователя вглубь сайта), возможно, применённых на самом сайте и выглядит, например, так: ООО «АВС» / Услуги / Арбитраж.

Последний вариант приведённые выше коллегами «Страница 1» и лучше чем название фирмы, но хуже чем может быть.

Часть советов Рика более опытным оптимизаторам может показаться вызывающе очевидной, но опыт показывает, что в любом списке возможных улучшений всегда есть пара идей, которые стоит проверить, особенно когда речь идёт об унаследованных CMS собственного производства и полностью статических сайтах.

1. Используйте только один тэг title на странице

Автору оригинальной статьи не раз доводилось проводить аудит сайтов, страницы которых на поверку не содержали этот тэг вовсе, либо содержали сразу несколько таких тэгов. В некоторых случаях title оказывался размещённым внутри элемента body, а не head, что в принципе нарушает все мыслимые правила и понижает ценность содержимого тэга.

Правило очень простое: на странице должен быть только один тэг title, которым должен быть размещён внутри элемента head, в идеале — сразу после открывающего тэга head.

2. Порядок ключевых слов в заголовке

Тэг title отлично подходит для размещения лучших ключевых слов страницы, тем более что поисковые системы часто оценивают слова заголовка в порядке удаления от начала фразы. Больше того, пользователи тоже обычно читают текст слева направо. Поэтому при составлении заголовка имеет смысл руководствоваться заранее проведённым исследованием трендовых ключевых слов и по возможности размещать более «весомые» ключевые слова в начале.

Разумеется, здесь вступает в силу необходимость находить разумный баланс между желанием написать заголовок, пробивающий статью в топ, и заголовок, который нормально читается людьми. Поэтому заголовок всё-таки должен быть написан естественным языком.

Нельзя забывать, что сайты делаются для людей. А также что Ваш заголовок (title) попадёт в поисковую выдачу и задача заголовка зацепить пользователя и спровоцировать его перейти на Ваш сайт.

3. Название сайта должно идти в конце

Учитывая упомянутый выше понижающийся вес слов в заголовке, название сайта при автоматическом или ручном формировании title стоит перенести в конец. В отдельных случаях это правило можно нарушить, когда вы ориентируетесь на брэндовые запросы. Однако брэндов, которые могут себе позволить подобный перекос в органической выдаче, не так уж и много. В некоторых случаях название сайта из title стоит убрать вовсе.

Представляется, что указывать в title название сайта не имеет особого смысла, но имеет смысл указать название фирмы, т.к. не всегда доменное имя связано с названием фирмы. Но название фирмы незачем дублировать, размещая и в тэге title и в тэге description.

4. Используйте не больше 70 символов, включая пробелы

Поисковики не слишком жалуют избыточно длинный текст в title. После определённого количества символов вес релевантности ключевых слов падает практически до нуля.

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

Поскольку создатели поисковиков часто экспериментируют с внешним видом выдачи, допустимая длина заголовков иногда меняется. На текущий момент 65-70 символов — наиболее безопасный вариант.

5. Реже используйте стоп-слова

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

• притяжательные и указательные местоимения (мой, свой, тот, этот);
• разделительные и противительные союзы (либо … либо, или … или, а, но, зато);
• частицы (если, ведь, действительно).

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

6. Отразите самые важные ключевые слова заголовка в тексте

Поисковые системы давно научились бороться с примитивной накруткой ранжирования путём сопоставления заголовка страницы с их содержанием. Для того, чтобы ключевые слова из title работали, они должны использоваться в основном тексте страницы. Этим вы сообщаете поисковику, что заголовок действительно точно описывает содержание страницы.

Не забывайте, что с недавних пор как Яндекс, так и Google переписывают содержание title для сниппета выдачи, если считают его недостаточно релевантным содержанию. Лучше сразу сделать работу так, чтобы у поисковика не возникало искушения переделать её по своему усмотрению: не факт, что его результат вас устроит больше.

7. Заголовок должен быть уникальным

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

8. Старайтесь избегать повторения текста title в тэге h1

По мнению Рика, текст в title должен отличаться от текста в h1. Несмотря на то, что они оба описывают суть страницы, первый предназначен для формирования сниппета в выдаче, а второй является заголовком текста, который пользователь видит на уже открытой странице. Именно такое разграничение между ними проводят поисковые системы, поэтому во многих модулях SEO для популярных CMS есть отдельное поле для задания содержимого title.

Ну а поскольку содержимое тэга h1 также учитывается при ранжировании страницы, простое повторение текста из title означает, что вы потеряли возможность использовать ещё одно трендовое ключевое слово. Это не значит, что заголовок нужно полностью переписывать. Просто постарайтесь при возможности немного изменить формулировку, не потеряв привлекательность фразы.

Стоит заметить, что, например, в заметках и на страницах в WordPress заголовок страницы, является и заголовком первого уровня. Но если Вы используете в WordPress SEO-плагины, например, All in One SEO Pack, то тот текст, который изначально был title становится фактически заголовком первого уровня, а именно title Вы забиваете в отдельное поле.

9. Не превращайте заголовок в набор ключевых слов

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

Иными словами, идеальный заголовок страницы должен быть лаконичным, т.е. кратким и выразительно описывающим суть основного текста. Это поможет улучшить позиции сайта в выдаче и CTR.

Заключительные комментарии от ЮИК «Передсудом»:

У Вас может возникнуть резонный вопрос: Как Вам самостоятельно узнать заголовок конкретной страницы? Всё просто. Вы заходите на необходимую страницу и наводите мышку на вкладку в которой загрузили эту страницу. Через 1-2 секунды удержания курсора на вкладке Вы увидите всплывающее сообщение, где будет указан title страницы.

С уважением,

А. Никифоров