200 OK: зачем нужно, как проверить и настроить для SEO

200 OK — это HTTP-статус успешного запроса. Когда браузер, поисковый робот или другой клиент запрашивает обычную страницу сайта методом GET, сервер с ответом 200 сообщает: запрос обработан, а в теле ответа находится представление запрошенного ресурса.

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

Поэтому при техническом аудите проверяют не только наличие 200 OK, но и соответствие статуса реальному состоянию URL.

Что на самом деле означает HTTP-статус 200 OK

HTTP-статус — часть ответа сервера. Сначала клиент отправляет запрос, затем получает строку состояния, заголовки и, если это предусмотрено запросом, содержимое.

Упрощённо нормальный ответ страницы выглядит так:

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: ...
...

После заголовков передаётся HTML страницы.

По стандарту HTTP код 200 означает, что запрос выполнен успешно. Точное значение зависит от метода запроса. Для GET сервер передаёт представление ресурса, для HEAD — те же заголовки без тела ответа. Поэтому фраза «200 означает, что сайт работает» слишком грубая: статус относится к конкретному запросу и конкретному URL.

Например:

Ситуация	Ожидаемое поведение
Рабочая статья существует по запрошенному URL	200 OK
Страница навсегда переехала	постоянный 301 или 308 на новый URL
URL временно ведёт в другое место	временный 302 или 307
Ресурс не существует	404 Not Found
Ресурс удалён окончательно и это нужно явно показать	410 Gone
Доступ к ресурсу запрещён	403 Forbidden
Сайт временно недоступен из-за обслуживания	обычно 503 Service Unavailable

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

Когда для SEO нужен именно 200 OK

Для Google успешный ответ страницы — одно из минимальных технических условий её обработки. Если Googlebot получает нормальный 200, содержимое ответа может перейти к следующим этапам обработки и индексирования.

Однако 200 OK не является командой «добавить страницу в индекс». После получения ответа поисковая система ещё анализирует содержимое, доступность ресурсов, директивы индексирования, дубли и канонические версии.

Отсюда полезное правило: 200 должен отвечать на вопрос «ресурс действительно доступен?», а не «хочу ли я видеть эту страницу в поиске?».

Например, опубликованная статья с noindex вполне может корректно отвечать 200. Сервер сообщает, что ресурс существует, а директива noindex отдельно управляет индексированием. И наоборот, попытка сделать несуществующую страницу «доступной для SEO» с помощью принудительного 200 не превращает её в полезный документ.

То же касается переноса. Если старый адрес больше не является самостоятельным ресурсом, оставлять на нём 200 только потому, что этот код считается успешным, неправильно. Сервер должен сообщить о переносе редиректом, а уже конечный URL вернуть 200.

При технической проверке полезно разделять три независимых вопроса:

1. Какой HTTP-статус получает клиент?
2. Какое содержимое фактически приходит или рендерится?
3. Должен ли этот URL индексироваться?

Только совпадение этих трёх уровней даёт предсказуемое поведение.

Главная проблема: страница выглядит ошибкой, но отвечает 200

Наиболее опасный для диагностики случай — soft 404.

Представим URL:

https://example.com/catalog/tovar-kotorogo-net/

Товар удалён. Пользователь открывает страницу и видит:

Товар не найден.

Но сервер отвечает:

HTTP/2 200

Для HTTP это успешный ресурс. По смыслу страницы — ошибка.

Google прямо рассматривает подобные случаи как потенциальный soft 404: URL возвращает 200, но содержимое говорит, что нужной страницы нет, оказывается пустым или выглядит как ошибка.

Такое возникает не только на карточках товаров. Частые сценарии:

• внутренний поиск возвращает 200 для пустой выдачи;
• WordPress-тема показывает 404.php, но сторонний код уже принудительно отправил 200;
• приложение выводит «объект не найден» внутри обычного шаблона;
• сервер при любой неизвестной URL отдаёт главную страницу;
• SPA обрабатывает неизвестный маршрут только на стороне JavaScript;
• ошибка базы данных или API превращает страницу в пустой шаблон, но HTTP-статус остаётся успешным.

Почему soft 404 нельзя исправить косметически

Замена текста «ничего не найдено» на более красивую заглушку не исправляет серверную семантику.

Сначала нужно решить, что URL представляет собой в реальности.

Если страницы никогда не существовало или ресурс удалён без подходящей замены — нужен настоящий 404 или, в подходящих случаях, 410.

Если материал перенесён — нужен редирект на соответствующую страницу.

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

Именно поэтому массовая настройка «всегда отдавать 200, чтобы поисковик видел сайт» вредна. Она скрывает реальные состояния URL.

Как проверить 200 OK: браузера недостаточно

