SpeedyIndex: Google- und Yandex-Indexierung mit Zahlung pro Ergebnis

SpeedyIndex rechnet die Indexierung bei Google und Yandex nach dem Prinzip Zahlung pro Ergebnis ab: Token werden für eine URL fällig, die der Index tatsächlich aufnimmt, nicht für jeden Versandversuch. Eine eigene deutsche Locale-Site liegt im aktuellen Sprachumschalter nicht, deshalb verweisen die Produktlinks in diesem Überblick auf die englische SpeedyIndex-Site gemäß deren Sitemap. Den laufenden Dienst öffnen Sie auf der englischen Startseite; Pay-per-Result ist aktiv, Pay-per-Submit vorübergehend nicht verfügbar. Bing gehört hier nur in die Prüfung, nicht in eine Indexierungsaufgabe.

Was die Rechnung wirklich zählt

Ein indexierter URL kostet 100 Token. Die Suchmaschine entscheidet, ob sie das Dokument speichert. SpeedyIndex stellt die Adresse zu, prüft später nach und belastet die Zeile, die im Index steht. Bleibt eine berechtigte URL draußen, kommen die Token zurück. Eine 404, eine 403, eine robots-Sperre, ein noindex oder eine Redirect-Schleife gelten nicht als berechtigter Fehlschlag: Die Seite war für den Crawl nicht speicherbar. Das ist kein Versprechen, jede Adresse ins Ergebnis zu heben. Google und Yandex behalten die Speicherentscheidung.

Pay-per-Submit, also die Abrechnung pro Abgabe unabhängig vom Indexstatus, steht derzeit nicht zur Wahl. Wer den Dienst neu plant, plant mit Pay-per-Result. Der Crawler tritt als Googlebot Smartphone auf. Eine Verifizierung in der Search Console oder in Yandex Webmaster ist nicht nötig. Auch URLs auf fremden Domains — Gastbeiträge, Kommentare, Crowd-Links — dürfen in die Aufgabe. Das ersetzt weder die Search Console noch den Webmaster. Es füllt die Lücke, dass Sie auf einem Verlag, den Sie nicht bestätigt haben, keine Indexierung anfordern können.

200 Token stehen als Testguthaben bereit. Umrechnungskurse von Token in Euro nennt dieser Text nicht; die Abrechnungseinheit im Produkt ist der Token, nicht ein frei erfundener Dollarbetrag pro URL. Wer intern kalkuliert, rechnet in Token und hält die Kundin von Sätzen wie „jede Platzierung landet garantiert in Google“ fern.

Die Rechnung trennt drei Zustände, die in Agentur-Slack oft in einem Wort zusammenfallen. Indexiert heißt: 100 Token weg, die Suchmaschine hat gespeichert. Nicht indexiert und berechtigt heißt: Token zurück, der Prozess lief, die Speicherung blieb aus. Nicht indexiert und unerreichbar heißt: keine automatische Erstattung, der Publisher oder die Technik schuldet eine lebendige Seite. Wer diese drei Zeilen nicht auseinanderhalten kann, führt das falsche Streitgespräch.

Crawl ist nicht Speicherung

Googles eigene Übersicht zu Crawling und Indexierung trennt drei Schritte: finden, crawlen, speichern. Eine Sitemap, ein interner Link oder ein Hinweis von außen kann eine URL auffindbar machen. Der Crawl holt das Dokument. Die Speicherung entscheidet, ob es im Index bleibt. SpeedyIndex sitzt vor allem im mittleren Stück: Es reicht die URL nach und prüft später, ob die Speicherung stattfand. Es kann Google nicht zwingen, eine dünne, gespiegelte oder kanonisch woanders verortete Seite zu behalten.

Darum gibt es keine Garantie auf 100 Prozent Index. Wer das auf einer Agenturrechnung schreibt, verspricht etwas, das weder das Tool noch die Dokumentation der Suchmaschine hergibt. Was sich versprechen lässt: ein nachvollziehbarer Prozess, eine datierte Nachprüfung und eine Token-Rückgabe für berechtigte Fehlschläge. Was sich nicht versprechen lässt: dass eine Filter-URL mit drei Wörtern Text denselben Speicherwert hat wie ein redaktioneller Beitrag.

