5 meilleures Google Maps scraper APIs: testées et classées

Pour trouver le meilleur scraper Google Maps, nous avons benchmarké cinq fournisseurs de web scraping, Apify, SerpApi, Oxylabs, Zyte et Nimble, en demandant à chacun les mêmes 1 000 entreprises. Les entreprises couvrent 10 catégories dans 10 villes américaines, pour 5 000 requêtes au total.

Résultats du benchmark de scraping Google Maps

Étant donné que tous les fournisseurs ont dépassé 90 % de réussite, nous avons comparé le temps d'exécution :

Champs de métadonnées disponibles par Google Maps scraper

Seuls SerpApi et Apify ont renvoyé du JSON structuré, ce sont donc les deux pour lesquels nous avons compté les champs. Apify a renvoyé en moyenne 71 champs par lieu et SerpApi 30. Les autres fournisseurs ont renvoyé du HTML rendu, qui n'a pas de nombre de champs à signaler, nous avons donc validé leurs réponses avec des sélecteurs CSS à la place.

29 de ces champs contiennent les mêmes données chez les deux, parfois sous des noms différents : totalScore et rating, reviewsCount et reviews, placeId et place_id. Le tableau ci-dessous liste uniquement ce que l'un renvoie et pas l'autre.

Essai gratuit des scrapers Google Maps

Meilleurs scrapers Google Maps

Bright Data répartit sa couverture Google Maps sur six scrapers. Quatre d'entre eux renvoient les informations complètes sur l'entreprise et ne diffèrent que par la façon dont vous désignez un lieu. Les deux autres couvrent une seule partie d'une fiche.

Informations sur l'entreprise

• Collecter par URL : Vous fournissez une URL de lieu Google Maps et récupérez l'entreprise correspondante.
• Découvrir par identifiant de lieu : Prend l'identifiant de lieu propre à Google au lieu d'une URL, ce qui est utile lorsque vos enregistrements contiennent déjà des identifiants de lieu et que vous ne voulez pas créer des URL pour eux.
• Découvrir par CID : La même idée avec l'identifiant client, l'identifiant numérique derrière une fiche Maps.
• Découvrir par emplacement : Exécute une recherche par emplacement et renvoie les entreprises trouvées, ce qui vous permet de collecter des lieux que vous n'avez pas identifiés à l'avance.

Avis et images

Images, collecter par URL : Renvoie les photos associées à une fiche.

Avis, collecter par URL : Renvoie les avis sur un lieu plutôt que la fiche d'entreprise. Il prend un paramètre days_limit, ce qui permet de demander uniquement les avis récents, par exemple les 9 ou 18 derniers jours, au lieu d'extraire tout l'historique.

Les quatre premiers sont ceux à comparer entre eux : ils renvoient le même enregistrement et ne diffèrent que par l'entrée qu'ils acceptent. Celui qui convient dépend de l'apparence de vos données existantes. Si vous disposez d'URL, la collecte par URL est la voie directe. Si vous disposez d'identifiants de lieu ou de CID, le scraper de découverte correspondant vous évite une étape de construction d'URL. Si vous ne disposez ni de l'un ni de l'autre et souhaitez créer une liste à partir de zéro, la découverte par emplacement est le seul des quatre à trouver des lieux plutôt qu'à récupérer ceux que vous avez déjà nommés.

Les requêtes s'exécutent en mode synchrone ou asynchrone. En mode synchrone, le navigateur reste ouvert et les données reviennent dès que la tâche se termine.

Oxylabs propose deux voies d'accès à Google Maps, et celle que vous pouvez utiliser dépend de votre point de départ.

La source dédiée google_maps prend une requête de recherche plutôt qu'une URL. Elle n'accepte pas de paramètre url et ne prend pas en charge la sortie analysée : demander l'un ou l'autre renvoie une erreur indiquant que la source n'est pas disponible avec ce paramètre. Elle convient donc au travail de découverte, où vous recherchez des lieux plutôt que de récupérer ceux que vous détenez déjà.

