Техническое SEO: индексация, скорость и структура сайта

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

Что относится к техническому SEO

Техническую часть мы условно делим на четыре группы задач:

• Доступность. Сайт отвечает, отдаёт правильные коды состояния, не закрыт от роботов по недосмотру, работает по защищённому протоколу.
• Индексация. Нужные страницы попадают в индекс, ненужные — нет, у каждой страницы один канонический адрес.
• Структура и разметка. Понятная иерархия разделов, читаемые адреса, корректные заголовки, мета-теги, микроразметка, карта сайта.
• Производительность. Скорость загрузки и отклика, вес страниц, серверное время ответа, работа на мобильных.

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

Структура сайта и адреса страниц

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

• значимая страница доступна не более чем в три-четыре перехода от главной; всё, что глубже, обходится реже и хуже индексируется;
• адрес читаемый, латиницей, слова через дефис, без идентификаторов сессии и лишних параметров: /service/podderzhka-sajtov понятнее, чем /index.php?id=482;
• адрес соответствует вложенности: страница услуги лежит внутри раздела услуг, а не в корне;
• у сайта один основной вариант адреса — с www или без, с завершающим слэшем или без, только по https; все остальные варианты перенаправляются на него;
• хлебные крошки на всех внутренних страницах: они формируют дополнительные внутренние ссылки и попадают в сниппет.

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

Индексация: что должно быть в индексе и что не должно

Робот тратит на сайт ограниченный ресурс. Если он уходит на служебные адреса, фильтры и результаты поиска по сайту, до нужных страниц дело может не дойти. Задача — направить обход туда, где польза. Инструменты:

1. robots.txt. Закрывает от обхода служебные разделы: административную часть, корзину, личный кабинет, внутренний поиск. Ограничение: запрет закрывает обход, но не гарантирует отсутствие адреса в индексе, если на него ведут ссылки. И не закрывайте здесь стили и скрипты — без них робот не отрисует страницу и не оценит мобильную версию.
2. Мета-тег robots со значением noindex. Единственный надёжный способ убрать страницу из индекса. Работает, только если робот может её загрузить: закрывать такую страницу ещё и в robots.txt нельзя, иначе тег никто не прочитает.
3. Канонический адрес. Указывает основную версию, когда содержимое доступно по нескольким адресам; основная страница указывает сама на себя.
4. Карта сайта. Перечень адресов, которые мы хотим видеть в индексе, с датой изменения. Закрытые от индексации, перенаправляемые и несуществующие страницы в неё попадать не должны — панели вебмастеров сообщат об ошибках.

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

Ещё одна частая находка — незакрытая тестовая копия сайта на поддомене: она попадает в индекс и конкурирует с основным сайтом. Тестовые площадки закрываем паролем на уровне сервера, а не только в robots.txt.

Дубли: откуда берутся и как искать

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

• сайт открывается и с www, и без, и по http, и по https;
• адреса со слэшем на конце и без него отдают одну и ту же страницу;
• параметры сортировки, фильтров, меток рекламных кампаний создают бесконечное число вариантов одного каталога;
• постраничная навигация: вторая и третья страницы каталога с тем же текстом и тем же заголовком;
• один товар доступен из нескольких категорий по разным адресам;
• версии для печати и служебные копии страниц;
• частичные дубли: разные страницы с одинаковыми title, description и вводным текстом — формально это разные документы, но поиск считает их малоразличимыми.

Ищем так: обходим сайт краулером и сортируем результат по заголовкам и мета-описаниям, смотрим в панелях вебмастеров разделы про исключённые страницы, сравниваем число адресов в индексе с числом реальных страниц. Расхождение в разы — верный признак того, что в индекс попадает мусор.

Устаревшие страницы: обновить, склеить, удалить или закрыть

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

Решение принимаем по каждой странице отдельно.

Чего не стоит: удалять страницы пачкой без разбора, перенаправлять всё на главную и оставлять удалённые адреса в карте сайта. И обязательно проверьте внутренние ссылки — после чистки их не должно остаться на удалённые страницы.

Заголовки и мета-теги