Yandex folgt einem eigenen Kalender. Die Nachprüfung dort liegt am 15. Tag, nicht am siebten. Eine Google-Aufgabe und eine Yandex-Aufgabe sind zwei Vorgänge. Wer beide Suchmaschinen braucht, plant zwei Uhren, nicht eine gemittelte Woche. Ein „noch nicht in Yandex“ am Tag 8 einer Google-Aufgabe ist kein Bug. Es ist die andere Uhr.

Viele Teams verwechseln außerdem Auffindbarkeit mit Mitgliedschaft im Index. Eine URL, die irgendwo verlinkt ist, ist auffindbar. Eine URL, die Google speichert, ist indexiert. Dazwischen liegen robots, Canonical, Soft-404, Duplicate und schlicht Desinteresse der Suchmaschine. Zahlung pro Ergebnis kauft den Anstoß und die Prüfung. Sie kauft nicht das Urteil.

Standard und Drip-Feed

Zwei Modi teilen die Last. Standard passt auf eine kurze Liste: Sie geben die URLs ab, der Prozess läuft in einem Stück, die Google-Nachprüfung zählt sieben Tage ab diesem Durchlauf. Drip-Feed ist der Google-Modus für Pay-per-Result, wenn die Liste nicht an einem Vormittag über die Crawler-Schwelle der Zieldomain soll. Über die API heißen die Schalter drip_feed und drip_feed_days; die Spanne liegt bei 2 bis 30 Tagen, und die Zahl der URLs muss mindestens so groß sein wie die Zahl der Tage. Die Seite zur Drip-Feed-Indexierung beschreibt genau diesen Kalender.

Der Sieben-Tage-Zähler für Google startet nach der letzten Tagesportion, nicht nach dem Anlegen der Aufgabe. Wer am Montag eine 14-Tage-Drip anlegt und am folgenden Montag schon den Rückerstattungsbericht erwartet, hat die Uhr falsch gesetzt. Die Portionsarbeit läuft noch. Der konsolidierte Google-Bericht beginnt erst, wenn die letzte Charge draußen ist. Schreiben Sie das Datum „letzte Portion plus sieben“ ins Blatt, bevor jemand im Chat „wo bleibt die Erstattung?“ tippt.

Standard auf mehrere zehntausend Kommentar-URLs ist kein Kalender, sondern ein Stoß. Drip-Feed auf acht Gastbeiträge ist unnötige Warterei. Die Wahl hängt von der Listenlänge und vom Crawl-Budget der Zieldomain ab, nicht von einem Versprechen, dass Tröpfeln die Positionen hebt. Drip-Feed verteilt die Abgabe. Rankings bleiben Sache der Suchmaschine. Wer Drip-Feed als Ranking-Hebel verkauft, verkauft eine andere Leistung als die, die das Produkt erbringt.

Yandex-Aufgaben leben neben diesem Google-Kalender. Drip-Feed in den Produktfakten ist der Google-Pay-per-Result-Weg. Mischen Sie die Yandex-Nachprüfung am Tag 15 nicht in eine Google-Drip-Debatte. Zwei Engines, zwei Berichte, zwei Erstattungsfenster.

Erst prüfen, dann senden

Bevor Token in eine Aufgabe wandern, gehört der Ist-Stand ins Blatt. Der Google-Index-Checker markiert pro URL, ob Google die Adresse bereits hält. Der Yandex-Index-Checker macht dasselbe für Yandex. Bereits indexierte Zeilen müssen nicht durch Pay-per-Result, wenn Sie keinen erneuten Anstoß wollen. Tote Zeilen gehören zum Verlag, nicht in die Indexaufgabe. Eine Prüfung kostet weniger Streit als eine Rechnung über URLs, die schon lagen oder nie erreichbar waren.

