9 серверных проверок, которые влияют на ранжирование сильнее, чем перелинковка

За двадцать лет в SEO я насмотрелся на одну и ту же картину: владелец сайта неделями перекраивает внутренние ссылки, рисует схемы перелинковки в Miro, спорит про анкоры в меню — а позиции стоят на месте. И почти всегда, когда я открываю такой проект, проблема оказывается не в ссылках. Она на сервере. На том самом сервере, в который никто не заглядывал с момента запуска сайта.

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

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

1. Время ответа сервера (TTFB) — то, на что робот реагирует первым

TTFB (Time To First Byte) — это интервал между моментом, когда робот отправил запрос, и моментом, когда сервер выдал первый байт ответа. Не загрузил картинки, не отрисовал страницу — просто отозвался. И вот этот показатель робот Яндекса чувствует острее, чем любой человек.

Логика простая. У робота есть краулинговый бюджет — лимит времени и ресурсов, которые он готов потратить на ваш сайт за визит. Если каждая страница отвечает по 600–800 миллисекунд, робот за один заход обойдёт в разы меньше страниц, чем мог бы. Часть документов остаётся непросканированной, новые материалы попадают в индекс с задержкой в дни и недели. А вы сидите и гадаете, почему свежая статья «не залетает».

Норма, к которой я стремлю клиентские проекты, — TTFB до 200 мс. Всё, что выше 500 мс, — это уже красная зона, требующая разбирательств с хостингом или с тем, как сервер обрабатывает запросы (тяжёлые плагины, отсутствие кэша, медленная база данных). Проверяется элементарно: через консоль командой curl -w "%{time_starttransfer}" -o /dev/null -s ваш-сайт или через WebPageTest, где TTFB выводится отдельной строкой. Если цифры пугают — это первое, что я выношу на доработку сайта, потому что без этого остальное лечить бессмысленно.

2. Корректность кодов ответа HTTP — здесь рушится больше сайтов, чем кажется

Сервер на каждый запрос отвечает кодом состояния. Живая страница — 200, постоянный переезд — 301, временный — 302, удалённая страница — 404 или 410, технические работы — 503. Звучит как азбука. А на практике я регулярно встречаю сайты, где половина кодов выставлена неправильно, и Яндекс из-за этого ведёт себя непредсказуемо.

Классика жанра — «мягкий 404» (soft 404). Это когда вы удалили товар или страницу, а сервер вместо честного 404 отдаёт код 200 и пустую страницу-заглушку «ничего не найдено». Для робота это сигнал: страница жива, индексируй её. В итоге индекс забивается мусором, а полезные документы размываются в общей массе низкокачественных. Яндекс такое не любит и постепенно роняет доверие ко всему хосту.

Вторая беда — цепочки редиректов. Когда URL ведёт на 301, тот на ещё один 301, а тот уже на финальную страницу. Каждое звено съедает время робота и размывает передаваемый вес. Я проверяю всё это Screaming Frog: один прогон по сайту показывает карту кодов ответа целиком, и сразу видно, где 200 притворяется 404, где висят бесконечные редиректы, а где страница вообще отдаёт 500. Без этой ревизии любая перелинковка строится на песке — вы можете вести вес на страницу, которая для робота технически мертва.

3. Стабильность сервера и обработка ошибок 5xx

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

Представьте: робот заходит на сайт во время пиковой нагрузки, сервер не справляется и выдаёт 500-ю ошибку на десятке страниц подряд. Что делает Яндекс? Он откладывает их, снижает частоту обходов и фиксирует, что хост нестабилен. Если такое повторяется из визита в визит, страницы начинают вылетать из индекса. Я лично разбирал кейс, где интернет-магазин терял позиции каждый понедельник — оказалось, по понедельникам запускалась тяжёлая выгрузка остатков, сервер ложился, и робот стабильно ловил 503 без всякой логики.