La source générale google accepte n'importe quelle URL Google, y compris les pages de lieu. C'est la voie à utiliser lorsque vous avez déjà des URL Maps. Définir render sur html exécute le JavaScript, et geo_location fixe le pays de sortie, ce qui est important sur les propriétés Google, car une sortie européenne peut renvoyer un interstitiel de consentement au lieu de la page.

SerpApi divise Google Maps en sept APIs. Deux d'entre elles partagent le moteur google_maps et diffèrent par l'entrée, et les autres sont des moteurs distincts basés sur un identifiant que les deux premières vous fournissent.

Le moteur google_maps

• Résultats locaux : type=search avec une requête et des coordonnées ll. Renvoie les entreprises correspondant à une recherche, 20 à la fois.
• Résultats de lieu : Le même moteur avec place_id ou data_cid au lieu d'une requête. Renvoie une fiche d'entreprise, sans étape de recherche.

Moteurs dédiés

• Avis : google_maps_reviews, basé sur data_id ou place_id. Celui-ci offre le plus de contrôles : tri par qualityScore, newestFirst, ratingHigh ou ratingLow, filtrage par mot-clé ou topic_id, et pagination via num et next_page_token.
• Photos : google_maps_photos, basé sur data_id. Renvoie les images en taille réelle et les vignettes avec l'utilisateur qui les a publiées.
• Publications : google_maps_posts, basé sur data_id. Renvoie les publications de l'entreprise elle-même.
• Avis de contributeurs : google_maps_contributor_reviews, basé sur un contributor_id tiré de l'URL du profil d'un évaluateur. Renvoie tout ce qu'une personne a évalué, ce qui est l'inverse de l'API Avis : il part de l'évaluateur plutôt que du lieu.
• Autocomplétion : google_maps_autocomplete, basé sur une requête. Renvoie les suggestions que Google afficherait pendant que vous tapez.
• Itinéraires : google_maps_directions, prenant un point de départ et un point d'arrivée sous forme d'adresses, de coordonnées ou d'ID de données. Renvoie des itinéraires avec distances, durées et étapes détaillées.

Les identifiants sont ce qui relie tout cela. Une recherche renvoie place_id, data_id et data_cid pour chaque entreprise, et ce sont les clés attendues par les moteurs d'avis, de photos et de publications ; le premier appel détermine donc lesquels des autres vous pouvez effectuer.

Dans notre benchmark, nous avons utilisé Résultats de lieu : engine=google_maps avec le place_id de chacune des 1 000 entreprises du jeu de données, et no_cache=true afin qu'une réponse en cache ne puisse pas être renvoyée.

Apify est une marketplace ; vous choisissez donc un actor plutôt qu'un endpoint. Celui que nous avons utilisé pour Google Maps est compass/crawler-google-places, publié sous le nom de Google Maps Scraper. Il est facturé par événement.

Il accepte soit un terme de recherche avec un lieu, soit des URL de départ lorsque vous connaissez déjà les lieux voulus. Le reste de l'entrée est constitué d'options facultatives, dont plusieurs coûtent un supplément : filtres de catégorie et de nombre d'étoiles, exclusion des lieux fermés, ouverture de la page de détail du lieu et récupération des prestataires de réservation, des widgets de commande en ligne ou des résultats web.

Les exécutions sont asynchrones. Vous lancez une exécution, interrogez jusqu'à ce qu'elle se termine, puis lisez les résultats depuis son dataset.

Dans notre benchmark Google Maps, nous avons utilisé cet actor avec startUrls défini sur chaque URL de lieu et maxCrawledPlacesPerSearch à 1, afin qu'il renvoie uniquement l'entreprise demandée. Les avis, images, résultats web et recherches associées ont été désactivés.

