Аварійний ремонт мультимовного WordPress: зникли переклади та мовні версії

Зникнення перекладів або окремих мовних версій у WordPress може проявлятися по-різному: сторінки повертають помилку 404, перемикач мов не показує потрібну мову, замість перекладеного матеріалу відкривається оригінал, а в адміністративній панелі розриваються зв’язки між мовними копіями.

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

Перед будь-якими змінами зробіть резервну копію файлів і бази даних у поточному стані. Якщо сайт працює нестабільно, не видаляйте мовні плагіни, переклади чи записи з бази даних навмання: такі дії можуть ускладнити подальше відновлення.

Як визначити джерело збою перекладів

Мультимовний сайт складається не лише з текстів. Для кожної мовної версії зберігаються окремі записи, метадані, зв’язки між перекладами, налаштування мов, URL та правила їх обробки. Пошкодження будь-якого з цих елементів може створити враження, що переклади зникли повністю.

• Збій WPML, Polylang або іншого мовного плагіна. Після оновлення може змінитися структура таблиць, формат метаданих або логіка створення мовних зв’язків.
• Відновлення неповної резервної копії. Наприклад, файли сайту повернулися до попереднього стану, а база даних залишилася новою, або навпаки.
• Помилки бази даних. Пошкоджені таблиці, невдала міграція чи частково виконаний імпорт можуть приховати записи та зв’язки між ними.
• Зміна структури постійних посилань. Після переходу на інший формат URL старі мовні адреси можуть почати повертати 404.
• Конфлікт плагінів або теми. Кастомні фільтри, оптимізатори, кешування та плагіни редиректів іноді блокують частину мовних сторінок.
• Видалення або зміна таксономій. Для категорій, тегів і спеціальних типів записів мовні версії можуть зникнути через неправильну синхронізацію.
• Шкідливий код. Вірус може змінювати налаштування, редиректи, права доступу або вміст бази даних.

Спочатку потрібно визначити масштаб проблеми: зникли самі записи, лише зв’язки між перекладами чи тільки доступ до сторінок через URL. Це різні ситуації, і відновлення кожної з них потребує окремої послідовності дій.

Резервні копії та налаштування мовного плагіна

Почніть із діагностики в адміністративній панелі WordPress. Перевірте, чи активний мовний плагін, чи не з’явилися повідомлення про помилки та чи відображаються доступні мови в його налаштуваннях. Не перевстановлюйте плагін одразу: без резервної копії це може призвести до зміни або втрати службових даних.

Для WPML важливо перевірити список мов, спосіб формування URL, налаштування перекладу типів записів і сторінок, а також стан таблиць і службових даних плагіна. Якщо використовується Polylang, слід перевірити мови, мовні атрибути записів, зв’язки перекладів і правила для префіксів у URL.

• Перевірте, чи доступні оригінальні записи в розділі «Сторінки» або «Записи».
• Подивіться, чи мають вони позначку мови та пов’язані перекладені версії.
• Порівняйте URL для різних мов: це можуть бути префікси на кшталт /uk/, /en/, окремі домени або піддомени.
• Перевірте, чи не змінилися структура постійних посилань і налаштування головної сторінки для кожної мови.
• Оновіть правила перезапису безпечним способом: у WordPress це зазвичай роблять через збереження налаштувань постійних посилань, але перед цим бажано мати резервну копію.
• Тимчасово очистіть кеш WordPress, серверний кеш і кеш CDN, якщо старі або неправильні URL продовжують відображатися.

Окремо перевірте журнали помилок PHP і вебсервера. Повідомлення про критичну помилку, відсутній клас, помилку SQL або перевищення ліміту пам’яті можуть пояснити, чому мовний плагін перестав обробляти сторінки.

Якщо в адміністративній панелі записи присутні, але на сайті їх немає, імовірніше, проблема пов’язана з URL, кешем, шаблоном або фільтрами плагіна. Якщо записи відсутні й у базі даних, необхідно аналізувати резервні копії та стан таблиць.

Відновлення мовних URL

Зв’язок між мовними сторінками визначає, які записи є перекладами один одного. Якщо його втрачено, сторінки можуть залишатися доступними окремо, але перемикач мов не працюватиме, а пошукові системи не зможуть коректно визначити відповідні версії.