Кстати про 503. Если вы проводите технические работы, отдавать нужно именно 503 с заголовком Retry-After — это вежливое «зайди позже, я скоро вернусь». Робот поймёт и не станет деиндексировать страницы. А вот если во время работ сервер сыплет 500-ми или, того хуже, отдаёт 200 с пустотой — вы рискуете куда сильнее. Мониторинг аптайма (хоть UptimeRobot, хоть встроенный в Яндекс.Вебмастер сигнал о недоступности) должен стоять на каждом боевом проекте.

4. Сжатие контента: Gzip и Brotli

Между сервером и роботом гоняется текст — HTML, CSS, JavaScript. В несжатом виде это килобайты, которые передаются медленнее и снова бьют по тому самому краулинговому бюджету. Сжатие решает проблему на уровне сервера, и это одна из самых дешёвых оптимизаций с самым заметным эффектом.

Gzip умеют все, он давно стандарт. Brotli (разработка Google) жмёт текст ещё плотнее — в среднем на 15–20% лучше gzip на том же HTML. Если хостинг и сервер поддерживают Brotli, я всегда включаю именно его для текстовых ресурсов. Проверить, работает ли сжатие, можно по заголовку ответа: должен присутствовать Content-Encoding: gzip или Content-Encoding: br. Если заголовка нет — вы гоняете по сети лишний вес просто так.

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

5. Протоколы HTTP/2 и HTTP/3

Многие сайты до сих пор сидят на устаревшем HTTP/1.1, даже не подозревая об этом. А ведь протокол — это то, как именно сервер и клиент обмениваются данными, и переход на современную версию даёт прирост скорости без единой строчки изменений в коде сайта.

HTTP/2 принёс мультиплексирование: по одному соединению одновременно качается множество ресурсов, а не по очереди, как в старом протоколе. Для страницы с десятками картинок, стилей и скриптов это ощутимое ускорение отрисовки. HTTP/3 пошёл дальше — он работает поверх QUIC (на UDP) и устойчивее к потерям пакетов и нестабильному соединению, что особенно заметно на мобильном интернете.

Проверяется версия протокола во вкладке «Сеть» в инструментах разработчика браузера или тем же curl с флагом версии. Если ваш сервер всё ещё на HTTP/1.1 — это разговор с хостинг-провайдером или вопрос настройки nginx. Сама по себе версия протокола не «волшебная кнопка ТОПа», но в связке с быстрым TTFB и сжатием она складывается в ту общую скорость, на которую поисковики реагируют вполне измеримо.

6. Настройка SSL и TLS — не только зелёный замочек

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

Первое — срок действия. Истёкший сертификат превращает сайт в недоступный за одну ночь: браузер пугает пользователя красным экраном, а робот видит ошибку соединения и не может зайти. Видел проекты, которые теряли позиции на ровном месте просто потому, что автопродление сертификата отвалилось, а никто не заметил. Поставьте напоминание или включите автообновление через Let’s Encrypt — это бесплатно.

Второе — смешанный контент (mixed content), когда страница отдаётся по HTTPS, но внутри тянет картинки или скрипты по старому HTTP. Браузер ругается, часть ресурсов может не загрузиться, доверие к странице падает. Третье — версия протокола шифрования: TLS 1.2 как минимум, а лучше 1.3, плюс настроенный HSTS, который заставляет соединение всегда идти по защищённому каналу. Всё это проверяется за минуту через SSL Labs, и я прогоняю эту проверку на старте каждого аудита.

7. Кэширование и коды 304 — экономим бюджет робота

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

Механика такая. Сервер при ответе отдаёт заголовки Last-Modified и ETag — отпечаток состояния страницы. В следующий визит робот присылает запрос с If-Modified-Since, и если страница не изменилась, сервер отвечает коротким кодом 304 Not Modified — без тела страницы, почти мгновенно. Робот понимает, что качать нечего, и тратит освободившийся бюджет на новые или обновлённые документы.

Заголовок Cache-Control при этом управляет тем, как долго ресурсы (картинки, стили, скрипты) хранятся в кэше и не запрашиваются повторно. На сайтах, где это не настроено, робот при каждом заходе перекачивает всё подряд, как будто видит сайт впервые. Я регулярно встречаю проекты, где грамотная настройка 304-х ответов одна, без всякой перелинковки, ускоряла индексацию новых страниц в разы. Если вам кажется, что робот «забыл» про ваш сайт, — проверьте, отдаёте ли вы ему 304-е там, где должны.

