Как решить проблему c объемной навигацией сайта


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

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

blok1

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

Я заметила, что если сквозные блоки по объему кода существенно превышают содержательную часть, то это может сильно притормаживать продвижение (и в Яндексе, и в Google). Эта проблема особенно актуальна для интернет-магазинов, где зачастую вся структура каталога товара отображается в навигации, а также для туристических сайтов, гостиничных порталов и других ресурсов с большими каталогами. Многие продвинутые оптимизаторы считают, что поисковые системы умеют различать сквозные блоки и не принимают их во внимание при ранжировании сайта. Тем не менее, я не раз сталкивалась с ситуацией, когда наличие огромных сквозных блоков мешало продвижению – ни значительные изменения в объемах текстов, ни манипуляции с плотностью ключевых слов вообще не сказывались на позициях сайта. Зато после сокращения сквозных блоков сайт получал значительный скачек по всем запросам и по трафику как с Яндекса, так и с Google. Так что если у вас большое меню и плохие позиции, это вполне может быть взаимосвязано.

Пример 1. Неудобно для людей, плохо для роботов

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

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

Вид меню
на сайте
Меню в коде
(выделено)
розовым
blok2 blok3

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

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

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

Третья проблема не столь существенна, но тоже стоит упоминания. Страница весит около 500 Кб, что достаточно много для html-документа (как правило, в среднем страницы весят 20-50 Кб).

Пример 2. Удобно для людей, плохо для роботов

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

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

Зато на сайте меню имеет вполне аккуратный вид:

blokiz1

При наведении на какой-либо пункт меню появляются всплывающие подпункты, что и обуславливает объемную кодовую часть:

blokiz2

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

Решение проблем с объемной навигацией

Первый способ (простой) – noindex

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

Так поступил один известный в РУнете интернет-магазин бытовой техники. Если мы зайдем на страницу категории “Бытовая техника для кухни”, то увидим, что ссылки на страницы текущего раздела доступны к индексации, в то время как ссылки на все страницы других разделов закрыты для роботов (красным пунктиром выделена часть, закрытая noindeх, синим – nofollow – сделано с помощью Seolib.Toolbar)

Ссылки на страницы текущего раздела Ссылки на страницы других разделов
blokh1 blokh2

Плюс такого способа заключается в том, что можно исправить ситуацию с объемным меню, ничего не меняя во внешнем виде сайта (актуально для уже устоявшихся ресурсов, для которых смена внешнего вида нежелательна). Минусы – такой способ не работает для Google, поскольку он не читает noindex, а nofollow не препятсвует ни индексации текста ссылки, ни утеканию веса (ссылочный вес просто направляется в никуда).

Второй способ – сокращение навигации

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

blokp

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

Осталось резюмировать вышесказанное. Если вы не желаете, что б навигация сайта препятсвовала индексации страниц, важно помнить 2 правила:

1) свозные болки в целом и навигация в частности по объему кода не должны превышать содержательную часть;

2) желательно навигацию в коде размещать после основного текста (div-верстка вам в помощь);

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

С ув., Елена Камская.

