Google Places API против парсинга: стоимость, пробелы и что выбрал бы я

Несколько месяцев назад разработчик на Stack Overflow задал вопрос, который висит там с 2012 года: "Google Places API Place Details limited to 5 reviews?" Прошло четырнадцать лет, вопрос собрал сотни лайков, а ответ всё тот же — да, максимум пять отзывов. Уже одно это ограничение отлично показывает, почему вообще существует этот спор.

Если тебе хоть раз нужно было массово вытаскивать данные Google Places — списки лидов, отзывы конкурентов, паттерны трафика, аудит локального SEO — ты наверняка упирался в тот же выбор. Официальный Google Places API аккуратный, структурированный и отлично задокументирован. Но он не отдаёт всё, что видно на странице Google Maps, а счёт может неприятно вырасти, когда ты выходишь за рамки бесплатного лимита. Парсинг позволяет собирать больше данных и по-другому влияет на бюджет, но приносит свои головные боли — CAPTCHA, сломанные селекторы, юридическая серая зона. Я довольно много времени изучал обе стороны — документацию API, тарифы, стек инструментов для парсинга и реальные компромиссы — и эта статья стала результатом этого исследования. Разберём, какие поля теряются, сколько всё реально стоит на объёмах 10K/100K/1M записей, как обстоят дела с антибот-защитой и какой гибридный подход работает на практике. И да, будет схема принятия решения — потому что никто не хочет читать 3000 слов и всё равно не понимать, что выбрать.

Что такое Google Places API и что он реально даёт?

Google Places API — это официальный структурированный способ получать бизнес-данные из базы Google: названия, адреса, телефоны, рейтинги, отзывы, фото и так далее. Ты отправляешь HTTP-запрос и получаешь форматированный JSON. Это одобренный Google канал.

Текущая версия, Places API "New", строится вокруг масок полей. Когда ты вызываешь Place Details, ты явно указываешь, какие поля нужны — displayName, formattedAddress, rating, reviews, photos и т. д. — а Google выставляет счёт по самой дорогой категории среди запрошенных полей. Если не указать field mask, ты получишь ошибку, а не ответ по умолчанию. Так и задумано: Google хочет, чтобы ты платил только за то, что используешь, и больше — за самые ценные данные.

Доступные поля разбиты по тарифным уровням:

Уровень	Примеры полей	Что ты получаешь
Essentials	Place ID, форматированный адрес, координаты, метаданные фото	Базовая идентификация и локация
Pro	Отображаемое название, статус бизнеса, URI Google Maps, основной тип	Более полная информация о компании
Enterprise	Рейтинг, количество оценок, сайт, телефоны, часы работы, ценовой уровень	Поля, которые чаще всего и нужны бизнесу
Enterprise + Atmosphere	Отзывы, сводка отзывов, генеративная сводка, удобства, парковка, еда навынос/доставка	Самые богатые и самые дорогие данные

Ключевые эндпоинты, которые чаще всего нужны: Autocomplete (поиск по мере ввода), Text Search и Nearby Search (поиск мест), Place Details (обогащение уже известного места) и Place Photos (изображения).

Теперь о важных ограничениях:

• Отзывы: ресурс Place возвращает не более 5 отзывов на одно место, отсортированных по релевантности. И всё. Не 50. Не "все". Пять.
• Фото: в ресурсе Place ограничение — 10 ссылок на фото на одно место.
• Популярное время / текущая загруженность: как стандартное поле Places API это недоступно. Google подтверждает наличие этих данных в пользовательских интерфейсах (на основе агрегированной и анонимизированной истории местоположений), а в блоге Maps объясняет, как это работает — но список полей этого не включает.
• Раздел Q&A: не доступен.
• "Пользователи также ищут" и конкуренты: не доступно.
• Меню / прайс-лист: не является стандартным полем.

Кто обычно использует Google Places API?

• Логистические компании — проверка и геокодирование адресов
• Тревел- и hospitality-приложения — отображение ближайших отелей, ресторанов и достопримечательностей
• Платформы недвижимости — обогащение карточек объектов данными о местном бизнесе
• Агентства локального SEO — аудит согласованности NAP (name, address, phone)
• Отделы продаж — формирование списков лидов по Place ID и базовой информации о компании

