Техническая оптимизация сайта: фундамент, на котором держится всё остальное

Highlights

Техническая оптимизация отвечает не на вопрос «почему мы должны быть в топе», а на четыре скучных: дойдёт ли робот, правильно ли прочитает, быстро ли отдастся страница человеку и не сломается ли всё это после ближайшего релиза.
Порядок работ важнее полноты чек-листа. Сначала доступность и индексация, потом дубли и рендеринг, и только потом скорость. Ускорять страницу, которая не в индексе, бессмысленно.
Большая часть «технических» потерь трафика, которые я разбирал у клиентов, — это не про миллисекунды. Это закрытый по недосмотру раздел, десяток версий одной страницы по URL-параметрам, цепочка редиректов после переезда и 5xx в часы пиковой нагрузки.
Скорость — реальный фактор ранжирования, но слабый, и работает он ближе к тай-брейку между сопоставимыми страницами. При этом на конверсию и отказы влияет заметно сильнее, чем на позиции.
Один смысл — один URL. Канонизация, обработка параметров, пагинации и фильтров даёт на среднем интернет-магазине больше, чем любая работа с CSS.
С июля 2024 Google обходит все сайты мобильным роботом. Мобильная версия — это не «вторая», это единственная, которую он видит.
Если контент дорисовывается скриптами, риск потерять его из индекса реальный: Googlebot рендерит JavaScript, но с задержкой и не при любых обстоятельствах.
Краулинговый бюджет — тема крупных проектов. По собственным порогам Google это сайты от миллиона страниц либо от десятка тысяч с ежедневными изменениями. Маленькому сайту забивать этим голову не нужно.
Технический долг возвращается. Любой релиз способен уронить то, что вы чинили полгода назад, поэтому мониторинг и регресс-проверки — часть работы, а не бонус к ней.

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

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

И ещё одно наблюдение из практики. Техничку почти никогда не «делают один раз». Её чинят, а потом сайт живёт: маркетологи добавляют UTM-метки, разработчики выкатывают новый фильтр, дизайнер меняет шаблон карточки. Через полгода всплывают те же грабли, только с другой стороны. Поэтому ниже я разложил тему не по алфавиту, а по слоям — от «робот вообще к нам дошёл» до «мы удержим это состояние».

Как я смотрю на технический слой

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

Слой 1. Доступность: робот должен дойти

Ответы сервера и редиректы

Первое, что видит поисковик, — не ваш текст, а код ответа. Всё дальнейшее зависит от этих трёх цифр, поэтому я всегда начинаю аудит с обхода сайта краулером и сортировки по статусам.

Код	Что означает	Что с этим делает Google
`200`	всё хорошо	сканирует и рассматривает для индекса
`301`, `308`	переехали навсегда	передаёт сигналы на новый адрес, старый выкидывает из индекса
`302`, `307`	временно	обычно оставляет в индексе исходный URL
`404`	страницы нет	со временем убирает из индекса
`410`	удалена насовсем	то же самое, но чуть быстрее
`429`, `5xx`	сервер не смог	притормаживает сканирование, при затяжных ошибках выбрасывает страницы

Больше всего проблем создают не сами коды, а их комбинации. Классика — цепочка редиректов после переезда: старый URL ведёт на версию без www, та на https, та на слэш, та на новый раздел. Google обходит до десяти переходов в одной цепочке, но каждый лишний прыжок — это потерянное время робота и риск, что где-то в середине кто-то поставит 302 вместо 301. Схлопывайте цепочки в один переход, даже если технически они работают.

Отдельная беда — «мягкие 404». Это когда сервер бодро отвечает 200, а на странице написано «ничего не найдено». Google такое распознаёт и помечает как soft 404, но лучше не заставлять его гадать: нет страницы — отдавайте честный 404. Подробный разбор всех статусов, включая сетевые ошибки и проблемы DNS, есть в переводе официальной справки про коды состояния HTTP и SEO.

Сканирование и индексация

