Erklärung
Trenne Tatsache, Deutung und Maßnahme. Nutze für diese kurze Schulungsübung drei Stufen:
- P0 — Blocker: Eine wichtige öffentliche Seite ist nicht erreichbar, versehentlich für Crawling/Indexierung gesperrt oder verursacht einen kritischen sichtbaren Nutzerfehler; bestätige zuerst die Auswirkung auf die genaue URL.
- P1 — erhebliche Abweichung: Eine wichtige Seite hat einen Entdeckungspfad oder ist erreichbar, aber Inhalt, Sprache,
canonical/Links oder Formular erschweren das Verständnis oder die Nutzung. Die Aussage „Das Suchsystem hat diese Seite entdeckt“ muss separat in einem Bericht oder verifizierten Protokoll bestätigt werden. - P2 — Verbesserung: Das Problem verhindert keinen Zugriff und führt Nutzer nicht in die Irre; halte es fest und plane es nach den Blockern ein.
Dies ist eine Arbeitspriorität für den Kurs, kein Suchmaschinenstandard. Bei ähnlicher Dringlichkeit hat ein Problem mit stärkeren reproduzierbaren Belegen und größerer Auswirkung auf Nutzer Vorrang.
Prüfbare Kriterien:
- Entdeckungspfad: ein normaler HTML-Link von einer geprüften Staging-Seite oder die URL in der geprüften Sitemap. Halte die Quelle fest; sie zeigt einen möglichen Weg, aber nicht, dass das System die URL gefunden hat.
- Entdeckung durch ein System: Bestätige sie im passenden Suchsystembericht oder anhand verifizierter Crawl-Protokolle.
- URL- und Canonical-Konsistenz: Der Link führt zur erwarteten endgültigen URL, die Antwort ist korrekt,
canonicalpasst zur Zielversion und die Sitemap enthält dieselbe kanonische URL. Prüfe das vom Suchsystem gewählte Canonical separat in dessen Bericht. - Keine dieser Prüfungen allein bestätigt die Indexierung.
Fiktives Beispiel
Die Schulungsnachbildung von /robots hat folgende Signale: Ein Kataloglink führt zu einer http://-URL, die weiterleitet; das HTML-canonical zeigt auf /robots-v2, während die Sitemap /robots enthält. Das ist eine P1-Abweichung, wenn beide Seiten erreichbar sind und Nutzer auf den Inhalt zugreifen können; eine höhere Priorität erfordert zusätzliche Belege für eine Sperre oder einen Zugriffsverlust. Änderungen an canonical, robots/noindex und WAF können Zugriff und Website-Signale beeinflussen. Daher benötigen echte Änderungen die Zustimmung des Eigentümers, eine vorherige Prüfung und einen getesteten Rücksetzplan.
Übung
Arbeite ausschließlich in einer Testumgebung oder lokalen Kopie von example.test:
- Erzeuge in der Testnachbildung für
/robotseinen widersprüchlichen Link-, Canonical- und Sitemap-Zustand. - Fülle den Protokolleintrag mit Rohbelegen und den Grenzen der Schlussfolgerung aus.
- Weise nach den obigen Kriterien P0/P1/P2 zu.
- Schlage eine Korrektur und die erwartete beobachtbare Änderung vor, setze sie aber nicht in der Produktion um.
- Prüfe die Korrektur in der Testumgebung mit denselben Methoden. Jede echte Produktionsänderung an
robots.txt,noindex,canonicaloder WAF erfordert zuvor einen bestätigten Eigentümer, eine schriftliche Folgenabschätzung und einen Rücksetzplan; die Bereitstellung folgt dem üblichen Freigabeprozess. Ändere für diese Übung nichts in der Produktion.
Prüfliste
- URL, Zeitpunkt, Werkzeug und Rohbelege sind dokumentiert.
- Entdeckungspfad (Link/Sitemap) und bestätigte Systementdeckung (Bericht/verifiziertes Protokoll) sind getrennt.
- URL, Weiterleitung,
canonicalund Sitemap wurden einzeln geprüft. - Die Priorität ist mit Auswirkung und Zuverlässigkeit der Beobachtung begründet.
- Übung und Korrektur fanden nur in der Testumgebung/example.test statt.
- Jede spätere Produktionsänderung nennt Eigentümer, Prüfung und Rücksetzplan.
- Vorher- und Nachher-Prüfung verwenden dieselbe URL, Methode und Bedingungen.
Häufiger Fehler
robots.txt, canonical oder WAF in der Produktion „zum Ausprobieren“ ändern und erst danach prüfen. Eine solche Änderung kann einen nützlichen Bereich sperren oder den Zugriff verändern. Beginne in der Testumgebung, mit Zustimmung des Eigentümers, Prüfung und Rücksetzplan.
Wiederverwendbare Fragen und Ausgangsbasis für Migrationen
Führe für wiederholbare Prüfungen von KI-Antworten eine kleine, stabile Auswahl echter Kundenfragen. Bewahre den genauen Wortlaut, Sprache, Region, Produktoberfläche, Datum sowie Konto-/Sitzungsbedingungen auf. Nimm Entdeckungs-, Vergleichs- und Entscheidungsfragen auf; ergänze nicht jede Anfrage um einen Markennamen. Ein Beispiel für eine fiktive Website: „Was sollte ich prüfen, bevor ich eine kleine Dokumentationswebsite auf eine neue Domain umziehe?“ Halte die vollständige Antwort und zitierte URLs fest. Das ist ein Messverfahren, weder eine empfohlene Zahl von Anfragen noch ein Zitatversprechen.
Exportiere vor einer Migration die alten URLs und lege für jede wichtige URL eine Zeile an: alte URL, vorgesehenes Ziel, Weiterleitungsstatus, endgültige Antwort, Canonical-Ziel, interne Links und Eintrag in der Sitemap. Teste die Zuordnung in der Testumgebung, einschließlich Query-Strings und Varianten mit abschließendem Schrägstrich, die die Website tatsächlich verwendet. Vergleiche vor der Einführung eine repräsentative Auswahl und prüfe nach der Einführung dieselben URLs erneut. Ersetze eine Weiterleitungskarte nicht durch eine pauschale Weiterleitung zur Startseite; ändere die Produktion nicht ohne vom Eigentümer freigegebene Veröffentlichung und Rücksetzplan.
In dieser Übung ist die Spalte „Ergebnis nach Einführung“ nur eine Vorlage für später: Trage „nicht zutreffend – keine Produktionsveröffentlichung“ ein. Fülle sie erst nach einer vom Eigentümer freigegebenen Veröffentlichung aus.
| Alte URL | Vorgesehenes Ziel | Ergebnis in der Testumgebung | Ergebnis nach Einführung |
|---|---|---|---|
https://example.test/guide-a | https://example.test/docs/guide-a | Status und endgültige URL notieren | dieselbe Anfrage wiederholen |
https://example.test/guide-b | https://example.test/docs/guide-b | Status und endgültige URL notieren | dieselbe Anfrage wiederholen |
Der Host .test und alle obigen Zeilen sind fiktive Beispiele.