Если твой кейс звучит как "нужны структурированные данные о месте для продакшн-приложения", API — правильная отправная точка. Если в требованиях есть слова "все отзывы", "популярное время" или "анализ конкурентов" — читай дальше.

Что значит "парсить" данные Google Places?

Web scraping — это использование софта для автоматического извлечения данных со страницы, в данном случае из Google Maps или результатов Google Search, а не через официальный API. Парсер читает страницу так же, как это делает браузер, а затем вытаскивает структурированные куски: название компании, адрес, текст отзывов, звёздный рейтинг, графики популярного времени, Q&A, предложения конкурентов, всю галерею фото и всё остальное, что отображается на экране.

Главное отличие: API отдаёт то, что Google решил показать. Парсинг даёт тебе, по крайней мере в теории, всё, что видит человек на странице.

Но "парсинг" — это не один подход. Есть три очень разных варианта, и разница между ними существенная.

Скрипты своими руками, managed scraping API и no-code инструменты

Подход	Как это работает	Для кого подходит	Главный компромисс
Скрипты своими руками (Puppeteer, Playwright, Selenium)	Ты пишешь и поддерживаешь headless-скрипт, который открывает страницы Google Maps и разбирает DOM	Разработчики, которым нужен полный контроль и кастомная логика	Самая высокая нагрузка на поддержку — селекторы ломаются, когда Google меняет интерфейс
Managed scraping API (Thunderbit API, SerpApi, Outscraper)	Ты отправляешь URL или запрос в API; сервис сам обрабатывает рендеринг, антибот-защиту и парсинг, а затем возвращает структурированные данные	Разработчики, которым нужен структурированный результат без поддержки собственного парсера	Тарифы и качество у разных вендоров отличаются; ты доверяешь стороннему сервису
No-code расширения для браузера (Thunderbit Chrome Extension)	Извлечение данных прямо из браузера по клику — AI предлагает поля, ты нажимаешь "Scrape", затем экспортируешь в Sheets/Excel	Бизнес-пользователи, маркетологи, sales-команды, которым нужно быстро выгрузить данные в таблицу	Меньше гибкости для сложных пайплайнов; зависит от качества AI в инструменте

Коротко: DIY — максимум гибкости, но и максимум поддержки. Managed API — структурированный результат без обслуживания. No-code — самый быстрый вариант для неразработчиков.

Google Places API против парсинга: сравнение полей один к одному

Это та таблица, которую я хотел бы увидеть в самом начале исследования. Все поля, которые могут понадобиться бизнесу или разработчику, — рядом для сравнения:

Поле данных	Google Places API	Web Scraping
Название компании	✅ Полностью (уровень Pro)	✅ Полностью
Адрес / локация	✅ Полностью (Essentials)	✅ Полностью
Телефон	✅ Уровень Enterprise	✅ Если отображается
URL сайта	✅ Уровень Enterprise	✅ Если отображается
Сводный рейтинг	✅ Уровень Enterprise	✅ Полностью
Количество оценок	✅ Уровень Enterprise	✅ Полностью
Отдельные отзывы (текст + оценка)	⚠️ Максимум 5 отзывов	✅ Все доступные отзывы
Popular times / текущая загруженность	❌ Не стандартное поле API	✅ Можно извлечь, если отображается
Раздел Q&A	❌ Недоступен	✅ Можно извлечь
Метаданные фото	✅ До 10 ссылок через Photos endpoint	✅ Полная галерея
Меню / прайс-лист	❌ Не стандартное поле	⚠️ Если есть на странице
"Пользователи также ищут" (конкуренты)	❌ Недоступно	✅ Можно извлечь
Часы работы	✅ Уровень Enterprise	✅ Если отображается
Ценовой уровень	✅ Уровень Enterprise	✅ Если отображается
Place ID	✅ Надёжно (Essentials)	⚠️ Возможно, но API — канонический источник
Google Maps URI	✅ Уровень Pro	✅ Это URL страницы
Ответы владельца на отзывы	⚠️ Нужно проверять актуальную доступность	✅ Часто видно
Позиция в SERP / map-pack	❌ Не цель API	✅ Через парсинг SERP

Главный пробел: если тебе нужны полные наборы отзывов для sentiment-анализа, мониторинга репутации или конкурентного бенчмаркинга, одного API недостаточно. Пять отзывов на место — это срез, а не датасет.

