Как изменить URL в MODX: окончания, вложенность и 301-редиректы

Эта инструкция нужна, если у сайта уже есть страницы и вы хотите изменить их адреса: убрать .html, переименовать страницу или раздел, перейти от вложенных URL к плоским либо наоборот.

Для нового сайта формат адресов выбирается в уроке по настройке ЧПУ. Здесь разберем другой сценарий: изменение существующих URL с сохранением доступа по старым ссылкам.

В качестве инструмента управления перенаправлениями используем easyRedirects. Он работает в MODX 2 и MODX 3, позволяет создавать точные правила, использовать регулярные выражения и выполнять пакетный импорт.

Когда действительно нужно менять URL

Не меняйте работающие адреса только потому, что вариант без .html выглядит аккуратнее. Само изменение окончания не гарантирует роста позиций.

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

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

Формы, API и другие запросы с передачей данных рассматриваются отдельно. Не распространяйте правила обычных страниц на все служебные адреса.

Что подготовить перед изменениями

Перед работой сохраните файлы и базу данных. Подготовьте список старых адресов, план новых URL и возможность возврата. Массовые изменения сначала проверьте на отдельной копии сайта.

1. Запишите текущие значения use_alias_path, container_suffix и расширения типа содержимого HTML.
2. Сохраните конфигурацию веб-сервера и существующие правила редиректов.
3. Получите список URI ресурсов до изменения.
4. Дополните его адресами из sitemap, обхода сайта, статистики и внешних размещений.
5. Отдельно отметьте замороженные URI, дополнительные контексты и виртуальные страницы.
6. Определите, какие страницы сохраняются, объединяются или удаляются.

В примерах ниже используется один сайт с основным контекстом web. Для нескольких доменов и контекстов с одинаковыми путями отдельно проверяйте, к какому сайту применяется правило. Не предполагается, что компонент автоматически разделяет правила по доменам.

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

Устанавливаем easyRedirects

Откройте менеджер пакетов, переключитесь на modstore.pro и найдите easyRedirects.

Карточка компонента: easyRedirects на modstore.pro. Проверьте выбранную версию, загрузите пакет и установите его.

После установки откройте «Пакеты» → «easyRedirects». Здесь находятся правила перенаправлений и их статистика.

В текущем описании компонента заявлены:

• Точные правила для отдельных путей.
• Регулярные выражения с подстановками.
• Коды 301, 302, 307 и 308.
• Метки правил.
• Статистика срабатываний.
• Отслеживание изменения URI редактируемого ресурса.
• Пакетный импорт из текста CSV.

Документация находится на docs.modx.pro.

Как создать точное правило

Допустим, страница раньше открывалась по адресу /o-kompanii.html, а после изменения — по /o-kompanii.

1. Откройте раздел easyRedirects.
2. Создайте новое правило.
3. В исходном URL укажите o-kompanii.html.
4. В цели укажите o-kompanii.
5. Для постоянного перехода выберите 301.
6. Если используете метки, задайте понятную метку этой миграции.
7. Сохраните правило и проверьте переход.

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

Новый адрес должен быть доступен до того, как посетители начнут переходить на него. На рабочем сайте согласуйте смену URI и включение правил в рамках одной операции.

Во время тестирования можно использовать временный код 302, а после проверки постоянной миграции — 301. Не оставляйте постоянный переход обозначенным как временный без причины.

Почему правило может не срабатывать

easyRedirects обрабатывает событие OnPageNotFound. Если старый адрес продолжает открывать существующий ресурс, событие не наступит.

Также запрос должен дойти до MODX. Реальный файл или ответ, обработанный веб-сервером раньше, может не попасть в компонент.

Исходный путь сравнивается без query-параметров. Поэтому этот механизм нельзя считать готовым способом перенаправления разных запросов index.php?id=....

Для таких случаев используются соответствующие настройки CMS или серверные правила. Не добавляйте в таблицу десятки одинаковых путей, различающихся только параметром id, в надежде, что easyRedirects их различит.

Сценарий 1. Убираем .html у существующих страниц

До изменения сохраните текущие URI. Не рассчитывайте, что плагин восстановит прежние значения после того, как они уже изменены.

1. Откройте «Содержимое» → «Типы содержимого».
2. Найдите тип HTML.
3. Удалите .html из поля расширения файла.
   
4. Обновите URI ресурсов через соответствующее действие меню «Управление».
5. Выполните штатную очистку кеша.

MIME-тип text/html менять не нужно. Не удаляйте расширения у XML, CSS и других типов содержимого.

Суффикс контейнеров задается отдельно. Если раздел открывается как /uslugi/, его завершающий слеш не нужно менять вместе с .html обычных страниц.

Проверьте новый адрес напрямую:

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

Сценарий 2. Меняем псевдоним одной страницы

Если меняется одна страница, можно использовать автоматическое отслеживание.

