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

Нижче — що саме варто перевіряти, які інструменти для цього підходять і де найчастіше ховаються помилки.
Що на сайті залежить від країни відвідувача
Географію відвідувача сервер найчастіше визначає за IP. Від неї може залежати багато речей:
- мова і регіональна версія — автоматичний вибір мови або підпапки на кшталт /pl/ чи /de/;
- валюта, ціни, податки й способи доставки;
- редиректи за IP — переадресація на регіональний домен або сторінку «сервіс недоступний у вашій країні»;
- банери згоди на cookie, які часто показують лише відвідувачам з певних регіонів;
- рекламні та аналітичні скрипти з різними налаштуваннями для різних ринків;
- вміст, що віддає CDN — різні копії сторінок у різних точках присутності.
Будь-який із цих пунктів може зламатися непомітно для команди, бо локально всі бачать один і той самий варіант.
Чим перевіряти: від заголовків до справжнього IP
Підміна мови та часового поясу
Інструменти розробника в браузері дозволяють змінити мову, часовий пояс і геолокацію браузера. Це корисно для перевірки логіки на фронтенді, яка читає Accept-Language або Geolocation API. Але сервер, що визначає країну за IP, такої підміни не помітить.
VPN
VPN змінює IP усього комп'ютера. Для разової перевірки достатньо, проте вибір міст обмежений, адреси здебільшого належать дата-центрам, а паралельно порівняти кілька країн не вийде. До того ж частина систем визначення гео трактує адреси дата-центрів інакше, ніж домашні.
Проксі з вибором країни й міста
Проксі підключаються на рівні браузера, профілю чи окремого запиту. Можна відкрити три профілі з трьома країнами поруч або прогнати curl-запити по списку регіонів у скрипті. Для тестування найближчий до реальності варіант — резидентські проксі, тобто IP домашніх провайдерів: сервер бачить таку саму адресу, як у звичайного відвідувача. Деякі сервіси, як-от Prokso, дають вибір країни, а в розширеному режимі — регіону, міста й оператора (ASN). Можливості такого гео описано на сторінці про резидентські проксі з вибором країни, міста та оператора.
Як не обдурити себе під час перевірки
Перед будь-яким тестом переконайтеся, що запит справді йде з потрібної країни. Найпростіше — відкрити в тому ж профілі сервіс, який показує ваш IP, країну, місто й провайдера, і перевірити, чи не «просочується» справжня адреса через WebRTC.
Ще кілька пасток:
- Невідповідність сигналів. IP із Німеччини, а мова браузера й часовий пояс — українські. Сайт може обрати мову за браузером, а валюту за IP, і ви побачите змішаний варіант, якого в реального відвідувача не буде. Налаштовуйте профіль цілісно.
- Cookie з минулих візитів. Якщо сайт уже запам'ятав ваш вибір мови чи регіону, редирект за IP не спрацює. Тестуйте в чистому профілі або вікні інкогніто.
- Місто — приблизне. Бази геолокації надійно визначають країну, а місто — з похибкою. Якщо логіка сайту прив'язана до міста, перевірте кілька адрес.
Редиректи за IP: що перевіряти
Автоматичні переадресації за країною — часте джерело проблем і для користувачів, і для пошукової індексації. Пошукові роботи здебільшого заходять з обмеженого набору країн, тож жорсткий редирект може сховати від них регіональні версії.
- Перевірте, що відвідувач з кожної цільової країни потрапляє на правильну версію і може вручну перемкнутися на іншу.
- Подивіться код відповіді: тимчасовий 302 чи постійний 301. Для переадресацій за гео постійний редирект зазвичай помилка.
- Переконайтеся, що атрибути hreflang вказують на сторінки, які відкриваються без примусового переходу.
- Перевірте ланцюжки: редирект за гео плюс редирект зі слешем плюс редирект на HTTPS — це три зайві запити.
Зручно робити це з консолі: curl з параметром проксі і прапорцем для показу заголовків одразу покаже статус, адресу переходу й заголовки кешу.
CDN і кеш: чому різні країни бачать різні версії
CDN зберігає копії сторінок у точках присутності по всьому світу. Якщо сервер віддає різний вміст для різних країн, а кеш цього не враховує, відвідувач з Польщі може отримати сторінку, закешовану для німецького користувача.
Що перевірити:
- заголовок Vary і ключ кешу: чи враховують вони країну або мову;
- заголовки, що показують статус кешу (влучання чи промах) і точку присутності;
- час життя кешу для сторінок з цінами, щоб після оновлення прайсу користувачі не бачили старі цифри;
- швидкість завантаження з різних регіонів — далека точка присутності або її відсутність помітно уповільнює сайт.
Для таких тестів зручний фіксований IP: кілька запитів поспіль з однієї адреси показують, як поводиться кеш на повторних зверненнях. Ротація з новою адресою на кожен запит краще підходить для масової перевірки списку сторінок по різних країнах.
Мінімальний чек-лист перед запуском на новому ринку
- правильна мова, валюта й ціни для відвідувача з цільової країни;
- можливість вручну змінити регіон без повернення назад редиректом;
- коректні hreflang і відсутність постійних гео-редиректів;
- банер згоди та аналітика працюють відповідно до вимог регіону;
- CDN віддає правильну локалізовану версію, а кеш не змішує країни.
Такий прогін займає пів години, а помилки в локалізації інакше виявляються лише тоді, коли про них напишуть клієнти.