Справочник: редиректы

Что здесь. Редирект — правило сайта «откуда → куда», а не свойство страницы: с любого пути сайта на любой путь этого сайта или на адрес другого домена. Страница-заглушка по старому адресу не нужна, правило ловит путь и без неё. Правила заводятся вручную, импортом CSV или сами — когда опубликованная страница меняет адрес или удаляется. В дашборде это «Инструменты → Редиректы». Каждая ручка, поле и код отказа сверены с кодом и прогнаны на тестовом сайте.

Адреса. Ручки сайта: https://onpress.pro/api/v2/site/{siteId}/redirects…, права — администратор сайта или суперадмин сети. В примерах op_XXXX — ваш токен, SITE_ID — внешний идентификатор сайта. Как выбирается сайт и в какой форме приходят отказы — доступ.

Правило работает, пока существует. У правила только from и to: ни включателя, ни выбора кода, ни заметки, ни счётчика. Заведённое правило срабатывает всегда, остановить редирект — удалить правило. Ответ всегда постоянный, 301: поиск переносит старый адрес на новый. Срабатывание ничего не пишет в базу — переходы видно в логах сервера и в аналитике.

Когда срабатывает. Правило отвечает раньше всего остального: раньше сборки страницы, её статической копии и кэша. Если по адресу правила опубликована страница, правило её перекрывает — статическая копия снимается в том же запросе, кэш сайта сбрасывается, и новая копия по этому адресу не появится, пока правило есть. Удалили правило или сменили его from — страница снова отвечает 200 и снова получает копию. Исключение — загруженное статическое приложение: его файлы отдаются раньше любого правила, и по его адресу редирект не сработает (предупреждение static_app).

Правила

Пункт	Ручка	Тело
Список правил	GET /redirects	—
Завести правило	POST /redirects	{"from": "/old/", "to": "/new/"}
Одно правило	GET /redirects/{id} PATCH /redirects/{id} DELETE /redirects/{id}	{"to": "/newer/"}

Поля правила