1. В системных настройках найдите easyredirects_track.
2. Включите ее до изменения ресурса.
3. Запишите старый URI.
4. Откройте ресурс, измените псевдоним и сохраните.
5. Проверьте появление правила в easyRedirects.
6. Проверьте его код, назначение и реальный переход со старого URL.

Например:

Старый URI: company
Новый URI:  o-kompanii

Проверьте, что новое правило соответствует постоянному изменению. Автоматическое создание записи не заменяет проверку результата.

Ограничение для родительских разделов

Автоотслеживание не учитывает изменение адресов дочерних страниц. Если переименовали раздел с потомками, проверьте не только его собственный URL.

Например, изменение catalog на products может затронуть:

catalog/
catalog/item-a
catalog/item-b

Для всего набора используйте карту URI или проверенное правило раздела. Не считайте easyredirects_track универсальной автоматизацией массового обновления.

Сценарий 3. Меняем вложенность адресов

Настройка use_alias_path определяет, включаются ли псевдонимы родителей в путь ресурса:

• Да — вложенная структура, например /uslugi/remont.
• Нет — плоская структура, например /remont.

Включение или отключение может затронуть множество ресурсов. Сначала выполните изменение на копии сайта и сравните старые и новые URI.

Перед отключением проверьте совпадающие псевдонимы

При вложенной структуре могут существовать:

/uslugi/remont
/portfolio/remont

Их нельзя без проверки превратить в один адрес /remont. Сначала определите уникальные новые URI, например измените один из псевдонимов.

Не пытайтесь решить конфликт перенаправлением обеих страниц на один URL, если содержание у них разное.

Применяем выбранную структуру

1. Сохраните список ресурсов с текущими URI.
2. В «Системных настройках» измените use_alias_path.
3. При необходимости подготовьте новые псевдонимы и проверьте родителей ресурсов.
4. Обновите URI и очистите кеш.
5. Получите второй список адресов.
6. Сопоставьте записи по ID ресурса и подготовьте правила для изменившихся URI.

Проверьте ресурсы с замороженным URI. Их адрес не следует определять только по глобальному значению use_alias_path.

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

uslugi/remont.html → remont

Не создавайте без необходимости цепочку:

uslugi/remont.html → uslugi/remont → remont

Массовая миграция: сохраняем и сопоставляем URI

Для большого сайта надежнее получить два снимка адресов и связать их по ID. Псевдоним или окончание могут измениться, а идентификатор сохраненного ресурса позволяет сопоставить ту же страницу.

Получаем первый снимок

В phpMyAdmin откройте базу нужного сайта. Проверьте фактический префикс таблиц: modx_ используется ниже только как стандартный пример.

На вкладке SQL выполните запрос для основного контекста web:

SELECT
    id,
    context_key,
    class_key,
    pagetitle,
    alias,
    parent,
    uri,
    uri_override,
    content_type,
    published
FROM modx_site_content
WHERE deleted = 0
  AND context_key = 'web'
ORDER BY id;

Запрос только читает данные. Если префикс другой, замените имя таблицы. Для другого контекста измените условие context_key.

Экспортируйте результат в CSV с заголовками столбцов. Назовите файл, например, uri-before.csv. Запишите время снимка и связанные настройки.

Этот список не охватывает все возможные виртуальные адреса и ссылки на удаленные ресурсы. Дополните карту данными обхода, sitemap, журналов и статистики.

Получаем второй снимок

На копии сайта примените новую схему, обновите URI и выполните тот же запрос. Экспортируйте результат как uri-after.csv.

Пока сравниваете снимки, не смешивайте миграцию с удалением и созданием множества ресурсов. Такие изменения усложняют сопоставление.

Собираем рабочую карту

Соедините строки по id, сохранив context_key для контроля. В таблице должны оказаться:

• ID ресурса.
• Контекст.
• Старый URI.
• Новый URI.
• Нужный статус перенаправления.
• Комментарий об исключениях.

Для нескольких страниц карту можно составить вручную. Для большого списка используйте объединение таблиц по id в редакторе таблиц или скрипте, а не сопоставление по похожим заголовкам.

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

Если несколько материалов действительно объединены, их старые URL могут вести на одну соответствующую итоговую страницу. В остальных случаях сохраняйте соответствие содержания.

Импортируем в easyRedirects

Откройте пакетный импорт в разделе компонента. easyRedirects принимает правила из текста CSV.

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

Проверьте разделитель, необходимость заголовка, формат статуса и метки. Не подставляйте формат другого компонента или сервиса с похожим названием.

1. Сначала подготовьте две-три проверенные строки.
2. Импортируйте их на копии сайта.
3. Откройте созданные правила и сравните исходные пути, цели и статус.
4. Проверьте реальные переходы.
5. После успешной проверки импортируйте остальной набор.

До импорта проверьте существующие правила. Не предполагается, что пакет обязательно перезапишет, объединит или пропустит дубли именно так, как вы ожидаете.

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

Когда достаточно регулярного выражения

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

Удаление .html по единой схеме

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

URL:   ^(.+)\.html$
Цель:  $1
Статус: 301

