ONMA Ratgeber

Online SEO Tools: was ein Browser-Check prüfen kann und wo er endet

Meta Tags, H1, ALT und Core Web Vitals prüft ein Browser-Tool zuverlässig. Wo Crawl-Tiefe, Login-Bereiche und Backlinks die Grenze setzen, lesen Sie hier.

Frau vor einer Wand mit bunten Haftnotizen, davor sechs Personen mit Laptops an einem Besprechungstisch

Ein Online SEO Tool ist keine Software, die auf dem eigenen Rechner arbeitet. Es ist ein Formular. Sie geben eine URL ein, drücken auf Start und bekommen einen Bericht zurück. Genau diese Bauweise entscheidet darüber, welche Prüfungen möglich sind und welche nicht. Wer die Grenze kennt, spart sich den Streit über Ergebnisse, die ein Browser-Check gar nicht liefern kann.

Was “im Browser” technisch bedeutet

Der Browser rechnet in aller Regel nichts. Er transportiert nur zwei Dinge: die eingegebene URL hin, das fertige Ergebnis zurück. Dazwischen arbeitet der Server des Anbieters. Er ruft die Seite ab wie ein Besucher, liest den ausgelieferten HTML-Code, wertet ihn nach festen Regeln aus und schickt die Auswertung an Ihr Browserfenster.

Daraus folgt die zentrale Faustregel dieser Werkzeuggattung: Ein Online SEO Tool sieht genau so viel, wie ein fremder Server ohne Zugangsdaten von außen sehen darf. Alles, was Anmeldung, lokalen Netzwerkzugriff, lange Laufzeit oder einen eigenen Datenbestand voraussetzt, liegt außerhalb dieses Rahmens oder muss vom Anbieter zusätzlich aufgebaut werden.

Wie weit ein einzelner Dienst geht, unterscheidet sich. Manche laden nur das HTML-Dokument. Andere holen zusätzlich Bilder und Skripte, rendern die Seite in einem automatisierten Browser, fragen externe Messdaten ab oder folgen einigen internen Links. SEORCH etwa beschreibt seinen Check als Prüfung von Page Speed, Core Web Vitals, OnPage, OffPage und Mobile Friendly in einem Durchgang. Das ist die obere Kante dessen, was ohne Installation üblich ist.

Nebenbei zeigt schon die Nachfrage, wonach die Leute wirklich suchen: Für die Suchanfrage “online seo tools” meldet DataForSEO in Deutschland 170 Suchanfragen pro Monat bei einem CPC von 4,95 Euro und einer Keyword-Difficulty von 46. Der Name eines einzelnen Anbieters, “seobility”, kommt allein auf 6.600 Suchanfragen pro Monat. Die generische Frage ist also selten, die Frage nach einem konkreten Werkzeug häufig. Wer den generischen Begriff sucht, will meist nicht den Testsieger, sondern wissen, ob der schnelle Weg ohne Installation für seinen Fall überhaupt reicht.

Die Prüfungen, die im Browser zuverlässig funktionieren

Alles, was direkt im ausgelieferten Quelltext steht, ist für einen Server-seitigen Abruf trivial zu erfassen. Das ist mehr, als viele erwarten.

Meta Tags und Description. Title, Meta Description, Robots-Anweisungen und Canonical-Verweise stehen im Head des Dokuments. Ein Check erkennt zuverlässig, ob ein Title fehlt, wie lang Title und Description sind, ob ein Element mehrfach vorkommt, ob die Seite auf noindex steht, wohin das Canonical zeigt und ob sich Robots- und Canonical-Signal widersprechen. Was er nicht erkennt: ob die Description zur Suchintention passt. Zeichenzahl ist messbar, Klickmotivation nicht.

Überschriften. H1 bis H6 sind im HTML eindeutig ausgezeichnet. Fehlende H1, mehrfache H1, übersprungene Ebenen, Überschriften ohne Text: alles deterministisch prüfbar. Ob die H1 den Inhalt der Seite präzise benennt, bleibt eine redaktionelle Frage.

