Warning: Declaration of FEE_Field_Terms::wrap($content, $taxonomy, $before, $sep, $after) should be compatible with FEE_Field_Post::wrap($content, $post_id = 0) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/post.php on line 0

Warning: Declaration of FEE_Field_Tags::wrap($content, $before, $sep, $after) should be compatible with FEE_Field_Terms::wrap($content, $taxonomy, $before, $sep, $after) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/post.php on line 0

Warning: Declaration of FEE_Field_Category::wrap($content, $sep, $parents) should be compatible with FEE_Field_Terms::wrap($content, $taxonomy, $before, $sep, $after) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/post.php on line 0

Warning: Declaration of FEE_Field_Post_Thumbnail::wrap($html, $post_id, $post_thumbnail_id, $size) should be compatible with FEE_Field_Post::wrap($content, $post_id = 0) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/post.php on line 0

Warning: Declaration of FEE_Field_Post_Meta::wrap($data, $post_id, $key, $ui, $single) should be compatible with FEE_Field_Post::wrap($content, $post_id = 0) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/post.php on line 0

Warning: Declaration of FEE_Field_Widget::wrap($params) should be compatible with FEE_Field_Base::wrap($content, $data) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/widget.php on line 0

Warning: Declaration of FEE_Field_Comment::wrap($content) should be compatible with FEE_Field_Base::wrap($content, $data) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/other.php on line 0

Warning: Declaration of FEE_Field_Term_Field::wrap($content, $term_id, $taxonomy) should be compatible with FEE_Field_Base::wrap($content, $data) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/other.php on line 0

Warning: Declaration of FEE_Field_Single_Title::wrap($title) should be compatible with FEE_Field_Term_Field::wrap($content, $term_id, $taxonomy) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/other.php on line 0

Warning: Declaration of FEE_Field_Option::wrap($content, $key, $ui) should be compatible with FEE_Field_Base::wrap($content, $data) in /home/twfs/serverkurabe.com/public_html/blog/wp-content/plugins/front-end-editor/php/fields/other.php on line 0
SEO対策 | Sabakura Blog

DMCA侵害申し立てとその後の順位変化について(体験談)

記事にするのが遅くなってしまったのですが、今回もSEOに関連する実体験についてです。

順位の安定しないサイト

じつは以前から、管理サイトの中にいまいちGoogleでの検索順位が安定しないものがありました。まだ記事自体が数十ページしかない状態なので、コンテンツ量がやや不足しているのかとは感じていましたが、それでもやや腑に落ちない点がありました。

たとえば記事タイトルの完全一致で検索しても10位以下のページがあったり、検索数が少ない複合キーワードでも100位以下だったりと、これまでの他サイト運営の体験からすると明らかに順位が低いページが散見されていました。

とくに昨年10月頃から、この(ペナルティとまでは呼べないものの)明らかに若干なにかに阻害されている感じが続いていました(なお先日記事にしたペナルティを受けたサイトとは別のサイトです)。

コピーサイトを発見

それが今年に入ってから、そのサイトの記事の幾つかが丸々コピーされているのを発見しました。リライトなどは一切なく、完全に記事全文をそのままコピー、さらに画像まで同じものを流用されていました。

普段であれば無視するところですが、どうやら別のサイトから比較的強い被リンクもついているようで、Googleで記事タイトルで検索するとコピーサイトの方が上に来てしまいます。しかも公開日時が10月になっており、どうやらサイトの順位が不安定になった時期と一致します。

DMCA侵害の申し立て

そこでGoogleに対してDMCA(デジタルミレニアム著作権法)侵害の申し立てを行うことにしました。(直接サイト運営者に連絡をとるという方法も考えたのですが、今回は連絡先の記載が見当たらなかったためGoogleへの申し立てという手段になりました)

なおこの具体的な手順については、下記の記事に分かりやすくまとめられており大変参考になりました。

・著作権違反の全パクリサイトにDMCA侵害申し立てしたら12時間で処理された – パシのSEOブログ

なお上記に書かれている以外にとった作業として、念のためにWeb魚拓にてコピーサイトの各記事を保存しておきました。もしも証拠が必要となったら、と考えてのことです。