Zyte ne propose pas de produit spécifique Google Maps. Vous appelez l'Zyte API générale sur /v1/extract avec l'URL du lieu et demandez browserHtml, ce qui exécute un navigateur complet et renvoie la page rendue. Il n'y a pas de schéma Maps analysé derrière ; ce que vous récupérez est du HTML à analyser vous-même.

Un paramètre compte plus que ne le suggère la documentation : geolocation. S'il n'est pas défini, nos requêtes sortaient en Europe et revenaient avec l'interstitiel de consentement de Google, une vraie page avec un statut 200 et aucune donnée de lieu dessus. En le fixant sur US, le lieu était renvoyé. Au-delà, aucune instruction supplémentaire n'était nécessaire : le panneau était déjà affiché à l'arrivée de la réponse.

Nimble propose deux voies. L'API Web prend une URL avec render activé et renvoie la page rendue, de la même forme que Zyte. Son SERP API liste également Google Maps parmi les moteurs pris en charge, en prenant une requête plutôt qu'une URL, ce qui convient à la découverte plutôt qu'à la récupération d'un lieu que vous détenez déjà.

Les réponses analysées reviennent groupées par type d'entité plutôt que sous forme d'une liste unique, avec les résultats organiques, la pagination et les informations de recherche dans des compartiments séparés. La même réponse contient également le HTML brut à côté des données analysées ; vous obtenez donc les deux en un seul appel.

Octoparse est un modèle que vous exécutez dans son application ou son cloud plutôt qu'un endpoint que vous appelez.

Ce qu'il prend en entrée

• Mots-clés avec lieux : jusqu'à 100 000 combinaisons de mots-clés et de lieux, le lieu étant indiqué comme une ville, une région ou un pays.
• URL de lieu : jusqu'à 5 000 d'entre elles, lorsque vous connaissez déjà les entreprises voulues.
• Langue : anglais, français, espagnol, italien, coréen, japonais ou chinois traditionnel.

Ce qu'il renvoie

Titre, adresse décomposée en pays, ville et État, plus code, latitude et longitude, téléphone, site web, catégorie, horaires d'ouverture, statut actuel, gamme de prix, note et nombre d'avis, contenu des avis et informations sur les évaluateurs, heures d'affluence, images, description, livraison, URL de la page, et à la fois l'ID Google et l'identifiant de lieu.

Méthodologie du benchmark des scrapers Google Maps

Nous avons benchmarké 5 fournisseurs de données (Apify, SerpApi, Oxylabs, Zyte, Nimble) sur leur capacité à renvoyer des données d'entreprises Google Maps. Chaque fournisseur a reçu les mêmes 1 000 entreprises, une requête par entreprise, pour 5 000 requêtes au total.

Dataset

Nous avons constitué le dataset à l'avance plutôt que de lancer des recherches au moment de l'exécution, afin que chaque fournisseur reçoive les mêmes lieux dans le même ordre.

• Lieux : 1 000 entreprises, chacune avec sa propre URL Google Maps et son identifiant de lieu.
• Villes (10) : New York, Los Angeles, Chicago, Houston, Phoenix, Philadelphia, San Antonio, San Diego, Dallas et Austin, 100 entreprises pour chacune.
• Catégories (10) : café, restaurant, salle de sport, pharmacie, hôtel, hôpital, banque, supermarché, station-service et salon de coiffure.
• Adressage : cinq fournisseurs ont reçu l'URL Google Maps. SerpApi a reçu l'identifiant de lieu, car son produit Google Maps prend un identifiant plutôt qu'une URL.

Paramètres de test

• Exécutions : une requête par entreprise, sans répétitions.
• Exécution : séquentielle, une requête à la fois, avec une pause entre elles. Pas de requêtes parallèles.
• Délais d'expiration : 300 secondes pour soumettre, 600 secondes pour terminer.
• Limites de débit : sur une réponse HTTP 429, la requête était réessayée jusqu'à 3 fois.

