work.log

元エンジニアの備忘録的ブログ

鬱陶しいコンテンツ丸パクリサイトを撃退する方法について

投稿:2017-07-23 22:10  更新:

コンテンツを丸パクリする鬱陶しいコピーサイトを撃退する方法をエンジニア的目線で考えてみるメモです。

新規取得等でドメイン評価が低いうちは、オリジナルコンテンツを先に公開していたとしても、後から丸ごとコピーしたサイトに検索順位が負けてしまう事が多々あります。

運営を続けドメインの評価が上がってくればそれらは気にならなくなる事が多いですが、やっぱりこういうのは情報発信をしている側からすれば精神衛生上良くないですよね。

自分も過去にこれで悩んだ事があったので、コピーサイトに対して実際にやってみた対策を紹介したいと思います。

また、自分もスクレイピング技術を使ってクローラーを作っている(パクリではなく)ので、そういう目線からその対策はどう見えているのかも解説していきます。

丸パクリサイトを撃退する方法

撃退方法をおすすめ順に書いていきます。

有名な「Googleの著作権侵害フォームに通報する」方法については周知の事実だと思うので今回は省いています。

また、用語は下記の意味で使っていきます。

スクレイピング = HTMLやRSSからコンテンツデータを抜き出す行為
スクレイパー = スクレイピングを行う人
クローラー = スクレイピングでコンテンツを収集するツール
スクレイピングサーバ = クローラーを動かしているホスト

ドメインパワーの強化

一番の対策は何といってもこれです。

検索順位がコピーサイトに負けてしまうのは、そこよりもドメインパワーが弱いからなので、結局はこれに勝たなくてはいけません。

なので、せっせとコンテンツを作っては公開して良質な被リンクを獲得していくしか無いかなと思うのですが、公開した傍らからコンテンツをパクられるのを見ているのはとても辛いのは確か。

ですが、自分の管理するサイトがパクリ問題を解決したのは最終的にこれだったのでこの方法を一番に推します。

某掲示板に「ドメインパワーが弱い所を狙う」とまで書き込んでいたスクレイパーが居たので、こういう輩が居る以上これ以外の対策は気休めにしかならないという事実があります。

RSSの全文配信を停止する

効果はイマイチなのですが、手軽なので一応やっておいた方が良いのは、RSSの全文配信を停止し抜粋配信にする方法です。

全文配信をするとコンテンツの全てをプログラムで処理しやすい形で公開する事になるので、スクレイパーの格好の標的となります。なのでやらないよりかはやった方が良いのは確かです。

ですが、これまでの経験でこの方法で防げたケースはそう多くはありませんでした。

読みものさんもRSSの全文配信からコンテンツがパクられているのではないかと分析していますが、もし自分がスクレイパーだったらRSSから抜けるか抜けないかは試さずに以下のようにプログラミングすると思います。

  1. クローラーを一定間隔で動かしRSSを取得する
  2. RSSフィードを解析しエントリーURLをDBに記録
  3. 項2のDBから照合して更新があるかどうかを確認する
  4. 更新があれば記事のHTMLデータを直接取得する
  5. HTML解析してコンテンツをスクレイピングする
  6. コピーサイトに投稿する(項1に戻る)

RSSフィードは最初は全文配信していても途中から抜粋配信に変更するサイトもあるので、プログラミングする時は確実に取れる方法を選択すると思います。

抜粋でもエントリーURLは確実に取れるのでそれさえわかればコンテンツを抜く何て簡単です。

また、上記ロジックのクローラーが来るとサーバのアクセスログにこのようなパターンのログが記録されます。

192.168.0.1 - - [23/Jul/2017:09:15:01 +0900] "GET /feed HTTP/1.1" 200 4047 "-" "-"
192.168.0.1 - - [23/Jul/2017:09:25:01 +0900] "GET /feed HTTP/1.1" 200 4047 "-" "-"
192.168.0.1 - - [23/Jul/2017:09:35:01 +0900] "GET /feed HTTP/1.1" 200 4047 "-" "-"
192.168.0.1 - - [23/Jul/2017:09:35:05 +0900] "GET /hoge.html HTTP/1.1" 200 68707 "-" "-"
192.168.0.1 - - [23/Jul/2017:09:45:01 +0900] "GET /feed HTTP/1.1" 200 4047 "-" "-"
192.168.0.1 - - [23/Jul/2017:09:55:01 +0900] "GET /feed HTTP/1.1" 200 4047 "-" "-"

このログの場合は3行目と4行目に注目です。確認する点は3点あって、

  1. 同じIPから一定間隔でRSSにアクセスがある
  2. 記事の更新を検知をすると即座に対象記事にアクセスしてくる
  3. しかも、HTMLや画像ファイル以外にはアクセスしない

というのがあります。

普通のアクセスであれば、記事を表示したらCSSやJSも一緒に読み込むはずですが、スクレイパーの書いたクローラーはそんな事しないので判断が付くと思います。

中には画像は元記事から直リンするという不届き者までいます。

