Базовая SEO-оптимизация: как сэкономить на продвижении ещё при разработке сайта

Настроить SEO (,) нельзя (,) откладывать: часть 1

Сага о том, как базовая SEO-оптимизация на этапе разработки экономит деньги и время на этапе продвижения и что в нее обычно входит

«Спасибо, мы сами» — типичная ошибка всех владельцев сайтов откладывать SEO на потом. Мол, давайте сначала сайт сделаем, а потом я пойду вон к тем ребятам-сеошникам, и они мне всё настроят. Настроить-то настроят, но вопрос в том, как. И насколько эффективным окажется результат.

Типичные проблемы такого сценария следующие.

Это долго

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

4–6 месяцев

в среднем уходит на достижение целевых показателей после начала поискового продвижения. Если у вас сайт изначально не будет готов к SEO — смело добавляйте 2−3 месяца сверху.

Это дорого

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

Самые частые проблемы, о которых говорят SEO-специалисты, — вот эти:

нелогичная или неразвитая структура сайта;
плохо выстроенная иерархия страниц, хромающий уровень вложенности (его либо нет, либо вложенность подчиняется ну очень странным правилам);
плохая индексация страниц — поисковики не хотят их видеть — а также индексация технических страниц (например, /cart, /search);
генерация дублей страниц из-за фильтров или неправильной работы пагинации;
отсутствие доступа к редактированию страниц через админ-панель (а значит, что-либо исправить никак нельзя, кроме проникновения в код проекта);
отсутствие шаблонов мета-тегов.

Это неприятно

Как известно, разработчики с Марса, а сеошники с Венеры. Или наоборот. Но суть остается неизменной: обе группы специалистов недолюбливают друг друга. А чтобы сделать хотя бы базовую настройку SEO после финала разработки вам придется как-то их «подружить» (и скорее всего, принимать огонь гневных комментариев с обеих сторон на себя).

Самые частые камни преткновения разработчиков и сеошников обычно такие:

Технические нестыковки: SEO-специалисты не всегда описывают задачи для разработчиков технически точно, что мешает их реализации (тут без четкого ТЗ вообще никак).

ЧПУ (человеко-понятные URL) и URL-структура: SEO-шники хотят понятных ссылок на страницы и не хотят при этом понимать, что фильтры и пагинация страниц вносят свои коррективы на стороне разработки.

Проблемы с переадресациями, 404 и 301 страницами: если разработчики вдруг поленились настроить редиректы при смене URL, это приводит к потере трафика и позиций в выдаче — а значит, всё, что нажито непосильным трудом предыдущих SEO-специалистов, улетучивается.

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

Например, для клиники репродуктологии «Линия жизни» мы пристально сопоставляли URL по всем страницам при переносе сайта с тестового сервера на боевой и делали ручную проверку, а также тщательное тестирование. Это помогло не потерять ценный SEO-трафик при «переезде».

Индексация фильтров и дубли: та же самая проблема с уникальными ссылками, только вид сбоку.

Ленивая подгрузка контента и SPA-сайты (которые ведут себя как приложения): во-первых, это красиво. Во-вторых, влияет на скорость загрузки контента (мы тут о пользователи думаем, если что). Но SEO-шники за своё: не нравится, мол, поисковикам такое!

Микроразметка и schema.org: помогает поисковикам лучше понимать структуру и смысл контента: где заголовок, где рейтинг, где цена, где рецепт, где адрес. Она же помогает получить сайту расширенные сниппеты в выдаче — например, звёздочки рейтинга, цену, наличие, дату мероприятия или вопрос-ответ. Это повышает CTR (кликабельность) без дополнительных вложений. Но не всегда получается корректно ее привязать. Особенно постфактум, когда сайт уже готовенький, а на этапе ТЗ такого не предусмотрели. И особенно, когда он сделан на фреймворках React или Vue без SSR (server-side rendering).

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

Наталья

Аккаунт-директор

— Если вы хотите не просто сделать сайт, а получить трафик, то SEO никто не отменял. Причем, сеошный трафик сейчас — самый дешевый.

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

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

Must-have любого проекта, или многообразие SEO-настроек

1. Подготовительный этап

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

