new-term-radar: Neue KI-Begriffe für SEO früh erkennen

Was ist new-term-radar?

Ein neues KI-Werkzeug kann in einer Entwicklercommunity bereits Aufmerksamkeit bekommen, während sein Name in deiner bisherigen Keyword-Liste fehlt. Genau hier setzt new-term-radar an: Es beobachtet wiederholt ausgewählte Quellen, vergleicht sie mit gespeicherten Zuständen und schreibt die gefundenen Kandidaten in einen Bericht.

Technisch ist es eine Kommandozeilenanwendung, kein SEO-Dashboard. Lokale Snapshots halten Vergleichsstände fest, eine SQLite-Datenbank speichert Hinweise. Der Tageslauf kann Markdown und JSON ausgeben. Die CLI-Implementierung und der Datenspeicher bilden diesen Ablauf ab.

Kerndatum	Einordnung und Beleg
Lizenz	MIT, ohne Lizenzgebühr für den Code
Laufzeit	Python 3.10 oder neuer; Grundlauf mit Standardbibliothek laut README
Besprochener Quellstand	Commit fe442a24afe57e209abd39d602f44218ef0d73a8 vom 13. Oktober 2026
Release-Version	Beim Abruf keine veröffentlichten GitHub-Releases

Die folgende Einordnung beruht auf Dokumentation und statischer Quellcodeprüfung. Eine eigene Installation, ein Radar-Lauf oder ein Test mit bezahlten Providerantworten wurde nicht durchgeführt.

Welche Signale sammelt der Radar?

Die Quellen beantworten unterschiedliche Fragen. Du solltest sie nicht als austauschbare Bestätigungen desselben Trends lesen.

Quelle	Was auffällt	Was daraus nicht folgt
X	Ein Name erscheint neu im eigenen beobachteten Wortschatz konfigurierter Accounts	Der Name wurde erstmals weltweit genannt
Hugging Face	Eine aktuelle Trending-ID fehlt im vorherigen Vergleichsstand	Das zugrunde liegende Modell wurde gerade veröffentlicht
GitHub	Ein junges Repository erreicht Aufmerksamkeitsschwellen	Es gibt entsprechende Google-Suchnachfrage
Sitemaps	Neue URLs tragen gemeinsame Begriffe	Die Seiten sind indexiert oder ranken
Search Console, optional	Neue erfasste Queries der eigenen Property	Der gesamte Markt sucht erstmals danach
Neue Domains, optional	Domains erfüllen die konfigurierten Datenfilter	Ihr geschätzter Traffic ist tatsächlich gemessen

Die Quellenlogik meldet bei Hugging Face aktuelle Top-50-IDs, die in den vorherigen Top 100 fehlten. X verwendet ein eigenes rollierendes Vokabular, keinen vollständigen historischen Archivscan. Bei GitHub ist die Geschwindigkeit entweder Stars geteilt durch Repository-Alter oder eine Differenz seit dem letzten Snapshot, keine zwingend gemessene Tagesrate.

Auch die Auswahl deiner Quellen bleibt entscheidend. Eine Marketingkampagne kann gleichzeitig Posts, Stars und Verzeichniseinträge erzeugen. Mehrere Signalarten bedeuten deshalb nicht automatisch mehrere unabhängige Nachfragebelege.

Wie startest du ohne bezahlte Datenpfade?

Für einen betreuten Einstieg reichen die freien Hugging-Face-, GitHub- und Sitemap-Module. Passe zuerst die Beispielkonfiguration an: eigene zulässige Quellen, passende Themen und bereits abgedeckte Namen. Prüfe bei fremden Sitemaps Abrufbedingungen und Pausen selbst; eine automatische robots.txt-Prüfung ist im Sitemap-Modul nicht implementiert.

Der dokumentierte Einstieg für den besprochenen Commit:

git clone https://github.com/zhuyansen/new-term-radar
cd new-term-radar
git checkout fe442a24afe57e209abd39d602f44218ef0d73a8
cp config.example.json config.json

Passe jetzt config.json auf eigene zulässige Quellen und Known Terms an, bevor du den folgenden Befehl ausführst.

python -m radar daily --skip x,newsites,review,judge,usecases --out report.md

Die CLI unterstützt diese Ausschlüsse. Sie deaktivieren X, neue Domains, spätere Reviews, den Namensjudge und die Keyword-Tabelle. Der Lauf schreibt report.md sowie report.json. Eigene GSC-Abfragen bleiben möglich, falls du sie separat eingerichtet hast.

Wichtig: Kostenfreie Quellmodule sind kein Offline-Modus. Die Befehle lösen Netzwerkabfragen aus und wurden für diesen Artikel nicht praktisch ausgeführt.