ダミーのRSSを持っていかせる

これは結局試しませんでしたが、クローラーにダミーのRSSを掴ませるというのも有効な手段だと思います。

この方法が使えるのはWordPress等のCMSを使っている、かつプログラミングが出来る場合のみですが、上記のようにアクセスログからクローラーのパターンを分析して、それらからアクセスが来た場合は偽のRSSを渡してあげれば大人しく帰っていくと思います。

既にパクられた後のRSSフィードをコピーしておいて、その静的ファイルを毎回渡してあげれば更新無しと判断してくれると思います。

これで対応できないケース

ただし、以下の場合はこの方法では対応ができません。

  • RSSを使わずにスクレイピングしている場合
  • スクレイピングサーバがIPを変えてアクセスしてくる場合

クローラーによってはRSS自体を使わずに、GoogleBotのように直接HTMLをスクレイピングしてくるのもありますし、スクレイピングサーバがころころIPを変えてくる場合はパターン化するのが難しいのでこの場合も対処出来ないです。

Javascriptで強制リダイレクトさせる

次はコンテンツ側だけで出来る対策で、スクレイピング自体を防ぐ事は出来ませんがパクられた記事にアクセスしたユーザーを、自サイトに強制的にリダイレクトさせる方法となります。

コピーサイトの記事を無意味にするというささやかな抵抗程度の対策ですが、コンテンツを丸パクリするクローラーには特に有効な手段です。

この方法は記事の先頭に下記のようなJavascriptを埋め込むだけで対策が可能です。

<script type="text/javascript">
var url = location.href.match(/^https?:\/\/[^\/]+/);
	/* 末尾に / は付けない */
	if (url[0] != 'https://worklog.be') {
	location.href = 'https://worklog.be/';
}
</script>

面倒で無ければ location.href に設定するURLを元記事のURLにしておくと尚良いかと思われます。

これで対応できないケース

  • スクレイピング処理時に対策コードをプログラム処理で消された場合

コピーサイトやクローラーを定期的にメンテナンスしているマメなスクレイパーであれば、この対策にすぐ気付くと思うのでそうすればプログラム処理であっさりコードを消されてしまうとは思います。

また、コンテンツ部分に毎回これを記述しないといけないのがやや面倒なので、やはりCMS等で一括処理できる仕組みが欲しいと思います。

スクレイピングサーバの特定と遮断

次は古典的なスクレイピングサーバを逐一遮断する方法です。

Linux系サーバを操作出来る方であればiptables等のファイヤーウォール機能で、WordPressならプラグインのWP-Banを、あとは.htaccess等を使ってスクレイピングサーバのIPを遮断していきます。

スクレイピングサーバは維持費の安いVPSサーバを利用するケースが多く、それらはほぼ必ず固定IPからのアクセスになるのでアクセスログさえ解析できれば遮断するのは簡単です。

スクレイパーはクローラー稼働後は放ったらかしにしたり、スクレイピング対象のサイトが多すぎてメンテナンスが出来ず、遮断された事に気付かないケースも多いです。

これで対応できないケース

この方法は最も即効性があり強力ですが、解析・対応が面倒臭い他に下記の場合には向きません。

  • スクレイピングアクセスが多すぎる場合 (iptablesを除く)
  • スクレイピングサーバのIPが特定出来ない場合

一点目は、WP-Banや.htaccessで多くのIPを遮断していると動作が重くなってしまう可能性があるので、大量のスクレイピングサーバに狙われているケースではこの方法が使えません。その場合は動作の軽い、iptables等のOSのファイヤーウォール機能を使いましょう。

二点目は、他の対策方法でも言える事ですが、巧妙なスクレイパーであればIPを特定されないように頭を使ったり、IPをプロキシさせる仕組みをクローラーに搭載してくるのでそれをやられるとこの対策方法は無意味です。

特に面倒なのが自宅サーバを使ったスクレイピングで、遮断してもルーター再起動ですぐIPを変えて来ますし、開放されたIPはDHCPで他の一般ユーザーに割り当てられるので、ずっと遮断しておく訳にもいきません。

また、スクレイパー自体が次から次へと湧いて来るのでイタチごっことなるので、この方法も結局は気休めとなります。

2年位コツコツと遮断してきた結果、対象のスクレイピングサーバは209ホストにもなっていました。

勿論、既に潰れたコピーサイトが大半ですが解除の精査をする為に時間をまた使うのは勿体無いですよね…

クローラーをパターン化してWebサーバの機能で弾く

先程と似たような方法で、クローラーをパターン化して弾く方法を紹介します。

これはApacheやNginxといったWebサーバを管理する人しか出来ない方法なのですが、サクッと設定できて割りと広範囲に効くので結構おすすめだったりします。

Nginxで実際に使っているクローラー避けの設定を公開します。

set $deny_f 0;

# 出来の悪いクローラーがよく使うUserAgent
if ($http_user_agent ~* (libwww-perl|Ruby|FeedWordPress|Python-urllib|UniversalFeedParser|MagpieRSS)) {
	set $deny_f 1;
}