ALT-Attribute. Ein Tool sieht jedes img-Element im Quelltext, dazu Dateiname, Format, Abmessungen und oft die übertragene Dateigröße. Ein fehlendes ALT-Attribut ist ein harter Befund. Ein leeres ALT-Attribut dagegen ist bei rein dekorativen Bildern korrekt und gewollt, weshalb eine reine Zählung ohne Kontext irreführt.

Interne und externe Links. Aus den href-Attributen lassen sich Ziele extrahieren, in intern und extern trennen, mit einem Statuscode-Abruf prüfen und um Attribute wie nofollow, sponsored oder ugc ergänzen. Zwei Einschränkungen gehören dazu: Die Aussage gilt nur für die Links dieser einen URL, nicht für die Linkstruktur der Domain. Und ein einzelner Abruf ist eine Momentaufnahme. Bot-Abwehr, Rate Limits oder eine kurze Störung lassen ein funktionierendes Ziel als defekt erscheinen.

HTTP-Status und Weiterleitungen. Weil der Prüfserver die URL selbst anfordert, kann er die komplette Weiterleitungskette dokumentieren, Statuscodes ausweisen und relevante Header lesen. Daraus folgt, ob eine Seite abrufbar und technisch zur Indexierung freigegeben ist. Es folgt nicht daraus, ob sie im Google-Index steht. Diese Auskunft gibt nur die Google Search Console, und die ist zwar kostenlos, liefert aber erst nach der Verifizierung einer Property Daten. Sie prüft also ausschließlich eigene, nachgewiesene Domains, niemals eine beliebige fremde Website.

Core Web Vitals: zwei Datenarten, die oft verwechselt werden

Zu den Core Web Vitals zählen Largest Contentful Paint für die Ladeleistung, Cumulative Layout Shift für die visuelle Stabilität und Interaction to Next Paint für die Reaktionsfähigkeit. INP hat First Input Delay im März 2024 als offizielle Metrik abgelöst. Ältere Berichte, die noch FID ausweisen, messen also eine abgeschaffte Größe.

Entscheidend ist die Herkunft der Zahlen. Google PageSpeed Insights kombiniert Labordaten aus Lighthouse mit Felddaten aus dem Chrome UX Report. Labordaten entstehen in einer kontrollierten Testumgebung und eignen sich zur Ursachensuche: blockierende Skripte, zu große Bilder, lange Aufgaben im Hauptthread. Sie schwanken mit Teststandort, simulierter Verbindung und Serverauslastung. Felddaten stammen von echten Chrome-Nutzern über einen längeren Zeitraum und beschreiben die tatsächliche Erfahrung. Sie erscheinen aber nur, wenn für die URL oder die Domain genügend reale Nutzerdaten vorliegen.

Praktische Konsequenz: Für kleine oder neue Seiten zeigt ein Browser-Check häufig gar keine Felddaten, sondern nur ein Laborergebnis. Wer diesen Laborwert als “die” Performance der Seite behandelt, misst eine Testbedingung, keine Nutzerrealität.

Ausgehende Links stehen auf der geprüften Seite und sind deshalb vollständig auslesbar. Eingehende Links stehen dort nicht. Sie existieren auf fremden Domains, über das ganze Web verteilt. Um sie zu kennen, braucht ein Anbieter einen eigenen, laufend aktualisierten Link-Index oder eingekaufte Daten aus einer fremden Quelle.

Ein Werkzeug ohne solchen Index kann nur zeigen, was seine Datenquelle gerade hergibt. Deshalb melden verschiedene Dienste für dieselbe Domain unterschiedliche Backlinks: Sie crawlen zu verschiedenen Zeitpunkten und mit verschiedener Abdeckung. Aus einer Stichprobe von einigen Dutzend Verweisen lässt sich kein Urteil über ein Linkprofil ableiten, besonders nicht bei frischen Links, selten gecrawlten Quellen, inzwischen entfernten Verweisen und Links, die erst nach einer JavaScript-Interaktion im Dokument auftauchen.