Просмотров: 6,274


  • http://dimapolyakov.ru DPolyakov

    А что если переносить навигацию ниже основного контента?

  • Игорь

    Интересная статья. Спасибо, Елена. Скажите пожалуйста каково допустимое количество Noindex на странице, или каков % скрытого кода допустим.

  • Гость

    Первый способ не очень сочетается с содержимым статьи на которую Вы ссылаетесь. noindex не помогает и для Яндекс. Автор статьи не прав или я что то не понял?

  • Blox

    По поводу навигации. Я переделал навигацию по типу http://php.net
    Было древовидное:
    http://help.blox.ru/8.6/?advan
    Теперь такое:
    http://help.blox.ru/latest/?ad
    То есть, в меню совмещены: список текущих ссылок и хлебные крошки (только в вертикальном исполнении). Меню получилось компактное.

    Вообще-то цель была другая – нужно было упростить наполнение по документации BLOX CMS.
    В результате опять же была создана другая система управления содержимым сайта Bloxdoc CMS, но очень простая (PHP-5).
    Ее суть заключается в том, что авторы пишут только содержательные тексты в виде гипертекста без заголовков документа (только содержимое элемента body).
    Эти содержательные файлы помещаются в одну папку, а все файл-данные (картинки, архивы и т.п.) – в другую папку.
    Система навигации же генерируется автоматически всего из двух вещей: элемента H1, плюс небольшого кода-комментария, в котором нужно указывать родительскую страницу.
    Эта простая CMS рекомендуется для применения в сайтах со сложной древовидной структурой навигации и произвольной структурой содержимого.

    Большого поискового эффекта еще не ощутил, так материал сайта технического характера, да и прошло только полмесяца.

  • http://www.facebook.com/people/Kirill-G-Morozov/593894354 Kirill G Morozov

    А как же вариант с навигацией на яваскрипте?

  • http://biz-blog.net Роман Малышев

    это будет неудобно для пользователей как минимум и непонятно для роботов

  • Chelovek

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

  • FreeMan

    Добрый день Елена.
    Не могу подписаться на вашу рассылку по e-mail.
    Выдает следующую ошибку:

    Microsoft OLE DB Provider for SQL Server error ‘80040e31′
    Timeout expired
    /ready.asp, line 759

  • Vollove

    А вот такой вопрос – какой значение для раскрутки может иметь меняющийся блок сайта. Допустим какой то товар случайным образом показывается на главной. Насколько это влияет на продвижение?

  • http://blogopraktika.ru/ Игорь

    Очень интересно, пример с магазином и длинным рулоном навигации показательный, демонстрирует то, да какого абсурда можно дойти. По сути, сайт в таком случае – это свалка ссылок, только внутренних.

  • http://optimizatorsha.ru/ Kamskaya

    Noindex в Яндексе не закрывает переходы робота по ссылкам, но закрывает статичный контент.

  • http://optimizatorsha.ru/ Kamskaya

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

  • http://optimizatorsha.ru/ Kamskaya

    Вроде то был временный глюк, попробуйте подписаться сейчас.

  • http://optimizatorsha.ru/ Kamskaya

    Если меняется не весь контент, а только отдельные блоки – это вполне допустимо, особенно для интернет магазина. Сейчас все зависит от типа сайта. У новостных ресурсов, которые стабильно находятся в топе, например, на главной меняется весь контент каждый полчаса, и это не мешает их ранжированию :)

  • http://optimizatorsha.ru/ Kamskaya

    Свалка ссылок – очень удачное название :)

  • http://dimlazarev.ru/ Дмитрий

    Странно что поисковики не научились вычленять содержательную часть. Кстати что если вставить в существующую структуру кода блоки типа content/main/navigation/text/links – это не поможет Яндексу увидеть очевидное? В хтмл5 вроде что-то такое пытаются ввести?

  • http://damir-tote.blogspot.com/ damir-tote

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

  • Stotland

    А если лишние пункты меню убрать в Ajax?
    (содержимое потом подгружается на страницу с сервера и при просмотре кода, лишних ссылок не будет)

    Я подобное сделал на своём сайте http://www.KupiFonarik.ru (к сожалению сайт не любит Google, видимо по супер фильтром) для верхнего меню, но особых результатов пока не получил, хотя на другом сайте http://www.Stotland.ru результаты есть, трафик вырос на 50 хостов в сутки.

    Как Вы считаете, так можно делать?

  • Сергей

    У меня блог на блогспот http://temarss.blogspot.com/. Там таких возможностей нет. Наверно надо переезжать на автономный блог.

  • Braind

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

  • Noname

    Елена, на каком движке ваш блог?

  • http://optimizatorsha.ru/ Kamskaya

    WordPress

  • Pingback: Ответы на вопросы #5: дубли контента, юзабилити, пользовательские факторы. | Optimizatorsha.Ru()

  • http://www.webpower.ru/ Юрий Кузнецов

    Спасибо, что привели в качестве примера один из созданных и продвигаемых мной сайт http://www.posutochno.com

    Я даже стал немного собой гордиться :)

    Гораздо чаще люди обсуждают другой мой проект http://www.barahla.net
    Буду рад, если Вы напишите когда-нибудь и про него ;)

  • Pingback: Внутренние дубли страниц – чем опасны, как найти и обезвредить. | Optimizatorsha.Ru()

  • Mattiassss

    А можно считать выходом использование jquery? Мне недавно посоветовали скрыть навигацию с его помощью (jquery). Или тогда навигация вообще не будет индексироваться. У меня блоговая структура, я хочу перелинковать внутренние странички между собой и что бы вес с внутренних не утекал, закрыть обратные ссылки на категории.

  • http://optimizatorsha.ru/ Kamskaya

    Все меню закрывать с помощью jquery не советую – будут проблемы с индексацией. Если Вы закроете обратные ссылки атрибутом nofollow, вес все равно будет утекать, но не страницы сайта, а вникуда.

  • Pingback: Навигация по сайту: дизайн и юзабилити()