Профильная экспертиза, кейсы и посадочные под конкретный рынок.
Один партнёр на весь цикл — от запуска до роста по цифрам.
Разбираем, что именно в вашей сборке Битрикса мешает поисковикам: дубли умного фильтра, некорректный композитный кэш, тяжёлые запросы к инфоблокам, служебные разделы в индексе. Правим на стороне платформы, а не только в текстах, и фиксируем в договоре измеримый результат по трафику и заявкам. Бесплатно проверим ваш сайт на Битриксе за 1–2 дня — покажем, что нашли, до любых разговоров о бюджете.
Аудит занимает от 5 до 20 рабочих дней в зависимости от размера каталога. Доступ к админке нужен на этапе работ, для первичной оценки достаточно адреса сайта: первичную оценку делаем бесплатно за один-два рабочих дня и по её итогам говорим, какого порядка бюджет и срок обсуждаются.
Мы работаем с 1С-Битрикс как с инженерной системой: смотрим серверные логи, коды ответов, время генерации страниц, поведение композитного кэша и запросы к базе. Большинство проблем, из-за которых сайт на Битриксе не растёт в поиске, не видно из браузера — сайт открывается, каталог работает, заказы принимаются, а робот в это время обходит служебные адреса и комбинации умного фильтра вместо карточек товаров. Ниже разобрано, что именно ломается, что мы с этим делаем, сколько это стоит и чего нельзя обещать ни за какие деньги.
Ни одно агентство не управляет ранжированием Яндекса и Google — управлять можно только состоянием сайта. Поэтому KPI в договоре мы пишем по небрендовому трафику из поиска и по числу обращений с органики, с базовым замером до старта и точками контроля раз в месяц.
Правим шаблоны компонентов, urlrewrite.php, настройки SEF, кэширование, свойства инфоблоков. Средний технический этап на интернет-магазине — 40–80 задач в трекере, каждая с проверяемым критерием приёмки.
Аудит платформы — отдельная услуга от 40 000 ₽ с постраничным перечнем проблем и приоритетами. Если по итогам аудита выяснится, что сайт дешевле переписать, чем чинить, мы так и скажем, а не будем продавать абонемент.
Битрикс сам по себе не хуже и не лучше других CMS для поиска. Проблема в другом: платформа старая, богатая на функции и очень терпимая к неаккуратной сборке. Она позволит разработчику сделать почти что угодно и не предупредит, что через полгода из этого вырастет двести тысяч мусорных URL или база начнёт отвечать по три секунды. Ниже — те поломки, которые мы находим чаще всего. Список составлен по нашим аудитам, а не по общим статьям: под каждым пунктом лежит конкретный механизм платформы и конкретное место, где он настраивается.
Компонент bitrix:catalog.smart.filter умеет выдавать ЧПУ на каждое сочетание свойств. На каталоге из восьми фильтруемых характеристик это десятки и сотни тысяч адресов, и все они по умолчанию открыты для обхода. Роботу приходится тратить бюджет на страницы «синие кроссовки 43 размера с доставкой за 2 дня», где два товара и нулевой спрос. Мы разделяем набор фильтра на две части: посадочные комбинации, у которых есть частотность в Wordstat и хотя бы 5–7 товаров, и всё остальное. Первым даём ЧПУ, уникальные шаблоны title и H1 через SEO-свойства инфоблока, включаем в sitemap. Вторым закрываем индексацию на уровне метатега robots в шаблоне компонента, а не в robots.txt — закрытое в robots.txt Google всё равно показывает в выдаче как URL без описания. Типовой результат расчистки — сокращение обходимых URL в 20–50 раз при сохранении всех страниц, которые приносили трафик.
Композит в Битриксе разрезает страницу на статическую часть, которая летит из кэша, и динамическую, которую дорисовывает JavaScript. Если разработчик по невнимательности вынес в динамическую часть блок с текстом, ценой или хлебными крошками, робот получит страницу без них. Второй сценарий: композит закэшировал страницу в момент, когда сайт отвечал ошибкой, и месяцами раздаёт этот снимок. Третий: закэшированный ответ содержит чужие персональные данные из личного кабинета. Мы проверяем каждую типовую страницу дважды — из браузера и curl без JS — и сравниваем текстовое содержимое. Всё, что расходится, либо переносим в статическую часть, либо признаём некритичным осознанно. Отдельно настраиваем инвалидацию: тегированный кэш должен сбрасываться по изменению элемента инфоблока, иначе правки метатегов не доезжают до выдачи неделями.
Битрикс по умолчанию хранит свойства элементов вертикально, в таблице b_iblock_element_property: одна строка на одно значение одного свойства одного товара. Каталог на 30 000 товаров с 20 свойствами — это 600 000 строк, по которым идёт джойн на каждой выдаче списка. Добавьте сюда CIBlockElement::GetList без ограничения выборки полей, вызванный в цикле, — получите классический N+1 и время генерации 3–6 секунд. Лечится это не покупкой сервера побольше. Мы включаем хранение свойств в отдельной таблице для инфоблока каталога, выносим фасеты в highload-блоки, ограничиваем SELECT только нужными полями, добавляем индексы под реальные запросы. Замеряем до и после через встроенный монитор производительности и внешние прогоны. Ориентир, к которому идём: время до первого байта — до 400 мс на прогретом кэше, до 1,2 с на холодном.
Стандартная реакция контент-менеджера на закончившийся товар — снять с публикации. В Битриксе это мгновенно превращает карточку в 404, а если товаров тысячи, то в массовое исчезновение страниц, на которых висел весь низкочастотный трафик. Через месяц каталог теряет 15–30 % органики, и никто не связывает это с закупкой. Правильная схема другая. Товар, который вернётся, остаётся опубликован и отдаёт 200, но в карточке стоит явный статус, отключена кнопка покупки и показан блок аналогов из того же раздела. Товар, снятый навсегда, получает 301 на ближайший аналог или на раздел — не на главную, такие редиректы Google трактует как мягкую 404. Товар, которого не было в индексе и который никому не нужен, спокойно удаляется. Разделение мы автоматизируем: правило зашивается в обработчик события, а не держится на дисциплине менеджера.
Параметр PAGEN_1 живёт в Битриксе с незапамятных времён и порождает сразу несколько проблем. Первая: одна и та же страница доступна и как /catalog/obuv/, и как /catalog/obuv/?PAGEN_1=1 — прямой дубль. Вторая: на всех страницах пагинации одинаковые title, H1 и описание раздела, поисковик видит серию клонов. Третья, самая дорогая: попытка это вылечить каноническим адресом на первую страницу приводит к тому, что товары со второй и дальше вообще перестают находиться, потому что робот не считает нужным ходить по неканоническим спискам. Мы делаем иначе: первая страница живёт без параметра, дубль с PAGEN_1=1 редиректится на неё, у остальных страниц к title добавляется номер, текстовое описание раздела выводится только на первой, канонический адрес каждая страница указывает на себя, а ссылки на пагинацию остаются обычными <a href>, а не подгрузкой по клику.
Битрикс умеет отдавать один и тот же элемент по нескольким путям одновременно: через SECTION_CODE_PATH с вложенностью разделов, через плоский SECTION_CODE, через /catalog/element.php?ID=1234, а иногда ещё и через старый URL, оставшийся от предыдущей версии сайта. Все четыре отвечают 200 и содержат одинаковый текст. Добавьте сюда index.php в конце пути, необязательный слэш и апперкейс в символьном коде — и количество вариантов одного товара доходит до восьми. Мы приводим правила в urlrewrite.php и в настройках SEF-шаблонов компонентов к единственной канонической форме, вешаем 301 со всех остальных вариантов и добавляем сторожевой скрипт, который раз в неделю дёргает выборку адресов и сообщает, если новая сборка снова начала отвечать по двум путям.
Свежий Битрикс из коробки отдаёт наружу довольно много того, чего в поиске быть не должно: /bitrix/ со служебными скриптами, /auth/, /personal/ с корзиной и заказами, /search/ с результатами внутреннего поиска, включаемые области из /include/, страницы печати и сравнения, а также адреса с ?clear_cache=Y, ?back_url_admin= и ?login=yes. Внутренний поиск особенно опасен: он генерирует бесконечное число страниц по любому запросу, и один раз проиндексированный мусорный запрос тянет за собой сотни таких же. Мы закрываем это на трёх уровнях сразу — метатег robots в шаблонах соответствующих компонентов, правила в robots.txt для тех адресов, которые ещё не в индексе, и удаление уже проиндексированного через инструменты Вебмастера и Search Console. Разово выкидываем из индекса и открытые копии сайта на технических поддоменах: их находят почти на каждом втором аудите.
Классика платформы: удалили раздел, зашли по старому адресу, увидели красивую страницу «ничего не найдено» — и решили, что всё в порядке. А в заголовке ответа стоит HTTP/1.1 200 OK, потому что константа ERROR_404 объявлена, а CHTTP::SetStatus('404 Not Found') в шаблоне не вызывается. Для поисковика это означает, что страница жива и её надо держать в индексе. Мы проверяем коды ответов массово, прогоняя весь известный список URL из логов, sitemap и старых выгрузок, и приводим их к правильным: несуществующее — 404, перемещённое — 301, временно закрытое на технические работы — 503 с указанием времени возврата. Отдельно ловим обратную ошибку — 404 на живых страницах после переезда каталога, когда часть символьных кодов сменилась при перегенерации.
Если товар в Битриксе разложен на торговые предложения — размеры, цвета, объёмы — платформа охотно даст каждому предложению собственный адрес или собственный набор GET-параметров. В индекс уходит пять почти одинаковых карточек одной футболки, каждая с тонким текстом, ни одна не набирает достаточной релевантности. Одновременно теряется главное: цена, наличие и характеристики выбранного варианта часто дорисовываются скриптом и не попадают в разметку, поэтому в сниппете нет цены. Мы собираем карточку так, чтобы адрес был один, а все варианты присутствовали в исходном HTML, и микроразметка Product с блоком offers перечисляла реальные предложения с ценой и статусом наличия. Отдельно следим, чтобы структурированные данные совпадали с тем, что видит человек, иначе Яндекс и Google просто перестают их учитывать.
Штатный генератор карты сайта в модуле поисковой оптимизации ходит по инфоблокам через веб-запрос и на каталоге в 50 000+ позиций стабильно упирается в лимит времени выполнения. Итог: файл обрывается на середине, часть разделов в него не попадает, а рядом остаются старые файлы с адресами, которых давно нет. Робот исправно скачивает их и тратит бюджет на 404. Мы переносим генерацию на cron с разбиением на индексный файл и части не более 45 000 URL, вычищаем из выгрузки всё, что закрыто от индексации или отвечает не 200, и добавляем в файл честные даты последнего изменения, взятые из даты изменения элемента, а не проставленные сегодняшним числом на все строки скопом.
Битрикс запускает фоновые задания двумя способами: на хитах посетителей и по cron. Первый вариант включён по умолчанию, и это значит, что один невезучий посетитель — а с равной вероятностью робот — оплачивает своим временем ожидания переиндексацию поиска или рассылку. Вдобавок модуль поиска пишет содержимое всего сайта в b_search_content, и на большом каталоге эта таблица разрастается до размеров, сопоставимых с самими данными. Скорость ответа плывёт непредсказуемо, а поисковый робот честно записывает эти всплески себе в статистику. Мы переводим агенты на cron, разносим тяжёлые задания по ночному окну, чистим и ограничиваем область индексации внутреннего поиска, а при необходимости выносим поиск на отдельный движок. Речь не про красоту архитектуры: нестабильное время ответа напрямую снижает частоту обхода.
В Битриксе title и description страницы могут прийти из свойств страницы, из SEO-свойств элемента инфоблока, из шаблонов метатегов раздела, из настроек компонента и из кода шаблона сайта — причём приоритеты между ними неочевидны и меняются от сборки к сборке. Практический результат: контент-менеджер правит заголовок в карточке товара, ничего не меняется, он правит ещё в одном месте, тоже ничего, а через неделю выясняется, что всё перебивает жёстко прописанный шаблон в header.php. Мы разбираем эту цепочку до конца, оставляем один управляемый источник на каждое поле, документируем его для команды клиента и проверяем результат на живых страницах всех типов. Побочный эффект — заголовки наконец можно править массово через шаблоны, а не руками по одной странице.
Битрикс позволяет развести регионы тремя разными способами: поддоменами, папками и подменой контента по геолокации на одном адресе. Первые два поисковые системы понимают, третий — нет: для робота это один сайт с плавающим содержимым, и он будет ранжировать его в одном регионе, каком именно — вопрос удачи. Чаще всего мы видим гибрид: поддомены есть, но контент на них подменяется скриптом, телефоны подставляются по IP, а в разметке и в title остаётся Москва. Разбор начинается с решения, какая схема нужна бизнесу: если у вас реальные офисы и склады в городах, имеет смысл полноценное разделение с уникальными контактами, ценами и текстами. Если региональность номинальная, лучше не плодить поддомены вовсе — десяток пустых клонов вредит сильнее, чем отсутствие региональных версий. После выбора схемы приводим в порядок региональную привязку в Вебмастере, перелинковку между версиями, разметку организации с адресами и правила, по которым робот попадает на нужную версию без редиректов по геолокации.
Выгрузка в Яндекс Маркет, товарные галереи и рекламные кабинеты в Битриксе обычно собирается отдельным механизмом, живущим своей жизнью. Через полгода после запуска фид содержит цены, которых на сайте нет, товары, снятые с продажи, и адреса, которые отвечают 404. Для товарного поиска это прямой сигнал недоверия: расхождение цены между фидом и посадочной страницей ведёт к отклонению оферов, а иногда и всего каталога. Отдельная типовая беда — адреса в фиде с рекламными метками, которые открыты для индексации и порождают ещё один слой дублей каталога. Мы синхронизируем фид с тем же источником данных, из которого рендерится карточка, добавляем регулярную сверку с прогоном всех адресов из выгрузки на коды ответа и цену, а параметрические адреса из фида закрываем от индексации так, чтобы они при этом остались рабочими для рекламных систем.
Механизм включаемых областей — удобная штука: кусок текста лежит в отдельном файле в /include/ и подключается в шаблон. Проблема в том, что этот файл доступен по прямому адресу и отвечает кодом 200. В индекс уходит голый фрагмент без шапки, без навигации и без стилей — и поисковик видит его как отдельную страницу низкого качества. На сайтах с большим числом включаемых блоков таких фрагментов набирается несколько сотен. Они не приносят трафика, зато исправно портят общую оценку качества сайта и оттягивают на себя обход. Закрывается это на уровне веб-сервера — запретом прямого доступа к каталогу включаемых областей, — а уже проиндексированное убирается через инструменты вебмастера. Заодно проверяем соседние каталоги: шаблоны писем, файлы обмена с 1С и служебные обработчики точно так же часто открыты наружу.
На каждом втором магазине каталог наполняется из 1С, и именно обмен чаще всего оказывается источником внезапных потерь трафика. Механизм простой: при выгрузке товар сопоставляется по внешнему коду, но если правило формирования символьного кода в настройках инфоблока стоит на автоматическую транслитерацию названия, то любое изменение наименования в учётной системе меняет адрес карточки. Старый адрес превращается в 404, новый начинает историю с нуля. За один неудачный обмен так можно потерять тысячи страниц. Второй сценарий — обмен деактивирует товары, которых не было в очередной выгрузке, потому что менеджер выгрузил не весь справочник. Мы фиксируем символьный код после первой публикации и запрещаем его перегенерацию, вводим предохранитель на массовую деактивацию (если в одной сессии обмена гасится больше заданного процента каталога, обмен останавливается и уходит уведомление), а на все исторические изменения адресов строим карту редиректов.
В типовой сборке единственный способ добраться до карточки товара — пройти через раздел и пагинацию. Товары с двадцатой страницы списка формально доступны, но отделены от главной десятком переходов, и робот доходит до них в последнюю очередь либо не доходит вовсе. Одновременно в шаблоне часто висит меню на несколько сотен ссылок, которое размазывает вес по всему сайту ровным слоем. Мы перестраиваем связи так, чтобы важные страницы получали ссылки из содержательных блоков: аналоги и сопутствующие товары в карточке, ссылки на посадочные фильтра из описания раздела, подборки и теги, блоки популярных запросов. Всё это делается штатными средствами инфоблоков и не требует переписывания шаблона с нуля. Контрольный показатель простой: доля страниц, до которых можно дойти от главной не более чем за три перехода, должна расти, а глубина обхода в логах — уменьшаться.
Отдельная строка почти в каждом аудите. У компании есть боевой сайт, а рядом — тестовая копия на поддомене вида dev. или new., оставшаяся после разработки, плюс иногда портал Битрикс24 и демо-версии. Копии открыты, отвечают 200, содержат тот же контент и спокойно индексируются. Дальше начинается неприятное: поисковик сам решает, какая версия основная, и иногда решает не в вашу пользу — трафик уходит на поддомен, который никто не поддерживает и на котором висят старые цены. Лечится это не только запрещающим файлом: копию нужно закрыть авторизацией на уровне веб-сервера, чтобы её физически нельзя было прочитать, а уже проиндексированные адреса удалить через панель вебмастера. Заодно проверяем, что боевой сайт доступен по одному варианту домена, а не по четырём — с www и без, по http и https.
Часть сайтов на Битриксе досталась бизнесу из времён, когда мобильную версию делали отдельным поддоменом или отдельным шаблоном с урезанным содержимым. Сейчас поисковые системы оценивают сайт по мобильному представлению, и урезанный шаблон означает урезанную оценку: если на телефоне нет части текста, характеристик, отзывов или блока с ценой, для поиска этого содержимого просто нет, сколько бы его ни было в десктопной версии. Мы сводим обе версии к одному содержимому — либо переводя проект на единый адаптивный шаблон, либо приводя мобильный шаблон к полноте десктопного. Одновременно проверяем, что переключение между версиями не делается редиректом по признаку устройства с потерей адреса страницы: типовая ошибка, когда телефон, открывший ссылку на карточку товара, приземляется на мобильную главную.
Заключительный пункт, который формально не про поиск, но определяет, что вообще можно сделать с сайтом. Битрикс позволяет отредактировать файлы ядра напрямую, и на проектах с длинной историей подрядчиков этим пользовались охотно: быстрее, чем делать по правилам. Итог — сайт, который нельзя обновить: обновление затрёт правки и что-нибудь сломает, поэтому его откладывают год за годом. Вместе с обновлениями сайт не получает ни исправлений безопасности, ни новых возможностей штатных компонентов, включая те, что касаются адресов, разметки и кэша. Мы находим такие места сравнением с эталонной поставкой, выносим доработки в собственные компоненты и обработчики событий и возвращаем проект в состояние, когда обновление — рутинная операция, а не событие с привлечением всей команды.
Ни одна из этих поломок не видна из браузера. Сайт открывается, каталог работает, менеджеры принимают заказы — а поисковая система тем временем тратит выделенный на сайт ресурс на обход того, что никому не нужно, и не доходит до карточек, которые могли бы приносить деньги. Именно поэтому мы начинаем работу с логов и кодов ответа, а не с текстов: текст на странице, до которой робот не доходит, не имеет значения.
Ни один из двадцати пунктов выше не требует переезда на другую CMS. Это всё чинится на месте, штатными средствами платформы, и на типовом интернет-магазине основная часть работ укладывается в 6–10 недель. Дорогое здесь не исправление, а промедление: каждый месяц с открытым фильтром и незакрытыми служебными разделами — это месяц, когда робот обходит мусор вместо ваших карточек, а конкурент с более скучным сайтом, но чистой технической частью, набирает трафик. Мы начинаем с того, что показываем полный список найденного с адресами и приоритетами, и вы сами решаете, что чинить в первую очередь, а что может подождать.
У робота на каждый сайт есть лимит: сколько адресов он готов обойти за визит. Если каталог отдаёт ему десятки тысяч комбинаций фильтра, страниц пагинации и служебных адресов, лимит расходуется на них — а до страниц, которые продают, очередь просто не доходит. Слева — типичный лог обхода до расчистки, справа — он же после.
Проверить это на своём сайте можно и самостоятельно: в Яндекс.Вебмастере раздел «Индексирование → Статистика обхода» показывает, по каким адресам робот ходил на самом деле. Если в первой сотне преобладают адреса с ?set_filter, PAGEN_ и /search/ — вы видите ровно левую колонку.
Состав работ ниже — не список услуг вообще, а последовательность, по которой мы идём на проекте на Битриксе. Порядок имеет значение: пока платформа отдаёт дубли и отвечает по три секунды, писать тексты и закупать ссылки бессмысленно, деньги уйдут в страницы, которые робот не успевает обойти. Поэтому первые два направления всегда идут в начале, а внешние сигналы подключаются не раньше третьего месяца. Внутри каждого направления мы работаем задачами с проверяемым критерием приёмки: у любой строки в плане есть ответ на вопрос «как понять, что это сделано» — не «специалист посмотрел», а конкретная проверка, которую может повторить кто угодно.
Начинаем с того, что фиксируем текущее состояние в цифрах, а не в оценках. Снимаем логи веб-сервера минимум за 30 дней и смотрим, куда на самом деле ходит робот: доля запросов к служебным адресам, к параметрическим адресам фильтра, к 404 и редиректам, распределение обхода по разделам и по дням. На каталогах, которые к нам приходят, доля полезных обходов обычно 20–40 %, остальное — мусор. Это самый недооценённый источник данных: он показывает не то, что мы думаем о сайте, а то, что с ним делает поисковая система.
Параллельно прогоняем полный краул сайта с отдельным профилем под Битрикс. Профиль важен, потому что стандартные настройки краулера либо не доходят до параметрических адресов фильтра, либо тонут в них. Ловим цепочки редиректов, дубликаты заголовков и описаний, страницы с кодом 200 без содержимого, адреса, доступные по нескольким путям, битые внутренние ссылки, циклы пагинации.
Дальше идёт разбор самой сборки. Смотрим версию ядра и модулей и наличие непереносимых правок в ядре — это определяет, можно ли вообще обновляться. Проверяем, включён ли композитный кэш и что попало в динамическую часть. Разбираем, как хранятся свойства инфоблоков и какие запросы к базе оказываются самыми дорогими. Находим все места, из которых приходят метатеги. Читаем правила маршрутизации и настройки SEF-шаблонов компонентов. Проверяем, какие фоновые задания висят на хитах посетителей. Разбираем, как собирается карта сайта и что в неё попадает. Отдельно смотрим коды ответов, разметку и скорость по каждому типовому шаблону — главная, раздел, подраздел, посадочная фильтра, карточка товара, статья, страница услуги.
Если проект товарный, добавляется анализ ассортимента: сколько позиций реально доступно, какая доля каталога находится в поиске, какие разделы не имеют ни одной страницы в индексе. Часто выясняется, что половина каталога не индексируется не по техническим причинам, а потому что в разделе три товара и поисковику нечего оттуда брать.
Есть и обратная задача — понять, что на сайте работает хорошо, чтобы это не сломать. Перед любыми правками мы выписываем страницы, которые приносят основной трафик и обращения, и заводим по ним отдельный контрольный список: адрес, заголовок, текущее содержимое, позиции по своим запросам. К этому списку возвращаемся после каждой выкладки. Половина громких историй «сделали SEO и трафик упал» — это не неудачные новые страницы, а сломанные старые.
Это основной объём на первые два-три месяца. Работаем в коде — в шаблонах компонентов, в настройках инфоблоков, в правилах маршрутизации, в конфигурации кэша и окружения. Типовой перечень: разделение умного фильтра на посадочные и служебные комбинации, приведение адресов к канонической форме с постоянными редиректами со всех вариантов, починка кодов ответа, переработка пагинации, перенос свойств каталога в отдельное хранилище, вынос фоновых заданий на регулярный запуск, настройка тегированного кэша и его сброса, чистка карты сайта и перевод её генерации на расписание, закрытие служебных разделов и включаемых областей.
Отдельный блок — скорость. Мы не гонимся за красивой цифрой в синтетическом тесте: смотрим на реальные показатели у пользователей и на время ответа сервера, потому что именно оно определяет, сколько страниц робот успеет забрать за сутки. Разбираем медленные запросы по логу базы, убираем выборки в циклах, включаем кэширование там, где его выключили «чтобы данные были свежие», настраиваем отдачу статики, современные форматы изображений и их размеры под реальные контейнеры. На больших каталогах отдельно занимаемся первой загрузкой без кэша — именно её чаще всего видит робот, приходя на редко посещаемую страницу.
Ещё один блок — устойчивость. Сайт, который раз в неделю на десять минут отдаёт ошибку сервера, теряет в обходе больше, чем принято думать, и падение это обычно никто не замечает, потому что случается ночью. Мы ставим внешний мониторинг доступности и кодов ответа по списку ключевых адресов и подключаем уведомления, чтобы проблема всплывала в день появления, а не в квартальном отчёте.
Отдельный разговор — обновление ядра. На проектах, где предыдущие подрядчики правили файлы ядра напрямую, обновиться нельзя: любое обновление затрёт правки, и сайт сломается. Такие места мы находим сравнением с эталонной поставкой и выносим доработки туда, где им положено быть — в собственные компоненты, обработчики событий и переопределённые шаблоны. Работа неблагодарная, её не видно в отчёте по трафику, но без неё через год вы окажетесь на версии, которую нельзя обновить и по которой уже не выпускают исправления безопасности.
Все изменения идут через ветку и тестовый контур, а не правкой боевых файлов через админку. Перед выкладкой снимаем контрольные срезы кодов ответа и текстового содержимого ключевых страниц, после — сверяем. Если что-то поехало, откат занимает минуты. На проектах, где своей команды разработки нет, работы делаем сами; где есть — отдаём задачи с описанием и принимаем результат.
Собираем спрос по всей нише, а не только по тем запросам, по которым сайт уже виден. Источники: Wordstat с раскрытием по глубине, поисковые подсказки, запросы из Метрики и из внутреннего поиска по сайту, выгрузка видимости конкурентов из ТОП живой выдачи, а для товарных ниш — сами названия, модели, артикулы и характеристики товаров. В товарке большая часть спроса формулируется именно так, и её нельзя собрать, глядя только на общие запросы.
Дальше кластеризация по совместной встречаемости в выдаче. Это принципиальный момент: два запроса объединяются в одну страницу только тогда, когда поиск сам показывает по ним пересекающиеся результаты. Развести «купить диван» и «диван недорого» на одну страницу можно, а «диван» и «диван-кровать» — уже нет, и решает это замер, а не мнение редактора. Мы проверяем пересечение по живой выдаче Яндекса и Google отдельно, потому что в части ниш их представления о структуре спроса расходятся, и тогда приходится выбирать, под какую систему собирать структуру, исходя из того, откуда идут деньги.
Готовые кластеры раскладываем на структуру: что становится разделом, что подразделом, что посадочной страницей умного фильтра, что тегом, что материалом в блоге. Для Битрикса это особенно осязаемо, потому что посадочные фильтра — самый дешёвый способ занять низкочастотный спрос: страница создаётся настройкой, а не разработкой, и на большом каталоге таких страниц можно ввести несколько сотен за месяц.
Каждую запланированную страницу проверяем на два условия: есть ли реальный спрос и есть ли чем её наполнить. Страницы, которые проходят по частотности, но не проходят по товарам, ставим в очередь до расширения ассортимента, а не выпускаем пустыми — пустая посадочная не поднимется и потянет вниз оценку раздела. Обратный случай тоже разбираем: если товаров много, а спроса под них в нужной формулировке нет, значит, ассортимент описан не теми словами, которыми его ищут, и правится описание, а не структура.
Отдельная часть работы — разбор запросов, по которым сайт уже виден, но на второй-третьей странице выдачи. Это самый дешёвый рост: страница уже есть, она уже релевантна, ей не хватает немного. Мы выписываем такие запросы отдельным списком и смотрим по каждому, чего именно не хватает — полноты ответа, коммерческих элементов, скорости, внутренних ссылок или просто цены на странице. На проектах с историей этот список обычно даёт первый заметный прирост трафика раньше, чем начнут работать новые посадочные.
Тексты пишем под конкретную страницу и конкретную задачу, а не «на 3000 знаков для объёма». Для разделов каталога это короткое описание, отвечающее на вопросы выбора: чем варианты отличаются, как подобрать под задачу, что входит в цену, какие сроки и условия. Для карточек — характеристики в структурированном виде, комплектация, совместимость, условия доставки и возврата, реальные фотографии вместо изображений поставщика, которые уже стоят на сорока сайтах.
Для посадочных фильтра нужен отдельный подход: текст минимальный, но не шаблонный. Тысяча страниц с переставленными словами из одного шаблона быстро попадает под фильтр за малополезный контент, и вместе с ними просаживается весь раздел. Мы делаем содержательными только те посадочные, у которых есть заметная частотность, а остальным даём корректные заголовки, разметку и товарную выдачу без текстового блока вовсе — этого достаточно.
Коммерческие факторы на товарных сайтах весят не меньше текста. Приводим в порядок цены и наличие, добавляем сравнение и отзывы, показываем условия доставки прямо на карточке, а не в отдельном разделе, выводим аналоги и сопутствующие товары. Это одновременно улучшает поведение пользователей и полноту сниппета, а на части запросов просто определяет, попадёт ли сайт в число тех, кого поиск считает нормальным магазином.
Отдельно занимаемся микроразметкой: товар с ценой и наличием, хлебные крошки, организация с реквизитами и адресами, блок вопросов и ответов там, где вопросы действительно есть на странице. Разметку проверяем валидатором и, что важнее, сверяем с видимым содержимым: при расхождении данных поисковик перестаёт использовать разметку целиком, а не только спорное поле.
Для сайтов услуг вместо каталога работаем с посадочными страницами: разбираем возражения, показываем цены или хотя бы вилки, состав работ, сроки, примеры и ограничения. Страница без цены проигрывает по конверсии и по поведению независимо от того, насколько хорошо она написана, а вилка с объяснением, от чего зависит сумма, работает лучше, чем «стоимость по запросу».
Тексты пишут редакторы, а не генератор, и это не вопрос принципа, а вопрос результата: страницы, собранные из общих формулировок, одинаково плохо конвертируют и одинаково плохо ранжируются, потому что не отвечают ни на один конкретный вопрос. Материал под сложную тему мы собираем из разговора с вашими специалистами: полчаса с человеком, который реально делает работу, дают больше фактуры, чем неделя чтения чужих сайтов. Готовый текст перед публикацией проверяем на фактические ошибки у вас — это дешевле, чем снимать неверную информацию с боевой страницы через месяц.
Отдельно ведём учёт того, что уже написано и как оно сработало. Каждая опубликованная страница попадает в общий реестр, а через 6–8 недель мы возвращаемся и смотрим, вышла ли она в индекс, набрала ли показы и по каким формулировкам её находят. Часть страниц требует доработки, часть оказывается лишней, и об этом лучше знать по данным, а не по ощущению.
Подключаем не раньше, чем сайт технически готов принимать вес: до этого ссылки размывают его по мусорным адресам и по страницам, которые скоро изменят адрес. Работаем узко и проверяемо. Основа — тематические площадки и справочники, отраслевые каталоги и агрегаторы, ресурсы с реальной аудиторией и живым трафиком. Массовых прогонов и биржевых пакетов не делаем: они дают короткий всплеск и долгий шлейф проблем, разбирать который дороже, чем не начинать.
Второй слой — карточки в картах и справочниках для локального спроса, с полным заполнением реквизитов, категорий, фотографий, режима работы и обработкой отзывов. Для многих коммерческих ниш в Москве этот слой приносит больше обращений, чем позиции по средним частотникам, и стоит существенно дешевле.
Третий слой — упоминания без ссылок и репутация в поиске по бренду. Смотрим, что выдаётся по запросам вида «название компании отзывы», и работаем с этим отдельно: для сделки на сотни тысяч рублей содержимое первой страницы по бренду решает больше, чем место сайта по общему запросу. Здесь же — присутствие в отраслевых рейтингах и подборках, куда попадают по формальным критериям, а не за деньги.
Перед началом внешних работ обязательно разбираем ссылочное прошлое сайта. У проектов с историей часто обнаруживается наследство от прежних подрядчиков: сотни размещений на сетках сайтов, которые давно выпали из индекса, ссылки с адресов, отвечающих ошибкой, или ссылки на страницы, которых на сайте больше нет. Последнее чинится проще всего — редиректом, и это бесплатный способ вернуть уже оплаченный когда-то вес. С остальным работаем по обстоятельствам: массовое отклонение ссылок сегодня требуется редко, но знать, что именно на вас ссылается, нужно до того, как добавлять новое.
Каждый размещённый адрес попадает в реестр с датой, стоимостью, типом размещения и статусом индексации. Раз в квартал реестр пересматриваем: площадки, выпавшие из индекса, сменившие тематику или обвешавшиеся рекламой, из работы убираем и в отчёте это показываем. Реестр остаётся у вас и после окончания работ.
Перед стартом фиксируем базовый замер: небрендовый трафик из поиска по каждой посадочной группе, число обращений с органики, видимость по семантическому ядру, скорость, коды ответов, число страниц в индексе. Без этого замера любой последующий разговор о результате превращается в спор о том, что было раньше, а через полгода восстановить исходную картину уже нельзя.
Настраиваем учёт обращений от начала до конца: цели в Метрике на реальные события, а не на клики по произвольному месту страницы, коллтрекинг там, где звонки — основной канал, передачу заявок в CRM с меткой источника. Если у вас Битрикс24, связываем формы и сделки, чтобы в отчёте была не только заявка, но и деньги по ней. Это меняет содержание разговора: обсуждать становится не трафик вообще, а стоимость обращения по каждой группе страниц.
Отчёт раз в месяц: что сделали, что это дало, что мешает, что делаем дальше. В отчёте есть перечень выполненных задач со ссылками на страницы, динамика по группам запросов и по трафику, разбор просадок с версией причины и планом проверки. Раз в квартал — пересмотр плана: часть гипотез не срабатывает, это нормальная часть работы, важно вовремя переложить бюджет в то, что даёт результат.
Кроме ежемесячного отчёта держим постоянный технический контроль. Раз в сутки автоматически проверяются коды ответа по списку ключевых адресов, наличие и содержимое заголовков, доступность карты сайта, число страниц в индексе и время ответа сервера. При отклонении приходит уведомление, и мы разбираемся в тот же день. Большинство серьёзных потерь трафика начинаются с мелочи — выкатили релиз, и часть раздела стала отвечать ошибкой, — а стоят они дорого именно потому, что месяц никто не смотрел.
Отдельная часть работы — передача практик вашей команде. Мы пишем короткий регламент для контент-менеджеров: как заводить товар, чтобы он не выпал из индекса, что делать с закончившимися позициями, как менять адреса разделов без потерь, какие поля обязательны к заполнению и почему. Для разработчиков — свод правил по адресам, кодам ответа и кэшу, который проверяется перед выкладкой. На больших проектах эти два документа спасают больше трафика, чем половина технических правок: типовая история потери органики — не сложная ошибка, а обычный релиз, в котором никто не проверил коды ответа.
Один разобранный проект целиком, без округлений в свою пользу. Магазин ИРС продаёт оборудование для гидроизоляции, сайт на 1С-Битрикс. Полная версия — на странице кейса магазина ИРС.
Оговорка, без которой цифры читаются неправильно: рост с нулевой базы всегда выглядит внушительнее, чем рост зрелого сайта. У проекта, который уже получает трафик, проценты будут скромнее, а работа — тяжелее. Мы показываем этот кейс не как обещание таких же процентов, а как пример того, из чего складывается результат.
Шесть вопросов о вашем сайте. По ответам прикинем, сколько типовых поломок платформы у вас вероятно есть и насколько велик риск терять поисковый трафик. Это грубая оценка по косвенным признакам, а не диагноз: точную картину даёт только разбор живого сайта. Ничего не отправляем и ничего не просим — считается прямо в браузере.
Партнёрства, сертификаты и аккредитации, подтверждающие экспертизу.
Руководитель разработки, руководитель маркетинга, менеджер проекта, SEO-оптимизатор, технический лидер, тимлид и UX/UI — на вашем проекте по тарифу, с сертификатами и репутацией.
Мы не продаём места в выдаче и не берём оплату за позиции. Позиции зависят от алгоритмов, конкурентов и сезона, и продавать то, чем не управляешь, нечестно. Продаём работы и результат, который можно измерить: обход сайта роботом, небрендовый трафик из поиска, число обращений с органики. Ниже три модели сотрудничества. Они не заменяют друг друга и часто идут последовательно: аудит показывает объём, проектная расчистка снимает технический долг, абонемент дальше наращивает трафик. Какая нужна вам, обычно понятно после первой оценки, и мы скажем об этом прямо, даже если это самая дешёвая из трёх.
Разовая работа с фиксированной ценой и сроком. Подходит, если у вас есть своя команда разработки и нужен внешний разбор с конкретными задачами, либо если вы выбираете подрядчика и хотите сперва понять реальный масштаб проблем и бюджета.
Сайт до 1 000 страниц. Полный краул, проверка кодов ответа, дубли адресов и метатегов, файл robots и карта сайта, базовая проверка скорости и композитного кэша, разбор настроек ЧПУ, проверка индексации по разделам. На выходе — таблица задач с приоритетами и часовой оценкой, плюс часовой созвон с разбором и ответами на вопросы. Подойдёт корпоративному сайту, сайту услуг или небольшому каталогу.
Сайт до 30 000 страниц. Всё из экспресса плюс анализ серверных логов за 30 дней с картиной реального обхода, разбор хранения свойств инфоблоков и медленных запросов к базе, аудит умного фильтра с расчётом посадочных комбинаций по частотности, проверка микроразметки и коммерческих факторов, разбор обмена с 1С и фидов, сравнение с тремя конкурентами из живой выдачи по вашим ключевым запросам. Задачи отдаём в виде, пригодном для постановки разработчику в спринт, с критериями приёмки по каждой.
Крупный интернет-магазин, мультирегиональность, несколько сайтов на одном ядре, тяжёлые интеграции. Дополнительно: сбор и кластеризация семантического ядра, проектирование структуры каталога и посадочных страниц фильтра, разбор региональной схемы, план работ на 6–9 месяцев с распределением бюджета по месяцам и ожидаемым вкладом каждого блока.
Что вы получаете в любом варианте: таблицу задач с приоритетом, оценкой в часах и критерием приёмки; перечень страниц, требующих правки, с адресами; замер текущего состояния, к которому можно вернуться через полгода. Чего не получаете: презентацию с общими рекомендациями вида «улучшить юзабилити». Стоимость аудита засчитывается в первый месяц, если вы продолжаете с нами работать по модели 2 или 3.
Ежемесячная работа командой: SEO-специалист, технический специалист по Битриксу, редактор, аналитик. Минимальный горизонт — 6 месяцев, потому что раньше по большинству коммерческих ниш нельзя отличить эффект работ от сезонных колебаний спроса. Мы не берём проекты на три месяца «попробовать»: это заведомо деньги в никуда, и обеим сторонам будет неловко.
До 300 страниц в работе, до 40 часов команды в месяц. Технические правки, семантика и структура, посадочные страницы, тексты, разметка, внешние сигналы, ежемесячная отчётность.
Каталог, посадочные страницы умного фильтра, работа с наличием и торговыми предложениями, фиды и обмен с учётной системой, коммерческие факторы, до 80 часов команды в месяц.
Каталоги свыше 50 000 позиций, несколько регионов или несколько сайтов на общем ядре, выделенный технический специалист и собственный спринт разработки, отдельный аналитик.
Что фиксируем в договоре: перечень работ на месяц, состав команды и часы, целевые значения по небрендовому трафику и обращениям с органики с точками контроля, порядок передачи задач вашей разработке и порядок приёмки, состав ежемесячной отчётности. Чего в договоре не будет: обещания позиций, «гарантии ТОП-10» и штрафов за место в выдаче. Если подрядчик такое подписывает, посмотрите внимательно, по каким именно запросам идёт гарантия: обычно это низкочастотные формулировки, по которым сайт и так первый, или запросы с названием бренда.
Отдельно про часы. Мы показываем в отчёте, сколько времени ушло на какие задачи, потому что абонемент — это оплата работы команды, и вы вправе видеть, куда она делась. Неизрасходованные часы не сгорают в пределах квартала и переносятся на следующий месяц.
Фиксированный объём работ с фиксированной ценой и сроком. Подходит, когда сайт технически запущен, но маркетинг вы ведёте сами и абонемент не нужен; либо когда до начала продвижения надо разово снять накопленный долг платформы, чтобы дальше работать спокойно.
Состав определяется по результатам аудита. Типовое наполнение: приведение адресов к канонической форме и карта редиректов, разбор умного фильтра с выделением посадочных, починка кодов ответа, переработка пагинации, композитный кэш и его инвалидация, перенос свойств каталога в отдельное хранилище, фоновые задания на расписание, карта сайта и robots, закрытие служебных разделов и технических копий, микроразметка, скорость до целевых значений. Каждая задача принимается по проверяемому критерию, полный список — приложение к договору.
Отдельный проект, если основная проблема одна: сайт медленный. Разбор дорогих запросов к базе, кэширование, статика и изображения, конфигурация окружения, вынос заданий из хитов, замеры до и после по одной методике.
Если чинить дороже, чем переделать. На части проектов накопленный долг таков, что расчистка сопоставима по стоимости с новым сайтом, а результат всё равно будет ограничен архитектурой. Мы говорим об этом прямо по итогам аудита и показываем расчёт обоих вариантов. Разработка корпоративного сайта у нас — от 150 000 ₽, с переносом всей поисковой истории и картой редиректов, чтобы переезд не обнулил трафик. Решение остаётся за вами, наша задача — чтобы оно принималось с цифрами на руках.
Если вы не знаете текущего состояния сайта и не понимаете, почему трафик стоит на месте, начинать надо с аудита. Он стоит дешевле одного месяца абонемента и снимает главный риск — платить полгода за работы, которые не решают вашу проблему. По итогам аудита часть клиентов уходит делать работы своими руками, и это нормальный исход.
Если состояние сайта известно, задачи понятны, а маркетинг вы ведёте сами и справляетесь — берите проектную расчистку. Это фиксированная сумма за фиксированный объём, после которой сайт перестаёт мешать сам себе. Дальше можно ничего не покупать: технический долг снят, а семантику и тексты ваша команда добавит по подготовленному плану.
Абонемент нужен, когда органика — значимый канал продаж и работа должна идти постоянно: каталог меняется, конкуренты не стоят, спрос сезонный, новые посадочные надо выпускать каждый месяц. Это не «поддержка результата», а именно непрерывная работа — на живом магазине объём задач не заканчивается никогда, он только меняет характер: первые месяцы техника, дальше структура, контент и коммерческие факторы.
Договор с приложением, в котором перечислены работы и порядок приёмки. Оплата помесячная по факту закрытого месяца или по этапам для проектных работ, предоплата за весь срок не требуется. Расторжение — с уведомлением за 30 дней, без штрафов и без удержания за «недоработанный срок договора». Все материалы, доступы, реестры и наработки остаются у вас: карта посадочных, семантическое ядро, реестр размещений, регламенты, список задач. Мы не держим клиента тем, что при уходе он теряет данные, — держать имеет смысл только результатом.
Как начать. Первый шаг — короткая оценка по адресу сайта, без доступов. Мы прогоняем краул, смотрим текущую видимость и характер обхода и говорим, какой из трёх вариантов имеет смысл и какого порядка бюджет обсуждается. Занимает 1–2 рабочих дня и ничего не стоит. Дальше — либо аудит, либо сразу договор, если объём и так понятен. Никаких предварительных встреч на полтора часа с презентацией агентства для этого не нужно.
Не знаете, какой вариант нужен? Бесплатно определим формат после первичной проверки — посмотрим сайт и скажем, что из этого списка вам действительно нужно, а что можно не брать.
Шестнадцать вопросов, которые нам задают чаще всего — с прямыми ответами, включая неудобные.
Нет, и никто не может. Ранжирование определяют алгоритмы Яндекса и Google, действия конкурентов и сезонность спроса — на всё это подрядчик не влияет. Влиять можно на состояние сайта: скорость ответа, полноту индексации, структуру, соответствие страниц реальному спросу, коммерческие факторы. Алгоритмы меняются несколько раз в год, и после крупного обновления перестановки в выдаче случаются даже у тех, кто ничего не трогал. Агентство, которое подписывает гарантию позиций, обычно берёт в список запросы, по которым сайт уже виден, или добавляет в договор оговорки, обесценивающие обязательство: гарантия действует «при условии выполнения всех рекомендаций», а рекомендации бесконечны.
Что мы фиксируем письменно: объём работ на период, состав команды и часы, целевые значения по небрендовому трафику из поиска и по числу обращений с органики, методику замера и точки контроля. Базовый замер снимается до старта — иначе через полгода нельзя будет разобрать, что изменилось. Если целевые значения не достигнуты, мы разбираем причину и корректируем план, а не ищем формулировку, под которую всё сошлось. Это менее эффектное обещание, чем «ТОП-10 за три месяца», зато его можно проверить.
Нет. Платформа даёт всё необходимое: управление метатегами через SEO-свойства инфоблоков, ЧПУ, шаблоны заголовков для разделов и элементов, генерацию карты сайта, человекопонятные адреса умного фильтра, гибкое кэширование, инструменты контроля производительности. Проблема не в самой системе, а в том, что она очень терпима к неаккуратной сборке и почти ничего не запрещает разработчику. Ошибка, которая на другой CMS проявится сразу и громко, здесь тихо копится год и вылезает уже в виде двухсот тысяч мусорных адресов или базы, отвечающей три секунды.
Практическое следствие: на Битриксе больше работы на техническом этапе, но и потолок выше, особенно на больших каталогах. Посадочные страницы умного фильтра — самый дешёвый способ занять низкочастотный спрос: они создаются настройкой, а не разработкой, и на серьёзном каталоге таких страниц вводят сотнями. На хорошо собранном Битриксе они дают заметную долю трафика уже к четвёртому-пятому месяцу. Менять платформу ради поиска почти никогда не нужно — нужно её починить.
Можно, и на многих проектах так дешевле. Мы отдаём задачи в виде, пригодном для спринта: описание проблемы, где именно в Битриксе она лежит, что должно получиться в результате и как это проверить. По каждой задаче есть критерий приёмки, который может прогнать любой человек, а не только автор. При такой схеме из сметы уходит блок часов на реализацию, остаётся постановка, консультации и приёмка.
Дальше мы принимаем работу: сверяем коды ответов, содержимое HTML без выполнения скриптов, поведение кэша, отсутствие регрессий на соседних шаблонах. Практика показывает, что примерно каждая пятая задача возвращается на доработку с первого раза — обычно потому, что правка сделана в одном шаблоне, а компонент используется в трёх местах, или потому что изменение не пережило сброс кэша. Это нормальный рабочий цикл. Важно, чтобы приёмка вообще была: без неё технический этап превращается в список закрытых тикетов, за которым ничего не стоит.
Композит разрезает страницу на две части: статическую, которая отдаётся из кэша почти мгновенно, и динамическую, которую дорисовывает скрипт уже в браузере. Идея хорошая, но если в динамическую часть по невнимательности попал основной текст, цена, хлебные крошки или блок характеристик, робот получит страницу без них. Человек в браузере при этом видит нормальную страницу и проблему не замечает — она обнаруживается только при сравнении того, что приходит в исходном HTML, с тем, что отображается.
Вторая беда — устаревший кэш. Композит мог сохранить страницу в момент сбоя и месяцами отдавать этот снимок; правки метатегов могут не доезжать до выдачи, потому что не настроен сброс по изменению элемента инфоблока. Иногда в кэш попадает персональная информация из личного кабинета и раздаётся всем подряд. Мы сверяем каждый тип страницы дважды — как видит браузер и как видит запрос без выполнения скриптов, — переносим значимое содержимое в статическую часть и настраиваем инвалидацию так, чтобы изменение товара гасило кэш всех страниц, где он выводится.
И то и другое, зависит от настройки. По умолчанию фильтр открывает под индексацию все возможные сочетания свойств, а это десятки и сотни тысяч адресов, большая часть которых содержит два товара и не имеет спроса. Робот тратит на них бюджет обхода и не доходит до страниц, которые действительно нужны. На каталогах, которые приходят к нам на аудит, доля полезных обходов часто составляет 20–40 %: остальное — блуждание по комбинациям фильтра и служебным адресам.
Полезная часть — комбинации с реальной частотностью и достаточным числом товаров. Мы отбираем их по данным Wordstat и по наполнению каталога, даём им человекопонятные адреса, уникальные шаблоны заголовков и описаний, включаем в карту сайта и ведём как обычные посадочные страницы. Остальное закрываем метатегом robots в шаблоне компонента — именно метатегом, потому что запрет в robots.txt не убирает адрес из выдачи, а лишь мешает роботу увидеть содержимое. После расчистки число обходимых адресов обычно падает в 20–50 раз, а трафик растёт: робот наконец добирается до нужного.
Аудит — 40 000 ₽ для сайта до 1 000 страниц, 120 000 ₽ для сайта до 30 000 страниц, от 180 000 ₽ для крупного магазина, мультирегиональности или нескольких сайтов на одном ядре. Абонентское продвижение — от 40 000 ₽ в месяц для корпоративного сайта и сайта услуг, от 50 000 ₽ для интернет-магазина, от 70 000 ₽ для крупного проекта с выделенным техническим специалистом. Разовая техническая расчистка — от 250 000 ₽ за проект длительностью 6–10 недель, отдельный проект по ускорению — от 150 000 ₽.
Цена определяется объёмом работ, а не «уровнем пакета»: размером и структурой каталога, состоянием сборки, конкурентностью ниши, числом регионов, наличием вашей разработки и состоянием аналитики. Если задачи выполняет ваша команда, блок часов на реализацию из сметы уходит. Стоимость аудита засчитывается в первый месяц работы, если вы продолжаете с нами. Мы не делаем скидку за длинный договор и не поднимаем цену задним числом: смета считается по часам и составу работ, и её видно в отчёте.
Порядком работ. Пока платформа отдаёт дубли, тормозит и держит в индексе служебные разделы, тексты и ссылки уходят в страницы, до которых робот не добирается или которые скоро сменят адрес. Поэтому первые два-три месяца — это технические работы на стороне Битрикса, и только потом контент и внешние сигналы. Такой порядок менее приятен на старте: в первый месяц показать в отчёте красивый график роста нечем, зато к четвёртому есть что показывать.
Второе отличие — проверяемость. У каждой задачи есть критерий приёмки, каждый месяц закрывается отчётом со списком сделанного и ссылками на конкретные страницы, каждая просадка разбирается с версией причины и планом проверки. Мы не подставляем в отчёт «видимость» по собственному ядру вместо трафика, не считаем брендовые запросы результатом продвижения и не показываем рост посещаемости, полученный за счёт рекламной кампании, запущенной в том же месяце. Всё, что мы показываем, вы можете проверить в своих счётчиках сами.
На проекте всегда есть ответственный специалист, который ведёт его от начала до конца, и технический специалист по Битриксу, который делает или принимает правки в коде. На магазинах к ним добавляются редактор и аналитик. Состав и часы каждого прописаны в договоре, а в ежемесячном отчёте видно, сколько времени ушло на какие задачи. Мы не практикуем схему, при которой договор подписывает один человек, а работу потом ведёт стажёр, которого вы никогда не видели.
Общение — рабочий чат для оперативных вопросов и созвон раз в месяц по итогам, при необходимости чаще. Между созвонами вы в любой момент можете посмотреть текущий статус задач: мы ведём их в общей доске, а не пересылаем таблицы почтой. На технических этапах добавляется контакт напрямую между нашим специалистом и вашими разработчиками, потому что переписка через двух менеджеров удлиняет любую правку втрое и порождает половину недоразумений.
Первые изменения в обходе сайта роботом видны через 2–4 недели после технических правок: растёт число страниц в индексе, падает доля обращений робота к мусорным адресам, сокращается время до первого байта. Это ранний, но честный индикатор — он показывает, что платформа перестала мешать. Рост трафика по низкочастотным и товарным запросам обычно начинается с третьего месяца, по средним частотникам — с четвёртого-шестого. Раньше этого срока любые колебания трафика скорее сезонные, чем наши, и мы стараемся не выдавать одно за другое в отчётах.
Сроки сильно зависят от возраста домена и стартового состояния. Сайт, которому пять лет и который просто технически запущен, отзывается быстрее нового: у него есть история, накопленные ссылки и узнаваемость. Новый домен в конкурентной нише в Москве выходит на осмысленный объём органики не раньше 8–12 месяцев, и мы говорим об этом до подписания договора, а не в отчёте за третий месяц. Если такой срок для бизнеса неприемлем, честнее начинать с платных каналов, а органику вести параллельно как более дешёвый источник на перспективу.
Для первичной оценки не нужен: хватает адреса сайта. Мы прогоняем краул, смотрим индексацию, скорость и видимость по вашей нише, оцениваем характер проблем по внешним признакам и говорим, есть ли смысл идти дальше и какого порядка бюджет обсуждается. Занимает 1–2 рабочих дня, ничего не стоит и ни к чему не обязывает.
Для аудита нужен доступ на чтение к админке, к серверным логам или панели статистики хостинга и к счётчикам аналитики. Для работ — доступ к репозиторию и тестовому контуру; если работы выполняет ваша команда, достаточно площадки для передачи задач. Правкой боевых файлов через админку мы не занимаемся принципиально: все изменения идут через ветку, тестовый контур и понятный откат. Доступы оформляются отдельными учётными записями на наших специалистов, а не общим паролем, и отзываются по окончании работ.
Не снимать с публикации. В Битриксе снятие с публикации мгновенно превращает карточку в 404, и если товаров сотни, каталог теряет весь низкочастотный трафик, который на них держался. Просадка проявляется через 3–6 недель, когда робот успевает переобойти каталог, и её почти никогда не связывают с закупкой — ищут причину в алгоритмах, конкурентах, погоде. Между тем на среднем магазине это самая частая причина потери органики вообще.
Правильная схема: товар, который вернётся, остаётся опубликованным, отдаёт код 200, показывает честный статус наличия и ожидаемый срок, скрывает кнопку покупки и предлагает аналоги из своего раздела. Товар, снятый навсегда, получает постоянный редирект на ближайший аналог или на свой раздел — не на главную, такие редиректы поисковые системы трактуют как мягкую ошибку. Товар, которого не было в индексе и по которому нет спроса, можно удалять без сожалений. Правило мы зашиваем в обработчик события, чтобы оно не зависело от дисциплины контент-менеджера и не ломалось при очередном обмене с учётной системой.
Да, это самостоятельная услуга, и её покупают чаще, чем кажется. На выходе вы получаете таблицу задач с приоритетом, оценкой в часах и критерием приёмки по каждой, перечень проблемных страниц с адресами и замер текущего состояния. Этого достаточно, чтобы поставить работу своей команде, другому подрядчику или разложить по спринтам на полгода вперёд. Задачи написаны так, чтобы их понял разработчик, а не только маркетолог.
Мы не используем аудит как инструмент продажи абонемента. Если по итогам разбора выяснится, что сайт технически в порядке, а проблема в ассортименте, ценах или в том, что спрос в нише в принципе небольшой, мы так и напишем. Если выяснится, что переписать дешевле, чем чинить, покажем расчёт обоих вариантов. Продавать работы, которые не окупятся, невыгодно в первую очередь нам: такие проекты уходят через полгода, а рассказывают о них дольше, чем об удачных.
Чаще всего дело в хранении свойств инфоблоков и в выборках, сделанных внутри цикла. Битрикс по умолчанию хранит значения свойств построчно в отдельной таблице: каталог на 30 000 товаров с 20 свойствами — это 600 000 строк, по которым идёт объединение при каждой выдаче списка. Добавьте выборку без ограничения полей, вызванную по одному разу на товар, — и время генерации уходит за три секунды. Более мощный сервер эту проблему не решает, он только делает её дороже.
Для поиска скорость важна не из-за баллов в синтетическом тесте, а из-за бюджета обхода: чем дольше отвечает сервер, тем меньше страниц робот заберёт за сутки. На каталоге в несколько десятков тысяч позиций разница между 400 мс и 2,5 с — это разница между полной переиндексацией за неделю и за квартал. Плюс скорость влияет на поведение живых людей, а через него на оценку качества страницы. Мы переносим свойства в отдельное хранилище, ограничиваем выборки, чиним кэширование, разбираем дорогие запросы по логу базы и подтверждаем результат замерами до и после по одной методике.
Ключевая работа делается до переезда, а не после. Нужно собрать полный список текущих адресов из карты сайта, серверных логов за несколько месяцев, панелей вебмастера и базы старого сайта, сопоставить каждый адрес со страницей на новом и составить карту постоянных редиректов. Отдельное внимание карточкам товаров: при перегенерации символьных кодов в Битриксе часть адресов меняется незаметно, и потерю обнаруживают спустя месяц по провалу низкочастотного трафика. Заодно переносятся метатеги, тексты разделов и настройки индексации — их регулярно забывают и запускают новый сайт с шаблонными заголовками.
Перед выкладкой снимаем базовый замер трафика, позиций и числа страниц в индексе, после выкладки прогоняем весь список старых адресов и проверяем коды ответов, а потом повторяем проверку через неделю и через месяц. Нормальная просадка при аккуратном переезде — до 10–15 % на две-четыре недели с последующим возвратом и ростом. Просадка на 50 % с обещанием «само восстановится» — это не особенность переезда, а незакрытые редиректы, потерянные страницы и сменившаяся структура, и чем позже это чинить, тем дороже.
Сначала разбираемся, чего именно нет. Бывает, что трафик растёт, а заявок нет — тогда проблема в конверсии, ценах или в самом предложении, и наращивать трафик дальше бессмысленно, надо чинить страницу и оффер. Бывает, что растёт индексация, но не трафик — значит, ошиблись с семантикой и страницы не отвечают реальному спросу. Бывает, что и то и другое растёт, но заявки не превращаются в сделки, и тогда разговор уходит в отдел продаж. Общий ответ «работаем дальше» тут не годится, каждый случай выглядит по-разному и требует отдельной проверки.
По каждому месяцу без движения мы обязаны предъявить версию причины и предложение, что менять, а не набор графиков. Если через три-четыре месяца план не даёт результата и мы не видим, чем это исправить, честнее сказать об этом и разойтись, чем тянуть договор до конца срока. Такие случаи бывают — чаще всего в нишах, где органика в принципе не основной канал или где спроса меньше, чем казалось на старте. Понять это стоило раньше, и в этом наша доля ответственности тоже есть.
Всё, что мы сделали, остаётся у вас и продолжает работать: правки в коде, настройки, посадочные страницы, тексты. Мы передаём семантическое ядро, карту посадочных, реестр внешних размещений, список выполненных и незакрытых задач и регламенты для контент-менеджеров и разработчиков. Доступы к нашим учётным записям отзываются, к вашим сервисам — тоже.
Трафик после окончания работ не обнуляется, но и не растёт сам по себе: технические правки держатся долго, а вот структура и контент требуют продолжения, особенно на живом каталоге, где ассортимент меняется каждый месяц. Наиболее частый сценарий — клиент забирает работу внутрь и продолжает по подготовленному плану своими силами, а нас зовёт точечно на технические задачи. Такой формат нам подходит: это честнее, чем удерживать абонемент ради абонемента.
Общие условия и тарифы — на странице SEO-продвижения с гарантией результата в договоре.
Для первичной оценки доступы не нужны — достаточно адреса сайта. Прогоним краул, посмотрим видимость и характер обхода и скажем, что именно в сборке мешает расти, какой из трёх форматов работы имеет смысл и какого порядка бюджет обсуждается.
Без доступа к админке. Бесплатно. Ответ за 1–2 рабочих дня.