Блог Внутренняя оптимизация

Мы запустили в работу новый сервис определения релевантности. Кроме анализа текста, мы добавили проверку основных параметров страницы.

Для сравнения, вот пример работы новой версии



Можно сравнить с анализом релевантности в прошлой версии

Нам важно Ваше мнение о том, что может помочь улучшить данный инструмент.

Разговор между исполнителем и заказчиком, или важность составления ТЗ по написанию текста со стороны заказчика.

Заказчик (З):
— Напишите мне текст 2000 символов.
Исполнитель (И):
— Ок, без проблем! Дайте ТЗ по тексту
З:
— KSJDFjjjdf 44A122WE ASDA ASD — ВОТ тз по тексту!
И:
— ВОТ ИЗ ИТ?!
З:
— Это модель оборудования, его нужно описать так, чтобы и в поиске подняться, и для людей было понятно!

И вот это пример того, как нельзя делать!

А вот пример того, как нужно делать ТЗ по написанию текста для страницы, которая уже есть:

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

Опубликовано "AS IS":

Всё чаще я читаю топики на форумах, что SEO — это в большинстве случаев простой развод клиентуры на деньги, смысла в этом нет и прочие негативности. А мне обидно за отрасль, ведь столько толковых техник и "фишек" для продвижения сайтов существует, сколько всего полезного на форумах описано и работает же, сам проверял. Можно, конечно, предположить, что большинство сэкономило, наняло начинающих или неквалифицированных SEO-шников, от чего и пострадало. Я так думал до сегодняшнего дня.

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

И вот, снова это случилось, сайт был сделан на движке drupal 6.0 версии 2010 года, нужно было "по-минимуму" сделать оптимизацию и пустить его в продвижение и контекстную рекламу: http://decomaison.ru/

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

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

Далее было все еще хуже — drupal-специалистов очень мало! А среди наших исполнителей… их НЕТ!

Что ж, было потрачено много часов работы, перебрано 5 программистов и 3 вебмастера… но задача была сделана!
Итак, смотрим как выглядит старый сайт:

И как выглядит новый сайт:

Перед продвижением внешними факторами (поведенческие, ссылки прочее) страницы сайта нужно правильно перелиинковать. Буквально в трех шагах рассмотрим цели, быстро пройдемся по софту и дадим рекомендации.

Шаг 1 — Цели

Перелинковка — это связывание страниц между собой с целью поисковой оптимизации.

Что можно добиться:
— повышение "веса" точек входа на сайт из поисковых систем, это касается всех запросов: ВЧ, СЧ, НЧ
— повышение скорости индексации
— повышение глубины индексации
— увеличение времени нахождения на сайте
— расширение анкор-листа

Шаг 2 — Софт

• Xenu Links — проверка на технические ошибки
• Page Weight — расчет весов страниц
• Screaming Frog Seo Spider — проверка ошибок + sitemap

Шаг 3 — Рекомендации

Разбавляйте анкор-лист
Если на сайте много ссылок с одним анкором — будет "склейка". Избежать "склейку" можно разбавляя анкор-лист.

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

Забудьте о noindex
никак не влияет на передачу веса

Забудьте о nofollow
К ссылкам можно прописывать атрибут rel="nofollow", в следствии которого вес не передается, но снимается.

Прошло уже более четырех лет (февраль 2009 года), с того момента как Google и Yahoo объявили о поддержке тега rel=canonical, и все же эта одна строка HTML-кода до сих пор вызывает много путаницы среди оптимизаторов и вебмастеров. В последнее время Google опубликовал список из 5 наиболее распространенных ошибок с rel=canonical. Этот документ внес определенную ясность, но все равно осталось много вопросов. В этом посте я хотел бы рассмотреть некоторые из наиболее распространенных вопросов

Что такое rel=canonical?