Die harte Grenze

Vier Grenzen sind nicht eine Frage der Anbieterqualität, sondern der Bauweise.

Crawl-Tiefe. Ein Browser-Check läuft in einem Request-Fenster von Sekunden, nicht Stunden. Jeder Anbieter muss Laufzeit, Speicher und Serverlast begrenzen, weil er die Kosten für alle Nutzer trägt. Manche folgen einer festgelegten Zahl interner Links, doch domainweite Fragen bleiben offen: identische Titles über hunderte URLs, verwaiste Seiten, tiefe Klickpfade, Weiterleitungsketten, Parameter- und Filterduplikate. Dass das eine echte Nutzerfrage ist, zeigt sich daran, dass SEORCH auf derselben Seite ausdrücklich die Frage “Wie kann ich eine komplette Domain überprüfen?” beantwortet.

Geschützte Bereiche. Ist ein Verzeichnis über .htaccess, HTTP-Authentifizierung, ein Login-Formular, VPN oder eine IP-Freigabe geschützt, kommt ein fremder Server nicht hinein. Auch hierfür führt SEORCH einen eigenen Punkt “Seite mit .htaccess Login?”. Zugangsdaten in ein fremdes Online-Formular einzutragen, ist zudem eine Sicherheitsentscheidung, keine Bequemlichkeitsfrage. Bei Zwei-Faktor-Authentifizierung, kurzlebigen Tokens, Single Sign-on oder rollenabhängigen Sitzungen scheidet der Weg praktisch aus. Staging-Systeme, Intranets und lokale Entwicklungsumgebungen sind von außen ohnehin unerreichbar.

Framesets und eingebettete Inhalte. Ein Frameset oder Iframe bindet ein zweites Dokument ein, oft von einer anderen Domain. Der Prüfserver sieht die Einbindung, aber der Inhalt gehört technisch nicht zu der Seite, deren URL Sie eingegeben haben. Nicht jeder Dienst folgt diesen Quellen, und wenn er es tut, ordnet er sie selten korrekt zu. Das Ergebnis beschreibt dann den gelieferten Rahmen, nicht das, was ein Besucher sieht. Dasselbe gilt für Widgets, Karten, Videoeinbettungen und Drittanbieter-Anwendungen.

JavaScript-Rendering. Prüft ein Tool nur die HTML-Antwort, fehlen alle Inhalte, die erst im Browser entstehen: nachgeladene Texte, Produktdaten, Navigationsbereiche, ganze Linkstrukturen. Rendering behebt das nur teilweise. Es kostet ein Vielfaches an Rechenzeit und stößt weiterhin auf Consent-Dialoge, verzögerte API-Aufrufe, notwendige Nutzerinteraktionen und Bot-Schutz. Außerdem hängt der gerenderte Zustand von Standort, Gerät, Cookies und Nutzerkonto ab. Prüfen Sie deshalb, ob ein Bericht auf dem Roh-HTML oder auf dem gerenderten DOM beruht. Steht es nirgends, ist die Antwort meistens Roh-HTML.

Der Punkt, an dem ein Desktop-Crawler nötig wird

Ein installierter Crawler ist kein besseres Online-Tool, sondern ein anderes Werkzeug. Screaming Frog SEO Spider etwa wird lokal auf Windows, macOS oder Ubuntu installiert und läuft nicht im Browser. Genau daher kommen seine Fähigkeiten: eigene Hardware, eigene Laufzeit, eigener Netzwerkzugang, eigene Konfiguration.