Популярное время и паттерны трафика? Та же история. Если ты консультант в ритейле или аналитик коммерческой недвижимости, парсинг — единственный путь, потому что этих данных просто нет в API.

С другой стороны, для канонических Place ID, структурированных адресов для геокодирования или работы локатора магазинов API проще, надёжнее и официально поддерживается.

Реальная стоимость: Google Places API против парсинга на 10K, 100K и 1M записей

Стоимость — самый неправильно понимаемый аспект этого выбора. Многие подключают бесплатный лимит API, делают прототип и потом получают счёт, который неприятно удивляет после масштабирования. В парсинге же люди часто недооценивают стоимость прокси и время разработчиков.

Итак, считаем.

Разбор цен Google Places API

В марте 2025 Google переработал ценообразование Maps Platform, заменив старый фиксированный кредит $200 в месяц на бесплатные лимиты по SKU и многоуровневую тарификацию по объёму. Текущие цены выглядят так:

• Essentials (Place Details): 10 000 бесплатных запросов в месяц, затем $5.00 за 1000 до 100K
• Pro (Place Details): 5 000 бесплатных, затем $7.00 за 1000
• Enterprise (Place Details): 1 000 бесплатных, затем $20.00 за 1000
• Enterprise + Atmosphere (отзывы, удобства): 1 000 бесплатных, затем $25.00 за 1000

Критически важно: если в твоей field mask есть хотя бы одно поле уровня Enterprise + Atmosphere, например reviews, весь запрос будет тарифицироваться по этому уровню. А типичный сценарий часто состоит из нескольких SKU — сначала Text Search Pro для поиска мест, потом Place Details Enterprise + Atmosphere для их обогащения — поэтому затраты складываются.

Один "поиск" очень редко означает один платный запрос.

Стоимость парсинга: инструменты, прокси и время разработчиков

Затраты на парсинг обычно делятся на три части:

1. Подписка на инструмент или API-кредиты: managed scraping API берут оплату за запрос, за кредит или за запись. SerpApi тарифицирует по поисковым запросам. Outscraper работает по модели pay-as-you-go за запись. У Thunderbit API кредитная модель (Extract = 20 кредитов за запрос). В расширении Thunderbit Chrome Extension 1 кредит = 1 строка результата.
2. Расходы на прокси (только DIY): residential-прокси для парсинга Google Maps обычно стоят $50–$300 в месяц в зависимости от объёма и провайдера.
3. Время разработчиков (только DIY): создание и поддержка Puppeteer/Playwright-скриптов. Это скрытая статья расходов, которая и убивает экономику собственного решения.

Таблица стоимости: API vs парсинг на масштабе

Масштаб	Google Places API (Enterprise + Atmosphere)	Managed scraping API (оценка)	DIY-парсинг (прокси + время разработчика)
10K записей/мес	~$225 (1K бесплатно, 9K × $25/1K)	~$50–$150 в зависимости от провайдера	~$50 на прокси + 2–4 часа разработки в месяц
100K записей/мес	~$2,475 (после бесплатного лимита срабатывают объёмные тарифы)	~$250–$500	~$150 на прокси + 8–16 часов разработки в месяц
1M записей/мес	~$17,975 (объёмные тарифы снижают цену за единицу, но итог всё равно высокий)	~$1,500–$3,000	~$300 на прокси + 20+ часов разработки в месяц + риск поломок

Примечания: оценки API используют опубликованные объёмные тарифы для Place Details Enterprise + Atmosphere после 1000 бесплатных запросов. Оценки managed scraping API — примерные диапазоны по разным провайдерам. Время DIY-разработки рассчитано при полной стоимости часа $50–$100.

Картина ясна: на любительском объёме (до 10K) бесплатные лимиты API могут сделать его самым дешёвым вариантом, особенно если тебе нужны только поля Essentials или Pro. На бизнес-объёмах (100K+) стоимость API резко растёт, особенно если нужны богатые поля. На enterprise-уровне (1M+) счёт за API может приблизиться к пятизначным суммам в месяц, и тогда парсинг или сервисы с готовыми датасетами становятся экономически оправданными — если тебе действительно нужны те дополнительные поля, которых нет в API.

Если тебе нужны только адреса и Place ID, не парси. Для этого API дешевле и лучше. Аргумент в пользу парсинга работает только тогда, когда тебе нужны данные, которые API вернуть не может.

