blocked-page-recovery

ブロックされたページの復旧

ページを取得できない場合（403/429、Cloudflare の「Just a moment...」、ペイウォール、ボット検出のインタースティシャルなど）も、諦めたり同じ URL を繰り返し試したりしないでください。サードパーティのサービスがページのコピーを保持していることがよくあります。最もコストの低い方法から、次の手順を試してください。

手順

1. Wayback Machine  — archive.org "available" API  (snapshot + timestamp)
2. archive.today    — domain rotation: archive.ph → .md → .li → .is
3. Jina Reader      — only if JINA_API_KEY is set  (live server-side render)
4. API-first pivot  — look for /api/, /graphql, .json, or RSS on the same host
5. Real browser     — browser tool as the last, most expensive resort

同梱スクリプトを使って、まとめて実行します。

python3 scripts/recover_page.py "https://example.com/blocked-article" --json

スクリプトは各方法を順番に試し、各本文を検証し（下記の「見せかけの成功」を参照）、最初に見つかった本物の結果とその出所を表示します。

出所の明記（必須）

復元したコピーにはそれぞれ出所が付随します。引用時には必ず保持してください。

方法	出所	引用方法
Wayback / archive.today	snapshot	スナップショットの日付を含めて引用します：「2026-08-06 にアーカイブされたもの」。スナップショットを公開中のページとして提示してはいけません。古い可能性があります。
Jina Reader	live	公開中のページをサーバー側で再レンダリングしたものです。通常どおり引用します。
ライブ取得 / ブラウザー	live	通常どおり引用します。

ユーザーが最新のデータ（価格、在庫状況、速報など）を必要としている場合、スナップショットは参考情報であり、回答そのものではありません。その点を明示し、いつの情報かも記してください。

手動で試す方法

1. Wayback Machine（出所が最も明確なため、最初に試す）

# Discovery: returns closest snapshot URL + timestamp as JSON
curl -sL "https://archive.org/wayback/available?url={URL}"
# Then fetch archived_snapshots.closest.url

多数のスナップショットを列挙する場合（または削除されたページを復元する場合）は、CDX インデックスを使います。

curl -sL "https://web.archive.org/cdx/search/cdx?url={URL}&output=json&limit=10"

CDX は負荷が高いと 503 を断続的に返します。その場合は available API に切り替えてください。繰り返しリクエストを送らないでください。

利用できる対象：公開状態でクロールされた URL。利用できない対象：robots によってブロックされたサイト、クロールされたことのない URL、JS のみの SPA（スナップショットはレンダリングされません）。

2. archive.today（ペイウォール、削除されたコンテンツ）

ユーザー投稿型のアーカイブです。Wayback にない、ペイウォール付きニュース記事が見つかることがよくあります。 レート制限が厳しく（429）、ドメインも切り替わるため、順に試してください。

for d in archive.ph archive.md archive.li archive.is; do
  curl -sL --max-time 20 "https://$d/newest/{URL}" -o ~/.hermes/cache/scratch/page.html \
    -w "%{http_code}" && break
done

ステータスコードではなく本文を検証してください。429 でも数 KB のレート制限用 HTML が返されることがあり、サイズだけを確認すると成功したように見えてしまいます。

3. Jina Reader（JINA_API_KEY が必要）

r.jina.ai は実際のブラウザーを使って公開中のページをサーバー側で再レンダリングし、Markdown を返します。匿名アクセスは利用できません（401 → Turnstile）。キーが必要です。

curl -s -H "Authorization: Bearer $JINA_API_KEY" "https://r.jina.ai/{URL}"

アーカイブでは対応できない JS SPA も処理できます。環境変数が設定されていない場合は、この方法を完全にスキップしてください。

4. API を優先する方法への切り替え

WAF は、その背後にあるデータエンドポイントよりも HTML の表示面をはるかに厳しく保護します。あるサイトで 2～3 回ブロックされたら、HTML へのアクセスを試すのをやめ、次を探してください。

• ページ URL の /api/...、/graphql、または .json 版
• RSS/Atom フィード（復元できたコピーにある /feed、/rss、<link rel="alternate">）
• サイトマップ（/sitemap.xml）。アクセス制限のない正規 URL が見つかる場合があります。

見せかけの成功 — 結果を偽る方法

これらは HTTP 200 と一見もっともらしい本文を返しますが、ページそのものではありません。スクリプトは自動的に除外しますが、手動で確認する場合も同様に除外してください。

• Google Cache は提供を終了しています（2024 年半ば以降）。webcache.googleusercontent.com は 200 と数十 KB のデータを返しますが、キャッシュではなく、JS リダイレクトを含む Google Search のインタースティシャルです。絶対に使わないでください。
• AMP キャッシュ（*.cdn.ampproject.org）の多くは、元の（ブロックされた）URL に戻る、約 300 バイトの <title>Redirecting</title> メタリフレッシュ用スタブを返します。これを成功として扱うと、取得ループが発生します。
• レート制限の本文：archive.today の 429 ページは数 KB の HTML です。サイズだけでなく、対象の実際のコンテンツ（タイトルの語句、想定される文字列など）が含まれているか確認してください。

スクリプトが適用する検出ヒューリスティック：方法ごとに定められたバイト数の下限を下回る本文、リダイレクト先が元のホストであるメタリフレッシュ／JS リダイレクトのスタブ、「Just a moment」「Redirecting」「Google Search」「Attention Required」といったインタースティシャルのタイトル。

プロキシリレーは使わない

汎用的な「ウェブプロキシ」リレーは、仕組み上、中間者として動作します。Cookie や Authorization ヘッダーを通してはいけません。また、ユーザーが信頼して利用するものには使わないでください。出所を検証できないためです。少なくともコピーにタイムスタンプを付与するアーカイブを優先してください。