Заголовки задают смысловую структуру документа: один h1 на страницу, он называет её тему и не повторяется на других страницах; h2 делят материал на разделы, h3 — на подразделы. Для оформления заголовки не используются: сделать текст крупным — задача стилей, а не тега h2.

Мета-теги напрямую позиции не задают, но определяют, как страница выглядит в выдаче, а значит — кликнут по ней или по соседней.

• title. Уникальный для каждой страницы, до 60-70 символов, чтобы не обрезался; главное — в начале, название компании в конце, если оно вообще нужно. Взаимозаменяемые хвосты вроде «повышение эффективности вашего бизнеса», одинаковые на десятке страниц, лучше заменить на то, что действительно делается.
• description. 140-160 символов, описывает содержание страницы и даёт повод перейти: срок, цена, состав услуги. Поиск не всегда показывает его дословно, но использует как основу сниппета.
• keywords. На ранжирование в современных системах не влияет; тратить на него время не стоит.
• Открытый граф. Заголовок, описание и картинка для превью в мессенджерах и соцсетях: ссылка без картинки выглядит недоделанной.

Микроразметку в минимальном объёме ставим всегда: организация с контактами и часами работы, хлебные крошки, статья для блога с датами публикации и изменения, вопросы и ответы там, где есть блок FAQ. Позиции она сама по себе не поднимает, но улучшает сниппет и помогает поиску разобрать страницу.

Скорость: что измерять и какие ориентиры

Скорость сайта — не одно число, а набор показателей. «Сайт грузится за три секунды» ничего не говорит: важно, когда посетитель увидел основное содержимое и когда смог с ним взаимодействовать. Мы опираемся на метрики Core Web Vitals и несколько дополнительных величин.

Чем мерить: для разовой проверки — PageSpeed Insights и панель разработчика в браузере (вкладки «Сеть» и «Производительность»); для наблюдения за реальными посетителями — Метрика и отчёты о показателях страниц в панелях вебмастеров, потому что лабораторные замеры показывают идеальные условия, а люди сидят на мобильном интернете; для контроля доступности — внешний мониторинг с уведомлением, когда сайт перестал отвечать.

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

Что чаще всего замедляет сайт

Сайт редко становится медленным одномоментно — обычно он год за годом обрастает виджетами, картинками и модулями. Источники замедления в порядке того, как часто мы их встречаем:

• Картинки. Фотографии на несколько мегабайт, уменьшенные до нужного размера стилями. Лечится сжатием, форматом WebP рядом с оригиналом, правильными размерами и отложенной загрузкой всего, что ниже первого экрана. Сам первый экран откладывать не надо — это ухудшит LCP.
• Сторонние скрипты. Счётчики, чаты, виджеты обратного звонка, пиксели. Каждый — подключение к чужому серверу, отвечает оно как получится. Регулярно находим скрипты от давно отключённых сервисов и счётчики, подключённые дважды.
• Отсутствие кэширования. Сервер собирает одну и ту же страницу заново на каждый запрос. Кэш страниц, кэш запросов и заголовки кэширования для статики решают это почти без правок кода.
• Несжатая статика. Сжатие на стороне сервера и минификация CSS и JS уменьшают объём передаваемых данных.
• Шрифты. Несколько семейств по пять начертаний с чужого домена. Оставляем только нужные начертания в формате woff2, размещаем у себя и задаём поведение при загрузке, чтобы текст не пропадал.
• Блокирующие ресурсы. Стили и скрипты в шапке, из-за которых браузер ждёт, прежде чем отрисовать страницу. Критические стили встраиваем, остальное грузим отложенно.
• Тяжёлые запросы к базе. Самая частая причина, когда сайт стал медленным по мере роста каталога.

Серверная часть и медленные запросы

Если время до первого байта измеряется секундами, оптимизировать картинки бессмысленно: проблема на сервере. С базой действуем так: включаем журнал медленных запросов и смотрим, какие выполняются дольше заданного порога. Практика показывает, что почти всё время съедают два-три запроса, а не «база вообще медленная». Оптимизировать наугад бессмысленно.

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

Мобильная версия и доступность

