8 (495) 215-53-73

В Москве

(048) 737-5-736

В Одессе


Главная страница Блог Технические аспекты 9 ошибок при разработке сайта, которые мешают продвижению

Блог SiteClinic

9 ошибок при разработке сайта, которые мешают продвижению

На тему статьи натолкнули несколько Skype-консультаций, во время которых между нашей компанией, клиентом и программистами обсуждались схожие ошибки, допущенные при разработке. Ситуация везде примерно одинаковая – планируется запуск нового сайта. Он уже на 80% сделан. Решили подключать SEO-специалистов, и тут оказывается, что нужно многое переделывать. Ситуация, конечно, лучше, чем когда сайт сдан и править все нужно уже на рабочем проекте «по живому», но все равно такие ошибки выливаются в трату времени и средств заказчика.

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

– «Мы можем реализовать требование оптимизатора, но это будет стоить, как половина сайта»,

– «Расставьте приоритеты, без чего можно обойтись» и т. п.

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

1. Структура сайта спланирована без учета семантического ядра

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

Чем грозит:

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

Как избежать:

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

Это позволит готовить ТЗ с учетом семантического ядра и избежать последующих «допиливаний».

2. Нет возможности оптимизировать все типы посадочных страниц

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

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

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

Чем грозит:

Для продвижения потребуются доработки, чтобы «выпиливать» из фильтров нужные страницы. Задача не из простых, и стоить такая ошибка на старте будет недешево.

Как избежать:

  • В ТЗ укажите все типы посадочных страниц, которые вы планируете использовать.
  • Подготовьте список полей, которые должны быть доступны для редактирования.

Определить типы посадочных страниц SEO-специалист может после базового сбора семантики.

3. Посадочные страницы «вырваны» из структуры и навигации по сайту

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

Чем грозит:

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

Как избежать:

Пользователь, работая с сайтом, должен переходить на посадочные страницы, если они созданы под критерии, выбранные им в системе фильтров. Например, если вы продвигаете запрос «телевизор самсунг 40 дюймов», и под него создана страница, то указав в системе фильтров критерии поиска «samsung» и «40 дюймов», пользователь должен попадать на продвигаемую страницу. Также на продвигаемые страницы должны вести внутренние ссылки.

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

4. Служебные страницы доступны для индексации

Сортировка товаров, фильтры могут генерировать тысячи бесполезных мусорных страниц. Разработчики часто просто закрывают такие страницы в robots.txt, не особо анализируя, все ли ненужные страницы закрыты. Сам по себе такой способ неоптимальный. Google расценивает директивы как рекомендации, и может их не учитывать, включая в индекс страницы.

google_robots

Чем грозит:

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

Как избежать:

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

Помочь может также:
— использование канонических адресов;
— закрытие ненужных страниц в robots.txt;
— использование метатега noindex.

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

5. Ошибки при формировании URL страницы

Использование ЧПУ (человеку понятных URL), продуманная структура, небольшая вложенность страниц – плюсы к удобству сайта и его продвижению. Ошибки тут обычно не критичны и не ставят крест на продвижении. Поэтому иногда разработчики не уделяют этим моментам внимания. В структуру URL нередко закладываются бесполезные промежуточные подразделы. Например, «shop/catalog/тип-товара».

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

Чем грозит:

Может ухудшаться индексация сайта. SEO-специалист лишается возможности оптимизировать URL, используя ЧПУ.

Как избежать:

После базового сбора семантики уже можно определиться со структурой сайта и указать ее в ТЗ. Также в ТЗ нужно включить требования по реализации ЧПУ. 

6. Отсутствие или некорректная настройка автозаполнения заголовков и метаданных

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

Чем грозит:

— дублирование заголовков и метаданных в рамках сайта;
— большое число малоинформативных или нерелевантных заголовков.

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

Как избежать:

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

7. Не все нужные элементы есть на странице

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

Чем грозит:

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

Как избежать:

Попросить оптимизатора оценить макеты до их отрисовки и внедрения. Если есть спорные моменты, решить их еще на этом этапе.