8. Анализ серверных логов — то, чего не покажет ни один внешний сервис

Вот мы и добрались до моего любимого инструмента, который при этом почему-то игнорирует 90% оптимизаторов. Серверные логи (access.log) — это дневник, в котором записан каждый визит каждого робота: когда пришёл, на какую страницу, какой код получил в ответ. Это не оценка и не прогноз сторонних сервисов — это факты о том, что реально происходит между вашим сервером и Яндексом.

Из логов я вытаскиваю то, что не видно больше нигде. Сколько раз в сутки робот заходит на сайт и какие разделы обходит чаще всего. Тратит ли он бюджет на мусорные страницы — фильтры, сортировки, дубли с UTM-метками, — вместо важных коммерческих разделов. Натыкается ли он на 404 и 500 там, где их быть не должно. На одном проекте логи показали, что робот 70% визитов тратил на бесконечную пагинацию каталога, а до карточек товаров просто не доходил — закрыли мусор от обхода, и трафик пошёл вверх без единой новой ссылки.

Анализировать логи можно тем же Screaming Frog Log File Analyser или вручную через консольные утилиты, если объём небольшой. Это не самая простая часть технического SEO, и если вы не уверены, что прочитаете логи правильно, имеет смысл взять SEO-консультацию — час разбора логов часто экономит месяцы блужданий вслепую. Реальные примеры того, как это меняет картину, я собрал в разделе с кейсами продвижения.

9. География хостинга и скорость DNS

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

Физическое расположение сервера влияет и на скорость (чем ближе к пользователю, тем меньше задержка), и косвенно — на восприятие хоста поисковиком в привязке к региону. Если ваша аудитория в России, а сервер где-то в дата-центре за океаном, вы добавляете лишние сотни миллисекунд к каждому ответу на пустом месте. Для проектов под российский поиск я почти всегда рекомендую хостинг в российской юрисдикции или в близких к ней регионах — это и быстрее, и спокойнее с точки зрения доступности.

DNS-резолвинг — это время, за которое доменное имя превращается в IP-адрес, прежде чем браузер или робот вообще начнёт грузить страницу. Медленный или нестабильный DNS добавляет задержку до самого первого байта, и её часто не замечают, потому что ищут проблему в самом сайте. Проверить можно через те же сервисы замера скорости, где DNS Lookup выводится отдельной строкой. Если он стабильно высокий — стоит присмотреться к DNS-провайдеру или подключить CDN с собственными быстрыми DNS-серверами.

Почему всё это важнее перелинковки и при чём тут трафик из нейросетей

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

И вот свежий поворот, который мало кто учитывает. Сегодня по сайтам ходят не только классические поисковые роботы, но и краулеры нейросетей — YandexGPT, боты ChatGPT, Perplexity. Они приходят за фактами, чтобы процитировать вас в своих ответах. И ведут себя так же требовательно к серверу: медленный, нестабильный или криво отвечающий сайт они просто пропускают. Серверная гигиена из этих девяти пунктов — это уже не только про позиции в Яндексе, но и про то, попадёте ли вы в выдачу GEO-продвижения, то есть в ответы генеративных систем.

Если вы дочитали досюда и поняли, что половину этих проверок на вашем сайте никто никогда не делал, — у меня для вас хорошая новость и предложение.

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

Если нужен результат, а не отчёт. Я беру профессиональное SEO-продвижение сайта в работу по одному проекту на нишу — без конкуренции с вашими же конкурентами на моей стороне. За двадцать с лишним лет и 300+ проектов у меня ни одного фильтра Яндекса: только белые методы, серверная и техническая база в порядке, рост трафика, который держится, а не схлопывается после первого апдейта. Сюда же входит и GEO-продвижение — вывод вашего бизнеса в ответы YandexGPT, ChatGPT и Perplexity, пока ваши конкуренты ещё даже не поняли, что туда тоже можно попасть.

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