Базовый уровень: поисковик должен находить страницы и добавлять их в индекс. Здесь живут robots.txt, карта сайта, внутренние ссылки и директивы индексации — то, чем вы прямо управляете тем, куда роботу можно, а куда нет.

Главная путаница, которую я вижу постоянно: robots.txt запрещает сканирование, а не индексацию. Закрытая в нём страница всё равно может попасть в выдачу — без описания, по одним внешним ссылкам. А noindex в мета-теге робот увидит, только если ему разрешено страницу скачать. То есть закрыть страницу в robots.txt и одновременно поставить на ней noindex — это выстрел себе в ногу: директиву никто не прочитает.

Чтобы не путаться, я держу в голове такую табличку — что каким инструментом на самом деле управляется:

Инструмент	Чем управляет	Чего не делает
`robots.txt`	пускает или не пускает робота к URL	не убирает из индекса: закрытая страница может показаться в выдаче без описания
`noindex` в мете или `X-Robots-Tag`	выкидывает страницу из индекса	не сработает, если URL закрыт в `robots.txt` — директиву некому прочитать
`rel="canonical"`	подсказывает предпочтительный адрес среди дублей	не приказывает: Google взвешивает подсказку вместе с остальными сигналами
`404` и `410`	сообщает, что страницы больше нет	не удаляет мгновенно — из индекса выпадает за несколько обходов
`sitemap.xml`	помогает найти страницы, до которых плохо доходят ссылки	не гарантирует ни сканирования, ни индексации
Удаление URL в Search Console	прячет адрес из выдачи примерно на полгода	не удаляет из индекса — по истечении срока страница вернётся

Всю механику от обнаружения до попадания в выдачу, вместе с чек-листом, я разобрал в статье про сканирование и индексацию.

Краулинговый бюджет и логи

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

Здесь я сразу оговорюсь, потому что тема перегрета.

А вот логи сервера полезны всем, у кого они есть. Это единственный источник, который показывает не то, что вы думаете о сайте, а что робот реально скачивал, как часто и с какими кодами ответа. Детали — в статье про краулинговый бюджет и анализ логов.

Доступ ботов, включая AI

Раньше вопрос звучал просто: пускаем Googlebot и Яндекс, всех остальных по настроению. Сейчас в логах десяток краулеров нейросетей, и решение стало более осмысленным. Разделять их я советую не по именам, а по тому, зачем они пришли:

Кто ходит	Зачем	Что теряете, если закроете
Поисковые роботы	обход и индексация	видимость в поиске — тут и обсуждать нечего
Обучающие краулеры ИИ	забирают тексты в обучающие выборки моделей	сегодня ничего заметного; это вопрос вашей позиции, а не трафика
Ответные краулеры ИИ	приходят в момент ответа пользователю, чтобы процитировать источник	цитирования и переходы из AI-ответов, гарантированно
Парсеры, скраперы, «серые» боты	копируют контент, снимают цены	ничего, кроме лишней нагрузки на сервер

Ключевая развилка — во второй и третьей строке: их часто закрывают одной строкой в robots.txt, не разобравшись, что это разные истории.

Отдельно про «серые» краулеры и парсеры: они реально едят ресурсы сервера, и на нагруженных проектах их фильтрация — тоже часть технической работы, просто не ради индексации, а ради стабильности. Кто есть кто среди AI-ботов и почему llms.txt сегодня почти не работает, я разбираю в статье про доступ AI-ботов.

Слой 2. Понимание: робот должен правильно прочитать

JavaScript-рендеринг

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

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

контент дорисовывается только после клика «показать ещё» или скролла;
навигация висит на onclick вместо честного <a href="..."> — робот такую ссылку не считает ссылкой;
canonical, title и описание проставляются скриптом уже после загрузки;
бесконечная лента вместо пагинации, без отдельных адресов у страниц списка.

Проверка простая: посмотрите исходный код страницы (не инспектор, а именно view-source) и поищите свой основной текст. Нет — надо думать про серверный рендеринг или пререндеринг. Подробности в статье про JavaScript SEO.

