Розв'яжіть редирект /goto Google у вашому SERP-пайплайні

Резюме за 30 секунд

26 серпня 2026 року Google підтвердив, що посилання в результатах пошуку тепер проходять через google.com/goto?url=[зашифрований токен], перш ніж дістатися до призначення. Про це повідомив Баррі Шварц у Search Engine Roundtable та Search Engine Land, а речник Google підтвердив, що це частина «довгострокових технічних заходів проти форм зловживань, які еволюціонують».

Якщо ваша команда витягує цільові URL з результатів пошуку Google (моніторинг позицій, скрейпінг SERP, збір даних для ШІ), щойно зламалося одне припущення: справжнього URL більше не видно в посиланні. Він зашифрований у токені, який браузер слідує як звичайний редирект.

Хороша новина: це можна виправити, і виправлення менше, ніж уявляє більшість. Токен не можна розшифрувати, але його можна розв'язати одним додатковим HTTP-запитом, а оскільки він детермінований — закешувати. Ця стаття проведе вас через виправлення на 30 хвилин: виявити зміну, безпечно розв'язати її та переконатися, що звіти досі показують правильні сторінки. Якщо ви не скрейпите SERP і не зіставляєте позиції з URL, витягнутими з цих сторінок, перейдіть одразу до «Що зміна не зачіпає». На вашому сайті нічого не змінюється.

Що саме змінилося

Багато років посилання результату Google несло справжнє призначення прямо у самому посиланні:

<a href="https://yoursite.com/landing-page?utm_...">...

Тепер той самий результат може нести транзитне посилання:

<a href="https://www.google.com/goto?url=TtFp1Lc2026...*">...

Після переходу Google повертає HTTP-редирект до призначення. Два важливі моменти щодо того, як це працює:

• Токен зашифрований і захищений від підробки. Згідно з незалежним реверс-інжинірингом (опублікованим у серпні 2026 року), він складається з маркера в 1 байт, 4-байтового ідентифікатора ключа та даних у форматі Tink. Змініть один символ — і Google відповість HTTP 400. Без ключів Google ви не зможете ні підробити токен, ні декодувати URL.
• Токен детермінований. Один і той самий цільовий URL завжди дає один і той самий токен. Це вже робить усе виправлення дешевим: розв'яжіть один раз — і далі використовуйте кеш токена.

Дерек Перкінс із Nozzle спостерігав розгортання близько до «100%» у кількох постачальників резидентних IP, і саме тому цього разу це більше, ніж експеримент.

Що переживає зміну

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

Що зміна не зачіпає

• Позиції й трафік. Система ранжування Google не має стосунку до того, які посилання вона рендерить.
• Дані Google Search Console. Позиції, покази та кліки в GSC походять із внутрішніх даних Google і не порушені.
• Краулери, що відвідують ваш сайт. Googlebot, GPTBot і будь-які боти, що обходять ваші сторінки, не торкаються google.com/goto. Він з'являється лише в посиланнях, які Google показує вам.
• Bing та інші пошуковики. Це зміна виключно з боку Google.

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

Перевірте, чи вас це стосується

Виконайте чотири перевірки. Перші дві займають п'ять хвилин; останні дві — розмова з вашим постачальником.

Якщо все чисто — це не ваша справа: закладіть цю сторінку та рухайтеся далі.

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

Крок 1: Виявіть токени там, де вони з'являються

Що робити. У вашому скрипті витягнення SERP зберіть усі посилання результатів і позначте все, що починається з https://www.google.com/goto?url= (збігайте також «голий» /goto?url=, що трапляється на деяких поверхнях, і url=, за яким іде корисне навантаження в стилі base64). Записуйте частку позначених посилань на один запит — це ваш індикатор розгортання. І, зі спостереження Дерека Перкінса: розгортання нерівномірне між діапазонами IP, тож відстежуйте його за постачальником, а не в загальному вигляді.

Очікуваний результат. Один goto_rate на запит. 0% означає, що ваше джерело досі віддає прямі посилання; 100% — повну токенізацію.

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

Відновлення. Якщо зразок дає нуль входжень, але ви підозрюєте токенізацію, перевірте, чи ваше витягнення читає DOM, відрендерений JavaScript, а не сирий HTML. Токени можуть з'являтися в рендереній розмітці, навіть коли сира відповідь лишається в старому форматі.

Крок 2: Розв'яжіть один токен одним редиректом

Що робити. Коли результат несе токен, слідуйте за посиланням на сервері з вимкненим відстеженням редиректів і прочитайте заголовок Location:

curl -sI "https://www.google.com/goto?url=TtFp1Lc..." | grep -i location

Відповідь — HTTP 3xx до справжнього призначення. Збережіть її. Два правила роблять цей крок дешевим і безпечним:

• Кешуйте за токеном, а не за URL. Оскільки токенізація детермінована, досить одного розв'язання на токен. Зберігайте token -> resolved_url і використовуйте постійно.
• Ніколи не крауліть `google.com/goto` як сторінку. Google додав Disallow: /goto? до власного robots.txt наприкінці липня 2026 року. Ця адреса явно не призначена для завантаження краулерами; правильний фетчер легко слідує за посиланням-токеном і читає лише ланцюжок редиректів; зламаний фетчер індексує чи архівує сам URL goto та забруднює ваші дані. До кінця липня на самому google.com було проіндексовано майже 3 750 таких URL.

Контроль витрат перед стартом: перший прохід по SERP з сотнями результатів — це сотні додаткових запитів до google.com, саме той клас навантаження, який відстежує детекція ботів Google. Детермінований кеш зводить це до одного запиту на унікальний токен, тож не економте на цьому кроці.

Очікуваний результат. Стабільна таблиця відповідностей між токенами та призначеннями. Перевірте десять випадкових токенів у браузері: кожен має вести на осмислену сторінку.