# Googlebotはアクセスを通すように念のため設定
if ($http_user_agent ~* (Googlebot)) {
	set $deny_f 0;
}

# 遮断対象のUserAgentでアクセスしてくるが除外したいホストはIPでここに設定
if ($remote_addr ~* (192.168.0.1|192.168.0.2)) {
	set $deny_f 0;
}

# 鬱陶しいクローラーはサヨナラー
if ($deny_f) {
	rewrite ^(.*)$ http://example.com//$1 last;
}

これを deny.conf という名前で保存します。

deny.conf を /etc/nginx/conf.d に保存した場合、下記のように読み込んでおきましょう。

server {

	listen       80;
	server_name  worklog.be;
	root         /home/blog/worklog.be/htdocs;

	access_log  /home/blog/worklog.be/log/nginx-access.log combined;
	error_log   /home/blog/worklog.be/log/nginx-error.log warn;

	include  conf.d/deny.conf;
.
.
.
~略~
.
.
.
}

これでプログラムデフォルトのUserAgentを吐くような出来の悪いクローラーは寄って来ません。

長い事これを使っていますが、Googleとかの必要なアクセスはきちんと通しているのでSEO的にも問題ありません。

これで対応できないケース

  • クローラーがUAを吐き出さない場合
  • クローラーがUAをきちんとUAを偽装している場合

この方法で対応出来ないのは主に上記のようなケースですが、賢いクローラーはちゃんと?UserAgentを偽装したりしてきます。

また、UserAgent自体を吐かないのもいますがこれは下手に遮断すると、一般ユーザーのRSSリーダーだったという事も考えられるので仕方ないですが放置するしかありません。

一応、IPを逆引きしてみて一般向けのISPなのか、サーバ事業者のIPなのかは見ておいた方が良いです。もし、サーバの固定IPであればスクレイピングサーバを疑って、ファイヤーウォールで遮断しておけば良いかと思います。

何もしない

もし、コピーサイトが自サイトよりショボい場合は、あえて何もしないというのも1つの対策だと思っています。

これは最初に書いた「ドメインパワーの強化」に関連しますが、余計な対策に時間を使わずにコンテンツ作成に注力しドメインパワーを上げていこうという考えです。

コピーサイトはいい加減に作られている事が多くて、デザインはお粗末、広告ベタベタでここが評価され続けるとはとても思えないサイトばっかりです。

なので、「作ったは良いが全然稼げなかった」と言ってサイトを閉鎖する人が多いのも事実です。(元スクレイパーに実際に聞いた話し)

何ていうか、そういう人らはコンテンツさえぶっこめば放ったらかしで楽に稼げる、という事しか考えていないみたいで勝手に自滅してくれます。

そして、プログラムが得意な人だけがスクレイパーをやっている訳ではなく、どちらかと言うと楽して稼ぎたい人が外注プログラマーを使って、クローラーを作らせているというケースも多いと思います。なので、納品後はろくにメンテナンスせずに放置して自滅という事も起きるんでしょうね。

ただし、サイトデザインが優れていて自サイトよりもユーザーフレンドリー、スクレイピングしたコンテンツを二次加工して付加情報を加えたようなサイトだったら必ず対処しましょう。

その場合はコピーサイトという枠を超えて強大なライバルになる可能性があり、自サイトが完全に喰われてしまうので非常にマズイです。物凄くレアなケースですが。

まとめ:最も有効なコピーコンテンツ対策は…

実際に試した、または試そうと思った対策を書いてきましたが、最も有効だった対策は最初の「ドメインパワーの強化」です。もうこれが最強です。

RSSの設定を変えてみたり、コツコツ遮断したり(2年も…)してましたが、スクレイピングサーバの特定作業は結構大変なので、最後は疲れて何もしなくなってひたすらコンテンツ作りに集中するように。

その間にコピーコンテンツはどんどん出来ては潰れましたが、自サイトの運営歴とドメインパワーは確実に上がっていきます。また、Googleのアルゴリズムも変わり、丸パクリのコピーコンテンツは前より評価されにくくなったようで更に追い風に。

今でも自サイトを丸パクリするスクレイパーはいますが、もう何もしていないのが現状ですね。たまに見つけたら今後、脅威になりそうかどうかだけはチェックしますがこの運用で暫くやっていけてます。

2013年、2014年辺りは本当に丸パクリで稼いでいるコピーサイトを見かけましたが、何だかんだ言われながらもGoogleはこの辺に厳しくなったんじゃないかなと思っています。

ドメインパワーが付くまでは辛抱かもしれませんが、コンテンツのコンセプトや書き手の思考まではパクれないと思うので評価を得るまで頑張るしかないですね。

おすすめのVPSサーバ

  • OSが選べる
  • VPS同士でLANが組める
  • 複数台構成向き

このブログで使っています。

  • 転送量が多いサービスに
  • 借りてるのは3年間一度もdown無し!

よく見られている記事

  • 本日
  • 週間
  • 月間