Дубли и канонизация

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

сайт открывается и с www, и без, и по http, и по https;
один и тот же адрес работает со слэшем на конце и без;
к URL прилипают UTM-метки, идентификаторы сессий, параметры сортировки и вида отображения;
фильтры генерируют бесконечные комбинации: цвет + размер + бренд + цена;
пагинация плодит страницы 2, 3, 4… с почти одинаковым содержимым;
у товара есть отдельные URL для каждого варианта и печатная версия впридачу.

Инструменты для наведения порядка известны: один главный хост с 301 на него, rel="canonical" на предпочтительный адрес, noindex для служебных комбинаций, разумная политика по параметрам. Важно помнить, что canonical — подсказка, а не директива. Google принимает её во внимание вместе с другими сигналами, поэтому противоречия он разрешит сам и не всегда в вашу пользу: если canonical указывает на одну страницу, а внутренние ссылки и sitemap ведут на другую, вы просто отдали выбор роботу.

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

Архитектура сайта и URL

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

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

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

Как это выглядит на практике:

Так лучше не надо	Так лучше	Почему
`/index.php?id=482&cat=17`	`/katalog/kuhonnye-nozhi/`	адрес читает человек в выдаче и в мессенджере
`/Catalog/Nozhi_Kuhonnye/`	`/katalog/kuhonnye-nozhi/`	нижний регистр и дефисы вместо подчёркиваний
`/2019/03/kak-vybrat-nozh/`	`/blog/kak-vybrat-nozh/`	дата в адресе состаривает материал раньше времени
`/p/482/?color=red&utm_source=fb`	`/p/nozh-santoku/`	параметры плодят дубли одного и того же товара

Как считать кликовую глубину, чем связывать разделы и по каким правилам писать адреса — в отдельном разборе про архитектуру сайта и URL.

Языковые версии и регионы

Если сайт живёт на нескольких языках или обслуживает несколько стран, добавляется отдельный технический узел — hreflang. Он не про ранжирование, а про то, чтобы человеку из нужной страны показали нужную версию, а версии не конкурировали между собой как дубли.

Тонкости, на которых спотыкаются:

Связи должны быть взаимными и включать саму себя. Если А ссылается на Б, то Б обязан ссылаться на А — и на себя тоже.
Код региона легко выдумать. Правильно en-GB, а не en-UK. И порядок фиксированный: сначала язык, потом регион — es-MX, но не MX-es.
Нужен x-default — версия для всех, кто не попал ни в одну страну из набора.
Ссылаться можно только на канонические адреса. hreflang на URL с параметрами или на страницу, у которой canonical смотрит в другое место, Google просто проигнорирует.

И самое частое: hreflang расставили, а внутри страны версии всё равно дублируют друг друга дословно, потому что перевод сделали автозаменой валюты. Это уже вопрос не техники, а контента.

Структурированные данные и машиночитаемый слой

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

Минимальный набор для большинства сайтов выглядит так:

Что за страница	Что размечать	Что это даёт
Сайт как сущность	`Organization` или `Person`	связывает сайт с брендом или автором
Любая внутренняя	`BreadcrumbList`	путь разделов вместо голого URL в сниппете
Статья, руководство	`Article`	автор и дата публикации машиночитаемо
Карточка товара	`Product` + `Offer`	цена, наличие и рейтинг прямо в выдаче
Вопросы и ответы	`FAQPage`	расширенный сниппет с 2023 года получают только сайты госорганов и медучреждений; остальным остаётся машиночитаемость

Разметку стоит проверять валидатором и не описывать в ней то, чего человек на странице не видит, — за это Google накладывает ручные санкции. Как связать разметку с сигналами доверия, я разбираю в статье про Schema.org и E-E-A-T, а куда это всё движется в сторону машиночитаемых форматов — в материале про машиночитаемый слой сайта.

Слой 3. Скорость и удобство

