SpeedyIndex : indexation Google et Yandex en paiement au résultat

SpeedyIndex envoie le Googlebot Smartphone vers des URL que vous ne pouvez pas inspecter dans Search Console. Le service facture l’indexation confirmée, pas le simple dépôt d’une liste. Un URL indexé coûte 100 jetons. Google revérifie au jour 7. Yandex revérifie au jour 15. Les jetons reviennent quand l’URL reste hors index et restait accessible. Une page en 404, bloquée par robots, en noindex ou coincée dans une boucle de redirection sort de ce remboursement automatique. Google et Yandex décident seuls de stocker la page. SpeedyIndex ne promet pas 100 % d’indexation.

Le bandeau d’accueil parle souvent d’un « remboursement 100 % de tout lien non indexé ». Lisez la règle produit, pas le slogan. Le paiement au résultat rembourse les échecs éligibles. Il ne transforme pas une URL morte en avoir. L’indexation Google à la soumission (pay-per-submit) est temporairement indisponible. Le paiement au résultat, lui, est en ligne. Bing n’a pas d’indexeur ici : seulement un vérificateur.

Vous ouvrez le service sur l’accueil SpeedyIndex en français. Vous importez un fichier .txt ou vous collez les URL. Vous n’avez pas besoin de GSC. Les URL de tiers passent : guest posts, communiqués, commentaires, pages que vous ne possédez pas. Le crawler se présente comme Googlebot Smartphone. Ensuite Google choisit. Le guide officiel de Google sur l’exploration et l’indexation le rappelle : découvrir une URL, l’explorer et la stocker sont trois étapes distinctes. Un clic de bot n’équivaut pas à une ligne dans l’index.

Le paiement au résultat facture la ligne indexée, pas le dépôt

Les indexeurs classiques débitent chaque URL soumise. Vous payez le volume. Si Google refuse soixante lignes sur cent, vous avez déjà payé les cent. SpeedyIndex inverse le compte : 1 URL indexée = 100 jetons. Au jour 7 pour Google, au jour 15 pour Yandex, le rapport sépare trois familles. Indexée : les jetons restent débités. Non indexée et éligible : les jetons reviennent. Inaccessible : pas de remboursement automatique.

Cette distinction protège le budget netlinking quand la page existe vraiment et que Google décline. Elle ne protège pas un fichier sale. Un 404 n’est pas un « miss » d’indexation. Un noindex non plus. Robots.txt qui refuse Googlebot non plus. Une boucle de redirection non plus. Le service peut garantir une visite du Googlebot Smartphone. Il ne peut pas forcer Google à conserver le document.

Le mode pay-per-submit Google n’est plus proposé pour l’instant. Ne construisez pas un devis autour de cette file. Travaillez uniquement en paiement au résultat. Yandex suit la même logique de jetons, avec un calendrier plus long. Ne mélangez pas les deux moteurs dans une seule tâche. Un rapport Google au jour 7 ne dit rien d’une file Yandex.

Les jetons s’achètent par packs. Ils servent aussi aux vérificateurs. Un compte neuf reçoit 200 jetons d’essai. N’en faites pas une campagne. Servez-vous-en pour tester le rapport : une poignée d’URL propres, un contrôle d’index, puis une petite tâche Google. Vous voyez alors comment le jour 7 parle, avant de coller 8 000 lignes.

Ce que le bandeau d’accueil oublie sur le remboursement

Le marketing aime la phrase courte. « Non indexé = remboursement intégral » tient en une ligne. La règle tient en deux. Premier cas : le crawler a pu lire la page, Google n’a pas stocké, les jetons reviennent. Second cas : la page n’était pas indexable au moment du passage — 404, 403, robots, noindex, boucle — et le remboursement automatique ne s’applique pas.

Cette règle évite de transformer SpeedyIndex en assurance tous risques pour éditeurs négligents. Si le publisher retire l’article après publication, le problème n’est plus l’indexeur. Si le canonical pointe ailleurs et que Google fusionne, le stockage peut viser une autre URL que celle de votre tableur. Si la page répond 200 mais envoie un X-Robots-Tag: noindex, vous avez envoyé une consigne de refus. Le jour 7 n’a pas à vous rembourser ce refus.

