Zusammenfassung

  • AFRINICs News & Announcements antwortete am 31. August mit HTTP 200; Titel, H1, Nachrichtenliste für 2026 und JSON-LD bezeichneten die Seite als News-Angebot.
  • Im selben Dokument verwiesen Canonical, Meta-Beschreibung, Open-Graph-Titel und -URL sowie der Twitter-Titel auf die separate Privacy Policy.
  • AFRINICs Sitemap führt News und Privacy getrennt. RFC 6596 verlangt für ein Canonical-Ziel duplizierten Inhalt oder eine Obermenge; die erfassten Seiten erfüllen diese Beziehung nicht.
  • Belegt ist eine fehlerhafte Quellidentität, nicht eine Deindexierung, ein Reichweitenverlust oder eine tatsächlich falsch ausgespielte Social Card.

Der Statuscode schließt nur die Verfügbarkeitsprüfung

Am 31. August um 05:46 UTC war AFRINIC News & Announcements erreichbar. Der Browser-Titel und die sichtbare Hauptüberschrift sagten „News & Announcements“. Darunter stand eine aktuelle Liste für 2026 mit Mitteilungen zum Appeal Committee, zum designierten CEO, zur Mitgliederbefragung und weiteren institutionellen Themen.

Auch JSON-LD ordnete das Dokument als News & Announcements ein und nannte eine URL mit news.html. Breadcrumb und Navigation führten zu News. Damit ist positiv belegt, dass die Route ihre sichtbare Aufgabe erfüllte. Es wäre falsch, daraus einen Ausfall oder eine durch den Datenschutztext ersetzte Nachrichtenseite zu machen.

HTTP 200 beantwortet jedoch nicht, welche Ressource das Dokument maschinenlesbar zu sein behauptet. Diese zweite Prüfung liefert ein anderes Ergebnis.

Ein gültiges Ziel mit der falschen Rolle

Das Canonical der News-Seite lautet https://afrinic.net/privacy.html. Die gewöhnliche Meta-Beschreibung nennt das Dokument die offizielle Privacy-Policy-Seite von AFRINIC. Die Open-Graph-Titel tragen den Namen der Privacy Policy; die absolute Open-Graph-URL zeigt ebenfalls dorthin. Twitter-Titel und -Beschreibung übernehmen dieselbe Identität.

Das ist mehr als eine Normalisierung zwischen www und der Stammdomain. Der Pfad und die inhaltliche Rolle wechseln von News zu Privacy.

Die AFRINIC Privacy Policy existiert separat und antwortet ebenfalls mit 200. Ihr Browser-Titel, H1 und selbstreferenzielles Canonical sind auf Datenschutz abgestimmt. Das Ziel ist also nicht kaputt. Gerade weil es ein funktionsfähiges anderes Dokument ist, ist seine Wahl als bevorzugte Identität der News-Seite problematisch.

Ein bloßer Vollständigkeitstest würde nichts bemerken: Alle Felder sind vorhanden. Erst der Vergleich ihrer Bedeutung zeigt, dass im selben HTML zwei Objekte beschrieben werden.

Die Sitemap widerspricht der Zusammenlegung

In der AFRINIC-Sitemap stehen /news und /privacy als getrennte Einträge. Die Datei ist keine Google-News-Sitemap und verrät nicht, was eine Suchmaschine tatsächlich indexiert hat. Sie belegt nur, dass AFRINICs eigene Discovery-Liste zwei öffentliche Ressourcen führt.

Damit entsteht eine interne Spannung: Die Sitemap trennt, was das Canonical der News-Seite als eine bevorzugte Ressource zusammenführen will. Unterschiede bei Hostname und .html gehören in den Prüfbericht, sind aber nicht der Kern. Der Kern ist die unterschiedliche Inhaltsrolle.

Eine kontrollierte Korrektur muss deshalb nicht die Sitemap oder eine der Seiten entfernen. Sie muss die Beziehung zwischen Route und Identität berichtigen.

