Как удалить устаревшие страницы сайта и настроить SEO-редиректы

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

Как понять, какие страницы пора удалять

На моей практике устаревшие страницы почти никогда не бывают «просто лишними». У одной компании на WordPress было около 18 000 URL, и примерно 4 500 из них уже не приносили трафик, но продолжали висеть в индексе. Часть была с дублями, часть — с архивами старых акций, часть — с товарами, которых не было в наличии больше года. Грубо говоря, это был склад мусора, который мешал поиску видеть нормальные страницы.

Я обычно смотрю на три вещи: трафик из поиска за 6–12 месяцев, количество внешних и внутренних ссылок, а также бизнес-ценность страницы. Если URL не получает переходов, не имеет ссылочного веса и не нужен пользователю, его можно удалить или заменить. Но если страница хоть как-то участвует в воронке — например, собирает заявки на старую услугу, которую вы переупаковали, — однозначно стоит подумать о редиректе, а не о голом удалении.

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

Какие страницы удалять, а какие сохранить

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

Удалять стоит страницы, которые:

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

Оставлять и переадресовывать нужно страницы, которые имеют SEO-вес, ссылочную массу или историю в выдаче. У одного клиента на Bitrix была старая категория с 120 товарами. Половины уже не было, но URL имел 17 внешних ссылок и стабильно приносил 40–60 переходов в месяц. Удалить такое в лоб — это плохая идея. Мы сделали редирект на актуальную категорию и сохранили трафик.

Что выбрать: 301, 410 или 404

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

301 — это перенаправление навсегда. Оно передаёт большую часть накопленного веса и помогает не терять пользователей. Это лучший выбор для смены URL, структуры каталога, переезда на HTTPS или объединения дубликатов. Кстати, если у вас меняется структура разделов, посмотрите как настроить 301 редиректы при смене URL и структуры сайта в 2026 и редиректы 301 без потери SEO-позиций.

410 — это «gone», то есть страница удалена окончательно. Я использую его, когда URL точно не должен возвращаться: старый лендинг акции 2022 года, архив завершённого события, удалённый тестовый раздел. По опыту, поисковики вычищают такие страницы быстрее, чем обычные 404. Но ставить 410 на всё подряд не надо. Это инструмент, а не магическая кнопка.

Как удалить страницы без потери трафика

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

На практике хорошо работает такой порядок:

1. составить список устаревших URL;
2. проверить входящие ссылки и трафик;
3. определить тип замены;
4. настроить редиректы;
5. удалить URL из sitemap;
6. убрать внутренние ссылки;
7. проверить ответ сервера и логи.

И вот здесь часто всплывает технический долг. Сайт вроде бы «всё ещё работает», но в коде уже висят старые шаблоны, древние адреса и костыли из времён PHP 7.4. Если видите такой бардак, это уже не просто SEO-задача, а полноценная доработка сайта с ревизией структуры. На Bitrix и WordPress я нередко сначала чищу маршрутизацию, а потом уже обновляю редиректы.

Настройка SEO-редиректов: nginx, .htaccess и PHP

Техническая реализация зависит от того, на чём у вас сайт. У меня были проекты на nginx + PHP 8.2, на Apache с .htaccess, а также на Laravel с кастомными правилами в middleware. Но логика одна: старый URL должен вести на максимально релевантный новый адрес, а не «куда-нибудь».

Пример для nginx:

location = /staryy-razdel/ {
    return 301 /novyy-razdel/;
}

location = /old-page.html {
    return 410;
}

Если нужен массовый перенос старых страниц на новые по шаблону, можно использовать регулярные выражения. Но тут я советую быть осторожным. Один неверный regex — и вы получите петлю редиректов или отправите половину сайта в 404. На одном проекте на WordPress 6.6 мы так однажды поймали цепочку: старый раздел → новая категория → canonical на старый раздел → снова редирект. Потеряли два дня на диагностику.

Пример для .htaccess:

<IfModule mod_rewrite.c>
RewriteEngine On

Redirect 301 /old-category/ /new-category/
Redirect gone /archive-2021/
</IfModule>

Если редиректы делаются в PHP, например в Laravel, используйте явное перенаправление:

if ($request->path() === 'old-page') {
    return redirect('/new-page', 301);
}

if ($request->path() === 'archive-2021') {
    abort(410);
}

На PHP 8.1–8.3 это работает стабильно, но я всегда проверяю, чтобы редиректы не выполнялись уже после вывода заголовков. Иначе будет знаменитый «headers already sent», а это, грубо говоря, лишняя головная боль из-за одного пробела в шаблоне.

Как не сделать ошибки при массовых редиректах

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

Вторая ошибка — цепочки редиректов. Было у меня на клиентском сайте: /old/ вело на /old2/301, а потом уже на /new/. Итого три запроса вместо одного. Это тормозит загрузку, ухудшает обход робота и иногда бьёт по поведенческим факторам. Если у вас есть такие цепочки, их надо расплющивать в один шаг.

Третья ошибка — редиректы без учёта canonical, sitemap и внутренних ссылок. Если в sitemap остались старые адреса, а в шаблоне хлебных крошек всё ещё висит старый URL, вы сами создаёте поисковику путаницу. Я всегда советую параллельно открыть статью как настроить canonical URL для SEO в 2026 году и свериться с аудитом robots.txt и XML Sitemap на сайте в 2026 году.