Поэтому, чтобы у сайта был потенциал занимать верхние строчки позиций в топе выдачи, начинать нужно с аналитики и прототипирования. Кто аудитория проекта? Что ей нужно? Как мы это отразим на главной? Чем зацепим? Все эти вопросы нужны, чтобы точно попасть в ожидания целевой аудитории — а значит, и понравиться поисковикам.

Екатерина

Директор по продукту

— На этапе агрегации требований мы анализируем целевые персоны и строим CJM (Customer Journey Map — карта путей пользователей по сайту).

Основная задача здесь — понять, как конкретная персона попала на сайт и на какую именно страницу. Если это пользователь, который пришел из поисковой системы, — аналитики прописывают предполагаемые запросы, по которым он переходит, и точку входа (страницу), куда тот попадет по клику в выдаче.

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

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

Как выглядит CJM на примере проекта «Водочист»

Адаптивная вёрстка. Это напрямую влияет на SEO, потому что Google и другие поисковики оценивают сайт в первую очередь по мобильной версии (mobile-first indexing). Если сайт плохо отображается на смартфоне или работает на нем слишком медленно, это снижает его позиции в поисковой выдаче.

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

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

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

2. Базовые SEO-настройки

Уникальные классы

Прописываем их для кликабельных функционально-значимых элементов:

кнопки «Отправить» для всех уникальных форм;
тега с номером телефона с общим классом для всех его использований, заданных в административной части сайта.

Почему это важно: уникальные классы позволяют точно отслеживать клики по ключевым элементам — например, по кнопкам «Отправить» или номеру телефона — в системах веб-аналитики («Яндекс Метрика» и Google Analytics). Без них невозможно собрать корректную статистику по действиям пользователей. Кроме того, единообразные классы упрощают настройку целей, событий и сквозной аналитики без вмешательства разработчиков (или самих SEO-специалистов) после запуска сайта.

ЧПУ (человеко-понятные URL)

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

URL на сайте клиники репродуктивной медицины «Линия жизни» полностью совпадает с «хлебными крошками» в навигации по сайту

Для нестатических страниц мы передаем параметры в GET-запросах (обычно это актуально для форм и фильтров).

В URL отражены атрибуты обоих фильтров в формате GET-запроса: и по адресу клиники, и по типу специалиста

Почему это важно: адреса с понятными URL легче читаются и самими пользователями, и поисковыми системами, а также выглядят более доверительными, чем ссылки типа site.ru/dhfhjkjd623mnoiir23r. Кроме того, такие ссылки часто содержат ключевые слова, что повышает шансы попасть в топ выдачи.

Изменения в URL при пагинации

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

Поэтому важно это учесть на этапе SEO-настроек:

Если список товаров/публикаций/чего-угодно подгружается без перезагрузки страницы (через ajax), то при переходе на следующую страницу меняется URL — так, чтобы пользователь мог обновить страницу или отправить ссылку, и при этом сразу откроется та же страница списка, а не первая.
Если человек открыл карточку товара (новость, урок, статью и т. д.) и потом нажал «назад» в браузере, то он вернётся ровно туда, где был: на ту же страницу списка, с теми же фильтрами и сортировкой. При этом более ранние страницы не загружаются автоматически — пользователь сам может перейти к ним через обычную пагинацию.

Почему это важно:

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

Мета-информация

Для всех элементов, формирующих самостоятельные страницы, мы предусматриваем управление шаблонами мета-тегов (title, description, keywords). Это нужно, чтобы каждая страница сайта могла иметь уникальные мета-теги — заголовок и описание, которые будут отображаться в поисковой выдаче.

Те самые мета-теги, которые формируют заголовок и описание в выдаче при поиске клиники репродуктологии «Линия жизни»

Почему это важно: правильно настроенные мета-теги повышают релевантность страницы, улучшают ее видимость и кликабельность при поиске.

Мета-информация для изображений

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

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

Почему это важно:

атрибут alt помогает поисковикам понимать, что именно изображено на картинке;
с прописанным alt изображение может участвовать в поиске по картинкам;
alt-текст — элемент доступности страниц: он озвучивается экранными «читалками» для пользователей с нарушениями зрения.

Счетчик Яндекс Метрики

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

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

