Ce que dit vraiment la documentation de Google
La question revient souvent sur les forums, en général juste après qu'un collègue a juré que « l'API Indexing, ça indexe tout en deux heures ». Avant de parler de ce qui marche ou pas, regardons le texte. La documentation officielle de l'API Indexing est sans ambiguïté : elle ne peut être utilisée que pour des pages qui contiennent soit des données structurées JobPosting, soit un BroadcastEvent intégré dans un VideoObject.
En langage courant : des offres d'emploi, et des vidéos diffusées en direct. C'est tout. Pas les articles de blog, pas les fiches produits, pas les pages d'actualité, même brûlantes.
La logique se comprend vite. Une offre d'emploi pourvue doit sortir des résultats rapidement, sinon les candidats postulent dans le vide. Un live n'a de valeur que pendant qu'il a lieu. Dans les deux cas, attendre le passage naturel de Googlebot, qui peut prendre des jours, rend l'information fausse ou inutile. L'API a été pensée pour ces contenus à durée de vie très courte, pas comme un raccourci d'indexation pour tout le web.
Qui peut s'en servir, concrètement ?
Il n'y a pas de liste blanche, pas de formulaire de candidature, pas de statut « grand compte » à décrocher. N'importe quel site peut activer l'API, avec une seule condition technique : le compte qui envoie les notifications doit être propriétaire de la propriété dans la Search Console. Le filtre ne porte pas sur qui vous êtes. Il porte sur ce que contiennent vos pages.
Dans la pratique, les usages légitimes ressemblent à ça :
- les sites d'emploi et agrégateurs d'annonces, qui publient et retirent des offres en continu ;
- les pages carrières d'entreprises, et les logiciels de recrutement qui génèrent ces pages pour leurs clients ;
- les cabinets de recrutement et agences d'intérim qui balisent proprement leurs annonces ;
- les plateformes et médias qui diffusent des événements en direct (sport, conférences, concerts, émissions) avec le balisage vidéo adéquat.
Un point souvent mal compris : avoir une page « Nous recrutons » avec deux postes ouverts vous rend éligible pour ces deux annonces, pas pour le reste du site. L'éligibilité se juge URL par URL.
Et pour vos articles, fiches produits ou pages catégories ?
C'est là que ça devient intéressant, parce que techniquement, rien ne vous empêche d'envoyer l'URL d'un article de blog. L'API ne vérifie pas le contenu au moment de l'appel : elle accepte la requête et renvoie une réponse 200. Beaucoup en concluent que « ça marche ». Des extensions WordPress et des services d'indexation express se sont d'ailleurs construits sur ce malentendu.
Une réponse 200 veut dire que Google a bien reçu la notification, pas que la page est éligible, ni qu'elle sera explorée, encore moins indexée.
Sur le terrain, j'ai déjà vu dans des logs serveur Googlebot passer peu après une notification sur une page hors cadre. J'ai aussi vu l'inverse, des notifications restées lettre morte pendant des semaines. Le comportement n'est pas documenté, donc pas fiable, et il peut changer du jour au lendemain sans que personne ne soit prévenu. Bâtir un process d'indexation là-dessus, c'est construire sur du sable.
Surtout, Google a durci le ton. La documentation précise désormais que tous les envois passent par une détection de spam, et que les tentatives d'abus (multiplier les comptes ou les projets pour dépasser les quotas, par exemple) peuvent entraîner la révocation de l'accès. Les porte-parole de Google ont aussi rappelé à plusieurs reprises qu'il valait mieux s'en tenir aux cas d'usage documentés. Le risque principal n'est donc pas une chute de classement spectaculaire. C'est de perdre l'outil, et d'attirer l'attention sur un site qui n'avait rien à y gagner.
Et puis, franchement : quand une page n'est pas indexée, c'est rarement un problème de notification. C'est plus souvent une affaire de qualité perçue, de duplication ou de maillage. Sur un gros site, regardez plutôt du côté de la définition du budget de crawl et de ses vrais leviers d'optimisation. L'API ne règle aucun de ces problèmes.
Si vos pages sont éligibles : la mise en place
Pour un site d'emploi ou une plateforme de lives, l'API vaut vraiment le détour. La configuration se fait sans douleur quand on a déjà mis un pied dans la Google Cloud Console.
- Créez un projet dans la Google Cloud Console et activez l'API Indexing dans la bibliothèque d'API.
- Créez un compte de service et téléchargez sa clé au format JSON. Gardez-la hors de votre dépôt de code, évidemment.
- Dans la Search Console, ajoutez l'adresse e-mail du compte de service comme propriétaire de la propriété. Un simple accès utilisateur ne suffit pas.
- Vérifiez que chaque page porte un balisage JobPosting ou BroadcastEvent valide. Si ce vocabulaire vous est étranger, notre guide pour débutants sur les données structurées et schema.org pose les bases.
- Envoyez une notification URL_UPDATED à la publication ou à la modification d'une page, et URL_DELETED quand l'offre est pourvue ou le live terminé, une fois la page passée en 404, en 410 ou en noindex.
Côté volume, le quota par défaut reste modeste : la documentation l'affiche à 200 requêtes de publication par jour et par projet, avec la possibilité de demander une augmentation si l'usage le justifie. Pour un job board qui brasse des milliers d'annonces, c'est cette demande qui fera foi, pas la création de dix projets en parallèle. C'est précisément le contournement que Google dit surveiller.
Pour tout le reste, les leviers que Google accepte
Pour les pages classiques, Google renvoie vers des méthodes moins spectaculaires mais durables, détaillées dans sa page consacrée à la demande de nouvelle exploration des URL :
- un sitemap XML à jour, avec une date lastmod honnête, qui change quand le contenu change vraiment et pas à chaque régénération du fichier ;
- l'outil d'inspection d'URL de la Search Console et son bouton « Demander une indexation », limité en nombre mais parfait pour une poignée de pages importantes ;
- des liens internes depuis des pages déjà bien explorées, comme la page d'accueil ou les rubriques principales.
Rien de magique là-dedans. Mais un robots.txt bien réglé et un sitemap XML propre pour piloter l'exploration de votre site, couplés à un maillage cohérent, font plus pour l'indexation sur la durée qu'une API détournée de son usage. C'est moins grisant qu'un appel API, je vous l'accorde. Mais ça ne risque pas de vous être retiré un matin.