Activez le précontrôle optionnel quand la liste vient d’un export douteux. L’option est éteinte par défaut. Elle peut écarter les 404, 410, 451, les blocages robots/noindex, les médias et les URL déjà indexées. Elle ne note pas la qualité du texte. Elle ne remplace pas un curl sur un échantillon. Elle évite surtout d’envoyer dans la file des lignes qui n’entreront jamais dans le panier « miss éligible ».

Sur une tâche Drip-Feed, le chronomètre Google de 7 jours démarre après le dernier lot quotidien, pas après le clic de création. Une campagne de 14 jours n’offre pas un rapport consolidé le lundi suivant. Elle l’offre sept jours après la dernière portion. Si vous promettez un avoir « lundi prochain » à un client, vous avez lu le mauvais calendrier.

« Nous remboursons les URL Google non indexées au jour 7 lorsqu’elles étaient accessibles au crawl. Nous ne remboursons pas un 404, un 403, un blocage robots, un noindex ou une boucle de redirection. En Drip-Feed, la fenêtre de sept jours suit le dernier lot. Bing n’a pas d’indexeur. Nous ne vendons pas 100 % d’indexation. »

— l’équipe SpeedyIndex

Gardez cette phrase sous les yeux quand vous lisez le bandeau. Le slogan vend la tranquillité. L’équipe décrit le contrat.

Standard pour une liste courte, Indexation Drip-Feed pour un calendrier

Deux modes existent. Standard convient à une liste courte que vous assumez de relâcher d’un coup. Indexation Drip-Feed convient à Google en paiement au résultat quand vous voulez étaler. L’API expose drip_feed et drip_feed_days (2 à 30). Le nombre d’URL doit être au moins égal au nombre de jours. Vous ne pouvez pas demander 21 jours pour 10 lignes.

Le Drip-Feed ne « booste » pas les positions. Il coupe une rafale. Un dump de 20 000 commentaires en une heure envoie un pic de crawl vers des hôtes que vous ne contrôlez pas. Sur un domaine jeune, ce pic ressemble à une poussée artificielle. Sur un réseau de guest posts, il réveille des éditeurs qui n’avaient pas prévu Googlebot en masse le lundi matin. L’Indexation Drip-Feed répartit les mêmes URL sur la durée choisie.

Le crawler reste le même : Googlebot Smartphone. Le tarif reste le même : 100 jetons par URL indexée. Seul le calendrier change. Et le calendrier change le remboursement. Notez la date du dernier lot. Ajoutez sept jours. C’est la date du rapport Google consolidé. Avant ça, le tableau de bord peut montrer des progrès. Il ne clôt pas encore le compte.

N’utilisez pas le Drip-Feed comme rustine Bing. Bing n’indexe rien via SpeedyIndex. N’y mélangez pas Yandex. Une tâche Yandex a son propre horloge à 15 jours. Une tâche Google Drip-Feed de 10 jours plus 7 jours d’audit n’est pas interchangeable avec une file Yandex lancée le même matin.

Standard n’est pas « plus rapide pour indexer ». Standard est plus rapide pour vider la file. Si Google refuse le document, la vitesse d’envoi n’a rien changé. Si la liste est propre et courte — quelques dizaines de guest posts déjà vérifiés — Standard suffit. Si la liste est longue, ou si le domaine cible est neuf, passez en Drip-Feed et tenez le journal des lots.

Vérifier avant d’envoyer : Google, Yandex, Bing

Indexer une URL déjà stockée gaspille un crawl. Indexer un 404 gaspille un argument de remboursement. Les vérificateurs existent pour ça. Ils ne soumettent rien. Ils marquent oui ou non.

Le vérificateur d’index Google lit l’appartenance à l’index Google sans propriété Search Console. Vous collez des guest posts chez un éditeur que vous ne vérifierez jamais. Vous obtenez une colonne datée. Sortez les lignes déjà présentes. Gardez les absentes. Contrôlez un échantillon à la main : statut HTTP, robots, meta, canonical. Ensuite seulement, créez la tâche de paiement au résultat.

Le vérificateur d’index Yandex fait le même travail pour Yandex. Un « oui » Yandex n’est pas un « oui » Google. Un site russe ou bilingue peut vivre dans un moteur et pas dans l’autre. Si vous payez une tâche Yandex, relisez le jour 15, pas le jour 7. Si vous ne travaillez que Google, ne créez pas la file Yandex « pour voir ».

