У нас есть несколько корпоративных блогов, для каждой страны свой. Вернее, физически это один блог на Wordpress, но используется плагин WPML для поддержки разных языков. У каждого языка - свой домен.
Часто бывает, что одна и та же статья публикуются в нескольких странах, иногда с небольшими изменениями (например, меняют спеллинг с британского на американский). Все вроде работало, и вдруг неожиданно начинаются 301 redirects на неправильный домен. Допустим, есть три варианта статьи:
www.example.com/blog/my-article/
www.example.ca/blog/my-article/
www.example.co.uk/blog/my-article/
Первые два начали перенаправляться на, допустим, www.example.co.uk/blog/my-article/. А другие статьи - на другой домен.
Оказалось, все дело в WMPL. Штатный способ работы - это пользоваться функцией "перевода". Т.е. что бы у тебя был как бы один логический "пост", но с "переводами" на другие языкы. А у нас, как оказалось, этой функцией иногда пользовались, а иногда просто создавали копии постов для другого языка. Если один и тот же slug используется для не связанных друг с другом постов, то WPML случайным образом выбирает один (самый старый?) и всё перенаправляет туда.
Но почему раньше не было этой проблемы? Видимо, обновили WPML, а предыдущая версия не была такой жёсткой.
Что делать? Если таких проблемных статьей две-три, то, конечно, легко всё исправить: надо выбрать один, "базовый" пост, вручную добавить туда "переводы", а посты с остальными вариантами стереть. Но у нас, как оказалось, таких постов почти тысяча. Замучаешься вручную делать, и ошибиться легко (ведь для каждого "перевода" надо скопировать не только текст, но и другие параметры),
Есть более простой вариант - поменять slugs, чтобы они были уникальными. Но, во-первых, это означает смену URLs, что очень плохо для SEO. Во-вторых, это решает проблему только частично: по-хорошему, все переводы должны быть связаны друг с другом с помощью мета-тэга hreflang. Если это не сделать, Гугль может сказать: "Так, а что это у вас почти один и тот же текст в пяти вариантах? Спамите, господа?" WMPL берет на себя hreflang, но, опять-таки, для этого нужно связать посты в один логический пост с переводами.
А может, просто откатить назад версию плагина WMPL? Можно, но, во-первых, есть шанс, что в будущем всё равно когда-то придется установить более новую версию, и проблема вернется. Во-вторых, мы не решаем проблему, а только её маскируем (ведь проблема с hreflang остается). В-третьих, просто и самим пользователям было бы удобнее работать, когда переводы сгруппированы.
Так что сжалился я над юзерами и написал небольшой SQL, который всё починил. Сэкономил им неделю работы. Идея такая: когда мы группируем посты, то физически их остается несколько (записи в таблице wp_posts не трогаем), но просто в wp_icl_translations нужно им всем присвоить одинаковое значение trid. Неважно, какое - главное, чтобы уникальное. Trid - это как бы id группы переведенных постов.
Часто бывает, что одна и та же статья публикуются в нескольких странах, иногда с небольшими изменениями (например, меняют спеллинг с британского на американский). Все вроде работало, и вдруг неожиданно начинаются 301 redirects на неправильный домен. Допустим, есть три варианта статьи:
www.example.com/blog/my-article/
www.example.ca/blog/my-article/
www.example.co.uk/blog/my-article/
Первые два начали перенаправляться на, допустим, www.example.co.uk/blog/my-article/. А другие статьи - на другой домен.
Оказалось, все дело в WMPL. Штатный способ работы - это пользоваться функцией "перевода". Т.е. что бы у тебя был как бы один логический "пост", но с "переводами" на другие языкы. А у нас, как оказалось, этой функцией иногда пользовались, а иногда просто создавали копии постов для другого языка. Если один и тот же slug используется для не связанных друг с другом постов, то WPML случайным образом выбирает один (самый старый?) и всё перенаправляет туда.
Но почему раньше не было этой проблемы? Видимо, обновили WPML, а предыдущая версия не была такой жёсткой.
Что делать? Если таких проблемных статьей две-три, то, конечно, легко всё исправить: надо выбрать один, "базовый" пост, вручную добавить туда "переводы", а посты с остальными вариантами стереть. Но у нас, как оказалось, таких постов почти тысяча. Замучаешься вручную делать, и ошибиться легко (ведь для каждого "перевода" надо скопировать не только текст, но и другие параметры),
Есть более простой вариант - поменять slugs, чтобы они были уникальными. Но, во-первых, это означает смену URLs, что очень плохо для SEO. Во-вторых, это решает проблему только частично: по-хорошему, все переводы должны быть связаны друг с другом с помощью мета-тэга hreflang. Если это не сделать, Гугль может сказать: "Так, а что это у вас почти один и тот же текст в пяти вариантах? Спамите, господа?" WMPL берет на себя hreflang, но, опять-таки, для этого нужно связать посты в один логический пост с переводами.
А может, просто откатить назад версию плагина WMPL? Можно, но, во-первых, есть шанс, что в будущем всё равно когда-то придется установить более новую версию, и проблема вернется. Во-вторых, мы не решаем проблему, а только её маскируем (ведь проблема с hreflang остается). В-третьих, просто и самим пользователям было бы удобнее работать, когда переводы сгруппированы.
Так что сжалился я над юзерами и написал небольшой SQL, который всё починил. Сэкономил им неделю работы. Идея такая: когда мы группируем посты, то физически их остается несколько (записи в таблице wp_posts не трогаем), но просто в wp_icl_translations нужно им всем присвоить одинаковое значение trid. Неважно, какое - главное, чтобы уникальное. Trid - это как бы id группы переведенных постов.
Комментариев нет:
Отправить комментарий