Bing bleibt ein Prüfkanal. Der Bing-Index-Checker sagt ja oder nein. Einen Bing-Indexierer bietet SpeedyIndex nicht; auf der englischen Startseite steht die Bing-Indexierung als vorübergehend nicht verfügbar. Ein „ja“ in Bing ist kein „ja“ in Google. Wer eine Lücke in Bing mit einer Google-Drip schließt, schließt die falsche Lücke. Drei Spalten im Blatt — Google, Yandex, Bing — verhindern den Mittelwert „zu 70 Prozent indexiert“, der keine der drei Suchmaschinen beschreibt.

Die Checker brauchen keine Property in den Webmaster-Tools. Das ist der Grund, warum sie auf Gastbeiträge und Wettbewerber-URLs passen. Sie ersetzen keinen URL-Inspektionsbericht auf einer Domain, die Sie besitzen. Sie ersetzen die Frage „liegt diese genaue Zeichenkette schon im Index?“, bevor Sie 100 Token pro Treffer riskieren. Schema, Host, Pfad und Slash müssen mit der späteren Aufgabe identisch sein. Eine UTM-Zwillingsschwester ist eine andere URL.

Prüfen und senden sind zwei Tätigkeiten. Wer eine gesperrte URL sendet, macht aus der Erstattung einen Streit. Wer zuerst prüft, schickt nur Kandidaten, die eine Chance auf Speicherung haben. Die optionale Vorabprüfung im Produkt hilft dabei, ersetzt aber nicht die Disziplin, das Blatt vorher zu säubern.

Rückerstattung nur für berechtigte Fehlschläge

Die ehrliche Regel ist enger als mancher Werbesatz. Token kehren zurück, wenn eine URL verarbeitet wurde, crawlbar war und bei der Nachprüfung trotzdem nicht im Index steht. Unerreichbare URLs — 404, 403, robots, noindex, Redirect-Schleife — liegen außerhalb der automatischen Erstattung. Wer eine tote Platzierung als „Indexierungsfehler des Dienstes“ verbucht, diskutiert mit dem Anbieter statt mit dem Publisher.

Google prüft am Tag 7 nach. Yandex prüft am Tag 15 nach. Beim Drip-Feed gilt für Google: letzte Tagesportion plus sieben Tage. Ein unabhängiger Checker am Tag 6 ist ein datierter Hinweis, keine Rechnung. Persönliche site:-Treffer und der Aufgabenbericht können einen Tag auseinanderliegen; maßgeblich für Token ist der Bericht.

Lesen Sie die Berichtsspalten, bevor Sie ein Ticket öffnen. Indexiert: 100 Token belastet. Nicht indexiert und berechtigt: 100 Token zurück. Nicht indexiert, weil die Live-URL unerreichbar war: keine Erstattung. Dann prüfen Sie eine Stichprobe mit demselben Checker wie vor der Aufgabe, am selben Kalendertag wie der Bericht. Zwei Daten, eine Diskussion.

„Wir erstatten Token für Google-URLs am siebten Tag, wenn die Adresse für den Crawl geeignet war und trotzdem nicht im Index steht. 404, 403, robots, noindex oder eine Redirect-Schleife erstatten wir nicht. Beim Drip-Feed folgt das Sieben-Tage-Fenster der letzten Portion. Ein unabhängiger Checker ist eine zweite datierte Zeile, keine zweite Rechnung. Hundert Prozent Aufnahme verkaufen wir nicht.“

— das SpeedyIndex-Team

Diese Trennung schützt beide Seiten. Der Dienst verkauft keinen magischen Index. Die Kundin kauft keinen Blankoscheck gegen tote Seiten. Die Token-Rückgabe ist die Audit-Zeile für den Fall „Prozess gelaufen, Speicherung ausgeblieben“, nicht die Versicherung gegen 404.

Vorabprüfung, standardmäßig aus

Optional filtert eine Vorabprüfung 404, 410, 451, robots/noindex, Medien und bereits indexierte URLs. Sie ist standardmäßig aus. Wer sie einschaltet, verkürzt die Liste, bevor Token und Rückerstattungsgespräch überhaupt entstehen. Wer sie auslässt und eine 404 mitschickt, darf später keine Erstattung erwarten: Die Seite war nicht speicherbar.