Реальность антибот-защиты: почему DIY-скрейперы Google ломаются

Вот часть, которую часто пропускают энтузиасты парсинга. Google не хочет, чтобы ты парсил Google Maps. Поэтому компания построила несколько уровней защиты и регулярно их обновляет.

Многоуровневая защита Google

• reCAPTCHA: автоматические браузеры сталкиваются с CAPTCHA значительно чаще, чем живые пользователи
• Рендеринг JavaScript на стороне клиента: Google Maps — тяжёлое JavaScript-приложение. Простого HTTP-запроса недостаточно, нужен полноценный headless-браузер
• Браузерный fingerprinting: Google распознаёт headless-браузеры по canvas fingerprint, WebGL, свойствам navigator и другим сигналам
• Ограничение частоты запросов по IP: слишком много запросов с одного IP или одной подсети прокси — и вас блокируют
• Изменения DOM-структуры: Google регулярно меняет разметку страниц — по общему опыту из Reddit и GitHub issues селекторы ломаются каждые несколько недель или месяцев

Именно последний пункт — тихий убийца. Скрипт на Puppeteer, который идеально работал в июне, в июле может начать возвращать пустые результаты, потому что Google переименовал CSS-класс или перестроил div.

Скрытая цена поддержки DIY-скриптов

Каждый раз, когда Google меняет DOM, кому-то в команде нужно:

1. Заметить, что парсер сломался (желательно до того, как плохие данные разойдутся дальше)
2. Изучить новую структуру страницы
3. Обновить селекторы, обработать новые типы CAPTCHA, подправить retry-логику
4. Протестировать и задеплоить

За год это легко может стоить больше, чем подписка на managed scraping API. Я видел команды, которые тратят 40+ часов разработчика в год только на то, чтобы Google Maps-парсер продолжал работать, и это ещё консервативная оценка для умеренно сложной системы.

Зачем вообще существуют managed scraping API

Именно поэтому существуют сервисы вроде Thunderbit API, SerpApi и Outscraper. Они берут на себя антибот-сложность — рендеринг JS, обход CAPTCHA, ротацию прокси, поддержку селекторов — и возвращают структурированные данные.

Эндпоинт Thunderbit POST /extract с renderMode: "full" справляется с тяжёлыми на JavaScript страницами вроде Google Maps и возвращает структурированный JSON, согласованный со схемой, а не сырой HTML, который ещё нужно разбирать. MCP-сервер расширяет это для AI-агентов — Claude, Cursor и другие LLM-процессы могут получать данные из Google Maps прямо во время задачи, не выходя из своей среды.

Для нетехнических пользователей Thunderbit Chrome Extension — вариант без поддержки: открой страницу Google Maps, нажми "AI Suggest Fields", затем "Scrape", экспортируй в Sheets. Без селекторов, без прокси, без отладки.

SerpApi и Outscraper — тоже сильные альтернативы, но с другими тарифными моделями и форматами вывода. SerpApi возвращает структурированный JSON для каждого поиска; Outscraper берёт оплату за запись по модели pay-as-you-go. Выбор зависит от объёма, бюджета и того, нужен ли тебе JSON или ты готов парсить полуструктурированный результат.

Гибридная стратегия: использовать Google Places API и парсинг вместе

Ни одна из статей в топе поиска не предлагает то, что на практике работает лучше всего: использовать оба подхода. Многие команды в итоге берут официальный API для одних задач и парсинг — для других. Главное — подобрать инструмент под конкретную работу.

Когда выигрывает официальный API

• Autocomplete в живом продакшн-приложении: низкая задержка, соответствие ToS, надёжный SLA. Без конкурентов.
• Бэкенды приложений, завязанных на локацию: локаторы магазинов, валидация адресов, сопоставление Place ID. API структурированный, поддерживаемый и задокументированный.
• Интеграции с жёсткими требованиями к compliance: корпоративные контракты, публичные продукты или любой сценарий, где соблюдение условий Google не обсуждается.

Когда выигрывает парсинг