8. Одна и та же подкатегория или товар доступны по разным адресам

Например, на сайте есть возможность выбрать товары по типу (холодильники, телевизоры, пылесосы) и по бренду (Samsung, Toshibа, LG). В итоге один и тот же набор товаров может быть доступен по двум адресам. Пример:

magazin.ru/televizory/samsung/diagonal-40/
magazin.ru/samsung/televizory/diagonal-40/

Чем грозит:

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

Как избежать:

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

Возможные «вилки», когда один и тот же контент может быть доступен по разным адресам, нужно предусмотреть при разработке. В ТЗ укажите, в каких случаях и куда должна быть настроена переадресация.

9. Не учтены базовые технические требования

В большинстве CMS предусмотрены основные SEO-настройки. Опытные разработчики уже знакомы с требованиями поисковых систем и ошибок допускают гораздо меньше. Например, классику жанра, когда сайт не индексируется, потому что его забыли открыть в robots.txt, мы не встречали уже более года. Тем не менее, мелкие огрехи встречаются регулярно.

Чем грозит:

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

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

Как избежать:

Рекомендуем включать в ТЗ базовые SEO-требования. Сделать это вы можете самостоятельно, ориентируясь на наш чек-лист, или попросить сделать это SEO-специалиста. 

Вывод из перечисленных выше проблем очевиден: привлекать SEO-специалиста лучше еще на стадии разработки макетов. Это позволит избежать ошибок и траты ресурсов на их устранение.

Оцените статью: 
1 Star2 Stars3 Stars4 Stars5 Stars (6 оценок, среднее: 5,00 из 5)

Автор: Александр Явтушенко, SEO аналитик SiteClinic.ru

a.yavtushenko@siteclinic.ru

Google+

Подписаться
Наверх
  • Анатолий

    Добрый день !

    Спасибо за статью, очень полезная информация. Подскажите а как называется файл в корневой папке сайта который содержит "Серверные логи", просто на сайте Сергея Кокшарова seochecklist.ru указано что их нада закрывать от индексации, или как их найти по каким признакам ? Еще вопрос вот пришло сообщение в Search Console такого содержания "Googlebot не может получить доступ к файлам CSS и JS", как их открыть ? Сайт написан на Joomla 1.5

    • Добрый день! Обычно логи находятся не в корне сайта, а выше, в папках, к которым доступ для роботов закрыт, да и вообще доступ извне закрыт. Но иногда, обычно если вы сами попросите у хостера, эти файлы логов могут быть и непосредственно в папке сайта. Найти их можно по расширению .log. По поводу: "Googlebot не может получить доступ к файлам CSS и JS"  — можно открыть эти файлы в robots.txt, дополнив его следующими инструкциями:

      Disallow: /wp-content/

      Allow: /wp-content/*.css

      Allow: /wp-content/*.js

      после "User-Agent: *" 

      • Haskin

        А нужно ли открывать эти файлы для индексации гугл-боту? Насколько критичны закрытые файлы скриптов и css для успешного продвижения?

  • Анатолий

    Спасибо, попробую….

  • seoonly

    В ЧПУ многие рекомендуют включать .html Зачем?

    • Раньше использовать расширение рекомендовали, чтобы явно показать поисковым роботам, что это конечная статическая страница, а не папка или категория.

      В настоящий момент эта рекомендация уже не актуальна.

  • uGrade

    ЧПУ лучше, но если оно слишком длинное это не плохо??

    • С одной стороны, вы правы. Слишком длинное — плохо, не юзабельно. Также могут быть случаи спама в url (повторы или спамные включения продвигаемых фраз).
      Но тут же возникает вопрос. «Слишком длинное» — это сколько? Четкого ответа тут не будет. Многое зависит от конкретного случая. Например, если длинный url не содержит спама, и длина оправдана структурой сайта, то, полагаю, проблем нет.
      Чтобы понимать отношение Яндекса к url, рекомендую статью из Помощи для вебмастеров
      https://yandex.ru/support/webmaster/recommendations/site-structure.xml (Пункт 4.)