要約

  • 8月31日の AFRINIC News & Announcements はHTTP 200で応答し、タイトル、H1、2026年の告知一覧、JSON-LDはいずれもニュースページを示した。
  • 同じHTMLのcanonical、通常のdescription、Open GraphのタイトルとURL、Twitterのタイトルは、別に存在するPrivacy Policyを示していた。
  • AFRINICのsitemapはnewsとprivacyを別々に列挙している。RFC 6596がcanonicalの前提とする重複または包含関係は、取得した二つの本文には見当たらない。
  • 確認できたのは公開元の識別子不一致であり、検索順位の低下、アクセス減、誤ったカード表示ではない。修正はルート単位の識別記録で検証すべきだ。

まず、本文が機能していることを認める

8月31日05:46 UTC、ニュースのURLは200を返した。ブラウザのタイトルは「News & Announcements - AFRINIC - Regional Internet Registry for Africa」、画面の大見出しも「News & Announcements」だった。本文には2026年の最新告知が並び、Appeal Committee、CEO designate、メンバーと関係者への調査などをたどることができた。

JSON-LDもニュース側にそろっている。ページ名はNews & Announcements、URLは news.html で終わる。パンくずとナビゲーションもNewsを指す。したがって、この事例を「ニュースが消えた」「Privacy Policyに置き換わった」と表現するのは正しくない。

200は到達性の証拠である。ただし、到達できたページが機械に対してどのオブジェクトを名乗っているかまでは保証しない。今回の差は、その次の確認で現れる。

<head> ではPrivacy Policyを名乗る

ニュースページのcanonicalは https://afrinic.net/privacy.html だった。通常のmeta descriptionはAFRINICのPrivacy Policyの公式ページだと説明し、keywordsもprivacy policyから始まる。Open GraphのタイトルはPrivacy Policyで、絶対URLも同じページを指す。Twitterのタイトルと説明もPrivacy Policyのものだった。

これは単なる www の有無ではない。パスがnewsからprivacyへ変わり、ページの役割そのものが変わる。

比較先の AFRINIC Privacy Policy も200で応答する。こちらはブラウザタイトル、H1、自己参照のcanonicalがすべてPrivacy Policyとして一致している。壊れたリンクが問題なのではない。正常に存在する別の文書を、ニュースの優先識別先にしている点が問題だ。

canonicalが成立するための条件

RFC 6596 は、canonicalを重複コンテンツの集合から優先IRIを指定する関係として説明する。対象は参照元と重複する内容、またはその内容を含む上位版でなければならない。

取得したニュース一覧とプライバシーポリシーは、題名も目的も本文も異なる。前者は後者の分割ページではなく、後者も前者の「すべて表示」版ではない。ラベルを付けただけで重複関係が生まれるわけではない。

一方、canonicalはリダイレクトではない。RFCは、不適切な指定をアプリケーションが無視し、独自の判断を使う場合も認めている。このため、ニュースが検索結果から消えた、評価が移った、流入が減ったとは結論できない。確認できるのは、そうした処理に使われ得る誤った宣言が配信されたことまでである。

sitemapは二つの文書を分けている

AFRINICのsitemap には /news と /privacy が別々の行として載っている。これは通常のサイトマップであり、Googleニュース用でも、実際のインデックス状況を示すものでもない。

それでも比較資料として意味がある。AFRINIC自身の発見用リストは二つの公開資源を区別しているのに、ニュースページのcanonicalだけが両者を一つの優先識別先へまとめようとしているからだ。

ホスト名や .html の有無も記録すべきだが、中心的な失敗はURL表記ではない。「ニュース」と「プライバシー」という内容種別の不一致である。

ソーシャル用の識別は別に検証する

Open Graph protocol は、og:title をグラフ内で表示されるオブジェクト名、og:url を恒久的な識別子として使うcanonical URLと定義している。ニュースのHTMLは、ここでもPrivacy Policyを指定していた。

ただし、FacebookやXなどが実際に誤ったプレビューを出した証拠はない。各サービスはキャッシュを持ち、別のフィールドを選び、矛盾する値を無視することもある。公開元の入力とプラットフォームの出力は別々の証拠である。

さらにJSON-LDはニュースのままだ。機械可読情報が欠けているのではなく、canonical、ソーシャル、構造化データという複数の経路が異なる回答を返している。存在確認だけのテストでは見つからない。

ルートごとの公開識別記録

必要なのは、公開ルートごとに小さな識別記録を残すことだ。要求URLと最終URL、承認したページの役割、HTML titleとH1、canonicalと重複・包含関係の根拠、description、Open Graph、Twitter、構造化データの型・名称・URL、sitemap上の位置、配信したビルドまたはバイトのハッシュ、検証結果、例外、修正履歴を一つに結ぶ。

検証は意味を比較しなければならない。canonicalの対象が200かだけを調べれば、Privacy Policyが正常なので合格してしまう。Open Graphの必須項目があるかだけを調べても合格する。問うべきなのは、それらがH1と本文で承認した同じオブジェクトを表しているかである。

このケースの最小修正は、ニュース本文やPrivacy Policyを削除することではない。ニュース側のcanonical、description、ソーシャル識別子を現存するニュース内容に合わせ、修正前後のハッシュと時刻を残すことだ。外部キャッシュの更新は、その後に別の時計で観測する。

四つの状態を混同しない

到達性は「200でニュース本文が届いた」。公開元の識別は「一部フィールドがPrivacy Policyを示した」。外部処理は「未観測」。修正は「新しい配信バイトで未確認」。

この四つを分ければ、評価は過小にも過大にもならない。AFRINICはニュースを公開し続けている。同時に、機械向けの識別が別文書を指している。前者を認めながら後者を修正対象にできる。

Last-Modifiedは発生日ではない

ニュースの応答には Last-Modified: Fri, 28 Aug 2026 17:23:02 GMT も付いていた。これは今回取得した表現を特定する手掛かりにはなるが、誤ったメタデータが8月28日に初めて現れた証拠にはならない。本文の更新、静的ファイルの再配置、別の変更でも同じ値は更新され得る。過去のバイト列やリリース記録なしに、障害開始日へ読み替えてはいけない。

将来canonicalが正しくなった場合も同様である。その時点で修正済みだとは言えるが、いつから正しかったかは一回の取得では決まらない。旧ハッシュ、新ハッシュ、それぞれの応答時刻、途中の公開履歴がそろって初めて、修正区間を限定できる。

この時間分離は外部キャッシュの評価にも効く。元ページが直った後に古いカードが残っていても、直ちに修正失敗とは言えない。配信元の時計とプラットフォーム再取得の時計を別々に保存すべきである。

出典