Технические аспекты поисковой оптимизации: от критических ошибок до краулингового бюджета.
Техническое SEO невозможно без автоматизации. Парсеры (краулеры) имитируют поведение GoogleBot и собирают все ошибки сайта.
Основной десктопный инструмент для комплексного аудита. Золотой стандарт индустрии.
Мощный аналог Screaming Frog с отличным UI. Быстро парсит большие сайты.
Облачное решение. Регулярно мониторит сайт и присылает алерты об ошибках на почту.
| Задача | Инструмент | Почему он? |
|---|---|---|
| Глубокий разовый аудит | Screaming Frog | Максимум настроек, кастомная экстракция данных, проверка JS-рендеринга. |
| Быстрый срез ошибок | Netpeak Spider | Удобная дашборд-сводка, понятные подсказки по каждой ошибке. |
| Постоянный мониторинг | Ahrefs Site Audit | Работает в облаке, не требует включенного ПК, отслеживает динамику (Health Score). |
| Проверка одного URL | SEO META in 1 CLICK | Браузерное расширение для мгновенной проверки тегов без запуска парсера. |
Коды ответа сервера (HTTP Status Codes) — первое, что видит поисковик. Если сервер отдаёт ошибку, контент не индексируется, даже если он гениален.
.htaccess.Если GoogleBot регулярно получает 500-е ошибки, он снижает частоту обхода сайта (Crawl Rate) или вовсе выкидывает страницы из индекса до решения проблемы.
Страница A → 301 → Страница B → 301 → Страница C.
Проблема: Теряется ссылочный вес с каждым шагом, увеличивается время загрузки.
Решение: Прямой редирект A → C.
Страница A → 301 → Страница B → 301 → Страница A.
Проблема: Бесконечный цикл. Браузер выдаст ошибку ERR_TOO_MANY_REDIRECTS. Страница не работает.
Решение: Найти конфликт правил в серверных настройках и устранить петлю.
Дубли страниц размывают релевантность. Google не понимает, какую из копий показывать в поиске, и может пессимизировать обе (Каннибализация).
Страницы доступны по разным URL (с www и без, с / на конце и без).
Разные товары/обзоры с одинаковым текстом-шаблоном и разными H1.
Одинаковые Title и Description на множестве страниц.
| Проблема | URL 1 | URL 2 | Решение (301 редирект) |
|---|---|---|---|
| Слэш на конце | site.com/page/ | site.com/page | Склеить всё на версию со слэшем (или без). |
| Регистр букв | site.com/Page/ | site.com/page/ | Принудительно приводить к нижнему регистру (Lowercase). |
| Индексные файлы | site.com/ | site.com/index.html | Редирект с index.html на корень /. |
| WWW / non-WWW | www.site.com | site.com | Выбрать главное зеркало, со второго — 301 редирект. |
Тестовый контент, который разработчики забыли удалить при релизе.
Если Google проиндексирует 50 страниц с Lorem Ipsum, сайт может получить санкции за Thin Content (малополезный контент).
Сквозные блоки: большое мега-меню, огромный футер, одинаковые боковые колонки.
Если на странице 300 слов уникального текста и 1500 слов сквозного меню — соотношение Content to Code работает против вас.
rel="canonical" — это HTML-тег, который указывает поисковику главную (каноническую) версию страницы, если контент дублируется по разным URL.<link rel="canonical" href="https://site.com/main-page/" />
Указывает на несуществующую страницу или ту, которая редиректит дальше. Теряется вес и краулинговый бюджет.
Два тега canonical с разными URL на одной странице. Google просто проигнорирует оба.
Страница A ссылается на B, а B ссылается на C. Нужно, чтобы A и B сразу ссылались на C.
href="/page/" вместо href="https://site.com/page/". Легко сбивает робота с толку.
Ошибка: Ставить canonical со страницы 2, 3, 4 на первую страницу. Тогда товары со 2-й страницы не проиндексируются.
Решение: Self-referencing canonical. Страница ?page=2 должна канонизировать сама себя ?page=2.
Если у сайта отдельный мобильный поддомен (устаревший подход):
canonical на десктопную.alternate на мобильную.site.com/page?utm_source=tg).Disallow: /.Sitemap: https://site.com/sitemap.xml.?p=123&cat=4my_super_post/казино/ (превратится в /%D0%BA...)/c/a/t/e/g/o/r/y/post/best-casinos/site:yoursite.com в Google (быстрая, но грубая проверка).Используем метатег <meta name="robots" content="noindex"> в секции HEAD. Не используем для этого robots.txt.
Внутренняя ссылка, которая ведет на страницу с 404 ошибкой.
Почему плохо: Пользователь кликает и получает ошибку. GoogleBot кликает, тратит краулинговый бюджет и обрывает путь обхода. Ухудшает ПФ.
Ссылки, которые забыли поменять после переноса сайта с тестового сервера.
Пример: http://localhost:8080/image.jpg.
Ломают картинки и стили для всех внешних посетителей и ботов.
Страницы, на которые не ведет ни одна внутренняя ссылка.
Страницы, с которых нельзя перейти никуда дальше.
hreflang — это атрибут, сообщающий Google, на каком языке написана страница и для какого региона она предназначена./uk/) и страница на английском для Канады (/ca/).hreflang Google посчитает это дублем и пессимизирует.hreflang Google поймет, что это локализованные версии, и покажет канадцу канадскую страницу, а британцу — британскую.
<link rel="alternate" hreflang="en-GB" href="https://site.com/uk/casino/" />
<link rel="alternate" hreflang="en-CA" href="https://site.com/ca/casino/" />
<link rel="alternate" hreflang="x-default" href="https://site.com/casino/" />
Сначала язык (ISO 639-1), потом страна (ISO 3166-1 Alpha 2). Например: en-GB (английский, Британия). Нельзя писать uk вместо en-GB (uk = украинский язык).
В атрибуте href должны быть полные ссылки с https://, а не /uk/casino/.
Указывает "страницу по умолчанию" для всех остальных стран (например, для пользователя из Индии, если для него нет отдельной версии).
Если страница A ссылается на страницу B через hreflang, то страница B обязана ссылаться обратно на A. Иначе тег игнорируется.
Использование en-UK вместо en-GB. Использование eu для Европы (такого кода нет).
Указание в hreflang страницы, которая редиректит (301) или выдает 404.
Страница должна указывать в блоке hreflang не только другие языки, но и саму себя.
site.com/de/, site.com/es/. Легко управлять, весь траст накапливается на одном домене.de.site.com. Хуже передают ссылочный вес с основного домена.site.de, site.es. Максимальный гео-сигнал, но каждый сайт придется прокачивать ссылками с нуля (очень дорого).Сайт загрузился по HTTPS, но картинка или скрипт внутри страницы тянутся по старому HTTP (<img src="http://...">).
Результат: Браузер сбрасывает статус "Безопасно".
Доступны обе версии сайта: и HTTP, и HTTPS.
Результат: Жесткое дублирование контента. Вес распыляется.
Все запросы к http:// должны автоматически и безусловно перенаправляться на https:// на уровне сервера (.htaccess / nginx.conf).
Поменять в коде все жесткие ссылки http://site.com/img.jpg на относительные /img.jpg (защита от Mixed Content).
Специальный заголовок сервера, который запрещает браузеру даже пытаться открыть сайт по HTTP. Ускоряет загрузку и повышает безопасность.
Нет тега <meta name="viewport" ...>. Сайт открывается как мелкая десктопная версия.
Появляется горизонтальный скролл (обычно из-за широких таблиц казино или картинок с жестким width).
Текст меньше 16px тяжело читать с телефона.
Кнопки или ссылки стоят вплотную. Палец промахивается. Google считает это критической UX ошибкой.
Один HTML-код для всех устройств. Дизайн подстраивается через CSS (медиазапросы @media (max-width: 768px)). Рекомендовано Google.
max-width: 100% для картинок и видео, чтобы они сжимались, а не рвали экран.overflow-x: auto.| Тип разметки | Что дает в Google |
|---|---|
| Review / Product | Желтые звездочки рейтинга (⭐⭐⭐⭐⭐) под вашей ссылкой. Сильнейший магнит для кликов. |
| FAQPage | Выводит гармошку с вопросами прямо в поисковой выдаче. Сайт занимает в 2 раза больше места. |
| BreadcrumbList | Аккуратные навигационные крошки (Site > Casino > Review) вместо страшного URL. |
| Article / NewsArticle | Помогает попасть в блоки Top Stories и Google Discover. |
Рекомендован Google. Это невидимый для пользователя скрипт в блоке <head> или теле страницы. Легко внедрять, не ломает верстку.
<script type="application/ld+json">
...
</script>
Огромные PNG/JPEG по 5 МБ в шапке сайта. (Нужно сжимать и конвертировать в WebP).
Тяжелые скрипты аналитики, трекеров, чатов, которые загружаются до того, как появится текст.
Дешевый хостинг, который долго "думает" перед тем, как начать отдавать страницу.
<div>, но забыли закрыть).<span><div>...</div></span>).id с одинаковым именем (id должен быть уникальным).alt у картинок).Браузеры пытаются "угадать", как исправить кривой код. В Chrome сайт может выглядеть нормально, а в Safari или на iPhone — "поплыть".
Если код сильно сломан, GoogleBot может некорректно прочитать контент или вообще "выплюнуть" страницу, не дойдя до важного текста.
Кривой код заставляет браузер тратить лишние миллисекунды на перерасчет DOM-дерева, что ухудшает метрики Core Web Vitals.
Инструмент: W3C Markup Validation Service. Добиваться 100% валидности не обязательно, но критические ошибки (Fatals) нужно устранять.
| Уровень | Типы ошибок | Действие |
|---|---|---|
| Критический (Фатал) | Сайт отдает 5xx/4xx, закрыт в robots.txt, петли редиректов. | Бросать всё, чинить немедленно. |
| Высокий | Дубли страниц, отсутствие Canonical, сломанный мобайл, мусор в Sitemap. | Ставить в приоритет спринта (1-2 недели). |
| Средний | Медленная загрузка (CWV), отсутствие микроразметки, битые внутренние ссылки. | Плановая работа в рамках оптимизации. |
| Низкий | Ошибки валидации W3C, неоптимальный размер изображений, сироты в блоге. | Делать по мере наличия ресурсов разработки. |
Гениальный контент и крутые ссылки не работают, если сайт физически недоступен боту или утопает в дублях.
Вы не обязаны уметь кодить, но вы обязаны уметь понятно описать проблему, её причину и дать ТЗ на исправление программисту.
Парсер может показать "10,000 ошибок". Умейте отделять критические (Фаталы) от косметических. Чините главное.
Домашнее задание: Технический SEO-аудит реального проекта.