При установке счетчика в HTML-код сайта код мы размещаем как можно ближе к началу страницы: обычно в пределах тегов <head></head> — это нужно, чтобы счетчики могли как можно скорее загрузиться и начать фиксировать действия пользователей. Особенно это важно, если пользователь быстро покидает страницу — счетчик внизу может просто не успеть сработать и зафиксировать такой визит.

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

Настройки при выкладке сайта на рабочий адрес

Перед запуском сайта на новом сервере мы проводим отдельные настройки и создаём необходимые SEO-файлы:

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

Файл Robots.txt. Он разрешает полную индексацию открытого контента, при этом страницы административной части мы скрываем от индексации. Обычно это страницы корзины, авторизации и т. д.

Файл .htaccess. Это служебный файл на сервере (в системах, работающих на Apache), с помощью которого можно управлять поведением сайта без изменения кода. Он нужен для настройки важных SEO- и технических вещей, например:

перенаправлений (301-редиректов при смене адресов страниц);
открытия и закрытия доступа к файлам и разделам;
корректной обработки 404-ошибок;
принудительного перехода на HTTPS или на канонический домен (например, с www на без www).

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

3. Небазовые настройки SEO (опциональны, но желательны)

При желании заказчика мы можем сделать больше, чем базовые настройки — это также положительно повлияет на SEO после запуска проекта. Обычно это какие-то индивидуальные требования под специфику проекта или под запросы SEO-специалистов. Чаще всего это следующие работы (большая часть из них требуется не для нового проекта, а если мы забираем готовый сайт на поддержку):

Вид работ	Краткое описание
Установка или удаление счётчиков веб-аналитики	Подключение Google Tag Manager для централизованного управления тегами, удаление старых счетчиков «Яндекс Метрика» и Google Analytics и т. д.
Настройка целей в веб-аналитике	Отправка форм (успешная отправка, ошибки валидациии, клики по телефонам/мессенджерам, email-ссылкам и кнопкам CTA, добавление товара в избранное и т.д.
Подключение eCommerce-событий в веб-аналитике	Например, `view_item`, `add_to_cart`, `begin_checkout` и других
Работа с URL и редиректами	настройка 301-редиректов со старых URL на новые; устранение дублей — может потребоваться при автоматическом переносе контента со старого сайта на новый; указание на канонический (эталонный) адрес URL поисковикам с помощью тега `link rel="canonical" href="…"` (нужен, чтобы избежать дублирования контента)
«Хитрая» настройка метатегов по ТЗ SEO-специалистов	Настройка шаблонов по ТЗ от SEO-специалистов для title, description, robots.txt, sitemap.xml
Снижение дублирования контента на страницах пагинации	Добавляем настройки, чтобы избежать дублирования контента: уточнение «— Страница N» в Title/H1/Description для страниц пагинации; настройка 301-редиректов с ?page=1 на канонический URL без параметра
Работа с фильтрами для снижения числа страниц-дублей	генерация коротких понятных URL для страниц фильтрации и настройка 301-редиректов со старых фильтров на них; шаблонная генерация мета-тегов (title, description, h1) на основе выбранных фильтров; добавление rel="canonical" на страницы фильтров второго уровня (без этого поисковик может считать их отдельными страницами, хотя на деле это не так)
Работа с контентом	добавление SEO-текста внизу страниц листингов и фильтров; добавление инструкций по применению в карточках товаров с разметкой H2/H3, если это не было предусмотрено на этапе разработки;
Работа с Robots.txt и Sitemap	обновление правил в robots.txt: блокировка параметров, разрешение ?page, и так далее (необходимо, чтобы управлять индексацией по мере развития сайта); очистка sitemap.xml от несуществующих URL

Наталья

Аккаунт-директор

— Отдельный случай, если старый сайт уже был оптимизирован — тогда на новом проекте обязательно нужно сохранить важные для SEO моменты (тексты, мета-теги, URL), при необходимости настраивать редиректы и так далее.

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

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

Что дальше

Итак, проект запущен: логичный вопрос, что делать дальше?

Если кажется, что вы разок вложились в разработку нового сайта, которая включает базовые и небазовые SEO-настройки, и больше можно ничего не делать для его оптимизации — увы, это так не работает :)

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