• Полное извлечение отзывов (5K+ отзывов на место): sentiment-анализ, мониторинг репутации, конкурентный бенчмаркинг. Лимит в 5 отзывов делает API здесь бесполезным.
• Разовая выгрузка лидов: дешевле для batch-задач без постоянной тарификации. No-code инструмент вроде Thunderbit может за минуты собрать список компаний и выгрузить его в таблицу.
• Анализ popular times / трафика: через API это недоступно. Точка.
• Данные Q&A и блок "пользователи также ищут": видны только на странице, но не в API.

Когда имеет смысл гибридный подход

• Постоянный мониторинг цен и рейтингов: используй API для базовых структурированных данных (Place ID, адрес, сводный рейтинг), а парсинг — для глубоких полей, которых API не видит (полные отзывы, popular times).
• Workflow обогащения данных: API — чтобы получить Place ID и каноническую информацию о бизнесе, затем парсинг карточек — для полных наборов отзывов, Q&A и контекста конкурентов.
• Плановый мониторинг: scheduled scraper в Thunderbit (для no-code пользователей) или пакетный CLI-запуск по cron (для разработчиков) позволяют делать регулярный парсинг без собственной инфраструктуры.

Матрица выбора по кейсам

Сценарий	Рекомендуемый метод	Почему
Autocomplete в живом приложении	✅ Официальный API	Низкая задержка, соответствие ToS, надёжность
Выгрузка 5K+ полных наборов отзывов	✅ Парсинг / Scraping API	API ограничен 5 отзывами на место
Разовый список локальных бизнес-лидов	✅ Парсинг (или расширение Thunderbit)	Дешевле для batch; нет постоянной оплаты
Анализ popular times / трафика	✅ Только парсинг	Недоступно через API
Постоянный мониторинг цен/рейтингов	⚠️ Гибрид	API для базовых данных, парсинг для глубоких полей
Бэкенд приложения на основе геолокации	✅ Официальный API	Структура, поддержка, SLA
Отслеживание позиций в локальном SERP	✅ Парсинг / SERP API	Это не задача Places API
"Пользователи также ищут" у конкурентов	✅ Только парсинг	В API этого нет

Схема принятия решения: Google Places API или парсинг — что выбрать?

Вместо расплывчатого "зависит" — вот конкретный фреймворк выбора. Ответь на четыре вопроса:

1. Нужны ли тебе данные в реальном времени для продакшн-приложения? → Да: используй официальный API. Он поддерживается, имеет SLA и соответствует ToS. На этом всё. → Нет: идём дальше.

2. Нужны ли тебе данные, которые API не отдаёт (полные отзывы, popular times, Q&A)? → Да: нужен парсинг. API буквально не может дать эти данные. → Нет: идём дальше.

3. Сколько записей в месяц? → Меньше 10K: API, скорее всего, дешевле, особенно если тебе нужны только Essentials или Pro. На этом масштабе бесплатные лимиты покрывают многое. → Больше 10K: парсинг или managed scraping API, вероятно, будут экономичнее, особенно для богатых полей.

4. Есть ли у тебя разработчики, которые могут создавать и поддерживать парсеры? → Да: DIY на Puppeteer/Playwright даёт максимум контроля, но заложи бюджет на регулярную поддержку. → Нет: используй managed scraping API (Thunderbit API, SerpApi, Outscraper) или no-code инструмент (Thunderbit Chrome Extension).

Краткое сравнение альтернатив для разработчиков

Инструмент	Модель ценообразования	Формат вывода	Антибот-защита	Поддержка batch
Thunderbit API / MCP	Кредитная (Extract = 20 кредитов за запрос)	Структурированный JSON, согласованный со схемой	✅ JS-рендеринг, ротация прокси, geo-routing	✅ До 100 URL за batch
SerpApi	За поиск (тарифные планы)	Структурированный JSON	✅	✅ Через параметры API
Outscraper	За запись (pay-as-you-go)	JSON / CSV	✅	✅ Через очереди задач
DIY (Puppeteer/Playwright)	Прокси + время разработчиков	Сырой HTML (ты сам парсишь)	❌ Ты отвечаешь за это сам	✅ Как реализуешь

Ключевое отличие Thunderbit API: он возвращает структурированный JSON по JSON Schema, которую ты сам задаёшь, а не сырой HTML или Markdown, который ещё нужно дополнительно разбирать. Если ты кормишь LLM-пайплайн или загружаешь данные в базу, это экономит ощутимое время на постобработке.

