SerpAPI is down ?

Cet article est daté du 16 septembre 2026. Les équipes qui se demandent si SerpAPI est en panne cette semaine ont un historique public. Leur page de statut affiche Performance Degradation à la mi-septembre 2026. Le 10 septembre 2026, ils ont signalé une panne sur leurs API. Une mise à jour du 16 septembre 2026, 05:13 UTC, indiquait une amélioration du taux de succès et du temps de réponse sur les heures précédentes. L’incident était encore ouvert au moment de la rédaction.

Leur note du 10 septembre attribue le problème à des changements récents côté Google. C’est ce point qui compte pour toute intégration Google Search. Le même historique d’incidents liste déjà plusieurs incidents Google Search en juillet et août.

Ce que Google a changé

Depuis un an, Google rend la collecte automatisée des résultats Search plus difficile.

En septembre 2025, &num=100 a été désactivé. Les pipelines qui attendaient 100 résultats par page ont dû paginer. Nous l’avons décrit dans Google a tué num=100.

En décembre 2025, Google a assigné SerpAPI, en alléguant un contournement de SearchGuard. Le détail technique public est dans Google attaque SerpAPI : ce que SearchGuard révèle.

Fin août 2026, les liens organiques ont commencé à pointer vers google.com/goto?url=CAES… au lieu de l’URL de destination. Le paramètre n’est pas une URL décodable. Google renvoie la destination dans l’en-tête Location de /goto. Déploiement : google.com/goto : l'anti-scraping de Google. Méthode : lire Location avec HEAD.

Cet article /goto a été discuté sur Hacker News. La plupart des commentaires portent sur l’expérience Search grand public. Pour un fournisseur d’API, l’effet concret est une requête de plus par résultat, et un signal plus net lorsqu’un client résout de nombreuses URL /goto à la suite.

SearchGuard opère en arrière-plan. Une session qui paraît automatisée peut recevoir une page incomplète ou une erreur. Avec /goto, cela se traduit par plus de latence et plus d’erreurs sur les endpoints Google Search.

Chronologie publique (juillet-septembre 2026)

D’après l’historique d’incidents SerpAPI, limité à Google Search. Toutes les dates ci-dessous sont en 2026.

Juillet

7-12 juillet : réponses plus lentes et taux de succès plus bas. Clôturé après des changements internes et en amont
13 juillet-1er août : recherches paginées Google Light (start) renvoyant des résultats vides
14-17 juillet : API Google plus lentes ; certaines réponses Light vides. La note de statut cite des changements Google récents et un prestataire en amont
20 juillet-14 août : latence élevée sur Google Search et Google Light

Août

7-9 août : panne sur de nombreuses API Google ; une grande part des requêtes en échec ou en dépassement de délai
14-15 août : dégradation des API Google, attribuée à des changements côté Google. Marqué résolu le lendemain
À partir du 26 août (toujours ouvert) : dépassements de délai sur tbm=nws, et requêtes Google Search avec opérateurs avancés en timeout ou HTTP 500 (500 noté le 29 août)

Septembre

4-10 septembre : temps de réponse élevés sur Search, Shopping, News Light, Jobs et d’autres. Clôturé le 10 septembre, avec renvoi vers les incidents News et opérateurs avancés déjà ouverts
5-7 septembre : Google News dégradé, puis marqué résolu
10 septembre, 15:59 UTC (toujours ouvert) : panne, puis Performance Degradation. Mention de changements côté Google (roadmap #4265). Atténuation partielle les 10-11 septembre ; location et uule décrits comme peu fiables hors États-Unis (gl, hl, google_domain comme contournement). Nouvelles hausses d’erreurs et de latence les 14-15 septembre. Mise à jour du 16 septembre, 05:13 UTC : meilleur taux de succès et temps de réponse sur les heures précédentes
11 septembre (toujours ouvert) : Google Local renvoie des résultats vides

Fin août et septembre correspondent au déploiement de /goto. Les incidents de juillet sont de la latence Google plus ancienne, avant que /goto soit généralisé.

Autom est pleinement opérationnel

L’API Google Search d’Autom est 100 % fonctionnelle face à ces changements Google récents. Nous résolvons /goto en lisant Location (sans suivre la redirection) et renvoyons la destination dans organic_results[].link, dans les mêmes champs structurés qu’avant.

La pagination après num=100 et la gestion SearchGuard étaient déjà dans le pipeline. Si vous appelez nos endpoints Google Search, vous devriez continuer à recevoir des URL de destination exploitables.

1 000 requêtes gratuites sur les tarifs Autom, clé API sur app.autom.dev/register.