Core Web Vitals

Google измеряет реальный пользовательский опыт тремя метриками. Оценка берётся по 75-му перцентилю живых визитов, то есть по опыту большинства ваших посетителей, а не по лабораторному замеру на быстром ноутбуке.

Метрика	Что измеряет	Хорошо	Плохо
LCP	когда отрисовался самый крупный элемент контента	до 2,5 с	больше 4 с
INP	сколько страница думает, прежде чем отреагировать на действие	до 200 мс	больше 500 мс
CLS	насколько вёрстка прыгает уже после отрисовки	меньше 0,1	больше 0,25

Между «хорошо» и «плохо» лежит серая зона «нужно улучшить» — попадание в неё не катастрофа, но и не повод расслабиться.

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

Сервер, кеш и сеть

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

Дальше по списку, примерно в порядке отдачи:

Кеш готовых страниц на сервере — на тяжёлых шаблонах CMS это обычно самый крупный выигрыш по TTFB.
Сжатие — brotli, в крайнем случае gzip.
Заголовки кеширования для статики — чтобы браузер не ходил за одним и тем же файлом при каждом переходе.
Современный протокол — HTTP/2 или HTTP/3 вместо старого HTTP/1.1.
CDN — если аудитория размазана по географии.

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

Разбор по фазам, пороги TTFB и три уровня кеширования — в отдельной статье про сервер, TTFB и кеширование.

Картинки и медиа

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

Современные форматы вместо JPEG и PNG — WebP или AVIF. Для конвертации у меня есть бесплатный инструмент перевода в WebP.
Тот размер, в котором картинка показывается. Оригинал на две тысячи пикселей, ужатый браузером в триста, — это оплаченный трафик, который никто не увидел.
Явные width и height — чтобы вёрстка не прыгала и не портила CLS.
Ленивая загрузка для всего, что ниже первого экрана.

Мобильная версия

Тут всё коротко и жёстко. С июля 2024 года Google обходит сайты мобильным роботом, и то, чего нет в мобильной версии, для него просто не существует. Поэтому классическая ошибка «на мобильных спрятали часть текста, отзывы и часть перелинковки, чтобы не загромождать» превратилась из вопроса вкуса в потерю контента из индекса.

Что проверяю:

одинаков ли основной контент на десктопе и на мобильном;
доступны ли в HTML блоки, спрятанные в аккордеоны и табы;
не мешают ли попапы и баннеры согласия увидеть контент сразу;
хватает ли размера кликабельным элементам, не слипаются ли ссылки;
и обязательно — как это выглядит на реальном телефоне, а не в узком окне десктопного браузера.

Полный список того, что должно совпадать между версиями, и чем проверять после закрытия Mobile-Friendly Test — в статье про мобильную версию и mobile-first.

Слой 4. Устойчивость: чтобы завтра не сломалось

HTTPS и безопасность

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

Срок действия. Истёкший сертификат кладёт трафик мгновенно и без предупреждения — это дежурная авария выходного дня.
Смешанный контент. Защищённая страница, которая подтягивает картинки и скрипты по http.
Один переход на https. Все версии — с www и без, http и https — сводятся к канонической за один редирект, а не за три.
Ничего лишнего в открытом доступе. Стейджинг, бэкапы и служебные каталоги не должны отдавать 200 случайному роботу.

Переезды и редизайны

Самая рискованная операция в SEO. Смена домена, переход на новую CMS, переработка структуры URL, объединение двух сайтов — любая из них при аккуратном исполнении проходит с небольшой просадкой на несколько недель, а при неаккуратном превращается в потерю половины трафика без быстрого возврата.

Работает здесь скучная дисциплина, и порядок в ней важен:

Полный список старых URL — из краулера, sitemap, Search Console и логов, а не по памяти.
Карта соответствия «старый → новый» один-в-один. Свалить всё на главную — самый быстрый способ потерять трафик.
301 без цепочек: старый адрес ведёт сразу на конечный новый.
Перенос мета-данных и разметки вместе со страницами.
Обновление внутренних ссылок на новые адреса напрямую, а не через редирект.
Оба сайта в Search Console плюс инструмент смены адреса.
Свежий sitemap с новыми URL.
Наблюдение за индексом неделями после — просадка на несколько недель нормальна, отсутствие возврата нет.

Чек-лист по шагам — в статье про переезд на новый домен без потери трафика.

Мониторинг и регресс после релизов

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

Мой минимальный набор наблюдения выглядит так:

Search Console — отчёт по индексации, ошибки, Core Web Vitals, живые данные по запросам. Смотреть раз в неделю, а не когда трафик уже упал.
Регулярный обход краулером (Screaming Frog или Netpeak Spider) и сравнение с прошлым обходом: что изменилось в статусах, canonical, тайтлах, количестве страниц.
Логи сервера на крупных проектах — куда робот ходит и какие коды получает.
Аптайм и скорость — внешний мониторинг доступности плюс контроль CWV по полевым данным.
Быстрая проверка после каждого релиза: robots.txt, случайная выборка из десяти важных страниц, коды ответа, наличие текста в исходном HTML.

Как собрать из этого рабочий ритм и по каким признакам отличать свою поломку от апдейта Google — в статье про мониторинг и регресс после релизов.

Приоритеты: в каком порядке чинить

Порядок у меня простой и почти не зависит от проекта. На каждую следующую ступень имеет смысл вставать, только когда держит предыдущая.

Доступность. Сайт стабильно отвечает 200, важные страницы не закрыты, robots.txt не запрещает лишнего, критичных 5xx нет.
Индексация. Нужные страницы в индексе, ненужные — нет. Sitemap отдаёт актуальные адреса.
Дубли и канонизация. Один смысл — один URL, параметры и фильтры под контролем.
Рендеринг. Основной контент виден в HTML или гарантированно доживает до индекса.
Мобильная версия. Контент на мобильном равен десктопному.
Скорость. Сначала сервер и картинки, потом тонкая настройка метрик.
Разметка и мелочи. Микроразметка, хлебные крошки, аккуратные URL.
Мониторинг. Чтобы пункты с первого по седьмой не разъехались обратно.

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

JavaScript-рендеринг проверяю только там, где контент собирается скриптами. Краулинговый бюджет и логи — история для крупных проектов. Всё остальное актуально для сайта любого размера.

Чек-лист технического аудита

Короткая версия, по которой я прохожусь на первом заходе. Каждый пункт — либо «в порядке», либо задача в бэклог.

Глубже по теме

Сканирование и индексация — с этого стоит начать, там путь страницы от обнаружения до выдачи.
Коды состояния HTTP и SEO — как Google реагирует на 2xx, 3xx, 4xx, 5xx и сетевые ошибки.
Core Web Vitals — три метрики скорости и стабильности, их пороги и проверка.
Анализ Core Web Vitals в реальном времени — как снимать полевые данные у себя.
JavaScript SEO — как Google рендерит скрипты и где теряется контент.
Дубли и канонизация — как свести один смысл к одному URL.
Архитектура сайта и URL — кликовая глубина, перелинковка и правила адресов.
Сервер, TTFB и кеширование — скорость до того, как началась вёрстка.
Мобильная версия и mobile-first — паритет контента и проверка после закрытия старых инструментов.
Мониторинг и регресс после релизов — как удержать состояние, которого добились.
Краулинговый бюджет и анализ логов — как робот тратит внимание на крупном сайте.
Микроразметка Schema.org и E-E-A-T — что и как размечать.
Машиночитаемый слой сайта — llms.txt, EntityMap, OKF и что из этого работает.
Доступ AI-ботов и правда про llms.txt — управление доступом краулеров нейросетей.
Переезд на новый домен — чек-лист миграции.
Netpeak Spider vs Screaming Frog — чем обходить сайт.
Соседний слой: on-page оптимизация.
Назад к карте цикла: продвижение сайта.