Hugging Face und Sitemaps benötigen zunächst Vergleichsstände; auch X braucht bei späterer Aktivierung eine Baseline. GitHub kann bereits beim Erstlauf Kandidaten liefern, konfigurierte GSC ebenfalls. Bewahre den Zustand auf: Ein verlorener state-Ordner setzt Vergleichsmöglichkeiten zurück. known_terms hilft beim Markieren vorhandener Themen, verwendet aber Teilstringvergleiche, keine semantische Dublettenprüfung.

Wie wird aus einem neuen Namen eine Keyword-Idee?

Die optionale bezahlte Analyse trennt zunächst Eigennamen von gewöhnlichen Wörtern. Ein LLM-Judge bewertet, ob ein Kandidat nach einem konkreten Produkt, Modell oder Projekt aussieht. Sein Score ist keine kalibrierte Wahrscheinlichkeit für SEO-Erfolg.

Danach liest die Keyword-Pipeline Posts und gegebenenfalls README-Auszüge. Ein Modell schlägt Aufgabenbegriffe vor, ein weiterer Modellaufruf prüft die Relevanz. Ergänzend können über GoAnyAPI verwandte Queries hinzukommen. Modellvorschläge und beobachtete Related Queries haben unterschiedliche Herkunft und gehören redaktionell getrennt bewertet.

Ein illustrativer Redaktionsauftrag: Du beobachtest neue KI-Werkzeuge für lokale Dokumentenverarbeitung. Ein Kandidat beschreibt laut Originalquelle eine konkrete PDF-Aufgabe. Daraus entstehen Recherchefragen, nicht schon Nachfragewerte:

Rechercheebene	Deine Prüfung
Produktname	Existieren Originalquelle, nutzbarer Zugang und klare Funktion?
Deutsche Aufgabe	Passt „PDF mit KI lokal auswerten“ zum tatsächlichen Einsatzfall?
Englischer Fachbegriff	Beschreibt „local document analysis“ denselben Intent?
Content-Entscheidung	Braucht es einen neuen Guide, ein Update oder nur einen Beobachtungseintrag?

Das Beispiel ist kein Radar-Ergebnis. Es zeigt den sinnvollen Übergang vom Namen zur Leserfrage. Ein Produkt kann eine bestehende Aufgabe besser lösen, ohne deren Suchvolumen zu erhöhen. Umgekehrt kann ein Name stark diskutiert werden, obwohl noch kein belastbarer praktischer Nutzen erkennbar ist.

Für datenbasierte Anschlussrecherche gibt es getrennte Werkzeuge. Der Guide zur DataForSEO-MCP-Anbindung behandelt den Datenzugriff; der Radar setzt davor an, bei der Entdeckung möglicher Themen.

Welche Nachfragewerte zeigt der Report wirklich?

Hier liegt die wichtigste Interpretationsgrenze. Die Keyword-Tabelle kombiniert verschiedene Datenarten, die weder dieselbe Grundgesamtheit noch dieselbe Messmethode haben.

Anzeige oder Datenquelle	Belastbare Bedeutung
Plattformsignale	Aufmerksamkeit oder Veröffentlichung in beobachteten Quellen
Google-Ads-Volumen	Historische Größenordnung einschließlich naher Varianten
Trends-Kurve	Relative Entwicklung im jeweiligen Daten- und Abfragekontext
GSC-Queries	Erfasste Suchsichtbarkeit der eigenen Website
Est. searches/day	Zusammengesetzte Hochrechnung des Radars

Der Standardindex ist nicht eindeutig als Google Trends belegt

Der Code verwendet post_dataforseo_keywords_trends_explore_live. Die offizielle AIsa-Referenz ordnet diesen Identifier dem Pfad /apis/v1/dataforseo/keywords_data/dataforseo_trends/explore/live zu, nennt in ihrer Kurzbeschreibung aber Google Trends.

DataForSEO beschreibt das zugeordnete Produkt ausdrücklich als eigenen Popularitätsindex auf Basis eigener Daten und eines eigenen Algorithmus, nicht als Wiederverkauf von Google-Trends-Daten. Die Standardkurven kommen also über einen AIsa-Identifier, dessen dokumentierte Zuordnung auf DataForSEO Trends verweist. Ob AIsa intern anders routet, wurde ohne bezahlten Live-Aufruf nicht geprüft.

Der optionale GoAnyAPI-Pfad ist als Google Trends dokumentiert. Seine Beschaffungs- und Lizenzkette wurde nicht unabhängig auditiert. Beide Wege pauschal als Bestätigung durch echte Google-Suchnachfrage zu bezeichnen, wäre zu weitgehend.

