Мультиязычный сайт на WordPress без плагинов: Multisite и hreflang

Мультиязычный сайт на WordPress без плагинов сделать можно, и в некоторых проектах это даже более чистое решение. В ядре WordPress нет встроенного управления переводами, зато есть Multisite: он позволяет держать отдельный сайт для каждого языка в одной установке. Если добавить небольшой фрагмент кода, который связывает переводы и выводит теги hreflang, получится мультиязычный сайт без стороннего слоя перевода. Ниже объясняем, как это устроено, приводим проверенный код, сравниваем альтернативы и честно говорим, в каких случаях плагин перевода экономит больше времени, чем стоит.

Мультиязычный сайт на WordPress без плагинов: что нужно закрыть

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

• Отдельные URL для каждого языка, например /ru/ и /en/, чтобы каждая версия индексировалась и ею можно было поделиться.
• Связь между переводами, чтобы система знала, какая английская страница соответствует какой русской.
• Переключатель языка, который ведёт на переведённую страницу, а не на главную другого языка.
• Разметка hreflang, которая подсказывает поисковым системам, какую версию кому показывать.
• Переведённые меню, виджеты, строки темы и ярлыки (slug), а не только тексты записей.
• Редакционный процесс: кто что переводит и как замечать отсутствующие переводы.

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

Путь 1: мультисайт WordPress, один сайт на язык

Multisite превращает одну установку WordPress в сеть сайтов с общим кодом, темами и плагинами, но с собственным контентом, настройками и медиафайлами. Отдельный сайт для каждого языка — самый надёжный способ сделать мультиязычность без плагина перевода: меню, виджеты, ярлыки и язык сайта разделены уже по устройству системы.

Настройка Multisite WordPress по шагам

1. Сделайте резервную копию сайта и базы данных до любых изменений.
2. Добавьте в wp-config.php строку define( 'WP_ALLOW_MULTISITE', true ); как описано в официальном руководстве Create A Network.
3. Откройте «Инструменты» → «Установка сети» и выберите подкаталоги (example.com/ru/) или поддомены (ru.example.com).
4. Скопируйте показанные строки конфигурации в wp-config.php, а правила перезаписи — в .htaccess, затем войдите заново.
5. Создайте по сайту на каждый язык и задайте язык сайта в «Настройки» → «Общие».
6. Активируйте тему и нужные плагины для всей сети.

Подкаталоги держат всё на одном домене, что обычно проще для SSL и помогает поисковикам видеть один бренд. Перевод уже работающего сайта с контентом и трафиком требует той же аккуратности, что и любой переезд; редиректы и контроль после запуска описаны в нашем чек-листе по переносу сайта.

Что вы получаете и чем жертвуете

Вы получаете чистое разделение: у каждого языка могут быть свои меню, юридические страницы и даже товары, а редактор работает в своём языке, не задевая другой. Жертвуете удобством: нет экрана перевода «бок о бок», медиафайлы загружаются отдельно для каждого сайта, а плагины должны поддерживать Multisite. Некоторые тарифы хостинга ограничивают Multisite — проверьте это заранее.

Связь переводов и вывод hreflang без плагина

Multisite не знает, что русская запись — перевод английской. Самая простая надёжная связь — общее значение в произвольном поле: всем переводам одной статьи присваивается одинаковый ключ группы, например в поле _acme_group. Сетевой плагин ниже читает этот ключ, находит соответствующую запись на каждом языковом сайте и выводит ссылки hreflang, включая x-default на основной сайт. Правила, которым следуют эти теги, описаны в документации Google о локализованных версиях страниц.

<?php
/**
 * Plugin Name: Acme Network Hreflang
 * Description: Prints hreflang links between translated posts on a Multisite network with one site per language.
 * Network:     true
 * License:     GPL-2.0-or-later
 */

defined( 'ABSPATH' ) || exit;

// Translations of one article share the same value in the "_acme_group" post meta.
add_action( 'wp_head', function () {
	if ( ! is_singular() ) {
		return;
	}
	$group = get_post_meta( get_queried_object_id(), '_acme_group', true );
	if ( '' === $group ) {
		return;
	}

	$links   = array();
	$default = '';
	foreach ( get_sites( array( 'public' => 1, 'number' => 20 ) ) as $site ) {
		switch_to_blog( (int) $site->blog_id );
		$ids = get_posts( array(
			'post_type'      => 'any',
			'post_status'    => 'publish',
			'meta_key'       => '_acme_group',
			'meta_value'     => $group,
			'fields'         => 'ids',
			'posts_per_page' => 1,
			'no_found_rows'  => true,
		) );
		if ( $ids ) {
			$locale = get_option( 'WPLANG' ) ?: 'en_US'; // empty WPLANG means English
			$lang   = strtolower( strtok( $locale, '_' ) );
			$url    = get_permalink( $ids[0] );
			$links[ $lang ] = $url;
			if ( is_main_site() ) {
				$default = $url;
			}
		}
		restore_current_blog();
	}

	if ( count( $links ) < 2 ) {
		return; // one language needs no hreflang
	}
	foreach ( $links as $lang => $url ) {
		printf( '<link rel="alternate" hreflang="%s" href="%s" />' . "\n", esc_attr( $lang ), esc_url( $url ) );
	}
	if ( $default ) {
		printf( '<link rel="alternate" hreflang="x-default" href="%s" />' . "\n", esc_url( $default ) );
	}
} );