処理とその後の経過

前出のパシさんの記事では12時間で処理されたとなっていますが、私の場合は処理が完了したとの通知が来るまで約一週間かかりました。このあたりはサイトや申請タイミングによって若干誤差があるのかもしれません。

申し立てと処理完了、そしてその後のある複合キーワードの順位変化を示したものが以下のグラフです。なおグラフは順位チェックツールGRCのものを用いています。

DMCA侵害申し立て前後の順位推移

一目で分かるとおり、処理が完了して数日のタイミングで大きく順位が回復しています。その後やや小さな変動はあるものの、体感的に納得できるあたりで順位は推移しています。上記は一例ですが、このほかの複合キーワードや単一キーワードも全体的に大きな順位上昇を見せました。

またDMCA侵害の処理が完了すると、検索時には該当ページは「デジタルミレニアム著作権法に基づき~」といったメッセージとともに(表示を希望しないかぎりは)非表示となります。

ただ、じつはこの段階でもコピーサイトのタグやカテゴリのアーカイブが上位に出てしまうことがありました。しかしこれについてはその後自分のサイトの更新を続けていくと、一ヶ月ほどでオリジナルサイトより下にくるようになりました。

まとめ

コピーサイトへの対処は慣れないと手間もかかる作業であり、一般的にはそこまで神経質になる必要はないと思います。

しかし自分のサイトよりも明らかに評価が高くなってしまいっている場合や、Googleのロボットがコピーとコピー元を混同していると見受けられるような場合には、著作権侵害の申し立てをすることで順位を回復できる可能性があります。

検索順位は複合的な要因が絡み合っているため、DMCA侵害の申し立てをしても必ず回復すると保証はできませんが、原因解決のための一手として検討してみてください。

なおそもそもコピーサイトが存在するかどうかをチェックするための手法としては、自分の記事タイトルや本文で検索してみるといった方法のほか、下記のようなツールを利用する方法があります。

・コピペチェックツール影武者

Google XML Sitemapsで生成されるサイトマップの種類(xmlとgz)について

このブログを含めて、自分が管理しているサイトは原則としてGoogleのウェブマスターツール(WMT)に登録を行っています。あわせて、サイトマップの送信も行っています。

現在は管理しているサイトのほとんどがWordPressサイトになっているため、サイトマップの作成には有名なプラグイン「Google XML Sitemaps」を利用しています。

・Google XML Sitemaps – WordPress Plugins

ただ、このプラグインでは設定により「標準のXMLファイル(拡張子は.xml)」のものと「gz圧縮されたファイル(拡張子は.gz)」の両方を出力することができます。
※どちらかだけを作成することも可能です。

サイトマップファイルの生成

今まではあまり意識せずに両方を出力し、WMTにはgz形式のファイルを送信していましたのですが、ふと「どちらを送信するのが正しいのか?」「それとも両方送信するべきなのか?」「SEO上の効果に差はあるのか」などが気になったので調べてみました。

(もしかしてあまりに当たり前の情報だからなのかもしれませんが)意外とこのことに触れている記事が少なかったので、調べた結果を書いておきます。

gz圧縮について

まず「gz圧縮されたファイル」ですが、これについてはUnix/Linuxにおいて圧縮コマンド「gzip」を使った場合に生成されるファイルです。

このほかよく見られる圧縮形式として「.tar.gz」という形式がありますが、これは複数のファイルをgzipで圧縮したものです。サイトマップの場合は「sitemap.xml」のような単独のXMLファイルを圧縮するため、(.tarのつかない)「.gz」形式になります。

ためしにこのブログのサイトマップのサイズを確認してみたところ、以下のような結果になりました。たしかにgz形式のほうがサイズが明らかに小さくなっています。

  • sitemap.xml:18,342 byte
  • sitemap.xml.gz:2,440 byte

ウェブマスターツールへの登録について

では実際にWMTに送信するサイトマップの形式はどちらが望ましいかです。これについては、じつは「Google XML Sitemaps」の公式ヘルプに答えに近いことが書かれていました。