Если по-простому, rel=canonical – это тег, который показывает Google, что один URL эквивалентен другому URL, в целях улучшения результатов поиска. Как правило, URL (B) является дубликатом URL (A), и тег rel=canonical указывает на (A). Этот тег будет отображаться на странице с URL (B)

Документ Google по поддержке rel=canonical на самом деле очень полезен. Дублированный контент является сложной проблемой. Мой пост предполагает, что у вас есть знание технического SEO и Вы пытались использовать rel=canonical на Вашем сайте.

Нужно ли использовать rel=canonical при пагинации?

Я не собираюсь повторять все ответы Google, но эта тема актуальна и заслуживает более подробного рассмотрения. Допустим, у вас есть ряд в страничных результатах поиска (1, 2, 3… N). С точки зрения поиска можно прописать rel=canonical для страницы N и указать страницу 1.

Официально, ответ «нет». Google не рекомендует этого делать. Они рекомендуют, чтобы вы либо прописали rel=canonical на общую страницу со всеми результатами (если имеется возможность создать одну такую страницу), либо использовали тег rel=prev/next. Rel=canonical может быть использован в сочетании с rel=prev/next для обработки результатов поиска, работы всевозможных фильтров и т.д., но это быстро становится сложным. Пагинация для SEO это очень сложный вопрос, но найти информацию о ней можно.

Возможно ли кросс-доменное использование rel=canonical?

Да — в конце 2009 года Google объявил о поддержке кросс-доменного использования rel=canonical. Как правило, это необходимо в случаях, когда вы размещаете свой контент на других сайтах (например, форумы, соцсети и т.п), что приводит к его дублированию, а Вы хотите, чтобы в ранжировании участвовала только одна версия контента.

Нужно ли использовать кросс-доменного rel=canonical?

Это более тяжелый вопрос. Во-первых, Google может проигнорировать кросс-доменное использование rel=canonical, если страницы кажутся слишком разными или есть подозрение в манипуляции алгоритмами. Идеальным использованием кросс-доменного rel=canonical является ситуация, когда несколько сайтов, принадлежащих одной компании, имеют одинаковый контент, который привлекает большое количество трафика. В этом случае, вы, вероятно, не хотели бы использовать 301-редирект (это может запутать пользователей и навредить отдельным сайтам), но вы, возможно, захотите избежать проблемы дублирования контента и контролировать, какой именно сайт отображается в серпе Google. При этом не стоит забывать, что rel=canonical не рекомендуется использовать для передачи PageRank.

Нужно ли использовать rel=canonical на похожем (но не полностью дублированном) контенте?

Результаты тестов показывают, что Google, в некоторых случаях, одобряет использование rel=canonical даже на страницах, обладающих разным контентом. Это не значит, что это хорошая идея. Вообще, я думаю, что лучше использовать rel=canonical исключительно для 100% дубликатов или практически идентичных страниц. Например, если продуктовая страница может генерироваться в нескольких разных версиях (один и тот же продукт, но отличается по одному параметру, такому как упоминание цвета, картинка и т.п.), то да, я думаю, что это именно та ситуация, когда использование rel=canonical с указанием основной (общей) продуктовой страницы является необходимым.

Не используйте rel=canonical в качестве замены уместному 301-редиректу и/или 404-тым страницам. Хотя это, вероятно, не приведет к серьезным негативным последствиям, но есть мнения, что Google начнет игнорировать ваши каноникализационные теги.

Можно ли прописывать rel=canonical на оригинальной версии страницы?

Другими словами, стоит ли прописывать rel=canonical для каноничной URL, указывающий на себя? С практической точки зрения — да, это так, но это не обязательно. Уже на раннем этапе были намеки, что и Google и Бинг предпочитают, чтобы не было злоупотребления rel=canonical. С течением времени, однако, их позиции, кажется, смягчились, и я а последнее время нет никаких доказательств, что правильное использование каноникализации может нанести вред сайту.
Часто это просто практический вопрос. Многие урлы могут иметь общий шаблон и код. В результате достаточно просто забыть прописать rel=canonical на правильную страницу или указать, что страница является дубликатом. Поэтому данный тег удобнее прописать через шаблон сразу на все страницы, которые могут быть сгенерированы при использовании сайта.