Le vérificateur d’index Bing s’arrête au constat. SpeedyIndex n’envoie pas Bingbot pour indexer. L’indexation Bing est hors service ici. Une ligne verte Bing ne prouve pas que Google stocke. Une ligne rouge Bing ne justifie pas une tâche Google. Servez-vous de Bing comme troisième colonne d’audit, jamais comme file d’envoi.

Ces trois outils partagent une discipline. Une URL, un moteur, un horodatage. N’inventez pas un statut moyen « 70 % indexé » en mélangeant les moteurs. N’utilisez pas une capture site: personnalisée comme facture. Le rapport de tâche reste la source des jetons. Le vérificateur reste la source d’un second avis daté.

Avant une grosse file, un extracteur de sitemap aide à lister les URL que vous possédez vraiment. Sur les backlinks, l’extracteur ne remplace pas le tableur d’achat. Sur vos propres pages, il évite d’oublier des catégories ou d’envoyer des paramètres de filtre. Le précontrôle, s’il est allumé, recoupe 404 et déjà indexé. Le vérificateur, lui, reste le juge d’appartenance à l’index.

Jetons, essai, précontrôle : les limites qui comptent vraiment

Oubliez les plafonds quotidiens inventés. Les limites utiles tiennent dans le contrat produit. 100 jetons par URL indexée. Fenêtre Google 7 jours. Fenêtre Yandex 15 jours. Drip-Feed entre 2 et 30 jours, avec au moins autant d’URL que de jours. Précontrôle optionnel, éteint par défaut. Essai : 200 jetons. Pas de vérification GSC. URL de tiers acceptées. Bing en lecture seule.

Le précontrôle filtre 404, 410, 451, robots/noindex, médias et déjà indexé. Il ne juge pas l’intérêt éditorial. Une page vide en 200 passe. Une page dupliquée passe. Une canonical vers l’accueil passe. Google peut ensuite refuser le stockage. Ce refus-là, s’il arrive sur une URL accessible, entre dans le remboursement. Ce n’est pas un bug. C’est le moteur qui décide.

Les 200 jetons d’essai couvrent deux URL indexées, ou davantage de contrôles. Ne les brûlez pas sur un dump non filtré. Vérifiez dix URL. Envoyez trois URL propres. Lisez le rapport. Vous comprenez alors la différence entre « visité » et « stocké ».

N’attendez pas de SpeedyIndex qu’il remplace Search Console. L’inspection d’URL, les sitemaps, les journaux de couverture restent chez le propriétaire. SpeedyIndex sert surtout quand vous n’êtes pas ce propriétaire : le guest post, le communiqué, le commentaire, la page partenaire. Vous n’avez pas la propriété. Vous avez une URL publique. Le service tente le crawl. Google tranche.

N’attendez pas non plus un classement. Indexer une page ne la place pas en tête. Une URL stockée peut rester introuvable sur la requête vendue au client. Le paiement au résultat paie le stockage confirmé, pas la position, pas le trafic, pas l’autorité transmise. Si le lien est nofollow, ou si la page donneur pèse peu, l’indexation ne répare pas l’achat.

Affiliation : quinze pour cent sur les dépôts, à haut niveau

Le programme d’affiliation verse 15 % à vie sur les dépôts des comptes liés, pas sur les jetons que ces comptes dépensent. La personne reste attachée. Quand elle recharge, la commission suit. Quand elle consomme un solde déjà payé, rien de plus ne tombe.

Le retrait en espèces attend 20 $. PayPal et USDT figurent parmi les sorties. En dessous, vous n’êtes pas bloqué pour travailler : le solde d’affiliation peut payer des packs de jetons, sans virement externe. Le seuil de 20 $ décrit le payout, pas l’usage interne des jetons.

Ne vendez pas le lien d’affiliation avec une promesse d’indexation à 100 %. Le filleul paie des tentatives de crawl. Google reste juge. Si vous présentez le service, présentez le paiement au résultat, le jour 7, et la règle des URL inaccessibles. Un filleul qui découvre un 404 non remboursé après avoir lu « 100 % de tout lien » vous en voudra, à vous et à la page d’accueil.

La partnerie n’ouvre pas un indexeur Bing. Elle n’active pas le pay-per-submit. Elle n’ajoute pas de jetons magiques. Elle recopie une part des recharges. Traitez-la comme une commission de dépôt, pas comme un revenu lié au taux d’indexation du filleul.

