Rudra Analyzer

Methodik

So testen und bewerten wir Websites

Diese Seite erklärt genau, worauf unsere Prüfungen achten, woher ihre Nachweise stammen, wie jede Bewertung berechnet wird, wie wir sicher testen und wo die Grenzen liegen. Sie beschreibt die Einzelseiten-Prüfungen hinter den kostenlosen Tools und dem Website-Audit sowie die zusätzlichen Prüfungen eines Website-Scans.

Worauf jede Prüfung achtet

Ein vollständiges Audit umfasst sieben Prüfungen. Jede hat einen verständlichen Namen, den wir in unseren Berichten verwenden, und einen technischen Namen, der beschreibt, was tatsächlich getestet wird.

SEO

Technischer Name
OnPage- und technisches SEO
Was geprüft wird
Titel und Meta-Beschreibung (Länge, generische Formulierungen, wiederholte Wörter), H1 und Überschriftenreihenfolge, Canonical-URL und der Status ihres Ziels, Robots-Meta- und X-Robots-Tag-Regeln, Meta-Refresh, Open Graph- und Twitter-Card-Tags (einschließlich der Frage, ob og:image lädt), html lang, Viewport, Alt-Texte von Bildern, strukturierte JSON-LD-Daten (Parse-Fehler, doppelte Typen, ungültige URLs, fehlende Schlüsseleigenschaften gängiger Typen), hreflang, Favicon, Wortanzahl, Linktexte und URL-Aufbau sowie robots.txt, bis zu drei angegebene Sitemaps, llms.txt, Weiterleitungsketten und HTTPS.
Wie bewertet wird
Beginnt bei 100. Fehlender Titel −25, fehlende Meta-Beschreibung −15, fehlende H1 −15, noindex −30 und kleinere Abzüge (2–15 Punkte) für den Rest. Die neueren Prüfungen können zusammen höchstens 45 Punkte abziehen, und neue informative Befunde kosten nichts.
Getestet mit
Python requests + BeautifulSoup (liest das HTML, das der Server sendet; JavaScript wird nicht ausgeführt), plus je eine HEAD-Anfrage für ein abweichendes Canonical-Ziel und das og:image
SEO-Checker ausprobieren

Geschwindigkeit

Technischer Name
Seiten-Performance (Lighthouse)
Was geprüft wird
Die Performance-Kategorie von Lighthouse: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, Speed Index und Time to Interactive, jeweils verglichen mit dem veröffentlichten Schwellenwert (zum Beispiel LCP 2,5 s / 4 s, CLS 0,1 / 0,25, TBT 200 / 600 ms), plus bis zu 15 nicht bestandene Audits mit den zugehörigen Dateien. Kann Lighthouse nicht ausgeführt werden, meldet eine Schnellprüfung Serverantwort, HTML-Größe, Komprimierung, renderblockierende Dateien, Caching-Header sowie Größe und Format von Bildern.
Wie bewertet wird
Die eigene Performance-Bewertung von Lighthouse (0–100), unverändert. Ein Audit mit einem Wert unter 0,5 gilt als kritisch, unter 0,9 als Warnung. Die Schnellprüfung beginnt stattdessen bei 100 und listet ihre Abzüge auf; sie wird als Schnellprüfung gekennzeichnet, nie als Lighthouse-Bewertung.
Getestet mit
Google Lighthouse in Headless-Chrome, Standardeinstellungen (mobil), ein Durchlauf; Ersatz: 1 GET plus höchstens 25 HEAD-Anfragen
Website-Speed-Checker ausprobieren

Mobile Darstellung

Technischer Name
Responsives Layout
Was geprüft wird
Das Viewport-Meta-Tag (vorhanden, width=device-width, Zoomen nicht blockiert) und horizontaler Überlauf in den Größen Smartphone (375×667), Tablet (768×1024) und Desktop (1440×900), mit Nennung der überstehenden Elemente und Screenshots der Smartphone-Ansicht sowie jeder Größe mit einem Problem.
Wie bewertet wird
Beginnt bei 100. Fehlendes Viewport-Tag −20, Viewport ohne width=device-width −10, Viewport, das Zoomen blockiert −5, −15 für jede Größe, bei der die Seite breiter als der Bildschirm ist, −10, wenn bei irgendeiner Größe Ladeprobleme auftraten.
Getestet mit
Playwright mit Chromium
Mobil-Checker ausprobieren

