Виправлення роутінгу URL, редиректів та відновлення передачі параметрів (GCLID / UTM) в GA4
Контекст проблеми:
Дані про витрати, кліки та кампанії з Google Ads не передаються в Google Analytics 4 (в GA4 Ads cost = 0, конверсії в Google Ads = 0).
Авторазмітка (Auto-tagging) в Google Ads увімкнена, але підтримка Google зафіксувала критичну аномалію: з тисяч кліків по рекламі до GA4 доходить всього близько 8 сеансів. Роботи Google періодично фіксують помилку доступу до цільових сторінок («Landing page unavailable»).
В ході аудиту було встановлено, що сайт ламає рекламні посилання двома різними способами на рівні внутрішніх редиректів/обробки URL в WordPress.
ТЕХНІЧНІ ВИМОГИ І ЗАВДАННЯ:
1. Виправити злиття URL та видалення знака питання (?)
На головній сторінці сайту та на сторінках категорій WooCommerce при переході з реклами спрацьовує внутрішній редирект, який повністю стирає розділовий знак питання (?). Через це GET-параметри намертво зливаються з адресою сторінки. Сервер намагається знайти таку сторінку, видає помилку, а GA4 не може розпізнати мітки.
Приклад поломки на категоріях: .../product-category/truny/utm_source=google&utm_medium=cpc...
Приклад поломки на головній: https://www.lastway.com.ua/gclid=Cj0KCQjw0JnRBhDJARIsALobnXYY...
ЯК МАЄ БУТИ: Знак питання повинен залишатися на місці, розділяючи URL та параметри:
https://www.lastway.com.ua/product-category/truny/?utm_source=google...
https://www.lastway.com.ua/?gclid=Cj0KCQjw0JnRBhDJARIsALobnXYY...
2. Виключити GET-параметри з правила приведення URL до нижнього регістру (Lower Case)
На сторінках послуг (/ru/service/...) знак питання зберігається, але сайт примусово переводить всю строку URL разом з параметрами в нижній регістр.
Параметр gclid (ідентифікатор кліка Google) чутливий до регістру букв (case-sensitive). Коли хеш base64 переводиться в нижній регістр, він безповоротно руйнується, і GA4 його ігнорує.
Приклад поломки (всі букви стали маленькими):
.../?...&gclid=cj0kcqjw0jnrbhdjarisalobnxyy8gmug0_gfbdmrrkddfqsfqocgkpoiug6z3vvipu4vwug1knp5hqaak6healw_wcb
ЯК МАЄ БУТИ (оригінальний регістр Google Ads):
.../?...&gclid=Cj0KCQjw0JnRBhDJARIsALobnXYY8GMUG0_gFbDMrrKDdfQSfqoCGkpOIUG6z3VVIpU4vwUg1knP5HQaAk6hEALw_wcB
Де шукати проблему (коло підозрюваних плагінів):
Redirection: Перевірити глобальні правила (налаштування передачі Query Parameters). Має бути активно «Pass query parameters through».
Cyrillic URL Debug: Перевірити регулярні вирази, що обробляють кирилицю (наприклад, слово «гроби»). Можливо, плагін некоректно декодує рядок і затирає знак ?, або примусово опускає регістр параметрів.
Polylang / Connect Polylang for Elementor: Перевірити логіку редиректів при визначенні мови користувача (/ru/). Параметри не повинні модифікуватися при роутінгу мовних версій.
Yoast SEO: Перевірити, чи не увімкнена функція «Очистити постійні посилання» (Redirect ugly URLs).
Кастомні функції переведення посилань в нижній регістр в functions.php.
3. Перевірити доступність сайту для роботів Google (Рішення «Landing page unavailable»)
Переконатися, що захисні системи хостингу (фаєрвол, ModSecurity, Imunify360 або антибот-захист) не блокують юзер-агент GoogleAdsBot і перевірочних роботів Google при напливі рекламного трафіку. При необхідності додати IP-адреси та ботів Google в білий список (White List) на рівні сервера.
Проект закривається тільки тоді, коли ми побачимо, що посилання перестали ламатися, а Google Analytics успішно фіксує коректний gclid і пов'язує сесії з рекламою Ads в режимі реального часу. Якщо потрібно — почекаємо оновлення звітів по витратах.
Ціна договірна