Как в это вписывается Thunderbit (для бизнес-пользователей и разработчиков)

Мы создали Thunderbit, чтобы закрыть разрыв между "мне нужны данные Google Maps" и "я не хочу становиться инженером по scraping-инфраструктуре". Вот как это работает для обеих аудиторий.

Для нетехнических пользователей: Chrome Extension

1. Открой страницу Google Maps — страницу результатов поиска или карточку компании
2. Нажми "AI Suggest Fields" — AI Thunderbit считывает страницу и предлагает столбцы (название компании, адрес, рейтинг, отзывы, телефон и т. д.)
3. Нажми "Scrape" — расширение извлекает данные в структурированную таблицу. Для cloud mode можно обрабатывать до 50 страниц одновременно
4. Собери данные из подстраниц — нажми "Scrape Subpages", чтобы открыть каждую карточку и вытащить полные детали
5. Экспортируй — в Excel, Google Sheets, Airtable или Notion. Экспорт бесплатный, без paywall

Для регулярного мониторинга — еженедельной проверки рейтингов конкурентов, новых карточек бизнеса — scheduled scraper работает автоматически по выбранному расписанию.

Для разработчиков: API, MCP Server и CLI

• POST /extract с JSON Schema: отправляешь URL Google Maps, задаёшь нужные поля и получаешь структурированный JSON. Для тяжёлых на JavaScript страниц используй renderMode: "full". Thunderbit обрабатывает рендеринг, антибот-защиту, ротацию прокси и geo-routing.
• POST /distill: получает чистый Markdown с любой страницы — полезно для LLM-пайплайнов, где нужен исходный контент, а не структурированные поля. 1 кредит за запрос вместо 20 у Extract.
• MCP Server: AI-агенты (Claude, Cursor) могут собирать данные Google Maps прямо в процессе задачи. Поддерживаются distillation, структурированное извлечение, предложения полей и batch-задачи до 100 URL.
• CLI: thunderbit batch extract --file urls.txt --schema places.json для планового или CI/CD-интегрированного парсинга.

Цены по кредитам: Extract = 20 кредитов за запрос, Distill = 1 кредит за запрос. Кредиты API списываются за запрос, а не за строку (в отличие от расширения, где 1 кредит = 1 строка результата). Актуальные тарифы смотри на Thunderbit Pricing.

Юридические вопросы и условия использования

Скажу коротко и по фактам — без запугивания и без продаж.

У Google Places API есть чёткие правила: условия Google для конкретного сервиса говорят, что контент Places API можно использовать без Google Map, но нельзя использовать вместе с картой не от Google. Значения широты и долготы можно кэшировать максимум 30 календарных дней подряд; Place ID можно хранить бессрочно. Для деталей, фото и отзывов требуется атрибуция.

Парсинг Google Maps может нарушать Terms of Service Google. Принуждение к соблюдению зависит от ситуации — риски включают блокировку IP, CAPTCHA-барьеры и, в редких случаях, юридические действия. Managed scraping API обычно берут на себя часть рисков compliance от имени пользователей, но это не правовая защита.

Для продакшн-приложений, которыми пользуются конечные пользователи, официальный API — более безопасный выбор. Для внутренних исследований, batch-аналитики и конкурентной разведки парсинг — обычная индустриальная практика. По коммерческим рабочим процессам обязательно проконсультируйся со своим юристом.

Что бы выбрал я на практике и почему

После изучения тарифов, списков полей, обсуждений в комьюнити и документации инструментов, мой вывод такой:

• Используй официальный API, когда тебе нужны данные в реальном времени, соответствующие ToS, в продакшн-приложении, или когда полей Essentials/Pro достаточно и объём меньше 10K в месяц. На небольших объёмах бесплатные лимиты очень щедрые, а качество данных безупречно.
• Используй парсинг (managed API или no-code инструмент), когда тебе нужны полные отзывы, popular times, Q&A, контекст конкурентов или любое поле, которое API не отдаёт. Также если твой объём превышает 10K–100K записей в месяц и ты запрашиваешь богатые поля уровня Enterprise + Atmosphere — счёт API уже трудно оправдать.
• Используй оба подхода, когда твоему процессу нужны канонические Place ID и базовые структурированные данные из API, плюс глубокая информация со страницы через парсинг. Это встречается гораздо чаще, чем пишут в статьях.

