やわなべです。
だいぶ前に、「linkis.com」という、URL短縮サービスなのか、ブックマークサービスなのかよくわからないサービスに、自サイトのコンテンツが取り込まれて表示されるのを回避しようと悪戦苦闘したことを書きました。
過去記事 linkisとかいう微妙サービス経由でシェアされるのをカドが立たないように回避する方法
このエントリー、地味にアクセスがありまして、何度か「ここに対処法が書いてありますよ〜」的な会話がTwitter上でなされてるのを見かけたりもしてたんですが、先日「この記事の方法で解決しました！ありがとうございました」とご丁寧なご報告をいただきました。
コメント欄のないこのブログのメールフォームからわざわざお知らせいただいて、お礼の返信をしたところ、「実はですね..」と他にもコピーサイトにお困りのご様子。
なんでも、いわゆる「魚拓」系のサービスのひとつに「archive.is」というサービスがあるらしく、「ここにコンテンツが転載されるのを防ぐ方法を知りたいんですが、ご存じないでしょうか？」とのこと。
どこの馬の骨だかわからない私のような輩にお尋ねになるとは、よほどお困りとお察し致します。決して専門家でもないのですが、このようなリクエストを頂くこともあまりないことので、夏休みの自由研究課題として調べてみましたよ。
以下に書いた方法は有効ですが、結論として書いたクローラーのIPアドレスが、2016年6月現在、別のIPアドレスに変わっているようです。
こちらの方が、最新のIPアドレス含む情報を発信しておられますので、あわせてご参照ください。
アーカイブ拒否を無視するarchive.isをブロックする « REIMA’s Blog
archive.is サーバーIPアドレス一覧 « REIMA’s Blog
スポンサーリンク
archive.isって何だ？
archive.is が何か？については、こちらを見たほうが早いかもしれません。
（参考）Web魚拓のようにウェブサイトを保存できるサービスまとめ – NAVER まとめ
2014年の12月にアップされたこのまとめ記事の冒頭で、
ウェブ魚拓よりも削除されにくく取り逃しも少ないです。現在一番使える魚拓サイトです。
とのコメントで紹介されているのが「archive.today」というサービス。このサービスがドメインの移転で「archive.is」として現状運営されているようです。
ドメインの所有者として登録しているのはチェコの方でした。ちなみに「.is」というトップレベルドメインは「イスラミック・ステート」のドメイン、、、、なわけがなく、アイスランドのカントリードメインなんですね。
魚拓系のサービスの用としては、主に、自サイトがパクリにあったり、相手が「書いた、書いてない」といった証拠として使われるものですが、一番有名な「web魚拓」と違って
・キャッシュ拒否のサイトでも保存できる
・一旦とった魚拓が削除されにくい
という、（魚拓を取る側にとって）都合が良いサービスとして利用されてるようです。裏を返せば取られる側にとっては都合の悪いサービスとも言えますね。
archive.isのサイトTOPは、このようになってまして、ここに魚拓を取りたいペページのURLを入れると、「http://archive.is/[キー文字列]/」のURLで、そのページのコピーが作られます。コピーを取るのは指定した１ページのみで、下層のページをたどってサイト全体をまるまるコピーしたりはしないようです。
dc.js – Dimensional Charting Javascript Library
アーカイブされたページのサンプルとしてアップされてるのがこちら。特徴的なのは「Webpage」の隣にある「Screenshot」というタブ。アーカイブを取る際、サイトの見た目を1枚のキャプチャ画像として保存するようです。
現時点では、コピーページに広告も入っておらず「archive.is」が、各サイトのコンテンツをパクることで自らの価値を高めたり、コピー元サイトの価値を減じようとする意図があるようには感じませんでした。
が、写真や画像といったコンテンツを持ってるサイトオーナーからすれば、誰かがここにアーカイブし、そこの画像ファイルに直接リンクを貼られたりなんかすると、対処がとっても面倒そうです。
ダミーサイトをアーカイブしてみた
もう少し「archive.is」の挙動を詳しく見るべく、使ってないドメインでアップしたダミーサイト（リファラスパム対策の記事の検証で使ったやつ）をアーカイブしてみます。確かめたかったのはここらへん。
1. 画像ファイルはどのようにコピーされるのか？
2. GoogleAnalyticsのスクリプトは丸コピされるのか？
3. アドセンスのタグもそのままコピーされるのか？
4. サイトURLの一意性を示す「canonical」タグは尊重されるのか？
以下、ひとつずつ結果を検証していきましょう。
1. 画像ファイルはどのようにコピーされるのか？
サイトのコピーは「http://archive.is/XXXXXXX/」というURLで保存されますが、そこに貼っつけた画像も「http://archive.is/XXXXXXX/YYYYYYYYYY.jpg」といった別のファイル名で保存されるようでした。キャッシュはコピーした日時ごとに保存されるので、都合が悪くてあとで消した画像なんかがここに残ってたりすると、かなり厄介な感じです。
2. GoogleAnalyticsのスクリプトは丸コピされるのか？
ヘッダーにGoogleアナリティクスのアクセス解析のコードは書いたページをアーカイブさせたんですが、その部分はまるごと削除されてました。
自サイトのAnalyticsのアクセス解析が汚染されるということはないようですが、マイナーなアクセス解析なんかだと、スクリプト丸ごとコピーされる可能性はあるかも。
3. アドセンスのタグもそのままコピーされるのか？
同じように、Googleアドセンスの広告タグも入れてみたんですが、これもきれいに除去されてました。 キャッシュ先での規約違反によって、アドセンスを止められるといったリスクはないようです。
4. サイトURLの一意性を示す「canonical」タグは尊重されるのか？
canonical指定は、同じコンテンツ内容を返すページのURLが複数あるときに、「このURLがメインだよ」と、検索エンジンなどに教えるためのものです。
（参考）Google、ドメイン間の rel=”canonical” タグのサポート開始 | 海外SEO情報ブログ
具体的にはHTMLのヘッダー部分に、
<link rel="canonical" href="https://ywnb.net/p/201508/12345">のように記述します。Wordpressだと勝手についてるんじゃないでしょうか。
で、魚拓サイトがコピーページによる、検索エンジンへの悪影響を配慮してくれるなら、コピー元のソースの「canonical」指定をそのまま記載して欲しいところなんですが….
<link rel="canonical" href="http://archive.is/XXXXXX/">はい、アーカイブページのソースを見ると、せっかくつけたcanonical指定もタグも、アーカイブページのURLに差し替えられてしまってました。
悪意というよりは何も考えずに元ドメインのURLを全変換してるんでしょう。せめてここは改善してもらいたいなぁ。
archive.isの運営ポリシーを見てみよう
次に、archive.isのサイトのFAQページから、どういうポリシーでこの魚拓サービスを運営しているのかを見てみましょう。
（参考）FAQ | archive.is
Q. 一旦保存したページが削除されることあるの？
A. ホスティングサーバーの規約違反となるページ（暴力やポルノ、違法性のあるページ）は削除するよ。あと、中身の無いページ（サーバーのエラー画面とか）もね
訳は適当ですが、コンテンツ権利者が自分のコンテンツを保護するためのキャッシュ削除に関しては言及がありませんでした。削除申し立ての仕組みもどうやらなさそうですね。
Q. なんでarchive.isは robots.txtの指定を無視するの？
A. 検索エンジンのクローラーのようにページ中のリンクたどるようなことはしてなくて、あくまで普通のユーザーがブラウザから閲覧するのと同じやり方でページ見てるからね。robots.txtの対象とは考えてないよ。
補足すると前述の「ウェブ魚拓」は、サイトオーナーがrobots.txtに書いたポリシーを尊重してくれるんで、「User-agent: MegalodonDisallow: /」とrobots.txtに書いておけば、魚拓をとられることを回避することができるんですね。一方、「archive.is」はこのような配慮をするつもりはないようです。
archive.isのアーカイブ保存を回避する
お待たせしました。存在意義はわかるけど、自サイトのキャッシュを知らないところで保存されるのはやっぱり勘弁、という場合はどうすればいいでしょうか。
robots.txtを見てくれないなら、archive.isからのアクセスをサーバーレベルで拒否するしかなさそうです。上で、ダミーページのキャッシュを何度かとった時のサーバーのアクセスログを抜き出すとこんな感じでした。
———-
78.46.174.147 – – [17/Aug/2015:22:14:52 +0900] “GET / HTTP/1.1” 200 1326 “-” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36”
———-
78.46.174.142 – – [17/Aug/2015:22:30:48 +0900] “GET /index2.html HTTP/1.1” 200 2642 “https://www.google.com/” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36”
———-
78.46.174.130 – – [17/Aug/2015:22:43:59 +0900] “GET /index3.html HTTP/1.1” 403 2309 “https://www.google.com/” “Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36”
———-
3つのページを3回に分けて保存したんですが、それぞれ同じネットワーク内の3つのIPアドレスからアクセスがありました。たしかに上のFAQで書いてる通り「通常のwebブラウザから来ました」と偽装してアクセスしているようですね。
IPアドレスの持ち主を確認できるこのサイトで検索してみると、IPの持ち主は「hetzner.de」というドイツのドメインオーナーのようです。
同ドメインにアクセスし、「HETZNER」のサイトを見ましたが、普通のホスティングサーバー業者のようでした。archive.is はここのサーバを借りて、クローラを動かしているみたいですね。
他にも複数拠点にサーバーを借りてクローラを分散配置している可能性はありますが、「78.46.174.128 – 78.46.174.159」という範囲のIPアドレスからのアクセスを拒否すれば少なくとも今回のクローラーのアクセスは拒否できそう。
この範囲のアクセスを拒否するには .htaccess ファイルに、
deny from 78.46.174.128/27
と書けばOKです。「/27」という書き方はこちらのサイトを参考にしました。
（参考）サブネットマスク計算(IPv4)／サブネット一覧（早見表）
実際、この記述を書いたあとで、再度上のサイトの別のページのアーカイブを取ろうとすると….
サーバー側でアクセスが拒否され、サイトを設置しているエックスサーバーのデフォルトのエラー画面をアーカイブしていかれました。ご苦労さまです。
まとめ
上にも書いたように、archive.is が、今後別のIPからクロールしてくる可能性もありますし、今後出てくる第２、第３の魚拓サービスとのいたちごっこも終わることはないんでしょう。
ただ、どんな場合も基本的な対処は同じで、
1) クローラーのアクセスのIPを記録する（できれば複数）
2) そのIPを拒否する記述を.htaccessに書く（できれば範囲指定で）
ということですね。
まあ、そのうち自分の身を守るためにこれらのサービスを使うかもしれないので、魚拓系サービスの存在意義を全否定はしませんけれどもね。参考になれば幸いです。