Barrierefreiheit

Technischer Name
Automatisierte WCAG-Tests
Was geprüft wird
Der Standard-Regelsatz von axe-core – WCAG 2.x-Regeln der Stufen A und AA plus Best Practices – angewendet auf die gerenderte Seite. Bis zu 25 Verstoßarten werden aufgeführt, jeweils mit der Anzahl betroffener Elemente und bis zu fünf Beispielen (Selektor, HTML-Ausschnitt, was zu beheben ist). Regeln, die axe-core nicht entscheiden kann, erscheinen als „manuelle Prüfung nötig“, und bestandene Regeln werden ebenfalls aufgeführt.
Wie bewertet wird
Beginnt bei 100 und verliert Punkte pro nicht bestandener Regel, je nach Auswirkung: kritisch −15, schwerwiegend −10, mittel −5, gering −2.
Getestet mit
Eine mitgelieferte Kopie von axe-core, per Playwright in Chromium eingebunden
Barrierefreiheits-Checker ausprobieren

Website-Sicherheit

Technischer Name
Transportsicherheit, Header-Werte, Cookies und Angriffsfläche
Was geprüft wird
HTTPS nach Weiterleitungen und ob http:// dauerhaft auf HTTPS weiterleitet; das TLS-Zertifikat (Vertrauenswürdigkeit, Hostname, Protokollversion, Aussteller, Ablauf); Werte der Sicherheits-Header – HSTS max-age (mindestens 180 Tage) und Syntax, CSP-Direktiven einschließlich 'unsafe-inline', 'unsafe-eval', weit gefasster Skriptquellen, Nonces und Hashes, object-src und base-uri, X-Frame-Options oder CSP frame-ancestors, X-Content-Type-Options, Referrer-Policy, Permissions-Policy; Cookie-Flags (Secure, HttpOnly, SameSite, Domain) nur nach Name; CORS mit einem harmlosen Test-Origin; gemischte Inhalte; security.txt; Header, die Versionen verraten, und öffentliche Source Maps; Technologien und sichtbare Angriffsfläche wie Login-Formulare und API-Verweise; Inline-Event-Handler und Skripte ohne Subresource Integrity, markiert zur manuellen Prüfung.
Wie bewertet wird
Beginnt bei 100. Kein HTTPS −40, ungültiges oder abgelaufenes Zertifikat −40, fehlgeschlagene TLS-Verbindung −30, CORS, das jedem Origin mit Anmeldedaten vertraut −25, kein HSTS −15, keine CSP −12, keine Weiterleitung von http auf https −10, kein Clickjacking-Schutz −8, aktive gemischte Inhalte −8, CSP nur im Report-Only-Modus −8, kein X-Content-Type-Options −6, 'unsafe-inline'-Skripte −6, Cookies ohne Secure −6, schwaches HSTS −5 und kleinere Abzüge für andere schwache Werte. Viele informative Befunde, etwa eine fehlende security.txt, kosten nichts.
Getestet mit
Python requests (nur GET und HEAD) + das ssl-Modul der Standardbibliothek
Website-Sicherheits-Checker ausprobieren

Links & Seitenfehler