Implémentations des fournisseurs

• Apify : l'Actor compass/crawler-google-places, asynchrone. L'URL du lieu a été passée comme startUrls avec maxCrawledPlacesPerSearch défini sur 1, pour que l'Actor renvoie cette entreprise plutôt que de crawler plus loin. Les avis, images, résultats web et recherches associées ont été désactivés.
• SerpApi : le moteur google_maps avec place_id et no_cache=true. La mise en cache a été désactivée car une recherche en cache est gratuit, n'est pas décomptée du quota et rendrait la mesure du temps sans signification.
• Oxylabs : l'API Realtime Scraper avec source: google, l'URL du lieu, render: html et geo_location: United States, plus browser_instructions pour attendre, faire défiler et attendre à nouveau. Sans eux, la réponse revenait comme une coquille, avec le nom de l'entreprise dans le titre de la page et aucun panneau de lieu dans le DOM.
• Zyte : Zyte API /v1/extract avec browserHtml et geolocation: US. S'il n'est pas défini, les requêtes sortaient en Europe et renvoyaient l'interstitiel de consentement de Google, une vraie page avec un statut 200 et aucune donnée de lieu dessus.
• Nimble : l'API Web avec l'URL du lieu, le rendu activé et le pays défini sur les États-Unis (US).

Succès

Le statut HTTP est vérifié en premier. Les réponses entre 200 et 399, ainsi que 404, passent à la validation. Tout autre statut échoue sans atteindre les données. Un 404 réussit sur la base du statut seul, car signaler correctement une page qui n'existe plus est une réponse correcte et il n'y a aucune donnée à vérifier.

Pour les fournisseurs renvoyant du JSON, au moins un des quatre champs devait être présent et du bon type :

• Nom : une chaîne non vide.
• Adresse : si présente, une chaîne non vide et différente de « N/A ».
• Numéro de téléphone : si présent, au moins 5 chiffres.
• Nombre d'avis : si présent, un nombre non négatif. Zéro compte, car une entreprise sans avis est une vraie réponse.

Pour les fournisseurs renvoyant du HTML rendu, au moins un des sélecteurs de lieu devait correspondre et renvoyer une valeur. Les sélecteurs sont basés sur les attributs plutôt que sur les classes, car les noms de classe de Google sur cette page sont des hachages de build qui changent à chaque déploiement.

Nous avons enregistré quelle règle a validé chaque requête, afin qu'un sélecteur devenu obsolète apparaisse différemment dans les données d'un fournisseur ne renvoyant rien.

Temps

Les temps sont calculés uniquement sur les requêtes réussies, car un délai d'attente ou une erreur instantanée ne vous indique pas combien de temps il faut pour obtenir des données.

Métadonnées disponibles

Nous avons compté les champs dans l'enregistrement renvoyé par chaque fournisseur. Ceci n'est rapporté que pour les fournisseurs qui renvoient du JSON structuré. Les trois qui renvoient une page rendue sont laissés vides plutôt que notés zéro : ce que nous pourrions extraire d'une page est un compte des sélecteurs que nous avons écrits, pas de ce que le fournisseur propose.

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.

Ajouter comme source préférée

FAQ

Citez ce benchmark

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{sipi2026,
  author = {Şipi, Nazlı},
  title  = {{5 meilleures Google Maps scraper APIs: testées et classées}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/google-maps-scraper}},
  note   = {AIMultiple. Consulté le 29 septembre 2026}
}

Journal des modifications

4 mises à jour

20262025

1. 30 jan

   La section "How to scrape Google Maps with Python" a été supprimée.

Nazlı Şipi

Chercheuse en IA

Suivre

Nazlı est analyste de données chez AIMultiple. Elle a une expérience préalable en analyse de données dans divers secteurs, où elle a travaillé à transformer des datasets complexes en informations exploitables.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire