Если в WordPress накопились старые URL, которые уже не существуют, но продолжают всплывать в логах, Search Console или в отчётах краулера, проблема обычно не в одном «битом» адресе. Чаще это хвост из удалённых записей, неверных внутренних ссылок, старых вложений и страниц, которые когда-то были доступны, а теперь отдают 404. Сам по себе 404 — нормальный ответ, но когда таких URL много, они засоряют обход, создают лишние сигналы и мешают понять, что реально важно для индексации.
Ниже — рабочая схема: как найти источник, что закрывать редиректом, что оставлять 404, а что лучше отдать 410 Gone. Это не про «ускорить SEO магией», а про чистку сайта без лишних побочных эффектов.
Когда проблема действительно есть
Не каждый 404 требует вмешательства. Если это единичный старый адрес из внешней ссылки, его можно оставить как есть. Но если в отчётах повторяются десятки или сотни URL с одинаковым паттерном, стоит разбираться.
Типичные признаки
- в Google Search Console растёт список «Не найдено (404)»;
- краулер находит старые URL с одинаковыми шаблонами, например
/tag/,/author/, удалённые вложения, старые слаги записей; - в логах сервера много запросов к несуществующим страницам;
- внутренние ссылки на сайте ведут на удалённые материалы;
- после миграции или смены структуры URL остались старые адреса без редиректов.
Что считать нормой, а что — мусором
Нормальный 404 — это единичный запрос к странице, которой больше нет, без повторяющегося паттерна. Мусор — это когда поисковик или пользователи регулярно ходят по несуществующим URL, а сайт отвечает одинаково и ничего не объясняет. В таком случае задача не «убрать 404 любой ценой», а правильно разрулить судьбу каждого типа адресов.
Диагностика: откуда берутся битые URL
Перед исправлением важно понять источник. Иначе можно поставить редирект на один адрес, а через неделю получить ещё десять таких же из другого места.
Проверка через Search Console и краулер
Сначала выгрузите список проблемных URL из Search Console или из любого краулера вроде Screaming Frog. Смотрите не только на сами адреса, но и на шаблон: это старые записи, вложения, категории, параметры, пагинация или что-то из темы/плагина.
Проверка внутренних ссылок
Если URL встречается внутри сайта, его лучше исправить в исходном контенте, а не лечить редиректом. Для этого удобно пройтись по базе поиска по старому слагу или использовать поиск по контенту в админке, если сайт небольшой.
// Пример: найти упоминания старого слага в базе через WP-CLI
wp db search 'old-post-slug' --all-tablesКоманда не чинит проблему, но быстро показывает, где ещё остались ссылки или упоминания. Если WP-CLI недоступен, можно искать в редакторе записей, меню, виджетах и шаблонах.
Что делать с каждым типом URL
Здесь важна логика. Не все удалённые страницы должны вести на главную. И не каждый старый адрес нужно перенаправлять 301.
| Ситуация | Что делать | Компромисс |
|---|---|---|
| Страница переехала на новый URL | 301 редирект на новый адрес | Сохраняет переход и сигнал для поисковика |
| Материал удалён окончательно | 410 Gone или 404 | 410 быстрее показывает, что URL больше не вернётся |
| Внутренняя ссылка ведёт на несуществующую страницу | Исправить ссылку в контенте | Редирект не должен маскировать ошибку в редактуре |
| Старые вложения без ценности | Отключить индексацию вложений или закрыть их корректно | Не плодить тонкие страницы |
Когда нужен 301
301 ставят только если есть понятная замена. Например, статья переехала на новый слаг, а старая категория была переименована. Если редиректить всё подряд на главную, поисковик быстро поймёт, что это не релевантная замена, а пользователь получит плохой опыт.
Когда лучше 410
410 полезен для страниц, которые удалены окончательно и не должны возвращаться. Это честнее, чем бесконечно держать 404. Для поисковых систем такой ответ обычно сигнализирует, что URL можно быстрее убрать из обхода.
Пошаговое решение: как закрыть мусорные URL
Ниже — последовательность, которая не ломает сайт и не создаёт лишних редирект-цепочек.
Шаг 1. Исправьте внутренние ссылки
Если старый URL встречается в меню, тексте, блоках или шаблонах, замените его на актуальный. Это самый надёжный вариант: поисковик и пользователь сразу попадают куда нужно, без промежуточных ответов.
Шаг 2. Настройте редиректы только там, где есть замена
Для точечных редиректов можно использовать плагин редиректов или код в .htaccess / конфиге Nginx. Если URL немного, код часто надёжнее: меньше зависимостей и меньше шансов, что плагин начнёт конфликтовать с кэшем или другим SEO-модулем.
Redirect 301 /old-post/ https://example.com/new-post/Если сервер Nginx, правило обычно задают в конфигурации сайта, а не в .htaccess. Сам принцип тот же: старый адрес должен вести на новый без цепочки из нескольких переходов.
Шаг 3. Для окончательно удалённых URL отдайте 410
В WordPress это можно сделать через template_redirect, если нужно точечно закрыть конкретный набор адресов. Ниже пример для одного старого слага:
add_action('template_redirect', function () {
if (is_404()) {
$request_uri = isset($_SERVER['REQUEST_URI']) ? $_SERVER['REQUEST_URI'] : '';
if (strpos($request_uri, '/old-post/') !== false) {
status_header(410);
nocache_headers();
exit;
}
}
});Этот вариант стоит использовать аккуратно и только для понятных случаев. Если список большой, лучше решать на уровне сервера или через специализированный плагин редиректов, чтобы не нагружать фронтенд лишней логикой.
Шаг 4. Уберите индексируемые вложения, если они не нужны
Отдельная проблема — страницы вложений. Они часто создаются автоматически, но не несут ценности и только плодят тонкие URL. Если вложения не используются как самостоятельные страницы, их лучше перенаправлять на файл или на родительскую запись, либо закрывать от индексации в зависимости от структуры сайта.
Проверка результата после внедрения
После правок не ограничивайтесь открытием пары URL в браузере. Нужно проверить ответ сервера и отсутствие цепочек.
Что проверить вручную
- старый URL отдаёт 301, если есть новая страница;
- удалённый URL отдаёт 410 или 404, если замены нет;
- новый URL открывается напрямую без промежуточных переходов;
- внутренние ссылки больше не ведут на старый адрес;
- страница не попала в бесконечный редирект.
Проверка через curl
curl -I https://example.com/old-post/
curl -I https://example.com/new-post/В ответе смотрите на код статуса и заголовок Location. Для 301 должен быть один понятный переход, без цепочки из нескольких адресов. Для 410 заголовок редиректа отсутствует, а статус явно говорит о том, что страница удалена.
Проверка в Search Console
После исправлений не ждите мгновенного обновления отчётов. Поисковик должен заново обойти URL. Но если редиректы и коды ответа настроены правильно, список ошибок начнёт сокращаться, а новые 404 не будут появляться из-за внутренних ссылок.
Частые ошибки и как их исправить
Здесь обычно и теряется время: проблема вроде бы решена, но сайт продолжает генерировать мусорные запросы.
Редирект всех удалённых страниц на главную
Это плохая практика. Пользователь получает нерелевантную страницу, а поисковик видит слабую замену. Если страницы реально нет, лучше 404 или 410. Редирект нужен только при наличии близкой и логичной альтернативы.
Цепочки редиректов
Старый URL ведёт на промежуточный, потом ещё на один, и только потом на конечный адрес. Это лишняя задержка и лишняя нагрузка. Исправляйте правило так, чтобы старый адрес сразу вёл на финальный.
Редиректы на уровне плагина и сервера одновременно
Если одно правило прописано в плагине, а другое — в конфиге сервера, легко получить конфликт. В итоге один и тот же URL может вести по разным маршрутам в зависимости от порядка обработки. Для критичных правил оставляйте один источник истины.
Игнорирование внутренних ссылок
Если в тексте статьи или в меню осталась ссылка на удалённую страницу, редирект лишь маскирует ошибку. Исправляйте источник, иначе мусор будет возвращаться после каждого обновления контента.
Безопасность и производительность
Массовые редиректы и обработка 404 могут влиять на производительность, особенно если логика написана в теме и срабатывает на каждом запросе. Если сайт большой, не стоит держать сложные проверки в functions.php без необходимости.
Что лучше делать на стороне сервера
Если у вас много однотипных старых URL, правила редиректа лучше вынести в конфигурацию веб-сервера или использовать проверенный плагин, который не создаёт лишнюю нагрузку на PHP. Код в теме подходит для точечных случаев, но не для сотен правил.
Когда уместен плагин
Если редиректы часто меняются редакторами, удобнее использовать плагин с журналом переходов и понятным интерфейсом. Но следите, чтобы он не дублировал логику SEO-плагина и не создавал две параллельные системы управления URL.
Если нужен более широкий набор инструментов для чистки сайта, дублей и технической оптимизации, можно посмотреть Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но даже с таким плагином базовая логика остаётся прежней: сначала диагностика, потом точечная правка, потом проверка ответа сервера.
Мини-чек-лист перед публикацией правок
- старые URL собраны и сгруппированы по типам;
- внутренние ссылки исправлены в контенте и меню;
- для переехавших страниц настроен 301;
- для удалённых страниц выбран 404 или 410 без лишних редиректов;
- нет цепочек и петель;
- curl показывает ожидаемый код ответа;
- новые ошибки не появляются после повторного обхода сайта.
Если после чистки 404 всё равно растут, проблема обычно не в самих ошибках, а в источнике ссылок: старый шаблон, неактуальная карта сайта, импортированный контент или внешние ссылки из старых публикаций. Тогда нужно идти не от ответа сервера, а от того, кто продолжает генерировать запросы.