Как удалить устаревшие страницы в WordPress, Bitrix и Laravel

На WordPress я обычно сначала ищу, не остались ли старые записи в медиабиблиотеке, таксономиях и архивных шаблонах. Иногда страница уже удалена из админки, а URL продолжает открываться из-за кастомного роутинга или плагина. Если это WP, полезно проверить плагины типа Redirection, Rank Math, Yoast SEO Premium. Но я не люблю завязывать критичные редиректы только на плагин. Для важной структуры лучше держать правила на уровне сервера.

В Bitrix ситуация часто сложнее. Там могут участвовать инфоблоки, ЧПУ, компонентные кеши и старые шаблоны. У одного клиента на Битрикс 24/7 мы чистили 800+ устаревших страниц каталога. Сначала казалось, что надо просто удалить элементы инфоблока. Но потом выяснилось, что часть URL генерируется из старого шаблона, часть — из фильтров, а часть сидит в sitemap.xml. Пришлось делать нормальную ревизию через доработку сайта: что можно улучшить и подключать настройку кеширования в Битрикс, чтобы изменения быстро отразились для пользователей и ботов.

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

Пример таблицы для маппинга редиректов в MySQL 8.0:

CREATE TABLE seo_redirects (
    id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    old_url VARCHAR(255) NOT NULL UNIQUE,
    new_url VARCHAR(255) DEFAULT NULL,
    code SMALLINT UNSIGNED NOT NULL DEFAULT 301,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO seo_redirects (old_url, new_url, code) VALUES
('/old-category/', '/new-category/', 301),
('/archive-2021/', NULL, 410);

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

Что делать после удаления страниц

После удаления работа не заканчивается. На деле начинается самое интересное: проверка индекса, логов, карты сайта и поведения пользователей. Я всегда смотрю, не выросло ли число 404, не появились ли новые цепочки редиректов и не остались ли старые URL в внутренних ссылках. Если вы удалили 200 страниц и не проверили последствия, можно через месяц удивляться падению трафика на 15–20%.

Сначала обновляю XML sitemap и убираю из неё все неактуальные адреса. Затем очищаю кеш сайта и CDN. Если используется Nginx reverse proxy, Redis или Cloudflare, простая смена URL в CMS ещё ничего не значит: старые ответы могут висеть в кеше. У меня был случай на сайте с PHP 8.3 и Nginx, где старый 301 продолжал отдаваться из CDN почти сутки после правки. Поэтому я всегда делаю принудительную очистку кэша и проверяю заголовки через curl.

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

Параллельно проверяю Search Console и Яндекс.Вебмастер. Если страница была удалена правильно, поисковик должен либо увидеть 301 на новый адрес, либо 410/404 для окончательно удалённых URL. И здесь очень помогает мониторинг ошибок. Посмотрите также материал как настроить 404-отчет и мониторинг сломанных URL в 2026 — он хорошо дополняет тему.

Какие инструменты и отчёты использовать

Я обычно использую связку из нескольких источников: Google Search Console, Яндекс.Вебмастер, Screaming Frog, логи Nginx, аналитика и таблица с решениями по каждому URL. Если сайт большой, без этого вообще нечего делать. На 10–20 страницах ещё можно руками, а на 5 000+ URL уже нужен порядок и дисциплина.

Из технических инструментов особенно полезны:

• Screaming Frog или Netpeak Spider — для обхода URL и поиска 3xx/4xx;
• логи сервера — чтобы видеть реальные запросы ботов;
• Google Search Console — для проверки индексации и статуса страниц;
• Яндекс.Вебмастер — для контроля 404 и переобхода;
• curl и browser devtools — для быстрой проверки заголовков;
• таблица редиректов — чтобы не потеряться в правках.

Если вы не уверены, что всё настроено правильно, лучше сначала сделать проверку сайта, а уже потом массово удалять старые разделы. Иногда одна маленькая ошибка в конфиге nginx или в шаблоне CMS стоит дороже, чем час нормального аудита.

Как организовать процесс на будущее

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

На webfull.ru я обычно предлагаю клиентам не только разовую очистку, но и нормальную поддержку: проверка редиректов, контроль 404, корректировка sitemap, ревизия robots.txt, обновление шаблонов ссылок и мониторинг изменений. Иначе через полгода всё возвращается на круги своя. Если нужно сопровождение на постоянке, смотрите поддержка Bitrix или поддержка WordPress — в зависимости от вашей CMS.

И ещё момент. Когда вы удаляете старые страницы, не забывайте про аналитику. Иногда удаление якобы «мусорного» URL неожиданно влияет на лиды. У меня был клиент, который хотел снести архив статей 2020 года. Оказалось, что две статьи стабильно давали заявки через органику. Мы не удалили их, а обновили, переписали заголовки, добавили актуальные блоки и перевели часть URL на новые разделы. Результат был лучше, чем от грубой чистки.

Если нужен расчёт объёма работ, удобно начать с калькулятора стоимости сайта. Он не заменяет нормальный аудит, но помогает быстро понять порядок бюджета, когда вопрос упирается не только в SEO-редиректы, а в полноценную структуру и доработки.

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