В мультиязычном проекте почти всегда есть контент, который не должен дублироваться на все языки: служебные страницы, внутренние документы, отдельные товары, новости только для одной аудитории, формы и лендинги под конкретный рынок. Если просто включить перевод для всего подряд, быстро появляются лишние языковые версии, битые ссылки в переключателе и путаница в SEO.
В Polylang это решается не одним способом. Иногда достаточно изменить настройки типа записи, иногда — убрать конкретную запись из связки переводов, а иногда — запретить перевод через код, если контент создаётся автоматически. Ниже — рабочие варианты без выдуманных хуков и без лишней магии.
Когда перевод лучше отключить
Не каждый объект на сайте должен иметь языковую пару. На практике перевод обычно исключают для:
- служебных страниц: политика конфиденциальности, условия использования, страница благодарности;
- временных лендингов, которые работают только на одном языке;
- записей, импортируемых из внешней системы и не предназначенных для ручной локализации;
- контента, где перевод ломает логику: формы, инструкции, документы, внутренние справочники;
- части WooCommerce-каталога, если товар продаётся только в одном регионе.
Если такие страницы оставить в общем переводном пуле, редактор будет тратить время на пустые версии, а переключатель языка начнёт вести на страницы с неполным или дублирующимся содержимым.
Диагностика: почему запись всё равно попадает в перевод
Перед правками полезно понять, где именно Polylang создаёт связь. Обычно проблема выглядит так:
- в редакторе у записи есть пустой блок для перевода на другой язык;
- в списке записей отображаются языковые колонки, хотя для этого типа они не нужны;
- после публикации запись появляется в языковом переключателе;
- URL на другом языке открывает 404 или пустую страницу вместо того, чтобы скрыться.
Проверьте три места:
- Настройки Polylang — включён ли перевод для нужного типа записи.
- Редактор конкретной записи — не привязана ли она уже к переводу вручную.
- Таксономии и меню — иногда запись не переводится, но остаётся в меню или архиве другого языка.
Если проблема только в одной записи, не трогайте глобальные настройки. Если же весь тип контента не должен переводиться, лучше отключить его на уровне типа записи.
Способ 1: отключить перевод для типа записи в настройках Polylang
Самый чистый вариант — убрать перевод для целого post type. Это подходит для служебных страниц, кастомных сущностей и контента, который не должен иметь языковых версий вообще.
В админке Polylang откройте настройки типов записей и снимите галочку у нужного типа. После этого Polylang перестанет показывать языковые поля для новых объектов этого типа.
Важно: уже созданные переводы сами по себе не исчезнут. Их нужно удалить или отвязать вручную, если они больше не нужны.
Когда этот вариант не подходит
Если у вас один и тот же тип записи используется и для переводимого, и для непереводимого контента, глобальное отключение сломает редакционный процесс. В таком случае лучше исключать только отдельные записи через код или через ручную настройку связки языков.
Способ 2: убрать конкретную запись из языковой связки
Если нужно исключить только одну страницу или запись, проще всего сделать это в редакторе. У Polylang у записи есть язык, а рядом — блок связей с переводами. Если перевод не нужен, не создавайте связанный объект на другом языке и удалите уже существующую связь, если она есть.
На практике это означает:
- оставить записи только один язык;
- не создавать перевод в соседней колонке;
- проверить, что запись не добавлена в меню другого языка;
- при необходимости скрыть её из языкового переключателя через логику темы или меню.
Этот способ удобен, когда речь идёт о единичных страницах. Но если таких объектов много, ручная работа быстро становится ошибкой в процессах.
Способ 3: исключить запись программно
Когда контент создаётся автоматически, лучше помечать его как непереводимый на этапе сохранения. В Polylang есть функции для работы с языком объекта, и это надёжнее, чем пытаться потом чистить записи вручную.
Ниже пример, который назначает записи язык и не создаёт для неё переводную связку. Такой код можно использовать в плагине или в functions.php, если задача локальная.
<?php
add_action( 'save_post', function( $post_id, $post, $update ) {
if ( wp_is_post_revision( $post_id ) || wp_is_post_autosave( $post_id ) ) {
return;
}
if ( 'page' !== $post->post_type ) {
return;
}
// Пример: служебная страница всегда остаётся только на русском.
if ( 'privacy-policy' === $post->post_name ) {
if ( function_exists( 'pll_set_post_language' ) ) {
pll_set_post_language( $post_id, 'ru' );
}
// Если перевод уже был создан раньше, его связь нужно убрать отдельно.
}
}, 20, 3 );Этот фрагмент не удаляет существующие переводы автоматически. Его задача — зафиксировать язык записи. Если нужно именно исключить объект из перевода, а не просто назначить язык, обычно дополнительно чистят переводные связи через административный процесс или отдельную логику в плагине.
Если запись создаётся импортом
При импорте из CSV, XML или внешнего API лучше сразу решать, какие записи переводить, а какие нет. Для этого удобно хранить служебный флаг в метаполе, например _skip_translation, и на его основе не создавать языковые копии.
<?php
add_action( 'save_post_product', function( $post_id, $post ) {
if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) {
return;
}
$skip = get_post_meta( $post_id, '_skip_translation', true );
if ( '1' === $skip && function_exists( 'pll_set_post_language' ) ) {
pll_set_post_language( $post_id, 'en' );
}
}, 10, 2 );Здесь важно не путать язык записи и переводимость. Назначить язык можно, но если импортёр потом создаёт копии на другие языки, нужно отключать именно этот шаг в логике импорта.
Сравнение подходов
| Подход | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| Настройки типа записи | Непереводим весь post type | Просто, прозрачно для редакторов | Не подходит для смешанного контента |
| Ручное исключение записи | Нужно убрать 1–5 объектов | Быстро без кода | Легко забыть при массовом добавлении |
| Код на save_post | Контент создаётся автоматически | Стабильно и повторяемо | Нужно тестировать на импорте и ревизиях |
Проверка результата после внедрения
После изменения настроек не ограничивайтесь визуальной проверкой в админке. Смотрите на поведение сайта как пользователь и как редактор.
- Откройте запись в админке и убедитесь, что языковые поля больше не предлагают создать перевод.
- Проверьте фронтенд: запись не должна появляться в переключателе языка, если она не должна переводиться.
- Откройте прямую ссылку на запись на другом языке и посмотрите, что происходит: 404, редирект или корректное скрытие.
- Проверьте меню, виджеты и списки записей: иногда запись исключена из перевода, но всё ещё висит в навигации другого языка.
- Если используется кэш, очистите его после правок, иначе старые языковые ссылки могут сохраняться.
Для WooCommerce отдельно проверьте карточку товара, архивы и связанные элементы — атрибуты, категории и хлебные крошки могут жить своей жизнью, даже если сам товар уже не переводится.
Частые ошибки и как их исправить
Отключили перевод типа записи, но старые переводы остались
Это нормальная ситуация. Polylang не удаляет контент автоматически. Нужно вручную удалить ненужные языковые копии или отвязать их от исходной записи. Если этого не сделать, в базе останутся старые связи, а редакторы будут видеть мусор в списках.
Запись не переводится, но всё равно показывается в меню
Меню в WordPress — отдельная сущность. Если запись уже добавлена в меню другого языка, её нужно убрать вручную или пересобрать меню для каждого языка отдельно. Иначе пользователь увидит ссылку, которая ведёт не туда, куда ожидается.
Код срабатывает на ревизиях и автосохранении
Если не проверять wp_is_post_revision() и wp_is_post_autosave(), можно случайно назначить язык не той версии записи. Это особенно неприятно при массовом редактировании и импорте.
Путают язык записи и переводимость
Назначение языка не равно отключению перевода. Запись может иметь язык, но при этом не иметь связанной копии. Если задача именно в отсутствии перевода, проверьте и редактор, и связи, и поведение переключателя языка.
Что учесть для безопасности и производительности
Если вы решаете задачу кодом, не вешайте логику на каждый запрос фронтенда. Работайте на сохранении записи или в административном процессе. Это снижает нагрузку и уменьшает риск случайных изменений.
Для массовых правок лучше использовать отдельный мини-плагин, а не functions.php. Так проще отключить логику при отладке и не потерять изменения при смене темы.
Если на сайте много языков и большой каталог, после изменения структуры переводов проверьте кэш страниц, объектный кэш и sitemap. Иногда проблема выглядит как ошибка Polylang, хотя на деле пользователь видит старую версию из кэша.
Если нужно регулярно скрывать служебные страницы и чистить дубли, имеет смысл дополнительно использовать инструменты для удаления дублей и технической очистки сайта, например Clearfy Pro, но только как вспомогательный инструмент, а не замену нормальной настройке переводов.
Короткий рабочий сценарий
Если нужно быстро принять решение без долгой настройки, ориентируйтесь так:
- весь тип записи не должен переводиться — отключите его в настройках Polylang;
- непереводимы только отдельные страницы — уберите их из языковой связки вручную;
- контент создаётся автоматически — фиксируйте язык на сохранении и не создавайте переводную копию в импортере;
- после правок обязательно проверьте меню, переключатель языка и кэш.
Такой подход обычно закрывает задачу без лишних костылей и без риска сломать остальную мультиязычную структуру сайта.