So lesen Sie Ihren SRPS-Score und arbeiten mit technischen Briefings

Was das Site-Audit prüft

Der Großteil von Suparanku misst das Außen — was KI-Assistenten über Ihre Marke sagen. Das Site-Audit schaut nach innen: auf Ihre eigene Website, so wie KI-Crawler und Antwortmaschinen sie sehen. Es arbeitet auf zwei Ebenen. Das Domain-Audit prüft einmalig die websiteweiten Signale — HTTPS, robots.txt, ob Retrieval- und Citation-Bots zugelassen sind, Sitemaps, hreflang-Konsistenz, Organization-Markup. Das Seiten-Audit legt dieselbe Linse auf einzelne URLs: Statuscode, Canonical und noindex, genau ein H1, Länge von Title und Description, strukturierte Daten mit echten Fakten, Aktualität, alt-Abdeckung bei Bildern und den Zustand der Links auf der Seite.

Zusammen beantworten sie eine Frage, an die kein externer Sichtbarkeits-Tracker herankommt: Wenn die KI Ihre Seite nicht finden oder nicht lesen kann — warum nicht?

Wie Sie den SRPS lesen

Jede bewertbare Seite erhält einen SRPS, einen Readiness-Score von 0 bis 100. Das ist kein Checklisten-Prozentsatz: ein fehlender Title zählt stärker als eine fehlende Bildgröße. Ein Check, der nicht bewertet werden kann, fällt heraus statt gegen die Seite zu zählen.

Lesen Sie die Stufen wie eine Ampel:

• 80–100 — hohe technische Readiness.
• 60–79 — verbesserungsbedürftig; es bestehen relevante Lücken.
• unter 60 — geringe Readiness; priorisieren Sie die hoch gewichteten Befunde.

Zwei Details verändern, wie ein niedriger Wert zu lesen ist:

• Blocker setzen den Score auf 0. Ein fehlgeschlagener Sichtbarkeits-Blocker — etwa ein nicht erreichbarer Status, noindex oder eine nicht crawlbare Seite — setzt den Score unabhängig von allen anderen Prüfungen auf 0. Beheben Sie einen solchen Blocker zuerst.
• SRPS und SRPS+. Der einfache SRPS wird aus dem rohen HTML berechnet (schnelles Audit). Der SRPS+ stammt aus dem tiefen Audit, das die Seite wie ein Browser rendert und Prüfungen zur Extraktionsqualität ergänzt. Der SRPS+ zeigt einen Strich, bis Sie für diese Seite ein tiefes Audit starten. Ist der SRPS gesund, der SRPS+ aber schwach, hängen Ihre Inhalte an JavaScript, das Crawler möglicherweise nicht ausführen.

Der Domain-Score ist nicht der Durchschnitt der Seiten. Er verbindet die Seitenwerte mit Checks, die nur für die ganze Website Sinn ergeben — robots.txt, Sitemap, Übereinstimmung von Apex und www. Eine einzelne Seite bewegt ihn wenig, eine websiteweite Einstellung stärker.

Der SRPS misst technische Bereitschaft, nicht die Wahrscheinlichkeit einer Zitierung. Auch ein Wert von 100 verspricht weder Aufnahme in den Retrieval-Pool noch eine Erwähnung oder Empfehlung in einer KI-Antwort.

Warum eine Seite schlecht abschneidet

In der Praxis lassen sich niedrige Werte auf wenige Ursachen zurückführen:

• Zugang. Die robots.txt blockiert einen Retrieval- oder Citation-Bot, oder eine widersprüchliche Allow/Disallow-Regel tut es versehentlich. Nichts anderes zählt, wenn der Crawler nie ankommt.
• Indexierbarkeit. Ein übrig gebliebenes noindex, ein Canonical, das auf eine andere Seite zeigt, oder ein Status ungleich 200 nehmen die Seite still aus dem Rennen.
• Dünne Struktur. Keine strukturierten Daten, oder Markup, das zwar vorhanden ist, aber keine echten Fakten trägt (ein Product ohne Preis und Verfügbarkeit), oder fehlende beziehungsweise überlange Title und Description.
• Graph-Probleme. Eine Seite, auf die kein interner Inhalt verlinkt (verwaist), oder eine, die viele Klicks tief vergraben liegt, ist für jeden Crawler — und jeden Leser — schwer erreichbar.

Die derzeitigen manuellen Prüfungen (etwa in Google indexiert oder die Prüfung eines og:image) sind vom Score ausgeschlossen. Sie bleiben als Aufgaben sichtbar, verändern aber weder Zähler noch Nenner.

Beheben mit einem technischen Briefing

Das ist der Teil, der den Score handlungsfähig macht. Wo ein Audit-Befund einer technischen Empfehlung zugeordnet ist, stellt Suparanku ein deterministisches technisches Briefing zusammen. Es wird aus der fehlgeschlagenen Prüfung, ihren konkreten Nachweisen und der hinterlegten Korrekturanleitung gebaut — ohne eine neue KI-Analyse anzufordern. Es liefert:

• das Problem und genau die Stelle, an der es sitzt;
• warum es zählt, mit der PLAYBOOK-Taktik und der Stärke der Evidenz dahinter;
• die Schritt-für-Schritt-Korrektur, samt einsatzfertigem Artefakt — der robots.txt-Zeile, dem JSON-LD-Block oder dem korrigierten Meta-Tag;
• Abnahmekriterien, damit klar ist, wann die Sache wirklich erledigt ist.

Weil das Briefing schlichter, strukturierter Text ist, können Sie es direkt an eine Entwicklerin weitergeben, in ein Ticket legen oder einem kompatiblen KI-Agenten als Arbeitsanweisung geben. Geht die Korrektur live, prüft das nächste Audit dasselbe technische Signal erneut: besteht es, löst sich die Empfehlung automatisch auf; fällt es weiter durch, bleibt sie offen.

Ein Content-Briefing funktioniert anders: Eine Content-Empfehlung kommt zunächst ohne Briefing. Das Briefing wird auf Nachfrage per KI-Analyse erzeugt und zählt gegen das monatliche Kontingent des jeweiligen Tarifs. Technische Briefings und Content-Briefings sind daher keine zwei Varianten desselben Generierungsschritts.

Eine wöchentliche Gewohnheit

Sie brauchen nicht täglich einen vollständigen Crawl. Lassen Sie das schnelle Audit in seinem wöchentlichen Takt laufen, um den SRPS aktuell zu halten, und investieren Sie Ihr Budget für tiefe Audits in die Handvoll Seiten, auf die es ankommt — jene, die die KI bereits zitiert, oder jene, deren technische Bereitschaft Sie verbessern wollen. Lesen Sie den Domain-Score für die websiteweiten Blocker, sortieren Sie die Seiten nach SRPS, um die schwächsten zu finden, und arbeiten Sie die Briefings von oben ab. Erst Zugang, dann Indexierbarkeit, danach Struktur. Ob sich Zitierungen anschließend verändern, muss separat und über wiederholte Messungen beobachtet werden.