Die Vorabprüfung ersetzt nicht Ihren eigenen Status-Log. Ein Abruf mit Weiterverfolgung auf einer Stichprobe zeigt Status, Location und oft schon x-robots-tag. Ein Canonical, der auf ein Tag-Archiv zeigt, kann eine 200 liefern und trotzdem nie als eigenes Dokument im Index landen. Das ist dann ein Qualitäts- oder Kanonik-Ticket, kein Billing-Fehler. Medien-URLs, die die Vorabprüfung aussondern würde, gehören selten in eine Text-Indexaufgabe.

Schalten Sie die Filter ein, wenn die Liste aus vielen Händen kommt: Gastgeber, Excel-Export, altes Linkbuilding-Archiv. Lassen Sie sie aus, nur wenn Sie die Liste selbst Zeile für Zeile belegt haben — und selbst dann ist die Stichprobe Pflicht. Die Vorabprüfung ist ein Sieb, kein Freibrief, ungeprüfte Tabellen zu kippen.

Illustratives Szenario — kein realer Kunde

Eine Agentur in Köln hat 90 Gastbeiträge für einen Shop in der DACH-Region platziert. Die Publisher schreiben „online“. Drei URLs antworten mit 404, zwei tragen noindex im HTML, zwölf liegen bereits in Google. Die Agentur prüft zuerst mit dem Google-Checker, streicht die zwölf, schreibt die fünf toten Zeilen den Verlagen und legt die restlichen 73 als Standard-Aufgabe an — die Liste ist kurz genug für Standard. Am Tag 7 zeigt der Bericht: ein Teil indexiert zu 100 Token pro Zeile, ein Teil berechtigt unindexiert mit Token-Rückgabe, keine der 404er in der Aufgabe. Die Kundin erhält keine Zusage „alle 90 in Google“, sondern ein Blatt mit drei Spalten: schon drin, neu aufgenommen, crawlbar aber abgelehnt. Die abgelehnten Seiten mit Status 200 gehen in die Content-Nacharbeit, nicht in eine zweite identische Aufgabe am selben Tag.

Was hier nicht passiert: Niemand nennt den Dienst gescheitert, weil drei Publisher die Platzierung offline genommen haben. Niemand erwartet Token zurück für noindex. Niemand liest am Tag 6 eine leere site:-Suche als Rechnung. Die Uhr und die Erstattungsregel stehen vor der Aufgabe im Briefing, nicht danach im Streit.

Zweites illustratives Szenario — kein realer Kunde

Ein Marktplatz mit 2400 neuen Kategorie- und Filter-URLs will Google nicht an einem Nachmittag mit der ganzen Liste konfrontieren. Die Redaktion wählt Drip-Feed über 20 Tage, also mindestens 20 URLs, tatsächlich 2400, rund 120 pro Tag. Die Aufgabe ist eine Google-Pay-per-Result-Drip. Die Sieben-Tage-Uhr für den Bericht startet nach Tag 20, nicht nach dem Anlegen. Yandex läuft als zweite Aufgabe mit Nachprüfung am Tag 15, ohne die Drip-Erwartung aus dem Google-Kalender. Bing wird nur geprüft: welche Kategorien dort schon liegen, welche nicht. Es gibt keine Bing-Indexierungsaufgabe. Nach der letzten Google-Portion plus sieben Tagen liest das Team den Bericht und teilt Reste in unerreichbar — das geht an die Technik — und crawlbar-abgelehnt — das geht an die Kategorie-Texte. Niemand schreibt „100 Prozent indexiert bis Monatsende“ in den internen Chat.

Was hier nicht passiert: Niemand öffnet am achten Tag nach dem Anlegen ein Erstattungsticket. Niemand erklärt eine Bing-Lücke mit einer Google-Drip für geschlossen. Niemand behandelt Filter-URLs ohne eigenen Inhalt als versprochenen Indexgewinn. Die Drip verteilt den Anstoß. Die Speicherung bleibt Googles Entscheidung, Tag für Tag, URL für URL.

Partnerprogramm, ohne erfundene Schalter