Если данный пост будет интересен, я выложу вторую часть, которая посвящена каноникализации сайта целиком, разнице между rel=canonical и 301 редиректом, передаче PR и ряд других вопросов.

Также инфу по каноникализации можно найти здесь.
Комментарии как всегда приветствуются =)

Памятка. Часть 1.

Часть #1 — Общий анализ сайта

1.1 Сбор информации о проекте от клиента

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

доступы в Яндекс.Метрика, Яндекс.Вебмастер
доступы в Google.Analytics, Webmasters.Google
логи сервера
отчеты по SEO
семантическое ядро
выгрузка из бирж, или доступы туда
информация о том, попадал ли сайт хоть когда-нибудь под фильтры
информация о том, что меняли на сайте за последний год (два)
информация о том, какими человеческими ресурсами располагает заказчик
информация о том, какие результаты к каким срокам ожидает заказчик
план развития проекта на ближайший год
порядок внесения изменений на сайте
контактные лица
информация о том, как создаются новые страницы
аудиты (+ТЗ), проводимые ранее
есть ли другие сайты у компании, где продается та же или похожая продукция
есть ли зеркала сайта, менялся ли хозяин домена
логи всей переписки с Платоном Щукиным

Хочу поделиться результатами одного эксперимента и узнать мнение сообщества по этому поводу.
Дано:

• Небольшой интернет-магазин
• Средняя посещаемость 300 чел/день
• Плохая перелинковка

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


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

Лично для себя я сделал вывод, хотя некоторые товарищи и советуют закрывать "сквозняки", без хорошей внутренней перелинковки делать этого не стоит вообще, а с хорошей перелинковкой скрытие особо не повлияет.

У кого какие мысли по этому поводу?

Я долго думал над тем, как начать эту статью? Какие слова сказать первыми? Ведь о внутренней оптимизации уже СТОЛЬКО всего сказанно в интернете и в книгах, что многим вероятнее всего вообще сложно представить себе, что еще можно сказать о ней?

В онлайн трансляции о Яндекс островах был высказан интересный тезис, что данное нововведение, будет больше полезным для сайтов некоммерческой тематики… Думал долго, честно ;) Даже взял блог одной хорошей девушки и попытался набросать для неё свой «Остров». Входные данные — блог о путешествиях, сделан на wp, всё.
Чем может быть полезен Остров? Сниппетом? Блог по некоторым ВК СЧ в топе гугла и яндекса. Для каждого запроса создавать свой остров — пока утомительно. Сначала дождёмся когда технология заработает. Поставив себя на место пользователя, ну вот какой «остров» был бы интересен, например, по запросу «Шенген»? Скорее всего пользователю интересно: как получить шенген, сколько стоит, какие документы для какой страны, адреса посольств в ближайших городах и тп. В данном блоге ответов на эти вопросы нет и переписывать посты под запросы уже вышедшие в топ автору будет лениво. А если и перепишет, это никак не поможет мне сформировать остров, т.к. вся инфа будет в одном посте, растягивать на 10 записей смысла не вижу.
В итоге получилось вот такое:
Ничего кроме как списка категорий и архива по месяцам я придумать не смог. Ну ок, можно ещё сортировку по меткам записей сделать, или, скажем, по категориям фоток. Но, будет ли это интересно в выдаче? Обычно, если блог мне интересен, я читаю его «от» и «до», и никакие острова не помогут, если блог скучный, либо субъективно не нравится читателю.
Пока вопросов больше чем ответов. Яндексу «спасибо» за стимулирование деятельности мозга ;) Всё же, на мой взгляд, острова более заточены как раз под сайты коммерческой тематики, а не наоборот.