SEO & GEO Analyzer — Tipps & Tricks

Kniffe für den SEO & GEO Analyzer: GEO-/KI-Optimierung, typische Stolperfallen, Score-Gewichtung und die Kombination mit anderen JPKCom-Tools.

Zurück zur Übersicht: SEO & GEO Analyzer · Tool live öffnen: www.jpkc.com/tools/seo/

Das Manual erklärt jede Prüfung, die Beispiele zeigen die Arbeitsabläufe. Hier geht es um das, was beides voraussetzt, aber selten dabeisteht: wo die Punkte wirklich liegen, wann eine Zahl lügt und welche blanke Anzeige du getrost ignorierst. Die Oberfläche ist auf Englisch — die echten Tab- und Button-Namen stehen deshalb im Original, bei Bedarf mit deutscher Erläuterung.

Den GEO-Score gezielt bewegen

Der GEO-Score wirkt anfangs zäh, weil das Maximum klein ist: 40 Punkte verteilt auf vier Kategorien — Structured Data 13, AI Discoverability 11, Content Structure 11, Machine Readability 5. Das ist die gute Nachricht: Bei so wenig Gesamtpunkten hebt jede einzelne Prüfung den Prozentwert spürbar. Du musst nur an den richtigen drei, vier Stellen anpacken.

  • Structured-Data ist der größte Block (13 Punkte). Eine Seite mit nur einem WebPage-Block lässt hier am meisten liegen. Schema Variety belohnt Vielfalt: ≥ 3 verschiedene @type geben volle 3 Punkte. Pack also bewusst mehrere Typen aufs Markup — typisch BreadcrumbList, Article/BlogPosting, Organization. Dazu zahlen FAQ Schema (ein FAQPage-Block, 3 Punkte) und Author / Organization Schema (3 Punkte) direkt ein — Letzteres ist dein E-E-A-T-Signal: Markierst du Person/Organization oder ein author-Feld, weiß die KI, wem sie eine Aussage zuschreiben kann. Allein hier liegen 13 Punkte, also rund ein Drittel des GEO-Maximums.
  • Die llms.txt bringt zwei Prüfungen auf einmal. llms.txt Present (3 Punkte) verlangt nur eine erreichbare, nicht-leere Datei; llms.txt Valid Structure (2 Punkte) gibt es voll nur bei 0 Fehlern und 0 Warnungen. Eine vorhandene, aber schludrige Datei holt also nur Teilpunkte — die Struktur zählt, nicht die bloße Existenz.
  • KI-Crawler nicht versehentlich aussperren. AI Crawlers Allowed (3 Punkte) prüft die robots.txt gegen neun namentliche Bots: GPTBot, ChatGPT-User, OAI-SearchBot, Google-Extended, Claude-Web, ClaudeBot, anthropic-ai, PerplexityBot und CCBot. 0 blockiert → 3 Punkte. Ein pauschales Disallow: / oder ein altes „böse Bots aussperren"-Snippet kostet hier sofort. Kurioses Detail: Gar keine robots.txt zählt als „alle erlaubt" — eine 404 ist hier punktetechnisch besser als eine zu restriktive Datei.
  • Markdown-Alternate ist ein billiger Punkt. Ein <link rel="alternate" type="text/markdown"> im <head> gibt 1 Punkt als KI-Extraktions-Hilfe. Klein, aber bei 40 Gesamtpunkten nicht nichts — und ohnehin eine gute Praxis für KI-freundliche Seiten.
  • Content-Signal ist nur ein Hinweis — aber ein nützlicher. Die Prüfung Content Signals Declared ist info und gibt 0 Punkte. Jag sie also nicht für den Score. Ihr Wert liegt woanders: Sie meldet einen Konflikt, wenn deine Content-Signal-Direktive KI willkommen heißt, die robots.txt die KI-Crawler aber gleichzeitig blockiert. Genau dieser Widerspruch ist ein häufiger, unsichtbarer Fehler — die Prüfung deckt ihn auf, ohne den Score zu verfälschen.
  • Die Markdown-Content-Negotiation siehst du nur im Expert Mode. Die Prüfung Markdown via Content Negotiation (ebenfalls info, 0 Punkte) erscheint nur, wenn die Probe mit Accept: text/markdown über den lokalen Expert-Mode-Proxy gelaufen ist — der serverseitige Standard-Proxy kann diesen Header nicht mitschicken. Fehlt die Zeile im normalen Lauf, ist das kein Mangel deiner Seite, sondern schlicht der Architektur geschuldet.