Index, Monatsvolumen und Tageshochrechnung sind verschiedene Größen

Auch originäres Google Trends ist eine normalisierte Stichprobe: Der Index reicht von 0 bis 100 und bezieht sich auf Zeitraum und Ort. Ein Wert von 100 bedeutet nicht 100 Suchen. Geringe Mengen können Nullwerte oder statistisches Rauschen erzeugen.

Google Ads liefert historische, gerundete Volumina einschließlich naher Varianten. Die Search-Console-API zeigt dagegen Daten deiner Property und garantiert keine vollständige Ausgabe aller Query-Zeilen.

Est. searches/day rechnet laut Implementierung Ads-Monatsvolumen mit fixer 30-Tage-Normierung und Indexverhältnissen auf eine Tagesgröße um. Für Namen ohne eigenen Volumenanker wird der Benchmark gpts kalibriert. Das ist keine direkt gezählte Tagesnachfrage; die Kombination mit dem dokumentierten DataForSEO-Index benötigt zusätzlich eine belastbare Kalibrierung.

Für Deutschland sind die Defaults ungeeignet als Nachfragebeleg: US-Markt und englische Phrasen sind voreingestellt; die Volumenabfrage setzt Englisch. Eine lokale Kurve ändert nicht automatisch alle Zahlengrundlagen. Der Report unterstützt laut README Englisch und Chinesisch, nicht Deutsch.

Was kostet der Betrieb?

MIT macht den Code frei nutzbar, nicht Daten und Modelle kostenlos. AIsa bündelt kostenpflichtige Datenabfragen und Modellzugriffe; GoAnyAPI ist optional. Google-OAuth für GSC bleibt ein separater Zugang.

Die README nennt rund 15 US-Dollar monatlich für ihr Beispiel mit 35 X-Accounts, drei Durchläufen täglich und einer Keyword-Tabelle für fünf Namen. Das ist eine Autorenschätzung, keine unabhängig bestätigte Rechnung oder Kostengarantie. Laufhäufigkeit, Modelltoken, zusätzliche Module und Hosting verändern die Gesamtkosten.

Laut AIsa-Preisseite ist Pay-as-you-go ohne Monatsabo möglich; Daten- und Modellabrechnung folgen unterschiedlichen Regeln. Prüfe vor Aktivierung die konkreten Endpunkte und deinen Tarif. Die Report-Kostensumme enthält im geprüften Pfad nicht sämtliche Chatkosten. Außerdem begrenzt per_day die Bearbeitung je Lauf, nicht dein tägliches Dollarbudget.

Welche Einschränkungen bleiben?

Keine belegte Prognosegüte

Das Review startet standardmäßig frühestens nach 14 Tagen und prüft eine Index-Schwellenregel. Es misst weder Rankings noch Klicks oder Conversions. Die README räumt fehlende allgemeine Trefferquoten selbst ein; selektive Judge-Vergleiche und einzelne Autorenbeispiele ersetzen keine unabhängige Prognosemessung.

Fehlende Daten sind kein ruhiger Markt

Providerfehler können Berichte ausdünnen. Die CLI fängt Quellenfehler ab und kann trotzdem erfolgreich enden. Teile des Keyword-Screenings lassen bei Fehlern unbewertete Vorschläge stehen. Prüfe deshalb Quellenstatus und Belege, nicht nur den Prozessstatus oder das Label prioritize.

Eigene Suchdaten brauchen Zugriffskontrollen

Das GSC-OAuth-Skript speichert Token als lokale JSON-Datei; Read-only bedeutet nicht verschlüsselt. Optional gelangen Token als Secret auf einen GitHub-Runner. Berichte, Artefakte und Mail können eigene Suchdaten weitergeben, wie der Workflow zeigt.

GSC-Queries werden im geprüften Tagespfad nicht automatisch dem Namensjudge übergeben. Externe Posts und README-Auszüge gehen dagegen in Modellprompts und können Bewertungen verzerren. Vertrauliche Inhalte gehören nicht ungeprüft in diesen Ablauf.

Wie schneidet der Radar gegenüber Alternativen ab?

Dieser Vergleich beschreibt Einsatzgebiete, keine eigenen Produkttests oder gemessenen Zeitgewinne.

Vorgehen	Sinnvoll für	Zentrale Grenze
Kuratierte RSS- und Releasefeeds	Originalankündigungen ausgewählter Projekte	Keine Nachfragewerte
Manuelle Google-Trends- und SERP-Prüfung	Wenige Kandidaten, Mehrdeutigkeit und lokale Einordnung	Wiederholungsaufwand und schwache Daten bei kleinen Namen
Search Console	Anschlüsse an die eigene Suchsichtbarkeit	Keine Marktgesamtansicht
Keyword Planner oder SEO-Datenbank	Historische Größenordnung und Varianten	Neue Namen und Datenalter separat prüfen
new-term-radar	Wiederholte, gebündelte Entdeckung über mehrere Quellen	Zustandsverwaltung, Providerkosten und unbewiesene Prognosegüte

