SearchApi, SerpApi и иск Google: что проверить в договоре на SERP API до запуска продукта
В этой истории важно сразу разделить два разных спора. Первый: 20 января 2026 года SerpApi подала иск к SearchApi и связанным лицам. В карточке дела на Justia указано, что речь идет о споре по Defend Trade Secrets Act, а в самой жалобе SerpApi компания утверждает, что после несостоявшейся сделки на рынке появился конкурент с использованием чувствительных наработок.
Второй спор появился раньше и бьет уже по самой модели такого бизнеса. 19 декабря 2025 года Google объявила об иске к SerpApi. Позиция Google жесткая: компания пишет, что SerpApi обходила защитные меры, игнорировала выбор правообладателей по доступу к контенту и перепродавала данные из поисковой выдачи.
Если вы покупаете SERP API для rank tracking, SEO-аналитики, ad intelligence или AI-продукта, это не чужая драма. Это хороший повод проверить, что у вас написано в договоре, кто несет риск по downstream use и что вообще покрывают обещания вроде legal shield.
Что на самом деле показывают эти два спора
Издалека легко решить, что это просто конфликт двух сервисов с похожим продуктом. Но юридически там разные сюжеты.
В споре SerpApi против SearchApi вопрос упирается в коммерческую тайну, копирование и последствия несостоявшейся M&A-сделки. Суд еще не сказал, кто прав. Но сам факт такого иска показывает, насколько хрупкой может быть база у инфраструктурного поставщика.
В споре Google против SerpApi предмет другой. Google говорит не про внутренний конфликт рынка, а про scraping, обход защитных мер и перепродажу контента из Search. Для клиента это уже не спор о репутации бренда. Это вопрос, может ли ключевой поставщик данных внезапно оказаться под давлением правообладателя или платформы, на которой строится его бизнес.
Почему это тема для digital law, а не только для SEO
Здесь многие команды ошибаются одинаково. Они видят, что вендор сам собирает публичную выдачу, и делают вывод, что почти весь юридический риск лежит на нем. На практике это не так.
SearchApi в своих Terms of Service прямо пишет, что их Legal Protection Guarantee касается только претензий, которые возникают исключительно из собственной коллекции и парсинга публичной выдачи самим SearchApi. Там же отдельно сказано, что гарантия не распространяется на ваше использование, хранение, перераспределение или коммерциализацию данных, а также на ваши договорные отношения с третьими сайтами и поставщиками данных.
У SerpApi на странице U.S. Legal Shield логика похожая. Покрытие относится к scraping и parsing как таковым, если ваше использование не является незаконным. Но SerpApi отдельно советует консультироваться со своим юристом по вопросу downstream use, потому что правомерность такого использования лежит уже вне самого shield.
Именно здесь начинается зона digital law. Проблема не в том, можно ли в принципе купить SERP API. Проблема в том, что "законность сбора" и "законность вашего продукта на этих данных" - это разные вопросы.
Где у клиента остается риск, даже если у вендора есть legal shield
Самое полезное место в этом споре - не заголовок и не громкие формулировки, а исключения в документах.
1. Перепродажа и повторное использование данных
Если вы не просто смотрите данные внутри кабинета, а:
- перепродаете отчеты клиентам;
- встраиваете SERP-ответы в собственный продукт;
- храните массивы данных для повторного использования;
- показываете сниппеты, фрагменты или изображения третьим лицам;
- используете результаты как сырье для обучения или тонкой настройки моделей,
то вы выходите далеко за рамки вопроса "кто собрал выдачу". У SearchApi это прямо вынесено в исключения Legal Protection Guarantee. У SerpApi в U.S. Legal Shield тоже сказано, что покрытие касается lawful collection, а не того, что вы потом делаете с данными.
2. Договоры и ограничения третьих лиц
Даже если ваш поставщик обещает защиту, это не отменяет того, что вы можете быть связаны собственными обязательствами перед рекламными платформами, издателями, площадками или клиентами. SearchApi отдельно пишет, что гарантия не распространяется на ваши контракты и обязательства перед third-party sites или data providers.
Для legal-команды это важный сигнал: вендор может брать риск на сбор, но не берет риск на вашу бизнес-модель.
3. Privacy и персональные данные
Часть команд до сих пор думает, что SERP API - это только про поисковую выдачу, а не про privacy. Но как только вы отправляете через запросы user identifiers, внутренние query strings, UTM-структуры, адреса, телефоны или другие данные, вопрос меняется.
У SearchApi в DPA прямо расписаны роли: клиент - Controller, SearchApi - Processor, обработка идет в США, а для restricted transfers используются SCC. Там же указано, что SearchApi не использует customer data для обучения или дообучения AI-моделей. Это хорошие пункты, но их нужно читать до закупки, а не после запуска.
Если у другого поставщика эти роли, retention и transfer mechanisms не описаны так же явно, это уже не "потом разберемся", а отдельный блок для due diligence.
4. Ограничения по плану, сумме и процедуре
Даже когда legal shield есть, он редко безусловный.
SearchApi пишет, что гарантия действует только для активных платных подписок начиная с Production plan, capped на $2,000,000 за 12 месяцев, и требует prompt notice плюс сохранение логов и доказательств.
SerpApi на странице U.S. Legal Shield тоже ограничивает покрытие: оно начинается с Production plan и выше, а претензии должны попадать под право США и рассматриваться в суде США.
Для закупки это означает простую вещь: обещание "мы вас прикроем" почти всегда работает только при соблюдении условий. Если команда не знает этих условий, на shield нельзя опираться как на готовое решение.
Что digital law команде стоит проверить в договоре на SERP API
Ниже короткий список того, что реально полезно проверить до go-live.
1. Применимое право и подсудность
Условия спора лучше знать заранее, а не в момент конфликта.
SearchApi указывает New York law и venue в судах New York County.
SerpApi в legal-документах указывает Texas law.
Это влияет на процесс, стоимость спора, counsel strategy и на то, насколько вообще удобно вам защищать свои интересы.
2. Приостановка доступа и расторжение
Вендор почти всегда оставляет себе широкое право остановить доступ.
SearchApi пишет, что может suspend или terminate account и отказать в текущем или будущем доступе к сервису.
SerpApi в своих legal terms пишет, что может прекратить доступ, если по своему усмотрению считает, что вы не соблюдаете условия.
Для продукта это не абстракция. Это вопрос, есть ли у вас резервный маршрут и сколько часов займет переключение.
3. Возмещение и исключения
Нужно смотреть не только на рекламную формулировку про shield, но и на обратную обязанность клиента.
SearchApi в Terms отдельно включает indemnification со стороны клиента по ряду third-party claims, связанных с использованием данных. Там же сказано, что Legal Protection Guarantee - это exclusive remedy в пределах своей сферы.
Юридически это означает, что часть риска вендор берет, но часть очень явно возвращает клиенту.
4. Выгрузка, хранение и удаление данных
Если сервис критичен, нужно заранее знать:
- как выгрузить свои данные;
- как быстро вы их заберете при stop notice;
- что останется у поставщика после termination;
- как оформлен deletion request.
У SearchApi DPA есть отдельные положения про export во время срока договора, deletion и исключения, когда данные могут удерживаться по закону. Это хороший ориентир, который стоит требовать и у других поставщиков.
5. Что можно делать с данными после получения
Если вы строите AI-агента или аналитический продукт, обязательно проверьте, можно ли:
- сохранять результаты;
- нормализовать и смешивать их с другими датасетами;
- использовать их в retrieval pipeline;
- делать на их основе summaries для клиентов;
- включать такие данные в обучающие или evaluation-процессы.
Это уже не вопрос "какой API быстрее". Это вопрос лицензии, IP-risk и contract scope.
Практический вывод для бизнеса
Если ваш продукт держится на одном SERP API, legal due diligence нужно делать не после первого инцидента, а до подписания или продления.
Минимальный рабочий пакет выглядит так:
- Сверить Terms, DPA, privacy docs, venue и indemnity.
- Отдельно описать свой downstream use: хранение, отчеты, AI, resale, client dashboards.
- Проверить, что legal shield покрывает именно ваш сценарий, а не только сбор на стороне вендора.
- Сохранить fallback-провайдера хотя бы для критичных функций.
- Завести внутренний playbook: кто получает legal notice, кто сохраняет логи, кто принимает решение о failover.
Если нужен внешний аудит такой связки, это уже ближе к compliance-проверке цифровых сервисов и договорной модели, чем к обычному выбору API по цене и скорости ответа.
FAQ
Значит ли это, что SERP API использовать нельзя?
Нет. Это значит, что покупать его надо как юридически значимую инфраструктуру, а не как безобидный технический расходник.
Если у вендора есть legal shield, можно успокоиться?
Нет. Почти всегда shield покрывает только часть риска и при этом не снимает с клиента ответственность за downstream use.
Что важнее всего проверить перед запуском?
Ваш собственный сценарий использования данных: хранение, переработка, публикация, клиентский доступ, AI-функции и ограничения по третьим лицам.