Technischer Name
Funktionaler Smoke-Test und Formularprüfung
Was geprüft wird
Lädt die Seite in einem Browser, erfasst JavaScript-Konsolenfehler, nicht abgefangene Ausnahmen sowie eigene Skripte, Styles, Bilder und Schriften, die nicht laden, testet bis zu 12 eindeutige Links zur selben Website (Navigation zuerst) und bis zu 5 Links zu anderen Websites und prüft das Markup jedes Formulars: HTTPS, GET mit Passwörtern, Beschriftungen, Eingabetypen, Autovervollständigung, externe Ziele, ein sichtbares CSRF-artiges Token und eine Absenden-Schaltfläche. Formulare werden nie abgeschickt, angeklickt, fokussiert oder ausgefüllt.
Wie bewertet wird
Beginnt bei 100. Jeder defekte interne Link −10 (höchstens −40), jeder nicht abgefangene JavaScript-Fehler −10 (höchstens −30), jeder Konsolenfehler −5 (höchstens −20), jede nicht geladene eigene Datei −4 (höchstens −20), ein Passwortformular über HTTP, das Absenden an http:// oder die Verwendung von GET je −10, ein Platzhalter als einzige Beschriftung −3. Defekte externe Links und die übrigen Formularhinweise sind informativ.
Getestet mit
Playwright mit Chromium; Linkprüfungen per HEAD mit GET als Ersatz
Broken-Link-Checker ausprobieren

Server & Erreichbarkeit

Technischer Name
Erreichbarkeit und Antwortzeit
Was geprüft wird
Die Seite selbst plus gängige Pfade – robots.txt, sitemap.xml, /health, /healthz, /api, /api/health, openapi.json, swagger.json, manifest.json und security.txt – auf Serverfehler und durchschnittliche Antwortzeit. Ein 404 bei diesen optionalen Pfaden wird nicht bestraft.
Wie bewertet wird
Beginnt bei 100. Seite nicht erreichbar oder 5xx −50, Seite 4xx −20, −15 für jeden weiteren Pfad mit 5xx (höchstens −30), durchschnittliche Antwortzeit über 800 ms −8 oder über 1.500 ms −15.
Getestet mit
Python requests
Website-Audit ausprobieren

So werden Nachweise erfasst

Ein Befund erscheint nur, wenn eine Prüfung das Beschriebene tatsächlich gesehen hat – einen Header-Wert, ein Element, eine Antwort. Jeder Befund hält fest, woher sein Nachweis stammt:

HTTP-Antwort
Statuscodes, Weiterleitungen und Antwort-Header aus einer normalen Anfrage an Ihre Seite.
HTML
Der Seitenquelltext, den Ihr Server sendet, bevor JavaScript ausgeführt wird.
Gerenderte Seite und Browser-Laufzeit
Die Seite, nachdem sie in Chromium geladen wurde: die gerenderten Elemente, JavaScript-Fehler und Dateien, die nicht laden.
Lighthouse
Labormesswerte und Audits aus einem Lighthouse-Durchlauf.
axe-core
Ergebnisse der Barrierefreiheitsregeln für die gerenderte Seite.
Crawl-Daten
Bei Website-Scans: die beim Crawl gespeicherten Seiten, Links, Titel und Canonicals – ohne zusätzliche Anfragen.
robots.txt und Sitemap
Die Regeln Ihrer robots.txt und die URLs, die Ihre XML-Sitemaps auflisten.
TLS-Verbindung
Das Zertifikat und die Protokollversion, die Ihr Server vorweist.

Datenschutz: Nachweise enthalten nie Cookie-Werte, Tokens, Passwörter, Authorization-Header, API-Schlüssel oder Eingaben in Formularen. Cookies werden nur mit Name und Flags gemeldet, Formularfelder nur mit Name und Beschriftung, und Query-Parameter, die wie Tokens aussehen, werden aus URLs entfernt.

Sicherheitsstufen

Jeder Befund gibt an, wie sicher wir uns sind – so wissen Sie, was Sie sofort angehen und was Sie zuerst prüfen sollten.

Hoch

Direkt festgestellt: ein Header-Wert, ein Statuscode, ein Element, das gegen eine Regel verstößt. Sie können es in Sekunden selbst bestätigen.

Mittel

Ein starkes Signal, das vom Kontext abhängt – zum Beispiel ein Cookie, das seinem Namen nach wie ein Sitzungs-Cookie aussieht, oder eine Seite in der Sitemap, auf die keine gecrawlte Seite verlinkt.

Gering

Eine Heuristik, die ein Mensch prüfen muss, etwa ein Formular ohne sichtbares CSRF-Token oder Inline-Event-Handler. Solche Befunde werden als „möglich“ oder „manuelle Prüfung“ formuliert und nie als bestätigte Schwachstellen dargestellt.