Beginne mit einem begrenzten Pilot statt mit automatischer Artikelproduktion. Protokolliere Originalbeleg, erstes eigenes Auftauchen, Aufgabenbegriffe, Markt, Datenmonat und Quellenfehler. Vergleiche anschließend relevante Entdeckungen, Falschalarme und redaktionellen Aufwand mit deiner bisherigen Feed-Recherche. „Keine Daten“ muss getrennt von „kein Anstieg“ bleiben.

Wer eine breitere Arbeitsoberfläche sucht, findet im OpenSEO-Vergleich eine andere Werkzeugklasse. Der Radar ergänzt solche Arbeitsbereiche um Themenkandidaten, ersetzt sie aber nicht.

FAQ: Häufig gestellte Fragen zu new-term-radar

Erkennt new-term-radar neue Keywords vor klassischen SEO-Tools?

Das ist das Projektziel, kein allgemein nachgewiesener Vorsprung. Der Radar beobachtet Quellen, in denen Namen früh auftauchen können; ob das deinen Workflow verbessert, musst du vergleichend prüfen.

Kann ich den Radar kostenlos nutzen?

Der MIT-lizenzierte Code und freie Quellmodule benötigen keine Lizenzgebühr beziehungsweise keinen AIsa-Key. X, KI-Bewertungen, Keyword-Tabelle und Reviews verursachen dagegen Provider- oder Modellkosten.

Sind die geschätzten Suchen pro Tag echte Google-Messwerte?

Nein. Sie sind eine zusammengesetzte Hochrechnung aus historischen Volumenankern und Indexverhältnissen, keine direkt gezählte tägliche Suchanzahl.

Ist new-term-radar für deutsche Inhalte geeignet?

Als Entdeckungshilfe ja, als fertiger deutscher Nachfragebeleg im Standardsetup nein. Prüfe deutsche Aufgabenbegriffe und passende Marktparameter getrennt; eine Übersetzung englischer Vorschläge reicht nicht.

Sollte ich jeden priorisierten Namen sofort als Artikel veröffentlichen?

Nein. Prüfe Originalquelle, tatsächlichen Nutzen, Suchintention und vorhandene eigene Inhalte. Eine automatisierte Priorisierung ersetzt keine redaktionelle Themenentscheidung.

Fazit

new-term-radar ist einen begrenzten Pilot wert, wenn du viele KI-Quellen regelmäßig beobachtest und neue Namen systematisch dokumentieren willst. Nutze es als Kandidatenradar, nicht als Nachfrage-Orakel: Erst Originalbeleg und Einsatzfall prüfen, dann Markt- und Suchdaten separat einordnen. Für die Anschlussarbeit helfen der DataForSEO-MCP-Guide und der OpenSEO-Vergleich, nicht das blinde Übernehmen einer Tageshochrechnung.

Quellen

Projekt und Implementierung

• new-term-radar: README zum besprochenen Commit: Funktionsbeschreibung, Kostenbeispiel und Autorenmessungen.
• MIT-Lizenz, Commitnachweis und Releases-API: Quellstand und Reifeeinordnung.
• CLI, Defaults und Quellenlogik: Einstieg und Baselines.
• Keyword-Pipeline und Review: Hochrechnung und spätere Indexprüfung.
• GSC-OAuth und Actions-Workflow: Token und Berichtswege.

Datenanbieter und Messmethoden

• AIsa: Endpoint-Referenz und DataForSEO Trends: dokumentierter Provenienzkonflikt.
• Google Trends: Daten-FAQ: Normalisierung, Stichprobe und Rauschen.
• Google Ads: historische Metriken und Search Analytics API: Volumeninterpretation und Property-Grenzen.
• AIsa: Preise und Abrechnungsregeln; GoAnyAPI: Trends-Dokumentation: externe Dienste, keine unabhängig bestätigten Betriebsrechnungen.

Unabhängige Messungen

Eine unabhängig validierte allgemeine Prognosegüte oder ein eigener End-to-End-Lauf mit bezahlten Providerdaten liegt dieser Einordnung nicht zugrunde. Die README-Auswertungen bleiben Autorenangaben.

Quellenstand: 13. Oktober 2026; technische Aussagen beziehen sich auf den verlinkten Commit, nicht auf spätere Änderungen.