Поле	Тип	Что значит
id	number	номер правила
from	string	откуда: путь от корня сайта, по желанию с параметрами (/page/?id=5); /old/* — префикс
to	string	куда: путь от корня (/new/, / — главная) или полный адрес https://… на любой домен
match	string	exact — точный адрес, prefix — всё под префиксом
auto	boolean	правило завела платформа при переносе или удалении страницы
page_id	number или null	у автоправила — страница, чей адрес сменился или перестал отвечать; у ручного — null
created_at, updated_at	string	UTC, ISO 8601

Как сравнивается адрес. Без учёта регистра и косой черты на конце: правило /Old-Page/ ловит и /old-page, и /old-page/. Кириллица в пути пишется буквами или в %D0%… — это одно и то же. from можно прислать полным адресом этого же сайта, он сведётся к пути; адрес другого домена — отказ. Решётка (#…) в from не принимается: браузер её на сервер не отправляет.

Параметры адреса. Правило без параметров ловит адрес с любыми параметрами и передаёт их дальше: /old/?a=1 уйдёт на /new/?a=1, если в to своих параметров нет. Исключение — рекламные метки (utm_*, gclid, fbclid, yclid и подобные): если других параметров в адресе нет, кэш сайта отбрасывает их раньше правила, и /old/?utm_source=x уйдёт на /new/; вместе с обычными параметрами передаются все. Правило с параметрами (/page/?id=5&b=2) ловит только этот набор, порядок не важен (?b=2&id=5 тоже), и параметры дальше не передаёт; /page/?id=5 без b это правило не поймает. Для одного пути правило с параметрами проверяется раньше правила без них.

Префикс. from, который кончается на /*, ловит всё под этим путём, включая сам путь. Звёздочка в to заменяется хвостом адреса: правило /old/* → /docs/* уводит /old/a/b/?x=1 на /docs/a/b/?x=1, а /old/ — на /docs/. Без звёздочки в to всё под префиксом уходит на один адрес. Звёздочка в to бывает только у префиксного правила. Точное правило важнее префиксного, длинный префикс важнее короткого. Префикс на весь сайт (/*), звёздочка в середине пути и префикс с параметрами не принимаются.

Что занято. Адреса самой платформы — /wp-admin/, /wp-json/, /wp-content/, /wp-includes/, служебные .php — правилом не перекрываются: такое from — отказ redirect_invalid.

Список правил

GET /redirects отдаёт все правила сайта, старые первыми, и текущее состояние автоправил полем auto_redirects.

Параметр	Что делает
search	подстрока в from или to

curl -s "https://onpress.pro/api/v2/site/SITE_ID/redirects?search=legacy" \
  -H "Authorization: Bearer op_XXXX"

{
  "success": true,
  "redirects": [
    {
      "id": 232,
      "from": "/legacy/*",
      "to": "/docs/*",
      "match": "prefix",
      "auto": false,
      "page_id": null,
      "created_at": "2026-10-03T18:42:53Z",
      "updated_at": "2026-10-03T18:42:53Z"
    }
  ],
  "total": 1,
  "auto_redirects": true
}

Завести правило

POST /redirects с полями from и to, оба обязательны. Других полей у правила нет:

• "enabled": false — отказ 400 redirect_invalid: выключенных правил не бывает, правило удаляют;
• code не применяется: 301 проходит молча, с любым другим правило всё равно ставится с 301, а в warnings приходит code_ignored;
• dry_run: true (в теле или ?dry_run=1) проверяет правило целиком — петли, цепочки, живую страницу — и ничего не записывает; ответ 200 с правилом без id.

Ответ — 201 с правилом, списком предупреждений warnings и признаком applied (сайт принял новый набор правил). Если правило перекрыло опубликованную страницу, в ответе ещё static_removed — номера страниц, чья статическая копия снята.

curl -s -X POST "https://onpress.pro/api/v2/site/SITE_ID/redirects" \
  -H "Authorization: Bearer op_XXXX" -H "Content-Type: application/json" \
  -d '{"from": "/old/", "to": "/new/", "code": 302}'

{
  "success": true,
  "redirect": {
    "id": 231,
    "from": "/old/",
    "to": "/new/",
    "match": "exact",
    "auto": false,
    "page_id": null,
    "created_at": "2026-10-03T18:42:52Z",
    "updated_at": "2026-10-03T18:42:52Z"
  },
  "warnings": [
    { "code": "code_ignored", "message": "redirects are always 301; \"code\": 302 is ignored", "value": 302 }
  ],
  "applied": true
}

Предупреждения правило не отменяют, оно записано:

Код	Когда
live_page	по from опубликована страница (page_id) или это главная; пока правило есть, посетители её не видят, её статическая копия снята
chain	to ведёт на адрес другого правила — посетитель сделает лишний переход; chain — вся цепочка. Лучше сразу указать конечный адрес
static_app	по адресу лежит загруженное приложение, его файлы отдаются раньше правила; url
code_ignored	прислан code, отличный от 301; правило записано с 301, value
apply_failed	правило сохранено, но сайт ещё не принял новый набор — сработает со следующей правкой или после POST /redirects/apply

Отказы: 400 redirect_invalid (field, value; текст называет, что не так), 409 redirect_loop (chain), 409 redirect_exists (у этого from уже есть правило; id), 409 redirects_limit (больше 5000 правил на сайт).

{
  "success": false,
  "error": "redirect_exists",
  "message": "\"from\": \"/old/\" already has a rule #231 (→ /new/); change it instead",
  "field": "from",
  "value": "/old/",
  "id": 231
}

Петли проверяются по всем правилам сайта до записи. Отказ получает правило, которое уводит на свой же адрес (/a/ → /A), замыкает круг с другими правилами или префикс, который растёт с каждым переходом (/old/* → /old/sub/*):

{
  "success": false,
  "error": "redirect_loop",
  "message": "\"/docs/\" → \"/old/\" makes a redirect loop: /docs/ → /old/ → /home-next/ → /docs/",
  "field": "to",
  "value": "/old/",
  "chain": [
    { "id": null, "from": "/docs/", "to": "/old/" },
    { "id": 5, "from": "/old/", "to": "/home-next/" },
    { "id": 8, "from": "/home-next/", "to": "/docs/" }
  ]
}

Одно правило

GET /redirects/{id} — правило полем redirect. PATCH /redirects/{id} правит from, to или оба; проверки и предупреждения те же, что при заведении, dry_run тоже. Так же правится и автоправило — например, чтобы увести адрес удалённой страницы не на родителя, а на другую страницу; пометка auto и page_id при этом остаются. При смене from страница по старому адресу снова получает статическую копию.

curl -s -X PATCH "https://onpress.pro/api/v2/site/SITE_ID/redirects/242" \
  -H "Authorization: Bearer op_XXXX" -H "Content-Type: application/json" \
  -d '{"to": "/catalog/"}'

{
  "success": true,
  "redirect": {
    "id": 242,
    "from": "/catalog/old-page/",
    "to": "/catalog/",
    "match": "exact",
    "auto": true,
    "page_id": 7119,
    "created_at": "2026-10-03T18:44:58Z",
    "updated_at": "2026-10-03T18:45:20Z"
  },
  "warnings": [],
  "applied": true
}

DELETE /redirects/{id} удаляет правило и возвращает страницу, которую оно перекрывало: она снова отвечает 200 и получает статическую копию. Ответ — {"success": true, "deleted": 242, "applied": true, "warnings": []}, с dry_run — {"success": true, "dry_run": true, "deleted": 242, "redirect": {…}} без удаления.

Отказы: 404 redirect_not_found, 400 nothing_to_update (нет ни from, ни to), 400 redirect_invalid (прислано "enabled": false), остальные — как при заведении.

Автоправила

Пункт	Ручка	Тело
Включить или выключить	PUT /redirects/auto	{"enabled": false}
Текущее состояние	GET /redirects	поле auto_redirects

Автоправило — обычное правило 301 с пометкой auto: true и номером страницы в page_id. Платформа заводит его сама, когда адрес опубликованной страницы перестаёт отвечать: страницу перенесли или удалили. Ставится по правилу на каждый адрес — на саму страницу и на каждого её опубликованного потомка, — а не префиксом, чтобы не перехватить страницы, которые позже появятся под старым путём. Дальше автоправило живёт как любое другое: его видно в списке, можно поправить to или удалить.

Перенос страницы

Сменился путь опубликованной страницы — слаг или родитель — и со старого пути на новый заводится правило 301, для неё и для каждого опубликованного потомка. Источник не важен: дашборд (правка пути в строке, «Перенести в каталог», вкладка «Markdown» в панели страницы), POST /pages/markdown с id, PATCH /docs/sidebar/items/{ref}, ручки первой версии или панель WordPress. Смена языка (POST /pages/language) правила не заводит — если адрес из-за неё сменился, заведите правило вручную.

Заодно с переносом:

• цепочки сворачиваются: правила, которые вели на старый путь, переводятся прямо на новый;
• адрес освобождается: правило с from, равным новому пути страницы, удаляется — ручное тоже, — иначе оно спрятало бы страницу;
• обратный перенос не даёт петли: вернули страницу на прежний адрес — правило прежний → новый удаляется по тому же правилу, а заводится новый → прежний;
• чужую страницу не прячет: если по старому пути уже отвечает другая опубликованная страница, правило не заводится.

curl -s -X POST "https://onpress.pro/api/v2/site/SITE_ID/pages/markdown" \
  -H "Authorization: Bearer op_XXXX" -H "Content-Type: application/json" \
  -d '{"markdown": "---\nid: PAGE_ID\nname: \"Каталог\"\nslug: \"catalog-new\"\nurl: \"/catalog-new/\"\nstatus: \"publish\"\n---\n\nТекст страницы."}'

{
  "success": true,
  "updated": true,
  "id": 7117,
  "url": "/catalog-new/",
  "redirects_created": [
    { "id": 237, "from": "/catalog/", "to": "/catalog-new/" },
    { "id": 238, "from": "/catalog/kid/", "to": "/catalog-new/kid/" }
  ],
  "auto_redirects": {
    "moves": [
      { "id": 7117, "from": "/catalog/", "to": "/catalog-new/" },
      { "id": 7118, "from": "/catalog/kid/", "to": "/catalog-new/kid/" }
    ],
    "created": 2,
    "updated": 1,
    "enabled": true
  }
}

Здесь updated: 1 — одно правило, которое вело на /catalog/, переведено на /catalog-new/.

Удаление страницы

Опубликованная страница ушла в корзину или удалена насовсем — в дашборде (корзина в строке, «Удалить» у выбранных), через DELETE /pages/{ref} или в панели WordPress — и правило 301 ведёт с её пути на ближайшего опубликованного родителя. У страницы верхнего уровня цель — главная её языка: / у основного языка, /en/ — у языка с префиксом в адресе. Так же уводятся её опубликованные потомки: и удалённые вместе с ней (with_children), и оставшиеся под удалённой страницей, чей адрес перестал отвечать. Если страницу с живыми потомками удалили насовсем в панели WordPress, WordPress переносит потомков к её родителю, и правило ведёт на их новый путь. Правила, которые вели на путь удалённой страницы, переводятся на новую цель — цепочка сворачивается.

curl -s -X DELETE "https://onpress.pro/api/v2/site/SITE_ID/pages/7117?force=1&with_children=1" \
  -H "Authorization: Bearer op_XXXX"

{
  "success": true,
  "mode": "delete",
  "redirects_created": [
    { "id": 243, "from": "/catalog/kid/", "to": "/" },
    { "id": 244, "from": "/catalog/", "to": "/" }
  ],
  "auto_redirects": { "moves": 2, "created": 2, "enabled": true }
}

Цель не подходит — поправьте её: PATCH /redirects/{id} с новым to, правило останется автоправилом.

Возврат из корзины

Страницу вернули из корзины (в панели WordPress — у API ручки возврата нет) — автоправила с её нынешнего пути удаляются, даже если их цель меняли вручную; с путей потомков тоже, если сами потомки не в корзине. Правила прежних переносов страницы ведут с других путей и остаются.

Что приходит в ответе

Ручки, через которые страницу переносят или удаляют, — POST /pages/markdown, PATCH /docs/sidebar/items/{ref}, DELETE /pages/{ref} и ручки первой версии, — отвечают двумя полями, если адрес сменился:

Поле	Что значит
redirects_created	правила, которые теперь ведут со старых адресов: [{id, from, to}] — новые и прежние правила с того же from, переведённые на новую цель
auto_redirects.moves	сменившиеся адреса: в записи страницы — списком [{id, from, to}] (id — страница), в удалении и в первой версии — числом
auto_redirects.created	сколько правил заведено
auto_redirects.updated	в записи страницы: сколько прежних правил переведено на новую цель, включая свёрнутые цепочки
auto_redirects.enabled	включены ли автоправила; false — адрес сменился, а правила не заведены (в записи страницы ещё disabled: true)

Дашборд по этим полям показывает уведомление — подробно в разделе «В дашборде».

Выключатель

PUT /redirects/auto с {"enabled": false} выключает автоправила сайта целиком — и для переносов, и для удалений; true включает. По умолчанию включены. Ответ — {"success": true, "auto_redirects": false}. Пока выключено, адрес меняется без правила: redirects_created пустой, auto_redirects.enabled — false. Заведённые раньше автоправила выключатель не трогает.

Отказы: 400 redirect_invalid, если enabled не передан или не да/нет. Этот отказ приходит в общей форме ошибки — {"code": "redirect_invalid", "message": "…", "data": {"status": 400, "field": "enabled"}}.

Импорт и применение

Пункт	Ручка	Тело
Импорт CSV или JSON	POST /redirects/import	{"csv": "from,to\n/a/,/b/", "dry_run": true}
Применить заново	POST /redirects/apply	—

Импорт CSV или JSON

Тело — csv строкой или redirects списком [{from, to}]. В CSV колонки from,to; файл старого вида from,to[,code][,enabled] тоже читается — код не применяется (у строки с кодом не 301 — предупреждение code_ignored), строка с enabled = 0 отклоняется, лишние колонки пропускаются. Разделитель — запятая или точка с запятой, строка заголовка (from,to,…) необязательна, пустые строки и строки с # пропускаются.

on_conflict решает, что делать с from, у которого уже есть правило: skip (по умолчанию) — оставить старое, replace — переписать его строкой импорта. dry_run: true (в теле или ?dry_run=1) проверяет каждую строку и ничего не пишет — так удобно смотреть, что получится, перед настоящим импортом. До 5000 строк за раз. Строки с ошибкой не мешают остальным; записанные строки ложатся одной транзакцией.

curl -s -X POST "https://onpress.pro/api/v2/site/SITE_ID/redirects/import?dry_run=1" \
  -H "Authorization: Bearer op_XXXX" -H "Content-Type: application/json" \
  -d '{"csv": "from,to\n/imp-a/,/docs/\n/imp-b/*,https://example.com/*\n/old/,/x/\n/bad,ftp://x\n/imp-c/,/docs/,302\n/imp-d/,/docs/,301,0"}'

{
  "success": true,
  "dry_run": true,
  "created": 3,
  "updated": 0,
  "skipped": 1,
  "failed": 2,
  "rows": [
    { "line": 2, "from": "/imp-a/", "to": "/docs/", "status": "created" },
    { "line": 3, "from": "/imp-b/*", "to": "https://example.com/*", "status": "created" },
    { "line": 4, "from": "/old/", "to": "/x/", "status": "skipped", "id": 231, "reason": "exists" },
    { "line": 5, "from": "/bad", "to": "ftp://x", "status": "failed",
      "error": { "code": "redirect_invalid", "message": "\"to\": \"ftp://x\" is neither a path from the root (\"/new/\") nor an http(s) URL" } },
    { "line": 6, "from": "/imp-c/", "to": "/docs/", "status": "created",
      "warnings": [ { "code": "code_ignored", "message": "redirects are always 301; \"code\": \"302\" is ignored", "value": "302" } ] },
    { "line": 7, "from": "/imp-d/", "to": "/docs/", "status": "failed",
      "error": { "code": "redirect_invalid", "message": "\"enabled\": rules have no on/off switch — a rule that exists always works; delete it to stop the redirect" } }
  ]
}

status строки — created, updated, skipped или failed (с error), у записанных — id, у строк с предупреждениями — warnings. Без dry_run в ответе ещё applied и общие warnings:

{
  "success": true,
  "dry_run": false,
  "created": 1,
  "updated": 1,
  "skipped": 0,
  "failed": 0,
  "rows": [
    { "line": 1, "from": "/imp-a/", "to": "/docs/", "status": "created", "id": 234 },
    { "line": 2, "from": "/old/", "to": "/new/", "status": "updated", "id": 231 }
  ],
  "applied": true,
  "warnings": []
}

Отказы: 400 nothing_to_import (нет ни csv, ни redirects, или в них нет строк), 400 invalid_on_conflict, 409 redirects_limit.

Применить заново

POST /redirects/apply отдаёт сайту текущий набор правил и снимает статические копии по их адресам. Нужен только после предупреждения apply_failed; обычная правка делает это сама. Ответ: {"success": true, "applied": true, "rules": 5, "warnings": []}.

В дашборде

Инструменты → Редиректы — все правила сайта плотной таблицей «Откуда / Куда»: сверху итог «N редиректов», по умолчанию порядок по алфавиту адреса «Откуда», щелчок по заголовку колонки сортирует по ней. Автоправило помечено «авто», подсказка на пометке называет страницу. Действия в строке — значками при наведении, на телефоне видны всегда. Что можно сделать:

• добавить — кнопка «Добавить редирект» в шапке: поля «Откуда» и «Куда», код выбирать не нужно;
• поправить — клик по адресу в строке, сохраняется сразу; отказ или предупреждение встаёт текстом под строкой;
• удалить — корзина в строке, с подтверждением;
• открыть — адрес «Откуда» на домене сайта в новой вкладке; у префиксного правила кнопка неактивна;
• импорт из CSV — вставить строки или загрузить файл, «Проверить» показывает итог по каждой строке, «Применить» записывает; выбор «Пропустить» или «Заменить» для адресов, у которых правило уже есть;
• поиск по адресам;
• переключатель «Автоправила» — тот же, что PUT /redirects/auto; на телефоне он стоит строкой над таблицей.

Уведомления. Перенесли или удалили опубликованную страницу в разделе «Страницы» — дашборд показывает, что заведено: «Создан редирект: /старый/ → /новый/» или «Создано N редиректов» со списком по кнопке «Показать список». Если автоправила выключены, приходит «Адрес изменился, редирект не создан (автоправила выключены)» или «Страница удалена, редирект не создан…». В каждом уведомлении есть кнопка «Открыть редиректы».

Как перенести старые адреса

Раньше старый адрес заводился страницей с полем redirect. Этого поля у страниц больше нет: PATCH /pages/{ref} с ним отвечает 400 redirect_field_removed, а ключ redirect во frontmatter публикации не записывается и даёт предупреждение. Старые адреса — правилами: одно правило на адрес или префикс на целый раздел, пачкой — импортом CSV.

{
  "success": false,
  "error": "redirect_field_removed",
  "message": "pages no longer carry a \"redirect\" field; a redirect is a site rule: POST /site/{siteId}/redirects {from, to}",
  "field": "redirect"
}