Durchgeführte Prüfungen und „Nicht geprüft“

Berichte führen jede ausgewertete Regel auf, auch die bestandenen – so sehen Sie, was abgedeckt wurde, und nicht nur, was schiefging. Eine kurze Problemliste bedeutet etwas anderes, wenn vierzig Prüfungen bestanden wurden, als wenn nur fünf laufen konnten.

„Nicht geprüft“ heißt, dass eine Prüfung nicht zutraf oder nicht sicher ausführbar war – zum Beispiel die Secure-Prüfung für Cookies auf einer Seite ohne HTTPS oder ein Link zu einer privaten Adresse. „Übersprungen“ heißt, dass sie nicht laufen konnte, meist weil unsere eigene Anfrage fehlschlug oder eine Zeitüberschreitung hatte; der Bereich wird dann als teilweise markiert, und die Zusammenfassung nennt die fehlenden Prüfungen. Eine Zeitüberschreitung oder ein DNS-Fehler auf unserer Seite bedeutet „konnte nicht überprüft werden“, nie einen Fehler Ihrer Website.

Übersprungene und nicht geprüfte Prüfungen kosten keine Punkte. Konnte ein ganzer Bereich nicht laufen – weil sein Tool nicht verfügbar war oder er auf unserer Seite fehlschlug –, wird er aus der Gesamtbewertung herausgenommen, statt mit null gezählt zu werden.

Sicherheit: Warum Sicherheitsprüfungen nichts beschädigen

