Почему WordPress перенаправляет на сообщения на основе слага?

Содержание

Вопрос или проблема
Ответ или решение
Теория (Theory)
Пример (Example)
Применение (Application)

Вопрос или проблема

У нас есть сайт на WordPress со структурой постоянных ссылок, выглядящей следующим образом:

news/%year%/%monthnum%/%day%/%postname%/

Сегодня я заметил, что если попытаться зайти на несуществующую страницу, WordPress, кажется, подтягивает первую (?) публикацию, которая частично соответствует этому слагу.

Например:

реально: /news/2025/02/15/story-name

это допустимая страница публикации. Но если пользователь пытается зайти на

не реально: /some/page/that/does/not/exist/story-name

Она перенаправится на “реальную страницу”, потому что слаг совпадает. Более того, это произойдет даже при частичном совпадении, например:

не реально: /some/page/that/does/not/exist/story

Это не то поведение, которого я хочу. Я заметил это, потому что пытался использовать действие template_redirect для перехвата и перенаправления некоторых устаревших URL. Один из таких устаревших URL оканчивается на story, и это перенаправление происходило. Казалось, это происходило до действия template_redirect.

Что здесь происходит и как заставить WordPress подчиниться моей воле?

Ответ или решение

Ваша ситуация с WordPress, при которой сайт автоматически перенаправляет на посты, основываясь на совпадении части slug, является довольно распространенной и может быть объяснена особенностями работы системы пермалинков WordPress и поведения ядра при обработке запросов.

Теория (Theory)

WordPress использует довольно сложную систему обработки URL-запросов, чтобы связать входящие URL с конкретными страницами, постами, категориями или любым другим типом контента. Эта система называется "пермалинками" и управляется через функции, такие как rewrite_rules и WP_Query.

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

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

Пример (Example)

Допустим, у вас есть пост с URL /news/2025/02/15/story-name. Если пользователь по ошибке вводит URL /some/page/that/does/not/exist/story-name, WordPress по умолчанию попытается найти контент, который лучше всего соответствует введенной части slug, т.е. "story-name". Даже если URL отличается, WordPress продолжит искать наиболее полное совпадение по slug и может в итоге перенаправить на существующий контент с похожим названием.

Аналогичная логика применяется и для частичного slug, как в случае /some/page/that/does/not/exist/story, где система будет стараться найти первое наиболее соответствующее совпадение.

Применение (Application)

Для управления подобным поведением или его изменения можно использовать несколько подходов:

Настройка rewrite правил. Вы можете отключить или изменить существующие rewrite правила, чтобы они более строго соответствовали необходимым URL структурам. Это можно сделать с помощью фильтра rewrite_rules_array, чтобы добавить или изменить правила под свои нужды.
Использование плагинов. Существуют плагины, которые предоставляют более точное управление процессом обработки URL. Они могут помочь избежать перенаправлений по частичным совпадениям.
Кастомизация логики обработчика запросов. С помощью фильтра request можно изменить параметры запроса, который формирует WP_Query. Это позволит задать более строгую логику для поиска и обработки запросов.
Частичное отключение функции для автоподбора. Для контроля над поведением WordPress, касающегося URL, можно опираться на фильтры и действия такие, как template_redirect и непосредственно настраивать их так, чтобы они обрабатывали только те URLs, которые вам необходимы.
Создание пользовательского 404 шаблона. В случае, если вы хотите просто отображать пользователю ошибку о ненахождении страницы, наиболее верным решением будет создание собственного файла 404.php в теме, где вы самостоятельно зададите, что отображать пользователю на несуществующих страницах.

В вашем конкретном случае, вам вероятно понадобится объединить несколько данных методов, чтобы эффективно обрабатывать как существующие URL, так и работать с унаследованными, которые могут приводить к нежелательным перенаправлениям. Попробуйте заменить или дополнить фильтры и rewrite правила таким образом, чтобы URL-адреса сначала проверялись на полное совпадение перед применением логики автоподбора WordPress. Как часть данного процесса, обязательно протестируйте изменения на тестовом сервере перед деплоем на рабочем сайте.

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