Именно этот файл мы прогнали через php -l и через тестовый стенд, имитирующий трёхъязычную сеть: он выводит каждый язык и x-default, пропускает языки без перевода, ничего не выводит для одноязычных записей и архивов и всегда возвращает исходный контекст сайта. Положите его в wp-content/mu-plugins или активируйте как плагин для всей сети.

Три практических замечания. Во-первых, код языка берётся из языковой настройки каждого сайта, поэтому ru_RU превращается в ru; если у вас два варианта одного языка, например en-GB и en-US, доработайте код, чтобы сохранять регион. Во-вторых, цикл переключается между сайтами при каждом запросе: для нескольких языков это нормально, но в больших сетях результат стоит кэшировать. В-третьих, переключатель языка может использовать тот же поиск, чтобы вести прямо на переведённую страницу.

Пути 2 и 3: отдельные установки или свой код в одном сайте

Отдельные установки WordPress

Каждый язык может быть и полностью независимым сайтом на WordPress — в подкаталоге или на своём домене. Это самое сильное разделение, и оно работает на любом хостинге, но умножает обновления, резервные копии и учётные записи, а связь переводов приходится вести вручную или через API. Такой вариант подходит организациям, где каждая страновая команда ведёт свой сайт.

Один сайт с полями для каждого языка

Теоретически все языки можно хранить в одном сайте — например, в дополнительных полях и с префиксом URL через правила перезаписи. На практике это быстро разрастается: меню, виджеты, поиск, ярлыки, карты сайта, строки темы и данные магазина должны учитывать язык. Когда всё наконец заработает, окажется, что вы написали собственный плагин перевода, только без многолетнего тестирования, которое есть у зрелого решения.

Меню, строки темы и переключатель языка

Тексты записей — лишь часть переведённого сайта. В сети Multisite остальное настраивается проще, чем на одиночном сайте, но всё равно требует плана:

• Меню и виджеты хранятся отдельно для каждого сайта, поэтому у каждого языка своё меню с переведёнными названиями и ссылками.
• Строки темы и плагинов — кнопки, подписи форм, форматы дат — переводятся через языковые файлы (.po и .mo). WordPress сам загружает нужный файл по языковой настройке каждого сайта, если у темы есть перевод или его добавили.
• Ярлыки (slug) задаются для каждой записи, поэтому переведённые адреса вроде /ru/uslugi/ естественны, и их стоит использовать вместо копирования исходного ярлыка.
• Переключатель языка размещается в шаблоне шапки. Он может использовать тот же поиск по ключу группы, что и код hreflang, и вести на главную другого языка только тогда, когда перевода нет.

Заранее решите, как переключатель ведёт себя при отсутствии перевода. Скрыть язык без соответствующей страницы обычно понятнее для посетителя, чем отправить его на главную, которую он не искал. То же касается карт сайта: у каждого языкового сайта своя карта, и в неё должны попадать только страницы, которые действительно существуют на этом языке.

Редакционный процесс: как держать переводы в актуальном состоянии

Без плагина нет панели, которая отмечает устаревшие переводы, поэтому договоритесь о простой процедуре:

1. Присваивайте ключ группы при публикации исходной статьи, даже если перевода ещё нет.
2. Ведите простой список ключей групп и языков, на которых они есть, — таблицу или небольшой отчёт в админке.
3. При изменении оригинала отмечайте дату в этом списке, чтобы переводчики знали, какие версии нужно проверить.
4. Пусть заголовки, описания и ярлыки проверяет носитель языка: именно их первыми видит человек в поиске.
5. После каждого релиза, особенно после обновления темы или плагинов, проверяйте вывод hreflang на нескольких страницах.

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

Когда плагин перевода всё же лучше

Путь без плагина хорош, когда контент на разных языках отличается, когда языки ведут разные команды или когда нужен полный контроль над каждым URL. Плагин обычно лучше, если один и тот же контент переводится один к одному, если редакторы хотят переводить «бок о бок» или если магазину на WooCommerce нужны переведённые товары, цены и оформление заказа. Наш плагин AYM Multilingual создан как раз для второй группы, а оба варианта мы внедряем и сопровождаем в рамках услуги мультиязычный WordPress.

Какой бы путь вы ни выбрали, со стороны поиска всё работает одинаково: отдельные URL, взаимный hreflang и полностью переведённые метаданные. Эти правила и самые частые ошибки разобраны в нашем руководстве по hreflang.

Поделиться:XLinkedInWhatsApp