The “sitemap.xml.gz” is a compressed version of the “sitemap.xml” file. It has the same content, but is significantly smaller than the other one. This helps you and the search engines to save a lot of traffic. Since all search engines support compressed sitemaps, you actually don’t need the “sitemap.xml”, but maybe you or your visitors want to view them from time to time so keeping it doesn’t hurt.

要約すると「どちらの形式で作成しても中身には変わりないが圧縮されたgz形式だとサイズが小さいため、トラフィックの節約になる。すべてのの検索エンジンは圧縮したサイトマップを読み取れるので通常はgz形式で問題ない。ただユーザーが直接サイトマップファイルを閲覧するような場合には.xmlが役立つこともある」というわけです。

なおxml形式で送信したからといってインデックスが遅くなるなどのデメリットがあるというわけではないようです。なお、私は一時期「.xml」と「.gz」を両方ともWMTに送信していたことがありますが、とくに警告を受けたりSEO面で順位に変化も感じられませんでした。

ようするに、通常はサイズの小さいgz形式のファイルを送信していればOKということです。これで安心してサイトマップを送信することができるようになりました。

内部リンクだけでもGoogleペナルティは起こる&rel=”nofollow”での回避策

追記(2016年):現在も一定のアクセスをいただいているようなのですが、現在のGoogleにおいてはこの記事のペナルティ回避策は上手く働かなくなったように思います。(あくまで感覚的な話ですが)たとえnofollowをつけたとしても、それが内部リンクであれば通常のfollowリンクに近い形で認識されているように感じます。

※実体験を元にした情報ではありますが、SEOの専門家ではないためこの記事に書かれている推測が100%正しいと保証するものではありません。その点はご了承ください。

上記画像は私が管理しているサイト(このブログではないですが)のあるキーワードでの順位推移を示したものです。分かりにくいですが、三週間ほど150~250位を前後したあとに、いきなり5位前後まで上昇しています。

ペナルティ事例の解説

じつはこのキーワードは以前は2~5位で何ヶ月も安定していたのですが、ある日突然に大幅な順位下落を起こし、そのまま一ヶ月以上停滞していました。この現象は特定キーワードだけのものではなく、同サイトのほぼすべてのページが関連キーワードで100位以下~圏外まで飛びました。順位下落の状況としては「これってGoogleのペナルティなの?」に近いです。

自分としてはブラックハット的な施策は行っていないつもりでしたし、ウェブマスターツールにも警告メールが届いていないため、原因がまったく分からない状況でした。幸いにしてすでにリカバリは完了しているのですが、ペナルティにいたったと推測される要因があまり他のSEOブログでは見かけない情報だったため今回記事にしてみました。

※本来は「ペナルティ」という用語は、Googleとしての正式なものではありませんが、ここでは話を分かりやすくするために使用しています。

ちなみに画像は検索順位ツールである「GRC」のものです。本当は以前の安定していた頃の順位も見せれるとよいのですが、今回のペナを受けたことから導入を開始したため以前のデータがありません。

原因は内部リンクの数とアンカーテキスト

過剰な内部リンク

さて結論から書いてしまうと、(100%確実と断言できるわけではありませんが)おそらく原因は過剰な内部リンクにありました。

このサイトではとくにユーザーにとって価値が高いと思われるページに対して、様々なページの本文中から内部リンクを貼っていました。例としては以下のような感じになります。

ただしコスパ重視で選ぶなら商品Aもおすすめです。いくつかの面で商品Bに比べれば質は落ちますが、とても安価で気軽に購入できます。

上記はあくまでも例ですが、このような感じでいくつかのページの本文中から訴求したい商品Aに対して内部リンクを貼っていました。このときのアンカーテキストは「商品A」という商品名そのままを使っていました。

といっても、これはSEO的にページランクの受け渡しを狙ったわけではなく、単純にユーザーにとって最適な導線を提供しているだけのつもりでした。

なるべく良い商品を選んでもらえるようにすぐにページ移動できるようにしていたわけです。もちろん商品Aのみに集中させていたわけではなく、商品Bや商品Cなどにも、それぞれ状況に応じて同様の内部リンクを貼っていました。

