Изменение URL-слуга приводит к перенаправлению на главную страницу, появлению ошибки 404 или проблемы с отсутствующим lang_code.

Содержание

Вопрос или проблема
Ответ или решение
Анализ проблемы изменения URL Slug в WordPress
Описание проблемы
Возможные причины проблемы
Рекомендации по предотвращению проблемы в будущем
Заключение
Теги

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

Нам была поручена не полностью настроенная сайт на WordPress, использующий (a) плагин Custom Permalink (b) плагин Poly_lang (c) плагин WP Rocket Pro (без CDN).

Мы заметили, что слаги многих страниц на рабочем сайте отличались от слагов на тестовом сайте. Нам нужно было привести их в соответствие с тестовыми (поскольку они уже имели SEO-рейтинги).

Однако вскоре стало очевидно, что многие страницы просто не получали слаги с тестового сайта. После изменения слага, при попытке посетить страницу: (a) WordPress перенаправлял их на главную страницу (b) показывал ошибку 404 (c) отсутствовал lang_code в их адресе.

Еще одной загадкой является то, что это происходило на некоторых страницах, а некоторые страницы легко меняли свои слаги. Мы попытались удалить страницу (для всех языков), а затем создать её снова с нуля; это сработало для некоторых страниц, а некоторые все еще не могли изменить свои слаги. Более того, этот подход волшебным образом сработал, если мы удалили страницы два или три раза, а затем воссоздали их. Но все же для некоторых страниц даже воссоздание трижды не сработало.

Мы исчерпали все идеи. И сегодня проблема исчезла автоматически. У нас нет уверенного представления о том, как! Теперь я могу изменять слаги, и WordPress сохраняет их. Если этого не происходит, я возвращаюсь в панель редактирования, пишу правильный слаг снова и сохраняю его снова. И это работает на данный момент.

Мой вопрос: как могла возникнуть вся эта неразбериха? Что могло её вызвать? Что я могу сделать, чтобы убедиться, что это не произойдет на любом сайте, который я разрабатываю? Или если такая проблема возникнет снова, что я могу сделать?

Правка:
Нам пришлось изменить wp_settings > структуру постоянных ссылок на ‘настраиваемые постоянные ссылки’ (чтобы соответствовать тестовому сайту). И это могло быть причиной, по которой проблема была исправлена. Но мы не уверены.

Также, есть ли какой-либо способ зарегистрировать все события, происходящие в WordPress, чтобы увидеть, что именно делается и кем? Я использовал плагин ‘Stream’, но он только записывает, что страница была отредактирована или какие-то общие вещи были изменены. Но он не сообщает, что именно было отредактировано или какая опция была изменена.

Правка2:
Я уже пробовал и тестировал:

обновление темы/плагина/WP
очистка кеша (wp rocket, браузер) обоих
воссоздание .htaccess
постоянные ссылки сохранены (без изменения настроек. это ранее было сделано 100 раз)

Правка3:
Вау, это стал длинный вопрос. Пожалуйста, не стесняйтесь комментировать, как я мог объяснить ситуацию более короткими словами (если это возможно). Также являются ли теги, которые я указал, наиболее подходящими для этой ситуации.

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

Анализ проблемы изменения URL Slug в WordPress

Давайте подробно рассмотрим возникшую проблему изменения URL slug на вашей WordPress-программе с учетом всех предоставленных вами деталей.

Описание проблемы

Изменение Slug: У вас возникла необходимость изменить слаги страниц на производственном сайте, чтобы они соответствовали слажам на тестовом сайте, который имел более высокий SEO-рейтиг.
Симптомы проблемы:
- Перенаправление на главную страницу.
- Ошибка 404 (страница не найдена).
- Проблемы с отсутствующим lang_code в адресе.
Неоднородность поведения: Некоторые страницы позволяли изменять свои слоги, тогда как другие упорно вызывали вышеописанные ошибки.
Методы решения:
- Удаление и пересоздание страниц не всегда решало проблему, иногда требовалось делать это несколько раз.
Неожиданное разрешение: Проблема исчезла сама по себе, и вы смогли успешно изменять слаги страниц.

Возможные причины проблемы

Конфликт плагинов: Использование нескольких плагинов (например, Custom Permalink, Poly_lang и WP Rocket Pro) может привести к конфликтам. Особенно в случае, если разные плагины по-разному обрабатывают слаги и маршрутизацию URL.
Настройки постоянных ссылок: Изменения в структуре постоянных ссылок (например, переключение на "пользовательские ссылки") могут вызвать проблемы с кэшированием и перенаправлениями.
Кэширование: Плагин WP Rocket может кэшировать старые URL. Если кэш не очищается, даже после изменения слага, старое перенаправление будет продолжать действовать.
Языковые настройки: Отсутствие lang_code в адресе может указывать на то, что система языков (Poly_lang) неправильно настроена для некоторых страниц или языков. Это может привести к проблемам с определением языка URL.
Ошибки в базе данных: Если в базе данных были нарушения целостности, это также могло повлиять на обновление слага.
Прогрессивные изменения настроек: Вы упомянули, что настройки wp_settings > permalink structure были изменены. Это могло повлиять на восстановление нормальной работы.

Заключение

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

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

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