Публікація багатомовних сторінок потребує двох рішень: чи правильно реалізовані зв’язки між мовними версіями та чи допомагає кожна сторінка своєму читачеві? Аналіз міжнародного пошуку, який Білл Гант опублікував 28 жовтня, дає своєчасний привід повернутися до цієї відмінності. Це аналіз практика, а не оголошення нового правила ранжування Google.
Наведений нижче список — запропонований нами робочий процес. Технічні вимоги звіряйте з документацією Google, а перевірку реалізації відокремлюйте від досвіду клієнта. Сторінка може мати правильну розмітку, але показувати непридатні умови доставки чи непрацюючий шлях звернення. Водночас корисний переклад також потребує узгодженої технічної реалізації.
1. Почніть із типової групи сторінок
До перевірки всього сайту оберіть одну важливу сторінку та її справжні відповідники. Для картки товару, опису послуги й редакційного матеріалу критерії приймання можуть різнитися. Запишіть цільову аудиторію, відповідального та кінцеву URL-адресу кожної версії. Не поєднуйте сторінки лише через схожі закінчення адрес.
У рекомендованій нами таблиці кожна версія має окремий рядок і чотири поля доказів: завдання клієнта, фактична HTTP-відповідь, мовні зв’язки та позначка відповідального про приймання. Збережіть показану браузером сторінку разом із налаштуваннями. Тоді перевірка спиратиметься на фактичний результат, а не на задум шаблону.
2. Перевірте зв’язки в обох напрямках
Документація Google вимагає зворотних посилань між альтернативними версіями та правильних кодів мов. Для української код мови — uk; назва каталогу ua не визначає значення атрибута. Перегляньте фактичні оголошення на відповідних сторінках і звірте кінцеві адреси. Таблиця із запланованими тегами не доводить правильності опублікованої реалізації.
Повторюйте таку перевірку після переспрямувань або зміни структури адрес. Фіксуйте перевірену сторінку, час завантаження та місце розбіжності. Призначте одну людину, відповідальну за усунення порушеного зв’язку між командами. Інакше локалізація може вважати переклад завершеним, а розробники та SEO-фахівці — припускати, що опубліковані посилання перевірив хтось інший.
3. Окремо перегляньте вибір канонічної версії
Google описує використання канонічних і мовних сигналів для схожих регіональних сторінок однією мовою. Винесіть такий випадок в окремий пункт перевірки. З’ясуйте, яку адресу бізнес вважає основним представленням, які змістовні регіональні відмінності існують і чи послідовно реалізація передає цей намір.
Не переписуйте правила канонікалізації лише через неочікуваний статус в одному інструменті. Зберіть докази зі сторінок, зіставте їх із запланованими зв’язками та визначте конкретну розбіжність. Запишіть запропоновану зміну й спосіб повернення до попереднього стану. Мета — обґрунтоване налаштування, а не обіцянка окремого ранжування кожної версії чи миттєвого опрацювання.
4. Доручіть місцевому редактору завдання клієнта
Попросіть представника ринку виконати дію, яку обіцяє сторінка: з’ясувати право на послугу, оцінити товар, надіслати запит ціни або знайти умови доставки. Нехай він зафіксує перший незрозумілий момент. Перевіряйте весь шлях, наступну сторінку та відповідь форми. Це наша рекомендація щодо досвіду клієнта, а не додаткова вимога пошукової системи до розмітки.
Завершуйте публікацію двома явними результатами: технічні зв’язки прийняті, завдання місцевого клієнта виконане. Для невдалого пункту потрібні відповідальний і дата повторної перевірки. Після публікації відстежуйте результати сторінок за зіставними періодами й однаковими бізнес-визначеннями, не приписуючи зміни трафіку самим тегам. Так підтримка hreflang стає частиною відповідального видавничого процесу, а корисність місцевого досвіду зберігає окремого власника.
Джерела
- Bill Hunt: The Hreflang Magic Trick – It Routes, It Doesn’t Rank
- Google Search Central: localized versions
- Google Search Central: managing multilingual and multiregional sites
