Вы наполняете сайт статьями, закупаете ссылки, дорабатываете тексты, а позиции стоят на месте. Частая причина - не контент и не ссылки, а техническая база. Робот Google не может нормально просканировать сайт, натыкается на дубли, ждёт по пять секунд загрузки страницы и в итоге отдаёт трафик конкурентам.
Техника не приносит трафик сама по себе, но снимает потолок. Пока страницы не индексируются, грузятся медленно и ломаются на смартфонах, любые вложения в продвижение работают вполсилы. Ниже - конкретные ошибки, которые чаще всего тормозят рост, с инструментами для диагностики и понятными шагами по исправлению.
Материал построен по принципу практика: где смотреть, что именно искать, чем это грозит и как чинить. Без общих фраз.
Индексация: страницы, которых нет в поиске
Если страницы нет в индексе, она не приносит ни одного визита из поиска - независимо от качества текста. Поэтому диагностику всегда начинают отсюда.
Базовая проверка - оператор site: в поиске Google. Введите site:вашдомен.kz и сравните число найденных страниц с реальным количеством. Разница в разы - тревожный сигнал. Точную картину даёт Google Search Console, отчёт «Индексирование страниц»: там видно, сколько URL в индексе, сколько исключено и по какой причине.
Случайный запрет индексации
Классика - сайт переносили с тестового домена и забыли снять запрет. Проверьте две вещи.
- Мета-тег в коде страницы: <meta name="robots" content="noindex">. Если он висит на продающих страницах - это прямой запрет показывать их в поиске.
- Заголовок ответа сервера X-Robots-Tag: noindex. Его не видно в HTML, но он делает то же самое. Смотрите во вкладке Network браузера или через проверку URL в Search Console.
Ещё одна ловушка - закрытый в robots.txt раздел, который должен продвигаться. Robots.txt запрещает сканирование, но не гарантирует исключение из индекса, поэтому страница может попасть в поиск без описания, с пометкой о недоступности. Для запрета индексации используйте noindex, а не robots.txt.
Раздутый индекс и краулинговый бюджет
Обратная проблема - в индекс попадают тысячи мусорных URL: страницы фильтров, сортировок, результаты внутреннего поиска, теги. Робот тратит краулинговый бюджет на них вместо важных страниц. На крупных каталогах из-за этого новые товары индексируются неделями.
Правило простое: в индексе должны быть только те страницы, которые вы готовы показать пользователю из поиска. Всё остальное закрывайте от индексации осознанно.
Найти мусор помогает отчёт по индексированию в Search Console и краулеры вроде Screaming Frog или Netpeak Spider - они показывают полную карту URL, включая параметрические.
Дубли контента: сайт конкурирует сам с собой
Дубли - одна из самых недооценённых проблем. Когда один и тот же контент доступен по нескольким адресам, поисковик не понимает, какую версию ранжировать, и распыляет вес между копиями. В результате ни одна страница не выходит в топ.
Технические дубли главной и внутренних страниц
Проверьте, открывается ли сайт одновременно по разным адресам:
- с www и без www;
- по http и https;
- со слешом в конце URL и без него;
- главная по адресам /index.php, /home и просто /.
Каждая пара - это два одинаковых документа для робота. Решение: выбрать одну каноническую версию и настроить 301-редирект со всех остальных на неё. Дополнительно пропишите на страницах тег <link rel="canonical"> с указанием основного адреса.
Дубли из-за параметров и пагинации
UTM-метки, параметры фильтров и сессий плодят копии одной страницы. Адрес /catalog/?sort=price&utm_source=vk для робота отличается от /catalog/, хотя контент тот же. Здесь спасает canonical, который ведёт на чистый URL без параметров.
Найти дубли по контенту можно тем же Screaming Frog: он группирует страницы с одинаковыми Title и почти идентичным текстом. Совпадающие Title и H1 на десятках URL - почти всегда признак дублирования. Глубокую проверку архитектуры и приоритезацию правок удобно вынести в технический аудит сайта, чтобы получить готовый список задач с приоритетами.
Скорость загрузки и Core Web Vitals
Скорость - фактор ранжирования и одновременно фактор конверсии. Пользователь уходит, не дождавшись загрузки, а Google фиксирует высокий процент отказов. Google оценивает три метрики Core Web Vitals.
- LCP (загрузка основного контента) - должна укладываться в 2,5 секунды.
- INP (отзывчивость на действия) - до 200 миллисекунд.
- CLS (визуальная стабильность) - до 0,1, чтобы элементы не прыгали при загрузке.
Замеряйте через PageSpeed Insights и отчёт Core Web Vitals в Search Console - последний показывает данные реальных пользователей, а не лабораторный тест. Смотрите отдельно мобильную версию: именно она в приоритете у Google.
Что чаще всего тормозит
Типовые тяжёлые места и способы их разгрузить:
- Неоптимизированные изображения. Картинки по несколько мегабайт - главный балласт. Сжимайте, отдавайте в форматах WebP или AVIF, задавайте размеры через атрибуты width и height, включайте ленивую загрузку lazy loading для картинок ниже первого экрана.
- Тяжёлые скрипты. Лишние библиотеки, чаты, счётчики и виджеты блокируют отрисовку. Уберите неиспользуемое, подключайте сторонние скрипты с атрибутами defer или async.
- Отсутствие кеширования и сжатия. Включите сжатие Gzip или Brotli на сервере и кеширование статики в заголовках. Это снижает вес ответа в разы.
- Медленный хостинг. Если время ответа сервера (TTFB) выше 600 миллисекунд, оптимизация фронтенда мало поможет - нужен сервер побыстрее или CDN.
Мобильная версия: приоритет Google
Google индексирует сайты по мобильной версии. Если на смартфоне часть контента скрыта, кнопки налезают друг на друга, а текст приходится увеличивать пальцами - робот видит именно это, и позиции падают в обеих выдачах.
Проверьте сайт в режиме эмуляции устройства в браузере (клавиша F12, режим адаптива) и на реальном смартфоне. На что смотреть:
- весь ли контент десктопа доступен на мобильной версии - Google ранжирует по тому, что видит на мобиле;
- не мелкий ли шрифт и достаточно ли крупные кликабельные элементы;
- нет ли горизонтальной прокрутки и вылезающих за экран блоков;
- не перекрывают ли всплывающие окна основной контент сразу при заходе.
Отдельно проверьте, что мобильная и десктопная версии отдают одинаковый контент и одинаковую микроразметку. Урезанная мобильная версия - прямая потеря ранжирующих сигналов.
Robots.txt, sitemap.xml и редиректы
Три служебных механизма, через которые робот понимает структуру сайта. Ошибка в любом из них дорого обходится.
Robots.txt
Файл лежит по адресу /robots.txt. Самая опасная ошибка - директива Disallow: /, которая закрывает от сканирования весь сайт. Такое случается после переноса с тестового сервера. Проверьте файл вручную и убедитесь, что закрыты только служебные разделы (админка, корзина, личный кабинет), а не важные страницы. В конце файла должна быть ссылка на карту сайта: Sitemap: https://вашдомен.kz/sitemap.xml.
Sitemap.xml
Карта сайта помогает роботу быстрее находить страницы. Частые ошибки: в карту попадают закрытые от индексации URL, страницы с редиректами и 404, а также адреса с параметрами. В sitemap должны быть только канонические, отдающие код 200 страницы. Отправьте карту в Search Console и следите, чтобы количество отправленных и проиндексированных URL сходилось.
Редиректы
Редиректы нужны при смене адресов, но легко превращаются в проблему.
- Цепочки редиректов. URL A ведёт на B, B на C, C на D. Каждый переход - потеря времени и части веса. Сокращайте цепочки до одного перехода: сразу с A на D.
- Временные редиректы вместо постоянных. При переезде страницы навсегда используйте 301, а не 302. Код 302 не передаёт вес на новый адрес в полной мере.
- Редиректы на нерелевантные страницы. Массовая переадресация удалённых товаров на главную сбивает робота. Ведите на близкий по смыслу раздел.
Битые ссылки и ошибки сервера
Битые ссылки бьют по двум фронтам: пользователь упирается в тупик и уходит, а робот тратит бюджет на несуществующие адреса и теряет доверие к сайту.
Массово находить их удобнее всего краулером (Screaming Frog, Netpeak Spider) - он обходит весь сайт и выдаёт список URL с их кодами ответа. Ориентиры по кодам:
- 404 - страница не найдена. Проверьте внутренние ссылки, которые на неё ведут, и либо поправьте их, либо поставьте 301 на актуальную страницу.
- 5xx - ошибка сервера. Сигнал о проблемах хостинга или кода. Если робот регулярно ловит 5xx, он снижает частоту сканирования.
- Ссылки на 301 внутри сайта. Внутренние ссылки должны вести сразу на конечный URL, без промежуточного редиректа.
Отдельно настройте информативную страницу 404 с навигацией и поиском, чтобы посетитель не оказывался в тупике, а мог вернуться в каталог или на главную.
Микроразметка Schema.org
Структурированные данные не поднимают позиции напрямую, но дают расширенные сниппеты: звёзды рейтинга, цены, хлебные крошки, ответы на вопросы. Такой сниппет заметнее в выдаче и собирает больше кликов при той же позиции.
Базовый набор разметки для коммерческого сайта:
- Organization - данные о компании, логотип, контакты;
- BreadcrumbList - хлебные крошки, которые Google показывает в сниппете вместо длинного URL;
- Product и Offer - для карточек товаров: цена, наличие, рейтинг;
- FAQPage - блок вопросов и ответов;
- Article - для статей блога.
Проверяйте разметку в валидаторе Schema.org и через тест расширенных результатов Google. Частая ошибка - размечать то, чего нет на странице для пользователя: за это можно получить ручные санкции. Размечайте только реально видимый контент. Настройку разметки и других технических факторов логично закрывать в рамках работ по техническому SEO, где всё увязано в единую систему.
Мультиязычность и hreflang
Для сайтов в Казахстане типична пара языков - русский и казахский, а иногда добавляется английский. Без правильной технической разметки поисковик путает версии: показывает русскоязычному пользователю казахскую страницу и наоборот. Отказы растут, позиции падают.
За выбор языковой версии отвечает атрибут hreflang. Он ставится в секции head каждой страницы и перечисляет все её языковые копии.
- Каждая версия должна ссылаться на саму себя и на все остальные версии - иначе связка не работает.
- Указывайте корректные коды: ru для русской версии, kk для казахской (частая ошибка - писать kz вместо kk, это код страны, а не языка).
- Добавьте версию x-default для пользователей, чей язык не подошёл ни под одну версию.
- Все URL в hreflang должны отдавать код 200 и быть каноническими, без редиректов.
Проверить связки помогает отчёт по hreflang в сторонних сервисах или ручной осмотр кода нескольких страниц. Ошибки в языковой разметке особенно дорого стоят двуязычным проектам, где половина потенциального трафика приходит на казахском.
HTTPS и смешанный контент
Защищённый протокол - минимальный гигиенический стандарт и слабый фактор ранжирования. Проблема возникает не с самим сертификатом, а со смешанным контентом: страница открывается по https, но внутри подгружает картинки, скрипты или стили по старому http.
Браузер помечает такую страницу как небезопасную, часть ресурсов может не загрузиться, а вёрстка ломается. Найти смешанный контент можно в консоли браузера (вкладка Console по клавише F12) - там выводятся предупреждения Mixed Content с конкретными адресами. Исправление: заменить все внутренние ссылки на ресурсы с http на https или на относительные пути.
Заодно проверьте, что срок действия SSL-сертификата не истёк и что он покрывает и версию с www, и без. Истёкший сертификат мгновенно отпугивает посетителей предупреждением браузера на весь экран.
Сводная таблица частых ошибок
| Ошибка | Чем грозит | Как исправить |
|---|---|---|
| Случайный noindex на важных страницах | Страницы выпадают из поиска, трафик обнуляется | Убрать мета-тег robots noindex и X-Robots-Tag, переиндексировать в Search Console |
| Дубли www/http/слеш и параметры | Вес распыляется между копиями, ни одна не в топе | 301-редирект на каноническую версию, тег canonical |
| Медленная загрузка, тяжёлые картинки и скрипты | Рост отказов, просадка позиций по Core Web Vitals | Сжатие изображений, WebP, defer скриптов, кеш и Gzip/Brotli |
| Проблемы мобильной версии | Падение позиций в мобильной и десктопной выдаче | Адаптивная вёрстка, одинаковый контент на мобиле и десктопе |
| Disallow: / в robots.txt | Робот не сканирует сайт вообще | Открыть сканирование, закрыть только служебные разделы |
| Битые ссылки и цепочки редиректов | Потеря бюджета сканирования и доверия, тупики для пользователя | Починить или закрыть 404 через 301, сократить цепочки до одного перехода |
С чего начать проверку
Если брать техническое состояние сайта под контроль с нуля, порядок действий такой.
- Подключите Google Search Console и снимите базовые отчёты: индексирование, Core Web Vitals, удобство на мобильных.
- Прогоните сайт краулером и выгрузите коды ответов, дубли Title и H1, цепочки редиректов.
- Проверьте robots.txt, sitemap.xml и canonical на ключевых шаблонах страниц.
- Замерьте скорость мобильной версии в PageSpeed Insights по важнейшим типам страниц: главная, категория, карточка, статья.
- Составьте список правок с приоритетами: сначала то, что блокирует индексацию и роняет скорость, потом остальное.
Такой подход особенно важен для больших проектов и корпоративных сайтов со сложной структурой, где мелкая техническая ошибка масштабируется на сотни страниц.
Итог
Техническая оптимизация не заменяет контент и ссылки, но без неё они не раскрываются. Пока робот спотыкается об ошибки индексации, дубли, медленную загрузку и битые ссылки, сайт растёт медленнее своих возможностей и отдаёт позиции конкурентам с более чистой базой.
Хорошая новость - большинство таких ошибок находятся стандартными инструментами за пару часов и правятся один раз. После этого каждая новая статья и каждая ссылка начинают работать в полную силу. Начните с диагностики, зафиксируйте список правок по приоритетам и последовательно закройте технический долг.
Хотите точно знать, что тормозит именно ваш сайт, и получить готовый план правок с приоритетами - оставьте заявку на технический аудит, разберём проблемы по шагам и покажем, что даст рост быстрее всего.