Wer Kolleginnen und Kunden empfiehlt, erhält öffentlich 15 Prozent auf deren Einzahlungen, lebenslang; die Nutzerin bleibt dauerhaft verknüpft. Barauszahlung ab 20 US-Dollar per PayPal oder USDT, so die englische Partnerseite. Token-Pakete lassen sich aus dem Empfehlungsguthaben bezahlen, ohne den Umweg über eine externe Auszahlung. Die 20-Dollar-Schwelle ist die Schwelle für die Auszahlung, nicht ein frei erfundener Satz „Token tauschen ohne Minimum“. Öffentliche Seiten nennen keine Dashboard-Beschriftungen; dieser Überblick erfindet sie nicht.

Die 15 Prozent hängen an Einzahlungen, nicht am Token-Verbrauch der geworbenen Nutzerin. Wer das als „Anteil an fremden Indexzeilen“ erzählt, erzählt die Partnerseite falsch. Wer das Testguthaben von 200 Token mit dem Partnerguthaben vermischt, vermischt zwei Töpfe. Trial ist zum Ausprobieren der Pay-per-Result-Aufgabe da. Partnerguthaben ist die Folge einer Einzahlung, die jemand über den Empfehlungslink geleistet hat.

Ein Ablauf, der die Uhr ehrlich hält

Halten Sie die genaue URL fest: Schema, Host, Pfad, Slash. Aufgabe und Blatt tragen dieselbe Zeichenkette. Lesen Sie Status und Robots auf einer Stichprobe; Unerreichbares bleibt draußen. Prüfen Sie Google und, wenn die Kampagne es verlangt, Yandex und Bing. Schon indexierte und tote Zeilen verlassen die Queue. Wählen Sie Standard oder Drip-Feed nach Listenlänge. Notieren Sie das Berichtsdatum: bei Drip die letzte Portion plus sieben. Schalten Sie die Vorabprüfung ein, wenn 404, noindex und schon indexierte Zeilen nicht selbst ausgekehrt sind. Warten Sie das echte Datum ab. Lesen Sie den Bericht und eine Checker-Stichprobe am selben Tag. Teilen Sie Reste: Verlag oder Technik bei Unerreichbarkeit, Inhalt und Kanonik bei sauberer 200 ohne Speicherung. Dieselbe 404 erneut senden und eine zweite Erstattung erwarten ist kein Workflow, sondern eine Schleife.

Derselbe Ablauf gilt für fremde URLs. Sie müssen die Domain nicht verifizieren. Sie müssen die URL trotzdem lebendig antreffen. Zahlung pro Ergebnis hebt die Verifizierungsgrenze auf, nicht die Anforderung, dass ein Dokument existiert und crawlar sein darf.

Wann der Dienst passt — und wann nicht

SpeedyIndex passt, wenn Sie viele URLs haben, die Sie nicht in der Search Console verifizieren können, oder wenn Sie eigene Listen anstoßen und die Rechnung an den Index koppeln wollen statt an jeden Klick. Es passt nicht, wenn die Seiten 404 liefern, noindex tragen oder kanonisch woanders leben. Es ersetzt keine Inhaltsarbeit. Es indexiert Bing nicht. Es verspricht nicht, dass Google jede Kategorie speichert, nur weil Token fließen. Pay-per-Submit steht vorübergehend nicht bereit; wer heute startet, startet mit Pay-per-Result.

Wer eine einzelne URL auf der eigenen, verifizierten Domain hat, kommt oft mit der Search Console und Geduld weiter. Wer hunderte Gastbeiträge ohne Property hat, braucht einen Weg ohne Verlags-Konto, plus eine Prüfung vorher und eine ehrliche Erstattungsregel nachher. Genau dafür ist Zahlung pro Ergebnis gebaut: Prozess, Nachprüfung, Token nur für die gespeicherte Zeile, Rückgabe nur für den berechtigten Fehlschlag.

Nächster Schritt: Öffnen Sie die englische Startseite, prüfen Sie eine Stichprobe Ihrer Liste im Google-Checker und legen Sie erst dann eine Pay-per-Result-Aufgabe an — Standard bei kurzer Liste, Drip-Feed bei langer Liste, mit der Uhr ab der letzten Portion.

The previous note in this series covers the step before this one: SpeedyIndex: індексація Google і Яндекса з оплатою за результат. Read that first if you landed here on a related long tail.