1. Зафіксуйте поточний стан. Створіть копію файлів і бази даних, запишіть список доступних мов, проблемних URL та сторінок, які ще відкриваються.
2. Визначте оригінали та переклади. Зіставте сторінки за заголовками, URL, датами створення, вмістом і метаданими. Не покладайтеся лише на схожість назв.
3. Перевірте типи записів. Зв’язки можуть стосуватися не тільки сторінок, а й записів блогу, товарів, категорій, тегів і кастомних типів контенту.
4. Відновіть зв’язки штатними інструментами плагіна. Для кожної мовної сторінки виберіть відповідний переклад, збережіть зміни та перевірте результат на фронтенді.
5. Перевірте перемикач мов. Він має показувати доступні переклади, не створювати циклічних редиректів і не вести на сторінки з неправильним доменом або префіксом.
6. Протестуйте шаблони. Переконайтеся, що мовна версія коректно відображається в меню, віджетах, хлібних крихтах, картках товарів і формах.

Якщо сторінок багато, ручне відновлення може бути ризикованим. Масове редагування через SQL або сторонні скрипти здатне змінити не ті записи, дублювати зв’язки чи пошкодити метадані. Такі роботи виконують лише після повної резервної копії та перевірки на тестовій копії сайту.

Коли відновлюється резервна копія, потрібно узгодити версії файлів, бази даних і мультимовного плагіна. Часткове повернення окремих таблиць без розуміння їхніх залежностей може погіршити ситуацію. Якщо незрозуміло, які дані є актуальними, варто залучити спеціаліста з відновлення WordPress.

Перевірка SEO після ремонту

Після відновлення сторінок і зв’язків необхідно перевірити технічні сигнали для пошукових систем. Навіть якщо сайт відкривається для користувачів, помилки в мовних анотаціях можуть заважати розпізнаванню відповідних версій. Орієнтуйтеся на документацію Google щодо локалізованих сторінок; коректні анотації не гарантують індексацію або позиції.

• Переконайтеся, що кожна мовна сторінка має коректні альтернативні посилання на доступні мовні версії.
• Перевірте відповідність кодів мов і регіонів, наприклад uk, en або узгоджені регіональні варіанти.
• Переконайтеся, що URL у hreflang ведуть на сторінки з кодом відповіді 200, а не на 404, редиректи чи сторінки заборонені для індексації.
• Перевірте взаємність посилань: якщо українська версія вказує на англійську, англійська сторінка також має коректно посилатися на українську.
• Перевірте наявність посилання x-default, якщо воно передбачене логікою сайту.
• Переконайтеся, що sitemap містить актуальні мовні URL, а видалені або технічні сторінки не потрапляють до карти сайту.
• Перевірте, чи не генерує кілька плагінів одночасно різні sitemap або суперечливі метатеги.
• Після змін очистіть кеш і повторно перевірте заголовки, канонічні URL та мовні атрибути в коді сторінки.

Не варто механічно додавати до sitemap усі URL, які коли-небудь існували. До карти сайту мають потрапляти доступні, канонічні та призначені для індексації сторінки. Для великих сайтів корисно окремо перевірити карти для різних типів контенту та мов.

Як уникнути втрати перекладів надалі

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

• Налаштуйте регулярні резервні копії файлів і бази даних із зберіганням кількох попередніх версій.
• Зберігайте копії не лише на тому самому хостингу, а й у незалежному сховищі.
• Перед оновленням WordPress, теми або мовного плагіна створюйте контрольну резервну копію.
• Тестуйте великі оновлення на копії сайту та перевіряйте сторінки всіх мов після завершення робіт.
• Не змінюйте структуру URL без плану редиректів і перевірки sitemap та hreflang.
• Обмежте доступ до адміністративної панелі, використовуйте складні паролі, двофакторну автентифікацію та актуальні версії компонентів.
• Регулярно перевіряйте журнали сервера, критичні помилки, стан диска та працездатність бази даних.
• Контролюйте роботу кешування, CDN, плагінів оптимізації та автоматичних перекладачів.

Якщо переклади зникли після оновлення, перенесення, зараження або відновлення резервної копії, не робіть багато несистемних змін поспіль. Кожна така дія може перезаписати потрібні дані та ускладнити визначення першопричини.

Спеціаліст потрібен, коли не відкривається адміністративна панель, є ознаки пошкодження бази даних або вірусної активності, відсутні актуальні резервні копії, зламані права доступу чи проблема зачіпає десятки й сотні мовних сторінок. У таких випадках спочатку проводять діагностику, визначають, які дані збереглися, і лише потім обирають безпечний спосіб ремонту або відновлення.

Якщо потрібне відновлення сайту, передайте спеціалісту приклади непрацюючих адрес, час появи проблеми й інформацію про останні зміни. Не відновлюйте стару базу поверх нових замовлень без плану збереження актуальних даних.

Після ремонту домовтеся про регулярні перевірки всіх мов. Корисні орієнтири — перелік робіт технічної підтримки без розмитих обіцянок та пояснення, що замовник має отримувати щомісяця в межах підтримки сайту. Звіт повинен фіксувати виконані перевірки, а не лише факт оновлення плагінів.