Jede Prüfung ist passiv und rein lesend. Konkret bedeutet das:

  • Unsere eigenen Anfragen verwenden nur GET oder HEAD – nie POST, PUT, PATCH oder DELETE. Wird eine Seite im Browser geöffnet, laufen ihre eigenen Skripte wie bei jedem Besucher.
  • Die CORS-Prüfung ist ein einzelnes GET mit einem harmlosen Origin für eine Domain, die es nicht geben kann (https://rudra-audit.invalid), ohne Cookies oder Anmeldedaten.
  • Abgerufen wird nur eine kurze, feste Liste bekannter Dateien – etwa robots.txt, sitemap.xml, /.well-known/security.txt, llms.txt, humans.txt und das Manifest, auf das Ihre Seite verlinkt, plus die oben bei der Serverprüfung genannten Health- und API-Beschreibungspfade. Andere Pfade raten oder durchsuchen wir nicht, und Source Maps werden nur geprüft, wenn eines Ihrer eigenen Skripte sie nennt.
  • Formulare werden nie abgeschickt, angeklickt, fokussiert oder ausgefüllt, und es werden keine Angriffs-Payloads gesendet.
  • Wir melden uns nie an, senden keine Anmeldedaten und probieren keine Passwörter aus.
  • Anfragen an private und interne Netzwerkadressen – localhost, 10.x, 192.168.x, Cloud-Metadatendienste und Ähnliches – werden vor dem Senden blockiert, auch bei Weiterleitungen und bei unseren Playwright-Browserprüfungen für jede Anfrage, die die Seite beim Laden stellt.

Bewertung

Jeder Bereich beginnt bei 100 und verliert Punkte für gefundene Probleme; für die Geschwindigkeit wird stattdessen die eigene Bewertung von Lighthouse verwendet. Der Bericht führt jeden Abzug neben dem verursachenden Befund auf, sodass Sie genau sehen, wo die Punkte geblieben sind.

Dasselbe Problem wird nie doppelt abgezogen: Drei Cookies ohne Secure sind ein Befund mit einem Abzug. Wo die Anzahl zählt, etwa bei defekten Links oder JavaScript-Fehlern, wächst der Abzug mit der Anzahl bis zu einer angegebenen Obergrenze. Neuere informative Befunde kosten nichts; einige langjährige Prüfungen mit niedriger Priorität behalten einen kleinen Abzug, zum Beispiel eine fehlende Referrer-Policy (−4) oder eine kleinere Barrierefreiheitsregel (−2).

Ein Website-Scan ergänzt seitenübergreifende SEO-Prüfungen – doppelte Titel und Beschreibungen, Canonical-Probleme, Links auf Weiterleitungen, Sitemap-URLs mit Fehlern, fehlende hreflang-Rückverweise und identische Inhalte –, die Einzelseiten-Prüfungen nicht erkennen können. Zusammen können sie höchstens 5 Punkte von der SEO-Bewertung abziehen, und Probleme, die bereits auf den einzelnen Seiten bewertet wurden, werden nicht erneut gezählt.

So wird die Gesamtbewertung berechnet

Die Gesamtbewertung ist der Durchschnitt der Kategoriebewertungen, auf eine ganze Zahl gerundet. Es zählen nur Kategorien, die ein Ergebnis geliefert haben. Ist ein Tool auf unserem Server nicht verfügbar oder schlägt eine Prüfung auf unserer Seite fehl, wird diese Kategorie aus dem Durchschnitt herausgenommen, statt sie mit null zu zählen oder zu schätzen. Ist Lighthouse nicht verfügbar, deckt die Schnellprüfung die Geschwindigkeit ab.

Wenn eine Prüfung zwar startet, aber nicht abgeschlossen werden kann, etwa weil die Seite nicht rechtzeitig lädt, erhält sie 0 Punkte und zählt mit – denn das ist ein echtes Problem, auf das auch ein Besucher stoßen würde.

Bewertungen werden mit einem verständlichen Status angezeigt: 90–100 ist „Gut“, 50–89 „Verbesserungsbedarf“ und 0–49 „Schlecht“. Der Status steht immer ausgeschrieben neben seiner Farbe.

Die Tools, die wir verwenden

Wir setzen auf etablierte, offene Tools, statt eigene Messverfahren zu erfinden.

  • Google Lighthouse

    Misst die Ladeleistung in einem echten Chrome-Browser. Wir übernehmen Performance-Bewertung und Audits unverändert und kennzeichnen jede Kennzahl als Labormessung aus einem Durchlauf.

  • Playwright und Chromium

    Lädt Seiten in einer echten Browser-Engine für die Prüfungen zu mobilem Layout, Links, Formularen und Fehlern sowie Barrierefreiheit und erstellt Screenshots. Anfragen an private Netzwerkadressen werden im Browser blockiert.

  • axe-core

    Die Open-Source-Regel-Engine für Barrierefreiheit von Deque, die für automatisierte WCAG-Tests weit verbreitet ist.

  • requests und BeautifulSoup

    Rufen Seiten ab und analysieren ihr HTML für die SEO-, Sicherheits- und Serverprüfungen – ausschließlich mit GET- und HEAD-Anfragen.

  • Das ssl-Modul von Python

    Baut eine TLS-Verbindung auf, um Ihr Zertifikat auszulesen und gegen die üblichen vertrauenswürdigen Zertifizierungsstellen zu prüfen.

Was automatische Prüfungen nicht verraten können

  • Ob Ihre Inhalte nützlich, korrekt oder überzeugend sind oder wie gut sie im Vergleich zur Konkurrenz ranken werden.
  • Fragen zur Barrierefreiheit, die ein Mensch beurteilen muss: ob Alt-Texte aussagekräftig sind, die Tastaturreihenfolge sinnvoll ist oder Inhalte verständlich sind.
  • Ob Ihre Website Schwachstellen, veraltete Software, schwache Passwörter oder Malware hat. Die Sicherheitsprüfung liest Ihre Konfiguration aus – sie ist kein Penetrationstest.
  • Wie schnell Ihre Website für Ihre echten Besucher ist. Lighthouse führt einen einzelnen Labortest durch; Daten echter Besucher können abweichen.
  • Alles hinter einem Login, einer Paywall oder einem Formular – wir sehen nur öffentlich ladende Seiten.
  • Probleme auf anderen Seiten. Jede Einzelseiten-Prüfung betrachtet nur die Adresse, die Sie eingeben.

Warum Ergebnisse zwischen Durchläufen schwanken können

Die Geschwindigkeit schwankt am stärksten. Jeder Lighthouse-Durchlauf ist ein neuer Seitenaufruf, und Netzwerkbedingungen, Serverlast, Caching, Werbung und Skripte von Drittanbietern unterscheiden sich von Aufruf zu Aufruf. Ein paar Punkte Unterschied zwischen Durchläufen sind normal.

Browserbasierte Prüfungen können ebenfalls abweichen, wenn die Seite Inhalte in zufälliger Reihenfolge lädt, unterschiedliche Banner oder Experimente zeigt oder automatisierte Besucher zeitweise blockiert. SEO- und Sicherheitsergebnisse ändern sich nur, wenn sich Ihre Seite oder Serverkonfiguration ändert.

Bekannte Einschränkungen nach Bereich

Geschwindigkeit

Ein Labortest eines einzelnen Aufrufs mit der Standardsimulation von Lighthouse: ein Mittelklasse-Smartphone mit gedrosselter Verbindung. Interaction to Next Paint (INP) lässt sich damit nicht messen, da dafür echte Interaktionen nötig sind; Total Blocking Time ist das nächstliegende Labor-Signal.

Barrierefreiheit

Automatische Regeln finden nur einen Teil der Probleme, die eine Seite haben kann. Bestehen heißt nicht, dass die Seite WCAG erfüllt; manuelle Tests mit Tastatur und Screenreader bleiben nötig.

Sicherheit

Liest die Konfiguration, die ein Browser erhält: Header-Werte, Cookie-Flags aus der Antwort der Seite selbst, CORS, TLS und das HTML. Es ist kein Penetrationstest – keine Ausnutzung, keine Anmeldung, keine geschützten Seiten, keine Prüfung des serverseitigen Codes und kein Schwachstellenscan Ihrer Software oder Abhängigkeiten.

Links und Formulare

Testet pro Seite bis zu 12 Links zur selben Website und 5 zu anderen Websites. Manche Server liefern automatisierten Besuchern Fehler, obwohl die Seite für Menschen funktioniert; externe Antworten mit 401, 403, 405 und 429 gelten daher als nicht eindeutig. Formulare werden nie abgeschickt, deshalb lassen sich serverseitige Validierung und CSRF-Schutz nicht testen.

SEO

Liest das HTML, das Ihr Server sendet, nicht die Seite nach Ausführung von JavaScript. Rankings, Traffic, Keywords oder Backlinks werden nicht gemessen, und vollständige strukturierte Daten garantieren keine Rich Results.

Wie KI in Berichten eingesetzt wird

Wenn sie aktiviert ist, formuliert ein KI-Modell (Claude von Anthropic) die tatsächlichen Ergebnisse eines Scans in eine kurze, priorisierte Liste nächster Schritte um. Es erhält die gescannte Adresse, die Kategoriebewertungen und die Probleme, die unsere Scanner erkannt haben.

Es ist angewiesen, nur diese Ergebnisse zu erklären und zu priorisieren. Es erfindet keine Probleme, ändert keine Bewertungen und behauptet nicht, etwas sei gemessen worden, was nicht gemessen wurde. Ist keine KI eingerichtet oder schlägt die Anfrage fehl, verwenden wir stattdessen eine Zusammenfassung aus einer Vorlage, die auf den am schlechtesten bewerteten Bereichen basiert – der Bericht zeigt an, welche Sie lesen.

Bewertungen und Probleme stammen immer von den oben beschriebenen Scannern, nie von der KI.

Was mit Ihren Daten passiert

Analysen sind vorübergehend. Jeder Scan, Website-Scan und Layout-Test – mit Ergebnissen, Berichten und Screenshots – wird 24 Stunden nach der letzten Aktivität automatisch gelöscht.

Unsere Datenschutzerklärung erläutert, was wir sonst noch speichern, etwa Kontodaten, und wie lange.

Datenschutzerklärung lesen

Probieren Sie die Prüfungen aus

Jedes Tool auf dieser Seite können Sie kostenlos an einer Seite Ihrer Website ausprobieren, und unsere Ratgeber erklären, wie Sie die gefundenen Probleme beheben.

Kostenlose Tools ansehenVollständiges Website-Audit startenRatgeber lesen