Перевірка якості. Підтвердьте, що довжина токена стабільна між різними URL і що однакові цільові URL завжди дають однаковий токен. Якщо відповідність ламається — була ротація ключів (див. Крок 5).

Відновлення. Токен, що повертає 400, підроблений, обрізаний або походить із простроченої сесії; перескрейпте SERP і спробуйте знову. Дві невдачі підряд зазвичай означають застарілий HTML в архіві, а не зламаний токен.

Крок 3: Зберігайте призначення, а не обгортку

Що робити. Решта пайплайну (зіставлення ключовик-сторінка, перевірки індексації, аудит схем) має бачити цільовий URL. Тож після Кроку 2 зберігайте три поля на результат: resolved_url, token і accessed_at. Приберіть посилання goto з колонки URL будь-якого звіту; URL google.com у звіті за ключовиками — це помилка якості даних у десятках виглядів.

Якщо цього тижня резолвер додати не виходить, безпечний проміжний крок — повністю пропустити призначення, а не зберігати токен: дані позицій і ранжування лишаються значимими, порожньою буде лише колонка URL. Інструмент, який чесно пише «без URL», набагато легше інтерпретувати, ніж той, що подає рядок токена як справжню адресу.

Очікуваний результат. Звіт, у якому 100% рядків — http(s)-URL ваших доменів і жодного рядка google.com.

Перевірка якості. Зіставте дані на рівні URL із Search Console по десяти ключовиках. Рядки мають збігатися. Якщо Search Console дає позицію URL, який ваш звіт називає «не знайдено», у резолвері чи парсері є діра.

Відновлення. Якщо невелика частина URL досі не розв'язується, записуйте їхні токени окремо. Більшість невдач сходиться до двох винуватців із Кроку 2: застарілий HTML або стіна детекції ботів на наступному запиті.

Крок 4: Перевірте, що робить ваш постачальник

Що робити. Якщо ви залежите від інструмента моніторингу позицій чи SERP API (зокрема побудованих на скрейплених даних Google), розгортання триває вже тижні. Поставте ці п'ять питань і звіряйте з ними будь-які зміни у звітах:

Очікуваний результат. Або підтверджене виправлення, або зрозуміла причина піти. За 30 днів ви маєте вміти зшивати URL зі своїх звітів із журналом змін сайту без шуму.

Запасний шлях. Якщо за тиждень від постачальника немає покращення: замініть цю точку даних на Google Search Console API для позицій, адже вона походить прямо з даних Google і ніколи не бачить токена. Ціна — трохи менше деталей на рівні посилання; це прийнятно, якщо вашим рішенням потрібна точність, а не сторонні функції.

Крок 5: Слідкуйте за наступним кроком

Механізм не зупиняється. Щомісяця відстежуйте три речі:

1. Ротація ключів. Зразок реверс-інжинірингу знайшов чотири ідентифікатори ключів у обігу, з одним домінантним («ee47aa4d», близько 62% токенів). Якщо з'явиться п'ятий ключ і домінантна частка зрушить — очікуйте інвалідації кешу: перерозв'яжіть токени на ротації.
2. Поширення на інші поверхні. /goto також помічено в платних посиланнях та інших типах результатів. Якщо ваші інструменти торкаються реклами чи зображень — розширюйте пошук із Кроку 1.
3. Продовження посилення. Це частина довшого ланцюжка: примусовий JavaScript-рендеринг (початок 2025), запуск SearchGuard, закриття &num=100 (вересень 2025) і DMCA-дія за Секцією 1201 проти SerpApi (грудень 2025). Кожен пункт задокументовано окремо; стаття про реверс-інжиніринг збирає більшість. Очікуйте, що дістати фінальний URL стане важче, а не легше.

Перевірка кінцевого результату

• [ ] Детектор із Кроку 1 працює в CI або за розкладом і логує goto_rate на запит
• [ ] Усі зразкові токени розв'язуються на справжні призначення, перевірені в браузері
• [ ] Нуль URL google.com/goto у ваших звітах (гріп по останньому експорту)
• [ ] Десять ключовиків збігаються з Search Console рядок у рядок
• [ ] Постачальник підтвердив стратегію розв'язання, або дані позицій ідуть через GSC API
• [ ] У вашому місячному ритмі є окрема перевірка ротації ключів

Часті питання

Це впливає на мої позиції чи трафік? Ні. Змінюється шлях кліку; система ранжування, результати й те, що бачить користувач, не змінюються. Ваші органічні показники під загрозою лише якщо інструмент, який ви експлуатуєте, почне подавати хибні дані.

Чи можна декодувати токен goto? Зовні — ні. Це зашифроване навантаження у форматі Tink, а зміна одного символу повертає HTTP 400, тож підробка також неможлива. Практичний шлях — піти за редиректом і прочитати заголовок Location, саме це робить браузер.

Чи законно скрейперу слідувати за посиланнями `/goto`? Практично це те, що робить клік у браузері, але Google заблокував /goto? у власному robots.txt, а умови обмежують автоматизований доступ до результатів пошуку. Якщо ви скрейпите SERP, ви вже на «тій» стороні умов; це розгортання нічого не змінює, воно лише робить це важчим. Оберіть свою позицію щодо комплаєнсу до того, як будувати резолвер.

Чи треба мені щось змінити на моєму сайті? Ні. Зміна повністю в посиланнях, які рендерить Google. Перевіряти треба інструменти, що читають SERP від вашого імені, — це Крок 4.

Авторка: Олівія Стоун, дослідниця SERP-інтелекту в Auspia (аналізує понад 25 000 запитів). Пише про аналіз SERP, патерни ранжування та те, як зміни в результатах пошуку впливають на дані позицій.