Поисковые системы оценивают сайт по мобильной версии: именно она определяет, что попадёт в индекс. Если на телефоне часть содержимого скрыта, а на десктопе есть, в индекс попадёт мобильный вариант. Что проверяем:

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

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

Регламент: что и с какой периодичностью проверять

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

Технические требования проще закладывать на этапе разработки, чем исправлять потом: с этого начинается наша работа над сайтами и информационными системами.

Коды ответов и перенаправления

Сервер должен отвечать однозначно, а на большинстве сайтов мы находим одни и те же ошибки:

• Мягкая 404. Несуществующий адрес отдаёт код 200 с текстом «страница не найдена». Поиск считает такую страницу нормальной и держит её в индексе.
• Перенаправление на главную вместо 404. Несуществующий адрес отдаёт 302 на главную. Индекс размывается, а понять, какие разделы удалены, становится нельзя.
• Цепочки перенаправлений. Три-четыре шага, оставшиеся после переездов и смены структуры. Каждый шаг тратит время робота, а иногда и часть ссылочного веса.

Правило: одна страница — один канонический адрес, все остальные варианты ведут на него постоянным перенаправлением 301 в один шаг. Временные 302 и 307 ставим только там, где адрес действительно вернётся.

Ошибки в canonical, пагинации и микроразметке

Канонический адрес — рекомендация, а не запрет, и ошибиться в нём проще, чем кажется. Регулярно встречаем canonical, указывающий на закрытую или несуществующую страницу: такая ошибка полностью выбивает раздел из индекса. Карточку товара привязываем к одному адресу, из какого бы раздела на неё ни пришли. Страницы постраничной навигации оставляем самостоятельными, но с уникальным title.

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

Для микроразметки действуют два правила, которые нарушают чаще всего: размечать можно только то, что видно посетителю, и данные в разметке должны совпадать с данными на странице. Выдуманные оценки или цена, которой нет в карточке, ведут к санкциям на расширенный сниппет.

Из приёмов ускорения добавим два, которые закрывают сразу несколько проблем: атрибуты ширины и высоты у изображений заодно лечат сдвиг вёрстки, а шрифты, размещённые у себя и подключённые с font-display, перестают задерживать текст. Оптимизировать имеет смысл то, что видно в полевых данных о реальных посетителях, а лабораторный тест подсказывает, где искать причину.

Логи сервера: что робот делал на самом деле

Логи — единственный источник, который показывает фактическое поведение робота: какие страницы он обходил, как часто и какие коды получал. Мы смотрим долю ответов 4xx и 5xx, распределение обхода по разделам и время ответа сервера для робота. Нередко выясняется, что половина обхода уходит на служебные адреса, а свежие карточки робот не видел неделями. Страницы, на которые не ведёт ни одна внутренняя ссылка, находим обходом краулера и либо связываем с сайтом, либо убираем.

Порядок технического аудита

Идём от того, что блокирует индексацию, к тому, что улучшает уже работающее.

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

Порядок действий, если сайт просел

Когда трафик падает, велик соблазн начать переписывать тексты. Мы сначала исключаем техническое — это быстрее и дешевле.

1. Проверяем код ответа главной и ключевых разделов: не отдаёт ли сайт ошибку, не истёк ли сертификат.
2. Смотрим robots.txt и мета-теги: не закрыли ли сайт от индексации при выкладке с тестового сервера — это случается чаще, чем кажется.
3. Сверяем число страниц в индексе с прошлым замером и открываем отчёты об исключённых страницах.
4. Проверяем, не менялись ли адреса и работают ли перенаправления со старых.
5. Смотрим сообщения в панелях вебмастеров — там прямо пишут про санкции и серьёзные ошибки.
6. Сравниваем падение по разделам: просел один — дело в нём, просел весь сайт — ищем общую причину или обновление алгоритма.
7. Проверяем скорость и мобильную версию, особенно если недавно ставили новый модуль или виджет.

И только если техническое в порядке, переходим к содержанию и внешним факторам. Такой порядок экономит недели работы.

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

Отдельно разбираем мобильное SEO — что входит в работу, как замеряем скорость на телефоне и по каким показателям считаем результат.