Merksatz: Hol dir zuerst die Structured-Data- und llms.txt-Punkte und sperr keine KI-Crawler aus — damit bewegst du den GEO-Score am schnellsten. Content-Tiefe und saubere Überschriften (Content Structure, 11 Punkte) holst du meist nebenbei mit, wenn die Seite ohnehin ordentlich geschrieben ist.

Die Scores klug lesen

  • Die beiden Scores sind unabhängig. SEO und GEO teilen sich keine Punkte. Eine technisch perfekte Seite kann GEO-schwach sein (keine llms.txt, dünnes Schema), und umgekehrt. Lies sie als zwei getrennte Blickrichtungen, nicht als eine Note mit zwei Nachkommastellen.
  • Jag keine literale 100 beim SEO-Score. Das SEO-Maximum ist dynamisch: Bedingte Prüfungen wie hreflang Valid, OG Completeness, Keyword Consistency und No Mixed Content kommen nur dann ins Maximum, wenn sie überhaupt anwendbar sind. Eine einsprachige Seite ohne hreflang kann gar keinen hreflang-Punkt „verlieren", weil die Prüfung gar nicht erst zählt. Deshalb wird immer ein Prozentwert ausgegeben — eine glatte 100 ist kein sinnvolles Ziel. Sinnvoll ist: die fail- und partial-Einträge im SEO Score-Tab nach Punkten sortiert abarbeiten.
  • Farbe und Note sind Orientierung, kein Urteil. Die Gauge ist ab 80 grün, ab 50 gelb, darunter rot; die Buchstabennote läuft ≥ 90 → A, ≥ 80 → B, ≥ 60 → C, ≥ 40 → D, sonst F. Das ist eine Ampel für den schnellen Eindruck — die eigentliche Arbeit steht in den Einzelprüfungen, nicht im Buchstaben. Ein „C" mit drei dicken, leicht behebbaren fails ist mehr wert als ein „B", bei dem nur noch Mikro-Punkte übrig sind.
  • Punkte schlagen Bauchgefühl bei der Priorisierung. Eine fehlende Meta Description (bis 8 Punkte) oder ein fehlender Title-Korridor (bis 8) wiegen schwerer als ein fehlendes og:image (3) oder ein Text/HTML-Ratio-Punkt (1). Die Sortierung nach points ist deine To-do-Reihenfolge.