Порог окупаемости: ниже примерно 10K записей в месяц и при базовых полях API проще и часто бесплатен. Выше этого уровня, особенно для богатых данных, парсинг становится экономичнее. На 1M записей с полями Enterprise + Atmosphere ты смотришь на ~$18K в месяц в API против заметно меньшей суммы у managed scraper.

Если хочешь проверить всё сам, Thunderbit Chrome Extension — самый быстрый способ увидеть, что именно собирает парсинг по сравнению с API. Для разработческих сценариев в Thunderbit API docs есть всё необходимое для старта. А если хочешь глубже разобраться в web scraping без кода или в AI web scraping в целом, у нас на блоге уже есть подробные материалы.

Ключевые выводы

• Google Places API — правильный инструмент для продакшн-приложений, autocomplete и структурированных запросов к местам, но он ограничивает отзывы пятью, фото — десятью и не показывает popular times, Q&A или предложения конкурентов.
• Парсинг позволяет собирать всё, что видно на странице Google Maps, включая полные наборы отзывов и данные о popular times, но требует обхода антибот-защиты или оплаты managed-сервиса.
• При объёме ниже 10K записей в месяц бесплатные лимиты API часто делают его самым дешёвым вариантом. Выше 100K парсинг или managed scraping API обычно выгоднее для богатых данных.
• DIY-парсеры регулярно ломаются из-за антибот-защиты Google и изменений DOM — закладывай 40+ часов разработчика в год на поддержку или используй managed-инструмент.
• Лучшее практическое решение чаще всего гибридное: API для канонических идентификаторов и базовых полей, парсинг — для глубокой информации, которую API вернуть не может.
• Thunderbit закрывает обе стороны: Chrome Extension для no-code пользователей и API/MCP server со структурированным JSON для разработчиков.

FAQ

Можно ли получить больше 5 отзывов Google через Places API?

Нет. Google Places API ограничивает выдачу отзывов пятью на одно место, отсортированными по релевантности. Это было так с момента запуска API и не изменилось, несмотря на многолетние просьбы разработчиков. Чтобы получить все доступные отзывы о компании, остаётся только парсинг — своими силами или через managed scraping API.

Законно ли парсить Google Maps?

Однозначного универсального ответа нет. Парсинг публично видимых данных Google Maps может нарушать Terms of Service Google, а меры воздействия варьируются от блокировки IP до редких юридических действий. Многие компании используют парсинг для внутренних исследований и конкурентной разведки без проблем. Managed scraping API частично снимают compliance-риск, но не являются юридической защитой. Если ты делаешь коммерческий продукт или обрабатываешь персональные данные, проконсультируйся с юристом.

Сколько стоит Google Places API для 100K запросов?

Это зависит от того, какие поля ты запрашиваешь. Для Place Details на уровне Essentials — около $450. На уровне Pro — около $1,615. На уровне Enterprise + Atmosphere (куда входят отзывы и удобства) — около $2,475. Если в твоём процессе ещё нужен Text Search Pro для поиска, добавь примерно $3,040. Эти оценки используют публичные объёмные тарифы Google и предполагают один платный запрос на запись после бесплатного лимита.

В чём разница между scraping API и no-code инструментом для парсинга?

Scraping API (например, Thunderbit Open API) предназначен для разработчиков, которые встраивают парсинг в код, автоматизацию или AI-agent workflow через HTTP-запросы. No-code инструмент (например, Thunderbit Chrome Extension) позволяет нетехническим пользователям просто кликать и экспортировать данные прямо из браузера без программирования. Оба варианта могут возвращать структурированные данные; разница — в интерфейсе и модели интеграции.

Thunderbit работает со страницами Google Maps?

Да. Chrome Extension умеет парсить результаты поиска в Google Maps и отдельные карточки компаний — AI автоматически предлагает поля, а в cloud mode можно обрабатывать до 50 страниц одновременно. Эндпоинт API POST /extract с renderMode: "full" обрабатывает страницы Google Maps, рендеримые JavaScript, и возвращает структурированный JSON, согласованный со схемой. MCP server позволяет AI-агентам получать данные Google Maps прямо во время workflow.

Узнать больше

• Что такое Web Scraping
• AI Web Scraping
• Альтернативы Instant Data Scraper
• Web Scraping без кода
• AI Lead Generation