Например, o-kompanii.html будет направлен на o-kompanii.

Используйте его только после проверки, что соответствующие новые страницы существуют. Исключения задайте отдельно. Не считайте любое обращение к неизвестному .html правильным кандидатом для перенаправления.

Реальные файлы, обрабатываемые сервером без MODX, это правило компонента не перехватит.

Перенос страниц раздела

Пример по документации easyRedirects:

URL:   ^catalog\/telephony\/(.*)$
Цель:  catalog/phones/$1
Статус: 301

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

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

В исходном выражении используются ^ и $ для границ, а буквальные слеши экранированы. Цель не является регулярным выражением, но использует подстановку $1.

Для удаления вложенности всего сайта я не рекомендую правило «оставить последний сегмент». Оно не учитывает одинаковые псевдонимы, исключения и разные назначения. Карта ресурсов здесь надежнее.

Переносим проверенную схему на рабочий сайт

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

1. Сделайте свежую копию файлов и базы.
2. Проверьте, не появились ли новые ресурсы после первого снимка.
3. Примените согласованные изменения адресов.
4. Обновите URI и очистите кеш.
5. Добавьте или включите подготовленные перенаправления.
6. Проверьте важные старые и новые URL.

Не оставляйте надолго промежуток, когда прежние адреса уже не работают, а перенаправления еще отсутствуют.

Сравните итоговые URI рабочего проекта с картой, полученной на копии. Если за время подготовки содержание изменилось, старый снимок нельзя считать полным.

Обновляем ссылки, canonical и sitemap

Перенаправления сохраняют доступ по прежним адресам, но сам сайт должен ссылаться сразу на новые.

• Проверьте меню, хлебные крошки, списки и карточки.
• Обновите вручную вставленные ссылки в содержимом, чанках и настройках.
• Проверьте canonical на новой странице.
• Сформируйте sitemap.xml с актуальными адресами.
• Если используется hreflang, обновите адреса языковых версий.
• Проверьте прежние редиректы, которые теперь ведут на промежуточные URL.
• Обновите управляемые ссылки в рекламе и внешних размещениях.

Не заменяйте .html или название каталога во всем проекте без разбора: можно повредить ссылки на файлы и сторонние сайты.

При изменении путей на том же домене инструмент смены адреса сайта в Google Search Console не требуется. Обновленную XML-карту можно отправить повторно.

Проверяем ответы и назначения

Для каждого правила ожидаем:

Старый URL → 301 → правильный новый URL → 200

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

• Обычные страницы и вложенные ресурсы.
• Сам раздел и его потомков.
• Адреса с .html и без него.
• Завершающие слеши и исключения.
• URL из рекламы с параметрами.
• Отсутствие перехода на чужую страницу, цикла и цепочки.

Для проверки в терминале:

curl -I https://your-site.ru/uslugi/remont.html
curl -I https://your-site.ru/remont

Замените домен и пути своими. В первом ответе проверьте 301 и Location, во втором — 200. На Windows при необходимости используйте curl.exe.

Если сервер обрабатывает HEAD иначе, чем GET, дополнительно проверьте обычный запрос в браузере через вкладку Network.

Для большого сайта проверяйте весь сохраненный список инструментом обхода. Статистика срабатываний easyRedirects полезна для наблюдения, но отсутствие срабатываний не подтверждает правильность правила.

Если что-то пошло не так

Старый URL возвращает 404

Проверьте исходный путь без домена и начального слеша, наличие правила и достижение запроса до MODX. Если запрос останавливает веб-сервер, исправление нужно на его уровне.

Правило сохранено, но старый адрес открывается со статусом 200

Возможно, по этому пути все еще существует ресурс, поэтому OnPageNotFound не наступает. Проверьте карту адресов и фактические URI, а не пытайтесь исправить это повторным импортом.

Новый адрес возвращает 404

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

Появился цикл или неверное назначение

Проверьте точные правила, регулярные выражения, серверные перенаправления и правила HTTPS/www. При отладке учитывайте сохраненный браузером 301.

Нужно вернуться к прежней структуре

Верните согласованный набор прежних настроек, обновите URI и отключите новые правила, которые больше не соответствуют адресам.

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

Для удаленной страницы без соответствующей замены допустим правильный 404 или 410. Не перенаправляйте все ошибки на главную.

После изменения адресов

Следите за ошибками, переходами и данными поисковых систем. При существенной смене URL возможны временные колебания видимости; редиректы не позволяют обещать отсутствие любых изменений трафика.

Google рекомендует сохранять постоянные перенаправления как минимум год, а для пользователей может быть полезно оставить их дольше. Внутренние ссылки при этом лучше обновить, а не постоянно проводить через редиректы.

Первоначальная настройка нового сайта находится в уроке по ЧПУ. Эта статья остается отдельной веткой для существующих адресов.

Общая последовательность находится в карте обучения MODX.

← Предыдущая статьяMODX https, как настроить самостоятельно

Следующая статья →Раздел управления виджетами