Stolperfallen aus der Praxis

  • Das Tool sieht, was der JPKCom-Server sieht — nicht deinen Browser. Der Abruf läuft serverseitig per Proxy. Es gibt also keine eingeloggte, personalisierte oder JS-nachgeladene Sicht: Was hinter einem Login liegt oder erst clientseitig erscheint, ist für den Analyzer unsichtbar. Prüf öffentliche URLs im ausgelieferten Zustand.
  • Schwere Client-gerenderte SPAs werden unterschätzt. Geparst wird das abgerufene HTML, nicht ein im Browser fertig gerendertes DOM. Eine App, die Titel, Überschriften, Meta-Daten oder Inhalt erst per JavaScript einsetzt, liefert dem Analyzer ein nahezu leeres Grundgerüst — entsprechend fallen Content-, Heading- und Meta-Prüfungen aus. Das ist kein Bug, sondern derselbe Grund, aus dem auch viele Crawler solche Seiten schlecht erfassen. Server-seitiges Rendering (SSR/Prerendering) ist hier die eigentliche Lösung.
  • Riesige oder weiterleitungsreiche Seiten werden abgeschnitten. Es gilt ein Body-Cap von ~1 MB (größeres HTML wird gekürzt) sowie ~15 s Timeout und maximal 10 Redirect-Hops. Bei sehr großen Seiten oder langen Redirect-Ketten kann der Bericht unvollständig sein — nicht jeder fehlende Wert ist dann ein echtes Seiten-Problem.
  • Der URL-Status-Check ist rate-limitiert. Die separate „URL Status Check"-Funktion erlaubt nur ~1 Anfrage pro 2 Sekunden pro IP; hämmerst du sie, kommt ein HTTP 429 mit Wartezeit zurück. Einfach kurz warten statt nachfeuern.
  • localhost und Intranet gehen nicht. Aus SSRF-Schutz blockiert der Proxy private und interne IP-Adressen; nur öffentliche HTTP/HTTPS-Adressen sind erlaubt. Eine lokale Dev-Instanz oder Intranet-Seite kannst du damit nicht analysieren — entweder öffentlich (z. B. über eine Staging-Domain) bereitstellen oder den Expert Mode mit lokalem Proxy nutzen.
  • Eine leere TLS-Version ist meist kein Drama. Im SSL / Security-Tab kann das Feld zur TLS-Version bei manchen Live-Läufen leer bleiben (die Quelle liefert sie nicht immer zurück) — in den Demo-Daten ist sie gefüllt. Lies in ein blankes Feld dort also nicht zu viel hinein; entscheidend ist, ob das Zertifikat gültig ist und wie lange es noch läuft.

Workflow-Tipps

  • Snapshot per Export, dann vergleichen. Sichere vor einer Optimierungsrunde die Analyse im Export / Import-Tab als JSON. Nach den Fixes re-importierst du die alte Datei — weil nur Rohdaten und kein eingefrorener Score gespeichert werden, rechnet das Tool beim Import neu, exakt nach derselben Logik. So ist der Vorher-/Nachher-Vergleich fair und reproduzierbar (Details im Beispiel 6).
  • Mit den Demo-Modi eichen. Wer ein Gefühl für die Skala bekommen will, lädt im Export/Import-Tab erst Perfect, dann Broken und vergleicht dieselben Tabs Prüfung für Prüfung. Weil die Demos ebenfalls nur Rohdaten enthalten und client-seitig bewertet werden, siehst du echte Scoring-Logik an einem bekannten Datensatz — eine saubere Lern-Baseline ohne Live-Seite.
  • Source Code als Schiedsrichter. Wenn die Structured-Data-Erkennung mehrdeutig ist — ein erwarteter @type taucht nicht auf, obwohl du ihn eingebaut hast — schlag die Stelle im Source Code-Tab (roher HTML-Quelltext) nach. Meist liegt es an ungültigem JSON-LD, das im Markup steht, aber nicht parst.

Mit anderen JPKCom-Tools kombinieren

Der Analyzer findet Lücken, behebt sie aber nicht. Das Muster ist immer dasselbe: mit dem passenden Tool reparieren, dann erneut analysieren und den Sprung ablesen.

  • GEO-Score rot, weil llms.txt fehlt oder schludrig ist? Erzeug mit dem llms.txt-Generator eine strukturell gültige Datei — genau das, was die beiden llms.txt-Prüfungen (Present + Valid Structure) belohnen.
  • Meta, OG, Twitter oder JSON-LD unvollständig? Der Meta-Tags-Generator liefert saubere Titel, Descriptions, Open-Graph-/Twitter-Daten und JSON-LD, die sowohl im SEO- als auch im GEO-Score zählen.
  • KI-Crawler aus Versehen blockiert oder Sitemap fehlt? Mit robots.txt & Sitemap baust du die Crawler-Freigabe (die neun Bots) und die Sitemap:-Einträge, die AI Crawlers Allowed, Allowed by robots.txt und Sitemap in robots.txt grün machen.

Reihenfolge: reparieren → dieselbe URL erneut in den Analyzer → Score-Sprung ablesen. So wird aus der Mängelliste ein messbarer Fortschritt.


Noch mehr Kontext: die Übersicht zum großen Bild, das Manual für jede Score-Gewichtung und die Beispiele für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im Tool.