Scénario illustratif — pas un client réel : 420 articles invités pour un cabinet à Lyon

Un consultant imagine une agence lyonnaise qui livre 420 guest posts sur le trimestre. Le tableur mélange des 200 propres, des URL déjà dans Google, des pages retirées par l’éditeur, deux noindex oubliés. S’il colle les 420 en Standard le lundi, il envoie aussi les cadavres. Les cadavres ne reviendront pas en jetons. Les déjà indexées lui coûteront un recrawl inutile si Google les confirme encore.

Le bon ordre tient en cinq gestes. Il passe d’abord le vérificateur d’index Google. Il sort 90 lignes déjà présentes. Il teste 30 URL au hasard : trois 404, un robots, un noindex. Il allume le précontrôle. Il crée une tâche Google en paiement au résultat, Drip-Feed 14 jours, parce que 330 restantes sur deux semaines restent raisonnables. Il note : dernier lot + 7 jours = date du rapport. Il ne promet rien au client avant cette date. Il n’ouvre pas Bing comme indexeur. Il n’ajoute pas Yandex « au cas où ».

Au jour du rapport, une partie des URL accessibles reste hors index. Les jetons de ces lignes reviennent. Google a visité et refusé. Le consultant relit le contenu, le canonical, le maillage interne du donneur. Il ne rouvre pas un ticket « le service a échoué ». Il a payé le stockage, pas le miracle.

Scénario illustratif — pas un client réel : un catalogue nantais et un contrôle Bing

Une responsable e-commerce imagine 1 200 fiches saisonnières. Elle veut Google. Elle a aussi l’habitude de regarder Bing. Elle lance d’abord le vérificateur Bing, voit beaucoup de « oui », et en conclut que Google suivra. Elle se trompe de moteur. Bing ne prouve pas Google. SpeedyIndex ne lui offrira pas de file Bing.

Elle revient à l’accueil, extrait les URL utiles, passe le vérificateur Google, écarte les déjà indexées et les 404 de variantes de couleur. Elle choisit Standard : liste déjà propre, domaine établi, volume tenu. Elle sait que le pay-per-submit est fermé. Elle paie au résultat. Au jour 7, les fiches accessibles hors index lui rendent les jetons. Les variantes en 404, si elle les a laissées passer, ne lui rendent rien. Elle écrit à son prestataire thème, pas au support indexeur.

Ce scénario n’existe que pour montrer la bascule. Le vérificateur Bing sert de colonne. La tâche Google sert de tentative. Le remboursement suit l’éligibilité, pas l’émotion du tableur.

Vous repartez avec trois phrases. SpeedyIndex tente le crawl, Google et Yandex stockent. Le paiement au résultat rembourse les misses accessibles, pas les URL mortes. Drip-Feed change le calendrier, pas la promesse. Ouvrez l’accueil, nettoyez la liste, puis créez la tâche.

The previous note in this series covers the step before this one: How to convert SpeedyIndex affiliate balance into tokens instead of waiting for a 20 dollar payout. Read that first if you landed here on a related long tail.

À propos

SpeedyIndex vend des demandes de crawl en paiement au résultat. Une URL indexée coûte 100 jetons.

Google revérifie au jour 7. Yandex revérifie au jour 15. Si l’URL n’est pas indexée à la revérification, les jetons reviennent sauf si l’URL était inaccessible.

Deux campagnes : Standard et Drip-Feed. Le Drip-Feed concerne Google en paiement au résultat. Le précontrôle optionnel peut retirer les 404, 410, 451, les blocages robots ou noindex, les médias et les URL déjà indexées. Côté API : drip_feed et drip_feed_days (2–30). Le nombre d’URL doit être au moins égal au nombre de jours.

Le crawler s’identifie comme Googlebot Smartphone. Aucune vérification Search Console n’est exigée. Les URL de tiers sont acceptées. Bing existe uniquement en vérificateur. Il n’y a pas d’indexeur Bing. L’indexation Google à la soumission est temporairement indisponible.

Un compte neuf reçoit 200 jetons d’essai. L’affiliation verse 15 % à vie sur les dépôts des comptes liés, avec un payout à partir de 20 $ (PayPal / USDT), ou le paiement de packs de jetons depuis le solde de parrainage. L’indexation reste la décision du moteur. Une demande payante est une tentative de crawl, pas une promesse de classement ni une garantie d’inclusion.