Was RFC 6596 erlaubt — und was nicht

RFC 6596 definiert Canonical für Ressourcen mit dupliziertem Inhalt. Das Ziel muss den Inhalt der Ausgangsressource duplizieren oder als Obermenge enthalten. Anwendungen können die Verarbeitung anschließend auf die bevorzugte Ressource konzentrieren.

Eine Nachrichtenliste und eine Datenschutzerklärung bilden in den erfassten Darstellungen keine solche Beziehung. Sie haben andere Überschriften, Zwecke und Texte. Das Setzen eines Links erzeugt keine Duplizität.

Der Standard begrenzt zugleich die Folgerung. Canonical ist keine HTTP-Weiterleitung. Eine Anwendung kann eine unzulässige Deklaration ignorieren und eigene Heuristiken verwenden. Ohne Search-Console-, Index- oder Traffic-Daten lässt sich daher weder eine Entfernung aus Suchergebnissen noch ein Ranking- oder Reichweitenverlust behaupten.

Sicher ist nur der veröffentlichte Hinweis: Die News-Seite erklärte ein sachfremdes Dokument zur bevorzugten Identität.

Social-Metadaten brauchen eine eigene Beweiskette

Das Open Graph protocol beschreibt og:title als Titel des Objekts im Graphen und og:url als kanonische URL, die als dauerhafte Objektkennung verwendet wird. Auf der News-Seite bezeichnen beide Felder die Privacy Policy.

Das beweist die ausgelieferten Eingabedaten, nicht die Darstellung bei Facebook, X oder einem anderen Dienst. Plattformen können cachen, andere Felder wählen oder widersprüchliche Werte verwerfen. Eine beobachtete Vorschau bräuchte daher eine eigene, datierte Erfassung.

JSON-LD liefert sogar die Gegenposition und bleibt bei News. Das Problem besteht nicht in fehlender Maschinenlesbarkeit, sondern in mehreren vollständigen, einander widersprechenden Identitäten.

Ein semantischer Freigabenachweis pro Route

Jede öffentliche Route sollte einen kleinen Identitätsnachweis erhalten. Er verbindet angeforderte und aufgelöste URL mit der freigegebenen Inhaltsrolle, HTML-Titel und H1, Canonical und Begründung der Duplikat- oder Obermengenbeziehung, Beschreibung, Open Graph, Twitter, Typ/Name/URL der strukturierten Daten, Sitemap-Eintrag, ausgerollte Version oder Byte-Hash, Prüfergebnis, Ausnahmen und Korrekturhistorie.

Die Prüfung muss semantisch sein. „Antwortet das Canonical-Ziel mit 200?“ würde hier grün werden. „Ist og:title vorhanden?“ ebenfalls. Erst „Beschreiben alle Felder dasselbe freigegebene Objekt?“ erfasst den Fehler.

Die kleinste Reparatur lässt beide Inhalte bestehen. Die News-Seite erhält Canonical-, Beschreibungs- und Social-Werte, die zu ihrer sichtbaren Rolle passen. Vorher- und Nachher-Hashes sowie der Korrekturzeitpunkt halten fest, was sich änderte. Externe Caches bleiben ein späterer, separater Zustand.

Vier Zustände statt einer dramatischen Abkürzung

Erreichbarkeit: belegt. Quellidentität: widersprüchlich. Externe Verarbeitung: nicht beobachtet. Korrektur: erst mit einer neuen, geprüften Darstellung belegbar.

Diese Trennung macht die Bewertung belastbar. AFRINIC verdient Anerkennung für eine funktionierende öffentliche News-Liste. Gleichzeitig verdient die falsch gesetzte Maschinenidentität eine präzise Korrektur. Weder muss das eine das andere verdecken, noch braucht die Kritik einen erfundenen Schaden.

Quellen