Frage und Grenzen des Audits festlegen
Ein technischer Audit-Bericht unterstützt Entscheidungen: Beobachtung, Zielkonflikt, verantwortliche Person und Nachweis der Korrektur. Host, Umgebung, Erfassungszeit, URL-Quelle, Crawl- und Rendering-Methode sowie Zugriffsgrenzen gehören an den Anfang. Sechs URLs sind keine Vollerhebung; ungeprüfte Templates, Geräte und geschützte Bereiche ausdrücklich nennen.
Die Originalbeispiele laufen auf Ihrem Rechner. Vorher- und Nachher-Pfade existieren gleichzeitig und verändern keine Produktionsseite. Sie zeigen HTTP, HTML-Anweisungen und Übergaben, simulieren aber weder Googlebot noch JavaScript-Rendering, Felddaten oder Indexierung. Relative Canonicals halten die Übung portabel; für Produktion die Canonical-Dokumentation beachten.
Reproduzierbare Belege dokumentieren
Exakte URL, Methode, Antwortkette, relevante Header und Quelltext erhalten. Bei realen Prüfungen UTC-Zeit sowie Trace- oder Screenshot-Verweis ergänzen. Initiales und gerendertes HTML getrennt erfassen, wenn sie abweichen. Beobachtung, Erklärung und Empfehlung unterscheiden; ungeprüft bedeutet nicht bestanden.
Der Prüfaufruf erzeugt sechs Antwortpaare als JSON. Mit evidence.json aus dem ZIP vergleichen. Serverdatum und temporäre Ports fehlen bewusst im stabilen Trace: Das ist ein wiederholbarer Testfall, keine datierte Kundenmessung. Die festen Befehle crawlen keine beliebigen Websites.
Ziel, Umfang und Sicherheit getrennt priorisieren
Drei hohe Prioritäten verletzen ein erklärtes Auslieferungs- oder Indexierungsziel; zwei mittlere Fälle brauchen begrenzte Template- oder Inhaltskorrekturen. Die Kontrolle bleibt unverändert. Für echte Websites Reichweite, kritische Pfade, Belegsicherheit, Änderungsrisiko und Aufwand separat beurteilen. Aus sechs Fällen keine Häufigkeit für die gesamte Website ableiten.
Je Befund eine verantwortliche Person und einen Prüftermin festlegen. Viele Warnungen sind nicht automatisch wichtiger als ein nachgewiesener Ausfall eines kritischen Pfads. Das gewünschte Verhalten klären, bevor noindex, Weiterleitungen oder Canonicals geändert werden. Beabsichtigte Ausschlüsse nicht für einen besseren Audit-Wert entfernen.
| ID | Beobachtung | Priorität | Verantwortlich |
|---|---|---|---|
| A01 | Öffentliche Startseite enthält noindex | Hoch | Webentwicklung |
| A02 | Robots blockiert die Ausschlussanweisung | Hoch | Plattformverantwortliche |
| A03 | Dauerhafte Weiterleitung endet im Fehler | Hoch | Routing-Entwicklung |
| A04 | Canonical verweist auf fremdes Thema | Mittel | SEO und Entwicklung |
| A05 | Fehlende Seite meldet Erfolg | Mittel | Webentwicklung |
| A06 | Funktionierende Kontrolle bleibt unverändert | Keine Änderung | Audit-Prüfung |
Sechs Befunde für die Übergabe an Entwickler
A01 · Öffentliche Startseite enthält noindex
Beobachtung: GET /launch liefert 200 und ein robots-Metaelement mit noindex. Ziel ist eine öffentlich suchfähige Seite.
Bedeutung: Die Anweisung widerspricht dem Ziel. Sie ist vorhanden; ob Google sie gesehen hat, ist unbekannt.
Empfohlene Maßnahme: Unbeabsichtigte Anweisung im öffentlichen Template entfernen. Auch HTTP-Header und gerendertes HTML prüfen.
Verantwortlich: Webentwicklung
Abnahmeprüfung: /fixed/launch liefert 200 ohne noindex. Reale Bereitstellung erneut prüfen; autorisierte URL-Prüfung getrennt durchführen.
A02 · Robots blockiert die Ausschlussanweisung
Beobachtung: robots.txt sperrt /blocked/; /blocked/page enthält noindex. Ziel ist Suchausschluss, keine Zugangsbeschränkung.
Bedeutung: Ein regelkonformer Crawler kann die Anweisung nicht lesen. Robots ersetzt keine Authentifizierung.
Empfohlene Maßnahme: Crawling der auszuschließenden Seite erlauben und noindex beibehalten. Private Inhalte durch Authentifizierung schützen.
Verantwortlich: Plattformverantwortliche
Abnahmeprüfung: /fixed/blocked/page liegt außerhalb der Sperre und enthält weiterhin noindex. Echte Host-Regeln und spätere Indexbeobachtungen gesondert prüfen.
A03 · Dauerhafte Weiterleitung endet im Fehler
Beobachtung: /old-guide leitet mit 301 zu /missing-guide weiter, das 404 liefert. /guide gilt hier als passender Ersatz.
Bedeutung: Der Weg liefert den gewünschten Inhalt nicht. Eine Weiterleitung allein bestätigt kein erfolgreiches Ziel.
Empfohlene Maßnahme: Direkt auf den passenden funktionierenden Ersatz verweisen und interne Links aktualisieren. Nicht alle gelöschten Seiten zur Startseite umleiten.
Verantwortlich: Routing-Entwicklung
Abnahmeprüfung: /fixed/old-guide führt über genau eine 301 zu /guide mit 200 und dem erwarteten Inhalt. Gesamte Kette nach Bereitstellung prüfen.
A04 · Canonical verweist auf fremdes Thema
Beobachtung: /variant nennt /other-topic als Canonical, obwohl der Inhalt /guide entspricht.
Bedeutung: Die Präferenz widerspricht der Inhaltsbeziehung. Googles gewählte kanonische URL ist damit nicht bekannt.
Empfohlene Maßnahme: Gleichwertigkeit bestätigen; Canonical, interne Links und Sitemap auf /guide abstimmen. Eigenständige Inhalte getrennt erhalten.
Verantwortlich: SEO und Entwicklung
Abnahmeprüfung: /fixed/variant nennt /guide; dieses Ziel funktioniert. Googles Auswahl später separat prüfen.
A05 · Fehlende Seite meldet Erfolg
Beobachtung: /gone liefert 200 und eine Not-found-Überschrift. Ein passender Ersatz fehlt.
Bedeutung: Fehlerinhalt und Erfolgsstatus widersprechen sich: ein Soft-404-Kandidat, keine bestätigte Google-Einstufung.
Empfohlene Maßnahme: Passenden Fehlerstatus senden, veraltete interne Links entfernen und eine hilfreiche Fehlerseite behalten.
Verantwortlich: Webentwicklung
Abnahmeprüfung: /fixed/gone liefert 404 mit Fehlerinhalt. Eine spätere Search-Console-Beobachtung ist ein eigenständiger Beleg.
A06 · Funktionierende Kontrolle bleibt unverändert
Beobachtung: /guide liefert 200, verweist kanonisch auf sich selbst und ist hier nicht durch robots gesperrt. noindex fehlt in dieser Antwort.
Bedeutung: Diese lokalen Prüfungen bestehen. Inhalt, Rendering, Auffindbarkeit, Indexierung und Rankings sind damit nicht bewiesen.
Empfohlene Maßnahme: Bestandene Kontrolle dokumentieren. Weitere Signale nur anhand einer konkreten Frage untersuchen.
Verantwortlich: Audit-Prüfung
Abnahmeprüfung: Vorher und nachher sind identisch. Belege erhalten, statt für eine höhere Fehlerzahl Probleme zu erfinden.
Mit einer neuen Prüfung abschließen
Ein Umsetzungsticket ist kein Abschlussbeleg. Ursprünglichen Aufruf in Produktion wiederholen, vergleichbare URLs prüfen und neue Zeit samt Antwort dokumentieren. Alte Belege erhalten. Technische Abnahme und spätere Suchmaschinenbeobachtung getrennt führen; eine korrigierte Anweisung garantiert weder Indexierung noch Traffic.
Bericht und Aufgabenliste verwenden
Die ausgefüllte CSV enthält sechs Entscheidungen; die leere Datei nur Spaltenüberschriften. Reale URLs, Umgebung, UTC-Zeit, Belegverweise, Reichweite, Sicherheit, Zuständigkeit, Termin, Status und Nachprüfung eintragen. HTML ist ein eigenständiger, druckbarer Bericht. Die Seite speichert kein Konto-Audit und untersucht keine eingegebene Domain.
Die Zusammenfassung beginnt mit Umfang und erforderlichen Entscheidungen, gefolgt von Prioritäten, Belegen, Abhängigkeiten und Abschlussplan. Zurückgestellte Prüfungen benennen. Die Übung nicht als Kundenaudit ausgeben oder Lücken durch erfundene Messwerte füllen. Rendering, Internationalisierung, strukturierte Daten, Barrierefreiheit und Performance können weitere Arbeit erfordern.
Ausgefüllte Aufgabenliste (CSV)
Technische Prüfungen von Leistungsaussagen trennen
Technische Eignung und beobachtete Suchleistung sind verschiedene Fragen. Für datierte Suchanfragen-/Seitenexporte dient der Ranking-Bericht, für Quelllinks das Backlink-Audit. Eine funktionierende Seite kann unindexiert bleiben. Klickänderungen beweisen weder Canonical-Fehler noch die Wirkung eines gekauften Backlinks.
SEO-Ranking-Bericht: Sichtbarkeit vergleichen und Mittelwerte verstehen
Backlink-Audit durchführen: Belege, Prioritäten und Aufgabenvorlage