内部のみでペナルティは発生しないのでは?

ここでSEOにある程度詳しい方であれば「内部リンクのみでペナルティは発生しないのでは?」と思うかもしれません。

実際「内部リンク ペナルティ」などで検索をすると「(昔のYahooは別として)現在のGoogleではまずペナらないのでさほど心配なし」といった記事が多く目に付きます。私も今までは、ヘッダやサイドバーへのキーワード詰め込みのような形でなければまず問題はないと考えていました。

しかし今回の体験談から言えば「内部のみでもGoogleのペナ発生はありうる」ことになります。しかも本文中からのリンクでも起こりえます。

リカバリ施策

半分ほどに減らすも反応なし

上記の「内部リンクが原因では?」に思い当たった時点で、対策をとることにしました。

素直に考えればリンクを減らすのが王道ですから、まず重要でないと思われるものを中心に全体の内部リンク数を半分ほどに削減しました。あわせてそのほか可能性として考えられる要因を修正した上で、Googleにサイトの再審査を依頼しました。

しかし返ってきたのは「手動対応は行っておりません」のメッセージのみでした。メッセージ到着から一週間ほど様子見をしましたが、順位変動もないため「リカバリ失敗」と判断しました。

rel=”nofollow”を付与

となると内部リンクをさらに減らすかですが、これ以上減らすと訪問してくれたユーザーにとっても不便になる可能性が出るため、できればその手はとりたくありませんでした。

そこで考えたのが「rel=”nofollow”」の使用です。もともとnofollowは信頼できないサイトに対して使用するものであり、「内部リンクにはnofollow属性を付けなくてよい」「自分のサイトのページを信頼していないし保証しないということになる」といった記事に見るように、内部に対して付与するものでないのは知っていました。

しかし「本当に内部リンクにrel=”nofollow”は不要なのか」の記事に見るように、あえてnofollowを使うことで、ユーザーを最適なページへ案内するために使う方法もありえます。

今回の事例で言えば「べつにページランクの受け渡しはゼロであってもかまわないが、ユーザーへの導線としてリンクは残しておきたい」と考え、そのためにrel=”nofollow”を内部リンクにつけることにしました。

そこでページランクが渡らないnofollowを、「商品A」や「商品B」でアンカーテキストを貼っている内部リンクのほぼすべてに付けてみました。結果として、4~5日後に見事に順位が回復しました。

本当に内部リンクが原因だったのか

順位が回復したとはいえ、これはアルゴリズム変更やそのほかの要因による可能性もあります。しかし、今回は高確率で内部リンクが原因だったと判断しています。根拠は以下の三点です。

  • このほかの疑わしい要素に対するリカバリ施策については、再審査を出した時点ですべて行っていた。しかし再審査後に一週間以上経っても順位にまったく変化は見られなかった。
  • その後、内部リンク施策のみ(nofollow化)を行ったところ、数日後にはっきりとした変化があった。
  • じつは同様のペナルティを受けている別サイトがあり、そちらでは内部リンクをすべて剥がす(nofollowをつけるのではなくリンクそのものを削除)という施策を同タイミングで行ったところ、このサイトとまったく同じタイミングで順位回復した。

このことから、内部リンクが原因であったこと、およびnofollowの付与がリンク削除と同じ効果を出したことが確認できます。

結論

長くなってしまいましたので、あらためて結論を書いておきます。

  • 本文からの内部リンクのみでも、数が多すぎたりアンカーテキストが最適化されすぎていると、(たとえそれがユーザーのためのものであっても)Googleの自動アルゴリズムによりペナルティを課せられる場合がある。
  • 対処法としてはリンクを剥がすのが王道だが、どうしても残しておきたいリンクの場合は「rel=”nofollow”」をつけることでも同様の効果が得られる。(ただし2012年12月現在の手法であり、また自己責任で行ってください)

今回のペナルティはSEO関連のブログなどにも既存の情報が少なくて原因を突き止めるのにも苦労しましたので、せっかくなのでここに情報を共有してみました。同じようなペナルティ状況で苦しんでいる方の一助になれば幸いです。