Der Wechsel lohnt sich, sobald mindestens einer dieser Punkte zutrifft:

  • Sie wollen nicht eine URL prüfen, sondern tausende systematisch erfassen.
  • Sie brauchen domainweite Muster: doppelte Titles, verwaiste Seiten, Klicktiefe, Weiterleitungsketten.
  • Der zu prüfende Bereich liegt hinter Login, VPN oder IP-Freigabe.
  • Individuelle Header, Cookies oder ein eigener User Agent sind erforderlich.
  • Das JavaScript-Rendering soll gezielt an- und abgeschaltet und verglichen werden.
  • Crawl-Daten sollen mit Sitemaps, URL-Listen, Search-Console- oder Analytics-Daten zusammengeführt werden.
  • Große Ergebnismengen müssen lokal gespeichert, gefiltert und versioniert werden.

Auch lokal gibt es keine Garantie auf Vollständigkeit. Bot-Schutz, unendliche URL-Räume durch Filter und Kalender, falsch gesetzte Regeln und knapper Arbeitsspeicher bleiben Fehlerquellen. Der Unterschied liegt nicht in der Perfektion, sondern in der Kontrolle: Sie bestimmen Zugriff, Tiefe, Tempo und Speicherung selbst.

Was die Datenweitergabe an einen fremden Server bedeutet

Jede Nutzung eines Online-Tools ist eine Übermittlung. Mindestens die URL verlässt Ihr Haus, dazu üblicherweise Zeitpunkt, IP-Adresse und Browserdaten, die der Anbieter in Serverprotokollen verarbeitet. Bei einer öffentlichen Unternehmensseite ist das unkritisch. Bei einem unveröffentlichten Relaunch, einer personalisierten URL oder einem internen Dokument nicht.

URLs tragen häufiger vertrauliche Angaben, als angenommen wird: E-Mail-Adressen, Kundennummern, Session-IDs, Zugriffstokens, interne Suchbegriffe. Eine schwer erratbare Staging-URL ist kein Zugriffsschutz, sondern nur Unauffälligkeit, und die endet in dem Moment, in dem die Adresse in fremden Logs steht.

Vor der Nutzung sind sieben Fragen zu klären: Welche Daten speichert der Anbieter? Wie lange? Werden Berichte öffentlich verlinkt oder für Dritte auffindbar? In welchem Land stehen Anbieter und Server? Welche Unterauftragnehmer sind eingebunden? Lassen sich Prüfungen löschen? Werden die Eingaben für andere Zwecke verwendet?

Eine Stufe ernster wird es, sobald ein Werkzeug nicht mehr nur eine URL abruft, sondern die Daten Ihrer eigenen Website-Besucher verarbeitet, etwa über eine Analytics- oder Monitoring-Anbindung. Dann ist in der Regel ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO erforderlich. Hinzu kommen Rechtsgrundlage, Datenminimierung, Löschfristen und die Prüfung möglicher Übermittlungen in Drittländer. Bei vertraulichen Projekten ist die lokale Analyse schlicht die risikoärmere Bauform, weil dabei nichts das eigene Netz verlässt.

Die Entscheidungsregel in einem Satz

Ein Browser-Check beantwortet Fragen, die an einer einzelnen, öffentlich erreichbaren URL hängen: Fehlt der Title? Ist die Description zu lang? Hat das Bild ein ALT-Attribut? Welcher Statuscode kommt zurück? Wohin geht die Weiterleitung? Welche groben Performance-Probleme zeigt der Labortest?

Sobald die Frage domainweit wird, hinter einer Anmeldung liegt, von gerendertem JavaScript abhängt oder einen eigenen Link-Index braucht, ist sie mit einem Formular im Browser nicht mehr zu beantworten. Nicht weil das Werkzeug schlecht wäre, sondern weil es an einer anderen Stelle steht als die Daten. Die nützlichste Frage vor jedem Check lautet deshalb nicht “welches Tool ist das beste”, sondern: Kann ein fremder Server ohne Zugangsdaten und in wenigen Sekunden überhaupt sehen, was ich wissen will?