Google выкатил Gemini 2.5 Computer Use
Google представил новый инструмент. Это специализированная модель, построенная на базе Gemini 2.5 Pro, которая умеет взаимодействовать с графическими интерфейсами так же, как человек: кликать, скроллить, печатать и заполнять формы.
Работает так: получает скриншот и задачу -> анализирует -> генерирует действие (клик, ввод текста) -> выполняет его -> получает новый скриншот и повторяет.
В модель встроены защитные механизмы. Для потенциально опасных действий (например, совершение покупки) система запрашивает подтверждение пользователя.
Модель уже доступна в режиме превью через Gemini API в Google AI Studio и Vertex AI.
https://ai.google.dev/gemini-api/docs/computer-use
https://cloud.google.com/vertex-ai/generative-ai/docs/computer-use
Еще из интересного в новости, что команда Google уже использует его для "починки" упавших UI-тестов, значит инструмент сначала был разработан для внутреннего пользования.
Мое внимание привлек этот тул тем, что потенциально выглядит "заменой" Zennoposter еще и от Google.Закинуть скрин, сказать что делать выглядит темой, конечно. Посмотрим на практике!
Update: Про скрин я не так понял из статьи, оно само использует скрины под капотом. Тут можно поиграться: http://gemini.browserbase.com/
Пока из интересного, что он решает рекапчу и даже ХОРОШО. Отмечает везде правильно!
Вижу кейс с решением капч через Computer Use...
Google представил новый инструмент. Это специализированная модель, построенная на базе Gemini 2.5 Pro, которая умеет взаимодействовать с графическими интерфейсами так же, как человек: кликать, скроллить, печатать и заполнять формы.
Работает так: получает скриншот и задачу -> анализирует -> генерирует действие (клик, ввод текста) -> выполняет его -> получает новый скриншот и повторяет.
В модель встроены защитные механизмы. Для потенциально опасных действий (например, совершение покупки) система запрашивает подтверждение пользователя.
Модель уже доступна в режиме превью через Gemini API в Google AI Studio и Vertex AI.
https://ai.google.dev/gemini-api/docs/computer-use
https://cloud.google.com/vertex-ai/generative-ai/docs/computer-use
Еще из интересного в новости, что команда Google уже использует его для "починки" упавших UI-тестов, значит инструмент сначала был разработан для внутреннего пользования.
Мое внимание привлек этот тул тем, что потенциально выглядит "заменой" Zennoposter еще и от Google.
Update: Про скрин я не так понял из статьи, оно само использует скрины под капотом. Тут можно поиграться: http://gemini.browserbase.com/
Пока из интересного, что он решает рекапчу и даже ХОРОШО. Отмечает везде правильно!
Вижу кейс с решением капч через Computer Use...
Кейс: вылет главной страницы из-за социальной сети
На одном из сайтов столкнулся с тем, что вылетела главная страница из результатов выдачи, даже по брендовым запросам. При этом при проверке в Search Console страница была в индексе.
Из-за NDA допустим, что домен сайта это
Мной было проведено глубокое расследование и выявлен ряд гипотез, одна из которых экспериментально оказалась правильной.
По истории выдачи в Ahrefs оказалось, что перед вылетом вместо
Выяснилось, что незадолго до вылета через структурированные данные у бренда были подвязаны соцсети через sameAs, в том числе X.com.
Обнаружилось, что компания указала домен сайта в био просто текстом
После удаления
Вероятно, из-за этой путаницы Google привязал к сущности бренда домен с
В одном из следующих постов расскажу еще один нетривиальный кейс вылета главной страницы.
На одном из сайтов столкнулся с тем, что вылетела главная страница из результатов выдачи, даже по брендовым запросам. При этом при проверке в Search Console страница была в индексе.
Из-за NDA допустим, что домен сайта это
example.comМной было проведено глубокое расследование и выявлен ряд гипотез, одна из которых экспериментально оказалась правильной.
По истории выдачи в Ahrefs оказалось, что перед вылетом вместо
https:// версии главной страницы ненадолго появилась её http:// версия.Выяснилось, что незадолго до вылета через структурированные данные у бренда были подвязаны соцсети через sameAs, в том числе X.com.
Обнаружилось, что компания указала домен сайта в био просто текстом
example.com, который X.com сам преобразует в ссылку с http://. При этом ссылки в правильном поле, которое позволяет заполнить X.com, не было. Интерпретатор Google обрабатывает данные сверху вниз, поэтому посчитал главной ссылкой именно эту.После удаления
example.com из био и указания правильной ссылки в нужном поле главная страница вернулась.Вероятно, из-за этой путаницы Google привязал к сущности бренда домен с
http://. Почему он отдал приоритет X.com, для меня странно, но таков Google.В одном из следующих постов расскажу еще один нетривиальный кейс вылета главной страницы.
Проблема BiDi-текста в RTL
При оптимизации сайта на арабском, столкнулся с важной особенностью RTL-языков (арабский, иврит): "проблема двунаправленного текста" (BiDi). Она возникает, когда LTR и RTL текст смешиваются, особенно рядом с нейтральными символами (пробелы, точка, запятая, :, -, /). Особый гемор это <title>.
Браузер не понимает, к какой части (LTR или RTL) относится нейтральный символ, и пытается "угадать", часто ломая порядок слов.
Для этого был придуман костыль: не давать браузеру угадывать, а явно указать направление для "проблемных" фрагментов.
1. Внутри <body>
Метод 1: Атрибут dir
Оборачиваем текст в <span> (или другой тег) и указываем направление:
- dir="ltr" — слева направо
- dir="rtl" — справа налево
- dir="auto" — браузер определяет сам
Пример:
Метод 2: Тег <bdi>
Тег создан специально для этого. Он работает как <span dir="auto">, автоматически изолируя контент. Идеален для динамической вставки (например, имен пользователей).
Пример:
2. Решение для <title>, атрибутов alt и т.д.
Здесь мы не можем использовать HTML-теги, поэтому были придуманы специальные невидимые Unicode символы. Они оборачивают фрагмент текста, чтобы изолировать его направление.
-
-
Пример для <title>:
Подробнее в посте от W3: https://www.w3.org/International/articles/inline-bidi-markup/
При оптимизации сайта на арабском, столкнулся с важной особенностью RTL-языков (арабский, иврит): "проблема двунаправленного текста" (BiDi). Она возникает, когда LTR и RTL текст смешиваются, особенно рядом с нейтральными символами (пробелы, точка, запятая, :, -, /). Особый гемор это <title>.
Браузер не понимает, к какой части (LTR или RTL) относится нейтральный символ, и пытается "угадать", часто ломая порядок слов.
Для этого был придуман костыль: не давать браузеру угадывать, а явно указать направление для "проблемных" фрагментов.
1. Внутри <body>
Метод 1: Атрибут dir
Оборачиваем текст в <span> (или другой тег) и указываем направление:
- dir="ltr" — слева направо
- dir="rtl" — справа налево
- dir="auto" — браузер определяет сам
Пример:
<p>
<span dir="rtl">هذا نص عربي</span>
<span dir="ltr"> (English Text)</span>
</p>
Метод 2: Тег <bdi>
Тег создан специально для этого. Он работает как <span dir="auto">, автоматически изолируя контент. Идеален для динамической вставки (например, имен пользователей).
Пример:
<p>
<bdi>المنتج الجديد</bdi> - <bdi>New Product</bdi>
</p>
2. Решение для <title>, атрибутов alt и т.д.
Здесь мы не можем использовать HTML-теги, поэтому были придуманы специальные невидимые Unicode символы. Они оборачивают фрагмент текста, чтобы изолировать его направление.
-
⁦ (LRI) + ⁩ (PDI) — Изоляция LTR (слева направо).-
⁧ (RLI) + ⁩ (PDI) — Изоляция RTL (справа налево).Пример для <title>:
<title>الأخبار ⁦World News⁩ اليوم</title>
Подробнее в посте от W3: https://www.w3.org/International/articles/inline-bidi-markup/
www.w3.org
Inline markup and bidirectional text in HTML
Provides background on the Unicode bidirectional algorithm and inline markup to help you implement Arabic, Hebrew and other right-to-left scripts in markup.
Кейс: вылет главной страницы платного адалт сайта из-за Google Merchant
В первом квартале этого года, 1-го числа месяца, у одного платного адалт сайта вылетела главная страница из поиска. С адалтом такое бывает часто, и обычно ее место занимает страница категорий. Но тут кейс уникален тем, что по запросу site:domain.com тоже была пустая выдача. При этом, все остальные страницы по site: были в индексе, т.е. это не был полный вылет сайта. В Search Console тоже все ок, страница "якобы" в индексе.
Мной было выдвинуто несколько гипотез, но рабочей оказалась только одна.
Что навело на мысль?
В выдаче Google по названию бренда с некоторых локалей внезапно начала показываться панелька, сформированная Google Merchant. Одновременно в Search Console, в разделе Shopping Tab Listings, появилось предложение разместиться в Shopping Tab, да еще и с количеством возможных товаров (лол).
Причина
Оказалось, что чуть более месяца до вылета сайт встроил в свои имеющиеся структурированные данные параметр price через тип Offer. Вероятно, это и стриггерило подсистему Merchant’а. Интересно, что в тестах Rich Results цены не отображались.
Нюансы
Offer — это один из типов разметки для Product snippet и Merchant листинга. В новости от Google Search Central Blog указано, что при детекте продуктовой разметки может быть получена возможность размещения в Shopping Tab.
Проблема
В Merchant Center есть отдельная статья про Adult-oriented content, где четко сказано, что показ его ограничен несколькими типами товаров. Естественно, пострадавший сайт под эти требования не попадал. Вероятно, Google счел, что "продукт" не соответствует правилам, и вместо того, чтобы просто не показывать его в Shopping Tab, он решил исключить главную страницу из поиска.
Решение
После удаления price с типом Offer из Structured Data, ровно 14-го числа месяца главная страница вернулась в выдачу. К концу месяца пропала и панелька, сформированная Merchant, которая показывалась по брендовому запросу. Интересно, что Shopping Tab в Search Console продолжил предлагать разместить товары...
В первом квартале этого года, 1-го числа месяца, у одного платного адалт сайта вылетела главная страница из поиска. С адалтом такое бывает часто, и обычно ее место занимает страница категорий. Но тут кейс уникален тем, что по запросу site:domain.com тоже была пустая выдача. При этом, все остальные страницы по site: были в индексе, т.е. это не был полный вылет сайта. В Search Console тоже все ок, страница "якобы" в индексе.
Мной было выдвинуто несколько гипотез, но рабочей оказалась только одна.
Что навело на мысль?
В выдаче Google по названию бренда с некоторых локалей внезапно начала показываться панелька, сформированная Google Merchant. Одновременно в Search Console, в разделе Shopping Tab Listings, появилось предложение разместиться в Shopping Tab, да еще и с количеством возможных товаров (лол).
Причина
Оказалось, что чуть более месяца до вылета сайт встроил в свои имеющиеся структурированные данные параметр price через тип Offer. Вероятно, это и стриггерило подсистему Merchant’а. Интересно, что в тестах Rich Results цены не отображались.
Нюансы
Offer — это один из типов разметки для Product snippet и Merchant листинга. В новости от Google Search Central Blog указано, что при детекте продуктовой разметки может быть получена возможность размещения в Shopping Tab.
Проблема
В Merchant Center есть отдельная статья про Adult-oriented content, где четко сказано, что показ его ограничен несколькими типами товаров. Естественно, пострадавший сайт под эти требования не попадал. Вероятно, Google счел, что "продукт" не соответствует правилам, и вместо того, чтобы просто не показывать его в Shopping Tab, он решил исключить главную страницу из поиска.
Решение
После удаления price с типом Offer из Structured Data, ровно 14-го числа месяца главная страница вернулась в выдачу. К концу месяца пропала и панелька, сформированная Merchant, которая показывалась по брендовому запросу. Интересно, что Shopping Tab в Search Console продолжил предлагать разместить товары...
О безопасности ссылок с рекламными анкорами
В 2024–2025 многие заметили массовое проставление ссылок с анкорами, рекламирующими услуги линкбилдинга. Провели с коллегами точечный опрос и тест, пришли к следующим первичным выводам.
Не вредят:
— Ссылки с новорегов.
— Ссылки, скрытые от GoogleBot.
Вредят:
— Ссылки со взломанных сайтов, которые не скрыты от GoogleBot.
Интересно наблюдение по регионам: в Tier-1 это касается сайтов в меньшей степени, а вот в азиатском Tier-3 эффект заметен.
Лично я после добавления таких доноров в Disavow (ссылки шли на конкретную англоязычную страницу) увидел рост из южно-азиатских стран. Рост продолжается, хотя до чистки было стабильное падение. При этом в Tier-1 изменений не было.
Еще пример от коллеги с белым проектом в одной азиатской стране: он постоянно добавляет новые домены ломов с рекламой в анкоре в Disavow. Стоит ненадолго забросить — позиции сразу проседают.
Важные оговорки:
— Не претендую на истину в последней инстанции, поскольку не проводилось масштабное исследование. Некогда.
— iGaming в опросе и тесте не участвовал.
— Антиспам-механизмы в зависимости от гео/запросов могут влиять по-разному: где-то сильнее, где-то слабее.
Бонусом регулярка для выделения таких анкоров:
Упд: конечно, влияющие ссылки dofollow, кстати, негатив от спамных ссылок в этом году и западные специалисты заметили.
В 2024–2025 многие заметили массовое проставление ссылок с анкорами, рекламирующими услуги линкбилдинга. Провели с коллегами точечный опрос и тест, пришли к следующим первичным выводам.
Не вредят:
— Ссылки с новорегов.
— Ссылки, скрытые от GoogleBot.
Вредят:
— Ссылки со взломанных сайтов, которые не скрыты от GoogleBot.
Интересно наблюдение по регионам: в Tier-1 это касается сайтов в меньшей степени, а вот в азиатском Tier-3 эффект заметен.
Лично я после добавления таких доноров в Disavow (ссылки шли на конкретную англоязычную страницу) увидел рост из южно-азиатских стран. Рост продолжается, хотя до чистки было стабильное падение. При этом в Tier-1 изменений не было.
Еще пример от коллеги с белым проектом в одной азиатской стране: он постоянно добавляет новые домены ломов с рекламой в анкоре в Disavow. Стоит ненадолго забросить — позиции сразу проседают.
Важные оговорки:
— Не претендую на истину в последней инстанции, поскольку не проводилось масштабное исследование. Некогда.
— iGaming в опросе и тесте не участвовал.
— Антиспам-механизмы в зависимости от гео/запросов могут влиять по-разному: где-то сильнее, где-то слабее.
Бонусом регулярка для выделения таких анкоров:
(?i)^.*(seo|links|backlink|traffic|gambling).*(@|t\.me).*$|(?i)^.*(@|t\.me).*(seo|links|backlink|traffic|gambling).*$
Упд: конечно, влияющие ссылки dofollow, кстати, негатив от спамных ссылок в этом году и западные специалисты заметили.
Рост через выгорание: итоги года
В этом году, как и в прошлом, основные проекты выросли, и очень хорошо - хотя на нашем уровне топов ниши это крайне сложно. Было множество проблем и преодолений, но мы справились и стали еще круче. Часто приходилось принимать решения, которые не у кого подсмотреть, - только придумывать с нуля, что очень трудозатратно.
Упор в первую очередь на поведение пользователей дает свои плоды, буду продолжать. Однако нужно постоянно находить баланс между юзерами и машинной обработкой страниц, что не всегда легко.
Мое давнее правило - смотреть на конкурентов и не делать, как они - продолжает работать. Очень редко бывает так, что "на том конце" сидит действительно сильная команда экспертов.
Судя по планам на 2026, еще есть варианты, как собрать больше трафика. Это радует, а то иногда кажется, что идеи могут иссякнуть.
Про индустрию
Прикольно было наблюдать за решениями, которые обсуждало SEO-сообщество в этом году, поскольку сам использую их годами. Есть только небольшое опасение, что теперь некоторые фишки Google опять прикроет.
Еще я полностью отказался от консультаций и аудитов, даже для друзей. Причины простые:
- сделал аудит - все равно будет куча вопросов;
- аудит без внедрения - деньги на ветер (а внедряют правильно редко);
- консультации часто превращаются в многочасовые расследования.
Денег на этом не заработаешь, только зря тратишь время и ресурс.
Про цену успеха и выводы
Но самое тяжелое, с чем я столкнулся в этом году: это выгорание и тревожное расстройство, развившееся на фоне стресса и переработок. Пришлось уходить в дополнительный неоплачиваемый отпуск на месяц, а также обращаться к врачам.
Теперь я учусь выстраивать жесткие границы: вообще не работать в выходные, не перерабатывать и блокировать коллег во всех мессенджерах в нерабочее время. Иначе начинаются невыносимые психосоматические мышечные спазмы. Само тело протестует против работы и стресса.
Планы
Надеюсь, в 2026-м получится успешно внедрить всё задуманное по работе, окончательно вылечиться от выгорания и наконец-то дописать свой пост-рок/блэкгейз альбом.
В этом году, как и в прошлом, основные проекты выросли, и очень хорошо - хотя на нашем уровне топов ниши это крайне сложно. Было множество проблем и преодолений, но мы справились и стали еще круче. Часто приходилось принимать решения, которые не у кого подсмотреть, - только придумывать с нуля, что очень трудозатратно.
Упор в первую очередь на поведение пользователей дает свои плоды, буду продолжать. Однако нужно постоянно находить баланс между юзерами и машинной обработкой страниц, что не всегда легко.
Мое давнее правило - смотреть на конкурентов и не делать, как они - продолжает работать. Очень редко бывает так, что "на том конце" сидит действительно сильная команда экспертов.
Судя по планам на 2026, еще есть варианты, как собрать больше трафика. Это радует, а то иногда кажется, что идеи могут иссякнуть.
Про индустрию
Прикольно было наблюдать за решениями, которые обсуждало SEO-сообщество в этом году, поскольку сам использую их годами. Есть только небольшое опасение, что теперь некоторые фишки Google опять прикроет.
Еще я полностью отказался от консультаций и аудитов, даже для друзей. Причины простые:
- сделал аудит - все равно будет куча вопросов;
- аудит без внедрения - деньги на ветер (а внедряют правильно редко);
- консультации часто превращаются в многочасовые расследования.
Денег на этом не заработаешь, только зря тратишь время и ресурс.
Про цену успеха и выводы
Но самое тяжелое, с чем я столкнулся в этом году: это выгорание и тревожное расстройство, развившееся на фоне стресса и переработок. Пришлось уходить в дополнительный неоплачиваемый отпуск на месяц, а также обращаться к врачам.
Теперь я учусь выстраивать жесткие границы: вообще не работать в выходные, не перерабатывать и блокировать коллег во всех мессенджерах в нерабочее время. Иначе начинаются невыносимые психосоматические мышечные спазмы. Само тело протестует против работы и стресса.
Планы
Надеюсь, в 2026-м получится успешно внедрить всё задуманное по работе, окончательно вылечиться от выгорания и наконец-то дописать свой пост-рок/блэкгейз альбом.
Google неделю назад обещали поддерживать старый URL со списком IP ботов еще некоторое время, а потом редиректнуть на новый, но вот уже сегодня вместо списка выводят такое сообщение по старому адресу:
https://developers.google.com/static/search/apis/ipranges/googlebot.json
Кто еще не успел, срочно меняйте на https://developers.google.com/static/crawling/ipranges/common-crawlers.json
https://developers.google.com/static/search/apis/ipranges/googlebot.json
Кто еще не успел, срочно меняйте на https://developers.google.com/static/crawling/ipranges/common-crawlers.json
Никакого bokep'а для Индонезии
Во время последнего Spam апдейта Google, похоже, принудительно включил Safe Search для пользователей из Индонезии. Раньше эта настройка была включена только на уровне провайдеров, и юзеры научились её обходить, но, судя по сообщениям на форумах, блокировка усложнилась.
Кратко, что получилось понять из индонезийских тредов:
• Google заблокировал возможность отключить SafeSearch для пользователей с IP-адресами Индонезии (поиск принудительно переводится в режим фильтрации NSFW-контента).
• Привычные методы вроде изменения DNS (Cloudflare, NextDNS), а также утилиты вроде Intra, WARP или DNSCrypt больше не отключают фильтр Google Search.
• Затронуты все провайдеры: блокировка работает одинаково на мобильном интернете (Telkomsel, XL, Tri) и на домашних провайдерах (Indihome, Biznet, MyRepublic, Oxygen).
• Часть юзеров уже нашла лазейки для обхода (например, смену региона поиска в настройках Google), но пока это не массовая история - большинство до сих пор сидит с фильтрованным поиском.
Ранее правительство Индонезии неоднократно предупреждало Google о блокировках в случае неисполнения обязательств, связанных с обновлениями в законе о защите детей.
Во время последнего Spam апдейта Google, похоже, принудительно включил Safe Search для пользователей из Индонезии. Раньше эта настройка была включена только на уровне провайдеров, и юзеры научились её обходить, но, судя по сообщениям на форумах, блокировка усложнилась.
Кратко, что получилось понять из индонезийских тредов:
• Google заблокировал возможность отключить SafeSearch для пользователей с IP-адресами Индонезии (поиск принудительно переводится в режим фильтрации NSFW-контента).
• Привычные методы вроде изменения DNS (Cloudflare, NextDNS), а также утилиты вроде Intra, WARP или DNSCrypt больше не отключают фильтр Google Search.
• Затронуты все провайдеры: блокировка работает одинаково на мобильном интернете (Telkomsel, XL, Tri) и на домашних провайдерах (Indihome, Biznet, MyRepublic, Oxygen).
• Часть юзеров уже нашла лазейки для обхода (например, смену региона поиска в настройках Google), но пока это не массовая история - большинство до сих пор сидит с фильтрованным поиском.
Ранее правительство Индонезии неоднократно предупреждало Google о блокировках в случае неисполнения обязательств, связанных с обновлениями в законе о защите детей.
Tempo English
Indonesia Sanctions Google Over Child Protection Rule Breach
Indonesia has issued a formal warning to Google over YouTube's failure to comply with child protection rules for digital platforms.
Главное Google во время спам-апдейта случайно не выйти на самих себя...
Прочел я тут как ломанули Binance:
И вспомнил, что находил эту google ads (!!!) ссылку летом в выдаче Google, все изучил и благополучно забыл. Причем злоумышленники заабузили редирект google.com, поэтому многие бы и не заметили подмены. Ну собственно на скрине все есть.
June 2026 — Supply chain attack. Engineer A from Wallet DevOps downloaded a tampered Homebrew installation in order to install a popular AI coding tool after searching for it on a search engine. Our security team detected the anomaly, replaced the device, and rotated all related credentials as a proactive security action. However, Engineer A’s role and his related colleagues on our wallet infrastructure team was exposed to the hacker.
И вспомнил, что находил эту google ads (!!!) ссылку летом в выдаче Google, все изучил и благополучно забыл. Причем злоумышленники заабузили редирект google.com, поэтому многие бы и не заметили подмены. Ну собственно на скрине все есть.