Открыть страницу в Chrome и увидеть привычный дизайн — не проверка HTTP-статуса. Пользователь может попасть на страницу через цепочку редиректов, а красивый шаблон ошибки может выглядеть как обычный документ.

Для первичной серверной проверки удобен curl.

Посмотреть заголовки:

curl -I https://example.com/page/

В начале ответа будет строка состояния:

HTTP/2 200

Если нужен только итоговый код:

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/page/

Для SEO-аудита важно сначала проверить исходный URL без автоматического следования редиректам. Иначе можно увидеть 200 конечной страницы и пропустить, что первоначальный адрес отвечает 301, 302 или другим кодом.

Цепочку переходов можно исследовать отдельно:

curl -I -L https://example.com/old-page/

Если есть подозрение, что сервер по-разному обрабатывает HEAD и обычный GET, полезно проверить GET-запрос без сохранения тела:

curl -sS -o /dev/null -D - https://example.com/page/

Такой тест особенно полезен для CDN, собственных прокси, приложений и нестандартных конфигураций.

Проверяйте не одну страницу, а контрольную пару

Самый быстрый способ поймать ложный 200 — сравнить существующий URL с заведомо вымышленным.

Например:

curl -s -o /dev/null -w "%{http_code}\n" \
https://example.com/real-page/

и:

curl -s -o /dev/null -w "%{http_code}\n" \
https://example.com/__test-page-does-not-exist-92841/

Если оба запроса возвращают 200, это повод проверить маршрутизацию, CMS и фактическое содержимое второго ответа.

Не нужно использовать для проверки популярный старый slug: он может неожиданно иметь редирект или существовать в CMS. Лучше сформировать уникальный путь, которого точно нет.

Проверка через Google Search Console: что видит сам Google

Серверный curl отвечает на вопрос, что получил ваш клиент прямо сейчас. Для SEO дополнительно полезна проверка URL в Google Search Console.

У инструмента проверки URL есть два разных контекста: данные о версии, которую Google уже знает из индекса, и Live Test текущего URL. При диагностике недавно исправленной ошибки важен именно тест актуальной версии.

В деталях проверки можно посмотреть сведения о доступности страницы и HTTP-ответе. Это помогает обнаружить ситуацию, когда локально URL работает, а Google получает другое поведение из-за CDN, защиты от ботов, географических правил, firewall или серверной логики.

Положительный Live Test всё равно не означает автоматическую индексацию. Он подтверждает техническую доступность в рамках проверяемых условий, но не заменяет решение систем индексирования.

Поэтому последовательность диагностики удобнее строить так:

curl → содержимое страницы → Live Test → индексированный статус.

Если цель аудита шире одного URL, к серверным кодам уже добавляют логи обхода, отчёты индексирования и производительность страниц. Например, core web vitals проверить сайт имеет смысл как отдельный уровень технического анализа, но метрики скорости не исправят URL, который возвращает неправильный HTTP-статус.

Что делать с 301, 403, 404 и другими кодами вместо 200

Ошибка аудита — пытаться превратить любой ответ в 200.

301 вместо 200

Если URL навсегда перенесён, постоянный редирект сообщает клиентам и поисковым системам новый адрес ресурса. В такой ситуации старый URL не обязан отвечать 200.

Проверять нужно пару:

старый URL → 301 → новый URL → 200

Если после перехода начинается длинная цепочка 301 → 302 → 301 → 200, её уже стоит разбирать отдельно.

403 Forbidden вместо 200

403 Forbidden означает, что сервер понял запрос, но доступ не разрешает. Для закрытой области это может быть абсолютно корректным ответом.

Проблема появляется, если 403 получает публичная SEO-страница или только поисковый робот. Тогда проверяют firewall, WAF, CDN, ограничения по User-Agent, IP, rate limit и правила безопасности.

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

404 вместо 200

404 Not Found нужен, когда запрошенного ресурса нет. Наличие красивого фирменного шаблона ошибки никак не отменяет необходимость правильного серверного кода.

Полезная 404-страница может содержать меню, поиск и ссылки на основные разделы, но её HTTP-ответ всё равно должен оставаться 404.

503 вместо 200

При кратковременном техническом обслуживании серверу не следует показывать поисковому роботу обычную заглушку с 200. Для временной недоступности существует 503 Service Unavailable.

То есть правильная настройка кодов ответа — это не стремление получить максимум 200, а однозначная модель состояния сайта.

Где ломается 200 OK на Nginx и WordPress

В нормальной конфигурации код ответа формируется совместной работой веб-сервера и приложения. Поэтому искать проблему только в .htaccess, только в теме WordPress или только в Nginx неправильно — нужно определить уровень, на котором статус стал неверным.

Nginx

Для обычных статических файлов Nginx умеет завершить обработку настоящим 404, если ресурс не найден:

location / {
    try_files $uri $uri/ =404;
}

Для WordPress распространена другая логика: если физического файла или каталога нет, запрос передаётся в index.php, а уже WordPress решает, существует ли запрошенная сущность:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Это важное различие. В WordPress неизвестный красивый URL не должен автоматически превращаться в серверный 404 до запуска CMS, иначе перестанут работать постоянные ссылки. Но после обработки запроса WordPress обязан сформировать корректное состояние.

Опасный вариант — безусловная конструкция уровня:

return 200;

или кастомный error_page, после которого внешний ответ непреднамеренно становится успешным. Любую подобную настройку нужно оценивать в контексте конкретного server и location, а не копировать фрагмент конфигурации отдельно.

После изменения Nginx сначала проверяют синтаксис:

sudo nginx -t

и только после успешной проверки применяют конфигурацию предусмотренным на сервере способом.

WordPress

У WordPress есть собственная обработка состояния запроса. После выполнения основного запроса ядро определяет, найден ли соответствующий объект, и для отсутствующего ресурса может выставить 404; для нормальной найденной страницы — 200.

Поэтому стандартный WordPress обычно не требует вручную прописывать 200 OK для каждой записи.

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

Если разработчик действительно создаёт собственную обработку отсутствующего ресурса, WordPress предоставляет функцию:

status_header( 404 );

Но вставлять её глобально в functions.php нельзя. Код должен выполняться только в той ветке, где приложение достоверно определило отсутствие ресурса.

При диагностике полезно временно отключить подозрительный слой — кастомный роут, SEO-плагин, кеширование, reverse proxy — и проверить, на каком этапе ответ меняется. Это быстрее, чем пытаться маскировать результат ещё одним заголовком поверх предыдущего.

Практический сценарий: WordPress показывает 404, но сервер возвращает 200

Допустим, после обновления темы в Search Console начали появляться soft 404.

Есть рабочая статья:

/articles/seo-audit/

и несуществующий адрес:

/articles/seo-audit-removed-92841/

Первый URL проверяем:

curl -s -o /dev/null -w "%{http_code}\n" \
https://example.com/articles/seo-audit/

Результат:

200

Второй:

curl -s -o /dev/null -w "%{http_code}\n" \
https://example.com/articles/seo-audit-removed-92841/

И неожиданно получаем:

200

В браузере второй адрес показывает шаблон «Страница не найдена». Значит проблема уже локализована: внешний HTTP-ответ не соответствует содержимому.

Дальше имеет смысл проверить сам HTML:

curl -s https://example.com/articles/seo-audit-removed-92841/ | head

затем исключить кеш/CDN и проверить ответ непосредственно на origin, если инфраструктура это позволяет.

На WordPress-сайте после этого проверяют:

• не отправляет ли тема собственный 200;
• не перехватывает ли неизвестные URL плагин;
• не подменяет ли CDN ошибку успешным кешированным документом;
• корректно ли WordPress распознаёт запрос как is_404();
• нет ли серверного правила, которое переписывает код ответа после PHP.

После устранения причины повторный curl для несуществующего URL должен показать:

404

а существующая статья по-прежнему:

200

Только после серверной проверки есть смысл перепроверить исправленный URL через Live Test в Search Console. Если сразу перейти к кнопке запроса индексирования, не убедившись в реальном статусе, можно просто повторно отправить поисковику ту же техническую ошибку.

Как оценить результат после исправления

Корректность 200 OK лучше проверять не одной цифрой, а небольшим набором контрольных URL.

Возьмите:

• несколько рабочих статей и страниц;
• URL с постоянным редиректом;
• заведомо отсутствующий URL;
• удалённую страницу без замены, если такая есть;
• закрытый служебный URL, если его статус входит в аудит.

Для каждого адреса зафиксируйте первый HTTP-ответ, конечный URL после редиректов и фактическое содержимое.

У рабочего документа должно выполняться простое соответствие: ресурс существует → сервер возвращает 200 → пользователь получает нужный контент.

Для отсутствующего: ресурса нет → сервер возвращает 404 или уместный 410 → шаблон страницы честно сообщает об отсутствии.

Для перенесённого: старый URL возвращает редирект → конечная страница существует → конечная страница отвечает 200.

Такой тест надёжнее правила «все важные URL должны иметь зелёный 200», потому что техническое SEO требует не максимального числа успешных ответов, а правильной семантики HTTP.

200 OK — хороший статус только там, где запрос действительно завершился получением существующего ресурса. Если это условие выполняется, код не нужно «оптимизировать» дальше. Если не выполняется, следует исправлять реальное состояние страницы, маршрутизацию или серверную конфигурацию, а не просто подменять цифру в заголовке.