Как разработка и SEO влияют на позиции сайта и как их согласовать
Разработчики говорят: «Команда поисковой оптимизации (SEO) ломает архитектуру». Специалисты по поисковой оптимизации (SEO-специалисты) отвечают: «Разработчики сносят позиции каждой выкаткой». В проигрыше — всегда сайт. Разбираем семь реальных сценариев конфликта.
Агентство полного цикла КручуВерчу сталкивается с такими ситуациями при каждом аудите — и всегда причина одна: договорились поздно.
1. Тестовый сервер попал в индекс
Разработчик открыл тестовый сервер для демонстрации. Специалист по поисковой оптимизации не проверил. Поисковик нашёл дубль основного сайта и выбрал его как приоритетный.
Кто виноват: оба.
Решение:
- тестовый сервер — за паролем или с директивой запрета сканирования в файле управления роботами
- публичный тестовый сервер — метатег запрета индексации в каждом шаблоне
- проверка доступности тестового домена входит в список перед выкаткой
2. Редизайн съел ссылочный вес
Адреса страниц поменялись. Постоянной переадресации нет. Все внешние ссылки вернули ошибку 404 — и накопленный вес испарился.
Кто виноват: разработчик не настроил переадресацию, специалист по поисковой оптимизации не подготовил карту адресов.
Решение: таблица «старый адрес → новый адрес» составляется до старта редизайна. В неё включают продвигаемые страницы, страницы с внешними ссылками и страницы с органической посещаемостью за 12 месяцев. Переадресация реализуется на уровне сервера, а не через метаобновление.
3. Скрипты не видит робот
Содержимое страницы формируется на стороне браузера — поисковый робот получает пустую страницу. Google официально подтверждает: такие страницы встают в очередь обработки и сканируются с задержкой. У Яндекса с этим ещё хуже.
Как проверить: отключить скрипты в браузере через инструменты разработчика. Пустая страница — содержимое роботу недоступно.
Решение по приоритету: серверный рендеринг (отрисовка на стороне сервера) → статическая генерация для редко меняющихся страниц → динамический рендеринг (отрисовка по типу запроса) как временная мера.
4. Бюджет сканирования уходит в фильтры
Интернет-магазин с 50 000 товарами и десятью параметрами фильтрации порождает миллионы бессмысленных адресов. Поисковый робот тратит лимит обхода на мусор и не доходит до важных страниц.
Кто виноват: разработчик реализовал фильтры через параметры адреса, специалист по поисковой оптимизации не прописал правила в техническом задании.
Решение: закрыть мусорные параметры в файле управления роботами. Для Яндекса — настроить «Оптимизацию обхода» в Вебмастере. Страницам с параметрами указать канонический адрес базовой версии.
5. После выкатки просела скорость
Google учитывает показатели качества загрузки (Core Web Vitals) при ранжировании: скорость отрисовки крупного элемента (LCP), задержку взаимодействия (INP) и смещение макета (CLS). Деградация на пару секунд — и позиции поползут вниз через несколько недель.
Кто виноват: разработчик добавил тяжёлые скрипты без анализа влияния, специалист по поисковой оптимизации не зафиксировал показатели до обновления.
Решение: замер скорости через инструмент проверки страниц PageSpeed Insights на тестовом стенде до выкатки. Базовые значения LCP, INP и CLS фиксируются перед каждым крупным обновлением.
6. Дубли метатегов на тысячах страниц
Шаблон генерирует одинаковый заголовок и описание для тысяч однотипных страниц. Поисковик не понимает, какую страницу показывать по конкретному запросу.
Кто виноват: разработчик реализовал шаблон без правил, специалист по поисковой оптимизации не заложил требования в техническое задание. В КручуВерчу разработка каждого проекта начинается с технического задания на метатеги — именно потому, что без него шаблон неизбежно плодит дубли.
Решение: шаблоны с уникальными переменными — до начала разработки, не после.
| Тег | Шаблон |
| Заголовок страницы | [Название] — купить в [Город] |
| Описание | [Название] от [Цена] руб. Доставка по [Город] |
7. Канонический адрес — одинаковый на всех страницах
Статическое значение в шаблоне даёт всем страницам один и тот же канонический адрес — например, главную. Поисковик считает весь сайт дублём одной страницы.
Как проверить: открыть исходный код любой внутренней страницы, найти тег канонического адреса — он должен совпадать с адресом текущей страницы.
Решение: тег канонического адреса генерируется динамически. Страницы с параметрами сортировки и постраничной навигации ссылаются на базовую версию без параметров.
Короткий список мира: повесить в обоих отделах
- Тестовый сервер закрыт паролем или запретом индексации
- Все старые адреса имеют постоянную переадресацию на новые
- Содержимое страницы видно при отключённых скриптах
- Бюджет сканирования не уходит на адреса фильтров и сортировок
- Скорость загрузки замерена до и после каждого обновления
- Метатеги генерируются по шаблонам с уникальными переменными
- Тег канонического адреса на каждой странице указывает на адрес именно этой страницы
Скопируйте. Внесите в регламент выкатки. Мир возможен.
